From ayoung at redhat.com Sun Mar 2 03:07:38 2014 From: ayoung at redhat.com (Adam Young) Date: Sat, 01 Mar 2014 22:07:38 -0500 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <5310A983.50409@redhat.com> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> <53105B27.4070003@redhat.com> <1393597539.3562.21.camel@localhost.localdomain> <20140228144351.GC16644@redhat.com> <1393599745.3562.23.camel@localhost.localdomain> <20140228151536.GD16644@redhat.com> <5310A983.50409@redhat.com> Message-ID: <5312A07A.3060706@redhat.com> On 02/28/2014 10:21 AM, Petr Viktorin wrote: > On 02/28/2014 04:15 PM, Alexander Bokovoy wrote: >> On Fri, 28 Feb 2014, Nathaniel McCallum wrote: >>> On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: >>>> On Fri, 28 Feb 2014, Nathaniel McCallum wrote: >>>> >On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: >>>> >> On 28.2.2014 04:02, Rob Crittenden wrote: >>>> >> > Alexander Bokovoy wrote: >>>> >> >> On Thu, 27 Feb 2014, Nathaniel McCallum wrote: >>>> >> >>> So the recent discussion on importing tokens led me to write a >>>> script to >>>> >> >>> parse RFC 6030 xml files into IPA token data. This all works >>>> well. But >>>> >> >>> now I need to integrate it into the IPA framework. >>>> >> >>> >>>> >> >>> This command will parse one or more xml files, creating a set >>>> of tokens >>>> >> >>> to be added. Given that we already have otptoken-add on the >>>> server-side, >>>> >> >>> it seems to me that all work needs to be done on the >>>> client-side. How do >>>> >> >>> I create a new client-side command that calls existing >>>> server-side API? >>>> >> >> subclass from frontend.Local, override run() or forward() >>>> method and >>>> >> >> perform batch >>>> >> >> operation of otptoken_add from there. >>>> >> >> >>>> >> >> See cli.help, for example. >>>> >> > >>>> >> > If you do an override, do forward() for cli-specific work. >>>> >> > >>>> >> > But you should do as little as possible for reasons you already >>>> stated: >>>> >> > the UI. Anything you do in forward Petr will need to implement >>>> in the UI. >>>> >> > >>>> >> > Unfortunately we don't yet have a nice way to handle files. We >>>> have >>>> >> > tickets open at https://fedorahosted.org/freeipa/ticket/1225 and >>>> >> > https://fedorahosted.org/freeipa/ticket/2933 >>>> >> > >>>> >> > If this file is something that would be pasted into a big text >>>> field >>>> >> > then you can probably handle it in a similarly clumsy way that >>>> we do >>>> >> > CSRs in the cert plugin. >>>> >> > >>>> >> > rob >>>> >> >>>> >> +1 for parsing it on server. Otherwise every client, not just CLI >>>> or Web >>>> >> UI, would have to reimplement the same logic - having it on server >>>> will >>>> >> support better integration with third party products. >>>> >> >>>> >> Parsing on client would be understandable if there was some middle >>>> step >>>> >> which would require some action from user, i.e, pick only some >>>> tokens to >>>> >> import. >>>> > >>>> >If we parse on the server side, how do we handle the long-running >>>> >operation? Think of the case of importing hundreds or thousands of >>>> >tokens... >>>> Why then to do it as a IPA CLI command at all? >>>> This is an administrative task which can be done with a separate >>>> ipa-otp-import command, designated to run on IPA masters. >>> >>> Agreed. >>> >>> 1. Is there a framework for this? Or should it just be an independent >>> script? >> We don't really have a framework for administrative tools. You may start >> with install/tools/ipa-adtrust-install, it is main part is relatively >> independent of the task (which is in >> ipaserver/install/adtrustinstance.py) >> > > The framework is there, new tools use it, and there's a ticket to > convert old ones: https://fedorahosted.org/freeipa/ticket/2652 (it's > low priority in Future Releases, so not much progress is there...) > Also see http://www.freeipa.org/page/V3/Logging_and_output > > The RESTful approach would be: 1. Upload a file to a specific URL (not JSON RPC) 2. Receive back a 202 Accepted HTTP Request, to include an URL to poll for status Not certain the right response from the URL in step 2 would be, but I am assuming it would be 200 with the body of the message stating: processing or completed. It would be really nice if the Batch command could be handled this way as well. The response back could be the partial responses until processing is complete. It might also be nice to supply an email address for notification of completed processing instead of polling, if it is going to be a really long running task. From redhatrises at gmail.com Sun Mar 2 22:26:43 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Sun, 2 Mar 2014 15:26:43 -0700 Subject: [Freeipa-devel] [PATCH 0007][DOC] Tip on restoring admin account In-Reply-To: References: <5310871D.7050702@redhat.com> Message-ID: Here is an updated patch that merges the notes and adds info about preventing removal of the last admin. Gabe On Fri, Feb 28, 2014 at 8:39 AM, Gabe Alford wrote: > That does make more sense to merge them under the same note. I can also > include a little blurb about ipa user-del and ipa group-remove-member. > > > On Fri, Feb 28, 2014 at 5:54 AM, Petr Viktorin wrote: > >> On 02/26/2014 04:01 PM, Gabe Alford wrote: >> >>> Hi all, >>> >>> I added a tip in the deleting users section on restoring admin account. >>> Please review. >>> >>> https://fedorahosted.org/freeipa/ticket/2746 >>> >> >> >> Hello, >> >> The new tip is added right under a Note about the same thing (or a very >> similar thing, from the user's POV). Would it be possible to merge those >> two into a single Note? >> >> Nowadays[0], ipa user-del and ipa group-remove-member will refuse to >> delete the last admin. I think this information should be added to the main >> docs. (Also, this reduces the importance of the recovery instructions.) >> >> [0] https://fedorahosted.org/freeipa/ticket/2564 >> >> -- >> Petr? >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0007-2-DOC-Document-steps-to-restore-deleted-admin-account.patch Type: application/octet-stream Size: 2250 bytes Desc: not available URL: From mkosek at redhat.com Mon Mar 3 08:50:43 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 03 Mar 2014 09:50:43 +0100 Subject: [Freeipa-devel] server install failing in F-20? In-Reply-To: <20140228220537.GB3638@redhat.com> References: <5310F62B.5030206@redhat.com> <20140228220537.GB3638@redhat.com> Message-ID: <53144263.80205@redhat.com> On 02/28/2014 11:05 PM, Alexander Bokovoy wrote: > On Fri, 28 Feb 2014, Rob Crittenden wrote: >> I'm seeing what looks like https://fedorahosted.org/freeipa/ticket/4084 in >> new F-20 install I stood up. I finally threw my hands up and configured >> system to use an environment file to work around it. >> >> Not sure if anyone else is seeing this. > One difference on F20 is that you are not supposed to see ccaches in > /tmp -- they are in the kernel keyring. Did you test with freeipa-server-3.3.4-3.fc20.x86_64? Works for me in up-to-date F20. This build contains the patches in the ticket and thus fixes the bug 1044994. Martin From pviktori at redhat.com Mon Mar 3 10:13:30 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 03 Mar 2014 11:13:30 +0100 Subject: [Freeipa-devel] [PATCH 0007][DOC] Tip on restoring admin account In-Reply-To: References: <5310871D.7050702@redhat.com> Message-ID: <531455CA.8040504@redhat.com> On 03/02/2014 11:26 PM, Gabe Alford wrote: > Here is an updated patch that merges the notes and adds info about > preventing removal of the last admin. > > Gabe That looks misleading to me -- by default, the "group administrators" privilege actually excludes the right to modify admins. Only admins or the Directory Manager can add new admins. I took a stab at correcting this; does the attached patch look good? > > > On Fri, Feb 28, 2014 at 8:39 AM, Gabe Alford > wrote: > > That does make more sense to merge them under the same note. I can > also include a little blurb about ipa user-del and ipa > group-remove-member. > > > On Fri, Feb 28, 2014 at 5:54 AM, Petr Viktorin > wrote: > > On 02/26/2014 04:01 PM, Gabe Alford wrote: > > Hi all, > > I added a tip in the deleting users section on restoring > admin account. > Please review. > > https://fedorahosted.org/__freeipa/ticket/2746 > > > > > Hello, > > The new tip is added right under a Note about the same thing (or > a very similar thing, from the user's POV). Would it be possible > to merge those two into a single Note? > > Nowadays[0], ipa user-del and ipa group-remove-member will > refuse to delete the last admin. I think this information should > be added to the main docs. (Also, this reduces the importance of > the recovery instructions.) > > [0] https://fedorahosted.org/__freeipa/ticket/2564 > > > -- > Petr? > > > -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0007-2+pviktori-Document-steps-to-restore-deleted-admin-account.patch Type: text/x-patch Size: 2088 bytes Desc: not available URL: From jcholast at redhat.com Mon Mar 3 10:43:21 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 03 Mar 2014 11:43:21 +0100 Subject: [Freeipa-devel] [PATCHES] 0483-0485 Move ipalib.text to ipapython In-Reply-To: <5310BDFD.5060003@redhat.com> References: <5310BDFD.5060003@redhat.com> Message-ID: <53145CC9.6020705@redhat.com> Hi, On 28.2.2014 17:49, Petr Viktorin wrote: > Hello! > > This moves ipalib.text to ipapython. > Why do we want this? > > Firstly, it's a step towards breaking the ipapython dependency on > ipalib, which is something we vaguely want to do in the long run for the > sake of clean code and potential reuse. > > But there's another reason: The DNS plugin defines some validators that > are used elsewhere. I'd like to eventually move them to ipapython, so > the DNS plugin can be made optional > (https://fedorahosted.org/freeipa/ticket/4058). > The validators use on ipalib.text, so that has to be moved to ipapython > (where I think it belongs). The validators are not used in ipapython, right? So why move them there? Also, the plan with DNS is to use python-dns where possible AFAIK, which will probably make most of the validators go away. Anyway, localization does not seem like a thing that a generic util module like ipapython should be bothered with, I would prefer if it stayed in ipalib and friends. > > The gettext wrappers in turn depend on the context, which I'd rather see > in ipalib, but it's literally one line of code so it's not a big burden > to have in ipapython. In the future we can think about somehow > extracting it and moving it back, if needed. I really don't see how tainting ipapython with stuff that is pure ipalib will make the code cleaner. > > > (And the first patch is just some general cleanup.) ACK on that. Honza -- Jan Cholasta From jcholast at redhat.com Mon Mar 3 10:43:45 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 03 Mar 2014 11:43:45 +0100 Subject: [Freeipa-devel] [PATCH] 238 Fix modlist generation code not to generate empty replace mods In-Reply-To: <5310AB4A.3050800@redhat.com> References: <52F0F2CA.9070701@redhat.com> <5310AB4A.3050800@redhat.com> Message-ID: <53145CE1.7070402@redhat.com> On 28.2.2014 16:29, Petr Viktorin wrote: > On 02/04/2014 03:01 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza > > Thanks, ACK. Here are some tests for this, do they look good? They look good to me, thanks. -- Jan Cholasta From pviktori at redhat.com Mon Mar 3 11:15:21 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 03 Mar 2014 12:15:21 +0100 Subject: [Freeipa-devel] [PATCH] 238 Fix modlist generation code not to generate empty replace mods In-Reply-To: <53145CE1.7070402@redhat.com> References: <52F0F2CA.9070701@redhat.com> <5310AB4A.3050800@redhat.com> <53145CE1.7070402@redhat.com> Message-ID: <53146449.2070605@redhat.com> On 03/03/2014 11:43 AM, Jan Cholasta wrote: > On 28.2.2014 16:29, Petr Viktorin wrote: >> On 02/04/2014 03:01 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >> >> Thanks, ACK. Here are some tests for this, do they look good? > > They look good to me, thanks. > Thanks, pushed to master: fa5cbe7cb2b30b055adfc68d160ddcfa1cec7b39 -- Petr? From lkrispen at redhat.com Mon Mar 3 11:51:32 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 03 Mar 2014 12:51:32 +0100 Subject: [Freeipa-devel] LDAP schema for PKCS#11 Message-ID: <53146CC4.8010200@redhat.com> Hi, starting a new thread, after a lot of discussion and feedback, which I tried to integrate into thecurrent draft at: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema Here are some design decisions I made and which need to be finally decided. 1] Add nss trust objects. These are not defined in the PKCS#11 standard, but Jan said they will be needed and I added them to the spec 2] Certificate representation In pkcs11 there is a certificate category (user, authority, ..) and certificate value. An alternate way to represent this would be to use the schema defined in rfc4523 and map (user, value) --> (objectclass: pkiUser, usercertificate) and (authority, value) --> (objectclass: pkiCA, cAcertificate) I kept the attributes pkcs11certificateCategory and pkcs11certificateValue and let the applications decide which format will be used. 3] Key attributes Like certificates keys can be stored ina single attribute as pkcs8 or bind.key format. In pkcs11 the keys are defined by their algoritthm specific attributes, I had defined RSA specific attributes (moduleus, exponent, ....) and did not remove them. Maybe some app wants to create keys and store these attrs, having defined them does not force to use them, but allows flexibility without requiring new attribute definitions 4] Not needed attributes. Jan pointed out that some of the attributes like CKA_TOKEN will always be true, so no need to define them. I have not yet removed them, they don't nned to be used, but I can still remove them. 5] Attribute syntaxes I associated boolean attributes with the ldap boolean syntax, which requires TRUE/FALSE as values There are a couple of attributes with a limited range like key_type which has values like: CKK_RSA, CKK_DSA, CKK_DH. There are defines for these values which translate them to integers, which could be used, but I propose to use a syntax of directoryString and use the values directly eg pkcs11keyType: CKK_RSA. To me this is more readable than pkcs11keyType: 0 And it would have to be parsed anywy From jcholast at redhat.com Mon Mar 3 12:14:41 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 03 Mar 2014 13:14:41 +0100 Subject: [Freeipa-devel] [PATCH 0042] Rework how otptoken defaults are handled In-Reply-To: <1393001129.23210.40.camel@localhost.localdomain> References: <1392993950.23210.22.camel@localhost.localdomain> <1392995390.23210.27.camel@localhost.localdomain> <530770D9.4020104@redhat.com> <1393001129.23210.40.camel@localhost.localdomain> Message-ID: <53147231.2060505@redhat.com> On 21.2.2014 17:45, Nathaniel McCallum wrote: > On Fri, 2014-02-21 at 16:29 +0100, Jan Cholasta wrote: >> Hi, >> >> On 21.2.2014 16:09, Nathaniel McCallum wrote: >>> On Fri, 2014-02-21 at 09:45 -0500, Nathaniel McCallum wrote: >>>> We had originally decided to provide defaults on the server side so that >>>> they could be part of a global config for the admin. However, on further >>>> reflection, only certain defaults really make sense given the >>>> limitations of Google Authenticator. Similarly, other defaults may be >>>> token specific. >>>> >>>> Attempting to handle defaults on the server side also makes both the UI >>>> and the generated documentation unclear. >>>> >>>> NOTE: this patch changes an existing API. VERSION says that we should >>>> bump the major version in this case. But we haven't actually released >>>> this API yet. Please advise. >> >> There were similar changes in the past and bumping minor version was >> always enough (we never ever bump major version). > > Fixed. Thanks, ACK. > >>> >>> I forgot to mention something else about this patch. The default_from in >>> the key parameter generates a warning. This is because the default is a >>> bytes string and internally a check is done against NULLS >>> (constants.py:36). The u'' in NULLS forces an attempt to convert the >>> byte string to unicode. When this fails (because ipatokenotpkey is *NOT* >>> a string but a byte array), a warning is thrown. >>> >>> Since '' and u'' evaluate as equal, what is the point of having u'' in >>> NULLS? I don't see any way to suppress this warning except to remove u'' >>> from NULLS. >> >> I think we can get rid of NULLS entirely and do something better instead >> (like "if not value and value is not False:"). >> >> Is this worth filing a ticket? > > How about a patch? > > https://www.redhat.com/archives/freeipa-devel/2014-February/msg00426.html Even better. But next time please post it in the same thread, so that other people don't review it while I'm reviewing it as well. > > Nathaniel > -- Jan Cholasta From tbabej at redhat.com Mon Mar 3 12:41:38 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 03 Mar 2014 13:41:38 +0100 Subject: [Freeipa-devel] [PATCHES] 0337-0343 YAML test configuration In-Reply-To: <52CA81B1.4040602@redhat.com> References: <52A9A0A9.9040706@redhat.com> <52CA81B1.4040602@redhat.com> Message-ID: <53147882.9090203@redhat.com> Finally got to this patchset! PATCH 337: ACK PATCH 338: ACK This prohibits us to use extra roles that end in digits. Can you put a note explaining that in http://www.freeipa.org/page/V3/Integration_testing#Host_configuration Also, this wiki page points out to environment variables so that it seems it is the preferred method of configuration. We should mention more user friendly YAML here first. PATCH 339: ACK PATCH 340: ACK PATCH 341: The have_master variable seems redundant in from_dict method (it's only a local definition and not referenced anywhere else): + def from_dict(cls, dct, config): + from ipatests.test_integration.host import BaseHost + + domain_type = dct.pop('type') + assert domain_type in ('IPA', 'AD') + domain_name = dct.pop('name') + self = cls(config, domain_name, domain_type) + + have_master = False + for host_dict in dct.pop('hosts'): + host = BaseHost.from_dict(host_dict, self) + self.hosts.append(host) + if host.role == 'master': + have_master = True + + check_config_dict_empty(dct, 'domain %s' % domain_name) + + return self PATCH 342: ACK PATCH 343: ACK PATCH 348: ACK PATCH 349: ACK On 01/06/2014 11:13 AM, Petr Viktorin wrote: > On 12/12/2013 12:40 PM, Petr Viktorin wrote: >> Hello Tom??! I'm planning a little Christmas present for you. Instead of >> a surprise I'm Releasing early :) >> Apply patches or: git pull http://github.com/encukou/freeipa yaml-config >> >> >> These patches add YAML/JSON configuration for tests. >> >> YAML/JSON is completely optional, the existing envvar style continues to >> work. The ipa-test-config tool can convert between the two (which is not >> just for show, export will be needed for debugging and unit tests). >> If you choose to use YAML, you need PyYAML (python-yaml) installed. >> >> >> Example: >> >> $ MASTER=master.ipa.test REPLICA=repl.ipa.test >> TESTHOST_XYZ_env1=xyz.ipa.test BEAKERMASTER1_IP_env1=1.2.3.4 >> BEAKERREPLICA1_IP_env1=1.2.3.5 BEAKERXYZ1_IP_env1=1.2.3.6 >> ipa-test-config --global --yaml | tee /tmp/testconf.yaml >> ad_admin_name: Administrator >> ad_admin_password: Secret123 >> admin_name: admin >> admin_password: Secret123 >> debug: false >> dirman_dn: cn=Directory Manager >> dirman_password: Secret123 >> dns_forwarder: 8.8.8.8 >> domains: >> - hosts: >> master: >> external_hostname: master.ipa.test >> ip: 1.2.3.4 >> role: master >> repl: >> external_hostname: repl.ipa.test >> ip: 1.2.3.5 >> role: replica >> xyz: >> external_hostname: xyz.ipa.test >> ip: 1.2.3.6 >> role: xyz >> name: ipa.test >> type: IPA >> ipv6: false >> nis_domain: ipatest >> ntp_server: 2.pool.ntp.org >> root_password: null >> root_ssh_key_filename: ~/.ssh/id_rsa >> test_dir: /root/ipatests >> >> $ IPATEST_YAML_CONFIG=/tmp/testconf.yaml ipa-run-tests ... >> >> >> >> What's left is to update the design and write tests. I'll get to it >> eventually, but now I'll probably be busy for a few days. If you'd like >> to do them as part of review, tests could be in the format: >> >> from ipatests.test_integration import config >> conf = config.Config.from_env($environment) >> assert conf.to_dict() == {$result} >> >> conf = config.Config.from_dict($inputdict) >> assert conf.to_dict() == {$result} >> >> >> https://fedorahosted.org/freeipa/ticket/3938 > > Tests added, new version attached. > As for #4081 (Export dynamic roles properly in ipa-test-config), hosts > are exported like static roles are (from the TestComplexConfig case): > > TESTHOST_EXTRAROLEM_env1="extram1.ipadomain.test extram2.ipadomain.test", > TESTHOST_EXTRAROLEM1_env1="extram1.ipadomain.test" > TESTHOST_EXTRAROLEM2_env1="extram2.ipadomain.test" > > For cases where there's just a single host of the role, it'll export > it both with the number and without. > -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From jcholast at redhat.com Mon Mar 3 12:49:20 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 03 Mar 2014 13:49:20 +0100 Subject: [Freeipa-devel] LDAP schema for PKCS#11 In-Reply-To: <53146CC4.8010200@redhat.com> References: <53146CC4.8010200@redhat.com> Message-ID: <53147A50.3070901@redhat.com> Hi, adding Stef Walter to CC, as he has extensive knowledge of PKCS#11. On 3.3.2014 12:51, Ludwig Krispenz wrote: > Hi, > > starting a new thread, after a lot of discussion and feedback, which I > tried to integrate into thecurrent draft at: > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema > > Here are some design decisions I made and which need to be finally decided. > > 1] Add nss trust objects. > These are not defined in the PKCS#11 standard, but Jan said they will be > needed and I added them to the spec For the record, here are some details about NSS trust objects: BTW, there are some additional attributes defined in /usr/include/nss3/pkcs11n.h besides these mentioned in the link above: CKA_TRUST_IPSEC_END_SYSTEM CKA_TRUST_IPSEC_TUNNEL CKA_TRUST_IPSEC_USER CKA_TRUST_TIME_STAMPING CKA_TRUST_STEP_UP_APPROVED Can you please add them as well? > > 2] Certificate representation > In pkcs11 there is a certificate category (user, authority, ..) and > certificate value. An alternate way to represent this would be to use > the schema defined in rfc4523 and map > (user, value) --> (objectclass: pkiUser, usercertificate) and > (authority, value) --> (objectclass: pkiCA, cAcertificate) > I kept the attributes pkcs11certificateCategory and > pkcs11certificateValue and let the applications decide which format will > be used. Applications talking to PKCS#11 do not need to be concerned with this and applications talking to LDAP will be only us. This only adds complexity, as there will have to be two code paths to handle certificates (plus code for handling conflicts between them, etc.) in the module instead of just one. I would prefer if pkcs11certificateValue and pkcs11certificateCategory were removed. They can be re-added later if someone needs them (we don't). > > 3] Key attributes > Like certificates keys can be stored ina single attribute as pkcs8 or > bind.key format. In pkcs11 the keys are defined by their algoritthm > specific attributes, I had defined RSA specific attributes (moduleus, > exponent, ....) and did not remove them. Maybe some app wants to create > keys and store these attrs, having defined them does not force to use > them, but allows flexibility without requiring new attribute definitions These attributes do not add flexibility, because they are RSA only, they only add complexity, because (again) there will have to be two code paths in the module to handle keys. Again, I would prefer if the extra attributes were removed. > > 4] Not needed attributes. > Jan pointed out that some of the attributes like CKA_TOKEN will always > be true, so no need to define them. > I have not yet removed them, they don't nned to be used, but I can still > remove them. Please do. It just makes no sense to have an LDAP attribute for CKA_TOKEN. > > 5] Attribute syntaxes > I associated boolean attributes with the ldap boolean syntax, which > requires TRUE/FALSE as values > There are a couple of attributes with a limited range like key_type > which has values like: CKK_RSA, CKK_DSA, CKK_DH. There are defines for > these values which translate them to integers, which could be used, but > I propose to use a syntax of directoryString and use the values directly > eg pkcs11keyType: CKK_RSA. To me this is more readable than > pkcs11keyType: 0 > And it would have to be parsed anywy +1, but I would prefer just "pkcs11keyType: rsa" (i.e. camel-cased and stripped of "CKK_" prefix) rather than "pkcs11keyType: CKK_RSA". The attribute is named "pkcs11keyType", not "pkcs11CKA_KEY_TYPE" after all. Honza -- Jan Cholasta From amessina at messinet.com Mon Mar 3 13:26:13 2014 From: amessina at messinet.com (Anthony Messina) Date: Mon, 03 Mar 2014 07:26:13 -0600 Subject: [Freeipa-devel] server install failing in F-20? In-Reply-To: <5310F62B.5030206@redhat.com> References: <5310F62B.5030206@redhat.com> Message-ID: <1754397.DFb9NVD6TC@linux-ws1.messinet.com> On Friday, February 28, 2014 03:48:43 PM Rob Crittenden wrote: > I'm seeing what looks like https://fedorahosted.org/freeipa/ticket/4084 > in new F-20 install I stood up. I finally threw my hands up and > configured system to use an environment file to work around it. > > Not sure if anyone else is seeing this. In reference to finding a way to upgrade F19 to F20: https://www.redhat.com/archives/freeipa-users/2014-March/msg00000.html I've been doing some VM testing of both F19 to F20 "yum upgrades" as well as fresh installs on F20. I actually have better luck with the yum upgrade. The fresh install of FreeIPA on F20 fails near the end of the process using freeipa-server-3.3.4-3.fc20.x86_64. I have to manually start named and sometimes krb5kdc/kadmin then it works after a reboot. *** F20 fresh install error: 2014-03-02T20:41:10Z DEBUG Starting external process 2014-03-02T20:41:10Z DEBUG args=/bin/systemctl enable ipa.service 2014-03-02T20:41:10Z DEBUG Process finished, return code=0 2014-03-02T20:41:10Z DEBUG stdout= 2014-03-02T20:41:10Z DEBUG stderr=ln -s '/usr/lib/systemd/system/ipa.service' '/etc/systemd/system/multi-user.target.wants/ipa.service' 2014-03-02T20:41:10Z DEBUG Starting external process 2014-03-02T20:41:10Z DEBUG args=/bin/systemctl restart ipa.service 2014-03-02T20:42:45Z DEBUG Process finished, return code=1 2014-03-02T20:42:45Z DEBUG stdout= 2014-03-02T20:42:45Z DEBUG stderr=Job for ipa.service failed. See 'systemctl status ipa.service' and 'journalctl -xn' for details. 2014-03-02T20:42:45Z DEBUG File "/usr/lib/python2.7/site- packages/ipaserver/install/installutils.py", line 622, in run_script return_value = main_function() File "/sbin/ipa-server-install", line 1230, in main ipaservices.knownservices.ipa.enable() File "/usr/lib/python2.7/site- packages/ipapython/platform/fedora16/service.py", line 134, in enable self.restart(instance_name) File "/usr/lib/python2.7/site-packages/ipapython/platform/base/systemd.py", line 131, in restart ipautil.run(["/bin/systemctl", "restart", self.service_instance(instance_name)], capture_output=capture_output) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 345, in run raise CalledProcessError(p.returncode, arg_string, stdout) 2014-03-02T20:42:45Z DEBUG The ipa-server-install command failed, exception: CalledProcessError: Command '/bin/systemctl restart ipa.service' returned non- zero exit status 1 *** F19 to F20 upgrade, things seem to go well until the restart of pki- tomcatd at pki-tomcat.service SEVERE: The scratchDir you specified: /var/lib/pki/pki- tomcat/work/Catalina/localhost/pki is unusable Changing the ownership of that directory to 'pkiuser:pkiuser' resolves the SEVERE entry in the log and things seem to work. -A -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From pspacek at redhat.com Mon Mar 3 13:30:25 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 03 Mar 2014 14:30:25 +0100 Subject: [Freeipa-devel] LDAP schema for PKCS#11 In-Reply-To: <53147A50.3070901@redhat.com> References: <53146CC4.8010200@redhat.com> <53147A50.3070901@redhat.com> Message-ID: <531483F1.6070005@redhat.com> On 3.3.2014 13:49, Jan Cholasta wrote: > On 3.3.2014 12:51, Ludwig Krispenz wrote: >> starting a new thread, after a lot of discussion and feedback, which I >> tried to integrate into thecurrent draft at: >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema I have added couple links and typo fixes to the document. Please add externals links when referring to some other standard so other people don't need to dig related links again and again. (I have added links for PKCS#8 and PKCS#11.) >> Here are some design decisions I made and which need to be finally decided. >> >> 1] Add nss trust objects. >> These are not defined in the PKCS#11 standard, but Jan said they will be >> needed and I added them to the spec > > For the record, here are some details about NSS trust objects: > This link definitely should be somewhere in design docs. > BTW, there are some additional attributes defined in > /usr/include/nss3/pkcs11n.h besides these mentioned in the link above: And this too... Feel free to upload the file to wiki if you didn't find any on-line repo suitable for direct linking from design docs. > CKA_TRUST_IPSEC_END_SYSTEM > CKA_TRUST_IPSEC_TUNNEL > CKA_TRUST_IPSEC_USER > CKA_TRUST_TIME_STAMPING > CKA_TRUST_STEP_UP_APPROVED > > Can you please add them as well? > >> >> 2] Certificate representation >> In pkcs11 there is a certificate category (user, authority, ..) and >> certificate value. An alternate way to represent this would be to use >> the schema defined in rfc4523 and map >> (user, value) --> (objectclass: pkiUser, usercertificate) and >> (authority, value) --> (objectclass: pkiCA, cAcertificate) >> I kept the attributes pkcs11certificateCategory and >> pkcs11certificateValue and let the applications decide which format will >> be used. > > Applications talking to PKCS#11 do not need to be concerned with this and > applications talking to LDAP will be only us. I would like to emphasis Rob's idea that this schema is IPA-specific for now but we should assume that other PKCS#11<->LDAP implementations can exist. > This only adds complexity, as there will have to be two code paths to handle > certificates (plus code for handling conflicts between them, etc.) in the > module instead of just one. This does not contradict my previous statement :-) Other PKCS#11 module implementations have to follow what we define here and I also prefer to keep it simple and extend it later as needed. > I would prefer if pkcs11certificateValue and pkcs11certificateCategory were > removed. They can be re-added later if someone needs them (we don't). > >> >> 3] Key attributes >> Like certificates keys can be stored ina single attribute as pkcs8 or >> bind.key format. In pkcs11 the keys are defined by their algoritthm >> specific attributes, I had defined RSA specific attributes (moduleus, >> exponent, ....) and did not remove them. Maybe some app wants to create >> keys and store these attrs, having defined them does not force to use >> them, but allows flexibility without requiring new attribute definitions > > These attributes do not add flexibility, because they are RSA only, they only > add complexity, because (again) there will have to be two code paths in the > module to handle keys. > > Again, I would prefer if the extra attributes were removed. I agree. >> 4] Not needed attributes. >> Jan pointed out that some of the attributes like CKA_TOKEN will always >> be true, so no need to define them. >> I have not yet removed them, they don't nned to be used, but I can still >> remove them. > > Please do. It just makes no sense to have an LDAP attribute for CKA_TOKEN. > >> >> 5] Attribute syntaxes >> I associated boolean attributes with the ldap boolean syntax, which >> requires TRUE/FALSE as values >> There are a couple of attributes with a limited range like key_type >> which has values like: CKK_RSA, CKK_DSA, CKK_DH. There are defines for >> these values which translate them to integers, which could be used, but >> I propose to use a syntax of directoryString and use the values directly >> eg pkcs11keyType: CKK_RSA. To me this is more readable than >> pkcs11keyType: 0 >> And it would have to be parsed anywy > > +1, but I would prefer just "pkcs11keyType: rsa" (i.e. camel-cased and > stripped of "CKK_" prefix) rather than "pkcs11keyType: CKK_RSA". The attribute > is named "pkcs11keyType", not "pkcs11CKA_KEY_TYPE" after all. -- Petr^2 Spacek From jcholast at redhat.com Mon Mar 3 14:03:03 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 03 Mar 2014 15:03:03 +0100 Subject: [Freeipa-devel] LDAP schema for PKCS#11 In-Reply-To: <53148911.4090606@redhat.com> References: <53146CC4.8010200@redhat.com> <53147A50.3070901@redhat.com> <531483F1.6070005@redhat.com> <53148911.4090606@redhat.com> Message-ID: <53148B97.4020900@redhat.com> On 3.3.2014 14:52, Stef Walter wrote: > On 03.03.2014 14:30, Petr Spacek wrote: >> On 3.3.2014 13:49, Jan Cholasta wrote: >>> On 3.3.2014 12:51, Ludwig Krispenz wrote: >>>> starting a new thread, after a lot of discussion and feedback, which I >>>> tried to integrate into thecurrent draft at: >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema >> I have added couple links and typo fixes to the document. Please add >> externals links when referring to some other standard so other people >> don't need to dig related links again and again. (I have added links for >> PKCS#8 and PKCS#11.) > > What is this for? This seems pretty wild :) This is for and , see for overview. > >>>> Here are some design decisions I made and which need to be finally >>>> decided. >>>> >>>> 1] Add nss trust objects. >>>> These are not defined in the PKCS#11 standard, but Jan said they will be >>>> needed and I added them to the spec >>> >>> For the record, here are some details about NSS trust objects: >>> > > Right, the NSS trust objects are definitely not an extensible scheme. > What's your use case. Don't you already have other ways in LDAP of > indicating trust in a certificate? The use case is to store NSS trust flags in LDAP along with CA certificates. > >> This link definitely should be somewhere in design docs. >> >>> BTW, there are some additional attributes defined in >>> /usr/include/nss3/pkcs11n.h besides these mentioned in the link above: >> And this too... Feel free to upload the file to wiki if you didn't find >> any on-line repo suitable for direct linking from design docs. >> >>> CKA_TRUST_IPSEC_END_SYSTEM >>> CKA_TRUST_IPSEC_TUNNEL >>> CKA_TRUST_IPSEC_USER >>> CKA_TRUST_TIME_STAMPING >>> CKA_TRUST_STEP_UP_APPROVED >>> >>> Can you please add them as well? >>> >>>> >>>> 2] Certificate representation >>>> In pkcs11 there is a certificate category (user, authority, ..) and >>>> certificate value. An alternate way to represent this would be to use >>>> the schema defined in rfc4523 and map >>>> (user, value) --> (objectclass: pkiUser, usercertificate) and >>>> (authority, value) --> (objectclass: pkiCA, cAcertificate) >>>> I kept the attributes pkcs11certificateCategory and >>>> pkcs11certificateValue and let the applications decide which format will >>>> be used. >>> >>> Applications talking to PKCS#11 do not need to be concerned with this and >>> applications talking to LDAP will be only us. >> I would like to emphasis Rob's idea that this schema is IPA-specific for >> now but we should assume that other PKCS#11<->LDAP implementations can >> exist. > > And also NSS specific, given the storage of NSS trust. I think we can make that conditional, i.e. by using an environment variable or the reserved argument in C_Initialize (like NSS does). If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust objects from the module? > > Cheers, > > Stef > -- Jan Cholasta From pviktori at redhat.com Mon Mar 3 14:15:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 03 Mar 2014 15:15:01 +0100 Subject: [Freeipa-devel] server install failing in F-20? In-Reply-To: <5310F62B.5030206@redhat.com> References: <5310F62B.5030206@redhat.com> Message-ID: <53148E65.6000502@redhat.com> On 02/28/2014 09:48 PM, Rob Crittenden wrote: > I'm seeing what looks like https://fedorahosted.org/freeipa/ticket/4084 > in new F-20 install I stood up. I finally threw my hands up and > configured system to use an environment file to work around it. > > Not sure if anyone else is seeing this. > > rob I'm getting a similar error in CI. Setting SELinux to permissive made it go away. A bugzilla is filed here: https://bugzilla.redhat.com/show_bug.cgi?id=1063827 -- Petr? From redhatrises at gmail.com Mon Mar 3 14:16:25 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 3 Mar 2014 07:16:25 -0700 Subject: [Freeipa-devel] [PATCH 0007][DOC] Tip on restoring admin account In-Reply-To: <531455CA.8040504@redhat.com> References: <5310871D.7050702@redhat.com> <531455CA.8040504@redhat.com> Message-ID: Yes, the attached patch looks good. I see what you are saying how it did look misleading. Thanks, Gabe On Mon, Mar 3, 2014 at 3:13 AM, Petr Viktorin wrote: > On 03/02/2014 11:26 PM, Gabe Alford wrote: > >> Here is an updated patch that merges the notes and adds info about >> preventing removal of the last admin. >> >> Gabe >> > > That looks misleading to me -- by default, the "group administrators" > privilege actually excludes the right to modify admins. Only admins or the > Directory Manager can add new admins. > > I took a stab at correcting this; does the attached patch look good? > > >> >> On Fri, Feb 28, 2014 at 8:39 AM, Gabe Alford > > wrote: >> >> That does make more sense to merge them under the same note. I can >> also include a little blurb about ipa user-del and ipa >> group-remove-member. >> >> >> On Fri, Feb 28, 2014 at 5:54 AM, Petr Viktorin > > wrote: >> >> On 02/26/2014 04:01 PM, Gabe Alford wrote: >> >> Hi all, >> >> I added a tip in the deleting users section on restoring >> admin account. >> Please review. >> >> https://fedorahosted.org/__freeipa/ticket/2746 >> >> >> >> >> >> Hello, >> >> The new tip is added right under a Note about the same thing (or >> a very similar thing, from the user's POV). Would it be possible >> to merge those two into a single Note? >> >> Nowadays[0], ipa user-del and ipa group-remove-member will >> refuse to delete the last admin. I think this information should >> be added to the main docs. (Also, this reduces the importance of >> the recovery instructions.) >> >> [0] https://fedorahosted.org/__freeipa/ticket/2564 >> >> >> -- >> Petr? >> >> >> >> > > -- > Petr? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon Mar 3 14:24:30 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 03 Mar 2014 15:24:30 +0100 Subject: [Freeipa-devel] LDAP schema for PKCS#11 In-Reply-To: <53148CA5.2040009@redhat.com> References: <53146CC4.8010200@redhat.com> <53147A50.3070901@redhat.com> <531483F1.6070005@redhat.com> <53148911.4090606@redhat.com> <53148B97.4020900@redhat.com> <53148CA5.2040009@redhat.com> Message-ID: <5314909E.9030502@redhat.com> On 3.3.2014 15:07, Stef Walter wrote: > On 03.03.2014 15:03, Jan Cholasta wrote: >> If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust >> objects from the module? > > No. This is the spec for storing trust policy in PKCS#11 that we've been > working on: > > http://p11-glue.freedesktop.org/doc/storing-trust-policy/ > > It's a far more extensible and future proof model. The p11-kit-trust > module stores/loads these sorts of objects, and additionally also > generates NSS trust objects on the fly so that NSS can consume the > information. > > It doesn't do that last bit for third party sources, but it could given > code :) Code is not a problem :) What would be the best way to provide trust policy to p11-kit from a third party PKCS#11 module, if not NSS trust objects? -- Jan Cholasta From pviktori at redhat.com Mon Mar 3 14:29:42 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 03 Mar 2014 15:29:42 +0100 Subject: [Freeipa-devel] [PATCH 0007][DOC] Tip on restoring admin account In-Reply-To: References: <5310871D.7050702@redhat.com> <531455CA.8040504@redhat.com> Message-ID: <531491D6.5060103@redhat.com> On 03/03/2014 03:16 PM, Gabe Alford wrote: > Yes, the attached patch looks good. I see what you are saying how it did > look misleading. > > Thanks, > > Gabe Thank you for your help! Pushed to docs master: dfb1b16b4b62e87540b34bae8b4454021f17fd71 > > > On Mon, Mar 3, 2014 at 3:13 AM, Petr Viktorin > wrote: > > On 03/02/2014 11:26 PM, Gabe Alford wrote: > > Here is an updated patch that merges the notes and adds info about > preventing removal of the last admin. > > Gabe > > > That looks misleading to me -- by default, the "group > administrators" privilege actually excludes the right to modify > admins. Only admins or the Directory Manager can add new admins. > > I took a stab at correcting this; does the attached patch look good? > > > > On Fri, Feb 28, 2014 at 8:39 AM, Gabe Alford > > >__> > wrote: > > That does make more sense to merge them under the same > note. I can > also include a little blurb about ipa user-del and ipa > group-remove-member. > > > On Fri, Feb 28, 2014 at 5:54 AM, Petr Viktorin > > >> > wrote: > > On 02/26/2014 04:01 PM, Gabe Alford wrote: > > Hi all, > > I added a tip in the deleting users section on > restoring > admin account. > Please review. > > https://fedorahosted.org/____freeipa/ticket/2746 > > > > > > > > Hello, > > The new tip is added right under a Note about the same > thing (or > a very similar thing, from the user's POV). Would it be > possible > to merge those two into a single Note? > > Nowadays[0], ipa user-del and ipa group-remove-member will > refuse to delete the last admin. I think this > information should > be added to the main docs. (Also, this reduces the > importance of > the recovery instructions.) > > [0] https://fedorahosted.org/____freeipa/ticket/2564 > > > > > -- > Petr? > > > > > > -- > Petr? > > -- Petr? From swalter at redhat.com Mon Mar 3 13:52:17 2014 From: swalter at redhat.com (Stef Walter) Date: Mon, 03 Mar 2014 14:52:17 +0100 Subject: [Freeipa-devel] LDAP schema for PKCS#11 In-Reply-To: <531483F1.6070005@redhat.com> References: <53146CC4.8010200@redhat.com> <53147A50.3070901@redhat.com> <531483F1.6070005@redhat.com> Message-ID: <53148911.4090606@redhat.com> On 03.03.2014 14:30, Petr Spacek wrote: > On 3.3.2014 13:49, Jan Cholasta wrote: >> On 3.3.2014 12:51, Ludwig Krispenz wrote: >>> starting a new thread, after a lot of discussion and feedback, which I >>> tried to integrate into thecurrent draft at: >>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema > I have added couple links and typo fixes to the document. Please add > externals links when referring to some other standard so other people > don't need to dig related links again and again. (I have added links for > PKCS#8 and PKCS#11.) What is this for? This seems pretty wild :) >>> Here are some design decisions I made and which need to be finally >>> decided. >>> >>> 1] Add nss trust objects. >>> These are not defined in the PKCS#11 standard, but Jan said they will be >>> needed and I added them to the spec >> >> For the record, here are some details about NSS trust objects: >> Right, the NSS trust objects are definitely not an extensible scheme. What's your use case. Don't you already have other ways in LDAP of indicating trust in a certificate? > This link definitely should be somewhere in design docs. > >> BTW, there are some additional attributes defined in >> /usr/include/nss3/pkcs11n.h besides these mentioned in the link above: > And this too... Feel free to upload the file to wiki if you didn't find > any on-line repo suitable for direct linking from design docs. > >> CKA_TRUST_IPSEC_END_SYSTEM >> CKA_TRUST_IPSEC_TUNNEL >> CKA_TRUST_IPSEC_USER >> CKA_TRUST_TIME_STAMPING >> CKA_TRUST_STEP_UP_APPROVED >> >> Can you please add them as well? >> >>> >>> 2] Certificate representation >>> In pkcs11 there is a certificate category (user, authority, ..) and >>> certificate value. An alternate way to represent this would be to use >>> the schema defined in rfc4523 and map >>> (user, value) --> (objectclass: pkiUser, usercertificate) and >>> (authority, value) --> (objectclass: pkiCA, cAcertificate) >>> I kept the attributes pkcs11certificateCategory and >>> pkcs11certificateValue and let the applications decide which format will >>> be used. >> >> Applications talking to PKCS#11 do not need to be concerned with this and >> applications talking to LDAP will be only us. > I would like to emphasis Rob's idea that this schema is IPA-specific for > now but we should assume that other PKCS#11<->LDAP implementations can > exist. And also NSS specific, given the storage of NSS trust. Cheers, Stef From swalter at redhat.com Mon Mar 3 14:07:33 2014 From: swalter at redhat.com (Stef Walter) Date: Mon, 03 Mar 2014 15:07:33 +0100 Subject: [Freeipa-devel] LDAP schema for PKCS#11 In-Reply-To: <53148B97.4020900@redhat.com> References: <53146CC4.8010200@redhat.com> <53147A50.3070901@redhat.com> <531483F1.6070005@redhat.com> <53148911.4090606@redhat.com> <53148B97.4020900@redhat.com> Message-ID: <53148CA5.2040009@redhat.com> On 03.03.2014 15:03, Jan Cholasta wrote: >>> This link definitely should be somewhere in design docs. >>> >>>> BTW, there are some additional attributes defined in >>>> /usr/include/nss3/pkcs11n.h besides these mentioned in the link above: >>> And this too... Feel free to upload the file to wiki if you didn't find >>> any on-line repo suitable for direct linking from design docs. >>> >>>> CKA_TRUST_IPSEC_END_SYSTEM >>>> CKA_TRUST_IPSEC_TUNNEL >>>> CKA_TRUST_IPSEC_USER >>>> CKA_TRUST_TIME_STAMPING >>>> CKA_TRUST_STEP_UP_APPROVED >>>> >>>> Can you please add them as well? >>>> >>>>> >>>>> 2] Certificate representation >>>>> In pkcs11 there is a certificate category (user, authority, ..) and >>>>> certificate value. An alternate way to represent this would be to use >>>>> the schema defined in rfc4523 and map >>>>> (user, value) --> (objectclass: pkiUser, usercertificate) and >>>>> (authority, value) --> (objectclass: pkiCA, cAcertificate) >>>>> I kept the attributes pkcs11certificateCategory and >>>>> pkcs11certificateValue and let the applications decide which format >>>>> will >>>>> be used. >>>> >>>> Applications talking to PKCS#11 do not need to be concerned with >>>> this and >>>> applications talking to LDAP will be only us. >>> I would like to emphasis Rob's idea that this schema is IPA-specific for >>> now but we should assume that other PKCS#11<->LDAP implementations can >>> exist. >> >> And also NSS specific, given the storage of NSS trust. > > I think we can make that conditional, i.e. by using an environment > variable or the reserved argument in C_Initialize (like NSS does). > > If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust > objects from the module? No. This is the spec for storing trust policy in PKCS#11 that we've been working on: http://p11-glue.freedesktop.org/doc/storing-trust-policy/ It's a far more extensible and future proof model. The p11-kit-trust module stores/loads these sorts of objects, and additionally also generates NSS trust objects on the fly so that NSS can consume the information. It doesn't do that last bit for third party sources, but it could given code :) Stef From pviktori at redhat.com Mon Mar 3 15:04:28 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 03 Mar 2014 16:04:28 +0100 Subject: [Freeipa-devel] [PATCH] 0486 permission-mod: Remove attributelevelrights before reverting entry Message-ID: <531499FC.4040303@redhat.com> Hello, This fixes issue #4212 which Petr? found in his Web UI work. [#4212] https://fedorahosted.org/freeipa/ticket/4212 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0486-permission-mod-Remove-attributelevelrights-before-re.patch Type: text/x-patch Size: 3246 bytes Desc: not available URL: From pviktori at redhat.com Mon Mar 3 15:10:12 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 03 Mar 2014 16:10:12 +0100 Subject: [Freeipa-devel] [PATCHES] 0473-0477 Managed permission updater, part 1 In-Reply-To: <53109370.7010905@redhat.com> References: <530DB78A.4040003@redhat.com> <53108B41.50700@redhat.com> <53109370.7010905@redhat.com> Message-ID: <53149B54.2050308@redhat.com> On 02/28/2014 02:47 PM, Petr Viktorin wrote: > On 02/28/2014 02:12 PM, Martin Kosek wrote: >> On 02/26/2014 10:44 AM, Petr Viktorin wrote: >>> Hello, >>> Here are a few fixes/improvements, and the first part of a managed >>> permission >>> updater. >>> >>> The patches should go in this order but don't need to be ACKed/pushed >>> all at once. >>> >>> >>> Design: >>> http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater >>> >>> Part of the work for: https://fedorahosted.org/freeipa/ticket/3566 >>> >>> >>> This part is a "preview" of sorts, to get the basic mechanism and the >>> metadata >>> format reviewed before I add all of the default read permissions. >>> It implements the first section of "Default Permission Updater" in >>> the design; >>> "Replacing legacy default permissions" and "Removing the global >>> anonymous read >>> ACI" is left for later. >>> Metadata is added for the netgroup plugin* for starters, so >>> installing this >>> will give you two shiny new read permissions: >>> >>> $ ipa permission-find ipa: --all >>> --------------------- >>> 2 permissions matched >>> --------------------- >>> dn: cn=ipa:Read Netgroup Membership,cn=permissions,cn=pbac,$SUFFIX >>> Permission name: ipa:Read Netgroup Membership >>> Permissions: read, compare, search >>> Effective attributes: externalhost, member, memberof, memberuser >>> Default attributes: member, memberof, memberuser, externalhost >>> Bind rule type: all >>> Subtree: cn=ng,cn=alt,$SUFFIX >>> Target filter: (objectclass=ipanisnetgroup) >>> Type: netgroup >>> ipapermissiontype: V2, MANAGED, SYSTEM >>> objectclass: ipapermission, groupofnames, top, ipapermissionv2 >>> >>> dn: cn=ipa:Read Netgroups,cn=permissions,cn=pbac,$SUFFIX >>> Permission name: ipa:Read Netgroups >>> Permissions: read, compare, search >>> Effective attributes: cn, description, hostcategory, ipaenabledflag, >>> ipauniqueid, nisdomainname, usercategory >>> Default attributes: cn, usercategory, hostcategory, ipauniqueid, >>> ipaenabledflag, nisdomainname, description >>> Bind rule type: all >>> Subtree: cn=ng,cn=alt,$SUFFIX >>> Target filter: (objectclass=ipanisnetgroup) >>> Type: netgroup >>> ipapermissiontype: V2, MANAGED, SYSTEM >>> objectclass: ipapermission, groupofnames, top, ipapermissionv2 >>> ---------------------------- >>> Number of entries returned 2 >>> ---------------------------- >>> >>> with corresponding ACIs at cn=ng,cn=alt,$SUFFIX: >>> >>> (targetattr = "externalhost || member || memberof || >>> memberuser")(targetfilter >>> = "(objectclass=ipanisnetgroup)")(version 3.0;acl >>> "permission:ipa:Read Netgroup >>> Membership";allow (read,compare,search) userdn = "ldap:///all";) >>> (targetattr = "cn || description || hostcategory || ipaenabledflag || >>> ipauniqueid || nisdomainname || usercategory")(targetfilter = >>> "(objectclass=ipanisnetgroup)")(version 3.0;acl "permission:ipa:Read >>> Netgroups";allow (read,compare,search) userdn = "ldap:///all";) >>> >>> >>> >>> Patches: >>> >>> 0473: Enables refactoring that will make it more clear (to humans and >>> machines) >>> what plugins code depends on. >>> https://fedorahosted.org/freeipa/ticket/4185 >>> >>> 0474: Fix handling of the search term for legacy permissions >>> My code that's in master now handles the search term incorrectly. >>> This does a >>> better job. >>> >>> 0475: Fix tests that relied on some assumptions I'll be breaking >>> >>> 0476: Allow modifying (but not creating) permissions with ":" in the >>> name >>> >>> 0477: Permission updater & sample metadata >>> >> >> 1) 476: Typo in test name: >> >> + desc='Search fo rnonexisting permission with ":" in the >> name', > > Will fix. > >> 2) 477: do we want to log anything when permission is up to date? >> >> + try: >> + ldap.update_entry(entry) >> + except errors.EmptyModlist: >> + return > > I don't think that's needed, after all that's the expected behavior in > all but the first upgrade. > But I'll be happy to add it if you think it would be better. > >> 3) I am not sure if this was initiated by this patch, but when I >> checked access >> log for a "permission-find --name ipa" operation, it produced over 170 >> LDAP >> operations, most of them asking for the same information many times. See >> attached access log excerpt. > > It's unrelated to this patch. I've started optimizing permission-find > with many legacy permissions, expect a patch soon. > >> 4) I have been quite resilient to the prefixes for the permissions, >> but it >> seems it is the easier possible approach to fix conflicts with user >> permissions >> without having to check that later for every upgrade or doing more >> complex >> stuff like multiple RDNs or different container for system and user >> permissions. >> >> I am now just thinking about the prefixing. Now you use this name: >> >> ipa:Read Netgroups >> >> Would it be "nicer" to use: >> >> IPA:Read Netgroups >> or >> IPA: Read Netgroups >> or even >> [IPA] Read Netgroups >> ? :-) > > Bikeshedding time! > Everyone on the list, please chime in! Bikeshedding results from today's meeting: "ipa: " pviktori++ "System: " mkosek++ simo+ ab++ "Builtin: " simo++ pvo+ "Default: " The winner is "System: ", so I'll go and change to that. > I don't really have a preference. > > >> 5) Are we sure we want to make our code Python 2.7 dependent? >> >> + 'ipapermright': {'read', 'search', 'compare'}, >> >> I did not test if we do not require some python 2.7 feature elsewhere >> already, >> but this construct raised a warning for me. > > That ship has sailed already. > Recently there was commit a8ba5e0 which explicitly mentions set literals > (and which, coincidentally, you acked...), but I'm pretty sure IPA > needed Python 2.7+ before that. > After all we don't test on Python 2.6 and don't support any OS with > Python 2.6. > >> Otherwise the patches seemed to work fine. I also tried to play with >> the global >> ACI blacklist blacklisting and it worked as well, when I for example >> added >> userpassword to netgroup managed_permissions. > -- Petr? From npmccallum at redhat.com Mon Mar 3 16:13:21 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 03 Mar 2014 11:13:21 -0500 Subject: [Freeipa-devel] [PATCH 0045] Fix token secret length RFC compliance Message-ID: <1393863201.1963.1.camel@localhost.localdomain> RFC 4226 states the following in section 4: R6 - The algorithm MUST use a strong shared secret. The length of the shared secret MUST be at least 128 bits. This document RECOMMENDs a shared secret length of 160 bits. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0045-Fix-token-secret-length-RFC-compliance.patch Type: text/x-patch Size: 986 bytes Desc: not available URL: From jcholast at redhat.com Mon Mar 3 16:19:48 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 03 Mar 2014 17:19:48 +0100 Subject: [Freeipa-devel] [PATCH 0045] Fix token secret length RFC compliance In-Reply-To: <1393863201.1963.1.camel@localhost.localdomain> References: <1393863201.1963.1.camel@localhost.localdomain> Message-ID: <5314ABA4.2020200@redhat.com> On 3.3.2014 17:13, Nathaniel McCallum wrote: > RFC 4226 states the following in section 4: > R6 - The algorithm MUST use a strong shared secret. The length of > the shared secret MUST be at least 128 bits. This document > RECOMMENDs a shared secret length of 160 bits. ACK. -- Jan Cholasta From tbabej at redhat.com Mon Mar 3 19:16:46 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 03 Mar 2014 20:16:46 +0100 Subject: [Freeipa-devel] [PATCH 0113] ipa-client: Set NIS domain name in the installer In-Reply-To: <5284B9E2.3000007@redhat.com> References: <5243F02D.9020005@redhat.com> <5284B9E2.3000007@redhat.com> Message-ID: <5314D51E.9040402@redhat.com> The updated patch addresses all the mentioned issues. Also enables systemd's specific domainname service instead of relying ypbind being present on the system. Please note that nisdomainname is not configured on boot time at the moment. The following bug is the cause: https://bugzilla.redhat.com/show_bug.cgi?id=1071951 On 11/14/2013 12:54 PM, Ana Krivokapic wrote: > On 09/26/2013 10:28 AM, Tomas Babej wrote: >> + if options.no_nisdomain and not options.nisdomain: > This should be `if options.no_nisdomain and options.nisdomain:`. >> + parser.error("--no-nisdomain cannot be used together with --nisdomain") > > Shouldn't we also revert the nisdomain authconfig setting on client uninstall? > -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0113-2-ipa-client-Set-NIS-domain-name-in-the-installer.patch Type: text/x-patch Size: 7323 bytes Desc: not available URL: From tbabej at redhat.com Mon Mar 3 19:24:41 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 03 Mar 2014 20:24:41 +0100 Subject: [Freeipa-devel] [PATCH 0157] ipa-client-install: Configure sudo to use SSSD as data source Message-ID: <5314D6F9.6010008@redhat.com> Hi, Makes ipa-client-install configure SSSD as the data provider for the sudo service by default. This behaviour can be disabled by using --no-sudo flag. https://fedorahosted.org/freeipa/ticket/3358 -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0157-ipa-client-install-Configure-sudo-to-use-SSSD-as-dat.patch Type: text/x-patch Size: 3916 bytes Desc: not available URL: From redhatrises at gmail.com Tue Mar 4 00:20:26 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Mon, 3 Mar 2014 17:20:26 -0700 Subject: [Freeipa-devel] [PATCH 0008] Typo in warning message where IPA realm and domain name differ Message-ID: Hi all, Quick one line change to fix. https://fedorahosted.org/freeipa/ticket/4211 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0008-Typo-in-warning-message-where-IPA-realm-and-domain-n.patch Type: application/octet-stream Size: 1185 bytes Desc: not available URL: From dpal at redhat.com Tue Mar 4 00:41:11 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 03 Mar 2014 19:41:11 -0500 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <1393519340.3562.13.camel@localhost.localdomain> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> <530F3106.7090505@redhat.com> <1393516297.3562.8.camel@localhost.localdomain> <530F6804.3090507@redhat.com> <1393519340.3562.13.camel@localhost.localdomain> Message-ID: <53152127.8000802@redhat.com> On 02/27/2014 11:42 AM, Nathaniel McCallum wrote: > On Thu, 2014-02-27 at 17:29 +0100, Petr Vobornik wrote: >> On 27.2.2014 16:51, Nathaniel McCallum wrote: >>> On Thu, 2014-02-27 at 13:35 +0100, Petr Vobornik wrote: >>>> On 21.2.2014 15:24, Petr Vobornik wrote: >>>>> On 10.2.2014 14:12, Petr Vobornik wrote: >>>>>> On 13.1.2014 17:09, Petr Vobornik wrote: >>>>>>> Hi, >>>>>>> >>>>>>> these patches implements the OTP Web UI. >>>>>>> >>>>>>> Last 5 patches is the OTP UI. >>>>>>> >>>>>>> First 6 patches is a little refactoring/bug fixes needed for them. >>>>>>> General password dialog is introduced to avoid another implementation. >>>>>>> >>>>>>> Self-service UI is implemented to be very simple. Atm user can choose >>>>>>> only token name. Admin interface allows to enter all values. >>>>>>> >>>>>>> It's based on the RCUE work -> we need to push RCUE first. Thanks >>>>>>> Nathaniel for review of the last font package. It will speed things up. >>>>>>> >>>>>>> Know bugs: >>>>>>> - there is clash in id's of checkboxes preventing editation of >>>>>>> subsequently displayed ones with the same name. Will be fixed in >>>>>>> separate patch. >>>>>>> - bugs caused by bugs in API (adding/removal of own tokens in >>>>>>> self-service, inability to enter key on token creation - >>>>>>> https://fedorahosted.org/freeipa/ticket/4099) >>>>>>> - datetime format (widget+validator) will be implemented in separate >>>>>>> patch >>>>>>> - no support of not reviewed CLI patches (HOTP..) >>>>>>> >>>>>>> Cgit: >>>>>>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3369 >>>>>>> >>>>>> patch 540-1 has been updated >>>>>> - QR code is centered >>>>>> - QR code correction level was lowered from H to M >>>>>> >>>>>> All other current patches from sub-threads are attached as well (it was >>>>>> getting hard to keep track of them). >>>>>> >>>>> Attaching new version of patch 537: 537-4 >>>>> >>>>> It: >>>>> * adds HOTP support - new switch in adder dialog and ipatokenhotpcounter >>>>> field in details facet >>>>> * removes 'default' radio button in adder dialog in ipatokenotpalgorithm >>>>> and ipatokenotpdigits field >>>>> >>>>> >>>>> Btw I've encountered an issue on Web UI login when: >>>>> - user is created >>>>> - token is created for him >>>>> - admin resets user's password and changes auth type to 'otp' >>>>> - user tries to login with psw+otp >>>>> >>>>> The initial login-password call is successful but subsequent change >>>>> password fails - it uses the old psw+otp. >>>>> >>>>> I'll address this issue in https://fedorahosted.org/freeipa/ticket/3903 >>>>> which is almost implemented. >>>>> >>>>> >>>>> I also plan to hide fields without any value in otp token details page >>>>> in self-service mode. This will be done after #3903 because some >>>>> prerequisites for #3903 add useful code for that task. >>>>> >>>> New version of 537 attached: 537-5 >>>> >>>> It removes token type switch from selfservice page. Therefore default >>>> token type (totp) will be always created. >>>> >>>> Originated from: >>>> http://www.redhat.com/archives/freeipa-devel/2014-February/msg00532.html >>> I'm not sure I understand the rationale for this (after having read the >>> other email thread). But I agree we should discuss which options should >>> be available on the self-service page. >>> >>> Just to recap the situation: >>> 1. Only token name / description are provided in the self-service UI >>> 2. All options are provided on the CLI >>> >>> I think the main question is: who should get to choose the primary token >>> type in FreeIPA? There are three possibilities: >>> 1. FreeIPA developers >>> 2. Admins >>> 3. Users >>> >>> The case for #1 is that we can't guarantee timely replication of the >>> counter attribute. On this basis, we choose TOTP as default because of >>> structural limitations. This is currently the default. >>> >>> I don't see much use for #3. But I can see an argument for #2. >>> >>> Personally, I lean toward #1. Thoughts? >>> >>> Nathaniel >>> >> Sorry, there is no real reason to not have HOTP there, and therefore >> 537-5 is wrong and 537-4 is OK. >> >> Rationale of the mistake: >> * self-service page has to be simple so it doesn't allow to add hw tokens >> * My thoughts were fixed to the idea that HOTP has to be hw token - >> maybe the H confused me. > On a similar note, I've been toying with the idea of a > ipatokenRestricted attribute. The idea is that restricted tokens cannot > be created or deleted by users and, when the user is deleted, the token > is orphaned in stead of deleted. During XML import, the restricted > attribute would be set by default. > > This seems to me the correct behavior. It should be possible for the hardware tokens to exist in the system as unassigned. This is why we need an type attribute that indicates this. Tokens that are HW can't be edited, they can be just assigned, unassigned, synched or deleted. > > Nathaniel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Tue Mar 4 00:48:13 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 03 Mar 2014 19:48:13 -0500 Subject: [Freeipa-devel] [PATCH 0008] Typo in warning message where IPA realm and domain name differ In-Reply-To: References: Message-ID: <1393894093.22047.60.camel@willson.li.ssimo.org> On Mon, 2014-03-03 at 17:20 -0700, Gabe Alford wrote: > Hi all, > > Quick one line change to fix. > > https://fedorahosted.org/freeipa/ticket/4211 ACK Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Mar 4 01:12:26 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 03 Mar 2014 20:12:26 -0500 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <5312A07A.3060706@redhat.com> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> <53105B27.4070003@redhat.com> <1393597539.3562.21.camel@localhost.localdomain> <20140228144351.GC16644@redhat.com> <1393599745.3562.23.camel@localhost.localdomain> <20140228151536.GD16644@redhat.com> <5310A983.50409@redhat.com> <5312A07A.3060706@redhat.com> Message-ID: <5315287A.8050201@redhat.com> On 03/01/2014 10:07 PM, Adam Young wrote: > On 02/28/2014 10:21 AM, Petr Viktorin wrote: >> On 02/28/2014 04:15 PM, Alexander Bokovoy wrote: >>> On Fri, 28 Feb 2014, Nathaniel McCallum wrote: >>>> On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: >>>>> On Fri, 28 Feb 2014, Nathaniel McCallum wrote: >>>>> >On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: >>>>> >> On 28.2.2014 04:02, Rob Crittenden wrote: >>>>> >> > Alexander Bokovoy wrote: >>>>> >> >> On Thu, 27 Feb 2014, Nathaniel McCallum wrote: >>>>> >> >>> So the recent discussion on importing tokens led me to write a >>>>> script to >>>>> >> >>> parse RFC 6030 xml files into IPA token data. This all works >>>>> well. But >>>>> >> >>> now I need to integrate it into the IPA framework. >>>>> >> >>> >>>>> >> >>> This command will parse one or more xml files, creating a set >>>>> of tokens >>>>> >> >>> to be added. Given that we already have otptoken-add on the >>>>> server-side, >>>>> >> >>> it seems to me that all work needs to be done on the >>>>> client-side. How do >>>>> >> >>> I create a new client-side command that calls existing >>>>> server-side API? >>>>> >> >> subclass from frontend.Local, override run() or forward() >>>>> method and >>>>> >> >> perform batch >>>>> >> >> operation of otptoken_add from there. >>>>> >> >> >>>>> >> >> See cli.help, for example. >>>>> >> > >>>>> >> > If you do an override, do forward() for cli-specific work. >>>>> >> > >>>>> >> > But you should do as little as possible for reasons you already >>>>> stated: >>>>> >> > the UI. Anything you do in forward Petr will need to implement >>>>> in the UI. >>>>> >> > >>>>> >> > Unfortunately we don't yet have a nice way to handle files. >>>>> We have >>>>> >> > tickets open at https://fedorahosted.org/freeipa/ticket/1225 and >>>>> >> > https://fedorahosted.org/freeipa/ticket/2933 >>>>> >> > >>>>> >> > If this file is something that would be pasted into a big text >>>>> field >>>>> >> > then you can probably handle it in a similarly clumsy way that >>>>> we do >>>>> >> > CSRs in the cert plugin. >>>>> >> > >>>>> >> > rob >>>>> >> >>>>> >> +1 for parsing it on server. Otherwise every client, not just CLI >>>>> or Web >>>>> >> UI, would have to reimplement the same logic - having it on server >>>>> will >>>>> >> support better integration with third party products. >>>>> >> >>>>> >> Parsing on client would be understandable if there was some middle >>>>> step >>>>> >> which would require some action from user, i.e, pick only some >>>>> tokens to >>>>> >> import. >>>>> > >>>>> >If we parse on the server side, how do we handle the long-running >>>>> >operation? Think of the case of importing hundreds or thousands of >>>>> >tokens... >>>>> Why then to do it as a IPA CLI command at all? >>>>> This is an administrative task which can be done with a separate >>>>> ipa-otp-import command, designated to run on IPA masters. >>>> >>>> Agreed. >>>> >>>> 1. Is there a framework for this? Or should it just be an independent >>>> script? >>> We don't really have a framework for administrative tools. You may >>> start >>> with install/tools/ipa-adtrust-install, it is main part is relatively >>> independent of the task (which is in >>> ipaserver/install/adtrustinstance.py) >>> >> >> The framework is there, new tools use it, and there's a ticket to >> convert old ones: https://fedorahosted.org/freeipa/ticket/2652 (it's >> low priority in Future Releases, so not much progress is there...) >> Also see http://www.freeipa.org/page/V3/Logging_and_output >> >> > > > The RESTful approach would be: > > 1. Upload a file to a specific URL (not JSON RPC) > 2. Receive back a 202 Accepted HTTP Request, to include an URL to > poll for status > > Not certain the right response from the URL in step 2 would be, but I > am assuming it would be 200 with the body of the message stating: > processing or completed. > > It would be really nice if the Batch command could be handled this way > as well. The response back could be the partial responses until > processing is complete. > > It might also be nice to supply an email address for notification of > completed processing instead of polling, if it is going to be a really > long running task. > > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Yes I think that: 1) We should not limit it to server side operation only 2) Upload the whole file and then process it. 3) We should already have code to upload files, we did it for entitlements and were supposed to use for certs. 4) Make sure we have a generic upload mechanism that reads a chunk of a configurable size and asks for more (pagination by 65K might be a good default). Regarding token files specifically: they can be big but not super huge. 10-20K tokens makes sense but probably not more. More than that would be a real corner case becuase it is hard to deploy that amount of tokens at the same time. It can take months and you do not want token file to contain many tokens that would sit on the shelf. Tokens expire so it is inefficient to buy huge chunks and let them sit unused. UI you allow uploading file too and then would process it locally. The processing of the file should generate a log or report. It would be nice to get indication from the server that it is still working so may be upload protocol should be something like: client: Initialize the transfer server: ready client: here is the chunk of data server: ack ... client: here is the last chunk of data server: ack, (forks the file processing method that updates shared status data) come back in x seconds client: how are things? server: working, here is current status, come back in x seconds ... client: how are things? server: done, here is current status, have errors in a file client: start download server: here is the chunk ... I think we can short socket the command for now to fail if it is not local on the server and then build the upload mechanism but separate command as proposed in this thread would lock us in a local approach forever. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Tue Mar 4 09:13:25 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 4 Mar 2014 11:13:25 +0200 Subject: [Freeipa-devel] [PATCH] 0145: trust fix filtering of users from subdomains Message-ID: <20140304091325.GF16644@redhat.com> Attached patch should fix https://fedorahosted.org/freeipa/ticket/4207 where we didn't filter out users from disabled subdomains aggressively enough. The code that did not filter exists only in git, not in released versions yet. Attached also a screenshot that explains the behavior. The code was tested by me, Sumit, and Scott, and reviewed over last few days by Simo and Sumit. -- / Alexander Bokovoy -------------- next part -------------- >From 9eafc57e54311d203254d84e3dab32261f1c9aba Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 28 Feb 2014 22:03:29 +0200 Subject: [PATCH 9/9] fix filtering of subdomain-based trust users https://fedorahosted.org/freeipa/ticket/4207 --- daemons/ipa-kdb/ipa_kdb_mspac.c | 41 ++++++++++++++++++++++++++++++++--------- 1 file changed, 32 insertions(+), 9 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 771b40b..cb1b68e 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -806,6 +806,12 @@ static krb5_error_code ipadb_get_pac(krb5_context kcontext, krb5_error_code kerr; enum ndr_err_code ndr_err; + /* When no client entry is there, we cannot generate MS-PAC */ + if (!client) { + *pac = NULL; + return 0; + } + ipactx = ipadb_get_context(kcontext); if (!ipactx) { return KRB5_KDB_DBNOTINITED; @@ -1538,6 +1544,12 @@ static krb5_error_code ipadb_add_transited_service(krb5_context context, uint32_t i; char *tmpstr; + /* When proxy is NULL, authdata flag on the service principal was cleared + * by an admin. We don't generate MS-PAC in this case */ + if (proxy == NULL) { + return 0; + } + tmpctx = talloc_new(NULL); if (!tmpctx) { kerr = ENOMEM; @@ -1735,6 +1747,12 @@ static krb5_error_code ipadb_verify_pac(krb5_context context, } if (flags & KRB5_KDB_FLAG_CONSTRAINED_DELEGATION) { + if (proxy == NULL) { + *pac = NULL; + kerr = 0; + goto done; + } + kerr = ipadb_add_transited_service(context, proxy, server, old_pac, new_pac); if (kerr) { @@ -1990,20 +2008,27 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, krb5_db_entry *client_entry = NULL; - /* When client is NULL, authdata flag on the service principal was cleared - * by an admin. We don't generate MS-PAC in this case */ - if (client == NULL) { - *signed_auth_data = NULL; - return 0; - } + is_as_req = ((flags & KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY) != 0); /* When using s4u2proxy client_princ actually refers to the proxied user * while client->princ to the proxy service asking for the TGS on behalf * of the proxied user. So always use client_princ in preference */ if (client_princ != NULL) { ks_client_princ = client_princ; - kerr = ipadb_get_principal(context, client_princ, flags, &client_entry); + if (!is_as_req) { + kerr = ipadb_get_principal(context, client_princ, flags, &client_entry); + /* If we didn't find client_princ in our database, it might be: + * - a principal from another realm, handle it down in ipadb_get/verify_pac() + */ + if (!kerr) { + client_entry = NULL; + } + } } else { + if (client == NULL) { + *signed_auth_data = NULL; + return 0; + } ks_client_princ = client->princ; } @@ -2018,8 +2043,6 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, "currently not supported."); } - is_as_req = ((flags & KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY) != 0); - if (is_as_req && with_pac && (flags & KRB5_KDB_FLAG_INCLUDE_PAC)) { /* Be aggressive here: special case for discovering range type * immediately after establishing the trust by IPA framework */ -- 1.8.3.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: subdomains-disable-kdb-1.png Type: image/png Size: 32156 bytes Desc: not available URL: From mkosek at redhat.com Tue Mar 4 09:24:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 04 Mar 2014 10:24:42 +0100 Subject: [Freeipa-devel] [PATCH] 0145: trust fix filtering of users from subdomains In-Reply-To: <20140304091325.GF16644@redhat.com> References: <20140304091325.GF16644@redhat.com> Message-ID: <53159BDA.6060007@redhat.com> On 03/04/2014 10:13 AM, Alexander Bokovoy wrote: > Attached patch should fix https://fedorahosted.org/freeipa/ticket/4207 > where we didn't filter out users from disabled subdomains aggressively > enough. > > The code that did not filter exists only in git, not in released > versions yet. > > Attached also a screenshot that explains the behavior. > > The code was tested by me, Sumit, and Scott, and reviewed over last few > days by Simo and Sumit. Thanks Alexander! Do I understand it right that it has an ACK from Simo and Sumit? If yes, I will push the patch to master and ipa-3-3 (when fedorahosted git starts working again). Martin From abokovoy at redhat.com Tue Mar 4 09:33:21 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 4 Mar 2014 11:33:21 +0200 Subject: [Freeipa-devel] [PATCH] 0145: trust fix filtering of users from subdomains In-Reply-To: <53159BDA.6060007@redhat.com> References: <20140304091325.GF16644@redhat.com> <53159BDA.6060007@redhat.com> Message-ID: <20140304093321.GG16644@redhat.com> On Tue, 04 Mar 2014, Martin Kosek wrote: >On 03/04/2014 10:13 AM, Alexander Bokovoy wrote: >> Attached patch should fix https://fedorahosted.org/freeipa/ticket/4207 >> where we didn't filter out users from disabled subdomains aggressively >> enough. >> >> The code that did not filter exists only in git, not in released >> versions yet. >> >> Attached also a screenshot that explains the behavior. >> >> The code was tested by me, Sumit, and Scott, and reviewed over last few >> days by Simo and Sumit. > >Thanks Alexander! Do I understand it right that it has an ACK from Simo and >Sumit? If yes, I will push the patch to master and ipa-3-3 (when fedorahosted >git starts working again). I'd like to get ACKs here, Simo didn't see the latest version yesterday. -- / Alexander Bokovoy From pviktori at redhat.com Tue Mar 4 10:58:11 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Mar 2014 11:58:11 +0100 Subject: [Freeipa-devel] [PATCHES] 0337-0343 YAML test configuration In-Reply-To: <53147882.9090203@redhat.com> References: <52A9A0A9.9040706@redhat.com> <52CA81B1.4040602@redhat.com> <53147882.9090203@redhat.com> Message-ID: <5315B1C3.20108@redhat.com> On 03/03/2014 01:41 PM, Tomas Babej wrote: > Finally got to this patchset! > > PATCH 337: ACK > PATCH 338: ACK > > This prohibits us to use extra roles that end in digits. Can you put a > note explaining that in > > http://www.freeipa.org/page/V3/Integration_testing#Host_configuration Updated. > Also, this wiki page points out to environment variables so that it > seems it is the preferred method of configuration. We should mention > more user friendly YAML here first. Let's do that when the patches are pushed. #3938 should stay open until it's done. > PATCH 339: ACK > PATCH 340: ACK > PATCH 341: > > The have_master variable seems redundant in from_dict method (it's only > a local definition and not referenced anywhere else): > > + def from_dict(cls, dct, config): > + from ipatests.test_integration.host import BaseHost > + > + domain_type = dct.pop('type') > + assert domain_type in ('IPA', 'AD') > + domain_name = dct.pop('name') > + self = cls(config, domain_name, domain_type) > + > + have_master = False > + for host_dict in dct.pop('hosts'): > + host = BaseHost.from_dict(host_dict, self) > + self.hosts.append(host) > + if host.role == 'master': > + have_master = True > + > + check_config_dict_empty(dct, 'domain %s' % domain_name) > + > + return self Right you are. Fixed. > PATCH 342: ACK > PATCH 343: ACK > > PATCH 348: ACK > PATCH 349: ACK > > -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0337.3-test_integration.config-Fix-crash-in-to_env-when-no-.patch Type: text/x-patch Size: 2357 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0338.3-test_integration.config-Do-not-save-the-input-enviro.patch Type: text/x-patch Size: 5588 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0339.3-test_integration.config-Use-a-more-declarative-appro.patch Type: text/x-patch Size: 7368 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0340.3-test_integration.config-Do-not-store-the-index-in-Do.patch Type: text/x-patch Size: 8601 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0341.3-test_integration.config-Load-store-from-to-dicts.patch Type: text/x-patch Size: 6198 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0342.3-test_integration.config-Add-environment-variables-fo.patch Type: text/x-patch Size: 1953 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0343.3-ipa-test-config-Add-json-and-yaml-output-options.patch Type: text/x-patch Size: 3905 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0348.3-test_integration.config-Convert-some-text-values-to-.patch Type: text/x-patch Size: 3098 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0349.3-Add-tests-for-integration-test-configuration.patch Type: text/x-patch Size: 17460 bytes Desc: not available URL: From sbose at redhat.com Tue Mar 4 11:10:49 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 4 Mar 2014 12:10:49 +0100 Subject: [Freeipa-devel] [PATCH] 0145: trust fix filtering of users from subdomains In-Reply-To: <20140304091325.GF16644@redhat.com> References: <20140304091325.GF16644@redhat.com> Message-ID: <20140304111049.GT2710@localhost.localdomain> On Tue, Mar 04, 2014 at 11:13:25AM +0200, Alexander Bokovoy wrote: > Attached patch should fix https://fedorahosted.org/freeipa/ticket/4207 > where we didn't filter out users from disabled subdomains aggressively > enough. > > The code that did not filter exists only in git, not in released > versions yet. > > Attached also a screenshot that explains the behavior. > > The code was tested by me, Sumit, and Scott, and reviewed over last few > days by Simo and Sumit. This patch worked well in my test, AS and TGS requests for IPA user and IPA services went well, as TGS request from trusted users for IPA services. According to the krb5kdc logs delegation HTTP->ldap was ok as well. I was not able to test S4U2Self and S4U2Proxy from the command line with kvno, but I think this might be expected since we currently do not support enterprise principals in IPA. I still have one comment, see inline. bye, Sumit > > -- > / Alexander Bokovoy > >From 9eafc57e54311d203254d84e3dab32261f1c9aba Mon Sep 17 00:00:00 2001 > From: Alexander Bokovoy > Date: Fri, 28 Feb 2014 22:03:29 +0200 > Subject: [PATCH 9/9] fix filtering of subdomain-based trust users > > https://fedorahosted.org/freeipa/ticket/4207 > --- > daemons/ipa-kdb/ipa_kdb_mspac.c | 41 ++++++++++++++++++++++++++++++++--------- > 1 file changed, 32 insertions(+), 9 deletions(-) > > diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c > index 771b40b..cb1b68e 100644 > --- a/daemons/ipa-kdb/ipa_kdb_mspac.c > +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c > @@ -806,6 +806,12 @@ static krb5_error_code ipadb_get_pac(krb5_context kcontext, > krb5_error_code kerr; > enum ndr_err_code ndr_err; > > + /* When no client entry is there, we cannot generate MS-PAC */ > + if (!client) { > + *pac = NULL; > + return 0; > + } > + > ipactx = ipadb_get_context(kcontext); > if (!ipactx) { > return KRB5_KDB_DBNOTINITED; > @@ -1538,6 +1544,12 @@ static krb5_error_code ipadb_add_transited_service(krb5_context context, > uint32_t i; > char *tmpstr; > > + /* When proxy is NULL, authdata flag on the service principal was cleared > + * by an admin. We don't generate MS-PAC in this case */ > + if (proxy == NULL) { > + return 0; > + } > + > tmpctx = talloc_new(NULL); > if (!tmpctx) { > kerr = ENOMEM; > @@ -1735,6 +1747,12 @@ static krb5_error_code ipadb_verify_pac(krb5_context context, > } > > if (flags & KRB5_KDB_FLAG_CONSTRAINED_DELEGATION) { > + if (proxy == NULL) { > + *pac = NULL; > + kerr = 0; > + goto done; > + } > + > kerr = ipadb_add_transited_service(context, proxy, server, > old_pac, new_pac); > if (kerr) { > @@ -1990,20 +2008,27 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, > krb5_db_entry *client_entry = NULL; > > > - /* When client is NULL, authdata flag on the service principal was cleared > - * by an admin. We don't generate MS-PAC in this case */ > - if (client == NULL) { > - *signed_auth_data = NULL; > - return 0; > - } > + is_as_req = ((flags & KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY) != 0); > > /* When using s4u2proxy client_princ actually refers to the proxied user > * while client->princ to the proxy service asking for the TGS on behalf > * of the proxied user. So always use client_princ in preference */ > if (client_princ != NULL) { > ks_client_princ = client_princ; > - kerr = ipadb_get_principal(context, client_princ, flags, &client_entry); > + if (!is_as_req) { > + kerr = ipadb_get_principal(context, client_princ, flags, &client_entry); > + /* If we didn't find client_princ in our database, it might be: > + * - a principal from another realm, handle it down in ipadb_get/verify_pac() > + */ > + if (!kerr) { > + client_entry = NULL; > + } > + } If I understand it correctly client_princ should be always set so the else block below is rarely executed. For TGS request (!is_as_req) another LDAP search is done. I think this is done even in the case where an IPA client want's a ticket for an IPA service where the client pointer should already have the needed data. I see two identical requests in the LDAP logs in this case. If there is a easy way to skip the second search for this type of request I would vote to include it, otherwise I think it can be kept as it is and the performance improvement can be added later. > } else { > + if (client == NULL) { > + *signed_auth_data = NULL; > + return 0; > + } > ks_client_princ = client->princ; > } > > @@ -2018,8 +2043,6 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, > "currently not supported."); > } > > - is_as_req = ((flags & KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY) != 0); > - > if (is_as_req && with_pac && (flags & KRB5_KDB_FLAG_INCLUDE_PAC)) { > /* Be aggressive here: special case for discovering range type > * immediately after establishing the trust by IPA framework */ > -- > 1.8.3.1 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Tue Mar 4 12:48:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 04 Mar 2014 13:48:28 +0100 Subject: [Freeipa-devel] Daily build of the documentation? In-Reply-To: References: <1382714021.2282.5.camel@unused-4-145.brq.redhat.com> Message-ID: <5315CB9C.6070907@redhat.com> On 10/25/2013 05:22 PM, J?r?me Fenal wrote: > 2013/10/25 Martin Basti : >> On Fri, 2013-10-25 at 16:48 +0200, J?r?me Fenal wrote: >>> Hi all, >>> >>> Do we have a place where we publish a daily build of the documentation? >>> I'd like to send such a link for documentation review by Red Hatters. >>> >>> Regards, >>> >>> J. >> >> Hi, >> >> We don't have place for it yet. >> IMHO new doc should be published after major corrections. >> There is a lot of outdated sections which are unusable for freeIPA >> 3.3.x . > > I agree, but it could have the red background "Draft" stamp on it to > indicate its status. > > My goal would be to have it reviewed by Red Hat SAs. > > I guess I could also do something internally. > > Regards, > > J. > This is a bit late, but I have finally enabled daily build of our development documentation. The documentation itself is bulding in our upstream Jenkins CI, the result is then copied by a cron script to the OpenShift instance. Result is here: http://www.freeipa.org/docs/master/html-desktop/index.html I also added link to http://www.freeipa.org/page/Documentation I hope this helps to improve the situation with our doc. Feedback welcome, Martin From pspacek at redhat.com Tue Mar 4 12:51:01 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Mar 2014 13:51:01 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <1393426820.18299.163.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> Message-ID: <5315CC35.9080503@redhat.com> On 26.2.2014 16:00, Simo Sorce wrote: >>>> need to be protected as carefully as the private key. >>> > > >>> > >This is something I meant to discuss too, how do we protect them ? >>> > >Clearly we have ACIs but I am wondering if we want to encrypt them with >>> > >keys not immediately or easily available via LDAP ? >>> > > >>> > >It's kind of catastrofic if they get inadvertently exposed like if >>> > >someone does a ldapsearch as "Directory Manager", which is one of the >>> > >reasons why we encrypt kerberos key material before storing it into the >>> > >db. >> > >> >PKCS#8 allows encryption, I guess we can use that. There needs to be >> >some metadata on how to decrypt the blob though, so that the PKCS#11 >> >module can actually decrypt it when necessary. > Yep, and we also need to decide what master key is used and where it is > placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M at IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standard&tool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. -- Petr^2 Spacek From lslebodn at redhat.com Tue Mar 4 13:26:30 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Tue, 4 Mar 2014 14:26:30 +0100 Subject: [Freeipa-devel] Daily build of the documentation? In-Reply-To: <5315CB9C.6070907@redhat.com> References: <1382714021.2282.5.camel@unused-4-145.brq.redhat.com> <5315CB9C.6070907@redhat.com> Message-ID: <20140304132629.GA7399@mail.corp.redhat.com> On (04/03/14 13:48), Martin Kosek wrote: >On 10/25/2013 05:22 PM, J?r?me Fenal wrote: >> 2013/10/25 Martin Basti : >>> On Fri, 2013-10-25 at 16:48 +0200, J?r?me Fenal wrote: >>>> Hi all, >>>> >>>> Do we have a place where we publish a daily build of the documentation? >>>> I'd like to send such a link for documentation review by Red Hatters. >>>> >>>> Regards, >>>> >>>> J. >>> >>> Hi, >>> >>> We don't have place for it yet. >>> IMHO new doc should be published after major corrections. >>> There is a lot of outdated sections which are unusable for freeIPA >>> 3.3.x . >> >> I agree, but it could have the red background "Draft" stamp on it to >> indicate its status. >> >> My goal would be to have it reviewed by Red Hat SAs. >> >> I guess I could also do something internally. >> >> Regards, >> >> J. >> > >This is a bit late, but I have finally enabled daily build of our development >documentation. > >The documentation itself is bulding in our upstream Jenkins CI, the result is >then copied by a cron script to the OpenShift instance. > >Result is here: >http://www.freeipa.org/docs/master/html-desktop/index.html ^^^^^^^^^ html page says: FreeIPA 3.4 > >I also added link to >http://www.freeipa.org/page/Documentation And you added link to: FreeIPA 4.0.0 Guide (development build from git) Versions could be consistent. LS From mkosek at redhat.com Tue Mar 4 13:28:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 04 Mar 2014 14:28:16 +0100 Subject: [Freeipa-devel] Daily build of the documentation? In-Reply-To: <20140304132629.GA7399@mail.corp.redhat.com> References: <1382714021.2282.5.camel@unused-4-145.brq.redhat.com> <5315CB9C.6070907@redhat.com> <20140304132629.GA7399@mail.corp.redhat.com> Message-ID: <5315D4F0.9000704@redhat.com> On 03/04/2014 02:26 PM, Lukas Slebodnik wrote: > On (04/03/14 13:48), Martin Kosek wrote: >> On 10/25/2013 05:22 PM, J?r?me Fenal wrote: >>> 2013/10/25 Martin Basti : >>>> On Fri, 2013-10-25 at 16:48 +0200, J?r?me Fenal wrote: >>>>> Hi all, >>>>> >>>>> Do we have a place where we publish a daily build of the documentation? >>>>> I'd like to send such a link for documentation review by Red Hatters. >>>>> >>>>> Regards, >>>>> >>>>> J. >>>> >>>> Hi, >>>> >>>> We don't have place for it yet. >>>> IMHO new doc should be published after major corrections. >>>> There is a lot of outdated sections which are unusable for freeIPA >>>> 3.3.x . >>> >>> I agree, but it could have the red background "Draft" stamp on it to >>> indicate its status. >>> >>> My goal would be to have it reviewed by Red Hat SAs. >>> >>> I guess I could also do something internally. >>> >>> Regards, >>> >>> J. >>> >> >> This is a bit late, but I have finally enabled daily build of our development >> documentation. >> >> The documentation itself is bulding in our upstream Jenkins CI, the result is >> then copied by a cron script to the OpenShift instance. >> >> Result is here: >> http://www.freeipa.org/docs/master/html-desktop/index.html > ^^^^^^^^^ > html page says: FreeIPA 3.4 >> >> I also added link to >> http://www.freeipa.org/page/Documentation > And you added link to: FreeIPA 4.0.0 Guide (development build from git) > > Versions could be consistent. > > LS > Already fixed: https://git.fedorahosted.org/cgit/freeipa-docs.git/commit/?id=5dbc599cd33fc68761be66fb15b0a638e6129921 You just need to wait for the mighty rebuild scripts to do their job. Martin From pviktori at redhat.com Tue Mar 4 13:33:22 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 04 Mar 2014 14:33:22 +0100 Subject: [Freeipa-devel] Daily build of the documentation? In-Reply-To: <5315D4F0.9000704@redhat.com> References: <1382714021.2282.5.camel@unused-4-145.brq.redhat.com> <5315CB9C.6070907@redhat.com> <20140304132629.GA7399@mail.corp.redhat.com> <5315D4F0.9000704@redhat.com> Message-ID: <5315D622.2010402@redhat.com> On 03/04/2014 02:28 PM, Martin Kosek wrote: > On 03/04/2014 02:26 PM, Lukas Slebodnik wrote: >> On (04/03/14 13:48), Martin Kosek wrote: >>> On 10/25/2013 05:22 PM, J?r?me Fenal wrote: >>>> 2013/10/25 Martin Basti : >>>>> On Fri, 2013-10-25 at 16:48 +0200, J?r?me Fenal wrote: >>>>>> Hi all, >>>>>> >>>>>> Do we have a place where we publish a daily build of the documentation? >>>>>> I'd like to send such a link for documentation review by Red Hatters. >>>>>> >>>>>> Regards, >>>>>> >>>>>> J. >>>>> >>>>> Hi, >>>>> >>>>> We don't have place for it yet. >>>>> IMHO new doc should be published after major corrections. >>>>> There is a lot of outdated sections which are unusable for freeIPA >>>>> 3.3.x . >>>> >>>> I agree, but it could have the red background "Draft" stamp on it to >>>> indicate its status. >>>> >>>> My goal would be to have it reviewed by Red Hat SAs. >>>> >>>> I guess I could also do something internally. >>>> >>>> Regards, >>>> >>>> J. >>>> >>> >>> This is a bit late, but I have finally enabled daily build of our development >>> documentation. >>> >>> The documentation itself is bulding in our upstream Jenkins CI, the result is >>> then copied by a cron script to the OpenShift instance. >>> >>> Result is here: >>> http://www.freeipa.org/docs/master/html-desktop/index.html >> ^^^^^^^^^ >> html page says: FreeIPA 3.4 >>> >>> I also added link to >>> http://www.freeipa.org/page/Documentation >> And you added link to: FreeIPA 4.0.0 Guide (development build from git) >> >> Versions could be consistent. >> >> LS >> > > Already fixed: > > https://git.fedorahosted.org/cgit/freeipa-docs.git/commit/?id=5dbc599cd33fc68761be66fb15b0a638e6129921 > > You just need to wait for the mighty rebuild scripts to do their job. > > Martin We'll need to change that number whenever we release. I added a note to http://www.freeipa.org/page/Release#Wiki_pages_to_be_updated . -- Petr? From simo at redhat.com Tue Mar 4 15:26:51 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 04 Mar 2014 10:26:51 -0500 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <5315CC35.9080503@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> Message-ID: <1393946811.22047.75.camel@willson.li.ssimo.org> On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: > On 26.2.2014 16:00, Simo Sorce wrote: > >>>> need to be protected as carefully as the private key. > >>> > > > >>> > >This is something I meant to discuss too, how do we protect them ? > >>> > >Clearly we have ACIs but I am wondering if we want to encrypt them with > >>> > >keys not immediately or easily available via LDAP ? > >>> > > > >>> > >It's kind of catastrofic if they get inadvertently exposed like if > >>> > >someone does a ldapsearch as "Directory Manager", which is one of the > >>> > >reasons why we encrypt kerberos key material before storing it into the > >>> > >db. > >> > > >> >PKCS#8 allows encryption, I guess we can use that. There needs to be > >> >some metadata on how to decrypt the blob though, so that the PKCS#11 > >> >module can actually decrypt it when necessary. > > Yep, and we also need to decide what master key is used and where it is > > placed, and who access it, and how:-) > > Let's move the discussion forward, we need to implement the schema for 4.0. > > Do I understand correctly that the whole purpose of > krbPrincipalName=K/M at IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example > is just to encrypt keys with some other key which is located at some other > place? I.e. the goal is to lower the probability that a random ldapsearch will > return encrypted blob and master key at once, right? Yes, it would also be nice if we could finally offload this key from LDAP for added security, but we are not there yet. > What algorithm/method should we use for key wrapping? As far as I remember > from my studies key wrapping is very sensitive thing and we definitely need to > use some existing standard&tool for doing it. Can we just call some NSS > function with default/system-wide parameters and let it do it's job? I think that would be what we want to do in some form. > That would mean that, after all, we just need to provide some blob as key > wrapping key :-) (Generated with care it deserves etc.) The key must be self describing somehow (for algorithm agility). > We have had discussion with Honza and the first idea is to add attribute like > 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key > when necessary. > - During decryption: Do a LDAP search with filter like (keyId=) > to find appropriate wrapping key. > - The harder part is how to pick a wrapping key for encryption. It can be > tricky if the wrapped key is shared among more users (DNS servers) etc. > - It is possible to easily use multiple wrapping keys at once so key rollover > is easy. You can re-encrypt keys one by one. This makes things complicated fast. One thing I was thinking was to use a keytab and krb functions to do the wrapping but that would be pretty IPA specific. > The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 > objects inside the same token will be encrypted with the same key. > - Decryption is easy - the same as in previous case. > - Encryption is basically the same as encryption. > - Key rollover is hard. You would have to re-encrypt all keys and change > wrappingKeyId associated with given token at once - but it is impossible > because we don't have LDAP transactions. As a result, clients will be confused > during rollover. (Consider problems with syncrepl when clients can see changes > immediately.) Yeah this is a problem we need to address. > The third approach is 'hybrid': > A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is > used for encrypting new objects stored into PKCS#11 token. Each key stored in > the token has own wrappingKeyId attribute and it is used for decryption. > - Decryption is easy - the same as in previous case. > - Encryption always use wrappingKeyId associated with given token. > - Key roll over can start from wrappingKeyId associated with the token and > then re-encrypt keys in the token one by one. All keys can be decrypted in any > step (assuming that changes in one LDAP object are atomic). > > > Where is a hole in this design? :-) I do not like the idea of having to add a wrappingKeyId everywhere. My initial though was to have a central place where wrapping keys are stored, and during a rollover period you try all the keys until one works or decryption fails. At the end of rollover you delete the old key so you avoid the additional load. > Where should we store wrapping keys for users/services and DNS servers? User > object or cn=dns doesn't sound like a good idea because it would defeat the > purpose. Indeed. And this is the biggest problem. It would be nice to have a mechanism to securely transfer the key to the DNS servers w/o having to store it permanently in LDAP. If we had this mechanism we'd be able to apply it to the Kerberos master key too. But it can't be confined to installation time only, which is easy, it needs to be possible to update it at a later time, which is where we have issues, as our replication mechanism is LDAP. If we solve the DNA plugin issue with the ability to use groups for authentication I guess we could build a control/extend operation that would allow masters to transfer keys to each other w/o exposing them as LDAP searches, do we want to try to go in that direction ? Simo. -- Simo Sorce * Red Hat, Inc * New York From tbabej at redhat.com Tue Mar 4 15:59:02 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 04 Mar 2014 16:59:02 +0100 Subject: [Freeipa-devel] [PATCHES] 0337-0343 YAML test configuration In-Reply-To: <5315B1C3.20108@redhat.com> References: <52A9A0A9.9040706@redhat.com> <52CA81B1.4040602@redhat.com> <53147882.9090203@redhat.com> <5315B1C3.20108@redhat.com> Message-ID: <5315F846.5080204@redhat.com> Thanks, PATCH 341: ACK (this is the last remaining ACK for this patchset) On 03/04/2014 11:58 AM, Petr Viktorin wrote: > On 03/03/2014 01:41 PM, Tomas Babej wrote: >> Finally got to this patchset! >> >> PATCH 337: ACK >> PATCH 338: ACK >> >> This prohibits us to use extra roles that end in digits. Can you put a >> note explaining that in >> >> http://www.freeipa.org/page/V3/Integration_testing#Host_configuration > > Updated. > >> Also, this wiki page points out to environment variables so that it >> seems it is the preferred method of configuration. We should mention >> more user friendly YAML here first. > > Let's do that when the patches are pushed. #3938 should stay open > until it's done. > >> PATCH 339: ACK >> PATCH 340: ACK >> PATCH 341: >> >> The have_master variable seems redundant in from_dict method (it's only >> a local definition and not referenced anywhere else): >> >> + def from_dict(cls, dct, config): >> + from ipatests.test_integration.host import BaseHost >> + >> + domain_type = dct.pop('type') >> + assert domain_type in ('IPA', 'AD') >> + domain_name = dct.pop('name') >> + self = cls(config, domain_name, domain_type) >> + >> + have_master = False >> + for host_dict in dct.pop('hosts'): >> + host = BaseHost.from_dict(host_dict, self) >> + self.hosts.append(host) >> + if host.role == 'master': >> + have_master = True >> + >> + check_config_dict_empty(dct, 'domain %s' % domain_name) >> + >> + return self > > Right you are. Fixed. > >> PATCH 342: ACK >> PATCH 343: ACK >> >> PATCH 348: ACK >> PATCH 349: ACK >> >> > -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From dpal at redhat.com Tue Mar 4 16:00:08 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 04 Mar 2014 11:00:08 -0500 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <1393946811.22047.75.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> Message-ID: <5315F888.8040805@redhat.com> On 03/04/2014 10:26 AM, Simo Sorce wrote: > On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: >> On 26.2.2014 16:00, Simo Sorce wrote: >>>>>> need to be protected as carefully as the private key. >>>>>>> This is something I meant to discuss too, how do we protect them ? >>>>>>> Clearly we have ACIs but I am wondering if we want to encrypt them with >>>>>>> keys not immediately or easily available via LDAP ? >>>>>>> >>>>>>> It's kind of catastrofic if they get inadvertently exposed like if >>>>>>> someone does a ldapsearch as "Directory Manager", which is one of the >>>>>>> reasons why we encrypt kerberos key material before storing it into the >>>>>>> db. >>>>> PKCS#8 allows encryption, I guess we can use that. There needs to be >>>>> some metadata on how to decrypt the blob though, so that the PKCS#11 >>>>> module can actually decrypt it when necessary. >>> Yep, and we also need to decide what master key is used and where it is >>> placed, and who access it, and how:-) >> Let's move the discussion forward, we need to implement the schema for 4.0. >> >> Do I understand correctly that the whole purpose of >> krbPrincipalName=K/M at IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example >> is just to encrypt keys with some other key which is located at some other >> place? I.e. the goal is to lower the probability that a random ldapsearch will >> return encrypted blob and master key at once, right? > Yes, it would also be nice if we could finally offload this key from > LDAP for added security, but we are not there yet. > >> What algorithm/method should we use for key wrapping? As far as I remember >> from my studies key wrapping is very sensitive thing and we definitely need to >> use some existing standard&tool for doing it. Can we just call some NSS >> function with default/system-wide parameters and let it do it's job? > I think that would be what we want to do in some form. > >> That would mean that, after all, we just need to provide some blob as key >> wrapping key :-) (Generated with care it deserves etc.) > The key must be self describing somehow (for algorithm agility). > > >> We have had discussion with Honza and the first idea is to add attribute like >> 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key >> when necessary. >> - During decryption: Do a LDAP search with filter like (keyId=) >> to find appropriate wrapping key. >> - The harder part is how to pick a wrapping key for encryption. It can be >> tricky if the wrapped key is shared among more users (DNS servers) etc. >> - It is possible to easily use multiple wrapping keys at once so key rollover >> is easy. You can re-encrypt keys one by one. > This makes things complicated fast. > One thing I was thinking was to use a keytab and krb functions to do the > wrapping but that would be pretty IPA specific. > >> The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 >> objects inside the same token will be encrypted with the same key. >> - Decryption is easy - the same as in previous case. >> - Encryption is basically the same as encryption. >> - Key rollover is hard. You would have to re-encrypt all keys and change >> wrappingKeyId associated with given token at once - but it is impossible >> because we don't have LDAP transactions. As a result, clients will be confused >> during rollover. (Consider problems with syncrepl when clients can see changes >> immediately.) > Yeah this is a problem we need to address. > >> The third approach is 'hybrid': >> A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is >> used for encrypting new objects stored into PKCS#11 token. Each key stored in >> the token has own wrappingKeyId attribute and it is used for decryption. >> - Decryption is easy - the same as in previous case. >> - Encryption always use wrappingKeyId associated with given token. >> - Key roll over can start from wrappingKeyId associated with the token and >> then re-encrypt keys in the token one by one. All keys can be decrypted in any >> step (assuming that changes in one LDAP object are atomic). >> >> >> Where is a hole in this design? :-) > I do not like the idea of having to add a wrappingKeyId everywhere. > > My initial though was to have a central place where wrapping keys are > stored, and during a rollover period you try all the keys until one > works or decryption fails. At the end of rollover you delete the old key > so you avoid the additional load. > >> Where should we store wrapping keys for users/services and DNS servers? User >> object or cn=dns doesn't sound like a good idea because it would defeat the >> purpose. > Indeed. And this is the biggest problem. It would be nice to have a > mechanism to securely transfer the key to the DNS servers w/o having to > store it permanently in LDAP. If we had this mechanism we'd be able to > apply it to the Kerberos master key too. But it can't be confined to > installation time only, which is easy, it needs to be possible to update > it at a later time, which is where we have issues, as our replication > mechanism is LDAP. > > If we solve the DNA plugin issue with the ability to use groups for > authentication I guess we could build a control/extend operation that > would allow masters to transfer keys to each other w/o exposing them as > LDAP searches, do we want to try to go in that direction ? > > Simo. > Should we consider "vault" as a storage for these keys too? It already supports recovery of the symmetric and asymmetric keys so may be these keys should be stored there? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pspacek at redhat.com Tue Mar 4 16:08:54 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Mar 2014 17:08:54 +0100 Subject: [Freeipa-devel] GSS-Proxy <-> TPM <-> PKCS#11 (silly idea) In-Reply-To: <1392553375.22754.13.camel@willson.li.ssimo.org> References: <52FE1F7A.8030206@redhat.com> <1392553375.22754.13.camel@willson.li.ssimo.org> Message-ID: <5315FA96.7060602@redhat.com> On 16.2.2014 13:22, Simo Sorce wrote: > On Fri, 2014-02-14 at 14:51 +0100, Petr Spacek wrote: >> Hello, >> >> I have got an silly idea to use TPM (Trusted Platform Module) as backend for >> Keytab storage (via GSS-Proxy). >> >> GSS-Proxy prevents application from accessing key material, right? So >> GSS-Proxy could theoretically store keys in TPM and application wouldn't >> notice any difference, right? >> >> We have libraries for that in Fedora already: >> https://admin.fedoraproject.org/pkgdb/acls/name/trousers >> >> >> Even sillier idea is to use TPM as a PKCS#11 module: >> http://trousers.sourceforge.net/pkcs11.html >> >> I have no idea what the use case could be ... :-) May be as a "cache" for >> PKCS#11 module in SSSD? >> >> >> As I said, it is just a silly idea. >> > > Open a ticket in the GSS-Proxy trac :) Is it a good topic for bachelor/master thesis? We are going to send list of topics for next year so we have a chance to add it. We are not going to touch this any time soon so it sounds like a good idea to me. -- Petr^2 Spacek From simo at redhat.com Tue Mar 4 16:12:28 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 04 Mar 2014 11:12:28 -0500 Subject: [Freeipa-devel] [PATCH] 0145: trust fix filtering of users from subdomains In-Reply-To: <20140304093321.GG16644@redhat.com> References: <20140304091325.GF16644@redhat.com> <53159BDA.6060007@redhat.com> <20140304093321.GG16644@redhat.com> Message-ID: <1393949548.22047.76.camel@willson.li.ssimo.org> On Tue, 2014-03-04 at 11:33 +0200, Alexander Bokovoy wrote: > On Tue, 04 Mar 2014, Martin Kosek wrote: > >On 03/04/2014 10:13 AM, Alexander Bokovoy wrote: > >> Attached patch should fix https://fedorahosted.org/freeipa/ticket/4207 > >> where we didn't filter out users from disabled subdomains aggressively > >> enough. > >> > >> The code that did not filter exists only in git, not in released > >> versions yet. > >> > >> Attached also a screenshot that explains the behavior. > >> > >> The code was tested by me, Sumit, and Scott, and reviewed over last few > >> days by Simo and Sumit. > > > >Thanks Alexander! Do I understand it right that it has an ACK from Simo and > >Sumit? If yes, I will push the patch to master and ipa-3-3 (when fedorahosted > >git starts working again). > I'd like to get ACKs here, Simo didn't see the latest version yesterday. > Looks good to me. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Mar 4 16:14:17 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 04 Mar 2014 11:14:17 -0500 Subject: [Freeipa-devel] [PATCH] 0145: trust fix filtering of users from subdomains In-Reply-To: <20140304111049.GT2710@localhost.localdomain> References: <20140304091325.GF16644@redhat.com> <20140304111049.GT2710@localhost.localdomain> Message-ID: <1393949657.22047.77.camel@willson.li.ssimo.org> On Tue, 2014-03-04 at 12:10 +0100, Sumit Bose wrote: > On Tue, Mar 04, 2014 at 11:13:25AM +0200, Alexander Bokovoy wrote: > > Attached patch should fix https://fedorahosted.org/freeipa/ticket/4207 > > where we didn't filter out users from disabled subdomains aggressively > > enough. > > > > The code that did not filter exists only in git, not in released > > versions yet. > > > > Attached also a screenshot that explains the behavior. > > > > The code was tested by me, Sumit, and Scott, and reviewed over last few > > days by Simo and Sumit. > > This patch worked well in my test, AS and TGS requests for IPA user and > IPA services went well, as TGS request from trusted users for IPA > services. According to the krb5kdc logs delegation HTTP->ldap was ok as > well. > > I was not able to test S4U2Self and S4U2Proxy from the command line with > kvno, but I think this might be expected since we currently do not > support enterprise principals in IPA. > > I still have one comment, see inline. > > bye, > Sumit > > > > > -- > > / Alexander Bokovoy > > > >From 9eafc57e54311d203254d84e3dab32261f1c9aba Mon Sep 17 00:00:00 2001 > > From: Alexander Bokovoy > > Date: Fri, 28 Feb 2014 22:03:29 +0200 > > Subject: [PATCH 9/9] fix filtering of subdomain-based trust users > > > > https://fedorahosted.org/freeipa/ticket/4207 > > --- > > daemons/ipa-kdb/ipa_kdb_mspac.c | 41 ++++++++++++++++++++++++++++++++--------- > > 1 file changed, 32 insertions(+), 9 deletions(-) > > > > diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c > > index 771b40b..cb1b68e 100644 > > --- a/daemons/ipa-kdb/ipa_kdb_mspac.c > > +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c > > @@ -806,6 +806,12 @@ static krb5_error_code ipadb_get_pac(krb5_context kcontext, > > krb5_error_code kerr; > > enum ndr_err_code ndr_err; > > > > + /* When no client entry is there, we cannot generate MS-PAC */ > > + if (!client) { > > + *pac = NULL; > > + return 0; > > + } > > + > > ipactx = ipadb_get_context(kcontext); > > if (!ipactx) { > > return KRB5_KDB_DBNOTINITED; > > @@ -1538,6 +1544,12 @@ static krb5_error_code ipadb_add_transited_service(krb5_context context, > > uint32_t i; > > char *tmpstr; > > > > + /* When proxy is NULL, authdata flag on the service principal was cleared > > + * by an admin. We don't generate MS-PAC in this case */ > > + if (proxy == NULL) { > > + return 0; > > + } > > + > > tmpctx = talloc_new(NULL); > > if (!tmpctx) { > > kerr = ENOMEM; > > @@ -1735,6 +1747,12 @@ static krb5_error_code ipadb_verify_pac(krb5_context context, > > } > > > > if (flags & KRB5_KDB_FLAG_CONSTRAINED_DELEGATION) { > > + if (proxy == NULL) { > > + *pac = NULL; > > + kerr = 0; > > + goto done; > > + } > > + > > kerr = ipadb_add_transited_service(context, proxy, server, > > old_pac, new_pac); > > if (kerr) { > > @@ -1990,20 +2008,27 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, > > krb5_db_entry *client_entry = NULL; > > > > > > - /* When client is NULL, authdata flag on the service principal was cleared > > - * by an admin. We don't generate MS-PAC in this case */ > > - if (client == NULL) { > > - *signed_auth_data = NULL; > > - return 0; > > - } > > + is_as_req = ((flags & KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY) != 0); > > > > /* When using s4u2proxy client_princ actually refers to the proxied user > > * while client->princ to the proxy service asking for the TGS on behalf > > * of the proxied user. So always use client_princ in preference */ > > if (client_princ != NULL) { > > ks_client_princ = client_princ; > > - kerr = ipadb_get_principal(context, client_princ, flags, &client_entry); > > + if (!is_as_req) { > > + kerr = ipadb_get_principal(context, client_princ, flags, &client_entry); > > + /* If we didn't find client_princ in our database, it might be: > > + * - a principal from another realm, handle it down in ipadb_get/verify_pac() > > + */ > > + if (!kerr) { > > + client_entry = NULL; > > + } > > + } > > If I understand it correctly client_princ should be always set so the > else block below is rarely executed. For TGS request (!is_as_req) > another LDAP search is done. I think this is done even in the case > where an IPA client want's a ticket for an IPA service where the client > pointer should already have the needed data. I see two identical > requests in the LDAP logs in this case. > > If there is a easy way to skip the second search for this type of > request I would vote to include it, otherwise I think it can be kept as > it is and the performance improvement can be added later. We should probably compare client_princ and client->princ and skip ipadb_get_principal() if they are the same. But I think we can do this as a separate patch. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Mar 4 16:25:23 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 04 Mar 2014 11:25:23 -0500 Subject: [Freeipa-devel] GSS-Proxy <-> TPM <-> PKCS#11 (silly idea) In-Reply-To: <5315FA96.7060602@redhat.com> References: <52FE1F7A.8030206@redhat.com> <1392553375.22754.13.camel@willson.li.ssimo.org> <5315FA96.7060602@redhat.com> Message-ID: <5315FE73.2020008@redhat.com> On 03/04/2014 11:08 AM, Petr Spacek wrote: > On 16.2.2014 13:22, Simo Sorce wrote: >> On Fri, 2014-02-14 at 14:51 +0100, Petr Spacek wrote: >>> Hello, >>> >>> I have got an silly idea to use TPM (Trusted Platform Module) as >>> backend for >>> Keytab storage (via GSS-Proxy). >>> >>> GSS-Proxy prevents application from accessing key material, right? So >>> GSS-Proxy could theoretically store keys in TPM and application >>> wouldn't >>> notice any difference, right? >>> >>> We have libraries for that in Fedora already: >>> https://admin.fedoraproject.org/pkgdb/acls/name/trousers >>> >>> >>> Even sillier idea is to use TPM as a PKCS#11 module: >>> http://trousers.sourceforge.net/pkcs11.html >>> >>> I have no idea what the use case could be ... :-) May be as a >>> "cache" for >>> PKCS#11 module in SSSD? >>> >>> >>> As I said, it is just a silly idea. >>> >> >> Open a ticket in the GSS-Proxy trac :) > > Is it a good topic for bachelor/master thesis? We are going to send > list of topics for next year so we have a chance to add it. > > We are not going to touch this any time soon so it sounds like a good > idea to me. > I am not sure. Sounds like a lot of work with questionable results... -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pspacek at redhat.com Tue Mar 4 16:25:39 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Mar 2014 17:25:39 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <5315F888.8040805@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> Message-ID: <5315FE83.403@redhat.com> On 4.3.2014 17:00, Dmitri Pal wrote: > On 03/04/2014 10:26 AM, Simo Sorce wrote: >> On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: >>> On 26.2.2014 16:00, Simo Sorce wrote: >>>>>>> need to be protected as carefully as the private key. >>>>>>>> This is something I meant to discuss too, how do we protect them ? >>>>>>>> Clearly we have ACIs but I am wondering if we want to encrypt them with >>>>>>>> keys not immediately or easily available via LDAP ? >>>>>>>> >>>>>>>> It's kind of catastrofic if they get inadvertently exposed like if >>>>>>>> someone does a ldapsearch as "Directory Manager", which is one of the >>>>>>>> reasons why we encrypt kerberos key material before storing it into the >>>>>>>> db. >>>>>> PKCS#8 allows encryption, I guess we can use that. There needs to be >>>>>> some metadata on how to decrypt the blob though, so that the PKCS#11 >>>>>> module can actually decrypt it when necessary. >>>> Yep, and we also need to decide what master key is used and where it is >>>> placed, and who access it, and how:-) >>> Let's move the discussion forward, we need to implement the schema for 4.0. >>> >>> Do I understand correctly that the whole purpose of >>> krbPrincipalName=K/M at IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example >>> is just to encrypt keys with some other key which is located at some other >>> place? I.e. the goal is to lower the probability that a random ldapsearch will >>> return encrypted blob and master key at once, right? >> Yes, it would also be nice if we could finally offload this key from >> LDAP for added security, but we are not there yet. >> >>> What algorithm/method should we use for key wrapping? As far as I remember >>> from my studies key wrapping is very sensitive thing and we definitely need to >>> use some existing standard&tool for doing it. Can we just call some NSS >>> function with default/system-wide parameters and let it do it's job? >> I think that would be what we want to do in some form. >> >>> That would mean that, after all, we just need to provide some blob as key >>> wrapping key :-) (Generated with care it deserves etc.) >> The key must be self describing somehow (for algorithm agility). >> >> >>> We have had discussion with Honza and the first idea is to add attribute like >>> 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key >>> when necessary. >>> - During decryption: Do a LDAP search with filter like (keyId=) >>> to find appropriate wrapping key. >>> - The harder part is how to pick a wrapping key for encryption. It can be >>> tricky if the wrapped key is shared among more users (DNS servers) etc. >>> - It is possible to easily use multiple wrapping keys at once so key rollover >>> is easy. You can re-encrypt keys one by one. >> This makes things complicated fast. >> One thing I was thinking was to use a keytab and krb functions to do the >> wrapping but that would be pretty IPA specific. >> >>> The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 >>> objects inside the same token will be encrypted with the same key. >>> - Decryption is easy - the same as in previous case. >>> - Encryption is basically the same as encryption. >>> - Key rollover is hard. You would have to re-encrypt all keys and change >>> wrappingKeyId associated with given token at once - but it is impossible >>> because we don't have LDAP transactions. As a result, clients will be confused >>> during rollover. (Consider problems with syncrepl when clients can see changes >>> immediately.) >> Yeah this is a problem we need to address. >> >>> The third approach is 'hybrid': >>> A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is >>> used for encrypting new objects stored into PKCS#11 token. Each key stored in >>> the token has own wrappingKeyId attribute and it is used for decryption. >>> - Decryption is easy - the same as in previous case. >>> - Encryption always use wrappingKeyId associated with given token. >>> - Key roll over can start from wrappingKeyId associated with the token and >>> then re-encrypt keys in the token one by one. All keys can be decrypted in any >>> step (assuming that changes in one LDAP object are atomic). >>> >>> >>> Where is a hole in this design? :-) >> I do not like the idea of having to add a wrappingKeyId everywhere. >> >> My initial though was to have a central place where wrapping keys are >> stored, and during a rollover period you try all the keys until one >> works or decryption fails. At the end of rollover you delete the old key >> so you avoid the additional load. >> >>> Where should we store wrapping keys for users/services and DNS servers? User >>> object or cn=dns doesn't sound like a good idea because it would defeat the >>> purpose. >> Indeed. And this is the biggest problem. It would be nice to have a >> mechanism to securely transfer the key to the DNS servers w/o having to >> store it permanently in LDAP. If we had this mechanism we'd be able to >> apply it to the Kerberos master key too. But it can't be confined to >> installation time only, which is easy, it needs to be possible to update >> it at a later time, which is where we have issues, as our replication >> mechanism is LDAP. >> >> If we solve the DNA plugin issue with the ability to use groups for >> authentication I guess we could build a control/extend operation that >> would allow masters to transfer keys to each other w/o exposing them as >> LDAP searches, do we want to try to go in that direction ? >> >> Simo. >> > Should we consider "vault" as a storage for these keys too? > It already supports recovery of the symmetric and asymmetric keys so may be > these keys should be stored there? Maybe. The question is if we want to support DNSSEC without Dogtag ... -- Petr^2 Spacek From amisnyov at redhat.com Tue Mar 4 16:27:21 2014 From: amisnyov at redhat.com (Adam Misnyovszki) Date: Tue, 4 Mar 2014 11:27:21 -0500 (EST) Subject: [Freeipa-devel] [PATCH] 545 webui: Don't act on keyboard events which originated in, different dialog In-Reply-To: <530C988B.90504@redhat.com> References: <530C988B.90504@redhat.com> Message-ID: <799250726.3565643.1393950441572.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Petr Vobornik" > To: "freeipa-devel" > Sent: Tuesday, February 25, 2014 2:20:11 PM > Subject: [Freeipa-devel] [PATCH] 545 webui: Don't act on keyboard events which originated in, different dialog > > Fixes issue when: > 1. 2 dialogs are opened > 2. top dialog's close button is focused > 3. user presses enter to execute 'close' action > 4. dialog is immediately closed (enter key is still pressed) > 5. second dialog automatically receives focus (it's top dialog now) > 6. user releases the key > 7. second dialog reacts to keyup event - which is by default > confirmation mixin's confirm event > 8. UNDESIRED behavior occurs > > Now confirmation mixin remembers which keys were pressed and released > and reacts only to those which originated there. > > https://fedorahosted.org/freeipa/ticket/4098 > -- > Petr Vobornik > ACK However, we should keep in mind, that there is an issue, when the ENTER key is pressed for a long time(ie more time than a keydown event is fired), the dialog starts to "blink". In my oppinion, this later behaviour is a wontfix, because firstly it is not easy to handle, secondly > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pspacek at redhat.com Tue Mar 4 16:40:57 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Mar 2014 17:40:57 +0100 Subject: [Freeipa-devel] GSS-Proxy <-> TPM <-> PKCS#11 (silly idea) In-Reply-To: <5315FE73.2020008@redhat.com> References: <52FE1F7A.8030206@redhat.com> <1392553375.22754.13.camel@willson.li.ssimo.org> <5315FA96.7060602@redhat.com> <5315FE73.2020008@redhat.com> Message-ID: <53160219.4010601@redhat.com> On 4.3.2014 17:25, Dmitri Pal wrote: > On 03/04/2014 11:08 AM, Petr Spacek wrote: >> On 16.2.2014 13:22, Simo Sorce wrote: >>> On Fri, 2014-02-14 at 14:51 +0100, Petr Spacek wrote: >>>> Hello, >>>> >>>> I have got an silly idea to use TPM (Trusted Platform Module) as backend for >>>> Keytab storage (via GSS-Proxy). >>>> >>>> GSS-Proxy prevents application from accessing key material, right? So >>>> GSS-Proxy could theoretically store keys in TPM and application wouldn't >>>> notice any difference, right? >>>> >>>> We have libraries for that in Fedora already: >>>> https://admin.fedoraproject.org/pkgdb/acls/name/trousers >>>> >>>> >>>> Even sillier idea is to use TPM as a PKCS#11 module: >>>> http://trousers.sourceforge.net/pkcs11.html >>>> >>>> I have no idea what the use case could be ... :-) May be as a "cache" for >>>> PKCS#11 module in SSSD? >>>> >>>> >>>> As I said, it is just a silly idea. >>>> >>> >>> Open a ticket in the GSS-Proxy trac :) >> >> Is it a good topic for bachelor/master thesis? We are going to send list of >> topics for next year so we have a chance to add it. >> >> We are not going to touch this any time soon so it sounds like a good idea >> to me. >> > I am not sure. Sounds like a lot of work with questionable results... I thought that it is purpose of thesis? :-) Now seriously: We are not doing "research with questionable results" because we don't have time for it - I perfectly understand that. That is the reason why I'm proposing such crazy ideas for theses. -- Petr^2 Spacek From dpal at redhat.com Tue Mar 4 16:43:24 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 04 Mar 2014 11:43:24 -0500 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <5315FE83.403@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> Message-ID: <531602AC.60605@redhat.com> On 03/04/2014 11:25 AM, Petr Spacek wrote: > On 4.3.2014 17:00, Dmitri Pal wrote: >> On 03/04/2014 10:26 AM, Simo Sorce wrote: >>> On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: >>>> On 26.2.2014 16:00, Simo Sorce wrote: >>>>>>>> need to be protected as carefully as the private key. >>>>>>>>> This is something I meant to discuss too, how do we protect >>>>>>>>> them ? >>>>>>>>> Clearly we have ACIs but I am wondering if we want to encrypt >>>>>>>>> them with >>>>>>>>> keys not immediately or easily available via LDAP ? >>>>>>>>> >>>>>>>>> It's kind of catastrofic if they get inadvertently exposed >>>>>>>>> like if >>>>>>>>> someone does a ldapsearch as "Directory Manager", which is one >>>>>>>>> of the >>>>>>>>> reasons why we encrypt kerberos key material before storing it >>>>>>>>> into the >>>>>>>>> db. >>>>>>> PKCS#8 allows encryption, I guess we can use that. There needs >>>>>>> to be >>>>>>> some metadata on how to decrypt the blob though, so that the >>>>>>> PKCS#11 >>>>>>> module can actually decrypt it when necessary. >>>>> Yep, and we also need to decide what master key is used and where >>>>> it is >>>>> placed, and who access it, and how:-) >>>> Let's move the discussion forward, we need to implement the schema >>>> for 4.0. >>>> >>>> Do I understand correctly that the whole purpose of >>>> krbPrincipalName=K/M at IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example >>>> >>>> is just to encrypt keys with some other key which is located at >>>> some other >>>> place? I.e. the goal is to lower the probability that a random >>>> ldapsearch will >>>> return encrypted blob and master key at once, right? >>> Yes, it would also be nice if we could finally offload this key from >>> LDAP for added security, but we are not there yet. >>> >>>> What algorithm/method should we use for key wrapping? As far as I >>>> remember >>>> from my studies key wrapping is very sensitive thing and we >>>> definitely need to >>>> use some existing standard&tool for doing it. Can we just call some >>>> NSS >>>> function with default/system-wide parameters and let it do it's job? >>> I think that would be what we want to do in some form. >>> >>>> That would mean that, after all, we just need to provide some blob >>>> as key >>>> wrapping key :-) (Generated with care it deserves etc.) >>> The key must be self describing somehow (for algorithm agility). >>> >>> >>>> We have had discussion with Honza and the first idea is to add >>>> attribute like >>>> 'wrappingKeyId' to each encrypted blob and use it for locating >>>> appropriate key >>>> when necessary. >>>> - During decryption: Do a LDAP search with filter like >>>> (keyId=) >>>> to find appropriate wrapping key. >>>> - The harder part is how to pick a wrapping key for encryption. It >>>> can be >>>> tricky if the wrapped key is shared among more users (DNS servers) >>>> etc. >>>> - It is possible to easily use multiple wrapping keys at once so >>>> key rollover >>>> is easy. You can re-encrypt keys one by one. >>> This makes things complicated fast. >>> One thing I was thinking was to use a keytab and krb functions to do >>> the >>> wrapping but that would be pretty IPA specific. >>> >>>> The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all >>>> PKCS#11 >>>> objects inside the same token will be encrypted with the same key. >>>> - Decryption is easy - the same as in previous case. >>>> - Encryption is basically the same as encryption. >>>> - Key rollover is hard. You would have to re-encrypt all keys and >>>> change >>>> wrappingKeyId associated with given token at once - but it is >>>> impossible >>>> because we don't have LDAP transactions. As a result, clients will >>>> be confused >>>> during rollover. (Consider problems with syncrepl when clients can >>>> see changes >>>> immediately.) >>> Yeah this is a problem we need to address. >>> >>>> The third approach is 'hybrid': >>>> A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' >>>> and is >>>> used for encrypting new objects stored into PKCS#11 token. Each key >>>> stored in >>>> the token has own wrappingKeyId attribute and it is used for >>>> decryption. >>>> - Decryption is easy - the same as in previous case. >>>> - Encryption always use wrappingKeyId associated with given token. >>>> - Key roll over can start from wrappingKeyId associated with the >>>> token and >>>> then re-encrypt keys in the token one by one. All keys can be >>>> decrypted in any >>>> step (assuming that changes in one LDAP object are atomic). >>>> >>>> >>>> Where is a hole in this design? :-) >>> I do not like the idea of having to add a wrappingKeyId everywhere. >>> >>> My initial though was to have a central place where wrapping keys are >>> stored, and during a rollover period you try all the keys until one >>> works or decryption fails. At the end of rollover you delete the old >>> key >>> so you avoid the additional load. >>> >>>> Where should we store wrapping keys for users/services and DNS >>>> servers? User >>>> object or cn=dns doesn't sound like a good idea because it would >>>> defeat the >>>> purpose. >>> Indeed. And this is the biggest problem. It would be nice to have a >>> mechanism to securely transfer the key to the DNS servers w/o having to >>> store it permanently in LDAP. If we had this mechanism we'd be able to >>> apply it to the Kerberos master key too. But it can't be confined to >>> installation time only, which is easy, it needs to be possible to >>> update >>> it at a later time, which is where we have issues, as our replication >>> mechanism is LDAP. >>> >>> If we solve the DNA plugin issue with the ability to use groups for >>> authentication I guess we could build a control/extend operation that >>> would allow masters to transfer keys to each other w/o exposing them as >>> LDAP searches, do we want to try to go in that direction ? >>> >>> Simo. >>> >> Should we consider "vault" as a storage for these keys too? >> It already supports recovery of the symmetric and asymmetric keys so >> may be >> these keys should be stored there? > > Maybe. The question is if we want to support DNSSEC without Dogtag ... > Without Dogtag? Vault would be an independent component from CA I assume, though CA might be needed anyways to issue transport keys for the internal components. But I think that even if we use Vault as an internal password and key storage I do not see a reason why we can't require it for DNSSEC. Why over-complicate things if we already have components that can be used? If we see a requests to support DNSSEC without Vault component we will adjust but I do not think we should limit ourselves in the first implementation. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Mar 4 16:47:09 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 04 Mar 2014 11:47:09 -0500 Subject: [Freeipa-devel] GSS-Proxy <-> TPM <-> PKCS#11 (silly idea) In-Reply-To: <53160219.4010601@redhat.com> References: <52FE1F7A.8030206@redhat.com> <1392553375.22754.13.camel@willson.li.ssimo.org> <5315FA96.7060602@redhat.com> <5315FE73.2020008@redhat.com> <53160219.4010601@redhat.com> Message-ID: <5316038D.10305@redhat.com> On 03/04/2014 11:40 AM, Petr Spacek wrote: > On 4.3.2014 17:25, Dmitri Pal wrote: >> On 03/04/2014 11:08 AM, Petr Spacek wrote: >>> On 16.2.2014 13:22, Simo Sorce wrote: >>>> On Fri, 2014-02-14 at 14:51 +0100, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> I have got an silly idea to use TPM (Trusted Platform Module) as >>>>> backend for >>>>> Keytab storage (via GSS-Proxy). >>>>> >>>>> GSS-Proxy prevents application from accessing key material, right? So >>>>> GSS-Proxy could theoretically store keys in TPM and application >>>>> wouldn't >>>>> notice any difference, right? >>>>> >>>>> We have libraries for that in Fedora already: >>>>> https://admin.fedoraproject.org/pkgdb/acls/name/trousers >>>>> >>>>> >>>>> Even sillier idea is to use TPM as a PKCS#11 module: >>>>> http://trousers.sourceforge.net/pkcs11.html >>>>> >>>>> I have no idea what the use case could be ... :-) May be as a >>>>> "cache" for >>>>> PKCS#11 module in SSSD? >>>>> >>>>> >>>>> As I said, it is just a silly idea. >>>>> >>>> >>>> Open a ticket in the GSS-Proxy trac :) >>> >>> Is it a good topic for bachelor/master thesis? We are going to send >>> list of >>> topics for next year so we have a chance to add it. >>> >>> We are not going to touch this any time soon so it sounds like a >>> good idea >>> to me. >>> >> I am not sure. Sounds like a lot of work with questionable results... > > I thought that it is purpose of thesis? :-) > > Now seriously: We are not doing "research with questionable results" > because we don't have time for it - I perfectly understand that. > > That is the reason why I'm proposing such crazy ideas for theses. > My hesitation is related to the satisfaction from the work being done by a student. We have many topics that we know we need for the project and taking them (and implementing right) would be beneficial for the project and rewarding for the student. With this idea I am concerned that since there is no clear drive for it to be needed there might not be enough motivation to make is usable for the project. But I might be wrong. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From amisnyov at redhat.com Tue Mar 4 16:56:51 2014 From: amisnyov at redhat.com (Adam Misnyovszki) Date: Tue, 4 Mar 2014 11:56:51 -0500 (EST) Subject: [Freeipa-devel] [PATCH] 545 webui: Don't act on keyboard events which originated in, different dialog In-Reply-To: <799250726.3565643.1393950441572.JavaMail.zimbra@redhat.com> References: <530C988B.90504@redhat.com> <799250726.3565643.1393950441572.JavaMail.zimbra@redhat.com> Message-ID: <919251367.3572806.1393952211928.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Adam Misnyovszki" > To: "Petr Vobornik" > Cc: "freeipa-devel" > Sent: Tuesday, March 4, 2014 5:27:21 PM > Subject: Re: [Freeipa-devel] [PATCH] 545 webui: Don't act on keyboard events which originated in, different dialog > > > > ----- Original Message ----- > > From: "Petr Vobornik" > > To: "freeipa-devel" > > Sent: Tuesday, February 25, 2014 2:20:11 PM > > Subject: [Freeipa-devel] [PATCH] 545 webui: Don't act on keyboard events > > which originated in, different dialog > > > > Fixes issue when: > > 1. 2 dialogs are opened > > 2. top dialog's close button is focused > > 3. user presses enter to execute 'close' action > > 4. dialog is immediately closed (enter key is still pressed) > > 5. second dialog automatically receives focus (it's top dialog now) > > 6. user releases the key > > 7. second dialog reacts to keyup event - which is by default > > confirmation mixin's confirm event > > 8. UNDESIRED behavior occurs > > > > Now confirmation mixin remembers which keys were pressed and released > > and reacts only to those which originated there. > > > > https://fedorahosted.org/freeipa/ticket/4098 > > -- > > Petr Vobornik > > > > ACK > However, we should keep in mind, that there is an issue, when the ENTER key > is pressed for a long time(ie more time than a keydown event is fired), the > dialog starts to "blink". In my oppinion, this later behaviour is a wontfix, > because firstly it is not easy to handle, secondly because this problem exists in mostly all softwares, thirdly this is not the scope of the ticket. Sorry for the amendment, zimbra doesn't work quite well. Adam > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > From pspacek at redhat.com Tue Mar 4 17:56:43 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Mar 2014 18:56:43 +0100 Subject: [Freeipa-devel] DNSSEC key rotation: long-term approach In-Reply-To: <52FD02B7.3060404@redhat.com> References: <52FD02B7.3060404@redhat.com> Message-ID: <531613DB.9000001@redhat.com> Hello list, On 13.2.2014 18:36, Petr Spacek wrote: > Automatic key rotation: > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm I have started discussion with OpenDNSSEC people about LDAP database backend and distributed-key generation: http://lists.opendnssec.org/pipermail/opendnssec-user/2014-March/002779.html Feel free to join the discussion. BTW they also develop SoftHSM module (i.e. software implementation of PKCS#11 module) so there are some possibilities for extending SoftHSM for our purposes. -- Petr^2 Spacek From pspacek at redhat.com Tue Mar 4 18:14:08 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Mar 2014 19:14:08 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <531602AC.60605@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> Message-ID: <531617F0.3030201@redhat.com> On 4.3.2014 17:43, Dmitri Pal wrote: > On 03/04/2014 11:25 AM, Petr Spacek wrote: >> On 4.3.2014 17:00, Dmitri Pal wrote: >>> On 03/04/2014 10:26 AM, Simo Sorce wrote: >>>> On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: >>>>> On 26.2.2014 16:00, Simo Sorce wrote: >>>>>>>>> need to be protected as carefully as the private key. >>>>>>>>>> This is something I meant to discuss too, how do we protect them ? >>>>>>>>>> Clearly we have ACIs but I am wondering if we want to encrypt them with >>>>>>>>>> keys not immediately or easily available via LDAP ? >>>>>>>>>> >>>>>>>>>> It's kind of catastrofic if they get inadvertently exposed like if >>>>>>>>>> someone does a ldapsearch as "Directory Manager", which is one of the >>>>>>>>>> reasons why we encrypt kerberos key material before storing it into the >>>>>>>>>> db. >>>>>>>> PKCS#8 allows encryption, I guess we can use that. There needs to be >>>>>>>> some metadata on how to decrypt the blob though, so that the PKCS#11 >>>>>>>> module can actually decrypt it when necessary. >>>>>> Yep, and we also need to decide what master key is used and where it is >>>>>> placed, and who access it, and how:-) >>>>> Let's move the discussion forward, we need to implement the schema for 4.0. >>>>> >>>>> Do I understand correctly that the whole purpose of >>>>> krbPrincipalName=K/M at IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example >>>>> >>>>> is just to encrypt keys with some other key which is located at some other >>>>> place? I.e. the goal is to lower the probability that a random ldapsearch >>>>> will >>>>> return encrypted blob and master key at once, right? >>>> Yes, it would also be nice if we could finally offload this key from >>>> LDAP for added security, but we are not there yet. >>>> >>>>> What algorithm/method should we use for key wrapping? As far as I remember >>>>> from my studies key wrapping is very sensitive thing and we definitely >>>>> need to >>>>> use some existing standard&tool for doing it. Can we just call some NSS >>>>> function with default/system-wide parameters and let it do it's job? >>>> I think that would be what we want to do in some form. >>>> >>>>> That would mean that, after all, we just need to provide some blob as key >>>>> wrapping key :-) (Generated with care it deserves etc.) >>>> The key must be self describing somehow (for algorithm agility). >>>> >>>> >>>>> We have had discussion with Honza and the first idea is to add attribute >>>>> like >>>>> 'wrappingKeyId' to each encrypted blob and use it for locating >>>>> appropriate key >>>>> when necessary. >>>>> - During decryption: Do a LDAP search with filter like >>>>> (keyId=) >>>>> to find appropriate wrapping key. >>>>> - The harder part is how to pick a wrapping key for encryption. It can be >>>>> tricky if the wrapped key is shared among more users (DNS servers) etc. >>>>> - It is possible to easily use multiple wrapping keys at once so key >>>>> rollover >>>>> is easy. You can re-encrypt keys one by one. >>>> This makes things complicated fast. >>>> One thing I was thinking was to use a keytab and krb functions to do the >>>> wrapping but that would be pretty IPA specific. >>>> >>>>> The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 >>>>> objects inside the same token will be encrypted with the same key. >>>>> - Decryption is easy - the same as in previous case. >>>>> - Encryption is basically the same as encryption. >>>>> - Key rollover is hard. You would have to re-encrypt all keys and change >>>>> wrappingKeyId associated with given token at once - but it is impossible >>>>> because we don't have LDAP transactions. As a result, clients will be >>>>> confused >>>>> during rollover. (Consider problems with syncrepl when clients can see >>>>> changes >>>>> immediately.) >>>> Yeah this is a problem we need to address. >>>> >>>>> The third approach is 'hybrid': >>>>> A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is >>>>> used for encrypting new objects stored into PKCS#11 token. Each key >>>>> stored in >>>>> the token has own wrappingKeyId attribute and it is used for decryption. >>>>> - Decryption is easy - the same as in previous case. >>>>> - Encryption always use wrappingKeyId associated with given token. >>>>> - Key roll over can start from wrappingKeyId associated with the token and >>>>> then re-encrypt keys in the token one by one. All keys can be decrypted >>>>> in any >>>>> step (assuming that changes in one LDAP object are atomic). >>>>> >>>>> >>>>> Where is a hole in this design? :-) >>>> I do not like the idea of having to add a wrappingKeyId everywhere. >>>> >>>> My initial though was to have a central place where wrapping keys are >>>> stored, and during a rollover period you try all the keys until one >>>> works or decryption fails. At the end of rollover you delete the old key >>>> so you avoid the additional load. >>>> >>>>> Where should we store wrapping keys for users/services and DNS servers? User >>>>> object or cn=dns doesn't sound like a good idea because it would defeat the >>>>> purpose. >>>> Indeed. And this is the biggest problem. It would be nice to have a >>>> mechanism to securely transfer the key to the DNS servers w/o having to >>>> store it permanently in LDAP. If we had this mechanism we'd be able to >>>> apply it to the Kerberos master key too. But it can't be confined to >>>> installation time only, which is easy, it needs to be possible to update >>>> it at a later time, which is where we have issues, as our replication >>>> mechanism is LDAP. >>>> >>>> If we solve the DNA plugin issue with the ability to use groups for >>>> authentication I guess we could build a control/extend operation that >>>> would allow masters to transfer keys to each other w/o exposing them as >>>> LDAP searches, do we want to try to go in that direction ? >>>> >>>> Simo. >>>> >>> Should we consider "vault" as a storage for these keys too? >>> It already supports recovery of the symmetric and asymmetric keys so may be >>> these keys should be stored there? >> >> Maybe. The question is if we want to support DNSSEC without Dogtag ... >> > Without Dogtag? Vault would be an independent component from CA I assume, > though CA might be needed anyways to issue transport keys for the internal > components. > But I think that even if we use Vault as an internal password and key storage > I do not see a reason why we can't require it for DNSSEC. > Why over-complicate things if we already have components that can be used? If > we see a requests to support DNSSEC without Vault component we will adjust but > I do not think we should limit ourselves in the first implementation. I'm personally fine with that. Are we going to re-prioritize Password Vault from Backlog to 4.0? https://fedorahosted.org/freeipa/ticket/3872 We need that in 4.0 timeframe for DNSSEC otherwise you need to convince Simo that key wrapping is not necessary :-) -- Petr^2 Spacek From npmccallum at redhat.com Tue Mar 4 19:03:36 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 04 Mar 2014 14:03:36 -0500 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <5315287A.8050201@redhat.com> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> <53105B27.4070003@redhat.com> <1393597539.3562.21.camel@localhost.localdomain> <20140228144351.GC16644@redhat.com> <1393599745.3562.23.camel@localhost.localdomain> <20140228151536.GD16644@redhat.com> <5310A983.50409@redhat.com> <5312A07A.3060706@redhat.com> <5315287A.8050201@redhat.com> Message-ID: <1393959816.7196.3.camel@localhost.localdomain> On Mon, 2014-03-03 at 20:12 -0500, Dmitri Pal wrote: > On 03/01/2014 10:07 PM, Adam Young wrote: > > On 02/28/2014 10:21 AM, Petr Viktorin wrote: > >> On 02/28/2014 04:15 PM, Alexander Bokovoy wrote: > >>> On Fri, 28 Feb 2014, Nathaniel McCallum wrote: > >>>> On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: > >>>>> On Fri, 28 Feb 2014, Nathaniel McCallum wrote: > >>>>> >On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: > >>>>> >> On 28.2.2014 04:02, Rob Crittenden wrote: > >>>>> >> > Alexander Bokovoy wrote: > >>>>> >> >> On Thu, 27 Feb 2014, Nathaniel McCallum wrote: > >>>>> >> >>> So the recent discussion on importing tokens led me to write a > >>>>> script to > >>>>> >> >>> parse RFC 6030 xml files into IPA token data. This all works > >>>>> well. But > >>>>> >> >>> now I need to integrate it into the IPA framework. > >>>>> >> >>> > >>>>> >> >>> This command will parse one or more xml files, creating a set > >>>>> of tokens > >>>>> >> >>> to be added. Given that we already have otptoken-add on the > >>>>> server-side, > >>>>> >> >>> it seems to me that all work needs to be done on the > >>>>> client-side. How do > >>>>> >> >>> I create a new client-side command that calls existing > >>>>> server-side API? > >>>>> >> >> subclass from frontend.Local, override run() or forward() > >>>>> method and > >>>>> >> >> perform batch > >>>>> >> >> operation of otptoken_add from there. > >>>>> >> >> > >>>>> >> >> See cli.help, for example. > >>>>> >> > > >>>>> >> > If you do an override, do forward() for cli-specific work. > >>>>> >> > > >>>>> >> > But you should do as little as possible for reasons you already > >>>>> stated: > >>>>> >> > the UI. Anything you do in forward Petr will need to implement > >>>>> in the UI. > >>>>> >> > > >>>>> >> > Unfortunately we don't yet have a nice way to handle files. > >>>>> We have > >>>>> >> > tickets open at https://fedorahosted.org/freeipa/ticket/1225 and > >>>>> >> > https://fedorahosted.org/freeipa/ticket/2933 > >>>>> >> > > >>>>> >> > If this file is something that would be pasted into a big text > >>>>> field > >>>>> >> > then you can probably handle it in a similarly clumsy way that > >>>>> we do > >>>>> >> > CSRs in the cert plugin. > >>>>> >> > > >>>>> >> > rob > >>>>> >> > >>>>> >> +1 for parsing it on server. Otherwise every client, not just CLI > >>>>> or Web > >>>>> >> UI, would have to reimplement the same logic - having it on server > >>>>> will > >>>>> >> support better integration with third party products. > >>>>> >> > >>>>> >> Parsing on client would be understandable if there was some middle > >>>>> step > >>>>> >> which would require some action from user, i.e, pick only some > >>>>> tokens to > >>>>> >> import. > >>>>> > > >>>>> >If we parse on the server side, how do we handle the long-running > >>>>> >operation? Think of the case of importing hundreds or thousands of > >>>>> >tokens... > >>>>> Why then to do it as a IPA CLI command at all? > >>>>> This is an administrative task which can be done with a separate > >>>>> ipa-otp-import command, designated to run on IPA masters. > >>>> > >>>> Agreed. > >>>> > >>>> 1. Is there a framework for this? Or should it just be an independent > >>>> script? > >>> We don't really have a framework for administrative tools. You may > >>> start > >>> with install/tools/ipa-adtrust-install, it is main part is relatively > >>> independent of the task (which is in > >>> ipaserver/install/adtrustinstance.py) > >>> > >> > >> The framework is there, new tools use it, and there's a ticket to > >> convert old ones: https://fedorahosted.org/freeipa/ticket/2652 (it's > >> low priority in Future Releases, so not much progress is there...) > >> Also see http://www.freeipa.org/page/V3/Logging_and_output > >> > >> > > > > > > The RESTful approach would be: > > > > 1. Upload a file to a specific URL (not JSON RPC) > > 2. Receive back a 202 Accepted HTTP Request, to include an URL to > > poll for status > > > > Not certain the right response from the URL in step 2 would be, but I > > am assuming it would be 200 with the body of the message stating: > > processing or completed. > > > > It would be really nice if the Batch command could be handled this way > > as well. The response back could be the partial responses until > > processing is complete. > > > > It might also be nice to supply an email address for notification of > > completed processing instead of polling, if it is going to be a really > > long running task. > > > > > > > > > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Yes I think that: > 1) We should not limit it to server side operation only > 2) Upload the whole file and then process it. > 3) We should already have code to upload files, we did it for > entitlements and were supposed to use for certs. > 4) Make sure we have a generic upload mechanism that reads a chunk of a > configurable size and asks for more (pagination by 65K might be a good > default). > > Regarding token files specifically: they can be big but not super huge. > 10-20K tokens makes sense but probably not more. More than that would be > a real corner case becuase it is hard to deploy that amount of tokens at > the same time. It can take months and you do not want token file to > contain many tokens that would sit on the shelf. Tokens expire so it is > inefficient to buy huge chunks and let them sit unused. > > UI you allow uploading file too and then would process it locally. > The processing of the file should generate a log or report. It would be > nice to get indication from the server that it is still working so may > be upload protocol should be something like: > > client: Initialize the transfer > server: ready > client: here is the chunk of data > server: ack > ... > client: here is the last chunk of data > server: ack, (forks the file processing method that updates shared > status data) come back in x seconds > client: how are things? > server: working, here is current status, come back in x seconds > ... > client: how are things? > server: done, here is current status, have errors in a file > client: start download > server: here is the chunk > ... > > I think we can short socket the command for now to fail if it is not > local on the server and then build the upload mechanism but separate > command as proposed in this thread would lock us in a local approach > forever. The problem is that we have no infrastructure for any of this. It would all have to be built just for the import command. It is also a fairly rare, admin-only operation. For this reason, I am leaning towards implementing it as a simple script to be executed on the FreeIPA master. The main drawback of this approach is that you don't get import functionality in the UI. I also disagree that doing it this way now necessitates we do it this way forever. In fact, it is more likely that if we design a fully featured server implementation now, we'll get details wrong and be stuck with it. Doing it on the master using the existing API frees us to add a server-side API in the future. Nathaniel From dpal at redhat.com Tue Mar 4 19:11:53 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 04 Mar 2014 14:11:53 -0500 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <1393959816.7196.3.camel@localhost.localdomain> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> <53105B27.4070003@redhat.com> <1393597539.3562.21.camel@localhost.localdomain> <20140228144351.GC16644@redhat.com> <1393599745.3562.23.camel@localhost.localdomain> <20140228151536.GD16644@redhat.com> <5310A983.50409@redhat.com> <5312A07A.3060706@redhat.com> <5315287A.8050201@redhat.com> <1393959816.7196.3.camel@localhost.localdomain> Message-ID: <53162579.80100@redhat.com> On 03/04/2014 02:03 PM, Nathaniel McCallum wrote: > On Mon, 2014-03-03 at 20:12 -0500, Dmitri Pal wrote: >> On 03/01/2014 10:07 PM, Adam Young wrote: >>> On 02/28/2014 10:21 AM, Petr Viktorin wrote: >>>> On 02/28/2014 04:15 PM, Alexander Bokovoy wrote: >>>>> On Fri, 28 Feb 2014, Nathaniel McCallum wrote: >>>>>> On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: >>>>>>> On Fri, 28 Feb 2014, Nathaniel McCallum wrote: >>>>>>>> On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: >>>>>>>>> On 28.2.2014 04:02, Rob Crittenden wrote: >>>>>>>>>> Alexander Bokovoy wrote: >>>>>>>>>>> On Thu, 27 Feb 2014, Nathaniel McCallum wrote: >>>>>>>>>>>> So the recent discussion on importing tokens led me to write a >>>>>>> script to >>>>>>>>>>>> parse RFC 6030 xml files into IPA token data. This all works >>>>>>> well. But >>>>>>>>>>>> now I need to integrate it into the IPA framework. >>>>>>>>>>>> >>>>>>>>>>>> This command will parse one or more xml files, creating a set >>>>>>> of tokens >>>>>>>>>>>> to be added. Given that we already have otptoken-add on the >>>>>>> server-side, >>>>>>>>>>>> it seems to me that all work needs to be done on the >>>>>>> client-side. How do >>>>>>>>>>>> I create a new client-side command that calls existing >>>>>>> server-side API? >>>>>>>>>>> subclass from frontend.Local, override run() or forward() >>>>>>> method and >>>>>>>>>>> perform batch >>>>>>>>>>> operation of otptoken_add from there. >>>>>>>>>>> >>>>>>>>>>> See cli.help, for example. >>>>>>>>>> If you do an override, do forward() for cli-specific work. >>>>>>>>>> >>>>>>>>>> But you should do as little as possible for reasons you already >>>>>>> stated: >>>>>>>>>> the UI. Anything you do in forward Petr will need to implement >>>>>>> in the UI. >>>>>>>>>> Unfortunately we don't yet have a nice way to handle files. >>>>>>> We have >>>>>>>>>> tickets open at https://fedorahosted.org/freeipa/ticket/1225 and >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2933 >>>>>>>>>> >>>>>>>>>> If this file is something that would be pasted into a big text >>>>>>> field >>>>>>>>>> then you can probably handle it in a similarly clumsy way that >>>>>>> we do >>>>>>>>>> CSRs in the cert plugin. >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>> +1 for parsing it on server. Otherwise every client, not just CLI >>>>>>> or Web >>>>>>>>> UI, would have to reimplement the same logic - having it on server >>>>>>> will >>>>>>>>> support better integration with third party products. >>>>>>>>> >>>>>>>>> Parsing on client would be understandable if there was some middle >>>>>>> step >>>>>>>>> which would require some action from user, i.e, pick only some >>>>>>> tokens to >>>>>>>>> import. >>>>>>>> If we parse on the server side, how do we handle the long-running >>>>>>>> operation? Think of the case of importing hundreds or thousands of >>>>>>>> tokens... >>>>>>> Why then to do it as a IPA CLI command at all? >>>>>>> This is an administrative task which can be done with a separate >>>>>>> ipa-otp-import command, designated to run on IPA masters. >>>>>> Agreed. >>>>>> >>>>>> 1. Is there a framework for this? Or should it just be an independent >>>>>> script? >>>>> We don't really have a framework for administrative tools. You may >>>>> start >>>>> with install/tools/ipa-adtrust-install, it is main part is relatively >>>>> independent of the task (which is in >>>>> ipaserver/install/adtrustinstance.py) >>>>> >>>> The framework is there, new tools use it, and there's a ticket to >>>> convert old ones: https://fedorahosted.org/freeipa/ticket/2652 (it's >>>> low priority in Future Releases, so not much progress is there...) >>>> Also see http://www.freeipa.org/page/V3/Logging_and_output >>>> >>>> >>> >>> The RESTful approach would be: >>> >>> 1. Upload a file to a specific URL (not JSON RPC) >>> 2. Receive back a 202 Accepted HTTP Request, to include an URL to >>> poll for status >>> >>> Not certain the right response from the URL in step 2 would be, but I >>> am assuming it would be 200 with the body of the message stating: >>> processing or completed. >>> >>> It would be really nice if the Batch command could be handled this way >>> as well. The response back could be the partial responses until >>> processing is complete. >>> >>> It might also be nice to supply an email address for notification of >>> completed processing instead of polling, if it is going to be a really >>> long running task. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Yes I think that: >> 1) We should not limit it to server side operation only >> 2) Upload the whole file and then process it. >> 3) We should already have code to upload files, we did it for >> entitlements and were supposed to use for certs. >> 4) Make sure we have a generic upload mechanism that reads a chunk of a >> configurable size and asks for more (pagination by 65K might be a good >> default). >> >> Regarding token files specifically: they can be big but not super huge. >> 10-20K tokens makes sense but probably not more. More than that would be >> a real corner case becuase it is hard to deploy that amount of tokens at >> the same time. It can take months and you do not want token file to >> contain many tokens that would sit on the shelf. Tokens expire so it is >> inefficient to buy huge chunks and let them sit unused. >> >> UI you allow uploading file too and then would process it locally. >> The processing of the file should generate a log or report. It would be >> nice to get indication from the server that it is still working so may >> be upload protocol should be something like: >> >> client: Initialize the transfer >> server: ready >> client: here is the chunk of data >> server: ack >> ... >> client: here is the last chunk of data >> server: ack, (forks the file processing method that updates shared >> status data) come back in x seconds >> client: how are things? >> server: working, here is current status, come back in x seconds >> ... >> client: how are things? >> server: done, here is current status, have errors in a file >> client: start download >> server: here is the chunk >> ... >> >> I think we can short socket the command for now to fail if it is not >> local on the server and then build the upload mechanism but separate >> command as proposed in this thread would lock us in a local approach >> forever. > The problem is that we have no infrastructure for any of this. It would > all have to be built just for the import command. It is also a fairly > rare, admin-only operation. For this reason, I am leaning towards > implementing it as a simple script to be executed on the FreeIPA master. > The main drawback of this approach is that you don't get import > functionality in the UI. > > I also disagree that doing it this way now necessitates we do it this > way forever. In fact, it is more likely that if we design a fully > featured server implementation now, we'll get details wrong and be stuck > with it. Doing it on the master using the existing API frees us to add a > server-side API in the future. > > Nathaniel > We already have use cases for upload but we defer it again and again for a better time. We need to upload and download files for other use cases: Download: a) Keytabs (we have a ticket to do it in the UI) b) Reports c) Import logs (for tokens or users) ... Upload: a) Token file b) SSH public keys c) Register user certificate in IPA ... We need this mechanisms anyways. We have been deferring this for too long. I would rather defer support of the hardware tokens till next version and do an upload in the cli and UI than cut the corner and create yet one off mechanism. IMO we are going the wrong way about it. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Tue Mar 4 19:19:44 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 04 Mar 2014 14:19:44 -0500 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <531617F0.3030201@redhat.com> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> Message-ID: <1393960784.22047.78.camel@willson.li.ssimo.org> On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: > On 4.3.2014 17:43, Dmitri Pal wrote: > > On 03/04/2014 11:25 AM, Petr Spacek wrote: > >> On 4.3.2014 17:00, Dmitri Pal wrote: > >>> On 03/04/2014 10:26 AM, Simo Sorce wrote: > >>>> On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: > >>>>> On 26.2.2014 16:00, Simo Sorce wrote: > >>>>>>>>> need to be protected as carefully as the private key. > >>>>>>>>>> This is something I meant to discuss too, how do we protect them ? > >>>>>>>>>> Clearly we have ACIs but I am wondering if we want to encrypt them with > >>>>>>>>>> keys not immediately or easily available via LDAP ? > >>>>>>>>>> > >>>>>>>>>> It's kind of catastrofic if they get inadvertently exposed like if > >>>>>>>>>> someone does a ldapsearch as "Directory Manager", which is one of the > >>>>>>>>>> reasons why we encrypt kerberos key material before storing it into the > >>>>>>>>>> db. > >>>>>>>> PKCS#8 allows encryption, I guess we can use that. There needs to be > >>>>>>>> some metadata on how to decrypt the blob though, so that the PKCS#11 > >>>>>>>> module can actually decrypt it when necessary. > >>>>>> Yep, and we also need to decide what master key is used and where it is > >>>>>> placed, and who access it, and how:-) > >>>>> Let's move the discussion forward, we need to implement the schema for 4.0. > >>>>> > >>>>> Do I understand correctly that the whole purpose of > >>>>> krbPrincipalName=K/M at IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example > >>>>> > >>>>> is just to encrypt keys with some other key which is located at some other > >>>>> place? I.e. the goal is to lower the probability that a random ldapsearch > >>>>> will > >>>>> return encrypted blob and master key at once, right? > >>>> Yes, it would also be nice if we could finally offload this key from > >>>> LDAP for added security, but we are not there yet. > >>>> > >>>>> What algorithm/method should we use for key wrapping? As far as I remember > >>>>> from my studies key wrapping is very sensitive thing and we definitely > >>>>> need to > >>>>> use some existing standard&tool for doing it. Can we just call some NSS > >>>>> function with default/system-wide parameters and let it do it's job? > >>>> I think that would be what we want to do in some form. > >>>> > >>>>> That would mean that, after all, we just need to provide some blob as key > >>>>> wrapping key :-) (Generated with care it deserves etc.) > >>>> The key must be self describing somehow (for algorithm agility). > >>>> > >>>> > >>>>> We have had discussion with Honza and the first idea is to add attribute > >>>>> like > >>>>> 'wrappingKeyId' to each encrypted blob and use it for locating > >>>>> appropriate key > >>>>> when necessary. > >>>>> - During decryption: Do a LDAP search with filter like > >>>>> (keyId=) > >>>>> to find appropriate wrapping key. > >>>>> - The harder part is how to pick a wrapping key for encryption. It can be > >>>>> tricky if the wrapped key is shared among more users (DNS servers) etc. > >>>>> - It is possible to easily use multiple wrapping keys at once so key > >>>>> rollover > >>>>> is easy. You can re-encrypt keys one by one. > >>>> This makes things complicated fast. > >>>> One thing I was thinking was to use a keytab and krb functions to do the > >>>> wrapping but that would be pretty IPA specific. > >>>> > >>>>> The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 > >>>>> objects inside the same token will be encrypted with the same key. > >>>>> - Decryption is easy - the same as in previous case. > >>>>> - Encryption is basically the same as encryption. > >>>>> - Key rollover is hard. You would have to re-encrypt all keys and change > >>>>> wrappingKeyId associated with given token at once - but it is impossible > >>>>> because we don't have LDAP transactions. As a result, clients will be > >>>>> confused > >>>>> during rollover. (Consider problems with syncrepl when clients can see > >>>>> changes > >>>>> immediately.) > >>>> Yeah this is a problem we need to address. > >>>> > >>>>> The third approach is 'hybrid': > >>>>> A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is > >>>>> used for encrypting new objects stored into PKCS#11 token. Each key > >>>>> stored in > >>>>> the token has own wrappingKeyId attribute and it is used for decryption. > >>>>> - Decryption is easy - the same as in previous case. > >>>>> - Encryption always use wrappingKeyId associated with given token. > >>>>> - Key roll over can start from wrappingKeyId associated with the token and > >>>>> then re-encrypt keys in the token one by one. All keys can be decrypted > >>>>> in any > >>>>> step (assuming that changes in one LDAP object are atomic). > >>>>> > >>>>> > >>>>> Where is a hole in this design? :-) > >>>> I do not like the idea of having to add a wrappingKeyId everywhere. > >>>> > >>>> My initial though was to have a central place where wrapping keys are > >>>> stored, and during a rollover period you try all the keys until one > >>>> works or decryption fails. At the end of rollover you delete the old key > >>>> so you avoid the additional load. > >>>> > >>>>> Where should we store wrapping keys for users/services and DNS servers? User > >>>>> object or cn=dns doesn't sound like a good idea because it would defeat the > >>>>> purpose. > >>>> Indeed. And this is the biggest problem. It would be nice to have a > >>>> mechanism to securely transfer the key to the DNS servers w/o having to > >>>> store it permanently in LDAP. If we had this mechanism we'd be able to > >>>> apply it to the Kerberos master key too. But it can't be confined to > >>>> installation time only, which is easy, it needs to be possible to update > >>>> it at a later time, which is where we have issues, as our replication > >>>> mechanism is LDAP. > >>>> > >>>> If we solve the DNA plugin issue with the ability to use groups for > >>>> authentication I guess we could build a control/extend operation that > >>>> would allow masters to transfer keys to each other w/o exposing them as > >>>> LDAP searches, do we want to try to go in that direction ? > >>>> > >>>> Simo. > >>>> > >>> Should we consider "vault" as a storage for these keys too? > >>> It already supports recovery of the symmetric and asymmetric keys so may be > >>> these keys should be stored there? > >> > >> Maybe. The question is if we want to support DNSSEC without Dogtag ... > >> > > Without Dogtag? Vault would be an independent component from CA I assume, > > though CA might be needed anyways to issue transport keys for the internal > > components. > > But I think that even if we use Vault as an internal password and key storage > > I do not see a reason why we can't require it for DNSSEC. > > Why over-complicate things if we already have components that can be used? If > > we see a requests to support DNSSEC without Vault component we will adjust but > > I do not think we should limit ourselves in the first implementation. > > I'm personally fine with that. > > Are we going to re-prioritize Password Vault from Backlog to 4.0? > https://fedorahosted.org/freeipa/ticket/3872 > > We need that in 4.0 timeframe for DNSSEC otherwise you need to convince Simo > that key wrapping is not necessary :-) For 4.0 we could document that you have to copy the keys around manually. And add Vault support in 4.1 ? Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Tue Mar 4 19:27:09 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 04 Mar 2014 14:27:09 -0500 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <53162579.80100@redhat.com> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> <53105B27.4070003@redhat.com> <1393597539.3562.21.camel@localhost.localdomain> <20140228144351.GC16644@redhat.com> <1393599745.3562.23.camel@localhost.localdomain> <20140228151536.GD16644@redhat.com> <5310A983.50409@redhat.com> <5312A07A.3060706@redhat.com> <5315287A.8050201@redhat.com> <1393959816.7196.3.camel@localhost.localdomain> <53162579.80100@redhat.com> Message-ID: <1393961229.7196.14.camel@localhost.localdomain> On Tue, 2014-03-04 at 14:11 -0500, Dmitri Pal wrote: > On 03/04/2014 02:03 PM, Nathaniel McCallum wrote: > > On Mon, 2014-03-03 at 20:12 -0500, Dmitri Pal wrote: > >> On 03/01/2014 10:07 PM, Adam Young wrote: > >>> On 02/28/2014 10:21 AM, Petr Viktorin wrote: > >>>> On 02/28/2014 04:15 PM, Alexander Bokovoy wrote: > >>>>> On Fri, 28 Feb 2014, Nathaniel McCallum wrote: > >>>>>> On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: > >>>>>>> On Fri, 28 Feb 2014, Nathaniel McCallum wrote: > >>>>>>>> On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: > >>>>>>>>> On 28.2.2014 04:02, Rob Crittenden wrote: > >>>>>>>>>> Alexander Bokovoy wrote: > >>>>>>>>>>> On Thu, 27 Feb 2014, Nathaniel McCallum wrote: > >>>>>>>>>>>> So the recent discussion on importing tokens led me to write a > >>>>>>> script to > >>>>>>>>>>>> parse RFC 6030 xml files into IPA token data. This all works > >>>>>>> well. But > >>>>>>>>>>>> now I need to integrate it into the IPA framework. > >>>>>>>>>>>> > >>>>>>>>>>>> This command will parse one or more xml files, creating a set > >>>>>>> of tokens > >>>>>>>>>>>> to be added. Given that we already have otptoken-add on the > >>>>>>> server-side, > >>>>>>>>>>>> it seems to me that all work needs to be done on the > >>>>>>> client-side. How do > >>>>>>>>>>>> I create a new client-side command that calls existing > >>>>>>> server-side API? > >>>>>>>>>>> subclass from frontend.Local, override run() or forward() > >>>>>>> method and > >>>>>>>>>>> perform batch > >>>>>>>>>>> operation of otptoken_add from there. > >>>>>>>>>>> > >>>>>>>>>>> See cli.help, for example. > >>>>>>>>>> If you do an override, do forward() for cli-specific work. > >>>>>>>>>> > >>>>>>>>>> But you should do as little as possible for reasons you already > >>>>>>> stated: > >>>>>>>>>> the UI. Anything you do in forward Petr will need to implement > >>>>>>> in the UI. > >>>>>>>>>> Unfortunately we don't yet have a nice way to handle files. > >>>>>>> We have > >>>>>>>>>> tickets open at https://fedorahosted.org/freeipa/ticket/1225 and > >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2933 > >>>>>>>>>> > >>>>>>>>>> If this file is something that would be pasted into a big text > >>>>>>> field > >>>>>>>>>> then you can probably handle it in a similarly clumsy way that > >>>>>>> we do > >>>>>>>>>> CSRs in the cert plugin. > >>>>>>>>>> > >>>>>>>>>> rob > >>>>>>>>> +1 for parsing it on server. Otherwise every client, not just CLI > >>>>>>> or Web > >>>>>>>>> UI, would have to reimplement the same logic - having it on server > >>>>>>> will > >>>>>>>>> support better integration with third party products. > >>>>>>>>> > >>>>>>>>> Parsing on client would be understandable if there was some middle > >>>>>>> step > >>>>>>>>> which would require some action from user, i.e, pick only some > >>>>>>> tokens to > >>>>>>>>> import. > >>>>>>>> If we parse on the server side, how do we handle the long-running > >>>>>>>> operation? Think of the case of importing hundreds or thousands of > >>>>>>>> tokens... > >>>>>>> Why then to do it as a IPA CLI command at all? > >>>>>>> This is an administrative task which can be done with a separate > >>>>>>> ipa-otp-import command, designated to run on IPA masters. > >>>>>> Agreed. > >>>>>> > >>>>>> 1. Is there a framework for this? Or should it just be an independent > >>>>>> script? > >>>>> We don't really have a framework for administrative tools. You may > >>>>> start > >>>>> with install/tools/ipa-adtrust-install, it is main part is relatively > >>>>> independent of the task (which is in > >>>>> ipaserver/install/adtrustinstance.py) > >>>>> > >>>> The framework is there, new tools use it, and there's a ticket to > >>>> convert old ones: https://fedorahosted.org/freeipa/ticket/2652 (it's > >>>> low priority in Future Releases, so not much progress is there...) > >>>> Also see http://www.freeipa.org/page/V3/Logging_and_output > >>>> > >>>> > >>> > >>> The RESTful approach would be: > >>> > >>> 1. Upload a file to a specific URL (not JSON RPC) > >>> 2. Receive back a 202 Accepted HTTP Request, to include an URL to > >>> poll for status > >>> > >>> Not certain the right response from the URL in step 2 would be, but I > >>> am assuming it would be 200 with the body of the message stating: > >>> processing or completed. > >>> > >>> It would be really nice if the Batch command could be handled this way > >>> as well. The response back could be the partial responses until > >>> processing is complete. > >>> > >>> It might also be nice to supply an email address for notification of > >>> completed processing instead of polling, if it is going to be a really > >>> long running task. > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Freeipa-devel mailing list > >>> Freeipa-devel at redhat.com > >>> https://www.redhat.com/mailman/listinfo/freeipa-devel > >> Yes I think that: > >> 1) We should not limit it to server side operation only > >> 2) Upload the whole file and then process it. > >> 3) We should already have code to upload files, we did it for > >> entitlements and were supposed to use for certs. > >> 4) Make sure we have a generic upload mechanism that reads a chunk of a > >> configurable size and asks for more (pagination by 65K might be a good > >> default). > >> > >> Regarding token files specifically: they can be big but not super huge. > >> 10-20K tokens makes sense but probably not more. More than that would be > >> a real corner case becuase it is hard to deploy that amount of tokens at > >> the same time. It can take months and you do not want token file to > >> contain many tokens that would sit on the shelf. Tokens expire so it is > >> inefficient to buy huge chunks and let them sit unused. > >> > >> UI you allow uploading file too and then would process it locally. > >> The processing of the file should generate a log or report. It would be > >> nice to get indication from the server that it is still working so may > >> be upload protocol should be something like: > >> > >> client: Initialize the transfer > >> server: ready > >> client: here is the chunk of data > >> server: ack > >> ... > >> client: here is the last chunk of data > >> server: ack, (forks the file processing method that updates shared > >> status data) come back in x seconds > >> client: how are things? > >> server: working, here is current status, come back in x seconds > >> ... > >> client: how are things? > >> server: done, here is current status, have errors in a file > >> client: start download > >> server: here is the chunk > >> ... > >> > >> I think we can short socket the command for now to fail if it is not > >> local on the server and then build the upload mechanism but separate > >> command as proposed in this thread would lock us in a local approach > >> forever. > > The problem is that we have no infrastructure for any of this. It would > > all have to be built just for the import command. It is also a fairly > > rare, admin-only operation. For this reason, I am leaning towards > > implementing it as a simple script to be executed on the FreeIPA master. > > The main drawback of this approach is that you don't get import > > functionality in the UI. > > > > I also disagree that doing it this way now necessitates we do it this > > way forever. In fact, it is more likely that if we design a fully > > featured server implementation now, we'll get details wrong and be stuck > > with it. Doing it on the master using the existing API frees us to add a > > server-side API in the future. > > > > Nathaniel > > > We already have use cases for upload but we defer it again and again for > a better time. > We need to upload and download files for other use cases: > > Download: > a) Keytabs (we have a ticket to do it in the UI) > b) Reports > c) Import logs (for tokens or users) > ... > > Upload: > a) Token file > b) SSH public keys > c) Register user certificate in IPA > ... > > We need this mechanisms anyways. > We have been deferring this for too long. I agree. > I would rather defer support of the hardware tokens till next version > and do an upload in the cli and UI than cut the corner and create yet > one off mechanism. > > IMO we are going the wrong way about it. So the problem isn't hardware tokens, the problem is that users can modify tokens they shouldn't (these are most commonly hardware, but not necessarily so). Support for this can be added trivially once I get some of the more pressing issues off my plate. I don't see any reason to delay this. Let's not conflate issues. Imports are a different story. We could land an independent import script (IIS) in 4.0. This functionality could be moved to a framework script (FS) later. If backwards compatibility for this is a concern, the IIS could just point to the FS. If we desire not to support the IIS at all, we could ship it as contrib or distribute it independently. But once we have infrastructure for uploads/downloads/long-running task state, the code from the IIS should move to the server side with little modification. So it isn't lost effort. Having *some* form of import is highly desirable for 4.0. Nathaniel From simo at redhat.com Tue Mar 4 19:48:58 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 04 Mar 2014 14:48:58 -0500 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <1393960784.22047.78.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <53035A03.8070409@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> Message-ID: <1393962538.22047.82.camel@willson.li.ssimo.org> On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: > On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: > > On 4.3.2014 17:43, Dmitri Pal wrote: > > > On 03/04/2014 11:25 AM, Petr Spacek wrote: > > >> On 4.3.2014 17:00, Dmitri Pal wrote: > > >>> On 03/04/2014 10:26 AM, Simo Sorce wrote: > > >>>> On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: > > >>>>> On 26.2.2014 16:00, Simo Sorce wrote: > > >>>>>>>>> need to be protected as carefully as the private key. > > >>>>>>>>>> This is something I meant to discuss too, how do we protect them ? > > >>>>>>>>>> Clearly we have ACIs but I am wondering if we want to encrypt them with > > >>>>>>>>>> keys not immediately or easily available via LDAP ? > > >>>>>>>>>> > > >>>>>>>>>> It's kind of catastrofic if they get inadvertently exposed like if > > >>>>>>>>>> someone does a ldapsearch as "Directory Manager", which is one of the > > >>>>>>>>>> reasons why we encrypt kerberos key material before storing it into the > > >>>>>>>>>> db. > > >>>>>>>> PKCS#8 allows encryption, I guess we can use that. There needs to be > > >>>>>>>> some metadata on how to decrypt the blob though, so that the PKCS#11 > > >>>>>>>> module can actually decrypt it when necessary. > > >>>>>> Yep, and we also need to decide what master key is used and where it is > > >>>>>> placed, and who access it, and how:-) > > >>>>> Let's move the discussion forward, we need to implement the schema for 4.0. > > >>>>> > > >>>>> Do I understand correctly that the whole purpose of > > >>>>> krbPrincipalName=K/M at IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example > > >>>>> > > >>>>> is just to encrypt keys with some other key which is located at some other > > >>>>> place? I.e. the goal is to lower the probability that a random ldapsearch > > >>>>> will > > >>>>> return encrypted blob and master key at once, right? > > >>>> Yes, it would also be nice if we could finally offload this key from > > >>>> LDAP for added security, but we are not there yet. > > >>>> > > >>>>> What algorithm/method should we use for key wrapping? As far as I remember > > >>>>> from my studies key wrapping is very sensitive thing and we definitely > > >>>>> need to > > >>>>> use some existing standard&tool for doing it. Can we just call some NSS > > >>>>> function with default/system-wide parameters and let it do it's job? > > >>>> I think that would be what we want to do in some form. > > >>>> > > >>>>> That would mean that, after all, we just need to provide some blob as key > > >>>>> wrapping key :-) (Generated with care it deserves etc.) > > >>>> The key must be self describing somehow (for algorithm agility). > > >>>> > > >>>> > > >>>>> We have had discussion with Honza and the first idea is to add attribute > > >>>>> like > > >>>>> 'wrappingKeyId' to each encrypted blob and use it for locating > > >>>>> appropriate key > > >>>>> when necessary. > > >>>>> - During decryption: Do a LDAP search with filter like > > >>>>> (keyId=) > > >>>>> to find appropriate wrapping key. > > >>>>> - The harder part is how to pick a wrapping key for encryption. It can be > > >>>>> tricky if the wrapped key is shared among more users (DNS servers) etc. > > >>>>> - It is possible to easily use multiple wrapping keys at once so key > > >>>>> rollover > > >>>>> is easy. You can re-encrypt keys one by one. > > >>>> This makes things complicated fast. > > >>>> One thing I was thinking was to use a keytab and krb functions to do the > > >>>> wrapping but that would be pretty IPA specific. > > >>>> > > >>>>> The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 > > >>>>> objects inside the same token will be encrypted with the same key. > > >>>>> - Decryption is easy - the same as in previous case. > > >>>>> - Encryption is basically the same as encryption. > > >>>>> - Key rollover is hard. You would have to re-encrypt all keys and change > > >>>>> wrappingKeyId associated with given token at once - but it is impossible > > >>>>> because we don't have LDAP transactions. As a result, clients will be > > >>>>> confused > > >>>>> during rollover. (Consider problems with syncrepl when clients can see > > >>>>> changes > > >>>>> immediately.) > > >>>> Yeah this is a problem we need to address. > > >>>> > > >>>>> The third approach is 'hybrid': > > >>>>> A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is > > >>>>> used for encrypting new objects stored into PKCS#11 token. Each key > > >>>>> stored in > > >>>>> the token has own wrappingKeyId attribute and it is used for decryption. > > >>>>> - Decryption is easy - the same as in previous case. > > >>>>> - Encryption always use wrappingKeyId associated with given token. > > >>>>> - Key roll over can start from wrappingKeyId associated with the token and > > >>>>> then re-encrypt keys in the token one by one. All keys can be decrypted > > >>>>> in any > > >>>>> step (assuming that changes in one LDAP object are atomic). > > >>>>> > > >>>>> > > >>>>> Where is a hole in this design? :-) > > >>>> I do not like the idea of having to add a wrappingKeyId everywhere. > > >>>> > > >>>> My initial though was to have a central place where wrapping keys are > > >>>> stored, and during a rollover period you try all the keys until one > > >>>> works or decryption fails. At the end of rollover you delete the old key > > >>>> so you avoid the additional load. > > >>>> > > >>>>> Where should we store wrapping keys for users/services and DNS servers? User > > >>>>> object or cn=dns doesn't sound like a good idea because it would defeat the > > >>>>> purpose. > > >>>> Indeed. And this is the biggest problem. It would be nice to have a > > >>>> mechanism to securely transfer the key to the DNS servers w/o having to > > >>>> store it permanently in LDAP. If we had this mechanism we'd be able to > > >>>> apply it to the Kerberos master key too. But it can't be confined to > > >>>> installation time only, which is easy, it needs to be possible to update > > >>>> it at a later time, which is where we have issues, as our replication > > >>>> mechanism is LDAP. > > >>>> > > >>>> If we solve the DNA plugin issue with the ability to use groups for > > >>>> authentication I guess we could build a control/extend operation that > > >>>> would allow masters to transfer keys to each other w/o exposing them as > > >>>> LDAP searches, do we want to try to go in that direction ? > > >>>> > > >>>> Simo. > > >>>> > > >>> Should we consider "vault" as a storage for these keys too? > > >>> It already supports recovery of the symmetric and asymmetric keys so may be > > >>> these keys should be stored there? > > >> > > >> Maybe. The question is if we want to support DNSSEC without Dogtag ... > > >> > > > Without Dogtag? Vault would be an independent component from CA I assume, > > > though CA might be needed anyways to issue transport keys for the internal > > > components. > > > But I think that even if we use Vault as an internal password and key storage > > > I do not see a reason why we can't require it for DNSSEC. > > > Why over-complicate things if we already have components that can be used? If > > > we see a requests to support DNSSEC without Vault component we will adjust but > > > I do not think we should limit ourselves in the first implementation. > > > > I'm personally fine with that. > > > > Are we going to re-prioritize Password Vault from Backlog to 4.0? > > https://fedorahosted.org/freeipa/ticket/3872 > > > > We need that in 4.0 timeframe for DNSSEC otherwise you need to convince Simo > > that key wrapping is not necessary :-) > > For 4.0 we could document that you have to copy the keys around > manually. And add Vault support in 4.1 ? Actually an idea came to mind that might work well enough. We could store the symmetric key wrapped itself. The wrapping would be done using a public key per DNS server. Public keys for DNS servers would be generated via certmonger in the usual way. The only unknown here is who adds a new wrapper wen a new server is up and it publishes the public key in LDAP. For existing servers they can re-wrap themselves. It's a few layers but should not be too hard. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Tue Mar 4 20:25:41 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Mar 2014 21:25:41 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <1393962538.22047.82.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> Message-ID: <531636C5.6010304@redhat.com> On 4.3.2014 20:48, Simo Sorce wrote: > On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: >> On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: >>> On 4.3.2014 17:43, Dmitri Pal wrote: >>>> On 03/04/2014 11:25 AM, Petr Spacek wrote: >>>>> On 4.3.2014 17:00, Dmitri Pal wrote: >>>>>> On 03/04/2014 10:26 AM, Simo Sorce wrote: >>>>>>> On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: >>>>>>>> On 26.2.2014 16:00, Simo Sorce wrote: >>>>>>>>>>>> need to be protected as carefully as the private key. >>>>>>>>>>>>> This is something I meant to discuss too, how do we protect them ? >>>>>>>>>>>>> Clearly we have ACIs but I am wondering if we want to encrypt them with >>>>>>>>>>>>> keys not immediately or easily available via LDAP ? >>>>>>>>>>>>> >>>>>>>>>>>>> It's kind of catastrofic if they get inadvertently exposed like if >>>>>>>>>>>>> someone does a ldapsearch as "Directory Manager", which is one of the >>>>>>>>>>>>> reasons why we encrypt kerberos key material before storing it into the >>>>>>>>>>>>> db. >>>>>>>>>>> PKCS#8 allows encryption, I guess we can use that. There needs to be >>>>>>>>>>> some metadata on how to decrypt the blob though, so that the PKCS#11 >>>>>>>>>>> module can actually decrypt it when necessary. >>>>>>>>> Yep, and we also need to decide what master key is used and where it is >>>>>>>>> placed, and who access it, and how:-) >>>>>>>> Let's move the discussion forward, we need to implement the schema for 4.0. >>>>>>>> >>>>>>>> Do I understand correctly that the whole purpose of >>>>>>>> krbPrincipalName=K/M at IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example >>>>>>>> >>>>>>>> is just to encrypt keys with some other key which is located at some other >>>>>>>> place? I.e. the goal is to lower the probability that a random ldapsearch >>>>>>>> will >>>>>>>> return encrypted blob and master key at once, right? >>>>>>> Yes, it would also be nice if we could finally offload this key from >>>>>>> LDAP for added security, but we are not there yet. >>>>>>> >>>>>>>> What algorithm/method should we use for key wrapping? As far as I remember >>>>>>>> from my studies key wrapping is very sensitive thing and we definitely >>>>>>>> need to >>>>>>>> use some existing standard&tool for doing it. Can we just call some NSS >>>>>>>> function with default/system-wide parameters and let it do it's job? >>>>>>> I think that would be what we want to do in some form. >>>>>>> >>>>>>>> That would mean that, after all, we just need to provide some blob as key >>>>>>>> wrapping key :-) (Generated with care it deserves etc.) >>>>>>> The key must be self describing somehow (for algorithm agility). >>>>>>> >>>>>>> >>>>>>>> We have had discussion with Honza and the first idea is to add attribute >>>>>>>> like >>>>>>>> 'wrappingKeyId' to each encrypted blob and use it for locating >>>>>>>> appropriate key >>>>>>>> when necessary. >>>>>>>> - During decryption: Do a LDAP search with filter like >>>>>>>> (keyId=) >>>>>>>> to find appropriate wrapping key. >>>>>>>> - The harder part is how to pick a wrapping key for encryption. It can be >>>>>>>> tricky if the wrapped key is shared among more users (DNS servers) etc. >>>>>>>> - It is possible to easily use multiple wrapping keys at once so key >>>>>>>> rollover >>>>>>>> is easy. You can re-encrypt keys one by one. >>>>>>> This makes things complicated fast. >>>>>>> One thing I was thinking was to use a keytab and krb functions to do the >>>>>>> wrapping but that would be pretty IPA specific. >>>>>>> >>>>>>>> The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 >>>>>>>> objects inside the same token will be encrypted with the same key. >>>>>>>> - Decryption is easy - the same as in previous case. >>>>>>>> - Encryption is basically the same as encryption. >>>>>>>> - Key rollover is hard. You would have to re-encrypt all keys and change >>>>>>>> wrappingKeyId associated with given token at once - but it is impossible >>>>>>>> because we don't have LDAP transactions. As a result, clients will be >>>>>>>> confused >>>>>>>> during rollover. (Consider problems with syncrepl when clients can see >>>>>>>> changes >>>>>>>> immediately.) >>>>>>> Yeah this is a problem we need to address. >>>>>>> >>>>>>>> The third approach is 'hybrid': >>>>>>>> A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is >>>>>>>> used for encrypting new objects stored into PKCS#11 token. Each key >>>>>>>> stored in >>>>>>>> the token has own wrappingKeyId attribute and it is used for decryption. >>>>>>>> - Decryption is easy - the same as in previous case. >>>>>>>> - Encryption always use wrappingKeyId associated with given token. >>>>>>>> - Key roll over can start from wrappingKeyId associated with the token and >>>>>>>> then re-encrypt keys in the token one by one. All keys can be decrypted >>>>>>>> in any >>>>>>>> step (assuming that changes in one LDAP object are atomic). >>>>>>>> >>>>>>>> >>>>>>>> Where is a hole in this design? :-) >>>>>>> I do not like the idea of having to add a wrappingKeyId everywhere. >>>>>>> >>>>>>> My initial though was to have a central place where wrapping keys are >>>>>>> stored, and during a rollover period you try all the keys until one >>>>>>> works or decryption fails. At the end of rollover you delete the old key >>>>>>> so you avoid the additional load. >>>>>>> >>>>>>>> Where should we store wrapping keys for users/services and DNS servers? User >>>>>>>> object or cn=dns doesn't sound like a good idea because it would defeat the >>>>>>>> purpose. >>>>>>> Indeed. And this is the biggest problem. It would be nice to have a >>>>>>> mechanism to securely transfer the key to the DNS servers w/o having to >>>>>>> store it permanently in LDAP. If we had this mechanism we'd be able to >>>>>>> apply it to the Kerberos master key too. But it can't be confined to >>>>>>> installation time only, which is easy, it needs to be possible to update >>>>>>> it at a later time, which is where we have issues, as our replication >>>>>>> mechanism is LDAP. >>>>>>> >>>>>>> If we solve the DNA plugin issue with the ability to use groups for >>>>>>> authentication I guess we could build a control/extend operation that >>>>>>> would allow masters to transfer keys to each other w/o exposing them as >>>>>>> LDAP searches, do we want to try to go in that direction ? >>>>>>> >>>>>>> Simo. >>>>>>> >>>>>> Should we consider "vault" as a storage for these keys too? >>>>>> It already supports recovery of the symmetric and asymmetric keys so may be >>>>>> these keys should be stored there? >>>>> >>>>> Maybe. The question is if we want to support DNSSEC without Dogtag ... >>>>> >>>> Without Dogtag? Vault would be an independent component from CA I assume, >>>> though CA might be needed anyways to issue transport keys for the internal >>>> components. >>>> But I think that even if we use Vault as an internal password and key storage >>>> I do not see a reason why we can't require it for DNSSEC. >>>> Why over-complicate things if we already have components that can be used? If >>>> we see a requests to support DNSSEC without Vault component we will adjust but >>>> I do not think we should limit ourselves in the first implementation. >>> >>> I'm personally fine with that. >>> >>> Are we going to re-prioritize Password Vault from Backlog to 4.0? >>> https://fedorahosted.org/freeipa/ticket/3872 >>> >>> We need that in 4.0 timeframe for DNSSEC otherwise you need to convince Simo >>> that key wrapping is not necessary :-) >> >> For 4.0 we could document that you have to copy the keys around >> manually. And add Vault support in 4.1 ? It could work ... Can we modify ipa-replica-prepare in 4.0 to add the wrapping key to replica file to make it easier? Can the vault approach work for Kerberos master key? If not, shouldn't we design something universal instead of deferring it again and again? Another problem is that the PKCS#11 LDAP schema was designed as application-independent but now we are adding very specific key-wrapping mechanism (it is hard to believe that somebody else will implement it). Maybe we can add something like attribute 'pkcs11keyWrapMech': - key is not wrapped if it is not present - key is wrapped if it is present - value determines used mechanism (mandatory mechanism to implement is only 'none') > Actually an idea came to mind that might work well enough. > > We could store the symmetric key wrapped itself. ??? > The wrapping would be done using a public key per DNS server. > Public keys for DNS servers would be generated via certmonger in the > usual way. I don't understand, maybe it is too late for me :-) Where will the private key be stored? > The only unknown here is who adds a new wrapper wen a new server is up > and it publishes the public key in LDAP. For existing servers they can > re-wrap themselves. > > It's a few layers but should not be too hard. I don't fully understand to your proposal but I'm afraid that it will not work for ordinary IPA users. Don't forget that we want to have universal PKCS#11 storage usable even for private SSH keys and other stuff. Please correct me if I'm wrong. -- Petr^2 Spacek From pspacek at redhat.com Tue Mar 4 20:39:50 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Mar 2014 21:39:50 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <531636C5.6010304@redhat.com> References: <52FD02B7.3060404@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@red! hat.com> Message-ID: <53163A16.3090908@redhat.com> On 4.3.2014 21:25, Petr Spacek wrote: > On 4.3.2014 20:48, Simo Sorce wrote: >> On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: >>> On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: >>>> On 4.3.2014 17:43, Dmitri Pal wrote: >>>>> On 03/04/2014 11:25 AM, Petr Spacek wrote: >>>>>> On 4.3.2014 17:00, Dmitri Pal wrote: >>>>>>> On 03/04/2014 10:26 AM, Simo Sorce wrote: >>>>>>>> On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: >>>>>>>>> On 26.2.2014 16:00, Simo Sorce wrote: >>>>>>>>>>>>> need to be protected as carefully as the private key. >>>>>>>>>>>>>> This is something I meant to discuss too, how do we protect them ? >>>>>>>>>>>>>> Clearly we have ACIs but I am wondering if we want to encrypt >>>>>>>>>>>>>> them with >>>>>>>>>>>>>> keys not immediately or easily available via LDAP ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> It's kind of catastrofic if they get inadvertently exposed like if >>>>>>>>>>>>>> someone does a ldapsearch as "Directory Manager", which is one >>>>>>>>>>>>>> of the >>>>>>>>>>>>>> reasons why we encrypt kerberos key material before storing it >>>>>>>>>>>>>> into the >>>>>>>>>>>>>> db. >>>>>>>>>>>> PKCS#8 allows encryption, I guess we can use that. There needs to be >>>>>>>>>>>> some metadata on how to decrypt the blob though, so that the PKCS#11 >>>>>>>>>>>> module can actually decrypt it when necessary. >>>>>>>>>> Yep, and we also need to decide what master key is used and where it is >>>>>>>>>> placed, and who access it, and how:-) >>>>>>>>> Let's move the discussion forward, we need to implement the schema >>>>>>>>> for 4.0. >>>>>>>>> >>>>>>>>> Do I understand correctly that the whole purpose of >>>>>>>>> krbPrincipalName=K/M at IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example >>>>>>>>> >>>>>>>>> >>>>>>>>> is just to encrypt keys with some other key which is located at some >>>>>>>>> other >>>>>>>>> place? I.e. the goal is to lower the probability that a random >>>>>>>>> ldapsearch >>>>>>>>> will >>>>>>>>> return encrypted blob and master key at once, right? >>>>>>>> Yes, it would also be nice if we could finally offload this key from >>>>>>>> LDAP for added security, but we are not there yet. >>>>>>>> >>>>>>>>> What algorithm/method should we use for key wrapping? As far as I >>>>>>>>> remember >>>>>>>>> from my studies key wrapping is very sensitive thing and we definitely >>>>>>>>> need to >>>>>>>>> use some existing standard&tool for doing it. Can we just call some NSS >>>>>>>>> function with default/system-wide parameters and let it do it's job? >>>>>>>> I think that would be what we want to do in some form. >>>>>>>> >>>>>>>>> That would mean that, after all, we just need to provide some blob as >>>>>>>>> key >>>>>>>>> wrapping key :-) (Generated with care it deserves etc.) >>>>>>>> The key must be self describing somehow (for algorithm agility). >>>>>>>> >>>>>>>> >>>>>>>>> We have had discussion with Honza and the first idea is to add attribute >>>>>>>>> like >>>>>>>>> 'wrappingKeyId' to each encrypted blob and use it for locating >>>>>>>>> appropriate key >>>>>>>>> when necessary. >>>>>>>>> - During decryption: Do a LDAP search with filter like >>>>>>>>> (keyId=) >>>>>>>>> to find appropriate wrapping key. >>>>>>>>> - The harder part is how to pick a wrapping key for encryption. It >>>>>>>>> can be >>>>>>>>> tricky if the wrapped key is shared among more users (DNS servers) etc. >>>>>>>>> - It is possible to easily use multiple wrapping keys at once so key >>>>>>>>> rollover >>>>>>>>> is easy. You can re-encrypt keys one by one. >>>>>>>> This makes things complicated fast. >>>>>>>> One thing I was thinking was to use a keytab and krb functions to do the >>>>>>>> wrapping but that would be pretty IPA specific. >>>>>>>> >>>>>>>>> The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all >>>>>>>>> PKCS#11 >>>>>>>>> objects inside the same token will be encrypted with the same key. >>>>>>>>> - Decryption is easy - the same as in previous case. >>>>>>>>> - Encryption is basically the same as encryption. >>>>>>>>> - Key rollover is hard. You would have to re-encrypt all keys and change >>>>>>>>> wrappingKeyId associated with given token at once - but it is impossible >>>>>>>>> because we don't have LDAP transactions. As a result, clients will be >>>>>>>>> confused >>>>>>>>> during rollover. (Consider problems with syncrepl when clients can see >>>>>>>>> changes >>>>>>>>> immediately.) >>>>>>>> Yeah this is a problem we need to address. >>>>>>>> >>>>>>>>> The third approach is 'hybrid': >>>>>>>>> A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' >>>>>>>>> and is >>>>>>>>> used for encrypting new objects stored into PKCS#11 token. Each key >>>>>>>>> stored in >>>>>>>>> the token has own wrappingKeyId attribute and it is used for decryption. >>>>>>>>> - Decryption is easy - the same as in previous case. >>>>>>>>> - Encryption always use wrappingKeyId associated with given token. >>>>>>>>> - Key roll over can start from wrappingKeyId associated with the >>>>>>>>> token and >>>>>>>>> then re-encrypt keys in the token one by one. All keys can be decrypted >>>>>>>>> in any >>>>>>>>> step (assuming that changes in one LDAP object are atomic). >>>>>>>>> >>>>>>>>> >>>>>>>>> Where is a hole in this design? :-) >>>>>>>> I do not like the idea of having to add a wrappingKeyId everywhere. >>>>>>>> >>>>>>>> My initial though was to have a central place where wrapping keys are >>>>>>>> stored, and during a rollover period you try all the keys until one >>>>>>>> works or decryption fails. At the end of rollover you delete the old key >>>>>>>> so you avoid the additional load. >>>>>>>> >>>>>>>>> Where should we store wrapping keys for users/services and DNS >>>>>>>>> servers? User >>>>>>>>> object or cn=dns doesn't sound like a good idea because it would >>>>>>>>> defeat the >>>>>>>>> purpose. >>>>>>>> Indeed. And this is the biggest problem. It would be nice to have a >>>>>>>> mechanism to securely transfer the key to the DNS servers w/o having to >>>>>>>> store it permanently in LDAP. If we had this mechanism we'd be able to >>>>>>>> apply it to the Kerberos master key too. But it can't be confined to >>>>>>>> installation time only, which is easy, it needs to be possible to update >>>>>>>> it at a later time, which is where we have issues, as our replication >>>>>>>> mechanism is LDAP. >>>>>>>> >>>>>>>> If we solve the DNA plugin issue with the ability to use groups for >>>>>>>> authentication I guess we could build a control/extend operation that >>>>>>>> would allow masters to transfer keys to each other w/o exposing them as >>>>>>>> LDAP searches, do we want to try to go in that direction ? >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>> Should we consider "vault" as a storage for these keys too? >>>>>>> It already supports recovery of the symmetric and asymmetric keys so >>>>>>> may be >>>>>>> these keys should be stored there? >>>>>> >>>>>> Maybe. The question is if we want to support DNSSEC without Dogtag ... >>>>>> >>>>> Without Dogtag? Vault would be an independent component from CA I assume, >>>>> though CA might be needed anyways to issue transport keys for the internal >>>>> components. >>>>> But I think that even if we use Vault as an internal password and key >>>>> storage >>>>> I do not see a reason why we can't require it for DNSSEC. >>>>> Why over-complicate things if we already have components that can be >>>>> used? If >>>>> we see a requests to support DNSSEC without Vault component we will >>>>> adjust but >>>>> I do not think we should limit ourselves in the first implementation. >>>> >>>> I'm personally fine with that. >>>> >>>> Are we going to re-prioritize Password Vault from Backlog to 4.0? >>>> https://fedorahosted.org/freeipa/ticket/3872 >>>> >>>> We need that in 4.0 timeframe for DNSSEC otherwise you need to convince Simo >>>> that key wrapping is not necessary :-) >>> >>> For 4.0 we could document that you have to copy the keys around >>> manually. And add Vault support in 4.1 ? > It could work ... Can we modify ipa-replica-prepare in 4.0 to add the wrapping > key to replica file to make it easier? Where are we going to store private keys for DNS services (for vault)? > Can the vault approach work for Kerberos master key? If not, shouldn't we > design something universal instead of deferring it again and again? > > Another problem is that the PKCS#11 LDAP schema was designed as > application-independent but now we are adding very specific key-wrapping > mechanism (it is hard to believe that somebody else will implement it). > > Maybe we can add something like attribute 'pkcs11keyWrapMech': > - key is not wrapped if it is not present > - key is wrapped if it is present - value determines used mechanism (mandatory > mechanism to implement is only 'none') > >> Actually an idea came to mind that might work well enough. >> >> We could store the symmetric key wrapped itself. > ??? > >> The wrapping would be done using a public key per DNS server. >> Public keys for DNS servers would be generated via certmonger in the >> usual way. > I don't understand, maybe it is too late for me :-) > > Where will the private key be stored? > >> The only unknown here is who adds a new wrapper wen a new server is up >> and it publishes the public key in LDAP. For existing servers they can >> re-wrap themselves. >> >> It's a few layers but should not be too hard. > I don't fully understand to your proposal but I'm afraid that it will not work > for ordinary IPA users. Don't forget that we want to have universal PKCS#11 > storage usable even for private SSH keys and other stuff. > > Please correct me if I'm wrong. I guess that you mean something like http://www.freeipa.org/page/V4/Password_Vault#Service_Workflows , right? -- Petr^2 Spacek From simo at redhat.com Tue Mar 4 21:15:54 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 04 Mar 2014 16:15:54 -0500 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <531636C5.6010304@redhat.com> References: <52FD02B7.3060404@redhat.com> <53036B7F.2030806@redhat.com> <530B36E2.9050101@redhat.com> <1393269646.22754.410.camel@willson.li.ssimo.org> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> Message-ID: <1393967754.22047.97.camel@willson.li.ssimo.org> On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: > On 4.3.2014 20:48, Simo Sorce wrote: > > On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: > >> On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: > >>> On 4.3.2014 17:43, Dmitri Pal wrote: > >>>> On 03/04/2014 11:25 AM, Petr Spacek wrote: > >>>>> On 4.3.2014 17:00, Dmitri Pal wrote: > >>>>>> On 03/04/2014 10:26 AM, Simo Sorce wrote: > >>>>>>> On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: > >>>>>>>> On 26.2.2014 16:00, Simo Sorce wrote: > >>>>>>>>>>>> need to be protected as carefully as the private key. > >>>>>>>>>>>>> This is something I meant to discuss too, how do we protect them ? > >>>>>>>>>>>>> Clearly we have ACIs but I am wondering if we want to encrypt them with > >>>>>>>>>>>>> keys not immediately or easily available via LDAP ? > >>>>>>>>>>>>> > >>>>>>>>>>>>> It's kind of catastrofic if they get inadvertently exposed like if > >>>>>>>>>>>>> someone does a ldapsearch as "Directory Manager", which is one of the > >>>>>>>>>>>>> reasons why we encrypt kerberos key material before storing it into the > >>>>>>>>>>>>> db. > >>>>>>>>>>> PKCS#8 allows encryption, I guess we can use that. There needs to be > >>>>>>>>>>> some metadata on how to decrypt the blob though, so that the PKCS#11 > >>>>>>>>>>> module can actually decrypt it when necessary. > >>>>>>>>> Yep, and we also need to decide what master key is used and where it is > >>>>>>>>> placed, and who access it, and how:-) > >>>>>>>> Let's move the discussion forward, we need to implement the schema for 4.0. > >>>>>>>> > >>>>>>>> Do I understand correctly that the whole purpose of > >>>>>>>> krbPrincipalName=K/M at IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example > >>>>>>>> > >>>>>>>> is just to encrypt keys with some other key which is located at some other > >>>>>>>> place? I.e. the goal is to lower the probability that a random ldapsearch > >>>>>>>> will > >>>>>>>> return encrypted blob and master key at once, right? > >>>>>>> Yes, it would also be nice if we could finally offload this key from > >>>>>>> LDAP for added security, but we are not there yet. > >>>>>>> > >>>>>>>> What algorithm/method should we use for key wrapping? As far as I remember > >>>>>>>> from my studies key wrapping is very sensitive thing and we definitely > >>>>>>>> need to > >>>>>>>> use some existing standard&tool for doing it. Can we just call some NSS > >>>>>>>> function with default/system-wide parameters and let it do it's job? > >>>>>>> I think that would be what we want to do in some form. > >>>>>>> > >>>>>>>> That would mean that, after all, we just need to provide some blob as key > >>>>>>>> wrapping key :-) (Generated with care it deserves etc.) > >>>>>>> The key must be self describing somehow (for algorithm agility). > >>>>>>> > >>>>>>> > >>>>>>>> We have had discussion with Honza and the first idea is to add attribute > >>>>>>>> like > >>>>>>>> 'wrappingKeyId' to each encrypted blob and use it for locating > >>>>>>>> appropriate key > >>>>>>>> when necessary. > >>>>>>>> - During decryption: Do a LDAP search with filter like > >>>>>>>> (keyId=) > >>>>>>>> to find appropriate wrapping key. > >>>>>>>> - The harder part is how to pick a wrapping key for encryption. It can be > >>>>>>>> tricky if the wrapped key is shared among more users (DNS servers) etc. > >>>>>>>> - It is possible to easily use multiple wrapping keys at once so key > >>>>>>>> rollover > >>>>>>>> is easy. You can re-encrypt keys one by one. > >>>>>>> This makes things complicated fast. > >>>>>>> One thing I was thinking was to use a keytab and krb functions to do the > >>>>>>> wrapping but that would be pretty IPA specific. > >>>>>>> > >>>>>>>> The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 > >>>>>>>> objects inside the same token will be encrypted with the same key. > >>>>>>>> - Decryption is easy - the same as in previous case. > >>>>>>>> - Encryption is basically the same as encryption. > >>>>>>>> - Key rollover is hard. You would have to re-encrypt all keys and change > >>>>>>>> wrappingKeyId associated with given token at once - but it is impossible > >>>>>>>> because we don't have LDAP transactions. As a result, clients will be > >>>>>>>> confused > >>>>>>>> during rollover. (Consider problems with syncrepl when clients can see > >>>>>>>> changes > >>>>>>>> immediately.) > >>>>>>> Yeah this is a problem we need to address. > >>>>>>> > >>>>>>>> The third approach is 'hybrid': > >>>>>>>> A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is > >>>>>>>> used for encrypting new objects stored into PKCS#11 token. Each key > >>>>>>>> stored in > >>>>>>>> the token has own wrappingKeyId attribute and it is used for decryption. > >>>>>>>> - Decryption is easy - the same as in previous case. > >>>>>>>> - Encryption always use wrappingKeyId associated with given token. > >>>>>>>> - Key roll over can start from wrappingKeyId associated with the token and > >>>>>>>> then re-encrypt keys in the token one by one. All keys can be decrypted > >>>>>>>> in any > >>>>>>>> step (assuming that changes in one LDAP object are atomic). > >>>>>>>> > >>>>>>>> > >>>>>>>> Where is a hole in this design? :-) > >>>>>>> I do not like the idea of having to add a wrappingKeyId everywhere. > >>>>>>> > >>>>>>> My initial though was to have a central place where wrapping keys are > >>>>>>> stored, and during a rollover period you try all the keys until one > >>>>>>> works or decryption fails. At the end of rollover you delete the old key > >>>>>>> so you avoid the additional load. > >>>>>>> > >>>>>>>> Where should we store wrapping keys for users/services and DNS servers? User > >>>>>>>> object or cn=dns doesn't sound like a good idea because it would defeat the > >>>>>>>> purpose. > >>>>>>> Indeed. And this is the biggest problem. It would be nice to have a > >>>>>>> mechanism to securely transfer the key to the DNS servers w/o having to > >>>>>>> store it permanently in LDAP. If we had this mechanism we'd be able to > >>>>>>> apply it to the Kerberos master key too. But it can't be confined to > >>>>>>> installation time only, which is easy, it needs to be possible to update > >>>>>>> it at a later time, which is where we have issues, as our replication > >>>>>>> mechanism is LDAP. > >>>>>>> > >>>>>>> If we solve the DNA plugin issue with the ability to use groups for > >>>>>>> authentication I guess we could build a control/extend operation that > >>>>>>> would allow masters to transfer keys to each other w/o exposing them as > >>>>>>> LDAP searches, do we want to try to go in that direction ? > >>>>>>> > >>>>>>> Simo. > >>>>>>> > >>>>>> Should we consider "vault" as a storage for these keys too? > >>>>>> It already supports recovery of the symmetric and asymmetric keys so may be > >>>>>> these keys should be stored there? > >>>>> > >>>>> Maybe. The question is if we want to support DNSSEC without Dogtag ... > >>>>> > >>>> Without Dogtag? Vault would be an independent component from CA I assume, > >>>> though CA might be needed anyways to issue transport keys for the internal > >>>> components. > >>>> But I think that even if we use Vault as an internal password and key storage > >>>> I do not see a reason why we can't require it for DNSSEC. > >>>> Why over-complicate things if we already have components that can be used? If > >>>> we see a requests to support DNSSEC without Vault component we will adjust but > >>>> I do not think we should limit ourselves in the first implementation. > >>> > >>> I'm personally fine with that. > >>> > >>> Are we going to re-prioritize Password Vault from Backlog to 4.0? > >>> https://fedorahosted.org/freeipa/ticket/3872 > >>> > >>> We need that in 4.0 timeframe for DNSSEC otherwise you need to convince Simo > >>> that key wrapping is not necessary :-) > >> > >> For 4.0 we could document that you have to copy the keys around > >> manually. And add Vault support in 4.1 ? > It could work ... Can we modify ipa-replica-prepare in 4.0 to add the wrapping > key to replica file to make it easier? > > Can the vault approach work for Kerberos master key? If not, shouldn't we > design something universal instead of deferring it again and again? We can use the same method for the M/K, now that the CA is installed before the rest we do not have a chicken-egg issue anymore. > Another problem is that the PKCS#11 LDAP schema was designed as > application-independent but now we are adding very specific key-wrapping > mechanism (it is hard to believe that somebody else will implement it). It could be optional. > Maybe we can add something like attribute 'pkcs11keyWrapMech': > - key is not wrapped if it is not present > - key is wrapped if it is present - value determines used mechanism (mandatory > mechanism to implement is only 'none') What is 'none' ? > > Actually an idea came to mind that might work well enough. > > > > We could store the symmetric key wrapped itself. > ??? > > > The wrapping would be done using a public key per DNS server. > > Public keys for DNS servers would be generated via certmonger in the > > usual way. > I don't understand, maybe it is too late for me :-) > > Where will the private key be stored? On the file system, just like with other certificates. > > The only unknown here is who adds a new wrapper wen a new server is up > > and it publishes the public key in LDAP. For existing servers they can > > re-wrap themselves. > > > > It's a few layers but should not be too hard. > I don't fully understand to your proposal but I'm afraid that it will not work > for ordinary IPA users. Don't forget that we want to have universal PKCS#11 > storage usable even for private SSH keys and other stuff. Well ... TBH I am not really that hot about storing private keys in IPA like that, however for people that want to do it they can simply store them not encrypted as you proposed above. > Please correct me if I'm wrong. You are right, but I was caring for the DNS keys case, not the user's ssh key case, which is hairy IMHO. I think the private ssh key case is a clear job for the Vault the fact sssd might use a pkcs#11 interface to present it to ssh, or the user simply pulls it to the local file system is, in my view, an implementation detail. Although I realize I have not said it explicitly before I am not all that happy to have a generic pkcs#11 storage in IPA. Storing *arbitrary private* keys in my mind is clearly the job of DRM which has been built with that specific use case in mind and has all the appropriate protections. Putting unencrypted private keys in the IPA tree is IMHO a too high risk. I am not against creating a generic schema if we think it may be useful for others, but the more I thin of it the less I think we should use it for anything but DNS keys and they should be definitely encrypted in LDAP and the DNS server machines should be the only ones able to decrypt them. A casual search with directory manager should never yield private keys. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Tue Mar 4 21:38:16 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Mar 2014 22:38:16 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <1393967754.22047.97.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> Message-ID: <531647C8.5090807@redhat.com> On 4.3.2014 22:15, Simo Sorce wrote: > On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: >> On 4.3.2014 20:48, Simo Sorce wrote: >>> On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: >>>> On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: >>>>> On 4.3.2014 17:43, Dmitri Pal wrote: >>>>>> On 03/04/2014 11:25 AM, Petr Spacek wrote: >>>>>>> On 4.3.2014 17:00, Dmitri Pal wrote: >>>>>>>> On 03/04/2014 10:26 AM, Simo Sorce wrote: >>>>>>>>> On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: >>>>>>>>>> On 26.2.2014 16:00, Simo Sorce wrote: >>>>>>>>>>>>>> need to be protected as carefully as the private key. >>>>>>>>>>>>>>> This is something I meant to discuss too, how do we protect them ? >>>>>>>>>>>>>>> Clearly we have ACIs but I am wondering if we want to encrypt them with >>>>>>>>>>>>>>> keys not immediately or easily available via LDAP ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It's kind of catastrofic if they get inadvertently exposed like if >>>>>>>>>>>>>>> someone does a ldapsearch as "Directory Manager", which is one of the >>>>>>>>>>>>>>> reasons why we encrypt kerberos key material before storing it into the >>>>>>>>>>>>>>> db. >>>>>>>>>>>>> PKCS#8 allows encryption, I guess we can use that. There needs to be >>>>>>>>>>>>> some metadata on how to decrypt the blob though, so that the PKCS#11 >>>>>>>>>>>>> module can actually decrypt it when necessary. >>>>>>>>>>> Yep, and we also need to decide what master key is used and where it is >>>>>>>>>>> placed, and who access it, and how:-) >>>>>>>>>> Let's move the discussion forward, we need to implement the schema for 4.0. >>>>>>>>>> >>>>>>>>>> Do I understand correctly that the whole purpose of >>>>>>>>>> krbPrincipalName=K/M at IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example >>>>>>>>>> >>>>>>>>>> is just to encrypt keys with some other key which is located at some other >>>>>>>>>> place? I.e. the goal is to lower the probability that a random ldapsearch >>>>>>>>>> will >>>>>>>>>> return encrypted blob and master key at once, right? >>>>>>>>> Yes, it would also be nice if we could finally offload this key from >>>>>>>>> LDAP for added security, but we are not there yet. >>>>>>>>> >>>>>>>>>> What algorithm/method should we use for key wrapping? As far as I remember >>>>>>>>>> from my studies key wrapping is very sensitive thing and we definitely >>>>>>>>>> need to >>>>>>>>>> use some existing standard&tool for doing it. Can we just call some NSS >>>>>>>>>> function with default/system-wide parameters and let it do it's job? >>>>>>>>> I think that would be what we want to do in some form. >>>>>>>>> >>>>>>>>>> That would mean that, after all, we just need to provide some blob as key >>>>>>>>>> wrapping key :-) (Generated with care it deserves etc.) >>>>>>>>> The key must be self describing somehow (for algorithm agility). >>>>>>>>> >>>>>>>>> >>>>>>>>>> We have had discussion with Honza and the first idea is to add attribute >>>>>>>>>> like >>>>>>>>>> 'wrappingKeyId' to each encrypted blob and use it for locating >>>>>>>>>> appropriate key >>>>>>>>>> when necessary. >>>>>>>>>> - During decryption: Do a LDAP search with filter like >>>>>>>>>> (keyId=) >>>>>>>>>> to find appropriate wrapping key. >>>>>>>>>> - The harder part is how to pick a wrapping key for encryption. It can be >>>>>>>>>> tricky if the wrapped key is shared among more users (DNS servers) etc. >>>>>>>>>> - It is possible to easily use multiple wrapping keys at once so key >>>>>>>>>> rollover >>>>>>>>>> is easy. You can re-encrypt keys one by one. >>>>>>>>> This makes things complicated fast. >>>>>>>>> One thing I was thinking was to use a keytab and krb functions to do the >>>>>>>>> wrapping but that would be pretty IPA specific. >>>>>>>>> >>>>>>>>>> The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 >>>>>>>>>> objects inside the same token will be encrypted with the same key. >>>>>>>>>> - Decryption is easy - the same as in previous case. >>>>>>>>>> - Encryption is basically the same as encryption. >>>>>>>>>> - Key rollover is hard. You would have to re-encrypt all keys and change >>>>>>>>>> wrappingKeyId associated with given token at once - but it is impossible >>>>>>>>>> because we don't have LDAP transactions. As a result, clients will be >>>>>>>>>> confused >>>>>>>>>> during rollover. (Consider problems with syncrepl when clients can see >>>>>>>>>> changes >>>>>>>>>> immediately.) >>>>>>>>> Yeah this is a problem we need to address. >>>>>>>>> >>>>>>>>>> The third approach is 'hybrid': >>>>>>>>>> A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is >>>>>>>>>> used for encrypting new objects stored into PKCS#11 token. Each key >>>>>>>>>> stored in >>>>>>>>>> the token has own wrappingKeyId attribute and it is used for decryption. >>>>>>>>>> - Decryption is easy - the same as in previous case. >>>>>>>>>> - Encryption always use wrappingKeyId associated with given token. >>>>>>>>>> - Key roll over can start from wrappingKeyId associated with the token and >>>>>>>>>> then re-encrypt keys in the token one by one. All keys can be decrypted >>>>>>>>>> in any >>>>>>>>>> step (assuming that changes in one LDAP object are atomic). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Where is a hole in this design? :-) >>>>>>>>> I do not like the idea of having to add a wrappingKeyId everywhere. >>>>>>>>> >>>>>>>>> My initial though was to have a central place where wrapping keys are >>>>>>>>> stored, and during a rollover period you try all the keys until one >>>>>>>>> works or decryption fails. At the end of rollover you delete the old key >>>>>>>>> so you avoid the additional load. >>>>>>>>> >>>>>>>>>> Where should we store wrapping keys for users/services and DNS servers? User >>>>>>>>>> object or cn=dns doesn't sound like a good idea because it would defeat the >>>>>>>>>> purpose. >>>>>>>>> Indeed. And this is the biggest problem. It would be nice to have a >>>>>>>>> mechanism to securely transfer the key to the DNS servers w/o having to >>>>>>>>> store it permanently in LDAP. If we had this mechanism we'd be able to >>>>>>>>> apply it to the Kerberos master key too. But it can't be confined to >>>>>>>>> installation time only, which is easy, it needs to be possible to update >>>>>>>>> it at a later time, which is where we have issues, as our replication >>>>>>>>> mechanism is LDAP. >>>>>>>>> >>>>>>>>> If we solve the DNA plugin issue with the ability to use groups for >>>>>>>>> authentication I guess we could build a control/extend operation that >>>>>>>>> would allow masters to transfer keys to each other w/o exposing them as >>>>>>>>> LDAP searches, do we want to try to go in that direction ? >>>>>>>>> >>>>>>>>> Simo. >>>>>>>>> >>>>>>>> Should we consider "vault" as a storage for these keys too? >>>>>>>> It already supports recovery of the symmetric and asymmetric keys so may be >>>>>>>> these keys should be stored there? >>>>>>> >>>>>>> Maybe. The question is if we want to support DNSSEC without Dogtag ... >>>>>>> >>>>>> Without Dogtag? Vault would be an independent component from CA I assume, >>>>>> though CA might be needed anyways to issue transport keys for the internal >>>>>> components. >>>>>> But I think that even if we use Vault as an internal password and key storage >>>>>> I do not see a reason why we can't require it for DNSSEC. >>>>>> Why over-complicate things if we already have components that can be used? If >>>>>> we see a requests to support DNSSEC without Vault component we will adjust but >>>>>> I do not think we should limit ourselves in the first implementation. >>>>> >>>>> I'm personally fine with that. >>>>> >>>>> Are we going to re-prioritize Password Vault from Backlog to 4.0? >>>>> https://fedorahosted.org/freeipa/ticket/3872 >>>>> >>>>> We need that in 4.0 timeframe for DNSSEC otherwise you need to convince Simo >>>>> that key wrapping is not necessary :-) >>>> >>>> For 4.0 we could document that you have to copy the keys around >>>> manually. And add Vault support in 4.1 ? >> It could work ... Can we modify ipa-replica-prepare in 4.0 to add the wrapping >> key to replica file to make it easier? >> >> Can the vault approach work for Kerberos master key? If not, shouldn't we >> design something universal instead of deferring it again and again? > > We can use the same method for the M/K, now that the CA is installed > before the rest we do not have a chicken-egg issue anymore. > >> Another problem is that the PKCS#11 LDAP schema was designed as >> application-independent but now we are adding very specific key-wrapping >> mechanism (it is hard to believe that somebody else will implement it). > > It could be optional. > >> Maybe we can add something like attribute 'pkcs11keyWrapMech': >> - key is not wrapped if it is not present >> - key is wrapped if it is present - value determines used mechanism (mandatory >> mechanism to implement is only 'none') > > What is 'none' ? I mean 'attribute is not present'. >>> The only unknown here is who adds a new wrapper wen a new server is up >>> and it publishes the public key in LDAP. For existing servers they can >>> re-wrap themselves. >>> >>> It's a few layers but should not be too hard. >> I don't fully understand to your proposal but I'm afraid that it will not work >> for ordinary IPA users. Don't forget that we want to have universal PKCS#11 >> storage usable even for private SSH keys and other stuff. > > Well ... TBH I am not really that hot about storing private keys in IPA > like that, however for people that want to do it they can simply store > them not encrypted as you proposed above. > >> Please correct me if I'm wrong. > > You are right, but I was caring for the DNS keys case, not the user's > ssh key case, which is hairy IMHO. There is no difference between DNSSEC keys and any other keys except the fact that we need shared wrapping key for DNSSEC. Nothing else. Note that SSH private key is just an example. You can use PKCS#11 as storage for user certificates used for authentication in Firefox etc. > I think the private ssh key case is a clear job for the Vault the fact > sssd might use a pkcs#11 interface to present it to ssh, or the user > simply pulls it to the local file system is, in my view, an > implementation detail. I can see a huge difference. Properly implemented PKCS#11 provides you the same separation as GSS-Proxy for keytabs. I.e. non-root process will not be able to extract any private keys. Also, PKCS#11 is a standard so any application can use it. I don't like IPA-specific hacks, let's use a standard. > Although I realize I have not said it explicitly before I am not all > that happy to have a generic pkcs#11 storage in IPA. Storing *arbitrary > private* keys in my mind is clearly the job of DRM which has been built > with that specific use case in mind and has all the appropriate > protections. Putting unencrypted private keys in the IPA tree is IMHO a > too high risk. Oh wait, I think we misunderstood each other. I'm not proposing to store any keys unencrypted (in IPA)! I only want to design the LDAP schema not to be IPA-specific, nothing else. In case of IPA we can always encrypt all keys (when we have vault available). I hope this clears the misunderstanding. > I am not against creating a generic schema if we think it may be useful > for others, but the more I thin of it the less I think we should use it > for anything but DNS keys and they should be definitely encrypted in > LDAP and the DNS server machines should be the only ones able to decrypt > them. Even if all keys will be encrypted? > A casual search with directory manager should never yield private keys. It makes sense. As I said above, all keys should be encrypted when the proposed schema will be used as part of IPA. Anyway, should we use vault for key storage from the beginning and do not spend time on a throw-away schema design etc.? I can see the reasoning and we don't need two mechanisms for the same thing. -- Petr^2 Spacek From simo at redhat.com Tue Mar 4 21:53:53 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 04 Mar 2014 16:53:53 -0500 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <531647C8.5090807@redhat.com> References: <52FD02B7.3060404@redhat.com> <530C7063.7080706@redhat.com> <1393335855.18299.8.camel@willson.li.ssimo.org> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> Message-ID: <1393970034.22047.109.camel@willson.li.ssimo.org> On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: > On 4.3.2014 22:15, Simo Sorce wrote: > > On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: > >> On 4.3.2014 20:48, Simo Sorce wrote: > >>> On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: > >>>> On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: > >>>>> On 4.3.2014 17:43, Dmitri Pal wrote: > >>>>>> On 03/04/2014 11:25 AM, Petr Spacek wrote: > >>>>>>> On 4.3.2014 17:00, Dmitri Pal wrote: > >>>>>>>> On 03/04/2014 10:26 AM, Simo Sorce wrote: > >>>>>>>>> On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: > >>>>>>>>>> On 26.2.2014 16:00, Simo Sorce wrote: > >>>>>>>>>>>>>> need to be protected as carefully as the private key. > >>>>>>>>>>>>>>> This is something I meant to discuss too, how do we protect them ? > >>>>>>>>>>>>>>> Clearly we have ACIs but I am wondering if we want to encrypt them with > >>>>>>>>>>>>>>> keys not immediately or easily available via LDAP ? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> It's kind of catastrofic if they get inadvertently exposed like if > >>>>>>>>>>>>>>> someone does a ldapsearch as "Directory Manager", which is one of the > >>>>>>>>>>>>>>> reasons why we encrypt kerberos key material before storing it into the > >>>>>>>>>>>>>>> db. > >>>>>>>>>>>>> PKCS#8 allows encryption, I guess we can use that. There needs to be > >>>>>>>>>>>>> some metadata on how to decrypt the blob though, so that the PKCS#11 > >>>>>>>>>>>>> module can actually decrypt it when necessary. > >>>>>>>>>>> Yep, and we also need to decide what master key is used and where it is > >>>>>>>>>>> placed, and who access it, and how:-) > >>>>>>>>>> Let's move the discussion forward, we need to implement the schema for 4.0. > >>>>>>>>>> > >>>>>>>>>> Do I understand correctly that the whole purpose of > >>>>>>>>>> krbPrincipalName=K/M at IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example > >>>>>>>>>> > >>>>>>>>>> is just to encrypt keys with some other key which is located at some other > >>>>>>>>>> place? I.e. the goal is to lower the probability that a random ldapsearch > >>>>>>>>>> will > >>>>>>>>>> return encrypted blob and master key at once, right? > >>>>>>>>> Yes, it would also be nice if we could finally offload this key from > >>>>>>>>> LDAP for added security, but we are not there yet. > >>>>>>>>> > >>>>>>>>>> What algorithm/method should we use for key wrapping? As far as I remember > >>>>>>>>>> from my studies key wrapping is very sensitive thing and we definitely > >>>>>>>>>> need to > >>>>>>>>>> use some existing standard&tool for doing it. Can we just call some NSS > >>>>>>>>>> function with default/system-wide parameters and let it do it's job? > >>>>>>>>> I think that would be what we want to do in some form. > >>>>>>>>> > >>>>>>>>>> That would mean that, after all, we just need to provide some blob as key > >>>>>>>>>> wrapping key :-) (Generated with care it deserves etc.) > >>>>>>>>> The key must be self describing somehow (for algorithm agility). > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> We have had discussion with Honza and the first idea is to add attribute > >>>>>>>>>> like > >>>>>>>>>> 'wrappingKeyId' to each encrypted blob and use it for locating > >>>>>>>>>> appropriate key > >>>>>>>>>> when necessary. > >>>>>>>>>> - During decryption: Do a LDAP search with filter like > >>>>>>>>>> (keyId=) > >>>>>>>>>> to find appropriate wrapping key. > >>>>>>>>>> - The harder part is how to pick a wrapping key for encryption. It can be > >>>>>>>>>> tricky if the wrapped key is shared among more users (DNS servers) etc. > >>>>>>>>>> - It is possible to easily use multiple wrapping keys at once so key > >>>>>>>>>> rollover > >>>>>>>>>> is easy. You can re-encrypt keys one by one. > >>>>>>>>> This makes things complicated fast. > >>>>>>>>> One thing I was thinking was to use a keytab and krb functions to do the > >>>>>>>>> wrapping but that would be pretty IPA specific. > >>>>>>>>> > >>>>>>>>>> The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 > >>>>>>>>>> objects inside the same token will be encrypted with the same key. > >>>>>>>>>> - Decryption is easy - the same as in previous case. > >>>>>>>>>> - Encryption is basically the same as encryption. > >>>>>>>>>> - Key rollover is hard. You would have to re-encrypt all keys and change > >>>>>>>>>> wrappingKeyId associated with given token at once - but it is impossible > >>>>>>>>>> because we don't have LDAP transactions. As a result, clients will be > >>>>>>>>>> confused > >>>>>>>>>> during rollover. (Consider problems with syncrepl when clients can see > >>>>>>>>>> changes > >>>>>>>>>> immediately.) > >>>>>>>>> Yeah this is a problem we need to address. > >>>>>>>>> > >>>>>>>>>> The third approach is 'hybrid': > >>>>>>>>>> A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is > >>>>>>>>>> used for encrypting new objects stored into PKCS#11 token. Each key > >>>>>>>>>> stored in > >>>>>>>>>> the token has own wrappingKeyId attribute and it is used for decryption. > >>>>>>>>>> - Decryption is easy - the same as in previous case. > >>>>>>>>>> - Encryption always use wrappingKeyId associated with given token. > >>>>>>>>>> - Key roll over can start from wrappingKeyId associated with the token and > >>>>>>>>>> then re-encrypt keys in the token one by one. All keys can be decrypted > >>>>>>>>>> in any > >>>>>>>>>> step (assuming that changes in one LDAP object are atomic). > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Where is a hole in this design? :-) > >>>>>>>>> I do not like the idea of having to add a wrappingKeyId everywhere. > >>>>>>>>> > >>>>>>>>> My initial though was to have a central place where wrapping keys are > >>>>>>>>> stored, and during a rollover period you try all the keys until one > >>>>>>>>> works or decryption fails. At the end of rollover you delete the old key > >>>>>>>>> so you avoid the additional load. > >>>>>>>>> > >>>>>>>>>> Where should we store wrapping keys for users/services and DNS servers? User > >>>>>>>>>> object or cn=dns doesn't sound like a good idea because it would defeat the > >>>>>>>>>> purpose. > >>>>>>>>> Indeed. And this is the biggest problem. It would be nice to have a > >>>>>>>>> mechanism to securely transfer the key to the DNS servers w/o having to > >>>>>>>>> store it permanently in LDAP. If we had this mechanism we'd be able to > >>>>>>>>> apply it to the Kerberos master key too. But it can't be confined to > >>>>>>>>> installation time only, which is easy, it needs to be possible to update > >>>>>>>>> it at a later time, which is where we have issues, as our replication > >>>>>>>>> mechanism is LDAP. > >>>>>>>>> > >>>>>>>>> If we solve the DNA plugin issue with the ability to use groups for > >>>>>>>>> authentication I guess we could build a control/extend operation that > >>>>>>>>> would allow masters to transfer keys to each other w/o exposing them as > >>>>>>>>> LDAP searches, do we want to try to go in that direction ? > >>>>>>>>> > >>>>>>>>> Simo. > >>>>>>>>> > >>>>>>>> Should we consider "vault" as a storage for these keys too? > >>>>>>>> It already supports recovery of the symmetric and asymmetric keys so may be > >>>>>>>> these keys should be stored there? > >>>>>>> > >>>>>>> Maybe. The question is if we want to support DNSSEC without Dogtag ... > >>>>>>> > >>>>>> Without Dogtag? Vault would be an independent component from CA I assume, > >>>>>> though CA might be needed anyways to issue transport keys for the internal > >>>>>> components. > >>>>>> But I think that even if we use Vault as an internal password and key storage > >>>>>> I do not see a reason why we can't require it for DNSSEC. > >>>>>> Why over-complicate things if we already have components that can be used? If > >>>>>> we see a requests to support DNSSEC without Vault component we will adjust but > >>>>>> I do not think we should limit ourselves in the first implementation. > >>>>> > >>>>> I'm personally fine with that. > >>>>> > >>>>> Are we going to re-prioritize Password Vault from Backlog to 4.0? > >>>>> https://fedorahosted.org/freeipa/ticket/3872 > >>>>> > >>>>> We need that in 4.0 timeframe for DNSSEC otherwise you need to convince Simo > >>>>> that key wrapping is not necessary :-) > >>>> > >>>> For 4.0 we could document that you have to copy the keys around > >>>> manually. And add Vault support in 4.1 ? > >> It could work ... Can we modify ipa-replica-prepare in 4.0 to add the wrapping > >> key to replica file to make it easier? > >> > >> Can the vault approach work for Kerberos master key? If not, shouldn't we > >> design something universal instead of deferring it again and again? > > > > We can use the same method for the M/K, now that the CA is installed > > before the rest we do not have a chicken-egg issue anymore. > > > >> Another problem is that the PKCS#11 LDAP schema was designed as > >> application-independent but now we are adding very specific key-wrapping > >> mechanism (it is hard to believe that somebody else will implement it). > > > > It could be optional. > > > >> Maybe we can add something like attribute 'pkcs11keyWrapMech': > >> - key is not wrapped if it is not present > >> - key is wrapped if it is present - value determines used mechanism (mandatory > >> mechanism to implement is only 'none') > > > > What is 'none' ? > I mean 'attribute is not present'. > > >>> The only unknown here is who adds a new wrapper wen a new server is up > >>> and it publishes the public key in LDAP. For existing servers they can > >>> re-wrap themselves. > >>> > >>> It's a few layers but should not be too hard. > >> I don't fully understand to your proposal but I'm afraid that it will not work > >> for ordinary IPA users. Don't forget that we want to have universal PKCS#11 > >> storage usable even for private SSH keys and other stuff. > > > > Well ... TBH I am not really that hot about storing private keys in IPA > > like that, however for people that want to do it they can simply store > > them not encrypted as you proposed above. > > > >> Please correct me if I'm wrong. > > > > You are right, but I was caring for the DNS keys case, not the user's > > ssh key case, which is hairy IMHO. > There is no difference between DNSSEC keys and any other keys except the fact > that we need shared wrapping key for DNSSEC. Nothing else. Note that SSH > private key is just an example. You can use PKCS#11 as storage for user > certificates used for authentication in Firefox etc. > > > I think the private ssh key case is a clear job for the Vault the fact > > sssd might use a pkcs#11 interface to present it to ssh, or the user > > simply pulls it to the local file system is, in my view, an > > implementation detail. > I can see a huge difference. Properly implemented PKCS#11 provides you the > same separation as GSS-Proxy for keytabs. I.e. non-root process will not be > able to extract any private keys. > > Also, PKCS#11 is a standard so any application can use it. I don't like > IPA-specific hacks, let's use a standard. Standards are fine. That's not the point though. > > Although I realize I have not said it explicitly before I am not all > > that happy to have a generic pkcs#11 storage in IPA. Storing *arbitrary > > private* keys in my mind is clearly the job of DRM which has been built > > with that specific use case in mind and has all the appropriate > > protections. Putting unencrypted private keys in the IPA tree is IMHO a > > too high risk. > Oh wait, I think we misunderstood each other. I'm not proposing to store any > keys unencrypted (in IPA)! I only want to design the LDAP schema not to be > IPA-specific, nothing else. > > In case of IPA we can always encrypt all keys (when we have vault available). > I hope this clears the misunderstanding. Well if the Vault is the storage, then why do we care for an LDAP schema ? I think Vault is the right storage for user custom data or application custom data. I am not sure we want to depend on the vault for DNS, because it needs high availability, however given we copy the keys on the local filesystem, once generated, perhaps the Vault is sufficient if it is a replicated system. I am not sure DRM is replicated, or will be replicated in the first incarnation, so that's why I am treating DNS differently. > > I am not against creating a generic schema if we think it may be useful > > for others, but the more I thin of it the less I think we should use it > > for anything but DNS keys and they should be definitely encrypted in > > LDAP and the DNS server machines should be the only ones able to decrypt > > them. > Even if all keys will be encrypted? ELOOP ? :) > > A casual search with directory manager should never yield private keys. > It makes sense. As I said above, all keys should be encrypted when the > proposed schema will be used as part of IPA. > > > Anyway, should we use vault for key storage from the beginning and do not > spend time on a throw-away schema design etc.? > > I can see the reasoning and we don't need two mechanisms for the same thing. Right. I guess my only reservation is about whether DRM storage is replicated or not. Although both the K/M and DNS cases do not require the Vault to be online at all times because the keys will be downloaded and stored locally and only needs to be accessed when they changed, there is the problem of having all keys in a SPOF, that should not happen. The additional thing about the Vault is that we can use key escrow there as a mechanism to re-encrypt automatically system relevant keys when a new server is joined to the realm. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Tue Mar 4 22:14:34 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Mar 2014 23:14:34 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <1393970034.22047.109.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> Message-ID: <5316504A.9090303@redhat.com> On 4.3.2014 22:53, Simo Sorce wrote: > On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: >> On 4.3.2014 22:15, Simo Sorce wrote: >>> On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: >>>> On 4.3.2014 20:48, Simo Sorce wrote: >>>>> On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: >>>>>> On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: >>>>>>> On 4.3.2014 17:43, Dmitri Pal wrote: >>>>>>>> On 03/04/2014 11:25 AM, Petr Spacek wrote: >>>>>>>>> On 4.3.2014 17:00, Dmitri Pal wrote: >>>>>>>>>> On 03/04/2014 10:26 AM, Simo Sorce wrote: >>>>>>>>>>> On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: >>>>>>>>>>>> Where should we store wrapping keys for users/services and DNS servers? User >>>>>>>>>>>> object or cn=dns doesn't sound like a good idea because it would defeat the >>>>>>>>>>>> purpose. >>>>>>>>>>> Indeed. And this is the biggest problem. It would be nice to have a >>>>>>>>>>> mechanism to securely transfer the key to the DNS servers w/o having to >>>>>>>>>>> store it permanently in LDAP. If we had this mechanism we'd be able to >>>>>>>>>>> apply it to the Kerberos master key too. But it can't be confined to >>>>>>>>>>> installation time only, which is easy, it needs to be possible to update >>>>>>>>>>> it at a later time, which is where we have issues, as our replication >>>>>>>>>>> mechanism is LDAP. >>>>>>>>>>> >>>>>>>>>>> If we solve the DNA plugin issue with the ability to use groups for >>>>>>>>>>> authentication I guess we could build a control/extend operation that >>>>>>>>>>> would allow masters to transfer keys to each other w/o exposing them as >>>>>>>>>>> LDAP searches, do we want to try to go in that direction ? >>>>>>>>>>> >>>>>>>>>>> Simo. >>>>>>>>>>> >>>>>>>>>> Should we consider "vault" as a storage for these keys too? >>>>>>>>>> It already supports recovery of the symmetric and asymmetric keys so may be >>>>>>>>>> these keys should be stored there? >>>>>>>>> >>>>>>>>> Maybe. The question is if we want to support DNSSEC without Dogtag ... >>>>>>>>> >>>>>>>> Without Dogtag? Vault would be an independent component from CA I assume, >>>>>>>> though CA might be needed anyways to issue transport keys for the internal >>>>>>>> components. >>>>>>>> But I think that even if we use Vault as an internal password and key storage >>>>>>>> I do not see a reason why we can't require it for DNSSEC. >>>>>>>> Why over-complicate things if we already have components that can be used? If >>>>>>>> we see a requests to support DNSSEC without Vault component we will adjust but >>>>>>>> I do not think we should limit ourselves in the first implementation. >>>>>>> >>>>>>> I'm personally fine with that. >>>>>>> >>>>>>> Are we going to re-prioritize Password Vault from Backlog to 4.0? >>>>>>> https://fedorahosted.org/freeipa/ticket/3872 >>>>>>> >>>>>>> We need that in 4.0 timeframe for DNSSEC otherwise you need to convince Simo >>>>>>> that key wrapping is not necessary :-) >>>>>> >>>>>> For 4.0 we could document that you have to copy the keys around >>>>>> manually. And add Vault support in 4.1 ? >>>> It could work ... Can we modify ipa-replica-prepare in 4.0 to add the wrapping >>>> key to replica file to make it easier? >>>> >>>> Can the vault approach work for Kerberos master key? If not, shouldn't we >>>> design something universal instead of deferring it again and again? >>> >>> We can use the same method for the M/K, now that the CA is installed >>> before the rest we do not have a chicken-egg issue anymore. >>> >>>> Another problem is that the PKCS#11 LDAP schema was designed as >>>> application-independent but now we are adding very specific key-wrapping >>>> mechanism (it is hard to believe that somebody else will implement it). >>> >>> It could be optional. >>> >>>> Maybe we can add something like attribute 'pkcs11keyWrapMech': >>>> - key is not wrapped if it is not present >>>> - key is wrapped if it is present - value determines used mechanism (mandatory >>>> mechanism to implement is only 'none') >>> >>> What is 'none' ? >> I mean 'attribute is not present'. >> >>>>> The only unknown here is who adds a new wrapper wen a new server is up >>>>> and it publishes the public key in LDAP. For existing servers they can >>>>> re-wrap themselves. >>>>> >>>>> It's a few layers but should not be too hard. >>>> I don't fully understand to your proposal but I'm afraid that it will not work >>>> for ordinary IPA users. Don't forget that we want to have universal PKCS#11 >>>> storage usable even for private SSH keys and other stuff. >>> >>> Well ... TBH I am not really that hot about storing private keys in IPA >>> like that, however for people that want to do it they can simply store >>> them not encrypted as you proposed above. >>> >>>> Please correct me if I'm wrong. >>> >>> You are right, but I was caring for the DNS keys case, not the user's >>> ssh key case, which is hairy IMHO. >> There is no difference between DNSSEC keys and any other keys except the fact >> that we need shared wrapping key for DNSSEC. Nothing else. Note that SSH >> private key is just an example. You can use PKCS#11 as storage for user >> certificates used for authentication in Firefox etc. >> >>> I think the private ssh key case is a clear job for the Vault the fact >>> sssd might use a pkcs#11 interface to present it to ssh, or the user >>> simply pulls it to the local file system is, in my view, an >>> implementation detail. >> I can see a huge difference. Properly implemented PKCS#11 provides you the >> same separation as GSS-Proxy for keytabs. I.e. non-root process will not be >> able to extract any private keys. >> >> Also, PKCS#11 is a standard so any application can use it. I don't like >> IPA-specific hacks, let's use a standard. > > Standards are fine. That's not the point though. > >>> Although I realize I have not said it explicitly before I am not all >>> that happy to have a generic pkcs#11 storage in IPA. Storing *arbitrary >>> private* keys in my mind is clearly the job of DRM which has been built >>> with that specific use case in mind and has all the appropriate >>> protections. Putting unencrypted private keys in the IPA tree is IMHO a >>> too high risk. >> Oh wait, I think we misunderstood each other. I'm not proposing to store any >> keys unencrypted (in IPA)! I only want to design the LDAP schema not to be >> IPA-specific, nothing else. >> >> In case of IPA we can always encrypt all keys (when we have vault available). >> I hope this clears the misunderstanding. > > Well if the Vault is the storage, then why do we care for an LDAP > schema ? We need PKCS#11 for CA certificates, BIND and OpenDNSSEC anyway so we need to design schema for *public* data. All private data can be stored in Vault if we agree on that. In theory, we can use proposed schema for PKCS#11 key storage and just replace private key attributes with an reference to vault and we are done. > I think Vault is the right storage for user custom data or application > custom data. > > I am not sure we want to depend on the vault for DNS, because it needs > high availability, however given we copy the keys on the local > filesystem, once generated, perhaps the Vault is sufficient if it is a > replicated system. I am not sure DRM is replicated, or will be > replicated in the first incarnation, so that's why I am treating DNS > differently. > >>> I am not against creating a generic schema if we think it may be useful >>> for others, but the more I thin of it the less I think we should use it >>> for anything but DNS keys and they should be definitely encrypted in >>> LDAP and the DNS server machines should be the only ones able to decrypt >>> them. >> Even if all keys will be encrypted? > > ELOOP ? :) > >>> A casual search with directory manager should never yield private keys. >> It makes sense. As I said above, all keys should be encrypted when the >> proposed schema will be used as part of IPA. >> >> >> Anyway, should we use vault for key storage from the beginning and do not >> spend time on a throw-away schema design etc.? >> >> I can see the reasoning and we don't need two mechanisms for the same thing. > > Right. > > I guess my only reservation is about whether DRM storage is replicated > or not. Although both the K/M and DNS cases do not require the Vault to > be online at all times because the keys will be downloaded and stored > locally and only needs to be accessed when they changed, there is the > problem of having all keys in a SPOF, that should not happen. According to http://www.freeipa.org/page/V4/Password_Vault#Replication the replication is available for DRM, we just need to use it. IMHO a vault without replication is not useful anyway. Users are not happy when their passwords disappear ;-) > The additional thing about the Vault is that we can use key escrow there > as a mechanism to re-encrypt automatically system relevant keys when a > new server is joined to the realm. So we agree that Vault offers what we want so we should use it, right? I think we should determine if we can use Vault for K/M. It would be another reason why we should use Vault instead of a custom solution. -- Petr^2 Spacek From dpal at redhat.com Tue Mar 4 22:16:53 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 04 Mar 2014 17:16:53 -0500 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <1393970034.22047.109.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <530CA08E.2060304@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> Message-ID: <531650D5.20109@redhat.com> On 03/04/2014 04:53 PM, Simo Sorce wrote: > On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: >> On 4.3.2014 22:15, Simo Sorce wrote: >>> On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: >>>> On 4.3.2014 20:48, Simo Sorce wrote: >>>>> On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: >>>>>> On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: >>>>>>> On 4.3.2014 17:43, Dmitri Pal wrote: >>>>>>>> On 03/04/2014 11:25 AM, Petr Spacek wrote: >>>>>>>>> On 4.3.2014 17:00, Dmitri Pal wrote: >>>>>>>>>> On 03/04/2014 10:26 AM, Simo Sorce wrote: >>>>>>>>>>> On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: >>>>>>>>>>>> On 26.2.2014 16:00, Simo Sorce wrote: >>>>>>>>>>>>>>>> need to be protected as carefully as the private key. >>>>>>>>>>>>>>>>> This is something I meant to discuss too, how do we protect them ? >>>>>>>>>>>>>>>>> Clearly we have ACIs but I am wondering if we want to encrypt them with >>>>>>>>>>>>>>>>> keys not immediately or easily available via LDAP ? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It's kind of catastrofic if they get inadvertently exposed like if >>>>>>>>>>>>>>>>> someone does a ldapsearch as "Directory Manager", which is one of the >>>>>>>>>>>>>>>>> reasons why we encrypt kerberos key material before storing it into the >>>>>>>>>>>>>>>>> db. >>>>>>>>>>>>>>> PKCS#8 allows encryption, I guess we can use that. There needs to be >>>>>>>>>>>>>>> some metadata on how to decrypt the blob though, so that the PKCS#11 >>>>>>>>>>>>>>> module can actually decrypt it when necessary. >>>>>>>>>>>>> Yep, and we also need to decide what master key is used and where it is >>>>>>>>>>>>> placed, and who access it, and how:-) >>>>>>>>>>>> Let's move the discussion forward, we need to implement the schema for 4.0. >>>>>>>>>>>> >>>>>>>>>>>> Do I understand correctly that the whole purpose of >>>>>>>>>>>> krbPrincipalName=K/M at IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example >>>>>>>>>>>> >>>>>>>>>>>> is just to encrypt keys with some other key which is located at some other >>>>>>>>>>>> place? I.e. the goal is to lower the probability that a random ldapsearch >>>>>>>>>>>> will >>>>>>>>>>>> return encrypted blob and master key at once, right? >>>>>>>>>>> Yes, it would also be nice if we could finally offload this key from >>>>>>>>>>> LDAP for added security, but we are not there yet. >>>>>>>>>>> >>>>>>>>>>>> What algorithm/method should we use for key wrapping? As far as I remember >>>>>>>>>>>> from my studies key wrapping is very sensitive thing and we definitely >>>>>>>>>>>> need to >>>>>>>>>>>> use some existing standard&tool for doing it. Can we just call some NSS >>>>>>>>>>>> function with default/system-wide parameters and let it do it's job? >>>>>>>>>>> I think that would be what we want to do in some form. >>>>>>>>>>> >>>>>>>>>>>> That would mean that, after all, we just need to provide some blob as key >>>>>>>>>>>> wrapping key :-) (Generated with care it deserves etc.) >>>>>>>>>>> The key must be self describing somehow (for algorithm agility). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> We have had discussion with Honza and the first idea is to add attribute >>>>>>>>>>>> like >>>>>>>>>>>> 'wrappingKeyId' to each encrypted blob and use it for locating >>>>>>>>>>>> appropriate key >>>>>>>>>>>> when necessary. >>>>>>>>>>>> - During decryption: Do a LDAP search with filter like >>>>>>>>>>>> (keyId=) >>>>>>>>>>>> to find appropriate wrapping key. >>>>>>>>>>>> - The harder part is how to pick a wrapping key for encryption. It can be >>>>>>>>>>>> tricky if the wrapped key is shared among more users (DNS servers) etc. >>>>>>>>>>>> - It is possible to easily use multiple wrapping keys at once so key >>>>>>>>>>>> rollover >>>>>>>>>>>> is easy. You can re-encrypt keys one by one. >>>>>>>>>>> This makes things complicated fast. >>>>>>>>>>> One thing I was thinking was to use a keytab and krb functions to do the >>>>>>>>>>> wrapping but that would be pretty IPA specific. >>>>>>>>>>> >>>>>>>>>>>> The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 >>>>>>>>>>>> objects inside the same token will be encrypted with the same key. >>>>>>>>>>>> - Decryption is easy - the same as in previous case. >>>>>>>>>>>> - Encryption is basically the same as encryption. >>>>>>>>>>>> - Key rollover is hard. You would have to re-encrypt all keys and change >>>>>>>>>>>> wrappingKeyId associated with given token at once - but it is impossible >>>>>>>>>>>> because we don't have LDAP transactions. As a result, clients will be >>>>>>>>>>>> confused >>>>>>>>>>>> during rollover. (Consider problems with syncrepl when clients can see >>>>>>>>>>>> changes >>>>>>>>>>>> immediately.) >>>>>>>>>>> Yeah this is a problem we need to address. >>>>>>>>>>> >>>>>>>>>>>> The third approach is 'hybrid': >>>>>>>>>>>> A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is >>>>>>>>>>>> used for encrypting new objects stored into PKCS#11 token. Each key >>>>>>>>>>>> stored in >>>>>>>>>>>> the token has own wrappingKeyId attribute and it is used for decryption. >>>>>>>>>>>> - Decryption is easy - the same as in previous case. >>>>>>>>>>>> - Encryption always use wrappingKeyId associated with given token. >>>>>>>>>>>> - Key roll over can start from wrappingKeyId associated with the token and >>>>>>>>>>>> then re-encrypt keys in the token one by one. All keys can be decrypted >>>>>>>>>>>> in any >>>>>>>>>>>> step (assuming that changes in one LDAP object are atomic). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Where is a hole in this design? :-) >>>>>>>>>>> I do not like the idea of having to add a wrappingKeyId everywhere. >>>>>>>>>>> >>>>>>>>>>> My initial though was to have a central place where wrapping keys are >>>>>>>>>>> stored, and during a rollover period you try all the keys until one >>>>>>>>>>> works or decryption fails. At the end of rollover you delete the old key >>>>>>>>>>> so you avoid the additional load. >>>>>>>>>>> >>>>>>>>>>>> Where should we store wrapping keys for users/services and DNS servers? User >>>>>>>>>>>> object or cn=dns doesn't sound like a good idea because it would defeat the >>>>>>>>>>>> purpose. >>>>>>>>>>> Indeed. And this is the biggest problem. It would be nice to have a >>>>>>>>>>> mechanism to securely transfer the key to the DNS servers w/o having to >>>>>>>>>>> store it permanently in LDAP. If we had this mechanism we'd be able to >>>>>>>>>>> apply it to the Kerberos master key too. But it can't be confined to >>>>>>>>>>> installation time only, which is easy, it needs to be possible to update >>>>>>>>>>> it at a later time, which is where we have issues, as our replication >>>>>>>>>>> mechanism is LDAP. >>>>>>>>>>> >>>>>>>>>>> If we solve the DNA plugin issue with the ability to use groups for >>>>>>>>>>> authentication I guess we could build a control/extend operation that >>>>>>>>>>> would allow masters to transfer keys to each other w/o exposing them as >>>>>>>>>>> LDAP searches, do we want to try to go in that direction ? >>>>>>>>>>> >>>>>>>>>>> Simo. >>>>>>>>>>> >>>>>>>>>> Should we consider "vault" as a storage for these keys too? >>>>>>>>>> It already supports recovery of the symmetric and asymmetric keys so may be >>>>>>>>>> these keys should be stored there? >>>>>>>>> Maybe. The question is if we want to support DNSSEC without Dogtag ... >>>>>>>>> >>>>>>>> Without Dogtag? Vault would be an independent component from CA I assume, >>>>>>>> though CA might be needed anyways to issue transport keys for the internal >>>>>>>> components. >>>>>>>> But I think that even if we use Vault as an internal password and key storage >>>>>>>> I do not see a reason why we can't require it for DNSSEC. >>>>>>>> Why over-complicate things if we already have components that can be used? If >>>>>>>> we see a requests to support DNSSEC without Vault component we will adjust but >>>>>>>> I do not think we should limit ourselves in the first implementation. >>>>>>> I'm personally fine with that. >>>>>>> >>>>>>> Are we going to re-prioritize Password Vault from Backlog to 4.0? >>>>>>> https://fedorahosted.org/freeipa/ticket/3872 >>>>>>> >>>>>>> We need that in 4.0 timeframe for DNSSEC otherwise you need to convince Simo >>>>>>> that key wrapping is not necessary :-) >>>>>> For 4.0 we could document that you have to copy the keys around >>>>>> manually. And add Vault support in 4.1 ? >>>> It could work ... Can we modify ipa-replica-prepare in 4.0 to add the wrapping >>>> key to replica file to make it easier? >>>> >>>> Can the vault approach work for Kerberos master key? If not, shouldn't we >>>> design something universal instead of deferring it again and again? >>> We can use the same method for the M/K, now that the CA is installed >>> before the rest we do not have a chicken-egg issue anymore. >>> >>>> Another problem is that the PKCS#11 LDAP schema was designed as >>>> application-independent but now we are adding very specific key-wrapping >>>> mechanism (it is hard to believe that somebody else will implement it). >>> It could be optional. >>> >>>> Maybe we can add something like attribute 'pkcs11keyWrapMech': >>>> - key is not wrapped if it is not present >>>> - key is wrapped if it is present - value determines used mechanism (mandatory >>>> mechanism to implement is only 'none') >>> What is 'none' ? >> I mean 'attribute is not present'. >> >>>>> The only unknown here is who adds a new wrapper wen a new server is up >>>>> and it publishes the public key in LDAP. For existing servers they can >>>>> re-wrap themselves. >>>>> >>>>> It's a few layers but should not be too hard. >>>> I don't fully understand to your proposal but I'm afraid that it will not work >>>> for ordinary IPA users. Don't forget that we want to have universal PKCS#11 >>>> storage usable even for private SSH keys and other stuff. >>> Well ... TBH I am not really that hot about storing private keys in IPA >>> like that, however for people that want to do it they can simply store >>> them not encrypted as you proposed above. >>> >>>> Please correct me if I'm wrong. >>> You are right, but I was caring for the DNS keys case, not the user's >>> ssh key case, which is hairy IMHO. >> There is no difference between DNSSEC keys and any other keys except the fact >> that we need shared wrapping key for DNSSEC. Nothing else. Note that SSH >> private key is just an example. You can use PKCS#11 as storage for user >> certificates used for authentication in Firefox etc. >> >>> I think the private ssh key case is a clear job for the Vault the fact >>> sssd might use a pkcs#11 interface to present it to ssh, or the user >>> simply pulls it to the local file system is, in my view, an >>> implementation detail. >> I can see a huge difference. Properly implemented PKCS#11 provides you the >> same separation as GSS-Proxy for keytabs. I.e. non-root process will not be >> able to extract any private keys. >> >> Also, PKCS#11 is a standard so any application can use it. I don't like >> IPA-specific hacks, let's use a standard. > Standards are fine. That's not the point though. > >>> Although I realize I have not said it explicitly before I am not all >>> that happy to have a generic pkcs#11 storage in IPA. Storing *arbitrary >>> private* keys in my mind is clearly the job of DRM which has been built >>> with that specific use case in mind and has all the appropriate >>> protections. Putting unencrypted private keys in the IPA tree is IMHO a >>> too high risk. >> Oh wait, I think we misunderstood each other. I'm not proposing to store any >> keys unencrypted (in IPA)! I only want to design the LDAP schema not to be >> IPA-specific, nothing else. >> >> In case of IPA we can always encrypt all keys (when we have vault available). >> I hope this clears the misunderstanding. > Well if the Vault is the storage, then why do we care for an LDAP > schema ? > > I think Vault is the right storage for user custom data or application > custom data. > > I am not sure we want to depend on the vault for DNS, because it needs > high availability, however given we copy the keys on the local > filesystem, once generated, perhaps the Vault is sufficient if it is a > replicated system. I am not sure DRM is replicated, or will be > replicated in the first incarnation, so that's why I am treating DNS > differently. > >>> I am not against creating a generic schema if we think it may be useful >>> for others, but the more I thin of it the less I think we should use it >>> for anything but DNS keys and they should be definitely encrypted in >>> LDAP and the DNS server machines should be the only ones able to decrypt >>> them. >> Even if all keys will be encrypted? > ELOOP ? :) > >>> A casual search with directory manager should never yield private keys. >> It makes sense. As I said above, all keys should be encrypted when the >> proposed schema will be used as part of IPA. >> >> >> Anyway, should we use vault for key storage from the beginning and do not >> spend time on a throw-away schema design etc.? >> >> I can see the reasoning and we don't need two mechanisms for the same thing. > Right. > > I guess my only reservation is about whether DRM storage is replicated > or not. Although both the K/M and DNS cases do not require the Vault to > be online at all times because the keys will be downloaded and stored > locally and only needs to be accessed when they changed, there is the > problem of having all keys in a SPOF, that should not happen. > > The additional thing about the Vault is that we can use key escrow there > as a mechanism to re-encrypt automatically system relevant keys when a > new server is joined to the realm. The DRM storage is replicated. This is the whole point. Also about PKCS#11 interface. I am all for PKCS#11 interface for client exposed from SSSD that uses whatever means to fetch the central keys it being SSH keys, gnome keyring keys or something else. I do not see a reason for IPA to expose a remote PKCS#11 interface. If we need a remote PKCS#11 interface (please insert why here) then it should be a part of the vault API rather than anything else. 2c. > > Simo. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Mar 4 22:18:35 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 04 Mar 2014 17:18:35 -0500 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <5316504A.9090303@redhat.com> References: <52FD02B7.3060404@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> Message-ID: <5316513B.6000703@redhat.com> On 03/04/2014 05:14 PM, Petr Spacek wrote: > On 4.3.2014 22:53, Simo Sorce wrote: >> On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: >>> On 4.3.2014 22:15, Simo Sorce wrote: >>>> On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: >>>>> On 4.3.2014 20:48, Simo Sorce wrote: >>>>>> On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: >>>>>>> On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: >>>>>>>> On 4.3.2014 17:43, Dmitri Pal wrote: >>>>>>>>> On 03/04/2014 11:25 AM, Petr Spacek wrote: >>>>>>>>>> On 4.3.2014 17:00, Dmitri Pal wrote: >>>>>>>>>>> On 03/04/2014 10:26 AM, Simo Sorce wrote: >>>>>>>>>>>> On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: >>>>>>>>>>>>> Where should we store wrapping keys for users/services and >>>>>>>>>>>>> DNS servers? User >>>>>>>>>>>>> object or cn=dns doesn't sound like a good idea because it >>>>>>>>>>>>> would defeat the >>>>>>>>>>>>> purpose. >>>>>>>>>>>> Indeed. And this is the biggest problem. It would be nice >>>>>>>>>>>> to have a >>>>>>>>>>>> mechanism to securely transfer the key to the DNS servers >>>>>>>>>>>> w/o having to >>>>>>>>>>>> store it permanently in LDAP. If we had this mechanism we'd >>>>>>>>>>>> be able to >>>>>>>>>>>> apply it to the Kerberos master key too. But it can't be >>>>>>>>>>>> confined to >>>>>>>>>>>> installation time only, which is easy, it needs to be >>>>>>>>>>>> possible to update >>>>>>>>>>>> it at a later time, which is where we have issues, as our >>>>>>>>>>>> replication >>>>>>>>>>>> mechanism is LDAP. >>>>>>>>>>>> >>>>>>>>>>>> If we solve the DNA plugin issue with the ability to use >>>>>>>>>>>> groups for >>>>>>>>>>>> authentication I guess we could build a control/extend >>>>>>>>>>>> operation that >>>>>>>>>>>> would allow masters to transfer keys to each other w/o >>>>>>>>>>>> exposing them as >>>>>>>>>>>> LDAP searches, do we want to try to go in that direction ? >>>>>>>>>>>> >>>>>>>>>>>> Simo. >>>>>>>>>>>> >>>>>>>>>>> Should we consider "vault" as a storage for these keys too? >>>>>>>>>>> It already supports recovery of the symmetric and asymmetric >>>>>>>>>>> keys so may be >>>>>>>>>>> these keys should be stored there? >>>>>>>>>> >>>>>>>>>> Maybe. The question is if we want to support DNSSEC without >>>>>>>>>> Dogtag ... >>>>>>>>>> >>>>>>>>> Without Dogtag? Vault would be an independent component from >>>>>>>>> CA I assume, >>>>>>>>> though CA might be needed anyways to issue transport keys for >>>>>>>>> the internal >>>>>>>>> components. >>>>>>>>> But I think that even if we use Vault as an internal password >>>>>>>>> and key storage >>>>>>>>> I do not see a reason why we can't require it for DNSSEC. >>>>>>>>> Why over-complicate things if we already have components that >>>>>>>>> can be used? If >>>>>>>>> we see a requests to support DNSSEC without Vault component we >>>>>>>>> will adjust but >>>>>>>>> I do not think we should limit ourselves in the first >>>>>>>>> implementation. >>>>>>>> >>>>>>>> I'm personally fine with that. >>>>>>>> >>>>>>>> Are we going to re-prioritize Password Vault from Backlog to 4.0? >>>>>>>> https://fedorahosted.org/freeipa/ticket/3872 >>>>>>>> >>>>>>>> We need that in 4.0 timeframe for DNSSEC otherwise you need to >>>>>>>> convince Simo >>>>>>>> that key wrapping is not necessary :-) >>>>>>> >>>>>>> For 4.0 we could document that you have to copy the keys around >>>>>>> manually. And add Vault support in 4.1 ? >>>>> It could work ... Can we modify ipa-replica-prepare in 4.0 to add >>>>> the wrapping >>>>> key to replica file to make it easier? >>>>> >>>>> Can the vault approach work for Kerberos master key? If not, >>>>> shouldn't we >>>>> design something universal instead of deferring it again and again? >>>> >>>> We can use the same method for the M/K, now that the CA is installed >>>> before the rest we do not have a chicken-egg issue anymore. >>>> >>>>> Another problem is that the PKCS#11 LDAP schema was designed as >>>>> application-independent but now we are adding very specific >>>>> key-wrapping >>>>> mechanism (it is hard to believe that somebody else will implement >>>>> it). >>>> >>>> It could be optional. >>>> >>>>> Maybe we can add something like attribute 'pkcs11keyWrapMech': >>>>> - key is not wrapped if it is not present >>>>> - key is wrapped if it is present - value determines used >>>>> mechanism (mandatory >>>>> mechanism to implement is only 'none') >>>> >>>> What is 'none' ? >>> I mean 'attribute is not present'. >>> >>>>>> The only unknown here is who adds a new wrapper wen a new server >>>>>> is up >>>>>> and it publishes the public key in LDAP. For existing servers >>>>>> they can >>>>>> re-wrap themselves. >>>>>> >>>>>> It's a few layers but should not be too hard. >>>>> I don't fully understand to your proposal but I'm afraid that it >>>>> will not work >>>>> for ordinary IPA users. Don't forget that we want to have >>>>> universal PKCS#11 >>>>> storage usable even for private SSH keys and other stuff. >>>> >>>> Well ... TBH I am not really that hot about storing private keys in >>>> IPA >>>> like that, however for people that want to do it they can simply store >>>> them not encrypted as you proposed above. >>>> >>>>> Please correct me if I'm wrong. >>>> >>>> You are right, but I was caring for the DNS keys case, not the user's >>>> ssh key case, which is hairy IMHO. >>> There is no difference between DNSSEC keys and any other keys except >>> the fact >>> that we need shared wrapping key for DNSSEC. Nothing else. Note that >>> SSH >>> private key is just an example. You can use PKCS#11 as storage for user >>> certificates used for authentication in Firefox etc. >>> >>>> I think the private ssh key case is a clear job for the Vault the fact >>>> sssd might use a pkcs#11 interface to present it to ssh, or the user >>>> simply pulls it to the local file system is, in my view, an >>>> implementation detail. >>> I can see a huge difference. Properly implemented PKCS#11 provides >>> you the >>> same separation as GSS-Proxy for keytabs. I.e. non-root process will >>> not be >>> able to extract any private keys. >>> >>> Also, PKCS#11 is a standard so any application can use it. I don't like >>> IPA-specific hacks, let's use a standard. >> >> Standards are fine. That's not the point though. >> >>>> Although I realize I have not said it explicitly before I am not all >>>> that happy to have a generic pkcs#11 storage in IPA. Storing >>>> *arbitrary >>>> private* keys in my mind is clearly the job of DRM which has been >>>> built >>>> with that specific use case in mind and has all the appropriate >>>> protections. Putting unencrypted private keys in the IPA tree is >>>> IMHO a >>>> too high risk. >>> Oh wait, I think we misunderstood each other. I'm not proposing to >>> store any >>> keys unencrypted (in IPA)! I only want to design the LDAP schema not >>> to be >>> IPA-specific, nothing else. >>> >>> In case of IPA we can always encrypt all keys (when we have vault >>> available). >>> I hope this clears the misunderstanding. >> >> Well if the Vault is the storage, then why do we care for an LDAP >> schema ? > We need PKCS#11 for CA certificates, BIND and OpenDNSSEC anyway so we > need to design schema for *public* data. All private data can be > stored in Vault if we agree on that. Do we need it on the server and if so can it be exposed by the vault rather than via LDAP? > > In theory, we can use proposed schema for PKCS#11 key storage and just > replace private key attributes with an reference to vault and we are > done. > >> I think Vault is the right storage for user custom data or application >> custom data. >> >> I am not sure we want to depend on the vault for DNS, because it needs >> high availability, however given we copy the keys on the local >> filesystem, once generated, perhaps the Vault is sufficient if it is a >> replicated system. I am not sure DRM is replicated, or will be >> replicated in the first incarnation, so that's why I am treating DNS >> differently. >> >>>> I am not against creating a generic schema if we think it may be >>>> useful >>>> for others, but the more I thin of it the less I think we should >>>> use it >>>> for anything but DNS keys and they should be definitely encrypted in >>>> LDAP and the DNS server machines should be the only ones able to >>>> decrypt >>>> them. >>> Even if all keys will be encrypted? >> >> ELOOP ? :) >> >>>> A casual search with directory manager should never yield private >>>> keys. >>> It makes sense. As I said above, all keys should be encrypted when the >>> proposed schema will be used as part of IPA. >>> >>> >>> Anyway, should we use vault for key storage from the beginning and >>> do not >>> spend time on a throw-away schema design etc.? >>> >>> I can see the reasoning and we don't need two mechanisms for the >>> same thing. >> >> Right. >> >> I guess my only reservation is about whether DRM storage is replicated >> or not. Although both the K/M and DNS cases do not require the Vault to >> be online at all times because the keys will be downloaded and stored >> locally and only needs to be accessed when they changed, there is the >> problem of having all keys in a SPOF, that should not happen. > According to http://www.freeipa.org/page/V4/Password_Vault#Replication > the replication is available for DRM, we just need to use it. > > IMHO a vault without replication is not useful anyway. Users are not > happy when their passwords disappear ;-) > >> The additional thing about the Vault is that we can use key escrow there >> as a mechanism to re-encrypt automatically system relevant keys when a >> new server is joined to the realm. > So we agree that Vault offers what we want so we should use it, right? > > I think we should determine if we can use Vault for K/M. It would be > another reason why we should use Vault instead of a custom solution. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Mar 4 22:21:58 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 04 Mar 2014 17:21:58 -0500 Subject: [Freeipa-devel] Client-side command in the IPA framework In-Reply-To: <1393961229.7196.14.camel@localhost.localdomain> References: <1393541072.3562.19.camel@localhost.localdomain> <20140227225935.GZ16644@redhat.com> <530FFC61.9060001@redhat.com> <53105B27.4070003@redhat.com> <1393597539.3562.21.camel@localhost.localdomain> <20140228144351.GC16644@redhat.com> <1393599745.3562.23.camel@localhost.localdomain> <20140228151536.GD16644@redhat.com> <5310A983.50409@redhat.com> <5312A07A.3060706@redhat.com> <5315287A.8050201@redhat.com> <1393959816.7196.3.camel@localhost.localdomain> <53162579.80100@redhat.com> <1393961229.7196.14.camel@localhost.localdomain> Message-ID: <53165206.1090901@redhat.com> On 03/04/2014 02:27 PM, Nathaniel McCallum wrote: > On Tue, 2014-03-04 at 14:11 -0500, Dmitri Pal wrote: >> On 03/04/2014 02:03 PM, Nathaniel McCallum wrote: >>> On Mon, 2014-03-03 at 20:12 -0500, Dmitri Pal wrote: >>>> On 03/01/2014 10:07 PM, Adam Young wrote: >>>>> On 02/28/2014 10:21 AM, Petr Viktorin wrote: >>>>>> On 02/28/2014 04:15 PM, Alexander Bokovoy wrote: >>>>>>> On Fri, 28 Feb 2014, Nathaniel McCallum wrote: >>>>>>>> On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: >>>>>>>>> On Fri, 28 Feb 2014, Nathaniel McCallum wrote: >>>>>>>>>> On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: >>>>>>>>>>> On 28.2.2014 04:02, Rob Crittenden wrote: >>>>>>>>>>>> Alexander Bokovoy wrote: >>>>>>>>>>>>> On Thu, 27 Feb 2014, Nathaniel McCallum wrote: >>>>>>>>>>>>>> So the recent discussion on importing tokens led me to write a >>>>>>>>> script to >>>>>>>>>>>>>> parse RFC 6030 xml files into IPA token data. This all works >>>>>>>>> well. But >>>>>>>>>>>>>> now I need to integrate it into the IPA framework. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This command will parse one or more xml files, creating a set >>>>>>>>> of tokens >>>>>>>>>>>>>> to be added. Given that we already have otptoken-add on the >>>>>>>>> server-side, >>>>>>>>>>>>>> it seems to me that all work needs to be done on the >>>>>>>>> client-side. How do >>>>>>>>>>>>>> I create a new client-side command that calls existing >>>>>>>>> server-side API? >>>>>>>>>>>>> subclass from frontend.Local, override run() or forward() >>>>>>>>> method and >>>>>>>>>>>>> perform batch >>>>>>>>>>>>> operation of otptoken_add from there. >>>>>>>>>>>>> >>>>>>>>>>>>> See cli.help, for example. >>>>>>>>>>>> If you do an override, do forward() for cli-specific work. >>>>>>>>>>>> >>>>>>>>>>>> But you should do as little as possible for reasons you already >>>>>>>>> stated: >>>>>>>>>>>> the UI. Anything you do in forward Petr will need to implement >>>>>>>>> in the UI. >>>>>>>>>>>> Unfortunately we don't yet have a nice way to handle files. >>>>>>>>> We have >>>>>>>>>>>> tickets open at https://fedorahosted.org/freeipa/ticket/1225 and >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/2933 >>>>>>>>>>>> >>>>>>>>>>>> If this file is something that would be pasted into a big text >>>>>>>>> field >>>>>>>>>>>> then you can probably handle it in a similarly clumsy way that >>>>>>>>> we do >>>>>>>>>>>> CSRs in the cert plugin. >>>>>>>>>>>> >>>>>>>>>>>> rob >>>>>>>>>>> +1 for parsing it on server. Otherwise every client, not just CLI >>>>>>>>> or Web >>>>>>>>>>> UI, would have to reimplement the same logic - having it on server >>>>>>>>> will >>>>>>>>>>> support better integration with third party products. >>>>>>>>>>> >>>>>>>>>>> Parsing on client would be understandable if there was some middle >>>>>>>>> step >>>>>>>>>>> which would require some action from user, i.e, pick only some >>>>>>>>> tokens to >>>>>>>>>>> import. >>>>>>>>>> If we parse on the server side, how do we handle the long-running >>>>>>>>>> operation? Think of the case of importing hundreds or thousands of >>>>>>>>>> tokens... >>>>>>>>> Why then to do it as a IPA CLI command at all? >>>>>>>>> This is an administrative task which can be done with a separate >>>>>>>>> ipa-otp-import command, designated to run on IPA masters. >>>>>>>> Agreed. >>>>>>>> >>>>>>>> 1. Is there a framework for this? Or should it just be an independent >>>>>>>> script? >>>>>>> We don't really have a framework for administrative tools. You may >>>>>>> start >>>>>>> with install/tools/ipa-adtrust-install, it is main part is relatively >>>>>>> independent of the task (which is in >>>>>>> ipaserver/install/adtrustinstance.py) >>>>>>> >>>>>> The framework is there, new tools use it, and there's a ticket to >>>>>> convert old ones: https://fedorahosted.org/freeipa/ticket/2652 (it's >>>>>> low priority in Future Releases, so not much progress is there...) >>>>>> Also see http://www.freeipa.org/page/V3/Logging_and_output >>>>>> >>>>>> >>>>> The RESTful approach would be: >>>>> >>>>> 1. Upload a file to a specific URL (not JSON RPC) >>>>> 2. Receive back a 202 Accepted HTTP Request, to include an URL to >>>>> poll for status >>>>> >>>>> Not certain the right response from the URL in step 2 would be, but I >>>>> am assuming it would be 200 with the body of the message stating: >>>>> processing or completed. >>>>> >>>>> It would be really nice if the Batch command could be handled this way >>>>> as well. The response back could be the partial responses until >>>>> processing is complete. >>>>> >>>>> It might also be nice to supply an email address for notification of >>>>> completed processing instead of polling, if it is going to be a really >>>>> long running task. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> Yes I think that: >>>> 1) We should not limit it to server side operation only >>>> 2) Upload the whole file and then process it. >>>> 3) We should already have code to upload files, we did it for >>>> entitlements and were supposed to use for certs. >>>> 4) Make sure we have a generic upload mechanism that reads a chunk of a >>>> configurable size and asks for more (pagination by 65K might be a good >>>> default). >>>> >>>> Regarding token files specifically: they can be big but not super huge. >>>> 10-20K tokens makes sense but probably not more. More than that would be >>>> a real corner case becuase it is hard to deploy that amount of tokens at >>>> the same time. It can take months and you do not want token file to >>>> contain many tokens that would sit on the shelf. Tokens expire so it is >>>> inefficient to buy huge chunks and let them sit unused. >>>> >>>> UI you allow uploading file too and then would process it locally. >>>> The processing of the file should generate a log or report. It would be >>>> nice to get indication from the server that it is still working so may >>>> be upload protocol should be something like: >>>> >>>> client: Initialize the transfer >>>> server: ready >>>> client: here is the chunk of data >>>> server: ack >>>> ... >>>> client: here is the last chunk of data >>>> server: ack, (forks the file processing method that updates shared >>>> status data) come back in x seconds >>>> client: how are things? >>>> server: working, here is current status, come back in x seconds >>>> ... >>>> client: how are things? >>>> server: done, here is current status, have errors in a file >>>> client: start download >>>> server: here is the chunk >>>> ... >>>> >>>> I think we can short socket the command for now to fail if it is not >>>> local on the server and then build the upload mechanism but separate >>>> command as proposed in this thread would lock us in a local approach >>>> forever. >>> The problem is that we have no infrastructure for any of this. It would >>> all have to be built just for the import command. It is also a fairly >>> rare, admin-only operation. For this reason, I am leaning towards >>> implementing it as a simple script to be executed on the FreeIPA master. >>> The main drawback of this approach is that you don't get import >>> functionality in the UI. >>> >>> I also disagree that doing it this way now necessitates we do it this >>> way forever. In fact, it is more likely that if we design a fully >>> featured server implementation now, we'll get details wrong and be stuck >>> with it. Doing it on the master using the existing API frees us to add a >>> server-side API in the future. >>> >>> Nathaniel >>> >> We already have use cases for upload but we defer it again and again for >> a better time. >> We need to upload and download files for other use cases: >> >> Download: >> a) Keytabs (we have a ticket to do it in the UI) >> b) Reports >> c) Import logs (for tokens or users) >> ... >> >> Upload: >> a) Token file >> b) SSH public keys >> c) Register user certificate in IPA >> ... >> >> We need this mechanisms anyways. >> We have been deferring this for too long. > I agree. > >> I would rather defer support of the hardware tokens till next version >> and do an upload in the cli and UI than cut the corner and create yet >> one off mechanism. >> >> IMO we are going the wrong way about it. > So the problem isn't hardware tokens, the problem is that users can > modify tokens they shouldn't (these are most commonly hardware, but not > necessarily so). Support for this can be added trivially once I get some > of the more pressing issues off my plate. I don't see any reason to > delay this. Let's not conflate issues. > > Imports are a different story. We could land an independent import > script (IIS) in 4.0. This functionality could be moved to a framework > script (FS) later. If backwards compatibility for this is a concern, the > IIS could just point to the FS. If we desire not to support the IIS at > all, we could ship it as contrib or distribute it independently. > > But once we have infrastructure for uploads/downloads/long-running task > state, the code from the IIS should move to the server side with little > modification. So it isn't lost effort. > > Having *some* form of import is highly desirable for 4.0. > > Nathaniel > I bet it will be a complete rewrite but I would not argue. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pspacek at redhat.com Tue Mar 4 22:30:46 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 04 Mar 2014 23:30:46 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <5316513B.6000703@redhat.com> References: <52FD02B7.3060404@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <5316513B.6000703@red! hat.com> Message-ID: <53165416.50000@redhat.com> On 4.3.2014 23:18, Dmitri Pal wrote: >> We need PKCS#11 for CA certificates, BIND and OpenDNSSEC anyway so we need >> to design schema for *public* data. All private data can be stored in Vault >> if we agree on that. > > Do we need it on the server and if so can it be exposed by the vault rather > than via LDAP? We need standard PKCS#11 interface because applications like BIND and OpenDNSSEC do not care about IPA-specifics. However applications see only PKCS#11 interface and nothing else, there could be LDAP or some other protocol behind the API. Honza's plan is to integrate PKCS#11 module to SSSD somehow so it will be available on all client machines, it will use caching facilities, fail-over etc. Replying to the other thread to join both threads to one: > Also about PKCS#11 interface. I am all for PKCS#11 interface for client > exposed from SSSD that uses whatever means to fetch the central keys it being > SSH keys, gnome keyring keys or something else. AFAIK that is exactly the plan. > I do not see a reason for IPA > to expose a remote PKCS#11 interface. If we need a remote PKCS#11 interface > (please insert why here) then it should be a part of the vault API rather than > anything else. I'm not sure that I understand... PKCS#11 is just a set of functions, for an application it is a library. An application just calls the PKCS#11 API and knows nothing about implementation details so there is nothing like 'remote PKCS#11'. As I said above, SSSD will be behind scenes. Everything is local except the data storage in LDAP or vault, it doesn't matter. Maybe I misunderstood you, sorry. -- Petr^2 Spacek From dpal at redhat.com Tue Mar 4 23:32:10 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 04 Mar 2014 18:32:10 -0500 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <53165416.50000@redhat.com> References: <52FD02B7.3060404@redhat.com> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <5316513B.6000703@red! hat.com> <53165416.50000@redhat.com> Message-ID: <5316627A.6060702@redhat.com> On 03/04/2014 05:30 PM, Petr Spacek wrote: > On 4.3.2014 23:18, Dmitri Pal wrote: >>> We need PKCS#11 for CA certificates, BIND and OpenDNSSEC anyway so >>> we need >>> to design schema for *public* data. All private data can be stored >>> in Vault >>> if we agree on that. >> >> Do we need it on the server and if so can it be exposed by the vault >> rather >> than via LDAP? > We need standard PKCS#11 interface because applications like BIND and > OpenDNSSEC do not care about IPA-specifics. However applications see > only PKCS#11 interface and nothing else, there could be LDAP or some > other protocol behind the API. > > Honza's plan is to integrate PKCS#11 module to SSSD somehow so it will > be available on all client machines, it will use caching facilities, > fail-over etc. > > Replying to the other thread to join both threads to one: >> Also about PKCS#11 interface. I am all for PKCS#11 interface for client >> exposed from SSSD that uses whatever means to fetch the central keys >> it being >> SSH keys, gnome keyring keys or something else. > AFAIK that is exactly the plan. > >> I do not see a reason for IPA >> to expose a remote PKCS#11 interface. If we need a remote PKCS#11 >> interface >> (please insert why here) then it should be a part of the vault API >> rather than >> anything else. > I'm not sure that I understand... > > PKCS#11 is just a set of functions, for an application it is a library. > > An application just calls the PKCS#11 API and knows nothing about > implementation details so there is nothing like 'remote PKCS#11'. As I > said above, SSSD will be behind scenes. Everything is local except the > data storage in LDAP or vault, it doesn't matter. > > Maybe I misunderstood you, sorry. > Remote means that there is a PKCS#11 library that can be loaded into a process and would remotely connect to a central server via LDAP/REST/whatever. My point is that library should be light weight and always talk to a local service like SSSD rather than have a remote interface. In this case SSSD on the server can talk to the vault or IPA LDAP directly and all consumers would use PKCS#11 interface exposed by SSSD Something like this... -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bagjhfhh.png Type: image/png Size: 31680 bytes Desc: not available URL: From simo at redhat.com Wed Mar 5 04:10:45 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 04 Mar 2014 23:10:45 -0500 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <5316627A.6060702@redhat.com> References: <52FD02B7.3060404@redhat.com> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <5316513B.6000703@red! hat.com> <53165416.50000@redhat.com> <5316627A.6060702@redhat.com> Message-ID: <1393992645.22047.178.camel@willson.li.ssimo.org> On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: > Remote means that there is a PKCS#11 library that can be loaded into a > process and would remotely connect to a central server via > LDAP/REST/whatever. My point is that library should be light weight > and always talk to a local service like SSSD rather than have a remote > interface. In this case SSSD on the server can talk to the vault or > IPA LDAP directly and all consumers would use PKCS#11 interface > exposed by SSSD > > Something like this... Yes this is the setting we are discussing, the actual specific discussion is how SSSD gets the information. Honza proposed to use a PKCS#11-like schema to store data in LDAP given DNS will need something similar, however the more we wandered into the discussion the more I got convinced the Vault is probably a better place to store this material than the LDAP tree itself at least for prvate keys. For public key material only though I am not sure a pkcs#11 schema will necessarily be useful. It might, but we do not use it for public SSH keys. And we also already have schema for public User or Servers X509 certs. We need to define something for DNS public keys, but they are already published in DNS Records too if I am not wrong, would that be sufficient as a storage for the public part ? I am assuming the private keys are stored in the Vault and they can be files in the format used by bind ? Simo. > -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Wed Mar 5 07:48:26 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 05 Mar 2014 08:48:26 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <1393992645.22047.178.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <5316513B.6000703@red! hat.com> <53165416.50000@redhat.com> <5316627A.6060702@redhat.com> <1393992645.22047.178.camel@willson.li.ssimo.org> Message-ID: <5316D6CA.5010103@redhat.com> On 5.3.2014 05:10, Simo Sorce wrote: > On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: >> Remote means that there is a PKCS#11 library that can be loaded into a >> process and would remotely connect to a central server via >> LDAP/REST/whatever. My point is that library should be light weight >> and always talk to a local service like SSSD rather than have a remote >> interface. In this case SSSD on the server can talk to the vault or >> IPA LDAP directly and all consumers would use PKCS#11 interface >> exposed by SSSD >> >> Something like this... > > Yes this is the setting we are discussing, the actual specific > discussion is how SSSD gets the information. > > Honza proposed to use a PKCS#11-like schema to store data in LDAP given > DNS will need something similar, however the more we wandered into the > discussion the more I got convinced the Vault is probably a better place > to store this material than the LDAP tree itself at least for prvate > keys. I only proposed something that would work for my needs (i.e. storing certificates and associated trust policy) and would be ready for 4.0. Can you say the same thing about the vault? > > For public key material only though I am not sure a pkcs#11 schema will > necessarily be useful. It might, but we do not use it for public SSH > keys. And we also already have schema for public User or Servers X509 > certs. Support for SSH public keys was implemented like 2 years ago, way before any talk about the vault or PKCS#11 even started. As for certs, the proposed schema works on top of RFC 4523, which is the cert schema you mention. > > We need to define something for DNS public keys, but they are already > published in DNS Records too if I am not wrong, would that be sufficient > as a storage for the public part ? I am assuming the private keys are > stored in the Vault and they can be files in the format used by bind ? So the information would be scattered in different places, using different formats and accessed using different protocols? I'm fine with that, but it is way beyond my original idea, so please let whoever is in charge of the vault implement the PKCS#11 module themselves. > > Simo. >> -- Jan Cholasta From pviktori at redhat.com Wed Mar 5 08:58:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Mar 2014 09:58:34 +0100 Subject: [Freeipa-devel] [PATCH 0008] Typo in warning message where IPA realm and domain name differ In-Reply-To: <1393894093.22047.60.camel@willson.li.ssimo.org> References: <1393894093.22047.60.camel@willson.li.ssimo.org> Message-ID: <5316E73A.2000909@redhat.com> On 03/04/2014 01:48 AM, Simo Sorce wrote: > On Mon, 2014-03-03 at 17:20 -0700, Gabe Alford wrote: >> Hi all, >> >> Quick one line change to fix. >> >> https://fedorahosted.org/freeipa/ticket/4211 > > ACK > > Simo. > Pushed to master: b50cdd55af8af7fdf30a822dce03af68969ddfe6 -- Petr? From pviktori at redhat.com Wed Mar 5 08:59:32 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Mar 2014 09:59:32 +0100 Subject: [Freeipa-devel] [PATCH] 545 webui: Don't act on keyboard events which originated in, different dialog In-Reply-To: <919251367.3572806.1393952211928.JavaMail.zimbra@redhat.com> References: <530C988B.90504@redhat.com> <799250726.3565643.1393950441572.JavaMail.zimbra@redhat.com> <919251367.3572806.1393952211928.JavaMail.zimbra@redhat.com> Message-ID: <5316E774.5050104@redhat.com> On 03/04/2014 05:56 PM, Adam Misnyovszki wrote: > > > ----- Original Message ----- >> From: "Adam Misnyovszki" >> To: "Petr Vobornik" >> Cc: "freeipa-devel" >> Sent: Tuesday, March 4, 2014 5:27:21 PM >> Subject: Re: [Freeipa-devel] [PATCH] 545 webui: Don't act on keyboard events which originated in, different dialog >> >> >> >> ----- Original Message ----- >>> From: "Petr Vobornik" >>> To: "freeipa-devel" >>> Sent: Tuesday, February 25, 2014 2:20:11 PM >>> Subject: [Freeipa-devel] [PATCH] 545 webui: Don't act on keyboard events >>> which originated in, different dialog >>> >>> Fixes issue when: >>> 1. 2 dialogs are opened >>> 2. top dialog's close button is focused >>> 3. user presses enter to execute 'close' action >>> 4. dialog is immediately closed (enter key is still pressed) >>> 5. second dialog automatically receives focus (it's top dialog now) >>> 6. user releases the key >>> 7. second dialog reacts to keyup event - which is by default >>> confirmation mixin's confirm event >>> 8. UNDESIRED behavior occurs >>> >>> Now confirmation mixin remembers which keys were pressed and released >>> and reacts only to those which originated there. >>> >>> https://fedorahosted.org/freeipa/ticket/4098 >>> -- >>> Petr Vobornik >>> >> >> ACK >> However, we should keep in mind, that there is an issue, when the ENTER key >> is pressed for a long time(ie more time than a keydown event is fired), the >> dialog starts to "blink". In my oppinion, this later behaviour is a wontfix, >> because firstly it is not easy to handle, > secondly because this problem exists in mostly all softwares, thirdly this is not the scope of the ticket. > Sorry for the amendment, zimbra doesn't work quite well. > Adam Pushed to master: 9b540ef21864f8da822bd92d58385339147e773d -- Petr? From pviktori at redhat.com Wed Mar 5 09:01:31 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Mar 2014 10:01:31 +0100 Subject: [Freeipa-devel] [PATCHES] 0337-0343 YAML test configuration In-Reply-To: <5315F846.5080204@redhat.com> References: <52A9A0A9.9040706@redhat.com> <52CA81B1.4040602@redhat.com> <53147882.9090203@redhat.com> <5315B1C3.20108@redhat.com> <5315F846.5080204@redhat.com> Message-ID: <5316E7EB.2080509@redhat.com> On 03/04/2014 04:59 PM, Tomas Babej wrote: > Thanks, > > PATCH 341: ACK > > (this is the last remaining ACK for this patchset) Thank you! Pushed to master: 561e57d12169cfa4e1d2c5d9fef42b149c37fca2 > On 03/04/2014 11:58 AM, Petr Viktorin wrote: >> On 03/03/2014 01:41 PM, Tomas Babej wrote: >>> Finally got to this patchset! >>> >>> PATCH 337: ACK >>> PATCH 338: ACK >>> >>> This prohibits us to use extra roles that end in digits. Can you put a >>> note explaining that in >>> >>> http://www.freeipa.org/page/V3/Integration_testing#Host_configuration >> >> Updated. >> >>> Also, this wiki page points out to environment variables so that it >>> seems it is the preferred method of configuration. We should mention >>> more user friendly YAML here first. >> >> Let's do that when the patches are pushed. #3938 should stay open >> until it's done. >> >>> PATCH 339: ACK >>> PATCH 340: ACK >>> PATCH 341: >>> >>> The have_master variable seems redundant in from_dict method (it's only >>> a local definition and not referenced anywhere else): >>> >>> + def from_dict(cls, dct, config): >>> + from ipatests.test_integration.host import BaseHost >>> + >>> + domain_type = dct.pop('type') >>> + assert domain_type in ('IPA', 'AD') >>> + domain_name = dct.pop('name') >>> + self = cls(config, domain_name, domain_type) >>> + >>> + have_master = False >>> + for host_dict in dct.pop('hosts'): >>> + host = BaseHost.from_dict(host_dict, self) >>> + self.hosts.append(host) >>> + if host.role == 'master': >>> + have_master = True >>> + >>> + check_config_dict_empty(dct, 'domain %s' % domain_name) >>> + >>> + return self >> >> Right you are. Fixed. >> >>> PATCH 342: ACK >>> PATCH 343: ACK >>> >>> PATCH 348: ACK >>> PATCH 349: ACK >>> >>> >> > -- Petr? From pviktori at redhat.com Wed Mar 5 09:03:59 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Mar 2014 10:03:59 +0100 Subject: [Freeipa-devel] [PATCHES] 0337-0343 YAML test configuration In-Reply-To: <5315F846.5080204@redhat.com> References: <52A9A0A9.9040706@redhat.com> <52CA81B1.4040602@redhat.com> <53147882.9090203@redhat.com> <5315B1C3.20108@redhat.com> <5315F846.5080204@redhat.com> Message-ID: <5316E87F.2070306@redhat.com> On 03/04/2014 04:59 PM, Tomas Babej wrote: > Thanks, > > PATCH 341: ACK > > (this is the last remaining ACK for this patchset) Also pushed to ipa-3-3: 23814f9b57794a5f2f8ae62a3342ee18535df2ea > > On 03/04/2014 11:58 AM, Petr Viktorin wrote: >> On 03/03/2014 01:41 PM, Tomas Babej wrote: >>> Finally got to this patchset! >>> >>> PATCH 337: ACK >>> PATCH 338: ACK >>> >>> This prohibits us to use extra roles that end in digits. Can you put a >>> note explaining that in >>> >>> http://www.freeipa.org/page/V3/Integration_testing#Host_configuration >> >> Updated. >> >>> Also, this wiki page points out to environment variables so that it >>> seems it is the preferred method of configuration. We should mention >>> more user friendly YAML here first. >> >> Let's do that when the patches are pushed. #3938 should stay open >> until it's done. >> >>> PATCH 339: ACK >>> PATCH 340: ACK >>> PATCH 341: >>> >>> The have_master variable seems redundant in from_dict method (it's only >>> a local definition and not referenced anywhere else): >>> >>> + def from_dict(cls, dct, config): >>> + from ipatests.test_integration.host import BaseHost >>> + >>> + domain_type = dct.pop('type') >>> + assert domain_type in ('IPA', 'AD') >>> + domain_name = dct.pop('name') >>> + self = cls(config, domain_name, domain_type) >>> + >>> + have_master = False >>> + for host_dict in dct.pop('hosts'): >>> + host = BaseHost.from_dict(host_dict, self) >>> + self.hosts.append(host) >>> + if host.role == 'master': >>> + have_master = True >>> + >>> + check_config_dict_empty(dct, 'domain %s' % domain_name) >>> + >>> + return self >> >> Right you are. Fixed. >> >>> PATCH 342: ACK >>> PATCH 343: ACK >>> >>> PATCH 348: ACK >>> PATCH 349: ACK >>> >>> >> > -- Petr? From pviktori at redhat.com Wed Mar 5 09:09:44 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Mar 2014 10:09:44 +0100 Subject: [Freeipa-devel] [PATCH 0042] Rework how otptoken defaults are handled In-Reply-To: <53147231.2060505@redhat.com> References: <1392993950.23210.22.camel@localhost.localdomain> <1392995390.23210.27.camel@localhost.localdomain> <530770D9.4020104@redhat.com> <1393001129.23210.40.camel@localhost.localdomain> <53147231.2060505@redhat.com> Message-ID: <5316E9D8.3030004@redhat.com> On 03/03/2014 01:14 PM, Jan Cholasta wrote: > On 21.2.2014 17:45, Nathaniel McCallum wrote: >> On Fri, 2014-02-21 at 16:29 +0100, Jan Cholasta wrote: >>> Hi, >>> >>> On 21.2.2014 16:09, Nathaniel McCallum wrote: >>>> On Fri, 2014-02-21 at 09:45 -0500, Nathaniel McCallum wrote: >>>>> We had originally decided to provide defaults on the server side so >>>>> that >>>>> they could be part of a global config for the admin. However, on >>>>> further >>>>> reflection, only certain defaults really make sense given the >>>>> limitations of Google Authenticator. Similarly, other defaults may be >>>>> token specific. >>>>> >>>>> Attempting to handle defaults on the server side also makes both >>>>> the UI >>>>> and the generated documentation unclear. >>>>> >>>>> NOTE: this patch changes an existing API. VERSION says that we should >>>>> bump the major version in this case. But we haven't actually released >>>>> this API yet. Please advise. >>> >>> There were similar changes in the past and bumping minor version was >>> always enough (we never ever bump major version). >> >> Fixed. > > Thanks, ACK. Pushed to master: 21ff4f920e4ff7c1e2870024f007f067fc3cf6c8 -- Petr? From pviktori at redhat.com Wed Mar 5 09:09:57 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Mar 2014 10:09:57 +0100 Subject: [Freeipa-devel] [PATCH 0045] Fix token secret length RFC compliance In-Reply-To: <5314ABA4.2020200@redhat.com> References: <1393863201.1963.1.camel@localhost.localdomain> <5314ABA4.2020200@redhat.com> Message-ID: <5316E9E5.2090809@redhat.com> On 03/03/2014 05:19 PM, Jan Cholasta wrote: > On 3.3.2014 17:13, Nathaniel McCallum wrote: >> RFC 4226 states the following in section 4: >> R6 - The algorithm MUST use a strong shared secret. The length of >> the shared secret MUST be at least 128 bits. This document >> RECOMMENDs a shared secret length of 160 bits. > > ACK. > Pushed to master: 0ca6653c299c75f5215cc37c6b129ce58a85e8df -- Petr? From mkosek at redhat.com Wed Mar 5 09:43:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 05 Mar 2014 10:43:34 +0100 Subject: [Freeipa-devel] [PATCH] 0145: trust fix filtering of users from subdomains In-Reply-To: <1393949548.22047.76.camel@willson.li.ssimo.org> References: <20140304091325.GF16644@redhat.com> <53159BDA.6060007@redhat.com> <20140304093321.GG16644@redhat.com> <1393949548.22047.76.camel@willson.li.ssimo.org> Message-ID: <5316F1C6.4000802@redhat.com> On 03/04/2014 05:12 PM, Simo Sorce wrote: > On Tue, 2014-03-04 at 11:33 +0200, Alexander Bokovoy wrote: >> On Tue, 04 Mar 2014, Martin Kosek wrote: >>> On 03/04/2014 10:13 AM, Alexander Bokovoy wrote: >>>> Attached patch should fix https://fedorahosted.org/freeipa/ticket/4207 >>>> where we didn't filter out users from disabled subdomains aggressively >>>> enough. >>>> >>>> The code that did not filter exists only in git, not in released >>>> versions yet. >>>> >>>> Attached also a screenshot that explains the behavior. >>>> >>>> The code was tested by me, Sumit, and Scott, and reviewed over last few >>>> days by Simo and Sumit. >>> >>> Thanks Alexander! Do I understand it right that it has an ACK from Simo and >>> Sumit? If yes, I will push the patch to master and ipa-3-3 (when fedorahosted >>> git starts working again). >> I'd like to get ACKs here, Simo didn't see the latest version yesterday. >> > > Looks good to me. > > Simo. > Pushed to: master: 6b45ec3f31773ee7a229d5bb56675badc2d8fd55 ipa-3-3: be033fd57d818d6e90d7a4a73650bfc18d0d2c2b Martin From pspacek at redhat.com Wed Mar 5 09:53:07 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 05 Mar 2014 10:53:07 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <5316D6CA.5010103@redhat.com> References: <52FD02B7.3060404@redhat.com> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <5316513B.6000703@red! hat.com> <53165416.50000@redhat.com> <5316627A.6060702@redhat.com> <1393992645.22047.178.camel@willson.li.ssimo.org> <5316D6CA.5010103@redhat.c! om> Message-ID: <5316F403.6010102@redhat.com> On 5.3.2014 08:48, Jan Cholasta wrote: > On 5.3.2014 05:10, Simo Sorce wrote: >> On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: >>> Remote means that there is a PKCS#11 library that can be loaded into a >>> process and would remotely connect to a central server via >>> LDAP/REST/whatever. My point is that library should be light weight >>> and always talk to a local service like SSSD rather than have a remote >>> interface. In this case SSSD on the server can talk to the vault or >>> IPA LDAP directly and all consumers would use PKCS#11 interface >>> exposed by SSSD >>> >>> Something like this... >> >> Yes this is the setting we are discussing, the actual specific >> discussion is how SSSD gets the information. >> >> Honza proposed to use a PKCS#11-like schema to store data in LDAP given >> DNS will need something similar, however the more we wandered into the >> discussion the more I got convinced the Vault is probably a better place >> to store this material than the LDAP tree itself at least for prvate >> keys. > > I only proposed something that would work for my needs (i.e. storing > certificates and associated trust policy) and would be ready for 4.0. Can you > say the same thing about the vault? I agree with Honza. I think that proposed LDAP schema is perfectly fits the purpose *for public* information like certificates and public keys. >> For public key material only though I am not sure a pkcs#11 schema will >> necessarily be useful. It might, but we do not use it for public SSH >> keys. And we also already have schema for public User or Servers X509 >> certs. > > Support for SSH public keys was implemented like 2 years ago, way before any > talk about the vault or PKCS#11 even started. As for certs, the proposed > schema works on top of RFC 4523, which is the cert schema you mention. > >> >> We need to define something for DNS public keys, but they are already >> published in DNS Records too if I am not wrong, would that be sufficient >> as a storage for the public part ? I am assuming the private keys are No, we need full PKCS#11 for OpenDNSSEC at least. Note that PKCS#11 in SSSD will give us generic mechanism for process/key separation (it is practically the same thing GSS-Proxy, just general purpose). This comes 'for free' if we implement PKCS#11 so please stop searching for workarounds :-) >> stored in the Vault and they can be files in the format used by bind ? BIND files are very hackish and we need to do PKCS#11->BIND files conversion anyway because OpenDNSSEC supports only PKCS#11 and nothing else. I plan to use PKCS#11 directly from BIND so we can drop the format conversion code and rely on pure PKCS#11 instead of bunch of hacks scripts. > So the information would be scattered in different places, using different > formats and accessed using different protocols? I'm fine with that, but it is > way beyond my original idea, so please let whoever is in charge of the vault > implement the PKCS#11 module themselves. - IMHO public information should be stored in LDAP schema as proposed. - I agree that Vault is the right choice to store secrets. - I propose to combine these two: Store public information in LDAP and store private keys in PKCS#8 blob as a secret in Vault. - This LDAP+Vault combo can be accessible over PKCS#11 interface. - Note that this will work even without vault if you want to store public information only (like CA certs and NSS trust objects). The only problem is that we need to use REST API from SSSD. Plain LDAP is already implemented in SSSD so it requires less code. I guess that we will need something like libipavault library... -- Petr^2 Spacek From jpazdziora at redhat.com Wed Mar 5 09:53:48 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 5 Mar 2014 10:53:48 +0100 Subject: [Freeipa-devel] [PATCH 0154] man: sshd should be run at least once before client In-Reply-To: <530B4FF5.60107@redhat.com> References: <530B4FF5.60107@redhat.com> Message-ID: <20140305095348.GA26583@redhat.com> On Mon, Feb 24, 2014 at 02:58:13PM +0100, Tomas Babej wrote: > Hi, > > If SSH keys have not been generated prior to enrolling the client to the > IPA server, they will not be uploaded to the server, since they're not > present. Clarify this issue in the man pages. > > https://fedorahosted.org/freeipa/ticket/4055 [...] > > +.SS "Assumptions" > +The ipa\-client\-install script assumes that the machine has already generated SSH keys. It will not generate SSH keys on its own accord. I'm not native speaker but I believe it should be either "on its own" or "of its own accord". > If SSH keys are not present (e.g when running the ipa-client-install in Is it correct that there are no backslashes in this occurence of ipa-client-install? > a kickstart, before ever running sshd), they will not be uploaded to the client host entry on the server. > + -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From tbabej at redhat.com Wed Mar 5 11:33:01 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 05 Mar 2014 12:33:01 +0100 Subject: [Freeipa-devel] [PATCH 0154] man: sshd should be run at least once before client In-Reply-To: <20140305095348.GA26583@redhat.com> References: <530B4FF5.60107@redhat.com> <20140305095348.GA26583@redhat.com> Message-ID: <53170B6D.7030104@redhat.com> Thanks Jan, both fixed. Tomas On 03/05/2014 10:53 AM, Jan Pazdziora wrote: > On Mon, Feb 24, 2014 at 02:58:13PM +0100, Tomas Babej wrote: >> Hi, >> >> If SSH keys have not been generated prior to enrolling the client to the >> IPA server, they will not be uploaded to the server, since they're not >> present. Clarify this issue in the man pages. >> >> https://fedorahosted.org/freeipa/ticket/4055 > [...] > >> >> +.SS "Assumptions" >> +The ipa\-client\-install script assumes that the machine has already generated SSH keys. It will not generate SSH keys on its own accord. > I'm not native speaker but I believe it should be either "on its own" > or "of its own accord". > >> If SSH keys are not present (e.g when running the ipa-client-install in > Is it correct that there are no backslashes in this occurence of > ipa-client-install? > >> a kickstart, before ever running sshd), they will not be uploaded to the client host entry on the server. >> + -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0154-2-man-sshd-should-be-run-at-least-once-before-client-e.patch Type: text/x-patch Size: 2096 bytes Desc: not available URL: From jpazdziora at redhat.com Wed Mar 5 11:37:50 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 5 Mar 2014 12:37:50 +0100 Subject: [Freeipa-devel] [PATCH 0154] man: sshd should be run at least once before client In-Reply-To: <53170B6D.7030104@redhat.com> References: <530B4FF5.60107@redhat.com> <20140305095348.GA26583@redhat.com> <53170B6D.7030104@redhat.com> Message-ID: <20140305113750.GB26583@redhat.com> On Wed, Mar 05, 2014 at 12:33:01PM +0100, Tomas Babej wrote: > Thanks Jan, both fixed. Ack. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Wed Mar 5 11:49:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 05 Mar 2014 12:49:01 +0100 Subject: [Freeipa-devel] [PATCH 0154] man: sshd should be run at least once before client In-Reply-To: <20140305113750.GB26583@redhat.com> References: <530B4FF5.60107@redhat.com> <20140305095348.GA26583@redhat.com> <53170B6D.7030104@redhat.com> <20140305113750.GB26583@redhat.com> Message-ID: <53170F2D.4030100@redhat.com> On 03/05/2014 12:37 PM, Jan Pazdziora wrote: > On Wed, Mar 05, 2014 at 12:33:01PM +0100, Tomas Babej wrote: >> Thanks Jan, both fixed. > > Ack. > Pushed to master: 6b94f959a4d41b62ca6c2b273633880bbfab8b49 Thanks, Martin From mkosek at redhat.com Wed Mar 5 12:05:45 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 05 Mar 2014 13:05:45 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <5316504A.9090303@redhat.com> References: <52FD02B7.3060404@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> Message-ID: <53171319.6030007@redhat.com> On 03/04/2014 11:14 PM, Petr Spacek wrote: > On 4.3.2014 22:53, Simo Sorce wrote: >> On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: >>> On 4.3.2014 22:15, Simo Sorce wrote: >>>> On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: ... >> I guess my only reservation is about whether DRM storage is replicated >> or not. Although both the K/M and DNS cases do not require the Vault to >> be online at all times because the keys will be downloaded and stored >> locally and only needs to be accessed when they changed, there is the >> problem of having all keys in a SPOF, that should not happen. > According to http://www.freeipa.org/page/V4/Password_Vault#Replication the > replication is available for DRM, we just need to use it. > > IMHO a vault without replication is not useful anyway. Users are not happy when > their passwords disappear ;-) > >> The additional thing about the Vault is that we can use key escrow there >> as a mechanism to re-encrypt automatically system relevant keys when a >> new server is joined to the realm. > So we agree that Vault offers what we want so we should use it, right? > > I think we should determine if we can use Vault for K/M. It would be another > reason why we should use Vault instead of a custom solution. > Do we really want to use the heavy machinery Vault for DNSSEC keys? I would personally like to avoid it and use something more lightweight. Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It needs Tomcat and all the Java machinery, special installation, replication scheme, difficult debugging etc. In my mind, Vault is a specialized heavy component that solves specific problems that not every admin may want and thus may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC). Marti From jcholast at redhat.com Wed Mar 5 12:08:31 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 05 Mar 2014 13:08:31 +0100 Subject: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter In-Reply-To: <530C6D30.5070509@redhat.com> References: <52CEC0AE.9040502@redhat.com> <1389385309.2072.12.camel@localhost.localdomain> <52D3DEF0.7020302@redhat.com> <52D3F0B9.4050302@redhat.com> <52D4F4EC.3020707@redhat.com> <52D5011D.30707@redhat.com> <530C6D30.5070509@redhat.com> Message-ID: <531713BF.7010804@redhat.com> On 25.2.2014 11:15, Tomas Babej wrote: > > On 01/14/2014 10:19 AM, Petr Viktorin wrote: >> On 01/14/2014 09:27 AM, Jan Cholasta wrote: >>> On 13.1.2014 14:57, Petr Vobornik wrote: >>>> On 13.1.2014 13:41, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 10.1.2014 21:21, Nathaniel McCallum wrote: >>>>>> On Thu, 2014-01-09 at 16:30 +0100, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Adds a parameter that represents a DateTime format using >>>>>>> datetime.datetime >>>>>>> object from python's native datetime library. >>>>>>> >>>>>>> In the CLI, accepts one of the following formats: >>>>>>> Accepts subset of values defined by ISO 8601: >>>>>>> %Y-%m-%dT%H:%M:%S >>>>>>> %Y-%m-%dT%H:%M >>>>>>> '%Y%m%dT%H:%M:%S' >>>>>>> '%Y%m%dT%H:%M' >>>>>>> >>>>>>> Also accepts LDAP Generalized time in the following format: >>>>>>> '%Y%m%d%H%M%SZ' >>>>>>> >>>>>>> As a simplification, it does not deal with timezone info and ISO >>>>>>> 8601 >>>>>>> values with timezone info (+-hhmm) are rejected. Values are expected >>>>>>> to be in the UTC timezone. >>>>>>> >>>>>>> Values are saved to LDAP as LDAP Generalized time values in the >>>>>>> format >>>>>>> '%Y%m%d%H%SZ' (no time fractions and UTC timezone is assumed). To >>>>>>> avoid >>>>>>> confusion, in addition to subset of ISO 8601 values, the LDAP >>>>>>> generalized >>>>>>> time in the format '%Y%m%d%H%M%SZ' is also accepted as an input (as >>>>>>> this >>>>>>> is the >>>>>>> format user will see on the output). >>>>>>> >>>>>>> Part of: https://fedorahosted.org/freeipa/ticket/3306 >>>>>> >>>>>> The date/time syntax formats are not compliant with ISO 8601. You >>>>>> stated >>>>>> they are expected to be in UTC timezone, but no 'Z' is expected in >>>>>> most >>>>>> of them. This is not only non-standard, but would prevent you from >>>>>> every >>>>>> supporting local time in the future. >>>>> >>>>> +1, please require the trailing "Z". >>>>> >>>>> >>>>> I think generalized time format should be the preferred one, as it is >>>>> stored in LDAP and thus returned by commands. Also, do we really need >>>>> all of these other formats? >>>> >>>> +1 That API should accept and always return generalized time. >>>> >>>> But UIs(CLI, Web) should display something more human readable. Like: >>>> %Y-%m-%dT%H:%M:%SZ or IMHO better (but not ISO 8601): %Y-%m-%d >>>> %H:%M:%SZ >>>> ie. 2014-03-08 14:16:55Z compared to 2014-03-08T14:16:55Z or >>>> 20140308141655Z >>>> >>>> Both should accept input value in the same format. Usage of different >>>> output and input formats is confusing. Thus I agree with supporting >>>> more >>>> input formats. Decision whether it should be done on API level or >>>> client >>>> level is another matter. >>> >>> If you want human readable output, you have to do the conversion from >>> generalized time on clients. If you want to support local time and >>> timezones, you have to do some processing on the client as well. I would >>> be perfectly happy if we supported only generalized time over the wire >>> and did conversion from/to human readable on clients. >>> >>>> >>>> I has been implementing the Web UI part and I think we should also >>>> support a formats without time component. My initial impl. supports >>>> combinations of: >>>> >>>> var dates = [ >>>> ['YYYY-MM-DD', /^(\d{4})-(\d{2})-(\d{2})$/], >>>> ['YYYYMMDD',/^(\d{4})(\d{2})(\d{2})$/] >>>> ]; >>>> >>>> var times = [ >>>> ['HH:mm:ss', /^(\d\d):(\d\d):(\d\d)Z$/], >>>> ['HH:mm', /^(\d\d):(\d\d)Z$/], >>>> ['HH', /^(\d\d)Z$/] >>>> ]; >>>> + generalized time >>>> ['YYYYMMDDHHmmssZ',/^(\d{4})(\d{2})(\d{2})(\d{2})(\d{2})(\d{2})Z$/] >>>> >>>> with /( |T)/ as divider and time optional. >>>> >>>> Both UIs should also tell the user what is the expected format (at >>>> least >>>> one of them). Getting incorrect format error without knowing it is >>>> annoying. >>> >>> The current code raises a ValidationError including the list of formats. >> >> On yesterday's meeting, Simo said that on the wire and for CLI output, >> we should use generalized time. >> I disagree with using it for CLI ouptut, as I find generalized time >> unreadable, but for the API it's the obvious choice. >> >> I believe we should require the "Z" postfix in all formats, so that 1) >> users are forced to be aware that it's UTC, and 2) we can >> theoretically support local time in the future. >> >> I think the supported input formats should be: >> >> %Y%m%d%H%M%SZ (generalized time) >> %Y-%m-%dT%H:%M:%SZ (ISO 8601, with seconds) >> %Y-%m-%dT%H:%MZ (ISO 8601, without seconds) >> %Y-%m-%dZ (ISO 8601, date only) >> >> I also think we should accept a space instead of the "T", as Petr? >> said above. >> > > Thanks for review, everybody. > > * All accepted formats now require explicit Z > * Accept values with ' ' instead of T > * LDAP generalized time used on the wire with JSON > * Minor implementation fixes > > Updated patch should address all the issues. The first if statement is not necessary here, datetime values are correctly handled in the super class: + def _convert_scalar(self, value, index=None): + if isinstance(value, datetime.datetime): + return value + elif isinstance(value, basestring): Please use ', ' instead of just ',' as the separator to make the error message more readable here: + error = (_("does not match any of accepted formats: ") + + (','.join(self.accepted_formats))) This if statement is not present on old clients, so the assert below will fail on them when they receive DateTime: + if isinstance(value, DateTime): + return datetime.datetime.strptime(str(value), "%Y%m%dT%H:%M:%S") assert type(value) in (unicode, int, float, bool, NoneType) But, they will never receive DateTime from us, because LDAP generalized time is decoded to unicode in ipaldap. What I think we should do is decode LDAP generalized time to datetime objects in ipaldap, add a new capability (e.g. "datetime_values") and use DateTime only for clients with that capability, otherwise use the generalized time string. Also, something similar should be done for JSON, so that clients can infer that a value is datetime and not just a generic string (e.g. wrap it in a dict with '__datetime__', similar to how binary values are wrapped with '__base64__'), again only for clients with the capability. -- Jan Cholasta From jcholast at redhat.com Wed Mar 5 12:10:11 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 05 Mar 2014 13:10:11 +0100 Subject: [Freeipa-devel] [PATCH 0138] ipalib: Expose krbPrincipalExpiration in CLI In-Reply-To: <530C478E.4080307@redhat.com> References: <52CEC0C9.70905@redhat.com> <530C478E.4080307@redhat.com> Message-ID: <53171423.8030204@redhat.com> On 25.2.2014 08:34, Tomas Babej wrote: > Rebased to current master. > > On 01/09/2014 04:31 PM, Tomas Babej wrote: >> Hi, >> >> Adds a krbPrincipalExpiration attribute to the user class >> in user.py ipalib plugin as a DateTime parameter. >> >> Part of: https://fedorahosted.org/freeipa/ticket/3306 >> The patch needs to be rebased again. I think you can drop the "(UTC)" here, as only values ending with "Z" are now accepted for DateTime: + label=_('Kerberos principal expiration (UTC)'), -- Jan Cholasta From pviktori at redhat.com Wed Mar 5 12:48:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Mar 2014 13:48:29 +0100 Subject: [Freeipa-devel] [PATCHES] 0473-0477 Managed permission updater, part 1 In-Reply-To: <53149B54.2050308@redhat.com> References: <530DB78A.4040003@redhat.com> <53108B41.50700@redhat.com> <53109370.7010905@redhat.com> <53149B54.2050308@redhat.com> Message-ID: <53171D1D.2010408@redhat.com> On 03/03/2014 04:10 PM, Petr Viktorin wrote: > On 02/28/2014 02:47 PM, Petr Viktorin wrote: >> On 02/28/2014 02:12 PM, Martin Kosek wrote: >>> On 02/26/2014 10:44 AM, Petr Viktorin wrote: >>>> Hello, >>>> Here are a few fixes/improvements, and the first part of a managed >>>> permission >>>> updater. >>>> >>>> The patches should go in this order but don't need to be ACKed/pushed >>>> all at once. >>>> >>>> >>>> Design: >>>> http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater >>>> >>>> >>>> Part of the work for: https://fedorahosted.org/freeipa/ticket/3566 >>>> >>>> >>>> This part is a "preview" of sorts, to get the basic mechanism and the >>>> metadata >>>> format reviewed before I add all of the default read permissions. >>>> It implements the first section of "Default Permission Updater" in >>>> the design; >>>> "Replacing legacy default permissions" and "Removing the global >>>> anonymous read >>>> ACI" is left for later. >>>> Metadata is added for the netgroup plugin* for starters [...] >>>> >>> >>> 1) 476: Typo in test name: >>> >>> + desc='Search fo rnonexisting permission with ":" in the >>> name', >> >> Will fix. Fixed >>> 2) 477: do we want to log anything when permission is up to date? >>> >>> + try: >>> + ldap.update_entry(entry) >>> + except errors.EmptyModlist: >>> + return >> >> I don't think that's needed, after all that's the expected behavior in >> all but the first upgrade. >> But I'll be happy to add it if you think it would be better. I've added a DEBUG message here. [...] >>> 4) I have been quite resilient to the prefixes for the permissions, >>> but it >>> seems it is the easier possible approach to fix conflicts with user >>> permissions >>> without having to check that later for every upgrade or doing more >>> complex >>> stuff like multiple RDNs or different container for system and user >>> permissions. >>> >>> I am now just thinking about the prefixing. Now you use this name: >>> >>> ipa:Read Netgroups >>> >>> Would it be "nicer" to use: >>> >>> IPA:Read Netgroups >>> or >>> IPA: Read Netgroups >>> or even >>> [IPA] Read Netgroups >>> ? :-) >> >> Bikeshedding time! >> Everyone on the list, please chime in! > > Bikeshedding results from today's meeting: > > "ipa: " pviktori++ > "System: " mkosek++ simo+ ab++ > "Builtin: " simo++ pvo+ > "Default: " > > The winner is "System: ", so I'll go and change to that. Done. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0473.2-Allow-indexing-API-object-types-by-class.patch Type: text/x-patch Size: 4114 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0474.2-permission-find-Fix-handling-of-the-search-term-for-.patch Type: text/x-patch Size: 3632 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0475.2-test_permission_plugin-Fix-tests-that-make-too-broad.patch Type: text/x-patch Size: 6973 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0476.2-Allow-modifying-permissions-with-in-the-name.patch Type: text/x-patch Size: 10996 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0477.2-Add-Object-metadata-and-update-plugin-for-managed-pe.patch Type: text/x-patch Size: 9078 bytes Desc: not available URL: From simo at redhat.com Wed Mar 5 13:21:13 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 05 Mar 2014 08:21:13 -0500 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <5316F403.6010102@redhat.com> References: <52FD02B7.3060404@redhat.com> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <5316513B.6000703@red! hat.com> <53165416.50000@redhat.com> <5316627A.6060702@redhat.com> <1393992645.22047.178.camel@willson.li.ssimo.org> <5316D6CA.5010103@redhat.c! om> <5316F403.6010102@redhat.com> Message-ID: <1394025673.14651.8.camel@willson.li.ssimo.org> On Wed, 2014-03-05 at 10:53 +0100, Petr Spacek wrote: > On 5.3.2014 08:48, Jan Cholasta wrote: > > On 5.3.2014 05:10, Simo Sorce wrote: > >> On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: > >>> Remote means that there is a PKCS#11 library that can be loaded into a > >>> process and would remotely connect to a central server via > >>> LDAP/REST/whatever. My point is that library should be light weight > >>> and always talk to a local service like SSSD rather than have a remote > >>> interface. In this case SSSD on the server can talk to the vault or > >>> IPA LDAP directly and all consumers would use PKCS#11 interface > >>> exposed by SSSD > >>> > >>> Something like this... > >> > >> Yes this is the setting we are discussing, the actual specific > >> discussion is how SSSD gets the information. > >> > >> Honza proposed to use a PKCS#11-like schema to store data in LDAP given > >> DNS will need something similar, however the more we wandered into the > >> discussion the more I got convinced the Vault is probably a better place > >> to store this material than the LDAP tree itself at least for prvate > >> keys. > > > > I only proposed something that would work for my needs (i.e. storing > > certificates and associated trust policy) and would be ready for 4.0. Can you > > say the same thing about the vault? > I agree with Honza. I think that proposed LDAP schema is perfectly fits the > purpose *for public* information like certificates and public keys. And I agree with you and Honza as well that the proposal is ok for *public* information. > >> For public key material only though I am not sure a pkcs#11 schema will > >> necessarily be useful. It might, but we do not use it for public SSH > >> keys. And we also already have schema for public User or Servers X509 > >> certs. > > > > Support for SSH public keys was implemented like 2 years ago, way before any > > talk about the vault or PKCS#11 even started. As for certs, the proposed > > schema works on top of RFC 4523, which is the cert schema you mention. > > > >> > >> We need to define something for DNS public keys, but they are already > >> published in DNS Records too if I am not wrong, would that be sufficient > >> as a storage for the public part ? I am assuming the private keys are > No, we need full PKCS#11 for OpenDNSSEC at least. Well, you need a pkcs#11 library interface, the backing store could be anything, but I do see the advantage of using a common schema so that SSSD can retrieve data to present through that interface in a simplified and consistent way. > Note that PKCS#11 in SSSD will give us generic mechanism for process/key > separation (it is practically the same thing GSS-Proxy, just general purpose). > This comes 'for free' if we implement PKCS#11 so please stop searching for > workarounds :-) I am not looking for workarounds for the interface between SSSD and consuming libraries. I am trying to evaluate what we could use this schema for before jumping into it. > >> stored in the Vault and they can be files in the format used by bind ? > BIND files are very hackish and we need to do PKCS#11->BIND files conversion > anyway because OpenDNSSEC supports only PKCS#11 and nothing else. > > I plan to use PKCS#11 directly from BIND so we can drop the format conversion > code and rely on pure PKCS#11 instead of bunch of hacks scripts. Ok. > > So the information would be scattered in different places, using different > > formats and accessed using different protocols? I'm fine with that, but it is > > way beyond my original idea, so please let whoever is in charge of the vault > > implement the PKCS#11 module themselves. Honza, clearly if something different is proposed work will be split between those that need to implement it in various ways, this will simply require to separate the pkcs#11 module into 2 parts, a 'feeder' that implements the pkcs#11 interface and a pluggable 'gatherer' that implements retrieval for specific stuff. No worries there. > - IMHO public information should be stored in LDAP schema as proposed. > - I agree that Vault is the right choice to store secrets. > - I propose to combine these two: Store public information in LDAP and store > private keys in PKCS#8 blob as a secret in Vault. > - This LDAP+Vault combo can be accessible over PKCS#11 interface. > - Note that this will work even without vault if you want to store public > information only (like CA certs and NSS trust objects). Works for me. > The only problem is that we need to use REST API from SSSD. Plain LDAP is > already implemented in SSSD so it requires less code. I guess that we will > need something like libipavault library... We'll need a helper process unless we can find a fully async library to deal with the vault. Authentication to the vault over REST-like APIs will also be an interesting problem ... Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Wed Mar 5 13:51:57 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Mar 2014 14:51:57 +0100 Subject: [Freeipa-devel] [PATCH] 0487 ipalib.plugable: Always set the parser in bootstrap() Message-ID: <53172BFD.6000607@redhat.com> Hello, This patch fixes a failing test setup where logging was configured before the API was bootstrapped. The __setattr__ is moved before a conditional return. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0487-ipalib.plugable-Always-set-the-parser-in-bootstrap.patch Type: text/x-patch Size: 1791 bytes Desc: not available URL: From simo at redhat.com Wed Mar 5 14:04:14 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 05 Mar 2014 09:04:14 -0500 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <53171319.6030007@redhat.com> References: <52FD02B7.3060404@redhat.com> <1393337468.18299.23.camel@willson.li.ssimo.org> <530CAFE6.1050007@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> Message-ID: <1394028254.14651.10.camel@willson.li.ssimo.org> On Wed, 2014-03-05 at 13:05 +0100, Martin Kosek wrote: > On 03/04/2014 11:14 PM, Petr Spacek wrote: > > On 4.3.2014 22:53, Simo Sorce wrote: > >> On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: > >>> On 4.3.2014 22:15, Simo Sorce wrote: > >>>> On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: > ... > >> I guess my only reservation is about whether DRM storage is replicated > >> or not. Although both the K/M and DNS cases do not require the Vault to > >> be online at all times because the keys will be downloaded and stored > >> locally and only needs to be accessed when they changed, there is the > >> problem of having all keys in a SPOF, that should not happen. > > According to http://www.freeipa.org/page/V4/Password_Vault#Replication the > > replication is available for DRM, we just need to use it. > > > > IMHO a vault without replication is not useful anyway. Users are not happy when > > their passwords disappear ;-) > > > >> The additional thing about the Vault is that we can use key escrow there > >> as a mechanism to re-encrypt automatically system relevant keys when a > >> new server is joined to the realm. > > So we agree that Vault offers what we want so we should use it, right? > > > > I think we should determine if we can use Vault for K/M. It would be another > > reason why we should use Vault instead of a custom solution. > > > > Do we really want to use the heavy machinery Vault for DNSSEC keys? I would > personally like to avoid it and use something more lightweight. > > Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It > needs Tomcat and all the Java machinery, special installation, replication > scheme, difficult debugging etc. In my mind, Vault is a specialized heavy > component that solves specific problems that not every admin may want and thus > may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC). Well keep in mind that you do not need a vault instance on every DNS server, just like a CA a few servers would be sufficient. DNS key rotation happens relatively 'rarely' so the dependency is not a huge problem in terms of performance or management. There is the problem of the heavyweight java-based infrastructure, but we already have that dependency for the CA part, so it's not like we are adding anything new. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Wed Mar 5 14:19:54 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 05 Mar 2014 15:19:54 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <1394025673.14651.8.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <5316513B.6000703@red! hat.com> <53165416.50000@redhat.com> <5316627A.6060702@redhat.com> <1393992645.22047.178.camel@willson.li.ssimo.org> <5316D6CA.5010103@redhat.c! om> <5316F403.6010102@redhat.com> <1394025673.14651.8.camel@willson.li.ssimo.org> Message-ID: <5317328A.4080402@redhat.com> On 5.3.2014 14:21, Simo Sorce wrote: > On Wed, 2014-03-05 at 10:53 +0100, Petr Spacek wrote: >> On 5.3.2014 08:48, Jan Cholasta wrote: >>> On 5.3.2014 05:10, Simo Sorce wrote: >>>> On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: >>>>> Remote means that there is a PKCS#11 library that can be loaded into a >>>>> process and would remotely connect to a central server via >>>>> LDAP/REST/whatever. My point is that library should be light weight >>>>> and always talk to a local service like SSSD rather than have a remote >>>>> interface. In this case SSSD on the server can talk to the vault or >>>>> IPA LDAP directly and all consumers would use PKCS#11 interface >>>>> exposed by SSSD >>>>> >>>>> Something like this... >>>> >>>> Yes this is the setting we are discussing, the actual specific >>>> discussion is how SSSD gets the information. >>>> >>>> Honza proposed to use a PKCS#11-like schema to store data in LDAP given >>>> DNS will need something similar, however the more we wandered into the >>>> discussion the more I got convinced the Vault is probably a better place >>>> to store this material than the LDAP tree itself at least for prvate >>>> keys. >>> >>> I only proposed something that would work for my needs (i.e. storing >>> certificates and associated trust policy) and would be ready for 4.0. Can you >>> say the same thing about the vault? >> I agree with Honza. I think that proposed LDAP schema is perfectly fits the >> purpose *for public* information like certificates and public keys. > > And I agree with you and Honza as well that the proposal is ok for > *public* information. > >>>> For public key material only though I am not sure a pkcs#11 schema will >>>> necessarily be useful. It might, but we do not use it for public SSH >>>> keys. And we also already have schema for public User or Servers X509 >>>> certs. >>> >>> Support for SSH public keys was implemented like 2 years ago, way before any >>> talk about the vault or PKCS#11 even started. As for certs, the proposed >>> schema works on top of RFC 4523, which is the cert schema you mention. >>> >>>> >>>> We need to define something for DNS public keys, but they are already >>>> published in DNS Records too if I am not wrong, would that be sufficient >>>> as a storage for the public part ? I am assuming the private keys are >> No, we need full PKCS#11 for OpenDNSSEC at least. > > Well, you need a pkcs#11 library interface, the backing store could be anything, > but I do see the advantage of using a common schema so that SSSD can retrieve data > to present through that interface in a simplified and consistent way. > >> Note that PKCS#11 in SSSD will give us generic mechanism for process/key >> separation (it is practically the same thing GSS-Proxy, just general purpose). >> This comes 'for free' if we implement PKCS#11 so please stop searching for >> workarounds :-) > > I am not looking for workarounds for the interface between SSSD and > consuming libraries. I am trying to evaluate what we could use this > schema for before jumping into it. > >>>> stored in the Vault and they can be files in the format used by bind ? >> BIND files are very hackish and we need to do PKCS#11->BIND files conversion >> anyway because OpenDNSSEC supports only PKCS#11 and nothing else. >> >> I plan to use PKCS#11 directly from BIND so we can drop the format conversion >> code and rely on pure PKCS#11 instead of bunch of hacks scripts. > > Ok. > >>> So the information would be scattered in different places, using different >>> formats and accessed using different protocols? I'm fine with that, but it is >>> way beyond my original idea, so please let whoever is in charge of the vault >>> implement the PKCS#11 module themselves. > > Honza, clearly if something different is proposed work will be split > between those that need to implement it in various ways, this will > simply require to separate the pkcs#11 module into 2 parts, a 'feeder' > that implements the pkcs#11 interface and a pluggable 'gatherer' that > implements retrieval for specific stuff. No worries there. Sounds good. (But I must admit I was a little bit scared for a moment :-) > >> - IMHO public information should be stored in LDAP schema as proposed. >> - I agree that Vault is the right choice to store secrets. >> - I propose to combine these two: Store public information in LDAP and store >> private keys in PKCS#8 blob as a secret in Vault. >> - This LDAP+Vault combo can be accessible over PKCS#11 interface. >> - Note that this will work even without vault if you want to store public >> information only (like CA certs and NSS trust objects). > > Works for me. +1 > >> The only problem is that we need to use REST API from SSSD. Plain LDAP is >> already implemented in SSSD so it requires less code. I guess that we will >> need something like libipavault library... > > We'll need a helper process unless we can find a fully async library to > deal with the vault. Authentication to the vault over REST-like APIs > will also be an interesting problem ... > > Simo. > -- Jan Cholasta From swalter at redhat.com Wed Mar 5 12:20:52 2014 From: swalter at redhat.com (Stef Walter) Date: Wed, 05 Mar 2014 13:20:52 +0100 Subject: [Freeipa-devel] LDAP schema for PKCS#11 In-Reply-To: <5314909E.9030502@redhat.com> References: <53146CC4.8010200@redhat.com> <53147A50.3070901@redhat.com> <531483F1.6070005@redhat.com> <53148911.4090606@redhat.com> <53148B97.4020900@redhat.com> <53148CA5.2040009@redhat.com> <5314909E.9030502@redhat.com> Message-ID: <531716A4.6060600@redhat.com> On 03.03.2014 15:24, Jan Cholasta wrote: > On 3.3.2014 15:07, Stef Walter wrote: >> On 03.03.2014 15:03, Jan Cholasta wrote: >>> If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust >>> objects from the module? >> >> No. This is the spec for storing trust policy in PKCS#11 that we've been >> working on: >> >> http://p11-glue.freedesktop.org/doc/storing-trust-policy/ >> >> It's a far more extensible and future proof model. The p11-kit-trust >> module stores/loads these sorts of objects, and additionally also >> generates NSS trust objects on the fly so that NSS can consume the >> information. >> >> It doesn't do that last bit for third party sources, but it could given >> code :) > > Code is not a problem :) > > What would be the best way to provide trust policy to p11-kit from a > third party PKCS#11 module, if not NSS trust objects? I obviously think that using the new stuff linked above would be best. It's future proof and models this comprehensively. That would allow extracting compat trust anchors to files (for crypto libraries that don't yet support looking it up trust via PKCS#11). But I understand if you're hesitant to commit to this spec that's in development (albeit already implemented). There's a third simple way to store trust, which is using standard PKCS#11. It's very limited: * Store certificates with the CKA_TRUSTED attribute set to CKA_TRUE and CKA_CERTIFICATE_CATEGORY set to 2. This method covers storing certificate authority anchors only. The above spec is a superset of this simple way of storing trust. NSS trust objects are not. So I would suggest implementing this simple mechanism and then implement the full spec later. If you want to have a call/hangout about this and discuss, I'd be happy to. Cheers, Stef From pviktori at redhat.com Wed Mar 5 14:51:15 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Mar 2014 15:51:15 +0100 Subject: [Freeipa-devel] [PATCH] 0235 tests: Use ipa-getkeytab from /usr/sbin instead of the in-tree one In-Reply-To: <5241B121.6090203@redhat.com> References: <51ADD407.6020100@redhat.com> <1370350403.2744.15.camel@willson.li.ssimo.org> <51AE06A5.4030301@redhat.com> <1370360902.2744.40.camel@willson.li.ssimo.org> <5241B121.6090203@redhat.com> Message-ID: <531739E3.1080603@redhat.com> On 09/24/2013 05:34 PM, Petr Viktorin wrote: > On 06/04/2013 05:48 PM, Simo Sorce wrote: >> On Tue, 2013-06-04 at 17:24 +0200, Petr Viktorin wrote: >>> On 06/04/2013 02:53 PM, Simo Sorce wrote: >>>> On Tue, 2013-06-04 at 13:48 +0200, Petr Viktorin wrote: >>>>> Hardcoding the in-tree location for ipa-getkeytab makes testing >>>>> outside >>>>> the source tree impossible. This patch makes the tests use the >>>>> installed >>>>> location. >>>>> >>>>> In other places the test suite assumes IPA is installed system-wide, >>>>> even if running from the source tree. >>>>> I know I frequently forget to run `make` before testing, which >>>>> makes the >>>>> ipa-getkeytab tests fail. So this patch would work well for me (and >>>>> probably other Python devs), but I guess others might be used to `make >>>>> test` checking what `make` built. >>>>> >>>>> C developers, are you OK with e.g. adding `cp ipa-client/ipa-getkeytab >>>>> /usr/sbin/ipa-getkeytab` to your testing workflow? >>>> >>>> Absolutely not. >>>> >>>>> Or should this be made configurable (or auto-detected)? >>>> >>>> You must not break a machine just to do make test. >>>> >>>> I often do make test, then make rpms and install rpms, I *never* >>>> directly install on my development machine or VMs, I always go through >>>> RPM in order to keep the system clean, and tests repeatable. >>> >>> I do the same except I never run make test on the development machine -- >>> without IPA installed the tests don't work. >>> >>>> ipa-getkeytab specifically do not need root to be tested so I really do >>>> not see that copying over a system path would ever be a good idea. >>>> >>>> Simo. >>> >>> >>> With this version of the patch, the tests use ipa-getkeytab from $PATH, >>> and the in-tree directory is added to PATH in make-test. Out-of-tree >>> tests don't use make-test so they will use the system PATH. >>> Is that OK? >>> >> >> Sounds good to me. >> >> Simo. >> > > Ping, could someone look at this patch? > It should fix 7 of the 11 failures that happen when running the test > suite out of tree. > Attaching a slightly updated version. Any takers? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0235.3-Do-not-hardcode-path-to-ipa-getkeytab-in-tests.patch Type: text/x-patch Size: 3293 bytes Desc: not available URL: From pspacek at redhat.com Wed Mar 5 15:02:33 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 05 Mar 2014 16:02:33 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <1394025673.14651.8.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <5316513B.6000703@red! hat.com> <53165416.50000@redhat.com> <5316627A.6060702@redhat.com> <1393992645.22047.178.camel@willson.li.ssimo.org> <5316D6CA.5010103@redhat.c! om> <5316F403.6010102@redhat.com> <1394025673.14651.8.camel@willson.li.ssimo.org> Message-ID: <53173C89.6050509@redhat.com> On 5.3.2014 14:21, Simo Sorce wrote: > On Wed, 2014-03-05 at 10:53 +0100, Petr Spacek wrote: >> On 5.3.2014 08:48, Jan Cholasta wrote: >>> On 5.3.2014 05:10, Simo Sorce wrote: >>>> On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: >>>>> Remote means that there is a PKCS#11 library that can be loaded into a >>>>> process and would remotely connect to a central server via >>>>> LDAP/REST/whatever. My point is that library should be light weight >>>>> and always talk to a local service like SSSD rather than have a remote >>>>> interface. In this case SSSD on the server can talk to the vault or >>>>> IPA LDAP directly and all consumers would use PKCS#11 interface >>>>> exposed by SSSD >>>>> >>>>> Something like this... >>>> >>>> Yes this is the setting we are discussing, the actual specific >>>> discussion is how SSSD gets the information. >>>> >>>> Honza proposed to use a PKCS#11-like schema to store data in LDAP given >>>> DNS will need something similar, however the more we wandered into the >>>> discussion the more I got convinced the Vault is probably a better place >>>> to store this material than the LDAP tree itself at least for prvate >>>> keys. >>> >>> I only proposed something that would work for my needs (i.e. storing >>> certificates and associated trust policy) and would be ready for 4.0. Can you >>> say the same thing about the vault? >> I agree with Honza. I think that proposed LDAP schema is perfectly fits the >> purpose *for public* information like certificates and public keys. > > And I agree with you and Honza as well that the proposal is ok for > *public* information. > >>>> For public key material only though I am not sure a pkcs#11 schema will >>>> necessarily be useful. It might, but we do not use it for public SSH >>>> keys. And we also already have schema for public User or Servers X509 >>>> certs. >>> >>> Support for SSH public keys was implemented like 2 years ago, way before any >>> talk about the vault or PKCS#11 even started. As for certs, the proposed >>> schema works on top of RFC 4523, which is the cert schema you mention. >>> >>>> >>>> We need to define something for DNS public keys, but they are already >>>> published in DNS Records too if I am not wrong, would that be sufficient >>>> as a storage for the public part ? I am assuming the private keys are >> No, we need full PKCS#11 for OpenDNSSEC at least. > > Well, you need a pkcs#11 library interface, the backing store could be anything, > but I do see the advantage of using a common schema so that SSSD can retrieve data > to present through that interface in a simplified and consistent way. > >> Note that PKCS#11 in SSSD will give us generic mechanism for process/key >> separation (it is practically the same thing GSS-Proxy, just general purpose). >> This comes 'for free' if we implement PKCS#11 so please stop searching for >> workarounds :-) > > I am not looking for workarounds for the interface between SSSD and > consuming libraries. I am trying to evaluate what we could use this > schema for before jumping into it. > >>>> stored in the Vault and they can be files in the format used by bind ? >> BIND files are very hackish and we need to do PKCS#11->BIND files conversion >> anyway because OpenDNSSEC supports only PKCS#11 and nothing else. >> >> I plan to use PKCS#11 directly from BIND so we can drop the format conversion >> code and rely on pure PKCS#11 instead of bunch of hacks scripts. > > Ok. > >>> So the information would be scattered in different places, using different >>> formats and accessed using different protocols? I'm fine with that, but it is >>> way beyond my original idea, so please let whoever is in charge of the vault >>> implement the PKCS#11 module themselves. > > Honza, clearly if something different is proposed work will be split > between those that need to implement it in various ways, this will > simply require to separate the pkcs#11 module into 2 parts, a 'feeder' > that implements the pkcs#11 interface and a pluggable 'gatherer' that > implements retrieval for specific stuff. No worries there. > >> - IMHO public information should be stored in LDAP schema as proposed. >> - I agree that Vault is the right choice to store secrets. >> - I propose to combine these two: Store public information in LDAP and store >> private keys in PKCS#8 blob as a secret in Vault. >> - This LDAP+Vault combo can be accessible over PKCS#11 interface. >> - Note that this will work even without vault if you want to store public >> information only (like CA certs and NSS trust objects). > > Works for me. > >> The only problem is that we need to use REST API from SSSD. Plain LDAP is >> already implemented in SSSD so it requires less code. I guess that we will >> need something like libipavault library... > > We'll need a helper process unless we can find a fully async library to > deal with the vault. Authentication to the vault over REST-like APIs > will also be an interesting problem ... Let me summarize what we have: We agree that ============= - PKCS#11 is the right interface for key manipulation and certificate retrieval. - We can have PKCS#11 client library talking to local SSSD so the data retrieval logic can be hidden in SSSD (something like "PKCS-responder"). Open questions/variants to discuss are ============== a) Do not invent any new schema for certificates and public keys. A set of "PKCS-providers" in SSSD will aggregate the data from various sources and transform them to appropriate format. A heavy machinery in SSSD will convert existing data in IPA LDAP tree to PKCS#11 objects presented over PKCS#11 interface. - CA certs will be pulled from cn=CAcert,cn=ipa,cn=etc,dc=ipa,dc=example and transformed to required format. ("PKCS-CA-provider") - Other data except DNSSEC keys (like user certificates) will be handled specially by special provider. (Most likely this provider will stay unimplemented :-)) - DNS public keys can be stored as DNS records and converted to format appropriate for PKCS#11 somehow. One problem is that sometimes you need to generate keys but do not publish them in DNS zone. Situations like this will require special handling. ("PKCS-DNSSEC-provider") - DNS private keys are special case because they require special handling for key wrapping. Sub-variant are: aa) Use IPA vault. It requires Vault support in IPA 4.0 (for DNSSEC) and also client-side support in SSSD. (special "PKCS-DNSSEC-vault-provider") ab) Use some simpler single-purpose key wrapping mechanism designed specially for DNSSEC. Implement the key un/wrapping in special code path in SSSD. ("PKCS-DNSSEC-simple-provider") b) Use a new schema for generic PKCS#11 module in LDAP. The generic "PKCS-ldap-provider" will simply 1:1 map the data in LDAP to objects presented over PKCS#11 interface. - DNS public keys, CA certs and generally all public data will be stored in the new schema in plain text. - This approach supports user certificates and all other use cases out of the box. - Private keys needs special handling: aa) Use IPA vault. It requires Vault support in IPA 4.0 (for DNSSEC) and also client-side support in SSSD. ab) Use some simpler single-purpose key wrapping mechanism. (Proposal with wrapping keys stored in LDAP is on the mailing list.) Implement the key un/wrapping in special code path in "PKCS-ldap-provider". The difference is that now we don't need to call any REST API from SSSD and we can read all the data from LDAP or file system. Personally, I agree with the pluggable approach with various PKCS providers but I still can see the value in variant (b) with LDAP schema designed specifically for PKCS#11. It enables us to use generic PKCS#11 interface in all applications and we do not need to tweak SSSD providers specifically for each use case. IMHO it is also easier to implement on SSSD side of things. The only problem is that we didn't agree on a key wrapping mechanism. Maybe we can start with generic LDAP schema and some simple key wrapping mechanism for now and gradually add support for Vault in the future. SSSD will be pluggable so we will not be tied to the simpler mechanism forever. Also, I'm not insisting on storing wrapping keys in LDAP. In theory, we could store one wrapping key per-user on disk and let SSSD to read that key when user logs in. Let's finally decide what to do! Please keep in mind that we need something feasible and reasonably secure for DNSSEC and CA rotation 4.0. -- Petr^2 Spacek From derek.p.moore at gmail.com Wed Mar 5 15:25:44 2014 From: derek.p.moore at gmail.com (Derek Moore) Date: Wed, 5 Mar 2014 09:25:44 -0600 Subject: [Freeipa-devel] LDAP schema for PKCS#11 In-Reply-To: <53146CC4.8010200@redhat.com> References: <53146CC4.8010200@redhat.com> Message-ID: In your descriptions, can you translate all acronyms according to: http://www.cryptsoft.com/pkcs11doc/v220/group__SEC__5__SYMBOLS__AND__ABBREVIATIONS.html ...and... http://www.cryptsoft.com/pkcs11doc/v220/group__SEC__10__2__COMMON__ATTRIBUTES.html E.g., instead of saying " pkcs11certificateCategory" is "represent CKA_CERTIFICATE_CATEGORY", can you say, "Categorization of the certificate: 0 = unspecified (default value), 1 = token user, 2 = authority, 3 = other entity" or whatever the translation of that enumeration might be in LDAP. You have good descriptions throughout your spec, but don't put those descriptions into your rfc2252 LDAP attribute definitions where they belong. Also, how are you deciding on capitalization in all cases? E.g, pkcs11uniqueid vs. pkcs11uniqueId vs. pkcs11uniqueID. See #3.5, supposed to be pkcs11nsstrust (pkcs11nssTrust?), but it starts with "( .2.5 NAME 'pkcs11certificate' ". I guess the crux of my recommendation is: make your schema entirely independent of the PKCS#11 standard. In other words, incorporate more of the standard's language into your actual schema definition file, so that users don't have to constantly compare and contrast against separate documents. Removing or at least demoting PKCS#11 C library #define artifacts. Thanks, Derek On Mon, Mar 3, 2014 at 5:51 AM, Ludwig Krispenz wrote: > Hi, > > starting a new thread, after a lot of discussion and feedback, which I > tried to integrate into thecurrent draft at: > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/pkcs11Schema > > Here are some design decisions I made and which need to be finally decided. > > 1] Add nss trust objects. > These are not defined in the PKCS#11 standard, but Jan said they will be > needed and I added them to the spec > > 2] Certificate representation > In pkcs11 there is a certificate category (user, authority, ..) and > certificate value. An alternate way to represent this would be to use the > schema defined in rfc4523 and map > (user, value) --> (objectclass: pkiUser, usercertificate) and (authority, > value) --> (objectclass: pkiCA, cAcertificate) > I kept the attributes pkcs11certificateCategory and pkcs11certificateValue > and let the applications decide which format will be used. > > 3] Key attributes > Like certificates keys can be stored ina single attribute as pkcs8 or > bind.key format. In pkcs11 the keys are defined by their algoritthm > specific attributes, I had defined RSA specific attributes (moduleus, > exponent, ....) and did not remove them. Maybe some app wants to create > keys and store these attrs, having defined them does not force to use them, > but allows flexibility without requiring new attribute definitions > > 4] Not needed attributes. > Jan pointed out that some of the attributes like CKA_TOKEN will always be > true, so no need to define them. > I have not yet removed them, they don't nned to be used, but I can still > remove them. > > 5] Attribute syntaxes > I associated boolean attributes with the ldap boolean syntax, which > requires TRUE/FALSE as values > There are a couple of attributes with a limited range like key_type which > has values like: CKK_RSA, CKK_DSA, CKK_DH. There are defines for these > values which translate them to integers, which could be used, but I propose > to use a syntax of directoryString and use the values directly eg > pkcs11keyType: CKK_RSA. To me this is more readable than pkcs11keyType: 0 > And it would have to be parsed anywy > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Mar 5 15:29:20 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 05 Mar 2014 16:29:20 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <1394028254.14651.10.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> Message-ID: <531742D0.9050203@redhat.com> On 03/05/2014 03:04 PM, Simo Sorce wrote: > On Wed, 2014-03-05 at 13:05 +0100, Martin Kosek wrote: >> On 03/04/2014 11:14 PM, Petr Spacek wrote: >>> On 4.3.2014 22:53, Simo Sorce wrote: >>>> On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: >>>>> On 4.3.2014 22:15, Simo Sorce wrote: >>>>>> On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: >> ... >>>> I guess my only reservation is about whether DRM storage is replicated >>>> or not. Although both the K/M and DNS cases do not require the Vault to >>>> be online at all times because the keys will be downloaded and stored >>>> locally and only needs to be accessed when they changed, there is the >>>> problem of having all keys in a SPOF, that should not happen. >>> According to http://www.freeipa.org/page/V4/Password_Vault#Replication the >>> replication is available for DRM, we just need to use it. >>> >>> IMHO a vault without replication is not useful anyway. Users are not happy when >>> their passwords disappear ;-) >>> >>>> The additional thing about the Vault is that we can use key escrow there >>>> as a mechanism to re-encrypt automatically system relevant keys when a >>>> new server is joined to the realm. >>> So we agree that Vault offers what we want so we should use it, right? >>> >>> I think we should determine if we can use Vault for K/M. It would be another >>> reason why we should use Vault instead of a custom solution. >>> >> >> Do we really want to use the heavy machinery Vault for DNSSEC keys? I would >> personally like to avoid it and use something more lightweight. >> >> Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It >> needs Tomcat and all the Java machinery, special installation, replication >> scheme, difficult debugging etc. In my mind, Vault is a specialized heavy >> component that solves specific problems that not every admin may want and thus >> may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC). > > Well keep in mind that you do not need a vault instance on every DNS > server, just like a CA a few servers would be sufficient. DNS key > rotation happens relatively 'rarely' so the dependency is not a huge > problem in terms of performance or management. There is the problem of > the heavyweight java-based infrastructure, but we already have that > dependency for the CA part, so it's not like we are adding anything new. Yeah, but the plan is not force people to have the heavy weight Java infrastructure on each server so that they are able to create more lightweight servers only with components they choose: https://fedorahosted.org/freeipa/ticket/4058 Martin From jcholast at redhat.com Wed Mar 5 16:02:21 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 05 Mar 2014 17:02:21 +0100 Subject: [Freeipa-devel] [PATCH] 0487 ipalib.plugable: Always set the parser in bootstrap() In-Reply-To: <53172BFD.6000607@redhat.com> References: <53172BFD.6000607@redhat.com> Message-ID: <53174A8D.8060402@redhat.com> On 5.3.2014 14:51, Petr Viktorin wrote: > Hello, > This patch fixes a failing test setup where logging was configured > before the API was bootstrapped. > The __setattr__ is moved before a conditional return. ACK, the test failures are gone. -- Jan Cholasta From simo at redhat.com Wed Mar 5 16:06:40 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 05 Mar 2014 11:06:40 -0500 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <531742D0.9050203@redhat.com> References: <52FD02B7.3060404@redhat.com> <1393341105.18299.36.camel@willson.li.ssimo.org> <530CB463.4000804@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> Message-ID: <1394035600.14651.13.camel@willson.li.ssimo.org> On Wed, 2014-03-05 at 16:29 +0100, Martin Kosek wrote: > On 03/05/2014 03:04 PM, Simo Sorce wrote: > > On Wed, 2014-03-05 at 13:05 +0100, Martin Kosek wrote: > >> On 03/04/2014 11:14 PM, Petr Spacek wrote: > >>> On 4.3.2014 22:53, Simo Sorce wrote: > >>>> On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: > >>>>> On 4.3.2014 22:15, Simo Sorce wrote: > >>>>>> On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: > >> ... > >>>> I guess my only reservation is about whether DRM storage is replicated > >>>> or not. Although both the K/M and DNS cases do not require the Vault to > >>>> be online at all times because the keys will be downloaded and stored > >>>> locally and only needs to be accessed when they changed, there is the > >>>> problem of having all keys in a SPOF, that should not happen. > >>> According to http://www.freeipa.org/page/V4/Password_Vault#Replication the > >>> replication is available for DRM, we just need to use it. > >>> > >>> IMHO a vault without replication is not useful anyway. Users are not happy when > >>> their passwords disappear ;-) > >>> > >>>> The additional thing about the Vault is that we can use key escrow there > >>>> as a mechanism to re-encrypt automatically system relevant keys when a > >>>> new server is joined to the realm. > >>> So we agree that Vault offers what we want so we should use it, right? > >>> > >>> I think we should determine if we can use Vault for K/M. It would be another > >>> reason why we should use Vault instead of a custom solution. > >>> > >> > >> Do we really want to use the heavy machinery Vault for DNSSEC keys? I would > >> personally like to avoid it and use something more lightweight. > >> > >> Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It > >> needs Tomcat and all the Java machinery, special installation, replication > >> scheme, difficult debugging etc. In my mind, Vault is a specialized heavy > >> component that solves specific problems that not every admin may want and thus > >> may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC). > > > > Well keep in mind that you do not need a vault instance on every DNS > > server, just like a CA a few servers would be sufficient. DNS key > > rotation happens relatively 'rarely' so the dependency is not a huge > > problem in terms of performance or management. There is the problem of > > the heavyweight java-based infrastructure, but we already have that > > dependency for the CA part, so it's not like we are adding anything new. > > Yeah, but the plan is not force people to have the heavy weight Java > infrastructure on each server so that they are able to create more lightweight > servers only with components they choose: > > https://fedorahosted.org/freeipa/ticket/4058 Yes, but the Vault does not need to be installed on each server, just on a couple of them like for the CA. In particular it doesn't need to be installed on the same servers that offer the DNS service. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Wed Mar 5 16:38:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 05 Mar 2014 17:38:09 +0100 Subject: [Freeipa-devel] [PATCH] 0488 tests: Create the testing service certificate on demand Message-ID: <531752F1.7040606@redhat.com> Hello, This transforms the make-testcert command into a module that creates the certificate when it is first needed. As a result the tests are more self-contained, and can be run from a read-only location (such as from the freeipa-tests package). With 0235, 0487, and this patch, `ipa-run-tests` passes. (It logs too much so it doesn't look pretty, but it passes.) -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0488-tests-Create-the-testing-service-certificate-on-dema.patch Type: text/x-patch Size: 19751 bytes Desc: not available URL: From jcholast at redhat.com Wed Mar 5 16:56:25 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 05 Mar 2014 17:56:25 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <53173C89.6050509@redhat.com> References: <52FD02B7.3060404@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <5316513B.6000703@red! hat.com> <53165416.50000@redhat.com> <5316627A.6060702@redhat.com> <1393992645.22047.178.camel@willson.li.ssimo.org> <5316D6CA.5010103@redhat.c! om> <5316F403.6010102@redhat.com> <1394025673.14651.8.camel@willson.li.ssimo.org> <53173C89.6050509@redhat.com> Message-ID: <53175739.30608@redhat.com> On 5.3.2014 16:02, Petr Spacek wrote: > On 5.3.2014 14:21, Simo Sorce wrote: >> On Wed, 2014-03-05 at 10:53 +0100, Petr Spacek wrote: >>> On 5.3.2014 08:48, Jan Cholasta wrote: >>>> On 5.3.2014 05:10, Simo Sorce wrote: >>>>> On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: >>>>>> Remote means that there is a PKCS#11 library that can be loaded >>>>>> into a >>>>>> process and would remotely connect to a central server via >>>>>> LDAP/REST/whatever. My point is that library should be light weight >>>>>> and always talk to a local service like SSSD rather than have a >>>>>> remote >>>>>> interface. In this case SSSD on the server can talk to the vault or >>>>>> IPA LDAP directly and all consumers would use PKCS#11 interface >>>>>> exposed by SSSD >>>>>> >>>>>> Something like this... >>>>> >>>>> Yes this is the setting we are discussing, the actual specific >>>>> discussion is how SSSD gets the information. >>>>> >>>>> Honza proposed to use a PKCS#11-like schema to store data in LDAP >>>>> given >>>>> DNS will need something similar, however the more we wandered into the >>>>> discussion the more I got convinced the Vault is probably a better >>>>> place >>>>> to store this material than the LDAP tree itself at least for prvate >>>>> keys. >>>> >>>> I only proposed something that would work for my needs (i.e. storing >>>> certificates and associated trust policy) and would be ready for >>>> 4.0. Can you >>>> say the same thing about the vault? >>> I agree with Honza. I think that proposed LDAP schema is perfectly >>> fits the >>> purpose *for public* information like certificates and public keys. >> >> And I agree with you and Honza as well that the proposal is ok for >> *public* information. >> >>>>> For public key material only though I am not sure a pkcs#11 schema >>>>> will >>>>> necessarily be useful. It might, but we do not use it for public SSH >>>>> keys. And we also already have schema for public User or Servers X509 >>>>> certs. >>>> >>>> Support for SSH public keys was implemented like 2 years ago, way >>>> before any >>>> talk about the vault or PKCS#11 even started. As for certs, the >>>> proposed >>>> schema works on top of RFC 4523, which is the cert schema you mention. >>>> >>>>> >>>>> We need to define something for DNS public keys, but they are already >>>>> published in DNS Records too if I am not wrong, would that be >>>>> sufficient >>>>> as a storage for the public part ? I am assuming the private keys are >>> No, we need full PKCS#11 for OpenDNSSEC at least. >> >> Well, you need a pkcs#11 library interface, the backing store could be >> anything, >> but I do see the advantage of using a common schema so that SSSD can >> retrieve data >> to present through that interface in a simplified and consistent way. >> >>> Note that PKCS#11 in SSSD will give us generic mechanism for process/key >>> separation (it is practically the same thing GSS-Proxy, just general >>> purpose). >>> This comes 'for free' if we implement PKCS#11 so please stop >>> searching for >>> workarounds :-) >> >> I am not looking for workarounds for the interface between SSSD and >> consuming libraries. I am trying to evaluate what we could use this >> schema for before jumping into it. >> >>>>> stored in the Vault and they can be files in the format used by bind ? >>> BIND files are very hackish and we need to do PKCS#11->BIND files >>> conversion >>> anyway because OpenDNSSEC supports only PKCS#11 and nothing else. >>> >>> I plan to use PKCS#11 directly from BIND so we can drop the format >>> conversion >>> code and rely on pure PKCS#11 instead of bunch of hacks scripts. >> >> Ok. >> >>>> So the information would be scattered in different places, using >>>> different >>>> formats and accessed using different protocols? I'm fine with that, >>>> but it is >>>> way beyond my original idea, so please let whoever is in charge of >>>> the vault >>>> implement the PKCS#11 module themselves. >> >> Honza, clearly if something different is proposed work will be split >> between those that need to implement it in various ways, this will >> simply require to separate the pkcs#11 module into 2 parts, a 'feeder' >> that implements the pkcs#11 interface and a pluggable 'gatherer' that >> implements retrieval for specific stuff. No worries there. >> >>> - IMHO public information should be stored in LDAP schema as proposed. >>> - I agree that Vault is the right choice to store secrets. >>> - I propose to combine these two: Store public information in LDAP >>> and store >>> private keys in PKCS#8 blob as a secret in Vault. >>> - This LDAP+Vault combo can be accessible over PKCS#11 interface. >>> - Note that this will work even without vault if you want to store >>> public >>> information only (like CA certs and NSS trust objects). >> >> Works for me. >> >>> The only problem is that we need to use REST API from SSSD. Plain >>> LDAP is >>> already implemented in SSSD so it requires less code. I guess that we >>> will >>> need something like libipavault library... >> >> We'll need a helper process unless we can find a fully async library to >> deal with the vault. Authentication to the vault over REST-like APIs >> will also be an interesting problem ... > > Let me summarize what we have: > > We agree that > ============= > - PKCS#11 is the right interface for key manipulation and certificate > retrieval. > - We can have PKCS#11 client library talking to local SSSD so the data > retrieval logic can be hidden in SSSD (something like "PKCS-responder"). > > > Open questions/variants to discuss are > ============== > a) Do not invent any new schema for certificates and public keys. A set > of "PKCS-providers" in SSSD will aggregate the data from various sources > and transform them to appropriate format. > > A heavy machinery in SSSD will convert existing data in IPA LDAP tree to > PKCS#11 objects presented over PKCS#11 interface. Petr requested a diagram for this scenario; see attachment. > > - CA certs will be pulled from cn=CAcert,cn=ipa,cn=etc,dc=ipa,dc=example > and transformed to required format. ("PKCS-CA-provider") (note: actually, not cn=CAcert) > - Other data except DNSSEC keys (like user certificates) will be handled > specially by special provider. (Most likely this provider will stay > unimplemented :-)) > - DNS public keys can be stored as DNS records and converted to format > appropriate for PKCS#11 somehow. One problem is that sometimes you need > to generate keys but do not publish them in DNS zone. Situations like > this will require special handling. ("PKCS-DNSSEC-provider") > - DNS private keys are special case because they require special > handling for key wrapping. Sub-variant are: > aa) Use IPA vault. It requires Vault support in IPA 4.0 (for DNSSEC) > and also client-side support in SSSD. (special > "PKCS-DNSSEC-vault-provider") > ab) Use some simpler single-purpose key wrapping mechanism designed > specially for DNSSEC. Implement the key un/wrapping in special code path > in SSSD. ("PKCS-DNSSEC-simple-provider") > > > b) Use a new schema for generic PKCS#11 module in LDAP. The generic > "PKCS-ldap-provider" will simply 1:1 map the data in LDAP to objects > presented over PKCS#11 interface. > - DNS public keys, CA certs and generally all public data will be stored > in the new schema in plain text. > - This approach supports user certificates and all other use cases out > of the box. > - Private keys needs special handling: > aa) Use IPA vault. It requires Vault support in IPA 4.0 (for DNSSEC) > and also client-side support in SSSD. > ab) Use some simpler single-purpose key wrapping mechanism. (Proposal > with wrapping keys stored in LDAP is on the mailing list.) Implement the > key un/wrapping in special code path in "PKCS-ldap-provider". The > difference is that now we don't need to call any REST API from SSSD and > we can read all the data from LDAP or file system. > > > Personally, I agree with the pluggable approach with various PKCS > providers but I still can see the value in variant (b) with LDAP schema > designed specifically for PKCS#11. +1 > > It enables us to use generic PKCS#11 interface in all applications and > we do not need to tweak SSSD providers specifically for each use case. > IMHO it is also easier to implement on SSSD side of things. The only > problem is that we didn't agree on a key wrapping mechanism. > > > Maybe we can start with generic LDAP schema and some simple key wrapping > mechanism for now and gradually add support for Vault in the future. > SSSD will be pluggable so we will not be tied to the simpler mechanism > forever. > > Also, I'm not insisting on storing wrapping keys in LDAP. In theory, we > could store one wrapping key per-user on disk and let SSSD to read that > key when user logs in. > > Let's finally decide what to do! Please keep in mind that we need > something feasible and reasonably secure for DNSSEC and CA rotation 4.0. > -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd-pkcs11.svg Type: image/svg+xml Size: 23406 bytes Desc: not available URL: From jcholast at redhat.com Wed Mar 5 17:02:44 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 05 Mar 2014 18:02:44 +0100 Subject: [Freeipa-devel] LDAP schema for PKCS#11 In-Reply-To: <531716A4.6060600@redhat.com> References: <53146CC4.8010200@redhat.com> <53147A50.3070901@redhat.com> <531483F1.6070005@redhat.com> <53148911.4090606@redhat.com> <53148B97.4020900@redhat.com> <53148CA5.2040009@redhat.com> <5314909E.9030502@redhat.com> <531716A4.6060600@redhat.com> Message-ID: <531758B4.8050004@redhat.com> On 5.3.2014 13:20, Stef Walter wrote: > On 03.03.2014 15:24, Jan Cholasta wrote: >> On 3.3.2014 15:07, Stef Walter wrote: >>> On 03.03.2014 15:03, Jan Cholasta wrote: >>>> If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust >>>> objects from the module? >>> >>> No. This is the spec for storing trust policy in PKCS#11 that we've been >>> working on: >>> >>> http://p11-glue.freedesktop.org/doc/storing-trust-policy/ >>> >>> It's a far more extensible and future proof model. The p11-kit-trust >>> module stores/loads these sorts of objects, and additionally also >>> generates NSS trust objects on the fly so that NSS can consume the >>> information. >>> >>> It doesn't do that last bit for third party sources, but it could given >>> code :) >> >> Code is not a problem :) >> >> What would be the best way to provide trust policy to p11-kit from a >> third party PKCS#11 module, if not NSS trust objects? > > I obviously think that using the new stuff linked above would be best. > It's future proof and models this comprehensively. That would allow > extracting compat trust anchors to files (for crypto libraries that > don't yet support looking it up trust via PKCS#11). > > But I understand if you're hesitant to commit to this spec that's in > development (albeit already implemented). Actually, I like it. Is everything mentioned at going to be standardized? > > There's a third simple way to store trust, which is using standard > PKCS#11. It's very limited: > > * Store certificates with the CKA_TRUSTED attribute set to CKA_TRUE > and CKA_CERTIFICATE_CATEGORY set to 2. > > This method covers storing certificate authority anchors only. The above > spec is a superset of this simple way of storing trust. NSS trust > objects are not. > > So I would suggest implementing this simple mechanism and then implement > the full spec later. I'm afraid this is simple too much. > > If you want to have a call/hangout about this and discuss, I'd be happy to. Thanks! > > Cheers, > > Stef > -- Jan Cholasta From simo at redhat.com Wed Mar 5 22:18:18 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 05 Mar 2014 17:18:18 -0500 Subject: [Freeipa-devel] [PATCHES] [RFC] New getkeytab operation Message-ID: <1394057898.14651.40.camel@willson.li.ssimo.org> Hello, this is a patchset I have been brewing for quite some time. It addresses primarily ticket #3859 however the implementation implicitly also addresses tickets #232 (effective only if we change permissions and break the old interface so only potentially but not immediately) and #233. The patchset is marked [RFC] because it involves the clever use of ACIs to introduce a new ipaPermittedOperations attribute that is used to allow to define a 'virtual' operation as a subtype. This clever use of ACIs is also what stalled this patchset because of 389DS bugs #47569 and #47571 which have since been fixed and I was finally able to verify. Also another blocker for this patchset is that we need to wait for 4.0 when we change the Permission model and stop allowing anyone to read all attributes. Another reason this is still RFC is that the admin user apparently is allowed to retrieve any keytab with the current code and default ACIs as augmented by the 3rd patch. It is not entirely clear to me why that happens, I think it maybe due to the broad permissions granted to the admins group. This is *not* something we want to allow in the default case so help to figure out how to avoid it will go a great way into allowing this patchset to be acceptable. However due to the various changes I want to post it to the list for feedback, to see if someone can poke holes in the general architecture of the patches. Thanks for reading this far :-) Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-508-1-keytabs-Modularize-setkeytab-operation.patch Type: text/x-patch Size: 16797 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-509-1-keytabs-Expose-and-modify-key-encoding-function.patch Type: text/x-patch Size: 5300 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-510-1-keytab-Add-new-extended-operation-to-get-a-keytab.patch Type: text/x-patch Size: 23046 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-511-1-ipa-getkeytab-Modularize-ldap_set_keytab-function.patch Type: text/x-patch Size: 11208 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-512-1-ipa-getkeytab-Add-support-for-get_keytab-extop.patch Type: text/x-patch Size: 15882 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-513-1-man-Add-r-option-to-ipa-getkeytab.1.patch Type: text/x-patch Size: 2019 bytes Desc: not available URL: From abokovoy at redhat.com Thu Mar 6 08:32:44 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Mar 2014 10:32:44 +0200 Subject: [Freeipa-devel] [PATCH] 0146: ipa-kdb: do not fetch client principal if it is the same Message-ID: <20140306083244.GL16644@redhat.com> Hi! Attached patch should fix the issue raised by Sumit when reviewing my patch 0145. Additionally, it fixes reverted condition check for case when we didn't find client_princ in the database, preventing a memory leak. Martin, you wanted to create a bug for this, so I didn't add the ticket reference. -- / Alexander Bokovoy -------------- next part -------------- >From fca38b11008ff6eabed31d7d5ca0237c6b9740d0 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 6 Mar 2014 10:26:29 +0200 Subject: [PATCH] ipa-kdb: do not fetch client principal if it is the same as existing entry When client principal is the same as supplied client entry, don't fetch it again. Note that when client principal is not NULL, client entry might be NULL for cross-realm case, so we need to make sure to not dereference NULL pointer here. Also fix reverted condition for case when we didn't find the client principal in the database, preventing a memory leak. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 68f27f0..8481278 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -2002,6 +2002,7 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, bool with_pad; int result; krb5_db_entry *client_entry = NULL; + krb5_boolean is_equal; is_as_req = ((flags & KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY) != 0); @@ -2012,12 +2013,18 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, if (client_princ != NULL) { ks_client_princ = client_princ; if (!is_as_req) { - kerr = ipadb_get_principal(context, client_princ, flags, &client_entry); - /* If we didn't find client_princ in our database, it might be: - * - a principal from another realm, handle it down in ipadb_get/verify_pac() - */ - if (!kerr) { - client_entry = NULL; + is_equal = false; + if ((client != NULL) && (client->princ != NULL)) { + is_equal = krb5_principal_compare(context, client_princ, client->princ); + } + if (!is_equal) { + kerr = ipadb_get_principal(context, client_princ, flags, &client_entry); + /* If we didn't find client_princ in our database, it might be: + * - a principal from another realm, handle it down in ipadb_get/verify_pac() + */ + if (kerr != 0) { + client_entry = NULL; + } } } } else { -- 1.8.3.1 From jcholast at redhat.com Thu Mar 6 08:46:35 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 06 Mar 2014 09:46:35 +0100 Subject: [Freeipa-devel] [PATCH] 0488 tests: Create the testing service certificate on demand In-Reply-To: <531752F1.7040606@redhat.com> References: <531752F1.7040606@redhat.com> Message-ID: <531835EB.4040707@redhat.com> On 5.3.2014 17:38, Petr Viktorin wrote: > Hello, > This transforms the make-testcert command into a module that creates > the certificate when it is first needed. > As a result the tests are more self-contained, and can be run from > a read-only location (such as from the freeipa-tests package). Works for me, ACK. > > With 0235, 0487, and this patch, `ipa-run-tests` passes. (It logs too > much so it doesn't look pretty, but it passes.) I'm still getting these: ====================================================================== FAIL: test_old_permission[22]: permission_find: Search for permissions by attr with a limit of 1 (truncated) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 291, in func = lambda: self.check(nice, **test) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 309, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 349, in check_output assert_deepequal(expected, got, nice) File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 344, in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (key,)) File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 332, in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (i,)) File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 338, in assert_deepequal doc, sorted(missing), sorted(extra), expected, got, stack AssertionError: assert_deepequal: dict keys mismatch. test_old_permission[22]: permission_find: Search for permissions by attr with a limit of 1 (truncated) missing keys = ['memberindirect_role'] extra keys = [] expected = {'dn': ipapython.dn.DN('cn=Modify HBAC rule,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'), 'attrs': [u'servicecategory', u'sourcehostcategory', u'cn', u'description', u'ipaenabledflag', u'accesstime', u'usercategory', u'hostcategory', u'accessruletype', u'sourcehost'], 'ipapermbindruletype': [u'permission'], 'ipapermtarget': [ipapython.dn.DN('ipauniqueid=*,cn=hbac,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com')], 'cn': [u'Modify HBAC rule'], 'objectclass': [u'groupofnames', u'ipapermission', u'top', u'ipapermissionv2'], 'member_privilege': [u'HBAC Administrator'], 'memberindirect_role': [u'IT Security Specialist'], 'subtree': u'ldap:///dc=idm,dc=lab,dc=bos,dc=redhat,dc=com', 'permissions': [u'write']} got = {u'dn': u'cn=Modify SELinux User Maps,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com', u'ipapermbindruletype': (u'permission',), u'cn': (u'Modify SELinux User Maps',), u'ipapermtarget': (u'ipauniqueid=*,cn=usermap,cn=selinux,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com',), u'member_privilege': (u'SELinux User Map Administrators',), u'subtree': u'ldap:///dc=idm,dc=lab,dc=bos,dc=redhat,dc=com', u'objectclass': (u'ipapermission', u'top', u'groupofnames', u'ipapermissionv2'), u'attrs': (u'cn', u'ipaenabledflag', u'ipaselinuxuser', u'memberhost', u'memberuser', u'seealso'), u'permissions': (u'write',)} path = ('result', 0) ====================================================================== FAIL: test_permission[20]: permission_find: Search for permissions by attr with a limit of 1 (truncated) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 291, in func = lambda: self.check(nice, **test) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 309, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/usr/lib/python2.7/site-packages/ipatests/test_xmlrpc/xmlrpc_test.py", line 349, in check_output assert_deepequal(expected, got, nice) File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 344, in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (key,)) File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 332, in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (i,)) File "/usr/lib/python2.7/site-packages/ipatests/util.py", line 338, in assert_deepequal doc, sorted(missing), sorted(extra), expected, got, stack AssertionError: assert_deepequal: dict keys mismatch. test_permission[20]: permission_find: Search for permissions by attr with a limit of 1 (truncated) missing keys = ['memberindirect_role'] extra keys = [] expected = {'dn': ipapython.dn.DN('cn=Modify HBAC rule,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'), 'ipapermright': [u'write'], 'ipapermtarget': [ipapython.dn.DN('ipauniqueid=*,cn=hbac,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com')], 'cn': [u'Modify HBAC rule'], 'objectclass': [u'groupofnames', u'ipapermission', u'top', u'ipapermissionv2'], 'member_privilege': [u'HBAC Administrator'], 'ipapermlocation': [ipapython.dn.DN('dc=idm,dc=lab,dc=bos,dc=redhat,dc=com')], 'memberindirect_role': [u'IT Security Specialist'], 'ipapermbindruletype': [u'permission'], 'attrs': [u'servicecategory', u'sourcehostcategory', u'cn', u'description', u'ipaenabledflag', u'accesstime', u'usercategory', u'hostcategory', u'accessruletype', u'sourcehost']} got = {u'dn': u'cn=Modify SELinux User Maps,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com', u'ipapermright': (u'write',), u'ipapermbindruletype': (u'permission',), u'cn': (u'Modify SELinux User Maps',), u'ipapermtarget': (u'ipauniqueid=*,cn=usermap,cn=selinux,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com',), u'member_privilege': (u'SELinux User Map Administrators',), u'objectclass': (u'ipapermission', u'top', u'groupofnames', u'ipapermissionv2'), u'attrs': (u'cn', u'ipaenabledflag', u'ipaselinuxuser', u'memberhost', u'memberuser', u'seealso'), u'ipapermlocation': (u'dc=idm,dc=lab,dc=bos,dc=redhat,dc=com',)} path = ('result', 0) I have been getting them for quite some time now. Any idea what might be the cause? -- Jan Cholasta From pspacek at redhat.com Thu Mar 6 08:50:26 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 06 Mar 2014 09:50:26 +0100 Subject: [Freeipa-devel] [PATCHES] [RFC] New getkeytab operation: why not to use kadmin protocol? In-Reply-To: <1394057898.14651.40.camel@willson.li.ssimo.org> References: <1394057898.14651.40.camel@willson.li.ssimo.org> Message-ID: <531836D2.9050709@redhat.com> On 5.3.2014 23:18, Simo Sorce wrote: > Thanks for reading this far :-) I will bikeshed this thread a little bit: Can we use kadmin protocol instead of the proprietary LDAP control? If I remember correctly one of objections was that we do not allow admin to read the key but it is not true anymore ... And we have ticket delegation capabilities so kadmin process can use credentials of requester to contact LDAP. I really don't like ipa-getkeytab :-) It is yet another proprietary tool. I would like to allow admins experienced with Kerberos to use normal kadmin. -- Petr^2 Spacek From pspacek at redhat.com Thu Mar 6 08:47:59 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 06 Mar 2014 09:47:59 +0100 Subject: [Freeipa-devel] [PATCHES] [RFC] New getkeytab operation: why not to use kadmin protocol? In-Reply-To: <1394057898.14651.40.camel@willson.li.ssimo.org> References: <1394057898.14651.40.camel@willson.li.ssimo.org> Message-ID: <5318363F.1060408@redhat.com> On 5.3.2014 23:18, Simo Sorce wrote: > Thanks for reading this far :-) I will bikeshed this thread a little bit: Can we use kadmin protocol instead of the proprietary LDAP control? If I remember correctly one of objections was that we do not allow admin to read the key but it is not true anymore ... And we have ticket delegation capabilities so kadmin process can use credentials of requester to contact LDAP. I really don't like ipa-getkeytab :-) It is yet another proprietary tool. I would like to allow admins experienced with Kerberos to use normal kadmin. -- Petr^2 Spacek From pviktori at redhat.com Thu Mar 6 09:39:03 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 06 Mar 2014 10:39:03 +0100 Subject: [Freeipa-devel] [PATCH] 0488 tests: Create the testing service certificate on demand In-Reply-To: <531835EB.4040707@redhat.com> References: <531752F1.7040606@redhat.com> <531835EB.4040707@redhat.com> Message-ID: <53184237.7010702@redhat.com> On 03/06/2014 09:46 AM, Jan Cholasta wrote: > On 5.3.2014 17:38, Petr Viktorin wrote: >> Hello, >> This transforms the make-testcert command into a module that creates >> the certificate when it is first needed. >> As a result the tests are more self-contained, and can be run from >> a read-only location (such as from the freeipa-tests package). > > Works for me, ACK. Pushed to master: 68f4af3122bfd9f83f4f09a7b6254da1bf0e533a >> With 0235, 0487, and this patch, `ipa-run-tests` passes. (It logs too >> much so it doesn't look pretty, but it passes.) > > I'm still getting these: > [...] > > FAIL: test_permission[20]: permission_find: Search for permissions by > attr with a limit of 1 (truncated) > ---------------------------------------------------------------------- [...] > > I have been getting them for quite some time now. Any idea what might be > the cause? > These tests rely on the order of entries returned by DS so frankly I'm not surprised they're failing in some cases. They're not failing for me, though. My patch 0475 should fix them. -- Petr? From sbose at redhat.com Thu Mar 6 10:01:35 2014 From: sbose at redhat.com (Sumit Bose) Date: Thu, 6 Mar 2014 11:01:35 +0100 Subject: [Freeipa-devel] [PATCH] 0146: ipa-kdb: do not fetch client principal if it is the same In-Reply-To: <20140306083244.GL16644@redhat.com> References: <20140306083244.GL16644@redhat.com> Message-ID: <20140306100135.GE3051@localhost.localdomain> On Thu, Mar 06, 2014 at 10:32:44AM +0200, Alexander Bokovoy wrote: > Hi! > > Attached patch should fix the issue raised by Sumit when reviewing my > patch 0145. > > Additionally, it fixes reverted condition check for case when we didn't > find client_princ in the database, preventing a memory leak. > > Martin, you wanted to create a bug for this, so I didn't add the ticket > reference. > > -- > / Alexander Bokovoy I checked AS-REQs for IPA users and TGS-REQs for IPA and AD users and the delegation used by the framework and didn't found an issue, so ACK. bye, Sumit From abokovoy at redhat.com Thu Mar 6 10:03:23 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 6 Mar 2014 12:03:23 +0200 Subject: [Freeipa-devel] [PATCH] 0147: ipaserver/rpcserver: catch ACIError and return proper message for out-of-realm users Message-ID: <20140306100323.GN16644@redhat.com> Hi, we had similar issue in past, in jsonserver_session() class, fixed by 0292ebd1 which Tomas did for ticket https://fedorahosted.org/freeipa/ticket/3252 This one is for non-sessioned call: https://fedorahosted.org/freeipa/ticket/4225 -- / Alexander Bokovoy -------------- next part -------------- >From bfd3ed72429f63cdf9bb1955ad8ee04c75e42014 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 6 Mar 2014 11:59:05 +0200 Subject: [PATCH 2/2] ipaserver/rpcserver: catch ACIError and return proper message for out-of-realm users https://fedorahosted.org/freeipa/ticket/4225 --- ipaserver/rpcserver.py | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py index eb9b073..4e5db68 100644 --- a/ipaserver/rpcserver.py +++ b/ipaserver/rpcserver.py @@ -864,7 +864,11 @@ class jsonserver_kerb(jsonserver): self.internal_error(environ, start_response, 'jsonserver_kerb.__call__: KRB5CCNAME not defined in HTTP request environment') return self.marshal(None, CCacheError()) - self.create_context(ccache=user_ccache) + # This may fail if a ticket from wrong realm was handled via browser + try: + self.create_context(ccache=user_ccache) + except ACIError, e: + return self.unauthorized(environ, start_response, str(e), 'denied') try: response = super(jsonserver_kerb, self).__call__(environ, start_response) -- 1.8.3.1 From mkosek at redhat.com Thu Mar 6 11:30:14 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 06 Mar 2014 12:30:14 +0100 Subject: [Freeipa-devel] [PATCH] 0146: ipa-kdb: do not fetch client principal if it is the same In-Reply-To: <20140306100135.GE3051@localhost.localdomain> References: <20140306083244.GL16644@redhat.com> <20140306100135.GE3051@localhost.localdomain> Message-ID: <53185C46.50107@redhat.com> On 03/06/2014 11:01 AM, Sumit Bose wrote: > On Thu, Mar 06, 2014 at 10:32:44AM +0200, Alexander Bokovoy wrote: >> Hi! >> >> Attached patch should fix the issue raised by Sumit when reviewing my >> patch 0145. >> >> Additionally, it fixes reverted condition check for case when we didn't >> find client_princ in the database, preventing a memory leak. >> >> Martin, you wanted to create a bug for this, so I didn't add the ticket >> reference. >> >> -- >> / Alexander Bokovoy > > I checked AS-REQs for IPA users and TGS-REQs for IPA and AD users and > the delegation used by the framework and didn't found an issue, so ACK. > > bye, > Sumit Pushed to: master: 4048d412f2297df6bb483c86cdb61c21a0081f35 ipa-3-3: 4de37e613d61a7f921687eec053f04bc55d2f09e Martin From amisnyov at redhat.com Thu Mar 6 12:01:32 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Thu, 6 Mar 2014 13:01:32 +0100 Subject: [Freeipa-devel] [PATCH] 546 webui: Datetime parsing and formatting In-Reply-To: <530CCD58.5030403@redhat.com> References: <530CCD58.5030403@redhat.com> Message-ID: <20140306130132.3813166b@unused-4-246.brq.redhat.com> On Tue, 25 Feb 2014 18:05:28 +0100 Petr Vobornik wrote: > prerequisite for patch 547, 548 > depends on tbabej's datetime patch > > this patch implements: > - output_formatter in field. It should be used in par with formatter. > Formatter serves for datasource->widget conversion, output_formatter > for widget->datasource format conversion. > - datetime module which parses/format strings in subset of ISO 8601 > and LDAP generalized time format to Date. > - utc formatter replaced with new datetime formatter > - datetime_validator introduced > - new datetime field, extension of text field, which by default uses > datetime formatter and validator > > Dojo was regenerated to include dojo/string module > > https://fedorahosted.org/freeipa/ticket/4194 Hi, these are the results of my review: - if incorrect number specified for any of the parts(ie 2013-01-01 25:00:00), then it counts forward(result: 2013-01-02 01:00:00), does it supposed to work this way? at least some warning should be given to the user, that the date is incorrect(imho) - couldn't test non utc datetime input(no test cases in the ui yet), but other tests(integration and ui) passed which are connected to this issue - validity fields accept non existing timeframe(ie start: 2013-01-01 00:00:00Z, end: 2012-01-01 00:00:00Z) - validity fields only accept UTC time, it's good so besides that timeframe issue(which the api should handle i think), it's an ACK Be careful, it should be pushed to master with pvoborni's 531-541 and 546-548, wait for the review of those! Greets: Adam From pvoborni at redhat.com Thu Mar 6 12:26:03 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 06 Mar 2014 13:26:03 +0100 Subject: [Freeipa-devel] [PATCH] 546 webui: Datetime parsing and formatting In-Reply-To: <20140306130132.3813166b@unused-4-246.brq.redhat.com> References: <530CCD58.5030403@redhat.com> <20140306130132.3813166b@unused-4-246.brq.redhat.com> Message-ID: <5318695B.4080100@redhat.com> On 6.3.2014 13:01, Misnyovszki Adam wrote: > On Tue, 25 Feb 2014 18:05:28 +0100 > Petr Vobornik wrote: > >> prerequisite for patch 547, 548 >> depends on tbabej's datetime patch >> >> this patch implements: >> - output_formatter in field. It should be used in par with formatter. >> Formatter serves for datasource->widget conversion, output_formatter >> for widget->datasource format conversion. >> - datetime module which parses/format strings in subset of ISO 8601 >> and LDAP generalized time format to Date. >> - utc formatter replaced with new datetime formatter >> - datetime_validator introduced >> - new datetime field, extension of text field, which by default uses >> datetime formatter and validator >> >> Dojo was regenerated to include dojo/string module >> >> https://fedorahosted.org/freeipa/ticket/4194 > > Hi, > these are the results of my review: > - if incorrect number specified for any of the parts(ie 2013-01-01 > 25:00:00), then it counts forward(result: 2013-01-02 01:00:00), does > it supposed to work this way? at least some warning should be given > to the user, that the date is incorrect(imho) It's standard behavior of JavaScript Date object's setUTCFullYear method. I did not find better methods which would not require pulling third-party lib or do real evaluation of the dates. In the end it's not that bad. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/setUTCFullYear > - couldn't test non utc datetime input(no test cases in the ui yet), > but other tests(integration and ui) passed which are connected to > this issue Non UTC are not supported therefore it's disabled. But there are unit tests in test/utils_tests.js > - validity fields accept non existing timeframe(ie start: 2013-01-01 > 00:00:00Z, end: 2012-01-01 00:00:00Z) I don't think it's checked even on a server. Maybe it should be. > - validity fields only accept UTC time, it's good > > so besides that timeframe issue(which the api should handle i think), > it's an ACK > > Be careful, it should be pushed to master with pvoborni's 531-541 and > 546-548, wait for the review of those! > > Greets: > Adam -- Petr Vobornik From simo at redhat.com Thu Mar 6 13:23:28 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 06 Mar 2014 08:23:28 -0500 Subject: [Freeipa-devel] [PATCHES] [RFC] New getkeytab operation: why not to use kadmin protocol? In-Reply-To: <531836D2.9050709@redhat.com> References: <1394057898.14651.40.camel@willson.li.ssimo.org> <531836D2.9050709@redhat.com> Message-ID: <1394112208.14651.52.camel@willson.li.ssimo.org> On Thu, 2014-03-06 at 09:50 +0100, Petr Spacek wrote: > On 5.3.2014 23:18, Simo Sorce wrote: > > Thanks for reading this far :-) > > I will bikeshed this thread a little bit: > Can we use kadmin protocol instead of the proprietary LDAP control? You know, you already made the same question last year when I sent the first RFC patchset, the answer is in that thread :) > If I remember correctly one of objections was that we do not allow admin to > read the key but it is not true anymore ... And we have ticket delegation > capabilities so kadmin process can use credentials of requester to contact LDAP. > > I really don't like ipa-getkeytab :-) It is yet another proprietary tool. I > would like to allow admins experienced with Kerberos to use normal kadmin. Right, but this is not the feedback I was looking for, we already have ipa-getkeytab and now we need an additional feature this patchset provides, I'd like comments on the implmentation. When we will have a way to use kadmin the core of this code will still be relevant as we'll use the same mechanism to control who can do what. Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Thu Mar 6 15:56:10 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 6 Mar 2014 16:56:10 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <53175739.30608@redhat.com> References: <5316504A.9090303@redhat.com> <5316513B.6000703@red!hat.com> <53165416.50000@redhat.com> <5316627A.6060702@redhat.com> <1393992645.22047.178.camel@willson.li.ssimo.org> <5316D6CA.5010103@redhat.c!om> <5316F403.6010102@redhat.com> <1394025673.14651.8.camel@willson.li.ssimo.org> <53173C89.6050509@redhat.com> <53175739.30608@redhat.com> Message-ID: <20140306155610.GD4572@hendrix.redhat.com> On Wed, Mar 05, 2014 at 05:56:25PM +0100, Jan Cholasta wrote: > On 5.3.2014 16:02, Petr Spacek wrote: > >On 5.3.2014 14:21, Simo Sorce wrote: > >>On Wed, 2014-03-05 at 10:53 +0100, Petr Spacek wrote: > >>>On 5.3.2014 08:48, Jan Cholasta wrote: > >>>>On 5.3.2014 05:10, Simo Sorce wrote: > >>>>>On Tue, 2014-03-04 at 18:32 -0500, Dmitri Pal wrote: > >>>>>>Remote means that there is a PKCS#11 library that can be loaded > >>>>>>into a > >>>>>>process and would remotely connect to a central server via > >>>>>>LDAP/REST/whatever. My point is that library should be light weight > >>>>>>and always talk to a local service like SSSD rather than have a > >>>>>>remote > >>>>>>interface. In this case SSSD on the server can talk to the vault or > >>>>>>IPA LDAP directly and all consumers would use PKCS#11 interface > >>>>>>exposed by SSSD > >>>>>> > >>>>>>Something like this... > >>>>> > >>>>>Yes this is the setting we are discussing, the actual specific > >>>>>discussion is how SSSD gets the information. > >>>>> > >>>>>Honza proposed to use a PKCS#11-like schema to store data in LDAP > >>>>>given > >>>>>DNS will need something similar, however the more we wandered into the > >>>>>discussion the more I got convinced the Vault is probably a better > >>>>>place > >>>>>to store this material than the LDAP tree itself at least for prvate > >>>>>keys. > >>>> > >>>>I only proposed something that would work for my needs (i.e. storing > >>>>certificates and associated trust policy) and would be ready for > >>>>4.0. Can you > >>>>say the same thing about the vault? > >>>I agree with Honza. I think that proposed LDAP schema is perfectly > >>>fits the > >>>purpose *for public* information like certificates and public keys. > >> > >>And I agree with you and Honza as well that the proposal is ok for > >>*public* information. > >> > >>>>>For public key material only though I am not sure a pkcs#11 schema > >>>>>will > >>>>>necessarily be useful. It might, but we do not use it for public SSH > >>>>>keys. And we also already have schema for public User or Servers X509 > >>>>>certs. > >>>> > >>>>Support for SSH public keys was implemented like 2 years ago, way > >>>>before any > >>>>talk about the vault or PKCS#11 even started. As for certs, the > >>>>proposed > >>>>schema works on top of RFC 4523, which is the cert schema you mention. > >>>> > >>>>> > >>>>>We need to define something for DNS public keys, but they are already > >>>>>published in DNS Records too if I am not wrong, would that be > >>>>>sufficient > >>>>>as a storage for the public part ? I am assuming the private keys are > >>>No, we need full PKCS#11 for OpenDNSSEC at least. > >> > >>Well, you need a pkcs#11 library interface, the backing store could be > >>anything, > >>but I do see the advantage of using a common schema so that SSSD can > >>retrieve data > >>to present through that interface in a simplified and consistent way. > >> > >>>Note that PKCS#11 in SSSD will give us generic mechanism for process/key > >>>separation (it is practically the same thing GSS-Proxy, just general > >>>purpose). > >>>This comes 'for free' if we implement PKCS#11 so please stop > >>>searching for > >>>workarounds :-) > >> > >>I am not looking for workarounds for the interface between SSSD and > >>consuming libraries. I am trying to evaluate what we could use this > >>schema for before jumping into it. > >> > >>>>>stored in the Vault and they can be files in the format used by bind ? > >>>BIND files are very hackish and we need to do PKCS#11->BIND files > >>>conversion > >>>anyway because OpenDNSSEC supports only PKCS#11 and nothing else. > >>> > >>>I plan to use PKCS#11 directly from BIND so we can drop the format > >>>conversion > >>>code and rely on pure PKCS#11 instead of bunch of hacks scripts. > >> > >>Ok. > >> > >>>>So the information would be scattered in different places, using > >>>>different > >>>>formats and accessed using different protocols? I'm fine with that, > >>>>but it is > >>>>way beyond my original idea, so please let whoever is in charge of > >>>>the vault > >>>>implement the PKCS#11 module themselves. > >> > >>Honza, clearly if something different is proposed work will be split > >>between those that need to implement it in various ways, this will > >>simply require to separate the pkcs#11 module into 2 parts, a 'feeder' > >>that implements the pkcs#11 interface and a pluggable 'gatherer' that > >>implements retrieval for specific stuff. No worries there. > >> > >>>- IMHO public information should be stored in LDAP schema as proposed. > >>>- I agree that Vault is the right choice to store secrets. > >>>- I propose to combine these two: Store public information in LDAP > >>>and store > >>>private keys in PKCS#8 blob as a secret in Vault. > >>>- This LDAP+Vault combo can be accessible over PKCS#11 interface. > >>>- Note that this will work even without vault if you want to store > >>>public > >>>information only (like CA certs and NSS trust objects). > >> > >>Works for me. > >> > >>>The only problem is that we need to use REST API from SSSD. Plain > >>>LDAP is > >>>already implemented in SSSD so it requires less code. I guess that we > >>>will > >>>need something like libipavault library... > >> > >>We'll need a helper process unless we can find a fully async library to > >>deal with the vault. Authentication to the vault over REST-like APIs > >>will also be an interesting problem ... > > > >Let me summarize what we have: > > > >We agree that > >============= > >- PKCS#11 is the right interface for key manipulation and certificate > >retrieval. > >- We can have PKCS#11 client library talking to local SSSD so the data > >retrieval logic can be hidden in SSSD (something like "PKCS-responder"). > > > > > >Open questions/variants to discuss are > >============== > >a) Do not invent any new schema for certificates and public keys. A set > >of "PKCS-providers" in SSSD will aggregate the data from various sources > >and transform them to appropriate format. > > > >A heavy machinery in SSSD will convert existing data in IPA LDAP tree to > >PKCS#11 objects presented over PKCS#11 interface. > > Petr requested a diagram for this scenario; see attachment. Awesome, this is helpful for someone like me who hasn't been following the whole thread on freeipa-devel into the detail. Given that you plan on implementing an AD provider as well, I guess it would make sense to also implement (but maybe not expose unless there is a common schema) a purre LDAP provider that both IPA and AD would share? Are you going to turn this e-mail into a design page and file SSSD tickets? Who's going to own the feature in SSSD, you, Petr or both? > > > > >- CA certs will be pulled from cn=CAcert,cn=ipa,cn=etc,dc=ipa,dc=example > >and transformed to required format. ("PKCS-CA-provider") > > (note: actually, not cn=CAcert) > > >- Other data except DNSSEC keys (like user certificates) will be handled > >specially by special provider. (Most likely this provider will stay > >unimplemented :-)) > >- DNS public keys can be stored as DNS records and converted to format > >appropriate for PKCS#11 somehow. One problem is that sometimes you need > >to generate keys but do not publish them in DNS zone. Situations like > >this will require special handling. ("PKCS-DNSSEC-provider") > >- DNS private keys are special case because they require special > >handling for key wrapping. Sub-variant are: > > aa) Use IPA vault. It requires Vault support in IPA 4.0 (for DNSSEC) > >and also client-side support in SSSD. (special > >"PKCS-DNSSEC-vault-provider") > > ab) Use some simpler single-purpose key wrapping mechanism designed > >specially for DNSSEC. Implement the key un/wrapping in special code path > >in SSSD. ("PKCS-DNSSEC-simple-provider") > > > > > >b) Use a new schema for generic PKCS#11 module in LDAP. The generic > >"PKCS-ldap-provider" will simply 1:1 map the data in LDAP to objects > >presented over PKCS#11 interface. > >- DNS public keys, CA certs and generally all public data will be stored > >in the new schema in plain text. > >- This approach supports user certificates and all other use cases out > >of the box. > >- Private keys needs special handling: > > aa) Use IPA vault. It requires Vault support in IPA 4.0 (for DNSSEC) > >and also client-side support in SSSD. > > ab) Use some simpler single-purpose key wrapping mechanism. (Proposal > >with wrapping keys stored in LDAP is on the mailing list.) Implement the > >key un/wrapping in special code path in "PKCS-ldap-provider". The > >difference is that now we don't need to call any REST API from SSSD and > >we can read all the data from LDAP or file system. > > > > > >Personally, I agree with the pluggable approach with various PKCS > >providers but I still can see the value in variant (b) with LDAP schema > >designed specifically for PKCS#11. > > +1 Another reason for implementing the LDAP provider first, I guess.. > > > > >It enables us to use generic PKCS#11 interface in all applications and > >we do not need to tweak SSSD providers specifically for each use case. > >IMHO it is also easier to implement on SSSD side of things. The only > >problem is that we didn't agree on a key wrapping mechanism. > > > > > >Maybe we can start with generic LDAP schema and some simple key wrapping > >mechanism for now and gradually add support for Vault in the future. > >SSSD will be pluggable so we will not be tied to the simpler mechanism > >forever. > > > >Also, I'm not insisting on storing wrapping keys in LDAP. In theory, we > >could store one wrapping key per-user on disk and let SSSD to read that > >key when user logs in. > > > >Let's finally decide what to do! Please keep in mind that we need > >something feasible and reasonably secure for DNSSEC and CA rotation 4.0. > > > > > -- > Jan Cholasta From mkosek at redhat.com Fri Mar 7 09:14:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Mar 2014 10:14:44 +0100 Subject: [Freeipa-devel] [PATCH] 459 Avoid passing non-terminated string to is_master_host Message-ID: <53198E04.8070106@redhat.com> When string is not terminated, queries with corrupted base may be sent to LDAP: ... cn=ipa1.example.com,cn=masters... https://fedorahosted.org/freeipa/ticket/4214 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-459-avoid-passing-non-terminated-string-to-is_master_hos.patch Type: text/x-patch Size: 1357 bytes Desc: not available URL: From abokovoy at redhat.com Fri Mar 7 09:21:45 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 7 Mar 2014 11:21:45 +0200 Subject: [Freeipa-devel] [PATCH] 459 Avoid passing non-terminated string to is_master_host In-Reply-To: <53198E04.8070106@redhat.com> References: <53198E04.8070106@redhat.com> Message-ID: <20140307092145.GT16644@redhat.com> On Fri, 07 Mar 2014, Martin Kosek wrote: >When string is not terminated, queries with corrupted base may be sent >to LDAP: > >... cn=ipa1.example.com,cn=masters... > >https://fedorahosted.org/freeipa/ticket/4214 > >-- >Martin Kosek >Supervisor, Software Engineering - Identity Management Team >Red Hat Inc. >From 74bb082c7c286e9911f1a376ed9ce25845857672 Mon Sep 17 00:00:00 2001 >From: Martin Kosek >Date: Fri, 7 Mar 2014 10:06:52 +0100 >Subject: [PATCH] Avoid passing non-terminated string to is_master_host > >When string is not terminated, queries with corrupted base may be sent >to LDAP: > >... cn=ipa1.example.com,cn=masters... > >https://fedorahosted.org/freeipa/ticket/4214 >--- > daemons/ipa-kdb/ipa_kdb_mspac.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > >diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c >index 9137cd5ad1e6166fd5d6e765fab2c8178ca0587c..c1b018cc80402c2c3488487aee1d9709b902c5b4 100644 >--- a/daemons/ipa-kdb/ipa_kdb_mspac.c >+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c >@@ -488,13 +488,14 @@ static krb5_error_code ipadb_fill_info3(struct ipadb_context *ipactx, > } > > data = krb5_princ_component(ipactx->context, princ, 1); >- strres = malloc(data->length); >+ strres = malloc(data->length+1); > if (strres == NULL) { > krb5_free_principal(ipactx->kcontext, princ); > return ENOENT; > } > > memcpy(strres, data->data, data->length); >+ strres[data->length] = '\0'; > krb5_free_principal(ipactx->kcontext, princ); > > /* Only add PAC to TGT to services on IPA masters to allow querying Obvious ACK. -- / Alexander Bokovoy From mkosek at redhat.com Fri Mar 7 09:45:34 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Mar 2014 10:45:34 +0100 Subject: [Freeipa-devel] [PATCHES] 0473-0477 Managed permission updater, part 1 In-Reply-To: <53171D1D.2010408@redhat.com> References: <530DB78A.4040003@redhat.com> <53108B41.50700@redhat.com> <53109370.7010905@redhat.com> <53149B54.2050308@redhat.com> <53171D1D.2010408@redhat.com> Message-ID: <5319953E.708@redhat.com> On 03/05/2014 01:48 PM, Petr Viktorin wrote: > On 03/03/2014 04:10 PM, Petr Viktorin wrote: >> On 02/28/2014 02:47 PM, Petr Viktorin wrote: >>> On 02/28/2014 02:12 PM, Martin Kosek wrote: >>>> On 02/26/2014 10:44 AM, Petr Viktorin wrote: >>>>> Hello, >>>>> Here are a few fixes/improvements, and the first part of a managed >>>>> permission >>>>> updater. >>>>> >>>>> The patches should go in this order but don't need to be ACKed/pushed >>>>> all at once. >>>>> >>>>> >>>>> Design: >>>>> http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater >>>>> >>>>> >>>>> >>>>> Part of the work for: https://fedorahosted.org/freeipa/ticket/3566 >>>>> >>>>> >>>>> This part is a "preview" of sorts, to get the basic mechanism and the >>>>> metadata >>>>> format reviewed before I add all of the default read permissions. >>>>> It implements the first section of "Default Permission Updater" in >>>>> the design; >>>>> "Replacing legacy default permissions" and "Removing the global >>>>> anonymous read >>>>> ACI" is left for later. >>>>> Metadata is added for the netgroup plugin* for starters > [...] >>>>> >>>> >>>> 1) 476: Typo in test name: >>>> >>>> + desc='Search fo rnonexisting permission with ":" in the >>>> name', >>> >>> Will fix. > > Fixed > >>>> 2) 477: do we want to log anything when permission is up to date? >>>> >>>> + try: >>>> + ldap.update_entry(entry) >>>> + except errors.EmptyModlist: >>>> + return >>> >>> I don't think that's needed, after all that's the expected behavior in >>> all but the first upgrade. >>> But I'll be happy to add it if you think it would be better. > > I've added a DEBUG message here. > > [...] >>>> 4) I have been quite resilient to the prefixes for the permissions, >>>> but it >>>> seems it is the easier possible approach to fix conflicts with user >>>> permissions >>>> without having to check that later for every upgrade or doing more >>>> complex >>>> stuff like multiple RDNs or different container for system and user >>>> permissions. >>>> >>>> I am now just thinking about the prefixing. Now you use this name: >>>> >>>> ipa:Read Netgroups >>>> >>>> Would it be "nicer" to use: >>>> >>>> IPA:Read Netgroups >>>> or >>>> IPA: Read Netgroups >>>> or even >>>> [IPA] Read Netgroups >>>> ? :-) >>> >>> Bikeshedding time! >>> Everyone on the list, please chime in! >> >> Bikeshedding results from today's meeting: >> >> "ipa: " pviktori++ >> "System: " mkosek++ simo+ ab++ >> "Builtin: " simo++ pvo+ >> "Default: " >> >> The winner is "System: ", so I'll go and change to that. > > Done. Thanks. The patch set looks good now, I just see that the update process may not be optimal After I run the upgrade second time, it still tries to update the ACI even though there was no change done to the permission object and should thus raise errors.EmptyModlist and skip the ACI update: 2014-03-07T09:44:34Z INFO Updating managed permissions for netgroup 2014-03-07T09:44:34Z INFO Updating managed permission: System: Read Netgroups 2014-03-07T09:44:34Z DEBUG Updating ACI for managed permission: System: Read Netgroups 2014-03-07T09:44:34Z DEBUG Removing ACI u'(targetattr = "cn || description || hostcategory || ipaenabledflag || ipauniqueid || nisdomainname || usercategory")(targetfilter = "(objectclass=ipanisnetgroup)")(version 3.0;acl "permission:System: Read Netgroups";allow (read,compare,search) userdn = "ldap:///all";)' from cn=ng,cn=alt,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com 2014-03-07T09:44:34Z DEBUG Adding ACI u'(targetattr = "cn || description || hostcategory || ipaenabledflag || ipauniqueid || nisdomainname || usercategory")(targetfilter = "(objectclass=ipanisnetgroup)")(version 3.0;acl "permission:System: Read Netgroups";allow (read,compare,search) userdn = "ldap:///all";)' to cn=ng,cn=alt,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com 2014-03-07T09:44:34Z INFO No changes to ACI 2014-03-07T09:44:34Z INFO Updating managed permission: System: Read Netgroup Membership Any idea what could cause this? Martin From jcholast at redhat.com Fri Mar 7 09:49:33 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 07 Mar 2014 10:49:33 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <20140306155610.GD4572@hendrix.redhat.com> References: <5316504A.9090303@redhat.com> <5316513B.6000703@red!hat.com> <53165416.50000@redhat.com> <5316627A.6060702@redhat.com> <1393992645.22047.178.camel@willson.li.ssimo.org> <5316D6CA.5010103@redhat.c!om> <5316F403.6010102@redhat.com> <1394025673.14651.8.camel@willson.li.ssimo.org> <53173C89.6050509@redhat.com> <53175739.30608@redhat.com> <20140306155610.GD4572@hendrix.redhat.com> Message-ID: <5319962D.5020406@redhat.com> On 6.3.2014 16:56, Jakub Hrozek wrote: > On Wed, Mar 05, 2014 at 05:56:25PM +0100, Jan Cholasta wrote: >> On 5.3.2014 16:02, Petr Spacek wrote: >>> a) Do not invent any new schema for certificates and public keys. A set >>> of "PKCS-providers" in SSSD will aggregate the data from various sources >>> and transform them to appropriate format. >>> >>> A heavy machinery in SSSD will convert existing data in IPA LDAP tree to >>> PKCS#11 objects presented over PKCS#11 interface. >> >> Petr requested a diagram for this scenario; see attachment. > > Awesome, this is helpful for someone like me who hasn't been following > the whole thread on freeipa-devel into the detail. > > Given that you plan on implementing an AD provider as well, I guess it > would make sense to also implement (but maybe not expose unless there is > a common schema) a purre LDAP provider that both IPA and AD would share? I did not include pure LDAP only because that would make the diagram too big ;-) > > Are you going to turn this e-mail into a design page and file SSSD > tickets? Who's going to own the feature in SSSD, you, Petr or both? Me, I guess, at least the generic bits and the part related to certificates. I will create a design page. -- Jan Cholasta From pvoborni at redhat.com Fri Mar 7 14:34:31 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 07 Mar 2014 15:34:31 +0100 Subject: [Freeipa-devel] [PATCH] 550 webui-css: improve radio, checkbox keyboard support and color Message-ID: <5319D8F7.7080304@redhat.com> checkboxes and radio buttons: - do not change color on hover when disabled - are focusable and checkable by keyboard again. This uses a little trick where the real checkbox is hidden under the artificial checkbox. That way it has the same position and therefore it works even in containers with overflow set. https://fedorahosted.org/freeipa/ticket/4217 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0550-webui-css-improve-radio-checkbox-keyboard-support-an.patch Type: text/x-patch Size: 4485 bytes Desc: not available URL: From mkosek at redhat.com Fri Mar 7 15:30:05 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Mar 2014 16:30:05 +0100 Subject: [Freeipa-devel] [PATCH] 0479 permission plugin: Allow multiple values for memberof In-Reply-To: <531059F7.30009@redhat.com> References: <531059F7.30009@redhat.com> Message-ID: <5319E5FD.5010407@redhat.com> On 02/28/2014 10:42 AM, Petr Viktorin wrote: > Hello, > Here is an additional part for the multivalued target filters: making > --memberof also multivalued. > > http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions > https://fedorahosted.org/freeipa/ticket/4074 Works fine. ACK if you remove the conflict on VERSION file. Martin From mkosek at redhat.com Fri Mar 7 15:34:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Mar 2014 16:34:15 +0100 Subject: [Freeipa-devel] [PATCH] 0480 permission plugin: Don't crash with empty targetfilter In-Reply-To: <53107D59.3020109@redhat.com> References: <53107CE8.1060403@redhat.com> <53107D59.3020109@redhat.com> Message-ID: <5319E6F7.2050202@redhat.com> On 02/28/2014 01:13 PM, Petr Viktorin wrote: > Fixing the subject > On 02/28/2014 01:11 PM, Petr Viktorin wrote: >> Hello, >> This fixes https://fedorahosted.org/freeipa/ticket/4206 >> >> Apply on top of my patch 0479, to avoid a conflict in tests. > > Works fine, ACK (thanks for your care with adding tests every time, this will benefit us in a long run). Martin From marco.disabatino at tirasa.net Fri Mar 7 15:39:31 2014 From: marco.disabatino at tirasa.net (Marco Di Sabatino Di Diodoro) Date: Fri, 7 Mar 2014 16:39:31 +0100 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope In-Reply-To: <52EF7274.7010503@apache.org> References: <52EA7F66.5040202@apache.org> <52EA9910.7030704@redhat.com> <52EB70A3.4090606@apache.org> <52EB74F5.1010002@redhat.com> <52EB8E8E.4040903@redhat.com> <52EBA251.6070208@apache.org> <52EBE3FD.3030709@redhat.com> <52EF7274.7010503@apache.org> Message-ID: Hi all, Il giorno 03/feb/2014, alle ore 11:41, Francesco Chicchiricc? ha scritto: > On 31/01/2014 18:57, Dmitri Pal wrote: >> On 01/31/2014 08:17 AM, Francesco Chicchiricc? wrote: >>> Are you saying that we should split our development in two: >>> >>> (1) smart proxy, exposing the RESTful interface, developed on the >>> basis of [8] >>> >>> (2) actual ConnId connector, dealing with the proxy above for >>> implementing its own logic >> Correct >> >>> If so, could you please point to the source code of [8]? >>> Will then this eventually become part of FreeIPA? >> Quite soon. I would leave it to the team to suggest whether user and >> host provisioning smart proxies should be a same smart proxy or >> different so that they can be installed independently from each other >> but use the same approach. IMO haveing them separately but share the >> same code and approach will be more valuable to the project. But I am >> open to other ideas here. >> >>> I am actually not sure if it is "lightweight" connector could actually >>> be better than a "loaded" connector (e.g. without proxy), from a >>> deployment point of view, unless you are saying either that (a) a >>> smart proxy is already available that can be reused >> The idea can be reused as a starting point. IMO the easiest would be to >> look at the patches and use same machinery but implement different commands. >> >>> or that (b) incorporating the smart proxy that we are going to develop >>> into FreeIPA will easily happen. >> If done right: i.e. following process and style then yes. >> >> Please become familiar with the coding style [9] page on the wiki and >> other contributer guidelines [10]. >> Also having a design page created as a result of the preliminary >> investigation would go a long way towards acceptance and quality of the >> feature. >> >> We will gladly guide you on the way if you have specific questions >> >> [...] > > Ok then, we'll do it as follows. > > We are currently experimenting with FreeIPA, to get familiar with technology and options; once we will be confident enough to start the actual work on the connector, we will check the status of the smart proxy patches from [11]. > > If the implementation status will be close to be ready and about to be included in the official distribution, we will follow the suggestions above and develop a REST-based connector. We start to implementing a FreeIPA ConnId connector for Apache Syncope. We have to implement all identity operations defined by the ConnId framework. I would like to know the implementation status of the Smart/Proxy and if we can use it to all the identity operations. Thanks M > > Otherwise, we will instead specialize the CMD connector [12] to feature the FreeIPA command-line interface (as suggested at the beginning of this thread). There will be potentially need, in this case, to include the ConnId connector server into the Syncope deployment architecture, but this is a supported pattern. > > Thanks for your support. > Regards. > >>>>>>> [2] http://tirasa.github.io/ConnId/ >>>>>>> [3] http://java.net/projects/identityconnectors/ >>>>>>> [4] https://github.com/Tirasa/ConnIdFreeIPABundle >>>>>> [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html >>>>> [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html >>>>> >>>>> [7] http://www.freeipa.org/page/Documentation >>>>> [8] http://www.freeipa.org/page/V3/Smart_Proxy >>> [1] http://syncope.apache.org/ >> [9] http://www.freeipa.org/page/Coding_Style >> [10] http://www.freeipa.org/page/Contribute/Code > [11] https://fedorahosted.org/freeipa/ticket/4128 > [12] https://github.com/Tirasa/ConnIdCMDBundle > [13] https://connid.atlassian.net/wiki/display/BASE/Connector+Servers > > -- > Francesco Chicchiricc? > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Involved at The Apache Software Foundation: > member, Syncope PMC chair, Cocoon PMC, Olingo PPMC > http://people.apache.org/~ilgrosso/ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Dott. Marco Di Sabatino Di Diodoro Tel. +39 3939065570 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~mdisabatino/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Mar 7 15:45:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Mar 2014 16:45:15 +0100 Subject: [Freeipa-devel] [PATCH] 0481 permission-find: Cache the root entry for legacy permissions In-Reply-To: <5310A259.9070109@redhat.com> References: <5310A259.9070109@redhat.com> Message-ID: <5319E98B.5010003@redhat.com> On 02/28/2014 03:51 PM, Petr Viktorin wrote: > Hello, > This reduces LDAP searches in permission-find when there are legacy > permissions. The root entry (which contains all legacy permission ACIs) is only > looked up once. > > There is a conflict on one line. But when I manually resolved it, the patch worked for me. We got from 176 OPS per "ipa permission-find" to ~96. This should be OK for now. Martin From mkosek at redhat.com Fri Mar 7 15:53:35 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 07 Mar 2014 16:53:35 +0100 Subject: [Freeipa-devel] [PATCH] 0486 permission-mod: Remove attributelevelrights before reverting entry In-Reply-To: <531499FC.4040303@redhat.com> References: <531499FC.4040303@redhat.com> Message-ID: <5319EB7F.1080600@redhat.com> On 03/03/2014 04:04 PM, Petr Viktorin wrote: > Hello, > This fixes issue #4212 which Petr? found in his Web UI work. > > [#4212] https://fedorahosted.org/freeipa/ticket/4212 > ACK. Pushed to master: 02e61961daf87fae22d6891ce2e1d7f8670dd2bf Martin From dpal at redhat.com Fri Mar 7 16:33:19 2014 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 07 Mar 2014 11:33:19 -0500 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <1394035600.14651.13.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <1393344759.18299.45.camel@willson.li.ssimo.org> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> Message-ID: <5319F4CF.3000406@redhat.com> On 03/05/2014 11:06 AM, Simo Sorce wrote: > On Wed, 2014-03-05 at 16:29 +0100, Martin Kosek wrote: >> On 03/05/2014 03:04 PM, Simo Sorce wrote: >>> On Wed, 2014-03-05 at 13:05 +0100, Martin Kosek wrote: >>>> On 03/04/2014 11:14 PM, Petr Spacek wrote: >>>>> On 4.3.2014 22:53, Simo Sorce wrote: >>>>>> On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: >>>>>>> On 4.3.2014 22:15, Simo Sorce wrote: >>>>>>>> On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: >>>> ... >>>>>> I guess my only reservation is about whether DRM storage is replicated >>>>>> or not. Although both the K/M and DNS cases do not require the Vault to >>>>>> be online at all times because the keys will be downloaded and stored >>>>>> locally and only needs to be accessed when they changed, there is the >>>>>> problem of having all keys in a SPOF, that should not happen. >>>>> According to http://www.freeipa.org/page/V4/Password_Vault#Replication the >>>>> replication is available for DRM, we just need to use it. >>>>> >>>>> IMHO a vault without replication is not useful anyway. Users are not happy when >>>>> their passwords disappear ;-) >>>>> >>>>>> The additional thing about the Vault is that we can use key escrow there >>>>>> as a mechanism to re-encrypt automatically system relevant keys when a >>>>>> new server is joined to the realm. >>>>> So we agree that Vault offers what we want so we should use it, right? >>>>> >>>>> I think we should determine if we can use Vault for K/M. It would be another >>>>> reason why we should use Vault instead of a custom solution. >>>>> >>>> Do we really want to use the heavy machinery Vault for DNSSEC keys? I would >>>> personally like to avoid it and use something more lightweight. >>>> >>>> Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It >>>> needs Tomcat and all the Java machinery, special installation, replication >>>> scheme, difficult debugging etc. In my mind, Vault is a specialized heavy >>>> component that solves specific problems that not every admin may want and thus >>>> may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC). >>> Well keep in mind that you do not need a vault instance on every DNS >>> server, just like a CA a few servers would be sufficient. DNS key >>> rotation happens relatively 'rarely' so the dependency is not a huge >>> problem in terms of performance or management. There is the problem of >>> the heavyweight java-based infrastructure, but we already have that >>> dependency for the CA part, so it's not like we are adding anything new. >> Yeah, but the plan is not force people to have the heavy weight Java >> infrastructure on each server so that they are able to create more lightweight >> servers only with components they choose: >> >> https://fedorahosted.org/freeipa/ticket/4058 > Yes, but the Vault does not need to be installed on each server, just on > a couple of them like for the CA. In particular it doesn't need to be > installed on the same servers that offer the DNS service. > > Simo. > I agree with Simo. From the big picture perspective we have more and more use cases when Vault becomes a requirement: a) Storing passwords for users - initial case b) Storing volume keys for Cinder - OpenStack - Barbican use case c) Storing passwords for external cloud provider accounts - deltacloud/Manage IQ use case d) Storing DNSSEC keys - your use case e) Storing private keys for users - classical PKI escrow the DRM was built for f) Storing private SSH key - there is a ticket for that kind of escrow functionality too. For me it is apparent that vault will be a default component. It is not as heavy weight now as it used to be. All Dogtag components can share same tomcat instance so if you have a CA on the system your incremental impact is very small. So what we need is: a) Solve the problem of the DRM install. Single server work was done by Rob. Ade will be able to take it over and hel;p with the DRM install across several servers (with replication). b) There is REST API for Vault it requires certificate authentication for now. No Kerberos. We can probably live without Kerberos for now since SSSD has host cert. c) We need to hook some kind of access control that would allow specifying policies about who can fetch which keys (this is regardless where they are stored Vault or LDAP) I do not think it is the right architectural approach to try to fix a specific use case with one off solution while we already know that we need a key storage. I would rather do things right and reusable than jam them into the currently proposed release boundaries. I understand that Vault brings a lot of work to the table. But let us do it right and if it does not fit into 4.0 let us do it in 4.1. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pvoborni at redhat.com Fri Mar 7 17:10:13 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 07 Mar 2014 18:10:13 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <530F6804.3090507@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> <530F3106.7090505@redhat.com> <1393516297.3562.8.camel@localhost.localdomain> <530F6804.3090507@redhat.com> Message-ID: <5319FD75.2010108@redhat.com> On 27.2.2014 17:29, Petr Vobornik wrote: > On 27.2.2014 16:51, Nathaniel McCallum wrote: >> On Thu, 2014-02-27 at 13:35 +0100, Petr Vobornik wrote: >>> On 21.2.2014 15:24, Petr Vobornik wrote: >>>> On 10.2.2014 14:12, Petr Vobornik wrote: >>>>> On 13.1.2014 17:09, Petr Vobornik wrote: >>>>>> Hi, >>>>>> >>>>>> these patches implements the OTP Web UI. >>>>>> >>>>>> Last 5 patches is the OTP UI. >>>>>> >>>>>> First 6 patches is a little refactoring/bug fixes needed for them. >>>>>> General password dialog is introduced to avoid another >>>>>> implementation. >>>>>> >>>>>> Self-service UI is implemented to be very simple. Atm user can choose >>>>>> only token name. Admin interface allows to enter all values. >>>>>> >>>>>> It's based on the RCUE work -> we need to push RCUE first. Thanks >>>>>> Nathaniel for review of the last font package. It will speed >>>>>> things up. >>>>>> >>>>>> Know bugs: >>>>>> - there is clash in id's of checkboxes preventing editation of >>>>>> subsequently displayed ones with the same name. Will be fixed in >>>>>> separate patch. >>>>>> - bugs caused by bugs in API (adding/removal of own tokens in >>>>>> self-service, inability to enter key on token creation - >>>>>> https://fedorahosted.org/freeipa/ticket/4099) >>>>>> - datetime format (widget+validator) will be implemented in separate >>>>>> patch >>>>>> - no support of not reviewed CLI patches (HOTP..) >>>>>> >>>>>> Cgit: >>>>>> http://fedorapeople.org/cgit/pvoborni/public_git/freeipa.git/log/?h=otp >>>>>> >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3369 >>>>>> >>>>> >>>>> patch 540-1 has been updated >>>>> - QR code is centered >>>>> - QR code correction level was lowered from H to M >>>>> >>>>> All other current patches from sub-threads are attached as well (it >>>>> was >>>>> getting hard to keep track of them). >>>>> >>>> >>>> Attaching new version of patch 537: 537-4 >>>> >>>> It: >>>> * adds HOTP support - new switch in adder dialog and >>>> ipatokenhotpcounter >>>> field in details facet >>>> * removes 'default' radio button in adder dialog in >>>> ipatokenotpalgorithm >>>> and ipatokenotpdigits field >>>> >>>> >>>> Btw I've encountered an issue on Web UI login when: >>>> - user is created >>>> - token is created for him >>>> - admin resets user's password and changes auth type to 'otp' >>>> - user tries to login with psw+otp >>>> >>>> The initial login-password call is successful but subsequent change >>>> password fails - it uses the old psw+otp. >>>> >>>> I'll address this issue in https://fedorahosted.org/freeipa/ticket/3903 >>>> which is almost implemented. >>>> >>>> >>>> I also plan to hide fields without any value in otp token details page >>>> in self-service mode. This will be done after #3903 because some >>>> prerequisites for #3903 add useful code for that task. >>>> >>> >>> New version of 537 attached: 537-5 >>> >>> It removes token type switch from selfservice page. Therefore default >>> token type (totp) will be always created. >>> >>> Originated from: >>> http://www.redhat.com/archives/freeipa-devel/2014-February/msg00532.html >> >> I'm not sure I understand the rationale for this (after having read the >> other email thread). But I agree we should discuss which options should >> be available on the self-service page. >> >> Just to recap the situation: >> 1. Only token name / description are provided in the self-service UI >> 2. All options are provided on the CLI >> >> I think the main question is: who should get to choose the primary token >> type in FreeIPA? There are three possibilities: >> 1. FreeIPA developers >> 2. Admins >> 3. Users >> >> The case for #1 is that we can't guarantee timely replication of the >> counter attribute. On this basis, we choose TOTP as default because of >> structural limitations. This is currently the default. >> >> I don't see much use for #3. But I can see an argument for #2. >> >> Personally, I lean toward #1. Thoughts? >> >> Nathaniel >> > > Sorry, there is no real reason to not have HOTP there, and therefore > 537-5 is wrong and 537-4 is OK. > > Rationale of the mistake: > * self-service page has to be simple so it doesn't allow to add hw tokens > * My thoughts were fixed to the idea that HOTP has to be hw token - > maybe the H confused me. Attaching new version of 537 which adds combobox control for owner attribute instead of textbox. All other patches are attached as well to reduce confusion in case of ACK :). -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0531-2-Added-empty-value-meaning-to-boolean-formatter.patch Type: text/x-patch Size: 2787 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0532-1-Declarative-replacement-of-array-item-in-specificati.patch Type: text/x-patch Size: 3642 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0533-1-Fixed-doc-examples-in-Spec_mod.patch Type: text/x-patch Size: 1316 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0534-1-Password-Dialog.patch Type: text/x-patch Size: 11249 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0535-1-Use-general-password-dialog-for-host-OTP.patch Type: text/x-patch Size: 6306 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0536-1-Fix-handling-of-action-visibility-change-in-action-p.patch Type: text/x-patch Size: 1532 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0537-6-UI-for-OTP-tokens.patch Type: text/x-patch Size: 16490 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0538-1-UI-for-radius-proxy.patch Type: text/x-patch Size: 7703 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0539-1-UI-for-managing-user-auth-types.patch Type: text/x-patch Size: 2008 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0540-2-Added-QRcode-generation-to-Web-UI.patch Type: text/x-patch Size: 33181 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0541-2-Support-OTP-in-form-based-auth.patch Type: text/x-patch Size: 3617 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 7 18:57:03 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 07 Mar 2014 19:57:03 +0100 Subject: [Freeipa-devel] [PATCHES] 0489-0495 Add the extratargetfilter virtual attribute to permissions Message-ID: <531A167F.7010302@redhat.com> Hello, This implements https://fedorahosted.org/freeipa/ticket/4216 It feels like permissions have gone full circle, from being managed by virtual attributes, to storing all data in LDAP and exposing that, to exposing mainly virtual attributes after all. The good part is that the virtual attributes are now just a layer on top of well-structured LDAP entries. To the point: extratargetfilter lists all target filters that are not implied by --memberof or --user. The list is writable; changing it will preserve the implied filters. By default the full underlying list is not shown, you can use --all or --raw for that. In CLI, extratargetfilter is now named simply --filter, and the underlying ipapermtargetfilter is named --rawfilter. There are still some cases where the illusion is not complete: - When searching, extratargetfilter and ipapermtargetfilter behave the same, they search the full list. - When adding a filter that matches the requirements for --memberof or --type, the filter will be "used" for that option instead: $ ipa permission-add testperm --type user --perm write --filter='(memberOf=cn=admins,cn=groups,cn=accounts,$SUFFIX)' --------------------------- Added permission "testperm" --------------------------- Permission name: testperm Permissions: write Bind rule type: permission Subtree: cn=users,cn=accounts,$SUFFIX Member of group: admins Type: user Patches: 0489 - Outputting extratargetfilter 0490 - Writing extratargetfilter 0491 - CLI names for the options 0492 - Tests for the above 0493 - Searching by extratargetfilter 0494 - Fix an existing bug in --memberof 0495 - This uses the information made available in the previous patches to polish a rough edge of the --memberof/--user options. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0489-permission-plugin-Output-the-extratargetfilter-virtu.patch Type: text/x-patch Size: 45422 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0490-permission-plugin-Write-support-for-extratargetfilte.patch Type: text/x-patch Size: 9258 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0491-permission-CLI-Rename-filter-to-rawfilter-extratarge.patch Type: text/x-patch Size: 8507 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0492-permission-plugin-Add-tests-for-extratargetfilter.patch Type: text/x-patch Size: 13571 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0493-permission-plugin-Support-searching-by-extratargetfi.patch Type: text/x-patch Size: 3552 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0494-permission-plugin-Do-not-fail-on-non-DN-memberof-fil.patch Type: text/x-patch Size: 1424 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0495-permission-plugin-Do-not-change-extra-target-filters.patch Type: text/x-patch Size: 9656 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 7 19:05:47 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 07 Mar 2014 20:05:47 +0100 Subject: [Freeipa-devel] [PATCH] 0479 permission plugin: Allow multiple values for memberof In-Reply-To: <5319E5FD.5010407@redhat.com> References: <531059F7.30009@redhat.com> <5319E5FD.5010407@redhat.com> Message-ID: <531A188B.1030403@redhat.com> On 03/07/2014 04:30 PM, Martin Kosek wrote: > On 02/28/2014 10:42 AM, Petr Viktorin wrote: >> Hello, >> Here is an additional part for the multivalued target filters: making >> --memberof also multivalued. >> >> http://www.freeipa.org/page/V3/Multivalued_target_filters_in_permissions >> https://fedorahosted.org/freeipa/ticket/4074 > > Works fine. ACK if you remove the conflict on VERSION file. > > Martin > Thank you! Rebased & pushed to master: 0c2aec1be52af311feab15c01d03dfaff4b60fce -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0479.2-permission-plugin-Allow-multiple-values-for-memberof.patch Type: text/x-patch Size: 8805 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 7 19:07:59 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 07 Mar 2014 20:07:59 +0100 Subject: [Freeipa-devel] [PATCH] 0480 permission plugin: Don't crash with empty targetfilter In-Reply-To: <5319E6F7.2050202@redhat.com> References: <53107CE8.1060403@redhat.com> <53107D59.3020109@redhat.com> <5319E6F7.2050202@redhat.com> Message-ID: <531A190F.2050103@redhat.com> On 03/07/2014 04:34 PM, Martin Kosek wrote: > On 02/28/2014 01:13 PM, Petr Viktorin wrote: >> Fixing the subject >> On 02/28/2014 01:11 PM, Petr Viktorin wrote: >>> Hello, >>> This fixes https://fedorahosted.org/freeipa/ticket/4206 >>> >>> Apply on top of my patch 0479, to avoid a conflict in tests. >> >> > > Works fine, ACK Thank you! Pushed to master: d727599aa804aecd91de969a9309c1903d0cfdce > (thanks for your care with adding tests every time, this will > benefit us in a long run). Not just in the long run; I think I'd go crazy if I had to test this manually... -- Petr? From jcholast at redhat.com Mon Mar 10 10:23:48 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Mar 2014 11:23:48 +0100 Subject: [Freeipa-devel] [PATCH] 236 Log unhandled exceptions in certificate renewal scripts In-Reply-To: <52E7B440.8070306@redhat.com> References: <52E12B7C.5020204@redhat.com> <52E7B440.8070306@redhat.com> Message-ID: <531D92B4.6090507@redhat.com> On 28.1.2014 14:44, Petr Viktorin wrote: > On 01/23/2014 03:47 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . >> >> Honza > > This needs a rebase for the new LDAP API. Fixed and rebased on top of current master. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-236.1-Log-unhandled-exceptions-in-certificate-renewal-scri.patch Type: text/x-patch Size: 24195 bytes Desc: not available URL: From pspacek at redhat.com Mon Mar 10 10:49:12 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 10 Mar 2014 11:49:12 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <5319F4CF.3000406@redhat.com> References: <52FD02B7.3060404@redhat.com> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> Message-ID: <531D98A8.8090207@redhat.com> On 7.3.2014 17:33, Dmitri Pal wrote: > I do not think it is the right architectural approach to try to fix a specific > use case with one off solution while we already know that we need a key storage. > I would rather do things right and reusable than jam them into the currently > proposed release boundaries. I want to make clear that I'm not opposed to Vault in general. I'm questioning the necessity of Vault from the beginning because it will delay DNSSEC significantly. One of the proposals in this thread is to use something simple for DNSSEC keys (with few lines of Python code) and migrate DNSSEC with Vault when Vault is available and stable enough (in some later release). > I understand that Vault brings a lot of work to the table. But let us do it > right and if it does not fit into 4.0 let us do it in 4.1. We will have one huge release with DNSSEC + Vault at once if we to postpone DNSSEC to the same release as Vault. As a result, it would be harder to debug it because we will have to find if something is broken because of: - DNSSEC-IPA integration - Vault-IPA integration - DNSSEC-Vault integration. I don't think it is a good idea to make such huge release. "Release early, release often" -- Petr^2 Spacek From pviktori at redhat.com Mon Mar 10 11:05:34 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Mar 2014 12:05:34 +0100 Subject: [Freeipa-devel] [PATCH] 0481 permission-find: Cache the root entry for legacy permissions In-Reply-To: <5319E98B.5010003@redhat.com> References: <5310A259.9070109@redhat.com> <5319E98B.5010003@redhat.com> Message-ID: <531D9C7E.9090008@redhat.com> On 03/07/2014 04:45 PM, Martin Kosek wrote: > On 02/28/2014 03:51 PM, Petr Viktorin wrote: >> Hello, >> This reduces LDAP searches in permission-find when there are legacy >> permissions. The root entry (which contains all legacy permission ACIs) is only >> looked up once. >> >> > > There is a conflict on one line. But when I manually resolved it, the patch > worked for me. We got from 176 OPS per "ipa permission-find" to ~96. This > should be OK for now. > > Martin I don't see the conflict. Perhaps I mistakenly based this patch on something that's now pushed (though this applies cleanly to master from a week ago, too...). Could you check again? -- Petr? From mkosek at redhat.com Mon Mar 10 11:08:39 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 10 Mar 2014 12:08:39 +0100 Subject: [Freeipa-devel] DNSSEC design page: key wrapping In-Reply-To: <531D98A8.8090207@redhat.com> References: <52FD02B7.3060404@redhat.com> <530CC69D.9090106@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> <531D98A8.8090207@redhat.com> Message-ID: <531D9D37.70201@redhat.com> On 03/10/2014 11:49 AM, Petr Spacek wrote: > On 7.3.2014 17:33, Dmitri Pal wrote: >> I do not think it is the right architectural approach to try to fix a specific >> use case with one off solution while we already know that we need a key storage. >> I would rather do things right and reusable than jam them into the currently >> proposed release boundaries. > I want to make clear that I'm not opposed to Vault in general. I'm questioning > the necessity of Vault from the beginning because it will delay DNSSEC > significantly. +1, I also now see number of scenarios where Vault will be needed. > > One of the proposals in this thread is to use something simple for DNSSEC keys > (with few lines of Python code) and migrate DNSSEC with Vault when Vault is > available and stable enough (in some later release). > >> I understand that Vault brings a lot of work to the table. But let us do it >> right and if it does not fit into 4.0 let us do it in 4.1. > We will have one huge release with DNSSEC + Vault at once if we to postpone > DNSSEC to the same release as Vault. > > As a result, it would be harder to debug it because we will have to find if > something is broken because of: > - DNSSEC-IPA integration > - Vault-IPA integration > - DNSSEC-Vault integration. > > I don't think it is a good idea to make such huge release. > > "Release early, release often" > I must say I tend to agree with Petr. If the "poor man's solution" of DNSSEC without Vault does not cost us too much time and it would seem that the Vault is not going to squeeze in 4.0 deadlines, I would rather release the poor man's solution in 4.0 and switch to Vault when it's available in 4.1. This would let our users test the non-Vault parts of our DNSSEC solution instead of waiting to test a perfect solution. Martin From jcholast at redhat.com Mon Mar 10 12:03:27 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 10 Mar 2014 13:03:27 +0100 Subject: [Freeipa-devel] [PATCHES] 172-196 Refactor certificate renewal code In-Reply-To: <5260175E.50809@redhat.com> References: <525FD641.20202@redhat.com> <526009D7.2040702@redhat.com> <5260175E.50809@redhat.com> Message-ID: <531DAA0F.9080300@redhat.com> On 17.10.2013 18:59, Jan Cholasta wrote: > On 17.10.2013 18:01, Petr Viktorin wrote: >> On 10/17/2013 02:21 PM, Jan Cholasta wrote: >>> Hi, >>> >>> this patchset contains refactoring of the certificate renewal code, >>> which will be the base for CA certificate renewal. >>> >>> The biggest change is a new certmonger CA helper >>> dogtag-ipa-ca-renew-agent, which replaces >>> dogtag-ipa-retrieve-agent-submit as well as parts of certmonger >>> post-commands used in certificate renewal. It provides more flexibility >>> when doing renewals and allows unified certmonger configuration on both >>> CA master and clones. >>> >>> How to test: Test both CA-ful and CA-less server and replica installs >>> and upgrades, check that certmonger is configured properly and >>> certificate renewal works (see >>> https://fedorahosted.org/freeipa/ticket/2803#comment:17 for details). >>> >>> Dependencies: >>> freeipa-jcholast-161.3-Fix-certificate-renewal-scripts-to-work-with-separat.patch. >>> >>> >> >> Thanks! >> Here are my comments from reading the patches; I haven't tested yet. >> >> 161. Looks good >> 172. Looks good >> >> 173. >> The second hunk removes `pem_cert` that is later used for >> upload_ca_dercert() > > Right, will fix. > >> >> 174. Looks good >> >> 175. >> This line in upload_ca_cert() seems redundant: >> name = certdb.cacert_name > > It indeed is in this particular patch. > >> >> 176. Looks good >> 177. Looks good >> 178. Looks good >> >> 179. >> Note: look if the other calls don't rely on this (replica-install, >> ca-install) > > I didn't see any failures. > >> >> 180. Looks good >> >> 181. >> What are those constants you define in the beginning? Why are most not >> used? I think you should add a link to some reference. > > They are certmonger specific: > > https://git.fedorahosted.org/cgit/certmonger.git/tree/doc/submit.txt > https://git.fedorahosted.org/cgit/certmonger.git/tree/src/submit-e.h > > Will add the links. > >> Nitpick - PEP8 explicitly says to avoid aligning with extra spaces: >> http://www.python.org/dev/peps/pep-0008/#pet-peeves > > OK. > >> >> Please use a docstring for documenting what request_cert() does, and >> describe the return value. > > OK. Return value is based on information in submit.txt (see above for > link). > >> I don't see the purpose of the `if rc == WAIT_WITH_DELAY` block since >> `delay, cookie` gets joined again by the caller. >> Wouldn't it be cleaner to always return (rc, output) instead of doing >> that [1:] dance? > > In the context of this single patch, yes. It the context of the whole > patchset, no. > >> >> Did you consider using `traceback.format_exc` for logging errors? Full >> tracebacks tend to be more useful than just type & message. > > I did, but was not sure I want to spam syslog with full tracebacks. > >> >> 182. >> I don't understand why you reordered get_subjectaltname & get_subject, >> that makes it hard to see what changed. > > It felt more natural to me this way. > >> >> 183. Looks good >> >> 184. Looks OK >> >> 185. >> ldap_connect: conn.disconnect() should be in a finally clause > > Right. > >> >> retrieve_cert: >> - Please use docstrings for documenting functions >> - The try: block is too long, NotFound only needs to be handled for >> conn.get_entry() >> - The `except Exception` block should be removed, or it should just log >> and re-raise; the error handling is done in main(). > > The body of this function is mostly copy-paste from > dogtag-ipa-retrieve-agent-submit. Yes, it could use some cleaning up. > >> >> main: >> Shouldn't we rather raise an error if CERTMONGER_CA_PROFILE has some >> unknown value? > > No, it might be a Dogtag profile name. > >> >> >> 186. >> I'm getting lost in all the arguments to dogtag_start_tracking(). Could >> you name them when calling it? > > OK. > >> >> 187. >> I think one changelog entry for all these patches is enough. > > OK. > >> >> 188. >> Please use docstrings for documenting functions. >> >> I think even with OPERATION_NOT_SUPPORTED_BY_HELPER this should display >> some output, like "unknown operation %s". > > This is handled by certmonger. > >> >> When store_cert() runs out of attempts, it should not return ISSUED. The >> exception should be re-raised so it's logged. > > If it didn't return ISSUED, the certificate would not be saved by > certmonger and you would not be able to retry the storage attempt. How > much of a problem is this I don't know, the behavior is taken from > renew_ra_cert. > >> >> 189. >> Again, naming arguments in dogtag_start_tracking calls would make them >> clearer >> >> 190. >> Instead of dogtag.install_constants, this should use >> configured_constants(). > > I didn't actually look at what's inside the function. Will fix. > >> >> 191. >> Again, please use docstrings for documenting functions. >> Or just do the `if` right in main(), I don't think a separate function >> is worth it here. > > OK, it probably isn't. > >> >> 192. >> Again, naming dogtag_start_tracking args would make the code clearer. >> >> 193. >> Same here >> >> 194. >> I don't see why you reorder the methods, it makes the changes harder to >> spot. > > To have them in a single spot instead of all over the place. > >> >> 195. Looks OK >> >> 196. >> Again, please use docstrings for documenting functions. >> >> > Updated patches attached. Note that patches 178 & 179 were already pushed. Also, patch 190 was changed to store information about which CA instance is master in LDAP. Dependencies: freeipa-jcholast-236.1-Log-unhandled-exceptions-in-certificate-renewal-scri.patch -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-161.4-Fix-certificate-renewal-scripts-to-work-with-separat.patch Type: text/x-patch Size: 5892 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-172.1-Move-CACERT-definition-to-a-single-place.patch Type: text/x-patch Size: 13423 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-173.1-Do-not-create-CA-certificate-files-in-CA-less-server.patch Type: text/x-patch Size: 1928 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-174.1-Use-LDAP-API-to-upload-CA-certificate-instead-of-lda.patch Type: text/x-patch Size: 2811 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-175.1-Upload-CA-certificate-from-DS-NSS-database-in-CA-les.patch Type: text/x-patch Size: 3169 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-176.1-Remove-unused-method-export_ca_cert-of-dsinstance.patch Type: text/x-patch Size: 979 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-177.1-Show-progress-when-enabling-SSL-in-DS-in-ipa-server-.patch Type: text/x-patch Size: 3276 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-180.1-Use-certmonger-D-Bus-API-to-configure-certmonger-in-.patch Type: text/x-patch Size: 4923 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-181.1-Add-new-certmonger-CA-helper-dogtag-ipa-ca-renew-age.patch Type: text/x-patch Size: 4170 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-182.1-Update-pkcs10-module-functions-to-always-load-CSRs-a.patch Type: text/x-patch Size: 5484 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-183.1-Remove-unused-function-get_subjectaltname-from-the-c.patch Type: text/x-patch Size: 1324 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-184.1-Add-function-for-parsing-friendly-name-from-certific.patch Type: text/x-patch Size: 2869 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-185.1-Support-retrieving-renewed-certificates-from-LDAP-in.patch Type: text/x-patch Size: 3515 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-186.1-Use-dogtag-ipa-ca-renew-agent-to-retrieve-renewed-ce.patch Type: text/x-patch Size: 5177 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-187.1-Remove-dogtag-ipa-retrieve-agent-submit.patch Type: text/x-patch Size: 4906 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-188.1-Support-storing-renewed-certificates-to-LDAP-in-dogt.patch Type: text/x-patch Size: 5516 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-189.1-Use-dogtag-ipa-ca-renew-agent-to-track-certificates-.patch Type: text/x-patch Size: 13042 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-190.1-Store-information-about-which-CA-server-is-master-in.patch Type: text/x-patch Size: 5330 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-191.1-Make-the-default-dogtag-ipa-ca-renew-agent-behavior-.patch Type: text/x-patch Size: 2858 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-192.1-Merge-restart_pkicad-functionality-to-renew_ca_cert-.patch Type: text/x-patch Size: 7777 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-193.1-Merge-restart_httpd-functionality-to-renew_ra_cert.patch Type: text/x-patch Size: 2238 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-194.1-Use-the-same-certmonger-configuration-for-both-CA-ma.patch Type: text/x-patch Size: 9618 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-195.1-Update-certmonger-configuration-in-ipa-upgradeconfig.patch Type: text/x-patch Size: 7235 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-196.1-Support-exporting-CSRs-in-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 1733 bytes Desc: not available URL: From pviktori at redhat.com Mon Mar 10 12:24:45 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Mar 2014 13:24:45 +0100 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope In-Reply-To: References: <52EA7F66.5040202@apache.org> <52EA9910.7030704@redhat.com> <52EB70A3.4090606@apache.org> <52EB74F5.1010002@redhat.com> <52EB8E8E.4040903@redhat.com> <52EBA251.6070208@apache.org> <52EBE3FD.3030709@redhat.com> <52EF7274.7010503@apache.org> Message-ID: <531DAF0D.2090208@redhat.com> On 03/07/2014 04:39 PM, Marco Di Sabatino Di Diodoro wrote: > Hi all, > > > Il giorno 03/feb/2014, alle ore 11:41, Francesco Chicchiricc? > > ha scritto: > >> On 31/01/2014 18:57, Dmitri Pal wrote: >>> On 01/31/2014 08:17 AM, Francesco Chicchiricc? wrote: >>>> Are you saying that we should split our development in two: >>>> >>>> (1) smart proxy, exposing the RESTful interface, developed on the >>>> basis of [8] >>>> >>>> (2) actual ConnId connector, dealing with the proxy above for >>>> implementing its own logic >>> Correct >>> >>>> If so, could you please point to the source code of [8]? >>>> Will then this eventually become part of FreeIPA? >>> Quite soon. I would leave it to the team to suggest whether user and >>> host provisioning smart proxies should be a same smart proxy or >>> different so that they can be installed independently from each other >>> but use the same approach. IMO haveing them separately but share the >>> same code and approach will be more valuable to the project. But I am >>> open to other ideas here. >>> >>>> I am actually not sure if it is "lightweight" connector could actually >>>> be better than a "loaded" connector (e.g. without proxy), from a >>>> deployment point of view, unless you are saying either that (a) a >>>> smart proxy is already available that can be reused >>> The idea can be reused as a starting point. IMO the easiest would be to >>> look at the patches and use same machinery but implement different >>> commands. >>> >>>> or that (b) incorporating the smart proxy that we are going to develop >>>> into FreeIPA will easily happen. >>> If done right: i.e. following process and style then yes. >>> >>> Please become familiar with the coding style [9] page on the wiki and >>> other contributer guidelines [10]. >>> Also having a design page created as a result of the preliminary >>> investigation would go a long way towards acceptance and quality of the >>> feature. >>> >>> We will gladly guide you on the way if you have specific questions >>> >>> [...] >> >> Ok then, we'll do it as follows. >> >> We are currently experimenting with FreeIPA, to get familiar with >> technology and options; once we will be confident enough to start the >> actual work on the connector, we will check the status of the smart >> proxy patches from [11]. >> >> If the implementation status will be close to be ready and about to be >> included in the official distribution, we will follow the suggestions >> above and develop a REST-based connector. > > We start to implementing a FreeIPA ConnId connector for Apache Syncope. > We have to implement all identity operations defined by the ConnId > framework. > I would like to know the implementation status of the Smart/Proxy and if > we can use it to all the identity operations. I'm reviewing the Foreman Smart proxy patches now. They're not in the FreeIPA repository yet. However the remaining issues were with packaging, code organization, naming. The Smart Proxy is now specific to Foreman provisioning; it is not a full REST interface so it will probably not support all operations you need. For a full REST interface, patches are welcome but the core FreeIPA team has other priorities at the moment. The RFE ticket is here: https://fedorahosted.org/freeipa/ticket/4168. >> Otherwise, we will instead specialize the CMD connector [12] to >> feature the FreeIPA command-line interface (as suggested at the >> beginning of this thread). There will be potentially need, in this >> case, to include the ConnId connector server into the Syncope >> deployment architecture, but this is a supported pattern. Have you looked at JSON-RPC interface mentioned earlier in this thread, and [6]? It might be cleaner to use that than the command-line interface. > [1] http://syncope.apache.org/ > [2] http://tirasa.github.io/ConnId/ > [3] http://java.net/projects/identityconnectors/ > [4] https://github.com/Tirasa/ConnIdFreeIPABundle > [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html > [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html > [7] http://www.freeipa.org/page/Documentation > [8] http://www.freeipa.org/page/V3/Smart_Proxy -- Petr? From npmccallum at redhat.com Mon Mar 10 14:34:09 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 10 Mar 2014 10:34:09 -0400 Subject: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration In-Reply-To: <1393269987.21604.16.camel@localhost.localdomain> References: <1393269987.21604.16.camel@localhost.localdomain> Message-ID: <1394462049.2147.7.camel@localhost.localdomain> On Mon, 2014-02-24 at 14:26 -0500, Nathaniel McCallum wrote: > Before this patch, ipa-kdb would load global configuration on startup > and never update it. This means that if global configuration is changed, > the KDC never receives the new configuration until it is restarted. > > This patch enables caching of the global configuration with a timeout of > 60 seconds. > > https://fedorahosted.org/freeipa/ticket/4153 I still need a review of this. Nathaniel From pviktori at redhat.com Mon Mar 10 15:38:33 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Mar 2014 16:38:33 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <530FABC0.3060601@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> Message-ID: <531DDC79.1000406@redhat.com> On 02/27/2014 10:18 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 02/17/2014 04:57 PM, Rob Crittenden wrote: >>>> Dmitri Pal wrote: >>>>> On 02/17/2014 04:13 PM, Rob Crittenden wrote: >>>>>> Dmitri Pal wrote: >>>>>>> On 02/17/2014 02:33 PM, Rob Crittenden wrote: >>>>>>>> Dmitri Pal wrote: >>>>>>>>> On 02/17/2014 01:21 PM, Rob Crittenden wrote: >>>>>>>>>> Martin Kosek wrote: >>>>>>>>>>> On 02/14/2014 11:26 PM, Dmitri Pal wrote: >>>>>>>>>>> +1, this was exactly my goal. It is easy to name and organize >>>>>>>>>>> things >>>>>>>>>>> now, >>>>>>>>>>> difficult to do when it is live upstream and/or integrated with >>>>>>>>>>> Foreman. >>>>>>>>>>> >>>>>>>>>>> I think the key for the right naming is a fact if this is really >>>>>>>>>>> specific to >>>>>>>>>>> Foreman or it is a truly general design usable also in other use >>>>>>>>>>> cases. If >>>>>>>>>>> Foreman-specific, I would go with >>>>>>>>>>> freeipa-server-smartproxy-host or >>>>>>>>>>> similar. >>>>>>>>>>> >>>>>>>>>>> If general, we can go with >>>>>>>>>>> >>>>>>>>>>> freeipa-server-proxy-host >>>>>>>>>>> freeipa-server-proxy-user >>>>>>>>>>> freeipa-server-proxy-dhcp >>>>>>>>>>> >>>>>>>>>>> The proxies may share the framework and only expose the >>>>>>>>>>> requested >>>>>>>>>>> part of the >>>>>>>>>>> tree - which in advance gives you an option for an API >>>>>>>>>>> separation, as >>>>>>>>>>> compared >>>>>>>>>>> to general freeipa-server-smartproxy. >>>>>>>>>> >>>>>>>>>> I still don't get the point of this. Are you proposing having 3 >>>>>>>>>> different servers, each providing a unique service? Or one >>>>>>>>>> service >>>>>>>>>> that one can turn on/off features, or something else? Do you >>>>>>>>>> envision >>>>>>>>>> this as 3 separate subpackages? >>>>>>>>>> >>>>>>>>>> There is no "framework" in my current patch, it is a cherrypy >>>>>>>>>> server >>>>>>>>>> that exposes parts of IPA on a given URI. It is the thinnest of >>>>>>>>>> layers. >>>>>>>>> >>>>>>>>> >>>>>>>>> Then it seems to make sense to have 3 different packages that >>>>>>>>> can be >>>>>>>>> optionally coninstalled and would probably share the same >>>>>>>>> principal, >>>>>>>>> keytab and local REST API socket/port. >>>>>>>>> >>>>>>>> >>>>>>>> Well, what you are designing is a central framework with plugins. >>>>>>>> What >>>>>>>> I designed is a quick-and-dirty get something up quickly. We >>>>>>>> need to >>>>>>>> pick one. The plugable method is going to require a fair bit of >>>>>>>> rework, though it will potentially pay dividends in the future. >>>>>>> >>>>>>> I think that we can start where you are but drive towards this >>>>>>> architecture via refactoring. But we need to pick the right name >>>>>>> now. >>>>>>> Even if the architecture is not there yet we should name the >>>>>>> package in >>>>>>> such way that it does not preclude us from moving towards a clean >>>>>>> architecture I described during the next iteration. >>>>>> >>>>>> Just having a hard time seeing the value. This would be like making >>>>>> each of the IPA plugins a separate package and somehow installing >>>>>> them >>>>>> individually. >>>>>> >>>>>> To do this you'd need at least 2 packages, a high level one with the >>>>>> "framework" and then a separate one for each data type. >>>>>> >>>>>> This could also be achieved, and likely more cleanly, without all >>>>>> these extra packages, as a simple configuration file. Once a package, >>>>>> always a package. >>>>>> >>>>>> Maybe I'm too close to the problem, but to me this is a >>>>>> Foreman-specific solution. The "smartproxy" is a Foreman creation, I >>>>>> don't know that anything else is using it. If you want a RESTful >>>>>> server, then we enable REST in IPA directly, but selectively enabling >>>>>> and disabling APIs is not something we've done before. It has been >>>>>> controlled by ACIs instead. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> We are trying to predict future here. Say we release it as you >>>>> suggest. >>>>> Tomorrow we point someone upstream who wants to add users to IPA >>>>> from a >>>>> similar proxy to this implementation and say use this as a model. >>>>> And then Rich needs the same but for DNS for Designate. >>>>> >>>>> What would be the best? Rob if you knew that tomorrow two other >>>>> developers will create similar proxies for users and DNS would you >>>>> change anything? Would you provide some guidelines to them? >>>>> If you are close to the problem you should be able to at least tell >>>>> them: "copy and paste" vs. "add more APIs to the same proxy". >>>>> If your recommendation is copy and paste then I suspect there will be >>>>> challenges of running these proxies on the same machine - they will >>>>> collide on ports and sockets. If we say "extend" shouldn't we use a >>>>> more >>>>> generic name? >>>>> >>>> >>>> I'd say "use the existing IPA API". The only reason we have to write >>>> the smartproxy at all is to interoperate with another service that >>>> already has a well-defined remote server API which uses REST. >>>> >>>> rob >>> OK, so you think that proxy is one off. OK I am fine with it. >>> I was under assumption that it would be a beginning of a trend but I >>> might be wrong as I do not have valid arguments to prove or disprove one >>> way or another. >>> I guess time would show. >>> >>> Any objections to Rob's approach? >>> >> >> Ok, so try to summarize this long-running thread, I'll rename the >> subpackage to freeipa-server-foreman-smartproxy to make it clearer what >> it is/does. Right now it requires manual configuration so having the >> package installed should have no negative impacts (other than >> potentially pulling in additional dependencies). >> >> I'll leave it in smartproxy for now, it's just cleaner and better >> integrates with ipatests IMHO. >> >> Foreman supports SSL client auth which is great, by cherrypy does not >> yet. There is a pull request to add this, >> https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity >> >> . Foreman otherwise supports no other authentication method, so we're >> blocked with this. The certs for this would initially come out of >> Foreman/puppet. >> >> I'll submit a new patch with an updated spec but I think otherwise I've >> addressed the isuses Petr has raised. This thread has taken a lot of >> turns so it is very possible I missed something though :-) > > Updated patch based on feedback from Foreman team. I added a new URI, > /features, which Foreman uses to determine what capabilities a proxy has. > > rob On my VMs, where the first request is handled properly but the server hangs on the second one. I gave you access to the machines for investigation. Please add the Python libraries (python-cherrypy, python-requests, python-kerberos) to BuildRequires. Otherwise the build fails due to pylint errors. In the man page: > +Create a host or user whose credentials will be used by the server to make requests and add it to the role: > + > + $ ipa user\-add \-\-first=Smartproxy \-\-last=Serversmartproxy > + $ ipa role\-add\-member \-\-users=smartproxy 'Smartproxy management' the first command should be ipa user-add smartproxy --first=Smartproxy --last=Serversmartproxy since by default the username is 'sserversmartproxy'. A nitpick regarding the systemd service: according to [0], Type=forking should be avoided. Is there a reason against setting Type=simple, and removing the PID file? [0] http://www.freedesktop.org/software/systemd/man/daemon.html#Writing%20Systemd%20Unit%20Files -- Petr? From pviktori at redhat.com Mon Mar 10 16:40:18 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Mar 2014 17:40:18 +0100 Subject: [Freeipa-devel] [PATCHES] 0489-0495 Add the extratargetfilter virtual attribute to permissions In-Reply-To: <531A167F.7010302@redhat.com> References: <531A167F.7010302@redhat.com> Message-ID: <531DEAF2.9090506@redhat.com> On 03/07/2014 07:57 PM, Petr Viktorin wrote: > Hello, > This implements https://fedorahosted.org/freeipa/ticket/4216 > > It feels like permissions have gone full circle, from being managed by > virtual attributes, to storing all data in LDAP and exposing that, to > exposing mainly virtual attributes after all. The good part is that the > virtual attributes are now just a layer on top of well-structured LDAP > entries. > > > To the point: extratargetfilter lists all target filters that are not > implied by --memberof or --user. The list is writable; changing it will > preserve the implied filters. By default the full underlying list is not > shown, you can use --all or --raw for that. > In CLI, extratargetfilter is now named simply --filter, and the > underlying ipapermtargetfilter is named --rawfilter. > > There are still some cases where the illusion is not complete: > > - When searching, extratargetfilter and ipapermtargetfilter behave the > same, they search the full list. > > - When adding a filter that matches the requirements for --memberof or > --type, the filter will be "used" for that option instead: > > $ ipa permission-add testperm --type user --perm write > --filter='(memberOf=cn=admins,cn=groups,cn=accounts,$SUFFIX)' > --------------------------- > Added permission "testperm" > --------------------------- > Permission name: testperm > Permissions: write > Bind rule type: permission > Subtree: cn=users,cn=accounts,$SUFFIX > Member of group: admins > Type: user > > > > Patches: > > 0489 - Outputting extratargetfilter > 0490 - Writing extratargetfilter > 0491 - CLI names for the options > 0492 - Tests for the above > 0493 - Searching by extratargetfilter > 0494 - Fix an existing bug in --memberof > 0495 - This uses the information made available in the previous patches > to polish a rough edge of the --memberof/--user options. > Attaching rebased patches. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0489.2-permission-plugin-Output-the-extratargetfilter-virtu.patch Type: text/x-patch Size: 46427 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0490.2-permission-plugin-Write-support-for-extratargetfilte.patch Type: text/x-patch Size: 9258 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0491.2-permission-CLI-Rename-filter-to-rawfilter-extratarge.patch Type: text/x-patch Size: 8504 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0492.2-permission-plugin-Add-tests-for-extratargetfilter.patch Type: text/x-patch Size: 13571 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0493.2-permission-plugin-Support-searching-by-extratargetfi.patch Type: text/x-patch Size: 3552 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0494.2-permission-plugin-Do-not-fail-on-non-DN-memberof-fil.patch Type: text/x-patch Size: 1424 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0495.2-permission-plugin-Do-not-change-extra-target-filters.patch Type: text/x-patch Size: 9656 bytes Desc: not available URL: From pviktori at redhat.com Mon Mar 10 17:42:16 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Mar 2014 18:42:16 +0100 Subject: [Freeipa-devel] [PATCH] 236 Log unhandled exceptions in certificate renewal scripts In-Reply-To: <531D92B4.6090507@redhat.com> References: <52E12B7C.5020204@redhat.com> <52E7B440.8070306@redhat.com> <531D92B4.6090507@redhat.com> Message-ID: <531DF978.9090302@redhat.com> On 03/10/2014 11:23 AM, Jan Cholasta wrote: > On 28.1.2014 14:44, Petr Viktorin wrote: >> On 01/23/2014 03:47 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patch fixes . >>> >>> Honza >> >> This needs a rebase for the new LDAP API. > > Fixed and rebased on top of current master. > ACK, pushed to master: 8e986904096925fc08df8cbdf271d722314c5460 -- Petr? From dpal at redhat.com Mon Mar 10 18:17:07 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 10 Mar 2014 14:17:07 -0400 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope In-Reply-To: <531DAF0D.2090208@redhat.com> References: <52EA7F66.5040202@apache.org> <52EA9910.7030704@redhat.com> <52EB70A3.4090606@apache.org> <52EB74F5.1010002@redhat.com> <52EB8E8E.4040903@redhat.com> <52EBA251.6070208@apache.org> <52EBE3FD.3030709@redhat.com> <52EF7274.7010503@apache.org> <531DAF0D.2090208@redhat.com> Message-ID: <531E01A3.5030802@redhat.com> On 03/10/2014 08:24 AM, Petr Viktorin wrote: > On 03/07/2014 04:39 PM, Marco Di Sabatino Di Diodoro wrote: >> Hi all, >> >> >> Il giorno 03/feb/2014, alle ore 11:41, Francesco Chicchiricc? >> > ha scritto: >> >>> On 31/01/2014 18:57, Dmitri Pal wrote: >>>> On 01/31/2014 08:17 AM, Francesco Chicchiricc? wrote: >>>>> Are you saying that we should split our development in two: >>>>> >>>>> (1) smart proxy, exposing the RESTful interface, developed on the >>>>> basis of [8] >>>>> >>>>> (2) actual ConnId connector, dealing with the proxy above for >>>>> implementing its own logic >>>> Correct >>>> >>>>> If so, could you please point to the source code of [8]? >>>>> Will then this eventually become part of FreeIPA? >>>> Quite soon. I would leave it to the team to suggest whether user and >>>> host provisioning smart proxies should be a same smart proxy or >>>> different so that they can be installed independently from each other >>>> but use the same approach. IMO haveing them separately but share the >>>> same code and approach will be more valuable to the project. But I am >>>> open to other ideas here. >>>> >>>>> I am actually not sure if it is "lightweight" connector could >>>>> actually >>>>> be better than a "loaded" connector (e.g. without proxy), from a >>>>> deployment point of view, unless you are saying either that (a) a >>>>> smart proxy is already available that can be reused >>>> The idea can be reused as a starting point. IMO the easiest would >>>> be to >>>> look at the patches and use same machinery but implement different >>>> commands. >>>> >>>>> or that (b) incorporating the smart proxy that we are going to >>>>> develop >>>>> into FreeIPA will easily happen. >>>> If done right: i.e. following process and style then yes. >>>> >>>> Please become familiar with the coding style [9] page on the wiki and >>>> other contributer guidelines [10]. >>>> Also having a design page created as a result of the preliminary >>>> investigation would go a long way towards acceptance and quality of >>>> the >>>> feature. >>>> >>>> We will gladly guide you on the way if you have specific questions >>>> >>>> [...] >>> >>> Ok then, we'll do it as follows. >>> >>> We are currently experimenting with FreeIPA, to get familiar with >>> technology and options; once we will be confident enough to start the >>> actual work on the connector, we will check the status of the smart >>> proxy patches from [11]. >>> >>> If the implementation status will be close to be ready and about to be >>> included in the official distribution, we will follow the suggestions >>> above and develop a REST-based connector. >> >> We start to implementing a FreeIPA ConnId connector for Apache Syncope. >> We have to implement all identity operations defined by the ConnId >> framework. >> I would like to know the implementation status of the Smart/Proxy and if >> we can use it to all the identity operations. > > I'm reviewing the Foreman Smart proxy patches now. They're not in the > FreeIPA repository yet. However the remaining issues were with > packaging, code organization, naming. > > The Smart Proxy is now specific to Foreman provisioning; it is not a > full REST interface so it will probably not support all operations you > need. > > For a full REST interface, patches are welcome but the core FreeIPA > team has other priorities at the moment. The RFE ticket is here: > https://fedorahosted.org/freeipa/ticket/4168. For user provisioning you do not need a full REST api. You need to have a similar proxy but just for user related operations. So the smart proxy can be used as a model to do what you need to implement for Syncope integration. What are the operations you need to implement? Can you list them? > >>> Otherwise, we will instead specialize the CMD connector [12] to >>> feature the FreeIPA command-line interface (as suggested at the >>> beginning of this thread). There will be potentially need, in this >>> case, to include the ConnId connector server into the Syncope >>> deployment architecture, but this is a supported pattern. > > Have you looked at JSON-RPC interface mentioned earlier in this > thread, and [6]? It might be cleaner to use that than the command-line > interface. > > > >> [1] http://syncope.apache.org/ >> [2] http://tirasa.github.io/ConnId/ >> [3] http://java.net/projects/identityconnectors/ >> [4] https://github.com/Tirasa/ConnIdFreeIPABundle >> [5] >> http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html >> [6] >> https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html >> [7] http://www.freeipa.org/page/Documentation >> [8] http://www.freeipa.org/page/V3/Smart_Proxy > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pviktori at redhat.com Mon Mar 10 19:14:45 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 10 Mar 2014 20:14:45 +0100 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope In-Reply-To: <531E01A3.5030802@redhat.com> References: <52EA7F66.5040202@apache.org> <52EA9910.7030704@redhat.com> <52EB70A3.4090606@apache.org> <52EB74F5.1010002@redhat.com> <52EB8E8E.4040903@redhat.com> <52EBA251.6070208@apache.org> <52EBE3FD.3030709@redhat.com> <52EF7274.7010503@apache.org> <531DAF0D.2090208@redhat.com> <531E01A3.5030802@redhat.com> Message-ID: <531E0F25.6070805@redhat.com> On 03/10/2014 07:17 PM, Dmitri Pal wrote: > On 03/10/2014 08:24 AM, Petr Viktorin wrote: >> On 03/07/2014 04:39 PM, Marco Di Sabatino Di Diodoro wrote: >>> Hi all, >>> >>> >>> Il giorno 03/feb/2014, alle ore 11:41, Francesco Chicchiricc? >>> > ha scritto: >>> >>>> On 31/01/2014 18:57, Dmitri Pal wrote: >>>>> On 01/31/2014 08:17 AM, Francesco Chicchiricc? wrote: [...] >>>>>> I am actually not sure if it is "lightweight" connector could >>>>>> actually >>>>>> be better than a "loaded" connector (e.g. without proxy), from a >>>>>> deployment point of view, unless you are saying either that (a) a >>>>>> smart proxy is already available that can be reused >>>>> The idea can be reused as a starting point. IMO the easiest would >>>>> be to >>>>> look at the patches and use same machinery but implement different >>>>> commands. >>>>> >>>>>> or that (b) incorporating the smart proxy that we are going to >>>>>> develop >>>>>> into FreeIPA will easily happen. ^ quote left here deliberately [...] >>> >>> We start to implementing a FreeIPA ConnId connector for Apache Syncope. >>> We have to implement all identity operations defined by the ConnId >>> framework. >>> I would like to know the implementation status of the Smart/Proxy and if >>> we can use it to all the identity operations. >> >> I'm reviewing the Foreman Smart proxy patches now. They're not in the >> FreeIPA repository yet. However the remaining issues were with >> packaging, code organization, naming. >> >> The Smart Proxy is now specific to Foreman provisioning; it is not a >> full REST interface so it will probably not support all operations you >> need. >> >> For a full REST interface, patches are welcome but the core FreeIPA >> team has other priorities at the moment. The RFE ticket is here: >> https://fedorahosted.org/freeipa/ticket/4168. > > For user provisioning you do not need a full REST api. You need to have > a similar proxy but just for user related operations. > So the smart proxy can be used as a model to do what you need to > implement for Syncope integration. You'd be building two bridges (IPA--REST & REST--ConnID) when you could build just one. Unless you already have a suitable generic REST connector already, I don't think it's your best option. From this thread it seems to me that JSON-RPC--ConnID would not require significantly more work than just the REST--ConnID part. > What are the operations you need to implement? Can you list them? They were listed earlier in the thread, and [5]. >>>> Otherwise, we will instead specialize the CMD connector [12] to >>>> feature the FreeIPA command-line interface (as suggested at the >>>> beginning of this thread). There will be potentially need, in this >>>> case, to include the ConnId connector server into the Syncope >>>> deployment architecture, but this is a supported pattern. >> >> Have you looked at JSON-RPC interface mentioned earlier in this >> thread, and [6]? It might be cleaner to use that than the command-line >> interface. >> >> >> >>> [1] http://syncope.apache.org/ >>> [2] http://tirasa.github.io/ConnId/ >>> [3] http://java.net/projects/identityconnectors/ >>> [4] https://github.com/Tirasa/ConnIdFreeIPABundle >>> [5] >>> http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html >>> >>> [6] >>> https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html >>> [7] http://www.freeipa.org/page/Documentation >>> [8] http://www.freeipa.org/page/V3/Smart_Proxy -- Petr? From rcritten at redhat.com Mon Mar 10 19:53:22 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 10 Mar 2014 15:53:22 -0400 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <531DDC79.1000406@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> Message-ID: <531E1832.7020908@redhat.com> Petr Viktorin wrote: > On 02/27/2014 10:18 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >> Updated patch based on feedback from Foreman team. I added a new URI, >> /features, which Foreman uses to determine what capabilities a proxy has. >> >> rob > > On my VMs, where the first request is handled properly but the server > hangs on the second one. I gave you access to the machines for > investigation. Sent you something out-of-band but in short, I wasn't able to reproduce on your reproducing VMs :-( Ping me tomorrow and we'll try it together. > Please add the Python libraries (python-cherrypy, python-requests, > python-kerberos) to BuildRequires. Otherwise the build fails due to > pylint errors. Fixed. > > In the man page: > >> +Create a host or user whose credentials will be used by the server to >> make requests and add it to the role: >> + >> + $ ipa user\-add \-\-first=Smartproxy \-\-last=Serversmartproxy >> + $ ipa role\-add\-member \-\-users=smartproxy 'Smartproxy management' > > the first command should be > ipa user-add smartproxy --first=Smartproxy --last=Serversmartproxy > since by default the username is 'sserversmartproxy'. The problem was a missing space before smartproxy. I have the login name last in this example. Fixed. > > A nitpick regarding the systemd service: according to [0], Type=forking > should be avoided. Is there a reason against setting Type=simple, and > removing the PID file? Because I wasn't able to get this working with cherrypy daemon mode. AFAICT it forks itself and systemd wouldn't end up with the right pid so can't stop the service. rob From rcritten at redhat.com Mon Mar 10 19:55:02 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 10 Mar 2014 15:55:02 -0400 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <531E1832.7020908@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> Message-ID: <531E1896.3050700@redhat.com> Rob Crittenden wrote: > Petr Viktorin wrote: >> On 02/27/2014 10:18 PM, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>> Updated patch based on feedback from Foreman team. I added a new URI, >>> /features, which Foreman uses to determine what capabilities a proxy >>> has. >>> >>> rob >> >> On my VMs, where the first request is handled properly but the server >> hangs on the second one. I gave you access to the machines for >> investigation. > > Sent you something out-of-band but in short, I wasn't able to reproduce > on your reproducing VMs :-( Ping me tomorrow and we'll try it together. > >> Please add the Python libraries (python-cherrypy, python-requests, >> python-kerberos) to BuildRequires. Otherwise the build fails due to >> pylint errors. > > Fixed. > >> >> In the man page: >> >>> +Create a host or user whose credentials will be used by the server to >>> make requests and add it to the role: >>> + >>> + $ ipa user\-add \-\-first=Smartproxy \-\-last=Serversmartproxy >>> + $ ipa role\-add\-member \-\-users=smartproxy 'Smartproxy management' >> >> the first command should be >> ipa user-add smartproxy --first=Smartproxy --last=Serversmartproxy >> since by default the username is 'sserversmartproxy'. > > The problem was a missing space before smartproxy. I have the login name > last in this example. Fixed. > >> >> A nitpick regarding the systemd service: according to [0], Type=forking >> should be avoided. Is there a reason against setting Type=simple, and >> removing the PID file? > > Because I wasn't able to get this working with cherrypy daemon mode. > AFAICT it forks itself and systemd wouldn't end up with the right pid so > can't stop the service. And now the updated patch. The changes are super-minor. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1106-7-rest.patch Type: text/x-patch Size: 47583 bytes Desc: not available URL: From rcritten at redhat.com Mon Mar 10 21:19:29 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 10 Mar 2014 17:19:29 -0400 Subject: [Freeipa-devel] [PATCHES] [RFC] New getkeytab operation In-Reply-To: <1394057898.14651.40.camel@willson.li.ssimo.org> References: <1394057898.14651.40.camel@willson.li.ssimo.org> Message-ID: <531E2C61.6010709@redhat.com> Simo Sorce wrote: > Hello, > this is a patchset I have been brewing for quite some time. > > It addresses primarily ticket #3859 however the implementation > implicitly also addresses tickets #232 (effective only if we change > permissions and break the old interface so only potentially but not > immediately) and #233. > > The patchset is marked [RFC] because it involves the clever use of ACIs > to introduce a new ipaPermittedOperations attribute that is used to > allow to define a 'virtual' operation as a subtype. This clever use of > ACIs is also what stalled this patchset because of 389DS bugs #47569 and > #47571 which have since been fixed and I was finally able to verify. > > Also another blocker for this patchset is that we need to wait for 4.0 > when we change the Permission model and stop allowing anyone to read all > attributes. > > Another reason this is still RFC is that the admin user apparently is > allowed to retrieve any keytab with the current code and default ACIs as > augmented by the 3rd patch. It is not entirely clear to me why that > happens, I think it maybe due to the broad permissions granted to the > admins group. This is *not* something we want to allow in the default > case so help to figure out how to avoid it will go a great way into > allowing this patchset to be acceptable. > > However due to the various changes I want to post it to the list for > feedback, to see if someone can poke holes in the general architecture > of the patches. > > Thanks for reading this far :-) patch 1 looks ok, though I didn't test it. It seems like fairly straightforward refactoring. In patch 2 shouldn't pwd be initialized with: krb5_data pwd = { 0 , 0, NULL}; In patch 3 I'd prefer that each ber failure have a distinct error message so we can more clearly see where the request failed. There is also some inconsistency when LOG_FATAL is called and when it isn't. Is this the sort of thing where seeing the value from the request would be helpful in error messages? For example, where the principalname is not found, should that be included in the error? For the ACIs it would be helpful to have owner and group in the ACI comment. Right now they are all the same for each type. Patch 4, do we want a knob to tune the timeout? Similar duplicated error messages. Typo in "Incopatible options ...." rob > > Simo. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > From dpal at redhat.com Mon Mar 10 21:57:57 2014 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 10 Mar 2014 17:57:57 -0400 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope In-Reply-To: <531E0F25.6070805@redhat.com> References: <52EA7F66.5040202@apache.org> <52EA9910.7030704@redhat.com> <52EB70A3.4090606@apache.org> <52EB74F5.1010002@redhat.com> <52EB8E8E.4040903@redhat.com> <52EBA251.6070208@apache.org> <52EBE3FD.3030709@redhat.com> <52EF7274.7010503@apache.org> <531DAF0D.2090208@redhat.com> <531E01A3.5030802@redhat.com> <531E0F25.6070805@redhat.com> Message-ID: <531E3565.3070009@redhat.com> On 03/10/2014 03:14 PM, Petr Viktorin wrote: > On 03/10/2014 07:17 PM, Dmitri Pal wrote: >> On 03/10/2014 08:24 AM, Petr Viktorin wrote: >>> On 03/07/2014 04:39 PM, Marco Di Sabatino Di Diodoro wrote: >>>> Hi all, >>>> >>>> >>>> Il giorno 03/feb/2014, alle ore 11:41, Francesco Chicchiricc? >>>> > ha scritto: >>>> >>>>> On 31/01/2014 18:57, Dmitri Pal wrote: >>>>>> On 01/31/2014 08:17 AM, Francesco Chicchiricc? wrote: > [...] >>>>>>> I am actually not sure if it is "lightweight" connector could >>>>>>> actually >>>>>>> be better than a "loaded" connector (e.g. without proxy), from a >>>>>>> deployment point of view, unless you are saying either that (a) a >>>>>>> smart proxy is already available that can be reused >>>>>> The idea can be reused as a starting point. IMO the easiest would >>>>>> be to >>>>>> look at the patches and use same machinery but implement different >>>>>> commands. >>>>>> >>>>>>> or that (b) incorporating the smart proxy that we are going to >>>>>>> develop >>>>>>> into FreeIPA will easily happen. > > ^ quote left here deliberately > > [...] >>>> >>>> We start to implementing a FreeIPA ConnId connector for Apache >>>> Syncope. >>>> We have to implement all identity operations defined by the ConnId >>>> framework. >>>> I would like to know the implementation status of the Smart/Proxy >>>> and if >>>> we can use it to all the identity operations. >>> >>> I'm reviewing the Foreman Smart proxy patches now. They're not in the >>> FreeIPA repository yet. However the remaining issues were with >>> packaging, code organization, naming. >>> >>> The Smart Proxy is now specific to Foreman provisioning; it is not a >>> full REST interface so it will probably not support all operations you >>> need. >>> >>> For a full REST interface, patches are welcome but the core FreeIPA >>> team has other priorities at the moment. The RFE ticket is here: >>> https://fedorahosted.org/freeipa/ticket/4168. >> >> For user provisioning you do not need a full REST api. You need to have >> a similar proxy but just for user related operations. >> So the smart proxy can be used as a model to do what you need to >> implement for Syncope integration. > > You'd be building two bridges (IPA--REST & REST--ConnID) when you > could build just one. Unless you already have a suitable generic REST > connector already, I don't think it's your best option. From this > thread it seems to me that JSON-RPC--ConnID would not require > significantly more work than just the REST--ConnID part. > >> What are the operations you need to implement? Can you list them? > > They were listed earlier in the thread, and [5]. It is usually easy to take something that is already working like smart proxy and change the entry points to the ones that you need. I am not familiar with the architecture of the connectors. Are they separate processes? Are they daemons? Are they forked per request? Connection to IPA needs to be authenticated. If the connection to IPA happens from a single process like smart proxy you do not need to worry about machinery related to authentication and session managment. It is already implemented. This is why I was suggesting to use smart proxy. IMO REST vs. JSON is not that big deal. They are similar. Doing things right from the authentication POV and session management are much harder. But if we do not see a value in using smart proxy even like a reference point for ConnID I would not insist. > >>>>> Otherwise, we will instead specialize the CMD connector [12] to >>>>> feature the FreeIPA command-line interface (as suggested at the >>>>> beginning of this thread). There will be potentially need, in this >>>>> case, to include the ConnId connector server into the Syncope >>>>> deployment architecture, but this is a supported pattern. >>> >>> Have you looked at JSON-RPC interface mentioned earlier in this >>> thread, and [6]? It might be cleaner to use that than the command-line >>> interface. >>> >>> >>> >>>> [1] http://syncope.apache.org/ >>>> [2] http://tirasa.github.io/ConnId/ >>>> [3] http://java.net/projects/identityconnectors/ >>>> [4] https://github.com/Tirasa/ConnIdFreeIPABundle >>>> [5] >>>> http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html >>>> >>>> >>>> [6] >>>> https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html >>>> >>>> [7] http://www.freeipa.org/page/Documentation >>>> [8] http://www.freeipa.org/page/V3/Smart_Proxy > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Tue Mar 11 09:01:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Mar 2014 10:01:53 +0100 Subject: [Freeipa-devel] [PATCH] 0481 permission-find: Cache the root entry for legacy permissions In-Reply-To: <531D9C7E.9090008@redhat.com> References: <5310A259.9070109@redhat.com> <5319E98B.5010003@redhat.com> <531D9C7E.9090008@redhat.com> Message-ID: <531ED101.2080805@redhat.com> On 03/10/2014 12:05 PM, Petr Viktorin wrote: > On 03/07/2014 04:45 PM, Martin Kosek wrote: >> On 02/28/2014 03:51 PM, Petr Viktorin wrote: >>> Hello, >>> This reduces LDAP searches in permission-find when there are legacy >>> permissions. The root entry (which contains all legacy permission ACIs) is only >>> looked up once. >>> >>> >> >> There is a conflict on one line. But when I manually resolved it, the patch >> worked for me. We got from 176 OPS per "ipa permission-find" to ~96. This >> should be OK for now. >> >> Martin > > I don't see the conflict. Perhaps I mistakenly based this patch on something > that's now pushed (though this applies cleanly to master from a week ago, too...). > Could you check again? > Ok, I probably simply applied your permission fixes in wrong order. ACK. Pushed to master: 34c3d309d99d0ebe5eb0b935d356e30d8866c139 Martin From pspacek at redhat.com Tue Mar 11 10:33:11 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 11 Mar 2014 11:33:11 +0100 Subject: [Freeipa-devel] DNSSEC: upgrade path to Vault In-Reply-To: <531D9D37.70201@redhat.com> References: <52FD02B7.3060404@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> <531D98A8.8090207@redhat.com> <531D9D37.70201@redhat.com> Message-ID: <531EE667.5060700@redhat.com> On 10.3.2014 12:08, Martin Kosek wrote: > On 03/10/2014 11:49 AM, Petr Spacek wrote: >> On 7.3.2014 17:33, Dmitri Pal wrote: >>> I do not think it is the right architectural approach to try to fix a specific >>> use case with one off solution while we already know that we need a key storage. >>> I would rather do things right and reusable than jam them into the currently >>> proposed release boundaries. >> I want to make clear that I'm not opposed to Vault in general. I'm questioning >> the necessity of Vault from the beginning because it will delay DNSSEC >> significantly. > > +1, I also now see number of scenarios where Vault will be needed. > >> >> One of the proposals in this thread is to use something simple for DNSSEC keys >> (with few lines of Python code) and migrate DNSSEC with Vault when Vault is >> available and stable enough (in some later release). >> >>> I understand that Vault brings a lot of work to the table. But let us do it >>> right and if it does not fit into 4.0 let us do it in 4.1. >> We will have one huge release with DNSSEC + Vault at once if we to postpone >> DNSSEC to the same release as Vault. >> >> As a result, it would be harder to debug it because we will have to find if >> something is broken because of: >> - DNSSEC-IPA integration >> - Vault-IPA integration >> - DNSSEC-Vault integration. >> >> I don't think it is a good idea to make such huge release. >> >> "Release early, release often" >> > > I must say I tend to agree with Petr. If the "poor man's solution" of DNSSEC > without Vault does not cost us too much time and it would seem that the Vault > is not going to squeeze in 4.0 deadlines, I would rather release the poor man's > solution in 4.0 and switch to Vault when it's available in 4.1. > > This would let our users test the non-Vault parts of our DNSSEC solution > instead of waiting to test a perfect solution. Yesterday we have agreed that DNSSEC support is not going to depend on Vault from the beginning and that we can migrate to Vault later. Here I'm proposing safe upgrade path from non-vault to Vault solution. After all, it seems relatively easy. TL;DR version ============= Use information in cn=masters to detect if there are old replicas and temporarily convert new keys from Vault to LDAP storage (until all old replicas are deleted). Full version ============ IPA 4.0 is going to have OpenDNSSEC key generator on a single IPA server and separate key import/export daemon (i.e. script called from cron or something like that) on all IPA servers. In 4.0, we can add new LDAP objects for DNSSEC-related IPA services (please propose better names :-): - key generator: cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example - key imported/exporter: cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example Initial state before upgrade: - N IPA 4.0 replicas - N DNSSECKeyImporterv1 service instances (i.e. key distribution for IPA 4.0) - 1 OpenDNSSECv1 service instance (key generator) Now we want to upgrade a first replica to IPA 4.1. For simplicity, let's add a *requirement* to upgrade the replica with OpenDNSSECv1 first. (We can generalize the procedure if this requirement is not acceptable.) Upgrade procedure: - stop OpenDNSSECv1 service - stop DNSSECKeyImporterv1 service - convert OpenDNSSECv1 database to OpenDNSSECv2 This step is not related to Vault. We need to covert local SQLite database from single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC. - convert private keys from LDAP to Vault *but let them in LDAP for a while*. - walk through cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example and check if there are any other replicas with DNSSECKeyImporterv1 service: a) No such replica exists -> delete old-fashioned keys from LDAP. b) Another replica with DNSSECKeyImporterv1 service exists: - *Temporarily* run DNSSECKeyImporterv2 which will do one-way key conversion from Vault to LDAP. - DNSSECKeyImporterv2 can check e.g. daily if all DNSSECKeyImporterv1 instances were deleted or not. Then it can delete old-fashioned keys from LDAP and also stop itself when all old replicas were deleted (and compatibility mode is not needed anymore). This approach removes time constraints from upgrade procedure and prevents DNS servers from failing when update is delayed etc. As a result, admin can upgrade replica-by-replica at will. -- Petr^2 Spacek From mkosek at redhat.com Tue Mar 11 11:21:37 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Mar 2014 12:21:37 +0100 Subject: [Freeipa-devel] DNSSEC: upgrade path to Vault In-Reply-To: <531EE667.5060700@redhat.com> References: <52FD02B7.3060404@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> <531D98A8.8090207@redhat.com> <531D9D37.70201@redhat.com> <531EE667.5060700@redhat.com> Message-ID: <531EF1C1.40805@redhat.com> On 03/11/2014 11:33 AM, Petr Spacek wrote: > On 10.3.2014 12:08, Martin Kosek wrote: >> On 03/10/2014 11:49 AM, Petr Spacek wrote: >>> On 7.3.2014 17:33, Dmitri Pal wrote: >>>> I do not think it is the right architectural approach to try to fix a specific >>>> use case with one off solution while we already know that we need a key >>>> storage. >>>> I would rather do things right and reusable than jam them into the currently >>>> proposed release boundaries. >>> I want to make clear that I'm not opposed to Vault in general. I'm questioning >>> the necessity of Vault from the beginning because it will delay DNSSEC >>> significantly. >> >> +1, I also now see number of scenarios where Vault will be needed. >> >>> >>> One of the proposals in this thread is to use something simple for DNSSEC keys >>> (with few lines of Python code) and migrate DNSSEC with Vault when Vault is >>> available and stable enough (in some later release). >>> >>>> I understand that Vault brings a lot of work to the table. But let us do it >>>> right and if it does not fit into 4.0 let us do it in 4.1. >>> We will have one huge release with DNSSEC + Vault at once if we to postpone >>> DNSSEC to the same release as Vault. >>> >>> As a result, it would be harder to debug it because we will have to find if >>> something is broken because of: >>> - DNSSEC-IPA integration >>> - Vault-IPA integration >>> - DNSSEC-Vault integration. >>> >>> I don't think it is a good idea to make such huge release. >>> >>> "Release early, release often" >>> >> >> I must say I tend to agree with Petr. If the "poor man's solution" of DNSSEC >> without Vault does not cost us too much time and it would seem that the Vault >> is not going to squeeze in 4.0 deadlines, I would rather release the poor man's >> solution in 4.0 and switch to Vault when it's available in 4.1. >> >> This would let our users test the non-Vault parts of our DNSSEC solution >> instead of waiting to test a perfect solution. > > Yesterday we have agreed that DNSSEC support is not going to depend on Vault > from the beginning and that we can migrate to Vault later. > > Here I'm proposing safe upgrade path from non-vault to Vault solution. > > After all, it seems relatively easy. > > TL;DR version > ============= > Use information in cn=masters to detect if there are old replicas and > temporarily convert new keys from Vault to LDAP storage (until all old replicas > are deleted). > > Full version > ============ > IPA 4.0 is going to have OpenDNSSEC key generator on a single IPA server and > separate key import/export daemon (i.e. script called from cron or something > like that) on all IPA servers. > > In 4.0, we can add new LDAP objects for DNSSEC-related IPA services (please > propose better names :-): > - key generator: > cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example cn=DNSSEC,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example DNSSEC will be translated by FreeIPA to appropriate service name. This can vary between platforms. "v1" can be an attribute of the entry, I would not add it's to name. > - key imported/exporter: > cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example I am thinking it may be sufficient to have just: cn=DNSSEC,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example for all DNSSEC empowered masters and then just have: ipaConfigString: keygenerator ... in the master VM. I am just trying to be future agnostic and avoid hardcoding service names and implementations details in cn=masters. FreeIPA on master would know what services to run when it is a keygenerator or not. > Initial state before upgrade: > - N IPA 4.0 replicas > - N DNSSECKeyImporterv1 service instances (i.e. key distribution for IPA 4.0) > - 1 OpenDNSSECv1 service instance (key generator) > > Now we want to upgrade a first replica to IPA 4.1. For simplicity, let's add a > *requirement* to upgrade the replica with OpenDNSSECv1 first. (We can > generalize the procedure if this requirement is not acceptable.) > > Upgrade procedure: > - stop OpenDNSSECv1 service > - stop DNSSECKeyImporterv1 service > - convert OpenDNSSECv1 database to OpenDNSSECv2 > This step is not related to Vault. We need to covert local SQLite database from > single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC. > > - convert private keys from LDAP to Vault *but let them in LDAP for a while*. > - walk through cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example and check if there > are any other replicas with DNSSECKeyImporterv1 service: In my proposal, one would just search for "cn=DNSSEC,cn=*,cn=masters..." with filter "(ipaConfigString=version 1)". > a) No such replica exists -> delete old-fashioned keys from LDAP. > b) Another replica with DNSSECKeyImporterv1 service exists: > - *Temporarily* run DNSSECKeyImporterv2 which will do one-way key conversion > from Vault to LDAP. > - DNSSECKeyImporterv2 can check e.g. daily if all DNSSECKeyImporterv1 instances > were deleted or not. Then it can delete old-fashioned keys from LDAP and also > stop itself when all old replicas were deleted (and compatibility mode is not > needed anymore). > > This approach removes time constraints from upgrade procedure and prevents DNS > servers from failing when update is delayed etc. As a result, admin can upgrade > replica-by-replica at will. Ok, though I am a little bit afraid that the temporary solution would become a permanent solution. There would need to be something forcing and pushing admins to migrate. Martin From pspacek at redhat.com Tue Mar 11 11:53:26 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 11 Mar 2014 12:53:26 +0100 Subject: [Freeipa-devel] DNSSEC: upgrade path to Vault In-Reply-To: <531EF1C1.40805@redhat.com> References: <52FD02B7.3060404@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> <531D98A8.8090207@redhat.com> <531D9D37.70201@redhat.com> <531EE667.5060700@redhat.com> <531EF1C1.40805@redhat.com> Message-ID: <531EF936.6090701@redhat.com> On 11.3.2014 12:21, Martin Kosek wrote: > On 03/11/2014 11:33 AM, Petr Spacek wrote: >> On 10.3.2014 12:08, Martin Kosek wrote: >>> On 03/10/2014 11:49 AM, Petr Spacek wrote: >>>> On 7.3.2014 17:33, Dmitri Pal wrote: >>>>> I do not think it is the right architectural approach to try to fix a specific >>>>> use case with one off solution while we already know that we need a key >>>>> storage. >>>>> I would rather do things right and reusable than jam them into the currently >>>>> proposed release boundaries. >>>> I want to make clear that I'm not opposed to Vault in general. I'm questioning >>>> the necessity of Vault from the beginning because it will delay DNSSEC >>>> significantly. >>> >>> +1, I also now see number of scenarios where Vault will be needed. >>> >>>> >>>> One of the proposals in this thread is to use something simple for DNSSEC keys >>>> (with few lines of Python code) and migrate DNSSEC with Vault when Vault is >>>> available and stable enough (in some later release). >>>> >>>>> I understand that Vault brings a lot of work to the table. But let us do it >>>>> right and if it does not fit into 4.0 let us do it in 4.1. >>>> We will have one huge release with DNSSEC + Vault at once if we to postpone >>>> DNSSEC to the same release as Vault. >>>> >>>> As a result, it would be harder to debug it because we will have to find if >>>> something is broken because of: >>>> - DNSSEC-IPA integration >>>> - Vault-IPA integration >>>> - DNSSEC-Vault integration. >>>> >>>> I don't think it is a good idea to make such huge release. >>>> >>>> "Release early, release often" >>>> >>> >>> I must say I tend to agree with Petr. If the "poor man's solution" of DNSSEC >>> without Vault does not cost us too much time and it would seem that the Vault >>> is not going to squeeze in 4.0 deadlines, I would rather release the poor man's >>> solution in 4.0 and switch to Vault when it's available in 4.1. >>> >>> This would let our users test the non-Vault parts of our DNSSEC solution >>> instead of waiting to test a perfect solution. >> >> Yesterday we have agreed that DNSSEC support is not going to depend on Vault >> from the beginning and that we can migrate to Vault later. >> >> Here I'm proposing safe upgrade path from non-vault to Vault solution. >> >> After all, it seems relatively easy. >> >> TL;DR version >> ============= >> Use information in cn=masters to detect if there are old replicas and >> temporarily convert new keys from Vault to LDAP storage (until all old replicas >> are deleted). >> >> Full version >> ============ >> IPA 4.0 is going to have OpenDNSSEC key generator on a single IPA server and >> separate key import/export daemon (i.e. script called from cron or something >> like that) on all IPA servers. >> >> In 4.0, we can add new LDAP objects for DNSSEC-related IPA services (please >> propose better names :-): >> - key generator: >> cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example > > cn=DNSSEC,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example > > DNSSEC will be translated by FreeIPA to appropriate service name. This can vary > between platforms. "v1" can be an attribute of the entry, I would not add it's > to name. > >> - key imported/exporter: >> cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example > > I am thinking it may be sufficient to have just: > > cn=DNSSEC,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example > > for all DNSSEC empowered masters and then just have: > ipaConfigString: keygenerator > > ... in the master VM. I am just trying to be future agnostic and avoid > hardcoding service names and implementations details in cn=masters. FreeIPA on > master would know what services to run when it is a keygenerator or not. > >> Initial state before upgrade: >> - N IPA 4.0 replicas >> - N DNSSECKeyImporterv1 service instances (i.e. key distribution for IPA 4.0) >> - 1 OpenDNSSECv1 service instance (key generator) >> >> Now we want to upgrade a first replica to IPA 4.1. For simplicity, let's add a >> *requirement* to upgrade the replica with OpenDNSSECv1 first. (We can >> generalize the procedure if this requirement is not acceptable.) >> >> Upgrade procedure: >> - stop OpenDNSSECv1 service >> - stop DNSSECKeyImporterv1 service >> - convert OpenDNSSECv1 database to OpenDNSSECv2 >> This step is not related to Vault. We need to covert local SQLite database from >> single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC. >> >> - convert private keys from LDAP to Vault *but let them in LDAP for a while*. >> - walk through cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example and check if there >> are any other replicas with DNSSECKeyImporterv1 service: > > In my proposal, one would just search for "cn=DNSSEC,cn=*,cn=masters..." with > filter "(ipaConfigString=version 1)". Why not :-) I do not care as long as it is unambiguous. >> a) No such replica exists -> delete old-fashioned keys from LDAP. >> b) Another replica with DNSSECKeyImporterv1 service exists: >> - *Temporarily* run DNSSECKeyImporterv2 which will do one-way key conversion >> from Vault to LDAP. >> - DNSSECKeyImporterv2 can check e.g. daily if all DNSSECKeyImporterv1 instances >> were deleted or not. Then it can delete old-fashioned keys from LDAP and also >> stop itself when all old replicas were deleted (and compatibility mode is not >> needed anymore). >> >> This approach removes time constraints from upgrade procedure and prevents DNS >> servers from failing when update is delayed etc. As a result, admin can upgrade >> replica-by-replica at will. > > Ok, though I am a little bit afraid that the temporary solution would become a > permanent solution. There would need to be something forcing and pushing admins > to migrate. Could you be more specific? Is there any particular difference from any other IPA upgrade? We always tell users to upgrade soon: > It is expected > that all servers will be upgraded in a relatively short period (days or weeks, > not months). They should be able to co-exist peacefully but new features will > not be available on old servers [...] IMHO the key is in "new features will not be available on old servers". In this case the "new feature" is "no single point of failure" which seems pretty important to me :-) -- Petr^2 Spacek From jpazdziora at redhat.com Tue Mar 11 13:45:20 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 11 Mar 2014 14:45:20 +0100 Subject: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration In-Reply-To: <1393269987.21604.16.camel@localhost.localdomain> References: <1393269987.21604.16.camel@localhost.localdomain> Message-ID: <20140311134520.GA12206@redhat.com> On Mon, Feb 24, 2014 at 02:26:27PM -0500, Nathaniel McCallum wrote: > Before this patch, ipa-kdb would load global configuration on startup > and never update it. This means that if global configuration is changed, > the KDC never receives the new configuration until it is restarted. > > This patch enables caching of the global configuration with a timeout of > 60 seconds. > > https://fedorahosted.org/freeipa/ticket/4153 > >From 7daeae56671d7b3049b0341aad66c96877431bbe Mon Sep 17 00:00:00 2001 > From: Nathaniel McCallum > Date: Mon, 24 Feb 2014 14:19:13 -0500 > Subject: [PATCH] Periodically refresh global ipa-kdb configuration > > Before this patch, ipa-kdb would load global configuration on startup and > never update it. This means that if global configuration is changed, the > KDC never receives the new configuration until it is restarted. > > This patch enables caching of the global configuration with a timeout of > 60 seconds. > > https://fedorahosted.org/freeipa/ticket/4153 I have only read the code and it looks sane, so depending on how much you consider my word about code-reading worth, ack. However, my gut feeling is that my preferred way of handling the issue (without knowing much about the background of the ticket) would probably be a HUP signal handler or something similar, rather than polling for current values with the value timeout. This patch introduces small nondeterminism to the behaviour when the usage of the new values cannot really be enfoced by the admin (without the daemon restart). -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From abokovoy at redhat.com Tue Mar 11 14:05:20 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Mar 2014 16:05:20 +0200 Subject: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration In-Reply-To: <20140311134520.GA12206@redhat.com> References: <1393269987.21604.16.camel@localhost.localdomain> <20140311134520.GA12206@redhat.com> Message-ID: <20140311140520.GE16644@redhat.com> On Tue, 11 Mar 2014, Jan Pazdziora wrote: >On Mon, Feb 24, 2014 at 02:26:27PM -0500, Nathaniel McCallum wrote: >> Before this patch, ipa-kdb would load global configuration on startup >> and never update it. This means that if global configuration is changed, >> the KDC never receives the new configuration until it is restarted. >> >> This patch enables caching of the global configuration with a timeout of >> 60 seconds. >> >> https://fedorahosted.org/freeipa/ticket/4153 > >> >From 7daeae56671d7b3049b0341aad66c96877431bbe Mon Sep 17 00:00:00 2001 >> From: Nathaniel McCallum >> Date: Mon, 24 Feb 2014 14:19:13 -0500 >> Subject: [PATCH] Periodically refresh global ipa-kdb configuration >> >> Before this patch, ipa-kdb would load global configuration on startup and >> never update it. This means that if global configuration is changed, the >> KDC never receives the new configuration until it is restarted. >> >> This patch enables caching of the global configuration with a timeout of >> 60 seconds. >> >> https://fedorahosted.org/freeipa/ticket/4153 > >I have only read the code and it looks sane, so depending on how much >you consider my word about code-reading worth, ack. > >However, my gut feeling is that my preferred way of handling the issue >(without knowing much about the background of the ticket) would >probably be a HUP signal handler or something similar, rather than >polling for current values with the value timeout. This patch >introduces small nondeterminism to the behaviour when the usage of the >new values cannot really be enfoced by the admin (without the daemon >restart). Thing is, we need the update to happen when other, non-root process makes the changes -- in our case when IPA server running under httpd privileges performs series of MS-RPC calls towards smbd which lead to creating certain LDAP objects. httpd couldn't send SIGHUP to a process not owned by httpd's effective user (non-root). -- / Alexander Bokovoy From jpazdziora at redhat.com Tue Mar 11 14:08:17 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 11 Mar 2014 15:08:17 +0100 Subject: [Freeipa-devel] [PATCH] 0471 permission_add: Remove permission entry if adding the ACI fails In-Reply-To: <530762FE.7080703@redhat.com> References: <530762FE.7080703@redhat.com> Message-ID: <20140311140817.GB12206@redhat.com> On Fri, Feb 21, 2014 at 03:30:22PM +0100, Petr Viktorin wrote: > Hello, > A permission object was not removed in permission-add when adding > the ACI failed. Here is a fix. > > https://fedorahosted.org/freeipa/ticket/4187 > > > Earlier we agreed that patch authors should bug the reviewer. I > guess now this means I should set Patch-review-by in the ticket, > right? So: > Martin, you reviewed the other ACI patches so I think you should > continue. If you don't agree, unset the field in the ticket. > > -- > Petr? > From 5ad2066b71b09248d348a5c4c85ef2ace0c553a4 Mon Sep 17 00:00:00 2001 > From: Petr Viktorin > Date: Fri, 21 Feb 2014 13:58:15 +0100 > Subject: [PATCH] permission_add: Remove permission entry if adding the ACI > fails > > https://fedorahosted.org/freeipa/ticket/4187 > --- > ipalib/plugins/permission.py | 15 ++++++++++++++- > ipatests/test_xmlrpc/test_permission_plugin.py | 25 +++++++++++++++++++++++++ > 2 files changed, 39 insertions(+), 1 deletion(-) > > diff --git a/ipalib/plugins/permission.py b/ipalib/plugins/permission.py > index 64deb99ef98583daf0419a240aa8852b0262874d..cb6f18b478735920bbf6cef4febc91481631c560 100644 > --- a/ipalib/plugins/permission.py > +++ b/ipalib/plugins/permission.py > @@ -812,7 +812,20 @@ def pre_callback(self, ldap, dn, entry, attrs_list, *keys, **options): > return dn > > def post_callback(self, ldap, dn, entry, *keys, **options): > - self.obj.add_aci(entry) > + try: > + self.obj.add_aci(entry) > + except Exception: > + # Adding the ACI failed. > + # We want to be 100% sure the ACI is not there, so try to > + # remove it. (This is a no-op if the ACI was not added.) > + self.obj.remove_aci(entry) > + # Remove the entry > + try: > + self.api.Backend['ldap2'].delete_entry(entry) > + except errors.NotFound: > + pass > + # Re-raise original exception > + raise > self.obj.postprocess_result(entry, options) > return dn I'm not totally happy about this patch. What happens when the ACI is already in LDAP and some part of that self.obj.add_aci(entry) operation fails? Won't you go and instead of doing noop, remove the ACI instead? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From simo at redhat.com Tue Mar 11 14:28:36 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 11 Mar 2014 10:28:36 -0400 Subject: [Freeipa-devel] [PATCHES] [RFC] New getkeytab operation In-Reply-To: <531E2C61.6010709@redhat.com> References: <1394057898.14651.40.camel@willson.li.ssimo.org> <531E2C61.6010709@redhat.com> Message-ID: <1394548116.32465.68.camel@willson.li.ssimo.org> On Mon, 2014-03-10 at 17:19 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > Hello, > > this is a patchset I have been brewing for quite some time. > > > > It addresses primarily ticket #3859 however the implementation > > implicitly also addresses tickets #232 (effective only if we change > > permissions and break the old interface so only potentially but not > > immediately) and #233. > > > > The patchset is marked [RFC] because it involves the clever use of ACIs > > to introduce a new ipaPermittedOperations attribute that is used to > > allow to define a 'virtual' operation as a subtype. This clever use of > > ACIs is also what stalled this patchset because of 389DS bugs #47569 and > > #47571 which have since been fixed and I was finally able to verify. > > > > Also another blocker for this patchset is that we need to wait for 4.0 > > when we change the Permission model and stop allowing anyone to read all > > attributes. > > > > Another reason this is still RFC is that the admin user apparently is > > allowed to retrieve any keytab with the current code and default ACIs as > > augmented by the 3rd patch. It is not entirely clear to me why that > > happens, I think it maybe due to the broad permissions granted to the > > admins group. This is *not* something we want to allow in the default > > case so help to figure out how to avoid it will go a great way into > > allowing this patchset to be acceptable. > > > > However due to the various changes I want to post it to the list for > > feedback, to see if someone can poke holes in the general architecture > > of the patches. > > > > Thanks for reading this far :-) > > patch 1 looks ok, though I didn't test it. It seems like fairly > straightforward refactoring. Yes, it's pure refactoring so that common functions can be reused later. > In patch 2 shouldn't pwd be initialized with: > > krb5_data pwd = { 0 , 0, NULL}; Not needed, in C99 it is allowed to use a single 0 as a shorthand to say: 'all zeros', it is quite handy :-) > In patch 3 I'd prefer that each ber failure have a distinct error > message so we can more clearly see where the request failed. There is > also some inconsistency when LOG_FATAL is called and when it isn't. Uhmm it seem like we do have individual errors in ipapwd_setkeytab indeed, must have been changed after my initial implementation, I had to adjust a bunch of things in my patches as a patch touching log strings wouldn't apply anymore. LOG_FATAL is generally applied only when an internal fatal error happens, if it is a user generated error (unknown principal in the request for example, then we do not log a fatal error). Fixed messages so that different failures have different messages. > Is this the sort of thing where seeing the value from the request would > be helpful in error messages? For example, where the principalname is > not found, should that be included in the error? Well the service name is the name of the principal you are trying to get a keytab for, it is known to the client as it sent it, don't think it is worth changing errMesg from const to allocated and all additional code to handle memory management to return to the client information it already knows. > For the ACIs it would be helpful to have owner and group in the ACI > comment. Right now they are all the same for each type. Changed the descriptions. > Patch 4, do we want a knob to tune the timeout? No I do not think we need to for now. > Similar duplicated error messages. > > Typo in "Incopatible options ...." Ok these are in patch 5 and fixed. Any comments on the actual mechanism used with the ACIs ? Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-508-2-keytabs-Modularize-setkeytab-operation.patch Type: text/x-patch Size: 16797 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-509-2-keytabs-Expose-and-modify-key-encoding-function.patch Type: text/x-patch Size: 5300 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-510-2-keytab-Add-new-extended-operation-to-get-a-keytab.patch Type: text/x-patch Size: 23121 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-511-2-ipa-getkeytab-Modularize-ldap_set_keytab-function.patch Type: text/x-patch Size: 11208 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-512-2-ipa-getkeytab-Add-support-for-get_keytab-extop.patch Type: text/x-patch Size: 15929 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-513-2-man-Add-r-option-to-ipa-getkeytab.1.patch Type: text/x-patch Size: 2019 bytes Desc: not available URL: From abokovoy at redhat.com Tue Mar 11 14:32:58 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Mar 2014 16:32:58 +0200 Subject: [Freeipa-devel] [PATCH] 0148: ipa-sam: when deleting subtree, deal with possible LDAP errors Message-ID: <20140311143258.GF16644@redhat.com> Hi, after discussing with Petr Spacek, following patch fixes ticket 4224. -- / Alexander Bokovoy -------------- next part -------------- >From 83803494757e078c3a2850ddbb5eb886fd067dd1 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 11 Mar 2014 16:28:12 +0200 Subject: [PATCH 3/3] ipa-sam: when deleting subtree make sure to deal with LDAP failures https://fedorahosted.org/freeipa/ticket/4224 --- daemons/ipa-sam/ipa_sam.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 1ca504d..7a8eeb4 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -2456,10 +2456,16 @@ static int delete_subtree(struct ldapsam_privates *ldap_state, char* dn) rc = smbldap_search(ldap_state->smbldap_state, dn, scope, filter, NULL, 0, &result); TALLOC_FREE(filter); - if (result != NULL) { - smbldap_talloc_autofree_ldapmsg(dn, result); + if (rc != LDAP_SUCCESS) { + return rc; } + if (result == NULL) { + return LDAP_NO_MEMORY; + } + + smbldap_talloc_autofree_ldapmsg(dn, result); + for (entry = ldap_first_entry(state, result); entry != NULL; entry = ldap_next_entry(state, entry)) { @@ -2467,6 +2473,9 @@ static int delete_subtree(struct ldapsam_privates *ldap_state, char* dn) /* remove child entries */ if ((entry_dn != NULL) && (strcmp(entry_dn, dn) != 0)) { rc = smbldap_delete(ldap_state->smbldap_state, entry_dn); + if (rc != LDAP_SUCCESS) { + return rc; + } } } rc = smbldap_delete(ldap_state->smbldap_state, dn); -- 1.8.3.1 From pspacek at redhat.com Tue Mar 11 14:39:57 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 11 Mar 2014 15:39:57 +0100 Subject: [Freeipa-devel] [PATCH] 0148: ipa-sam: when deleting subtree, deal with possible LDAP errors In-Reply-To: <20140311143258.GF16644@redhat.com> References: <20140311143258.GF16644@redhat.com> Message-ID: <531F203D.8030500@redhat.com> On 11.3.2014 15:32, Alexander Bokovoy wrote: > after discussing with Petr Spacek, following patch fixes ticket 4224. Code seems okay but I didn't do functional test. -- Petr^2 Spacek From pviktori at redhat.com Tue Mar 11 15:09:37 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 11 Mar 2014 16:09:37 +0100 Subject: [Freeipa-devel] [PATCH] 0471 permission_add: Remove permission entry if adding the ACI fails In-Reply-To: <20140311140817.GB12206@redhat.com> References: <530762FE.7080703@redhat.com> <20140311140817.GB12206@redhat.com> Message-ID: <531F2731.6030303@redhat.com> On 03/11/2014 03:08 PM, Jan Pazdziora wrote: > On Fri, Feb 21, 2014 at 03:30:22PM +0100, Petr Viktorin wrote: >> Hello, >> A permission object was not removed in permission-add when adding >> the ACI failed. Here is a fix. >> >> https://fedorahosted.org/freeipa/ticket/4187 >> >> >> Earlier we agreed that patch authors should bug the reviewer. I >> guess now this means I should set Patch-review-by in the ticket, >> right? So: >> Martin, you reviewed the other ACI patches so I think you should >> continue. If you don't agree, unset the field in the ticket. >> >> -- >> Petr? > >> From 5ad2066b71b09248d348a5c4c85ef2ace0c553a4 Mon Sep 17 00:00:00 2001 >> From: Petr Viktorin >> Date: Fri, 21 Feb 2014 13:58:15 +0100 >> Subject: [PATCH] permission_add: Remove permission entry if adding the ACI >> fails >> >> https://fedorahosted.org/freeipa/ticket/4187 >> --- >> ipalib/plugins/permission.py | 15 ++++++++++++++- >> ipatests/test_xmlrpc/test_permission_plugin.py | 25 +++++++++++++++++++++++++ >> 2 files changed, 39 insertions(+), 1 deletion(-) >> >> diff --git a/ipalib/plugins/permission.py b/ipalib/plugins/permission.py >> index 64deb99ef98583daf0419a240aa8852b0262874d..cb6f18b478735920bbf6cef4febc91481631c560 100644 >> --- a/ipalib/plugins/permission.py >> +++ b/ipalib/plugins/permission.py >> @@ -812,7 +812,20 @@ def pre_callback(self, ldap, dn, entry, attrs_list, *keys, **options): >> return dn >> >> def post_callback(self, ldap, dn, entry, *keys, **options): >> - self.obj.add_aci(entry) >> + try: >> + self.obj.add_aci(entry) >> + except Exception: >> + # Adding the ACI failed. >> + # We want to be 100% sure the ACI is not there, so try to >> + # remove it. (This is a no-op if the ACI was not added.) >> + self.obj.remove_aci(entry) >> + # Remove the entry >> + try: >> + self.api.Backend['ldap2'].delete_entry(entry) >> + except errors.NotFound: >> + pass >> + # Re-raise original exception >> + raise >> self.obj.postprocess_result(entry, options) >> return dn > > I'm not totally happy about this patch. > > What happens when the ACI is already in LDAP and some part of that > self.obj.add_aci(entry) operation fails? Won't you go and instead of > doing noop, remove the ACI instead? Unfortunately, yes, these operations are racy. When something fails, or when doing two operations simultaneously, it is possible that the objects are not both added. If that happens, it is the ACI that should be missing. The permission is added first, and the ACI is deleted first. This means that when things fail, access is denied, which is both more secure and easier to spot than having a stray ACI floating around. (In the long term, I'd really like to see a DS plugin for permission/ACI sync, so we can leverage transactions -- IPA is really the wrong layer to re-implement transactions in.) To answer your question, if the permission+ACI is already in LDAP, the call will fail with a DuplicateEntry error and post_callback won't get called. For the case that another permission_add command is called to add a permission of the same name, the existence of the permission entry acts as a "lock": while it's there, the other permission_add will fail, and removing it ("releasing the lock") is the last thing done in the error handler. I guess it would be good to add a comment saying this. -- Petr? From simo at redhat.com Tue Mar 11 15:09:59 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 11 Mar 2014 11:09:59 -0400 Subject: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration In-Reply-To: <20140311140520.GE16644@redhat.com> References: <1393269987.21604.16.camel@localhost.localdomain> <20140311134520.GA12206@redhat.com> <20140311140520.GE16644@redhat.com> Message-ID: <1394550599.32465.73.camel@willson.li.ssimo.org> On Tue, 2014-03-11 at 16:05 +0200, Alexander Bokovoy wrote: > On Tue, 11 Mar 2014, Jan Pazdziora wrote: > >On Mon, Feb 24, 2014 at 02:26:27PM -0500, Nathaniel McCallum wrote: > >> Before this patch, ipa-kdb would load global configuration on startup > >> and never update it. This means that if global configuration is changed, > >> the KDC never receives the new configuration until it is restarted. > >> > >> This patch enables caching of the global configuration with a timeout of > >> 60 seconds. > >> > >> https://fedorahosted.org/freeipa/ticket/4153 > > > >> >From 7daeae56671d7b3049b0341aad66c96877431bbe Mon Sep 17 00:00:00 2001 > >> From: Nathaniel McCallum > >> Date: Mon, 24 Feb 2014 14:19:13 -0500 > >> Subject: [PATCH] Periodically refresh global ipa-kdb configuration > >> > >> Before this patch, ipa-kdb would load global configuration on startup and > >> never update it. This means that if global configuration is changed, the > >> KDC never receives the new configuration until it is restarted. > >> > >> This patch enables caching of the global configuration with a timeout of > >> 60 seconds. > >> > >> https://fedorahosted.org/freeipa/ticket/4153 > > > >I have only read the code and it looks sane, so depending on how much > >you consider my word about code-reading worth, ack. > > > >However, my gut feeling is that my preferred way of handling the issue > >(without knowing much about the background of the ticket) would > >probably be a HUP signal handler or something similar, rather than > >polling for current values with the value timeout. This patch > >introduces small nondeterminism to the behaviour when the usage of the > >new values cannot really be enfoced by the admin (without the daemon > >restart). > Thing is, we need the update to happen when other, non-root process > makes the changes -- in our case when IPA server running under httpd > privileges performs series of MS-RPC calls towards smbd which lead to > creating certain LDAP objects. httpd couldn't send SIGHUP to a process > not owned by httpd's effective user (non-root). Yes but this is not really the way to go. The proper fix is to use syncrepl/persistent search to get a notification of when we need to reload the configuration. On the patch itself I have a NACK due to this syntax used in various places: function()->attribute don't. do. that. ever. assign whatever come from the function to a local variable and *check* it is not null, *then* use it. Simo. -- Simo Sorce * Red Hat, Inc * New York From massimiliano.perrone at tirasa.net Tue Mar 11 15:29:13 2014 From: massimiliano.perrone at tirasa.net (Massimiliano Perrone) Date: Tue, 11 Mar 2014 16:29:13 +0100 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope In-Reply-To: <531E3565.3070009@redhat.com> References: <52EA7F66.5040202@apache.org> <52EA9910.7030704@redhat.com> <52EB70A3.4090606@apache.org> <52EB74F5.1010002@redhat.com> <52EB8E8E.4040903@redhat.com> <52EBA251.6070208@apache.org> <52EBE3FD.3030709@redhat.com> <52EF7274.7010503@apache.org> <531DAF0D.2090208@redhat.com> <531E01A3.5030802@redhat.com> <531E0F25.6070805@redhat.com> <531E3565.3070009@redhat.com> Message-ID: <531F2BC9.4050606@tirasa.net> Hi guys, I hope to explain in a few words what we are doing with ConnID and IPA. Comments in-line. On 03/10/2014 10:57 PM, Dmitri Pal wrote: > On 03/10/2014 03:14 PM, Petr Viktorin wrote: >> On 03/10/2014 07:17 PM, Dmitri Pal wrote: >>> On 03/10/2014 08:24 AM, Petr Viktorin wrote: >>>> On 03/07/2014 04:39 PM, Marco Di Sabatino Di Diodoro wrote: >>>>> Hi all, >>>>> >>>>> >>>>> Il giorno 03/feb/2014, alle ore 11:41, Francesco Chicchiricc? >>>>> > ha scritto: >>>>> >>>>>> On 31/01/2014 18:57, Dmitri Pal wrote: >>>>>>> On 01/31/2014 08:17 AM, Francesco Chicchiricc? wrote: >> [...] >>>>>>>> I am actually not sure if it is "lightweight" connector could >>>>>>>> actually >>>>>>>> be better than a "loaded" connector (e.g. without proxy), from a >>>>>>>> deployment point of view, unless you are saying either that (a) a >>>>>>>> smart proxy is already available that can be reused >>>>>>> The idea can be reused as a starting point. IMO the easiest would >>>>>>> be to >>>>>>> look at the patches and use same machinery but implement different >>>>>>> commands. >>>>>>> >>>>>>>> or that (b) incorporating the smart proxy that we are going to >>>>>>>> develop >>>>>>>> into FreeIPA will easily happen. >> >> ^ quote left here deliberately >> >> [...] >>>>> >>>>> We start to implementing a FreeIPA ConnId connector for Apache >>>>> Syncope. >>>>> We have to implement all identity operations defined by the ConnId >>>>> framework. >>>>> I would like to know the implementation status of the Smart/Proxy >>>>> and if >>>>> we can use it to all the identity operations. >>>> >>>> I'm reviewing the Foreman Smart proxy patches now. They're not in the >>>> FreeIPA repository yet. However the remaining issues were with >>>> packaging, code organization, naming. >>>> >>>> The Smart Proxy is now specific to Foreman provisioning; it is not a >>>> full REST interface so it will probably not support all operations you >>>> need. >>>> >>>> For a full REST interface, patches are welcome but the core FreeIPA >>>> team has other priorities at the moment. The RFE ticket is here: >>>> https://fedorahosted.org/freeipa/ticket/4168. >>> >>> For user provisioning you do not need a full REST api. You need to have >>> a similar proxy but just for user related operations. >>> So the smart proxy can be used as a model to do what you need to >>> implement for Syncope integration. >> >> You'd be building two bridges (IPA--REST & REST--ConnID) when you >> could build just one. Unless you already have a suitable generic REST >> connector already, I don't think it's your best option. From this >> thread it seems to me that JSON-RPC--ConnID would not require >> significantly more work than just the REST--ConnID part. >> >>> What are the operations you need to implement? Can you list them? >> >> They were listed earlier in the thread, and [5]. > > > It is usually easy to take something that is already working like > smart proxy and change the entry points to the ones that you need. > I am not familiar with the architecture of the connectors. Are they > separate processes? Are they daemons? Are they forked per request? > Connection to IPA needs to be authenticated. If the connection to IPA > happens from a single process like smart proxy you do not need to > worry about machinery related to authentication and session managment. > It is already implemented. > This is why I was suggesting to use smart proxy. IMO REST vs. JSON is > not that big deal. They are similar. Doing things right from the > authentication POV and session management are much harder. But if we > do not see a value in using smart proxy even like a reference point > for ConnID I would not insist. Basically a ConnID bundle (ConnID is framework used by Apache Syncope to connect the external resources) is a Java library developed to invoke the following operations from Apache Syncope to the target resource: AUTHENTICATE CREATE UPDATE UPDATE_ATTRIBUTE_VALUES DELETE RESOLVE_USERNAME SCHEMA SEARCH SYNC TEST For example, ConnID already has an Active Directory bundle [9] and an LDAP bundle [10]. As you already know, our goal is to develop a new bundle to invoke the provisioning operations on IPA server installation. From "ConnID development" point of view, the first thing is to choose a right way (to read protocol/interfaces) to communicate with the server. Briefly "the right way" needs: *) a long term support interfaces; *) an interfaces that allows all user / group provisioning operations; *) a way which leaves ConnID developers totally independent from (in this case) the FreeIPA development. Starting from this introduction we think that the right way is to use JSON-RPC interfaces, with particular attention to authentication and session management, as suggested by you. Do we have to consider other critical factors before starting to work? Massi > > >> >>>>>> Otherwise, we will instead specialize the CMD connector [12] to >>>>>> feature the FreeIPA command-line interface (as suggested at the >>>>>> beginning of this thread). There will be potentially need, in this >>>>>> case, to include the ConnId connector server into the Syncope >>>>>> deployment architecture, but this is a supported pattern. >>>> >>>> Have you looked at JSON-RPC interface mentioned earlier in this >>>> thread, and [6]? It might be cleaner to use that than the command-line >>>> interface. >>>> >>>> >>>> >>>>> [1] http://syncope.apache.org/ >>>>> [2] http://tirasa.github.io/ConnId/ >>>>> [3] http://java.net/projects/identityconnectors/ >>>>> [4] https://github.com/Tirasa/ConnIdFreeIPABundle >>>>> [5] >>>>> http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html >>>>> >>>>> >>>>> [6] >>>>> https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html >>>>> >>>>> [7] http://www.freeipa.org/page/Documentation >>>>> [8] http://www.freeipa.org/page/V3/Smart_Proxy [9] https://github.com/Tirasa/ConnIdADBundle [10] https://github.com/Tirasa/ConnIdLDAPBundle >> > > -- Massimiliano Perrone Tel +39 393 9121310 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~massi/ "L'apprendere molte cose non insegna l'intelligenza" (Eraclito) From mkosek at redhat.com Tue Mar 11 15:33:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Mar 2014 16:33:42 +0100 Subject: [Freeipa-devel] [PATCH] 460 ipa-replica-install never checks for 7389 port Message-ID: <531F2CD6.3070706@redhat.com> When creating replica from a Dogtag 9 based IPA server, the port 7389 which is required for the installation is never checked by ipa-replica-conncheck even though it knows that it is being installed from the Dogtag 9 based FreeIPA. If the 7389 port would be blocked by firewall, installation would stuck with no hint to user. Make sure that the port configuration parsed from replica info file is used consistently in the installers. https://fedorahosted.org/freeipa/ticket/4240 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-460-ipa-replica-install-never-checks-for-7389-port.patch Type: text/x-patch Size: 9394 bytes Desc: not available URL: From pspacek at redhat.com Tue Mar 11 15:48:55 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 11 Mar 2014 16:48:55 +0100 Subject: [Freeipa-devel] [PATCH] 0471 permission_add: Remove permission entry if adding the ACI fails In-Reply-To: <531F2731.6030303@redhat.com> References: <530762FE.7080703@redhat.com> <20140311140817.GB12206@redhat.com> <531F2731.6030303@redhat.com> Message-ID: <531F3067.3060609@redhat.com> On 11.3.2014 16:09, Petr Viktorin wrote: > On 03/11/2014 03:08 PM, Jan Pazdziora wrote: >> On Fri, Feb 21, 2014 at 03:30:22PM +0100, Petr Viktorin wrote: >>> Hello, >>> A permission object was not removed in permission-add when adding >>> the ACI failed. Here is a fix. >>> >>> https://fedorahosted.org/freeipa/ticket/4187 >>> >>> >>> Earlier we agreed that patch authors should bug the reviewer. I >>> guess now this means I should set Patch-review-by in the ticket, >>> right? So: >>> Martin, you reviewed the other ACI patches so I think you should >>> continue. If you don't agree, unset the field in the ticket. >>> >>> -- >>> Petr? >> >>> From 5ad2066b71b09248d348a5c4c85ef2ace0c553a4 Mon Sep 17 00:00:00 2001 >>> From: Petr Viktorin >>> Date: Fri, 21 Feb 2014 13:58:15 +0100 >>> Subject: [PATCH] permission_add: Remove permission entry if adding the ACI >>> fails >>> >>> https://fedorahosted.org/freeipa/ticket/4187 >>> --- >>> ipalib/plugins/permission.py | 15 ++++++++++++++- >>> ipatests/test_xmlrpc/test_permission_plugin.py | 25 >>> +++++++++++++++++++++++++ >>> 2 files changed, 39 insertions(+), 1 deletion(-) >>> >>> diff --git a/ipalib/plugins/permission.py b/ipalib/plugins/permission.py >>> index >>> 64deb99ef98583daf0419a240aa8852b0262874d..cb6f18b478735920bbf6cef4febc91481631c560 >>> 100644 >>> --- a/ipalib/plugins/permission.py >>> +++ b/ipalib/plugins/permission.py >>> @@ -812,7 +812,20 @@ def pre_callback(self, ldap, dn, entry, attrs_list, >>> *keys, **options): >>> return dn >>> >>> def post_callback(self, ldap, dn, entry, *keys, **options): >>> - self.obj.add_aci(entry) >>> + try: >>> + self.obj.add_aci(entry) >>> + except Exception: >>> + # Adding the ACI failed. >>> + # We want to be 100% sure the ACI is not there, so try to >>> + # remove it. (This is a no-op if the ACI was not added.) >>> + self.obj.remove_aci(entry) >>> + # Remove the entry >>> + try: >>> + self.api.Backend['ldap2'].delete_entry(entry) >>> + except errors.NotFound: >>> + pass >>> + # Re-raise original exception >>> + raise >>> self.obj.postprocess_result(entry, options) >>> return dn >> >> I'm not totally happy about this patch. >> >> What happens when the ACI is already in LDAP and some part of that >> self.obj.add_aci(entry) operation fails? Won't you go and instead of >> doing noop, remove the ACI instead? > > Unfortunately, yes, these operations are racy. When something fails, or when > doing two operations simultaneously, it is possible that the objects are not > both added. > If that happens, it is the ACI that should be missing. The permission is added > first, and the ACI is deleted first. This means that when things fail, access > is denied, which is both more secure and easier to spot than having a stray > ACI floating around. > > (In the long term, I'd really like to see a DS plugin for permission/ACI sync, > so we can leverage transactions -- IPA is really the wrong layer to > re-implement transactions in.) This calls for https://fedorahosted.org/389/ticket/581 [RFE] Support LDAP transactions :-) Maybe we should always add a comment about each particular use case to give it the right priority ... Petr^2 Spacek From mkosek at redhat.com Tue Mar 11 15:55:52 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Mar 2014 16:55:52 +0100 Subject: [Freeipa-devel] [PATCH] 459 Avoid passing non-terminated string to is_master_host In-Reply-To: <20140307092145.GT16644@redhat.com> References: <53198E04.8070106@redhat.com> <20140307092145.GT16644@redhat.com> Message-ID: <531F3208.4000706@redhat.com> On 03/07/2014 10:21 AM, Alexander Bokovoy wrote: > On Fri, 07 Mar 2014, Martin Kosek wrote: >> When string is not terminated, queries with corrupted base may be sent >> to LDAP: >> >> ... cn=ipa1.example.com,cn=masters... >> >> https://fedorahosted.org/freeipa/ticket/4214 >> >> -- >> Martin Kosek >> Supervisor, Software Engineering - Identity Management Team >> Red Hat Inc. > >> From 74bb082c7c286e9911f1a376ed9ce25845857672 Mon Sep 17 00:00:00 2001 >> From: Martin Kosek >> Date: Fri, 7 Mar 2014 10:06:52 +0100 >> Subject: [PATCH] Avoid passing non-terminated string to is_master_host >> >> When string is not terminated, queries with corrupted base may be sent >> to LDAP: >> >> ... cn=ipa1.example.com,cn=masters... >> >> https://fedorahosted.org/freeipa/ticket/4214 >> --- >> daemons/ipa-kdb/ipa_kdb_mspac.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c >> index >> 9137cd5ad1e6166fd5d6e765fab2c8178ca0587c..c1b018cc80402c2c3488487aee1d9709b902c5b4 >> 100644 >> --- a/daemons/ipa-kdb/ipa_kdb_mspac.c >> +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c >> @@ -488,13 +488,14 @@ static krb5_error_code ipadb_fill_info3(struct >> ipadb_context *ipactx, >> } >> >> data = krb5_princ_component(ipactx->context, princ, 1); >> - strres = malloc(data->length); >> + strres = malloc(data->length+1); >> if (strres == NULL) { >> krb5_free_principal(ipactx->kcontext, princ); >> return ENOENT; >> } >> >> memcpy(strres, data->data, data->length); >> + strres[data->length] = '\0'; >> krb5_free_principal(ipactx->kcontext, princ); >> >> /* Only add PAC to TGT to services on IPA masters to allow querying > Obvious ACK. > Pushed to: master: 740298d1208e92c264ef5752ac3fe6adf1240790 ipa-3-3: 0430d0eb2b605290e34b9392a902ef2114a2d743 Martin From pviktori at redhat.com Tue Mar 11 15:59:26 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 11 Mar 2014 16:59:26 +0100 Subject: [Freeipa-devel] [PATCH] 460 ipa-replica-install never checks for 7389 port In-Reply-To: <531F2CD6.3070706@redhat.com> References: <531F2CD6.3070706@redhat.com> Message-ID: <531F32DE.5030803@redhat.com> On 03/11/2014 04:33 PM, Martin Kosek wrote: > When creating replica from a Dogtag 9 based IPA server, the port 7389 > which is required for the installation is never checked by > ipa-replica-conncheck even though it knows that it is being installed > from the Dogtag 9 based FreeIPA. If the 7389 port would be blocked by > firewall, installation would stuck with no hint to user. > > Make sure that the port configuration parsed from replica info file > is used consistently in the installers. > > https://fedorahosted.org/freeipa/ticket/4240 > ACK -- Petr? From amessina at messinet.com Tue Mar 11 16:00:16 2014 From: amessina at messinet.com (Anthony Messina) Date: Tue, 11 Mar 2014 11:00:16 -0500 Subject: [Freeipa-devel] [PATCH] 459 Avoid passing non-terminated string to is_master_host In-Reply-To: <531F3208.4000706@redhat.com> References: <53198E04.8070106@redhat.com> <20140307092145.GT16644@redhat.com> <531F3208.4000706@redhat.com> Message-ID: <1460551.NonnMt5E3a@linux-ws1.messinet.com> On Tuesday, March 11, 2014 04:55:52 PM Martin Kosek wrote: > On 03/07/2014 10:21 AM, Alexander Bokovoy wrote: > > On Fri, 07 Mar 2014, Martin Kosek wrote: > >> When string is not terminated, queries with corrupted base may be sent > >> to LDAP: > >> > >> ... cn=ipa1.example.com,cn=masters... > >> > >> https://fedorahosted.org/freeipa/ticket/4214 > >> > >> -- > >> Martin Kosek > >> Supervisor, Software Engineering - Identity Management Team > >> Red Hat Inc. > > > > > > > >> From 74bb082c7c286e9911f1a376ed9ce25845857672 Mon Sep 17 00:00:00 2001 > >> From: Martin Kosek > >> Date: Fri, 7 Mar 2014 10:06:52 +0100 > >> Subject: [PATCH] Avoid passing non-terminated string to is_master_host > >> > >> When string is not terminated, queries with corrupted base may be sent > >> to LDAP: > >> > >> ... cn=ipa1.example.com,cn=masters... > >> > >> https://fedorahosted.org/freeipa/ticket/4214 > >> --- > >> daemons/ipa-kdb/ipa_kdb_mspac.c | 3 ++- > >> 1 file changed, 2 insertions(+), 1 deletion(-) > >> > >> diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c > >> b/daemons/ipa-kdb/ipa_kdb_mspac.c index > >> 9137cd5ad1e6166fd5d6e765fab2c8178ca0587c..c1b018cc80402c2c3488487aee1d970 > >> 9b902c5b4 100644 > >> --- a/daemons/ipa-kdb/ipa_kdb_mspac.c > >> +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c > >> @@ -488,13 +488,14 @@ static krb5_error_code ipadb_fill_info3(struct > >> ipadb_context *ipactx, > >> > >> } > >> > >> data = krb5_princ_component(ipactx->context, princ, 1); > >> > >> - strres = malloc(data->length); > >> + strres = malloc(data->length+1); > >> > >> if (strres == NULL) { > >> krb5_free_principal(ipactx->kcontext, princ); > >> return ENOENT; > >> } > >> > >> memcpy(strres, data->data, data->length); > >> > >> + strres[data->length] = '\0'; > >> > >> krb5_free_principal(ipactx->kcontext, princ); > >> > >> /* Only add PAC to TGT to services on IPA masters to allow > >>querying>> > > Obvious ACK. > > > > > > Pushed to: > master: 740298d1208e92c264ef5752ac3fe6adf1240790 > ipa-3-3: 0430d0eb2b605290e34b9392a902ef2114a2d743 > > Martin Thank you guys. -A -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mkosek at redhat.com Tue Mar 11 16:10:59 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Mar 2014 17:10:59 +0100 Subject: [Freeipa-devel] [PATCH] 460 ipa-replica-install never checks for 7389 port In-Reply-To: <531F32DE.5030803@redhat.com> References: <531F2CD6.3070706@redhat.com> <531F32DE.5030803@redhat.com> Message-ID: <531F3593.7020007@redhat.com> On 03/11/2014 04:59 PM, Petr Viktorin wrote: > On 03/11/2014 04:33 PM, Martin Kosek wrote: >> When creating replica from a Dogtag 9 based IPA server, the port 7389 >> which is required for the installation is never checked by >> ipa-replica-conncheck even though it knows that it is being installed >> from the Dogtag 9 based FreeIPA. If the 7389 port would be blocked by >> firewall, installation would stuck with no hint to user. >> >> Make sure that the port configuration parsed from replica info file >> is used consistently in the installers. >> >> https://fedorahosted.org/freeipa/ticket/4240 >> > > ACK Pushed to: master: 0be66e9a67e433d36b9e4c00a17b45393d51a888 ipa-3-3: 892daaa79dba5473b30816d97e15b27d7d4b9d58 From abokovoy at redhat.com Tue Mar 11 17:09:42 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Mar 2014 19:09:42 +0200 Subject: [Freeipa-devel] [PATCH] 0149: ipa-sam: ipa-sam: cache gid to sid and uid to sid requests in idmap cache Message-ID: <20140311170942.GG16644@redhat.com> Hi, Add idmap_cache calls to ipa-sam to prevent huge numbers of LDAP calls to the directory service for gid/uid<->sid resolution. Additionally, this patch further reduces number of queries by: - fast fail on uidNumber=0 which doesn't exist in FreeIPA, - return fallback group correctly when looking up user primary group as is done during init, - checking for group objectclass in case insensitive way Based on the patch by Jason Woods https://fedorahosted.org/freeipa/ticket/4234 and https://bugzilla.redhat.com/show_bug.cgi?id=1073829 https://bugzilla.redhat.com/show_bug.cgi?id=1074314 -- / Alexander Bokovoy -------------- next part -------------- >From de5e03f7f7bf707c00b11569998b68b5c87744ed Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 7 Mar 2014 16:38:24 +0000 Subject: [PATCH 2/2] ipa-sam: cache gid to sid and uid to sid requests in idmap cache Add idmap_cache calls to ipa-sam to prevent huge numbers of LDAP calls to the directory service for gid/uid<->sid resolution. Additionally, this patch further reduces number of queries by: - fast fail on uidNumber=0 which doesn't exist in FreeIPA, - return fallback group correctly when looking up user primary group as is done during init, - checking for group objectclass in case insensitive way Based on the patch by Jason Woods https://fedorahosted.org/freeipa/ticket/4234 and https://bugzilla.redhat.com/show_bug.cgi?id=1073829 https://bugzilla.redhat.com/show_bug.cgi?id=1074314 --- daemons/ipa-sam/ipa_sam.c | 125 +++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 113 insertions(+), 12 deletions(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 7a8eeb4..4eee3a6 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -82,6 +82,28 @@ struct trustAuthInOutBlob { struct AuthenticationInformationArray previous;/* [subcontext(0),flag(LIBNDR_FLAG_REMAINING)] */ }/* [gensize,public,nopush] */; +/* from generated idmap.h - hopefully OK */ +enum id_type +#ifndef USE_UINT_ENUMS + { + ID_TYPE_NOT_SPECIFIED, + ID_TYPE_UID, + ID_TYPE_GID, + ID_TYPE_BOTH +} +#else + { __donnot_use_enum_id_type=0x7FFFFFFF} +#define ID_TYPE_NOT_SPECIFIED ( 0 ) +#define ID_TYPE_UID ( 1 ) +#define ID_TYPE_GID ( 2 ) +#define ID_TYPE_BOTH ( 3 ) +#endif +; + +struct unixid { + uint32_t id; + enum id_type type; +}/* [public] */; enum ndr_err_code ndr_pull_trustAuthInOutBlob(struct ndr_pull *ndr, int ndr_flags, struct trustAuthInOutBlob *r); /*available in libndr-samba.so */ bool sid_check_is_builtin(const struct dom_sid *sid); /* available in libpdb.so */ @@ -91,6 +113,7 @@ char *sid_string_talloc(TALLOC_CTX *mem_ctx, const struct dom_sid *sid); /* avai char *sid_string_dbg(const struct dom_sid *sid); /* available in libsmbconf.so */ char *escape_ldap_string(TALLOC_CTX *mem_ctx, const char *s); /* available in libsmbconf.so */ bool secrets_store(const char *key, const void *data, size_t size); /* available in libpdb.so */ +void idmap_cache_set_sid2unixid(const struct dom_sid *sid, struct unixid *unix_id); /* available in libsmbconf.so */ #define LDAP_PAGE_SIZE 1024 #define LDAP_OBJ_SAMBASAMACCOUNT "ipaNTUserAttrs" @@ -750,8 +773,8 @@ static bool ldapsam_sid_to_id(struct pdb_methods *methods, } for (c = 0; values[c] != NULL; c++) { - if (strncmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val, - values[c]->bv_len) == 0) { + if (strncasecmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val, + values[c]->bv_len) == 0) { break; } } @@ -769,6 +792,9 @@ static bool ldapsam_sid_to_id(struct pdb_methods *methods, } unixid_from_gid(id, strtoul(gid_str, NULL, 10)); + + idmap_cache_set_sid2unixid(sid, id); + ret = true; goto done; } @@ -785,8 +811,11 @@ static bool ldapsam_sid_to_id(struct pdb_methods *methods, unixid_from_uid(id, strtoul(value, NULL, 10)); + idmap_cache_set_sid2unixid(sid, id); + ret = true; done: + TALLOC_FREE(mem_ctx); return ret; } @@ -806,6 +835,18 @@ static bool ldapsam_uid_to_sid(struct pdb_methods *methods, uid_t uid, int rc; enum idmap_error_code err; TALLOC_CTX *tmp_ctx = talloc_stackframe(); + struct unixid id; + + /* Fast fail if we get a request for uidNumber=0 because it currently + * will never exist in the directory + * Saves an expensive LDAP call of which failure will never be cached + */ + if (uid == 0) { + DEBUG(3, ("ERROR: Received request for uid %u, " + "fast failing as it will never exist\n", + (unsigned int)uid)); + goto done; + } filter = talloc_asprintf(tmp_ctx, "(&(uidNumber=%u)" @@ -852,6 +893,10 @@ static bool ldapsam_uid_to_sid(struct pdb_methods *methods, uid_t uid, sid_copy(sid, user_sid); + unixid_from_uid(&id, uid); + + idmap_cache_set_sid2unixid(sid, &id); + ret = true; done: @@ -866,21 +911,30 @@ static bool ldapsam_gid_to_sid(struct pdb_methods *methods, gid_t gid, struct ldapsam_privates *priv = (struct ldapsam_privates *)methods->private_data; char *filter; - const char *attrs[] = { LDAP_ATTRIBUTE_SID, NULL }; + const char *attrs[] = { LDAP_ATTRIBUTE_SID, LDAP_ATTRIBUTE_OBJECTCLASS, NULL }; LDAPMessage *result = NULL; LDAPMessage *entry = NULL; bool ret = false; - char *group_sid_string; + char *group_sid_string = NULL; struct dom_sid *group_sid = NULL; + struct berval **values; + size_t c; int rc; enum idmap_error_code err; TALLOC_CTX *tmp_ctx = talloc_stackframe(); + struct unixid id; filter = talloc_asprintf(tmp_ctx, - "(&(gidNumber=%u)" - "(objectClass=%s))", + "(|(&(gidNumber=%u)" + "(objectClass=%s))" + "(&(uidNumber=%u)" + "(objectClass=%s)" + "(objectClass=%s)))", + (unsigned int)gid, + LDAP_OBJ_GROUPMAP, (unsigned int)gid, - LDAP_OBJ_GROUPMAP); + LDAP_OBJ_POSIXACCOUNT, + LDAP_OBJ_SAMBASAMACCOUNT); if (filter == NULL) { DEBUG(3, ("talloc_asprintf failed\n")); goto done; @@ -892,14 +946,46 @@ static bool ldapsam_gid_to_sid(struct pdb_methods *methods, gid_t gid, } smbldap_talloc_autofree_ldapmsg(tmp_ctx, result); - if (ldap_count_entries(priv2ld(priv), result) != 1) { - DEBUG(3, ("ERROR: Got %d entries for gid %u, expected one\n", + if (ldap_count_entries(priv2ld(priv), result) == 0) { + DEBUG(3, ("ERROR: Got %d entries for gid %u, expected at least one\n", ldap_count_entries(priv2ld(priv), result), (unsigned int)gid)); goto done; } - entry = ldap_first_entry(priv2ld(priv), result); + for (entry = ldap_first_entry(priv2ld(priv), result); + entry != NULL; + entry = ldap_next_entry(priv2ld(priv), entry)) { + + values = ldap_get_values_len(priv2ld(priv), entry, "objectClass"); + if (values == NULL) { + DEBUG(10, ("Cannot find any objectclasses.\n")); + goto done; + } + + for (c = 0; values[c] != NULL; c++) { + if (strncasecmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val, + values[c]->bv_len) == 0) { + goto found; + } + } + + } + +found: + // If we didn't find a group we found a user - so this is a primary group + // For user private group, use fallback group + if (entry == NULL) { + + DEBUG(10, ("Did not find user private group %u, " + "returning fallback group.\n", (unsigned int)gid)); + + sid_copy(sid, + &priv->ipasam_privates->fallback_primary_group); + ret = true; + goto done; + + } group_sid_string = get_single_attribute(tmp_ctx, priv2ld(priv), entry, LDAP_ATTRIBUTE_SID); @@ -910,7 +996,7 @@ static bool ldapsam_gid_to_sid(struct pdb_methods *methods, gid_t gid, } err = sss_idmap_sid_to_smb_sid(priv->ipasam_privates->idmap_ctx, - group_sid_string, &group_sid); + group_sid_string, &group_sid); if (err != IDMAP_SUCCESS) { DEBUG(3, ("Error calling sid_string_talloc for sid '%s'\n", group_sid_string)); @@ -919,6 +1005,10 @@ static bool ldapsam_gid_to_sid(struct pdb_methods *methods, gid_t gid, sid_copy(sid, group_sid); + unixid_from_gid(&id, gid); + + idmap_cache_set_sid2unixid(sid, &id); + ret = true; done: @@ -2865,6 +2955,7 @@ static int ipasam_get_sid_by_gid(struct ldapsam_privates *ldap_state, struct dom_sid *sid = NULL; int count; enum idmap_error_code err; + struct unixid id; tmp_ctx = talloc_new("ipasam_get_sid_by_gid"); if (tmp_ctx == NULL) { @@ -2919,6 +3010,10 @@ static int ipasam_get_sid_by_gid(struct ldapsam_privates *ldap_state, } sid_copy(_sid, sid); + unixid_from_gid(&id, gid); + + idmap_cache_set_sid2unixid(sid, &id); + ret = 0; done: @@ -2938,6 +3033,7 @@ static int ipasam_get_primary_group_sid(TALLOC_CTX *mem_ctx, uint32_t uid; uint32_t gid; struct dom_sid *group_sid; + struct unixid id; TALLOC_CTX *tmp_ctx = talloc_init("ipasam_get_primary_group_sid"); if (tmp_ctx == NULL) { @@ -2976,8 +3072,13 @@ static int ipasam_get_primary_group_sid(TALLOC_CTX *mem_ctx, } } - ret = 0; + unixid_from_gid(&id, gid); + + idmap_cache_set_sid2unixid(group_sid, &id); + + ret = 0; done: + if (ret == 0) { *_group_sid = talloc_steal(mem_ctx, group_sid); } -- 1.8.3.1 From dpal at redhat.com Tue Mar 11 18:09:27 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 11 Mar 2014 14:09:27 -0400 Subject: [Freeipa-devel] DNSSEC: upgrade path to Vault In-Reply-To: <531EF936.6090701@redhat.com> References: <52FD02B7.3060404@redhat.com> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> <531D98A8.8090207@redhat.com> <531D9D37.70201@redhat.com> <531EE667.5060700@redhat.com> <531EF1C1.40805@redhat.com> <531EF936.6090701@redhat.com> Message-ID: <531F5157.7010109@redhat.com> On 03/11/2014 07:53 AM, Petr Spacek wrote: > On 11.3.2014 12:21, Martin Kosek wrote: >> On 03/11/2014 11:33 AM, Petr Spacek wrote: >>> On 10.3.2014 12:08, Martin Kosek wrote: >>>> On 03/10/2014 11:49 AM, Petr Spacek wrote: >>>>> On 7.3.2014 17:33, Dmitri Pal wrote: >>>>>> I do not think it is the right architectural approach to try to >>>>>> fix a specific >>>>>> use case with one off solution while we already know that we need >>>>>> a key >>>>>> storage. >>>>>> I would rather do things right and reusable than jam them into >>>>>> the currently >>>>>> proposed release boundaries. >>>>> I want to make clear that I'm not opposed to Vault in general. I'm >>>>> questioning >>>>> the necessity of Vault from the beginning because it will delay >>>>> DNSSEC >>>>> significantly. >>>> >>>> +1, I also now see number of scenarios where Vault will be needed. >>>> >>>>> >>>>> One of the proposals in this thread is to use something simple for >>>>> DNSSEC keys >>>>> (with few lines of Python code) and migrate DNSSEC with Vault when >>>>> Vault is >>>>> available and stable enough (in some later release). >>>>> >>>>>> I understand that Vault brings a lot of work to the table. But >>>>>> let us do it >>>>>> right and if it does not fit into 4.0 let us do it in 4.1. >>>>> We will have one huge release with DNSSEC + Vault at once if we to >>>>> postpone >>>>> DNSSEC to the same release as Vault. >>>>> >>>>> As a result, it would be harder to debug it because we will have >>>>> to find if >>>>> something is broken because of: >>>>> - DNSSEC-IPA integration >>>>> - Vault-IPA integration >>>>> - DNSSEC-Vault integration. >>>>> >>>>> I don't think it is a good idea to make such huge release. >>>>> >>>>> "Release early, release often" >>>>> >>>> >>>> I must say I tend to agree with Petr. If the "poor man's solution" >>>> of DNSSEC >>>> without Vault does not cost us too much time and it would seem that >>>> the Vault >>>> is not going to squeeze in 4.0 deadlines, I would rather release >>>> the poor man's >>>> solution in 4.0 and switch to Vault when it's available in 4.1. >>>> >>>> This would let our users test the non-Vault parts of our DNSSEC >>>> solution >>>> instead of waiting to test a perfect solution. >>> >>> Yesterday we have agreed that DNSSEC support is not going to depend >>> on Vault >>> from the beginning and that we can migrate to Vault later. >>> >>> Here I'm proposing safe upgrade path from non-vault to Vault solution. >>> >>> After all, it seems relatively easy. >>> >>> TL;DR version >>> ============= >>> Use information in cn=masters to detect if there are old replicas and >>> temporarily convert new keys from Vault to LDAP storage (until all >>> old replicas >>> are deleted). >>> >>> Full version >>> ============ >>> IPA 4.0 is going to have OpenDNSSEC key generator on a single IPA >>> server and >>> separate key import/export daemon (i.e. script called from cron or >>> something >>> like that) on all IPA servers. >>> >>> In 4.0, we can add new LDAP objects for DNSSEC-related IPA services >>> (please >>> propose better names :-): >>> - key generator: >>> cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example >>> >> >> cn=DNSSEC,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example >> >> DNSSEC will be translated by FreeIPA to appropriate service name. >> This can vary >> between platforms. "v1" can be an attribute of the entry, I would not >> add it's >> to name. >> >>> - key imported/exporter: >>> cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example >>> >> >> I am thinking it may be sufficient to have just: >> >> cn=DNSSEC,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example >> >> for all DNSSEC empowered masters and then just have: >> ipaConfigString: keygenerator >> >> ... in the master VM. I am just trying to be future agnostic and avoid >> hardcoding service names and implementations details in cn=masters. >> FreeIPA on >> master would know what services to run when it is a keygenerator or not. >> >>> Initial state before upgrade: >>> - N IPA 4.0 replicas >>> - N DNSSECKeyImporterv1 service instances (i.e. key distribution for >>> IPA 4.0) >>> - 1 OpenDNSSECv1 service instance (key generator) >>> >>> Now we want to upgrade a first replica to IPA 4.1. For simplicity, >>> let's add a >>> *requirement* to upgrade the replica with OpenDNSSECv1 first. (We can >>> generalize the procedure if this requirement is not acceptable.) >>> >>> Upgrade procedure: >>> - stop OpenDNSSECv1 service >>> - stop DNSSECKeyImporterv1 service >>> - convert OpenDNSSECv1 database to OpenDNSSECv2 >>> This step is not related to Vault. We need to covert local SQLite >>> database from >>> single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC. >>> >>> - convert private keys from LDAP to Vault *but let them in LDAP for >>> a while*. >>> - walk through cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example and check >>> if there >>> are any other replicas with DNSSECKeyImporterv1 service: >> >> In my proposal, one would just search for >> "cn=DNSSEC,cn=*,cn=masters..." with >> filter "(ipaConfigString=version 1)". > Why not :-) I do not care as long as it is unambiguous. > >>> a) No such replica exists -> delete old-fashioned keys from LDAP. >>> b) Another replica with DNSSECKeyImporterv1 service exists: >>> - *Temporarily* run DNSSECKeyImporterv2 which will do one-way key >>> conversion >>> from Vault to LDAP. >>> - DNSSECKeyImporterv2 can check e.g. daily if all >>> DNSSECKeyImporterv1 instances >>> were deleted or not. Then it can delete old-fashioned keys from LDAP >>> and also >>> stop itself when all old replicas were deleted (and compatibility >>> mode is not >>> needed anymore). >>> >>> This approach removes time constraints from upgrade procedure and >>> prevents DNS >>> servers from failing when update is delayed etc. As a result, admin >>> can upgrade >>> replica-by-replica at will. >> >> Ok, though I am a little bit afraid that the temporary solution would >> become a >> permanent solution. There would need to be something forcing and >> pushing admins >> to migrate. > > Could you be more specific? Is there any particular difference from > any other IPA upgrade? > > We always tell users to upgrade soon: >> It is expected >> that all servers will be upgraded in a relatively short period (days >> or weeks, >> not months). They should be able to co-exist peacefully but new >> features will >> not be available on old servers [...] > > IMHO the key is in "new features will not be available on old > servers". In this case the "new feature" is "no single point of > failure" which seems pretty important to me :-) > The only narrow place IMO is the "-*Temporarily* run DNSSECKeyImporterv2 which will do one-way key conversion from Vault to LDAP." I think that OpenDNSSEC will use ldap up to the point when there are any masters that are old. Even if the vault is installed but not everything is upgraded every time the OpenDNSSEC needs to dump the keys it will check if there are any servers that are old. If there are, it will continue doing things the old way using keys from LDAP but would save a copy in vault. If it detects that there are no more old servers it will remove the ldap keys (and may be the old schema). The DNS servers (if they reread data automatically) would detect that the keys are deleted and fall forward to vault. If DNS servers do not reread keys automatically then they will do a check at the restart time and start reading the keys from vault. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Mar 11 18:14:51 2014 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 11 Mar 2014 14:14:51 -0400 Subject: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope In-Reply-To: <531F2BC9.4050606@tirasa.net> References: <52EA7F66.5040202@apache.org> <52EA9910.7030704@redhat.com> <52EB70A3.4090606@apache.org> <52EB74F5.1010002@redhat.com> <52EB8E8E.4040903@redhat.com> <52EBA251.6070208@apache.org> <52EBE3FD.3030709@redhat.com> <52EF7274.7010503@apache.org> <531DAF0D.2090208@redhat.com> <531E01A3.5030802@redhat.com> <531E0F25.6070805@redhat.com> <531E3565.3070009@redhat.com> <531F2BC9.4050606@tirasa.net> Message-ID: <531F529B.6020709@redhat.com> On 03/11/2014 11:29 AM, Massimiliano Perrone wrote: > Hi guys, > I hope to explain in a few words what we are doing with ConnID and > IPA. Comments in-line. > > On 03/10/2014 10:57 PM, Dmitri Pal wrote: >> On 03/10/2014 03:14 PM, Petr Viktorin wrote: >>> On 03/10/2014 07:17 PM, Dmitri Pal wrote: >>>> On 03/10/2014 08:24 AM, Petr Viktorin wrote: >>>>> On 03/07/2014 04:39 PM, Marco Di Sabatino Di Diodoro wrote: >>>>>> Hi all, >>>>>> >>>>>> >>>>>> Il giorno 03/feb/2014, alle ore 11:41, Francesco Chicchiricc? >>>>>> > ha scritto: >>>>>> >>>>>>> On 31/01/2014 18:57, Dmitri Pal wrote: >>>>>>>> On 01/31/2014 08:17 AM, Francesco Chicchiricc? wrote: >>> [...] >>>>>>>>> I am actually not sure if it is "lightweight" connector could >>>>>>>>> actually >>>>>>>>> be better than a "loaded" connector (e.g. without proxy), from a >>>>>>>>> deployment point of view, unless you are saying either that (a) a >>>>>>>>> smart proxy is already available that can be reused >>>>>>>> The idea can be reused as a starting point. IMO the easiest would >>>>>>>> be to >>>>>>>> look at the patches and use same machinery but implement different >>>>>>>> commands. >>>>>>>> >>>>>>>>> or that (b) incorporating the smart proxy that we are going to >>>>>>>>> develop >>>>>>>>> into FreeIPA will easily happen. >>> >>> ^ quote left here deliberately >>> >>> [...] >>>>>> >>>>>> We start to implementing a FreeIPA ConnId connector for Apache >>>>>> Syncope. >>>>>> We have to implement all identity operations defined by the ConnId >>>>>> framework. >>>>>> I would like to know the implementation status of the Smart/Proxy >>>>>> and if >>>>>> we can use it to all the identity operations. >>>>> >>>>> I'm reviewing the Foreman Smart proxy patches now. They're not in the >>>>> FreeIPA repository yet. However the remaining issues were with >>>>> packaging, code organization, naming. >>>>> >>>>> The Smart Proxy is now specific to Foreman provisioning; it is not a >>>>> full REST interface so it will probably not support all operations >>>>> you >>>>> need. >>>>> >>>>> For a full REST interface, patches are welcome but the core FreeIPA >>>>> team has other priorities at the moment. The RFE ticket is here: >>>>> https://fedorahosted.org/freeipa/ticket/4168. >>>> >>>> For user provisioning you do not need a full REST api. You need to >>>> have >>>> a similar proxy but just for user related operations. >>>> So the smart proxy can be used as a model to do what you need to >>>> implement for Syncope integration. >>> >>> You'd be building two bridges (IPA--REST & REST--ConnID) when you >>> could build just one. Unless you already have a suitable generic >>> REST connector already, I don't think it's your best option. From >>> this thread it seems to me that JSON-RPC--ConnID would not require >>> significantly more work than just the REST--ConnID part. >>> >>>> What are the operations you need to implement? Can you list them? >>> >>> They were listed earlier in the thread, and [5]. >> >> >> It is usually easy to take something that is already working like >> smart proxy and change the entry points to the ones that you need. >> I am not familiar with the architecture of the connectors. Are they >> separate processes? Are they daemons? Are they forked per request? >> Connection to IPA needs to be authenticated. If the connection to IPA >> happens from a single process like smart proxy you do not need to >> worry about machinery related to authentication and session >> managment. It is already implemented. >> This is why I was suggesting to use smart proxy. IMO REST vs. JSON is >> not that big deal. They are similar. Doing things right from the >> authentication POV and session management are much harder. But if we >> do not see a value in using smart proxy even like a reference point >> for ConnID I would not insist. > > Basically a ConnID bundle (ConnID is framework used by Apache Syncope > to connect the external resources) is a Java library developed to > invoke the following operations from Apache Syncope to the target > resource: > > AUTHENTICATE > CREATE > UPDATE > UPDATE_ATTRIBUTE_VALUES > DELETE > RESOLVE_USERNAME > SCHEMA > SEARCH > SYNC > TEST > > For example, ConnID already has an Active Directory bundle [9] and an > LDAP bundle [10]. > > As you already know, our goal is to develop a new bundle to invoke the > provisioning operations on IPA server installation. > > From "ConnID development" point of view, the first thing is to choose > a right way (to read protocol/interfaces) to communicate with the server. > > Briefly "the right way" needs: > *) a long term support interfaces; > *) an interfaces that allows all user / group provisioning operations; > *) a way which leaves ConnID developers totally independent from (in > this case) the FreeIPA development. > > Starting from this introduction we think that the right way is to use > JSON-RPC interfaces, with particular attention to authentication and > session management, as suggested by you. > > Do we have to consider other critical factors before starting to work? This seems reasonable. Here are some other questions that you might want to ask yourself starting the work. http://www.freeipa.org/page/General_considerations (there is no intent to scare you :-) ) HTH Dmitri > > Massi > >> >> >>> >>>>>>> Otherwise, we will instead specialize the CMD connector [12] to >>>>>>> feature the FreeIPA command-line interface (as suggested at the >>>>>>> beginning of this thread). There will be potentially need, in this >>>>>>> case, to include the ConnId connector server into the Syncope >>>>>>> deployment architecture, but this is a supported pattern. >>>>> >>>>> Have you looked at JSON-RPC interface mentioned earlier in this >>>>> thread, and [6]? It might be cleaner to use that than the >>>>> command-line >>>>> interface. >>>>> >>>>> >>>>> >>>>>> [1] http://syncope.apache.org/ >>>>>> [2] http://tirasa.github.io/ConnId/ >>>>>> [3] http://java.net/projects/identityconnectors/ >>>>>> [4] https://github.com/Tirasa/ConnIdFreeIPABundle >>>>>> [5] >>>>>> http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html >>>>>> >>>>>> >>>>>> [6] >>>>>> https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html >>>>>> >>>>>> [7] http://www.freeipa.org/page/Documentation >>>>>> [8] http://www.freeipa.org/page/V3/Smart_Proxy > [9] https://github.com/Tirasa/ConnIdADBundle > [10] https://github.com/Tirasa/ConnIdLDAPBundle >>> >> >> > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Tue Mar 11 18:40:02 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 11 Mar 2014 14:40:02 -0400 Subject: [Freeipa-devel] DNSSEC: upgrade path to Vault In-Reply-To: <531EE667.5060700@redhat.com> References: <52FD02B7.3060404@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> <531D98A8.8090207@redhat.com> <531D9D37.70201@redhat.com> <531EE667.5060700@redhat.com> Message-ID: <1394563202.32465.99.camel@willson.li.ssimo.org> On Tue, 2014-03-11 at 11:33 +0100, Petr Spacek wrote: > Yesterday we have agreed that DNSSEC support is not going to depend on Vault > from the beginning and that we can migrate to Vault later. > > Here I'm proposing safe upgrade path from non-vault to Vault solution. > > After all, it seems relatively easy. Ok let me put my 2c in. > TL;DR version > ============= > Use information in cn=masters to detect if there are old replicas and > temporarily convert new keys from Vault to LDAP storage (until all old > replicas are deleted). I think this is not necessary, we do not support running an infrastructure for long times with mixed major IPA versions. So we should not need to do this. > Full version > ============ > IPA 4.0 is going to have OpenDNSSEC key generator on a single IPA server and > separate key import/export daemon (i.e. script called from cron or something > like that) on all IPA servers. > > In 4.0, we can add new LDAP objects for DNSSEC-related IPA services (please > propose better names :-): > - key generator: > cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example As Martin said -> DNSSEC, the version is irrelevant here unless you are proposing to be able to run v1 or v2 conditionally with the same code base, if not then on upgrade the new openDNSSEC code will simply be upgraded like all other freeipa components. We do not capture version number for any of them. > - key imported/exporter: > cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example This is probably not needed as a separate key, if we are using systemd then we simply make one unit file depend on another so both start together in master, while on replica we only have 1 service to start anyway. If we are on sysv we will deploy our own init script that start both components at the same time on master, only one on replicas. The difference about what to start will be that only one master is configured as key generator, we do not even need to represent this in ldap in theory, because you cannot move the role by simply changing an LDAP entry anyway, and the difference can simply be a configuration file on the keygenerator master. > Initial state before upgrade: > - N IPA 4.0 replicas > - N DNSSECKeyImporterv1 service instances (i.e. key distribution for IPA 4.0) > - 1 OpenDNSSECv1 service instance (key generator) > > Now we want to upgrade a first replica to IPA 4.1. For simplicity, let's add a > *requirement* to upgrade the replica with OpenDNSSECv1 first. (We can > generalize the procedure if this requirement is not acceptable.) I think we can proceed with this restriction for now, either tat or the admin is required to stop and unconfigure the key generator service anyway. > Upgrade procedure: > - stop OpenDNSSECv1 service > - stop DNSSECKeyImporterv1 service stpo DNSSEC (will stop both) > - convert OpenDNSSECv1 database to OpenDNSSECv2 > This step is not related to Vault. We need to covert local SQLite database > from single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC. > > - convert private keys from LDAP to Vault *but let them in LDAP for a while*. This is only true *if* we'll decide to move storage to the Vault, we may not want to, or it may happen in a separate release. > - walk through cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example and check if there > are any other replicas with DNSSECKeyImporterv1 service: > a) No such replica exists -> delete old-fashioned keys from LDAP. I say we do this step unconditionally if we move to the vault, all other DNS server have functional keys for a while anyway (should always have at least 1 month autonomy), and we clearly state people must upgrade the infrastructure in a week not in months. So we should never need to keep old keys. > b) Another replica with DNSSECKeyImporterv1 service exists: > - *Temporarily* run DNSSECKeyImporterv2 which will do one-way key conversion > from Vault to LDAP. We do not need this, you must update all replicas to a vesion that knows what to do and then they'll find the new keys where they are. > - DNSSECKeyImporterv2 can check e.g. daily if all DNSSECKeyImporterv1 > instances were deleted or not. Then it can delete old-fashioned keys from LDAP > and also stop itself when all old replicas were deleted (and compatibility > mode is not needed anymore). We also avoid this. The *only* thing we really need to do IMO is that if a DNS server finds out it's key for a zone are expired then it shuts down itself and makes itself unavailable so clients will start falling over to another DNS server and the admin will have to troubleshoot and resolve out why the keys were not accessible. If the reason is that they forgot to update a replica then they should just proceed and update and the DNS server will restart after that (we may want to make sure we have a way to pull the latest key at upgrade or we have chick egg issue where replica update fails because DNS does not start). > This approach removes time constraints from upgrade procedure and prevents DNS > servers from failing when update is delayed etc. As a result, admin can > upgrade replica-by-replica at will. I want time constraints and I want DNS server to fail fast. constraints are in the order of 1 month though, not a few days. I think 1 month is sufficient. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Mar 11 20:14:58 2014 From: simo at redhat.com (Simo Sorce) Date: Tue, 11 Mar 2014 16:14:58 -0400 Subject: [Freeipa-devel] DNSSEC: upgrade path to Vault In-Reply-To: <1394563202.32465.99.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> <531D98A8.8090207@redhat.com> <531D9D37.70201@redhat.com> <531EE667.5060700@redhat.com> <1394563202.32465.99.camel@willson.li.ssimo.org> Message-ID: <1394568898.32465.108.camel@willson.li.ssimo.org> On Tue, 2014-03-11 at 14:40 -0400, Simo Sorce wrote: > The *only* thing we really need to do IMO is that if a DNS server > finds > out it's key for a zone are expired then it shuts down itself and > makes > itself unavailable so clients will start falling over to another DNS > server and the admin will have to troubleshoot and resolve out why the > keys were not accessible. If the reason is that they forgot to update > a > replica then they should just proceed and update and the DNS server > will > restart after that (we may want to make sure we have a way to pull the > latest key at upgrade or we have chick egg issue where replica update > fails because DNS does not start). > I am thinking that in case we have some zones protected with DNSSEC and some that are not (do we handle this case ?) then what we could do is simply to stop serving the secured zone. Is there an error code we can return that will make clients try another DNS server if they have multiple configured ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Mar 11 20:19:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 11 Mar 2014 21:19:13 +0100 Subject: [Freeipa-devel] DNSSEC: upgrade path to Vault In-Reply-To: <1394563202.32465.99.camel@willson.li.ssimo.org> References: <52FD02B7.3060404@redhat.com> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> <531D98A8.8090207@redhat.com> <531D9D37.70201@redhat.com> <531EE667.5060700@redhat.com> <1394563202.32465.99.camel@willson.li.ssimo.org> Message-ID: <531F6FC1.4020100@redhat.com> On 03/11/2014 07:40 PM, Simo Sorce wrote: > On Tue, 2014-03-11 at 11:33 +0100, Petr Spacek wrote: >> Yesterday we have agreed that DNSSEC support is not going to depend on Vault ... >> - walk through cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example and check if there >> are any other replicas with DNSSECKeyImporterv1 service: >> a) No such replica exists -> delete old-fashioned keys from LDAP. > > I say we do this step unconditionally if we move to the vault, all other > DNS server have functional keys for a while anyway (should always have > at least 1 month autonomy), and we clearly state people must upgrade the > infrastructure in a week not in months. So we should never need to keep > old keys. > >> b) Another replica with DNSSECKeyImporterv1 service exists: >> - *Temporarily* run DNSSECKeyImporterv2 which will do one-way key conversion >> from Vault to LDAP. > > We do not need this, you must update all replicas to a vesion that knows > what to do and then they'll find the new keys where they are. > >> - DNSSECKeyImporterv2 can check e.g. daily if all DNSSECKeyImporterv1 >> instances were deleted or not. Then it can delete old-fashioned keys from LDAP >> and also stop itself when all old replicas were deleted (and compatibility >> mode is not needed anymore). > > We also avoid this. > The *only* thing we really need to do IMO is that if a DNS server finds > out it's key for a zone are expired then it shuts down itself and makes > itself unavailable so clients will start falling over to another DNS > server and the admin will have to troubleshoot and resolve out why the > keys were not accessible. If the reason is that they forgot to update a > replica then they should just proceed and update and the DNS server will > restart after that (we may want to make sure we have a way to pull the > latest key at upgrade or we have chick egg issue where replica update > fails because DNS does not start). > >> This approach removes time constraints from upgrade procedure and prevents DNS >> servers from failing when update is delayed etc. As a result, admin can >> upgrade replica-by-replica at will. > > I want time constraints and I want DNS server to fail fast. > constraints are in the order of 1 month though, not a few days. > I think 1 month is sufficient. Do we need to do this unconditionally for whole DNS service? Let's say admin has 2 zones, my-dnssec-testing-zone.test and my-production-zone.test and keys for my-dnssec-testing-zone.test expire. Is this a reason to shut down the whole DNS service? I do not think so. Could we return with NotAuth or ServFail instead? Would DNS client failover for other DNS server for that broken zone? Martin From sbose at redhat.com Tue Mar 11 20:48:51 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 11 Mar 2014 21:48:51 +0100 Subject: [Freeipa-devel] [PATCH] 0149: ipa-sam: ipa-sam: cache gid to sid and uid to sid requests in idmap cache In-Reply-To: <20140311170942.GG16644@redhat.com> References: <20140311170942.GG16644@redhat.com> Message-ID: <20140311204851.GA7893@localhost.localdomain> On Tue, Mar 11, 2014 at 07:09:42PM +0200, Alexander Bokovoy wrote: > Hi, > > > Add idmap_cache calls to ipa-sam to prevent huge numbers of LDAP calls > to the > directory service for gid/uid<->sid resolution. > > Additionally, this patch further reduces number of queries by: > - fast fail on uidNumber=0 which doesn't exist in FreeIPA, > - return fallback group correctly when looking up user primary group as is > done during init, > - checking for group objectclass in case insensitive way > > Based on the patch by Jason Woods > > https://fedorahosted.org/freeipa/ticket/4234 > and > https://bugzilla.redhat.com/show_bug.cgi?id=1073829 > https://bugzilla.redhat.com/show_bug.cgi?id=1074314 I didn't had a chance to run some test so far, but here are my comments for the code. I will run some tests tomorrow. bye, Sumit > > -- > / Alexander Bokovoy > >From de5e03f7f7bf707c00b11569998b68b5c87744ed Mon Sep 17 00:00:00 2001 > From: Alexander Bokovoy > Date: Fri, 7 Mar 2014 16:38:24 +0000 > Subject: [PATCH 2/2] ipa-sam: cache gid to sid and uid to sid requests in > idmap cache > > Add idmap_cache calls to ipa-sam to prevent huge numbers of LDAP calls to the > directory service for gid/uid<->sid resolution. > > Additionally, this patch further reduces number of queries by: > - fast fail on uidNumber=0 which doesn't exist in FreeIPA, > - return fallback group correctly when looking up user primary group as is > done during init, > - checking for group objectclass in case insensitive way I think this list and the ticket list below would justify a split in at least two patches. > > Based on the patch by Jason Woods > > https://fedorahosted.org/freeipa/ticket/4234 > and > https://bugzilla.redhat.com/show_bug.cgi?id=1073829 > https://bugzilla.redhat.com/show_bug.cgi?id=1074314 > --- > daemons/ipa-sam/ipa_sam.c | 125 +++++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 113 insertions(+), 12 deletions(-) > > diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c > index 7a8eeb4..4eee3a6 100644 > --- a/daemons/ipa-sam/ipa_sam.c > +++ b/daemons/ipa-sam/ipa_sam.c > @@ -82,6 +82,28 @@ struct trustAuthInOutBlob { > struct AuthenticationInformationArray previous;/* [subcontext(0),flag(LIBNDR_FLAG_REMAINING)] */ > }/* [gensize,public,nopush] */; > > +/* from generated idmap.h - hopefully OK */ > +enum id_type > +#ifndef USE_UINT_ENUMS I think we do not need this Samba-ism here becasue we do not define USE_UINT_ENUMS anyways. Enums are fine imo, if you prefer defines I dont't mind. Btw, USE_UINT_ENUMS is not available in Samba either https://bugzilla.samba.org/show_bug.cgi?id=10477 :-) > + { > + ID_TYPE_NOT_SPECIFIED, > + ID_TYPE_UID, > + ID_TYPE_GID, > + ID_TYPE_BOTH > +} > +#else > + { __donnot_use_enum_id_type=0x7FFFFFFF} > +#define ID_TYPE_NOT_SPECIFIED ( 0 ) > +#define ID_TYPE_UID ( 1 ) > +#define ID_TYPE_GID ( 2 ) > +#define ID_TYPE_BOTH ( 3 ) > +#endif > +; > + > +struct unixid { > + uint32_t id; > + enum id_type type; > +}/* [public] */; > > enum ndr_err_code ndr_pull_trustAuthInOutBlob(struct ndr_pull *ndr, int ndr_flags, struct trustAuthInOutBlob *r); /*available in libndr-samba.so */ > bool sid_check_is_builtin(const struct dom_sid *sid); /* available in libpdb.so */ > @@ -91,6 +113,7 @@ char *sid_string_talloc(TALLOC_CTX *mem_ctx, const struct dom_sid *sid); /* avai > char *sid_string_dbg(const struct dom_sid *sid); /* available in libsmbconf.so */ > char *escape_ldap_string(TALLOC_CTX *mem_ctx, const char *s); /* available in libsmbconf.so */ > bool secrets_store(const char *key, const void *data, size_t size); /* available in libpdb.so */ > +void idmap_cache_set_sid2unixid(const struct dom_sid *sid, struct unixid *unix_id); /* available in libsmbconf.so */ > > #define LDAP_PAGE_SIZE 1024 > #define LDAP_OBJ_SAMBASAMACCOUNT "ipaNTUserAttrs" > @@ -750,8 +773,8 @@ static bool ldapsam_sid_to_id(struct pdb_methods *methods, > } > > for (c = 0; values[c] != NULL; c++) { > - if (strncmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val, > - values[c]->bv_len) == 0) { > + if (strncasecmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val, > + values[c]->bv_len) == 0) { > break; > } > } > @@ -769,6 +792,9 @@ static bool ldapsam_sid_to_id(struct pdb_methods *methods, > } > > unixid_from_gid(id, strtoul(gid_str, NULL, 10)); > + > + idmap_cache_set_sid2unixid(sid, id); > + > ret = true; > goto done; > } > @@ -785,8 +811,11 @@ static bool ldapsam_sid_to_id(struct pdb_methods *methods, > > unixid_from_uid(id, strtoul(value, NULL, 10)); > > + idmap_cache_set_sid2unixid(sid, id); > + > ret = true; > done: > + > TALLOC_FREE(mem_ctx); > return ret; > } > @@ -806,6 +835,18 @@ static bool ldapsam_uid_to_sid(struct pdb_methods *methods, uid_t uid, > int rc; > enum idmap_error_code err; > TALLOC_CTX *tmp_ctx = talloc_stackframe(); > + struct unixid id; > + > + /* Fast fail if we get a request for uidNumber=0 because it currently > + * will never exist in the directory > + * Saves an expensive LDAP call of which failure will never be cached > + */ > + if (uid == 0) { > + DEBUG(3, ("ERROR: Received request for uid %u, " > + "fast failing as it will never exist\n", > + (unsigned int)uid)); > + goto done; > + } > > filter = talloc_asprintf(tmp_ctx, > "(&(uidNumber=%u)" > @@ -852,6 +893,10 @@ static bool ldapsam_uid_to_sid(struct pdb_methods *methods, uid_t uid, > > sid_copy(sid, user_sid); > > + unixid_from_uid(&id, uid); > + > + idmap_cache_set_sid2unixid(sid, &id); > + > ret = true; > > done: > @@ -866,21 +911,30 @@ static bool ldapsam_gid_to_sid(struct pdb_methods *methods, gid_t gid, > struct ldapsam_privates *priv = > (struct ldapsam_privates *)methods->private_data; > char *filter; > - const char *attrs[] = { LDAP_ATTRIBUTE_SID, NULL }; > + const char *attrs[] = { LDAP_ATTRIBUTE_SID, LDAP_ATTRIBUTE_OBJECTCLASS, NULL }; > LDAPMessage *result = NULL; > LDAPMessage *entry = NULL; > bool ret = false; > - char *group_sid_string; > + char *group_sid_string = NULL; > struct dom_sid *group_sid = NULL; > + struct berval **values; > + size_t c; > int rc; > enum idmap_error_code err; > TALLOC_CTX *tmp_ctx = talloc_stackframe(); > + struct unixid id; > > filter = talloc_asprintf(tmp_ctx, > - "(&(gidNumber=%u)" > - "(objectClass=%s))", > + "(|(&(gidNumber=%u)" > + "(objectClass=%s))" > + "(&(uidNumber=%u)" > + "(objectClass=%s)" > + "(objectClass=%s)))", > + (unsigned int)gid, Can you add some indentation to make the grouping in the search filter more clear? > + LDAP_OBJ_GROUPMAP, > (unsigned int)gid, > - LDAP_OBJ_GROUPMAP); > + LDAP_OBJ_POSIXACCOUNT, > + LDAP_OBJ_SAMBASAMACCOUNT); > if (filter == NULL) { > DEBUG(3, ("talloc_asprintf failed\n")); > goto done; > @@ -892,14 +946,46 @@ static bool ldapsam_gid_to_sid(struct pdb_methods *methods, gid_t gid, > } > smbldap_talloc_autofree_ldapmsg(tmp_ctx, result); > > - if (ldap_count_entries(priv2ld(priv), result) != 1) { > - DEBUG(3, ("ERROR: Got %d entries for gid %u, expected one\n", > + if (ldap_count_entries(priv2ld(priv), result) == 0) { > + DEBUG(3, ("ERROR: Got %d entries for gid %u, expected at least one\n", > ldap_count_entries(priv2ld(priv), result), > (unsigned int)gid)); > goto done; > } > > - entry = ldap_first_entry(priv2ld(priv), result); > + for (entry = ldap_first_entry(priv2ld(priv), result); > + entry != NULL; > + entry = ldap_next_entry(priv2ld(priv), entry)) { > + > + values = ldap_get_values_len(priv2ld(priv), entry, "objectClass"); > + if (values == NULL) { > + DEBUG(10, ("Cannot find any objectclasses.\n")); > + goto done; > + } > + > + for (c = 0; values[c] != NULL; c++) { > + if (strncasecmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val, > + values[c]->bv_len) == 0) { > + goto found; > + } > + } > + > + } > + > +found: > + // If we didn't find a group we found a user - so this is a primary group > + // For user private group, use fallback group iirc the coding style says that we do not like C++ style comments. > + if (entry == NULL) { > + > + DEBUG(10, ("Did not find user private group %u, " > + "returning fallback group.\n", (unsigned int)gid)); > + > + sid_copy(sid, > + &priv->ipasam_privates->fallback_primary_group); > + ret = true; > + goto done; > + > + } > > group_sid_string = get_single_attribute(tmp_ctx, priv2ld(priv), entry, > LDAP_ATTRIBUTE_SID); > @@ -910,7 +996,7 @@ static bool ldapsam_gid_to_sid(struct pdb_methods *methods, gid_t gid, > } > > err = sss_idmap_sid_to_smb_sid(priv->ipasam_privates->idmap_ctx, > - group_sid_string, &group_sid); > + group_sid_string, &group_sid); > if (err != IDMAP_SUCCESS) { > DEBUG(3, ("Error calling sid_string_talloc for sid '%s'\n", > group_sid_string)); > @@ -919,6 +1005,10 @@ static bool ldapsam_gid_to_sid(struct pdb_methods *methods, gid_t gid, > > sid_copy(sid, group_sid); > > + unixid_from_gid(&id, gid); > + > + idmap_cache_set_sid2unixid(sid, &id); > + > ret = true; > > done: > @@ -2865,6 +2955,7 @@ static int ipasam_get_sid_by_gid(struct ldapsam_privates *ldap_state, > struct dom_sid *sid = NULL; > int count; > enum idmap_error_code err; > + struct unixid id; > > tmp_ctx = talloc_new("ipasam_get_sid_by_gid"); > if (tmp_ctx == NULL) { > @@ -2919,6 +3010,10 @@ static int ipasam_get_sid_by_gid(struct ldapsam_privates *ldap_state, > } > sid_copy(_sid, sid); > > + unixid_from_gid(&id, gid); > + > + idmap_cache_set_sid2unixid(sid, &id); > + > ret = 0; > > done: > @@ -2938,6 +3033,7 @@ static int ipasam_get_primary_group_sid(TALLOC_CTX *mem_ctx, > uint32_t uid; > uint32_t gid; > struct dom_sid *group_sid; > + struct unixid id; > > TALLOC_CTX *tmp_ctx = talloc_init("ipasam_get_primary_group_sid"); > if (tmp_ctx == NULL) { > @@ -2976,8 +3072,13 @@ static int ipasam_get_primary_group_sid(TALLOC_CTX *mem_ctx, > } > } > > - ret = 0; > + unixid_from_gid(&id, gid); > + > + idmap_cache_set_sid2unixid(group_sid, &id); > + > + ret = 0; > done: > + > if (ret == 0) { > *_group_sid = talloc_steal(mem_ctx, group_sid); > } > -- > 1.8.3.1 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From abokovoy at redhat.com Tue Mar 11 21:04:29 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 11 Mar 2014 23:04:29 +0200 Subject: [Freeipa-devel] [PATCH] 0149: ipa-sam: ipa-sam: cache gid to sid and uid to sid requests in idmap cache In-Reply-To: <20140311204851.GA7893@localhost.localdomain> References: <20140311170942.GG16644@redhat.com> <20140311204851.GA7893@localhost.localdomain> Message-ID: <20140311210429.GI16644@redhat.com> On Tue, 11 Mar 2014, Sumit Bose wrote: >On Tue, Mar 11, 2014 at 07:09:42PM +0200, Alexander Bokovoy wrote: >> Hi, >> >> >> Add idmap_cache calls to ipa-sam to prevent huge numbers of LDAP calls >> to the >> directory service for gid/uid<->sid resolution. >> >> Additionally, this patch further reduces number of queries by: >> - fast fail on uidNumber=0 which doesn't exist in FreeIPA, >> - return fallback group correctly when looking up user primary group as is >> done during init, >> - checking for group objectclass in case insensitive way >> >> Based on the patch by Jason Woods >> >> https://fedorahosted.org/freeipa/ticket/4234 >> and >> https://bugzilla.redhat.com/show_bug.cgi?id=1073829 >> https://bugzilla.redhat.com/show_bug.cgi?id=1074314 > >I didn't had a chance to run some test so far, but here are my comments >for the code. I will run some tests tomorrow. Fixed the code according to the comments. I've also changed the patch author to Jason as majority of the work was done by him, I only made it closer to what is expected in Samba and FreeIPA. -- / Alexander Bokovoy -------------- next part -------------- >From aaaabd6de3d834ab9acc4791c39646806723f0d3 Mon Sep 17 00:00:00 2001 From: Jason Woods Date: Fri, 7 Mar 2014 16:38:24 +0000 Subject: [PATCH] ipa-sam: cache gid to sid and uid to sid requests in idmap cache Add idmap_cache calls to ipa-sam to prevent huge numbers of LDAP calls to the directory service for gid/uid<->sid resolution. Additionally, this patch further reduces number of queries by: - fast fail on uidNumber=0 which doesn't exist in FreeIPA, - return fallback group correctly when looking up user primary group as is done during init, - checking for group objectclass in case insensitive way Patch by Jason Woods Reviewed-by: Alexander Bokovoy https://fedorahosted.org/freeipa/ticket/4234 and https://bugzilla.redhat.com/show_bug.cgi?id=1073829 https://bugzilla.redhat.com/show_bug.cgi?id=1074314 --- daemons/ipa-sam/ipa_sam.c | 128 +++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 114 insertions(+), 14 deletions(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 1ca504d..3b69f9e 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -82,6 +82,18 @@ struct trustAuthInOutBlob { struct AuthenticationInformationArray previous;/* [subcontext(0),flag(LIBNDR_FLAG_REMAINING)] */ }/* [gensize,public,nopush] */; +/* from generated idmap.h - hopefully OK */ +enum id_type { + ID_TYPE_NOT_SPECIFIED, + ID_TYPE_UID, + ID_TYPE_GID, + ID_TYPE_BOTH +}; + +struct unixid { + uint32_t id; + enum id_type type; +}/* [public] */; enum ndr_err_code ndr_pull_trustAuthInOutBlob(struct ndr_pull *ndr, int ndr_flags, struct trustAuthInOutBlob *r); /*available in libndr-samba.so */ bool sid_check_is_builtin(const struct dom_sid *sid); /* available in libpdb.so */ @@ -91,6 +103,7 @@ char *sid_string_talloc(TALLOC_CTX *mem_ctx, const struct dom_sid *sid); /* avai char *sid_string_dbg(const struct dom_sid *sid); /* available in libsmbconf.so */ char *escape_ldap_string(TALLOC_CTX *mem_ctx, const char *s); /* available in libsmbconf.so */ bool secrets_store(const char *key, const void *data, size_t size); /* available in libpdb.so */ +void idmap_cache_set_sid2unixid(const struct dom_sid *sid, struct unixid *unix_id); /* available in libsmbconf.so */ #define LDAP_PAGE_SIZE 1024 #define LDAP_OBJ_SAMBASAMACCOUNT "ipaNTUserAttrs" @@ -750,8 +763,8 @@ static bool ldapsam_sid_to_id(struct pdb_methods *methods, } for (c = 0; values[c] != NULL; c++) { - if (strncmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val, - values[c]->bv_len) == 0) { + if (strncasecmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val, + values[c]->bv_len) == 0) { break; } } @@ -769,6 +782,9 @@ static bool ldapsam_sid_to_id(struct pdb_methods *methods, } unixid_from_gid(id, strtoul(gid_str, NULL, 10)); + + idmap_cache_set_sid2unixid(sid, id); + ret = true; goto done; } @@ -785,8 +801,11 @@ static bool ldapsam_sid_to_id(struct pdb_methods *methods, unixid_from_uid(id, strtoul(value, NULL, 10)); + idmap_cache_set_sid2unixid(sid, id); + ret = true; done: + TALLOC_FREE(mem_ctx); return ret; } @@ -806,6 +825,18 @@ static bool ldapsam_uid_to_sid(struct pdb_methods *methods, uid_t uid, int rc; enum idmap_error_code err; TALLOC_CTX *tmp_ctx = talloc_stackframe(); + struct unixid id; + + /* Fast fail if we get a request for uidNumber=0 because it currently + * will never exist in the directory + * Saves an expensive LDAP call of which failure will never be cached + */ + if (uid == 0) { + DEBUG(3, ("ERROR: Received request for uid %u, " + "fast failing as it will never exist\n", + (unsigned int)uid)); + goto done; + } filter = talloc_asprintf(tmp_ctx, "(&(uidNumber=%u)" @@ -852,6 +883,10 @@ static bool ldapsam_uid_to_sid(struct pdb_methods *methods, uid_t uid, sid_copy(sid, user_sid); + unixid_from_uid(&id, uid); + + idmap_cache_set_sid2unixid(sid, &id); + ret = true; done: @@ -866,21 +901,30 @@ static bool ldapsam_gid_to_sid(struct pdb_methods *methods, gid_t gid, struct ldapsam_privates *priv = (struct ldapsam_privates *)methods->private_data; char *filter; - const char *attrs[] = { LDAP_ATTRIBUTE_SID, NULL }; + const char *attrs[] = { LDAP_ATTRIBUTE_SID, LDAP_ATTRIBUTE_OBJECTCLASS, NULL }; LDAPMessage *result = NULL; LDAPMessage *entry = NULL; bool ret = false; - char *group_sid_string; + char *group_sid_string = NULL; struct dom_sid *group_sid = NULL; + struct berval **values; + size_t c; int rc; enum idmap_error_code err; TALLOC_CTX *tmp_ctx = talloc_stackframe(); + struct unixid id; filter = talloc_asprintf(tmp_ctx, - "(&(gidNumber=%u)" - "(objectClass=%s))", + "(|(&(gidNumber=%u)" + "(objectClass=%s))" + "(&(uidNumber=%u)" + "(objectClass=%s)" + "(objectClass=%s)))", + (unsigned int)gid, + LDAP_OBJ_GROUPMAP, (unsigned int)gid, - LDAP_OBJ_GROUPMAP); + LDAP_OBJ_POSIXACCOUNT, + LDAP_OBJ_SAMBASAMACCOUNT); if (filter == NULL) { DEBUG(3, ("talloc_asprintf failed\n")); goto done; @@ -892,14 +936,46 @@ static bool ldapsam_gid_to_sid(struct pdb_methods *methods, gid_t gid, } smbldap_talloc_autofree_ldapmsg(tmp_ctx, result); - if (ldap_count_entries(priv2ld(priv), result) != 1) { - DEBUG(3, ("ERROR: Got %d entries for gid %u, expected one\n", + if (ldap_count_entries(priv2ld(priv), result) == 0) { + DEBUG(3, ("ERROR: Got %d entries for gid %u, expected at least one\n", ldap_count_entries(priv2ld(priv), result), (unsigned int)gid)); goto done; } - entry = ldap_first_entry(priv2ld(priv), result); + for (entry = ldap_first_entry(priv2ld(priv), result); + entry != NULL; + entry = ldap_next_entry(priv2ld(priv), entry)) { + + values = ldap_get_values_len(priv2ld(priv), entry, "objectClass"); + if (values == NULL) { + DEBUG(10, ("Cannot find any objectclasses.\n")); + goto done; + } + + for (c = 0; values[c] != NULL; c++) { + if (strncasecmp(LDAP_OBJ_GROUPMAP, values[c]->bv_val, + values[c]->bv_len) == 0) { + goto found; + } + } + + } + +found: + /* If we didn't find a group we found a user - so this is a primary group + * For user private group, use fallback group */ + if (entry == NULL) { + + DEBUG(10, ("Did not find user private group %u, " + "returning fallback group.\n", (unsigned int)gid)); + + sid_copy(sid, + &priv->ipasam_privates->fallback_primary_group); + ret = true; + goto done; + + } group_sid_string = get_single_attribute(tmp_ctx, priv2ld(priv), entry, LDAP_ATTRIBUTE_SID); @@ -910,7 +986,7 @@ static bool ldapsam_gid_to_sid(struct pdb_methods *methods, gid_t gid, } err = sss_idmap_sid_to_smb_sid(priv->ipasam_privates->idmap_ctx, - group_sid_string, &group_sid); + group_sid_string, &group_sid); if (err != IDMAP_SUCCESS) { DEBUG(3, ("Error calling sid_string_talloc for sid '%s'\n", group_sid_string)); @@ -919,6 +995,10 @@ static bool ldapsam_gid_to_sid(struct pdb_methods *methods, gid_t gid, sid_copy(sid, group_sid); + unixid_from_gid(&id, gid); + + idmap_cache_set_sid2unixid(sid, &id); + ret = true; done: @@ -2456,10 +2536,16 @@ static int delete_subtree(struct ldapsam_privates *ldap_state, char* dn) rc = smbldap_search(ldap_state->smbldap_state, dn, scope, filter, NULL, 0, &result); TALLOC_FREE(filter); - if (result != NULL) { - smbldap_talloc_autofree_ldapmsg(dn, result); + if (rc != LDAP_SUCCESS) { + return rc; } + if (result == NULL) { + return LDAP_NO_MEMORY; + } + + smbldap_talloc_autofree_ldapmsg(dn, result); + for (entry = ldap_first_entry(state, result); entry != NULL; entry = ldap_next_entry(state, entry)) { @@ -2467,6 +2553,9 @@ static int delete_subtree(struct ldapsam_privates *ldap_state, char* dn) /* remove child entries */ if ((entry_dn != NULL) && (strcmp(entry_dn, dn) != 0)) { rc = smbldap_delete(ldap_state->smbldap_state, entry_dn); + if (rc != LDAP_SUCCESS) { + return rc; + } } } rc = smbldap_delete(ldap_state->smbldap_state, dn); @@ -2856,6 +2945,7 @@ static int ipasam_get_sid_by_gid(struct ldapsam_privates *ldap_state, struct dom_sid *sid = NULL; int count; enum idmap_error_code err; + struct unixid id; tmp_ctx = talloc_new("ipasam_get_sid_by_gid"); if (tmp_ctx == NULL) { @@ -2910,6 +3000,10 @@ static int ipasam_get_sid_by_gid(struct ldapsam_privates *ldap_state, } sid_copy(_sid, sid); + unixid_from_gid(&id, gid); + + idmap_cache_set_sid2unixid(sid, &id); + ret = 0; done: @@ -2929,6 +3023,7 @@ static int ipasam_get_primary_group_sid(TALLOC_CTX *mem_ctx, uint32_t uid; uint32_t gid; struct dom_sid *group_sid; + struct unixid id; TALLOC_CTX *tmp_ctx = talloc_init("ipasam_get_primary_group_sid"); if (tmp_ctx == NULL) { @@ -2967,8 +3062,13 @@ static int ipasam_get_primary_group_sid(TALLOC_CTX *mem_ctx, } } - ret = 0; + unixid_from_gid(&id, gid); + + idmap_cache_set_sid2unixid(group_sid, &id); + + ret = 0; done: + if (ret == 0) { *_group_sid = talloc_steal(mem_ctx, group_sid); } -- 1.8.3.1 From jpazdziora at redhat.com Wed Mar 12 09:20:41 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 12 Mar 2014 10:20:41 +0100 Subject: [Freeipa-devel] [PATCH] 0471 permission_add: Remove permission entry if adding the ACI fails In-Reply-To: <531F2731.6030303@redhat.com> References: <530762FE.7080703@redhat.com> <20140311140817.GB12206@redhat.com> <531F2731.6030303@redhat.com> Message-ID: <20140312092040.GB2735@redhat.com> On Tue, Mar 11, 2014 at 04:09:37PM +0100, Petr Viktorin wrote: > > Unfortunately, yes, these operations are racy. When something fails, > or when doing two operations simultaneously, it is possible that the > objects are not both added. > If that happens, it is the ACI that should be missing. The > permission is added first, and the ACI is deleted first. This means > that when things fail, access is denied, which is both more secure > and easier to spot than having a stray ACI floating around. > > (In the long term, I'd really like to see a DS plugin for > permission/ACI sync, so we can leverage transactions -- IPA is > really the wrong layer to re-implement transactions in.) > > To answer your question, if the permission+ACI is already in LDAP, > the call will fail with a DuplicateEntry error and post_callback > won't get called. > > For the case that another permission_add command is called to add a > permission of the same name, the existence of the permission entry > acts as a "lock": while it's there, the other permission_add will > fail, and removing it ("releasing the lock") is the last thing done > in the error handler. > > I guess it would be good to add a comment saying this. Thank you for the explanation. In that case, ack on the patch, provided you add a nice comment. ;-) -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From sbose at redhat.com Wed Mar 12 10:02:02 2014 From: sbose at redhat.com (Sumit Bose) Date: Wed, 12 Mar 2014 11:02:02 +0100 Subject: [Freeipa-devel] [PATCH] 0149: ipa-sam: ipa-sam: cache gid to sid and uid to sid requests in idmap cache In-Reply-To: <20140311210429.GI16644@redhat.com> References: <20140311170942.GG16644@redhat.com> <20140311204851.GA7893@localhost.localdomain> <20140311210429.GI16644@redhat.com> Message-ID: <20140312100201.GC7893@localhost.localdomain> On Tue, Mar 11, 2014 at 11:04:29PM +0200, Alexander Bokovoy wrote: > On Tue, 11 Mar 2014, Sumit Bose wrote: > >On Tue, Mar 11, 2014 at 07:09:42PM +0200, Alexander Bokovoy wrote: > >>Hi, > >> > >> > >>Add idmap_cache calls to ipa-sam to prevent huge numbers of LDAP calls > >>to the > >>directory service for gid/uid<->sid resolution. > >> > >>Additionally, this patch further reduces number of queries by: > >> - fast fail on uidNumber=0 which doesn't exist in FreeIPA, > >> - return fallback group correctly when looking up user primary group as is > >> done during init, > >> - checking for group objectclass in case insensitive way > >> > >>Based on the patch by Jason Woods > >> > >>https://fedorahosted.org/freeipa/ticket/4234 > >>and > >>https://bugzilla.redhat.com/show_bug.cgi?id=1073829 > >>https://bugzilla.redhat.com/show_bug.cgi?id=1074314 > > > >I didn't had a chance to run some test so far, but here are my comments > >for the code. I will run some tests tomorrow. > Fixed the code according to the comments. > > I've also changed the patch author to Jason as majority of the work was > done by him, I only made it closer to what is expected in Samba and > FreeIPA. Patch looks good and the basic functionality like adding a trust is still working. ACK bye, Sumit > > -- > / Alexander Bokovoy From pspacek at redhat.com Wed Mar 12 10:19:02 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 12 Mar 2014 11:19:02 +0100 Subject: [Freeipa-devel] DNSSEC: upgrade path to Vault In-Reply-To: <531F6FC1.4020100@redhat.com> References: <52FD02B7.3060404@redhat.com> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> <531D98A8.8090207@redhat.com> <531D9D37.70201@redhat.com> <531EE667.5060700@redhat.com> <1394563202.32465.99.camel@willson.li.ssimo.org> <531F6FC1.4020100@redhat.com> Message-ID: <53203496.4080001@redhat.com> On 11.3.2014 21:19, Martin Kosek wrote: > On 03/11/2014 07:40 PM, Simo Sorce wrote: >> On Tue, 2014-03-11 at 11:33 +0100, Petr Spacek wrote: >>> Yesterday we have agreed that DNSSEC support is not going to depend on Vault > ... >>> - walk through cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example and check if there >>> are any other replicas with DNSSECKeyImporterv1 service: >>> a) No such replica exists -> delete old-fashioned keys from LDAP. >> >> I say we do this step unconditionally if we move to the vault, all other >> DNS server have functional keys for a while anyway (should always have >> at least 1 month autonomy), and we clearly state people must upgrade the >> infrastructure in a week not in months. So we should never need to keep >> old keys. >> >>> b) Another replica with DNSSECKeyImporterv1 service exists: >>> - *Temporarily* run DNSSECKeyImporterv2 which will do one-way key conversion >>> from Vault to LDAP. >> >> We do not need this, you must update all replicas to a vesion that knows >> what to do and then they'll find the new keys where they are. >> >>> - DNSSECKeyImporterv2 can check e.g. daily if all DNSSECKeyImporterv1 >>> instances were deleted or not. Then it can delete old-fashioned keys from LDAP >>> and also stop itself when all old replicas were deleted (and compatibility >>> mode is not needed anymore). >> >> We also avoid this. >> The *only* thing we really need to do IMO is that if a DNS server finds >> out it's key for a zone are expired then it shuts down itself and makes >> itself unavailable so clients will start falling over to another DNS >> server and the admin will have to troubleshoot and resolve out why the >> keys were not accessible. If the reason is that they forgot to update a >> replica then they should just proceed and update and the DNS server will >> restart after that (we may want to make sure we have a way to pull the >> latest key at upgrade or we have chick egg issue where replica update >> fails because DNS does not start). >> >>> This approach removes time constraints from upgrade procedure and prevents DNS >>> servers from failing when update is delayed etc. As a result, admin can >>> upgrade replica-by-replica at will. >> >> I want time constraints and I want DNS server to fail fast. >> constraints are in the order of 1 month though, not a few days. >> I think 1 month is sufficient. > > Do we need to do this unconditionally for whole DNS service? Let's say admin > has 2 zones, my-dnssec-testing-zone.test and my-production-zone.test and keys > for my-dnssec-testing-zone.test expire. Is this a reason to shut down the > whole DNS service? I do not think so. > > Could we return with NotAuth or ServFail instead? Would DNS client failover > for other DNS server for that broken zone? SERVFAIL encourages client to fail over. It could be tricky from implementation point of view but I will try it. -- Petr^2 Spacek From jpazdziora at redhat.com Wed Mar 12 10:37:13 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 12 Mar 2014 11:37:13 +0100 Subject: [Freeipa-devel] [PATCH] 0147: ipaserver/rpcserver: catch ACIError and return proper message for out-of-realm users In-Reply-To: <20140306100323.GN16644@redhat.com> References: <20140306100323.GN16644@redhat.com> Message-ID: <20140312103713.GE2735@redhat.com> On Thu, Mar 06, 2014 at 12:03:23PM +0200, Alexander Bokovoy wrote: > Hi, > > we had similar issue in past, in jsonserver_session() class, fixed by > 0292ebd1 which Tomas did for ticket https://fedorahosted.org/freeipa/ticket/3252 > > This one is for non-sessioned call: > https://fedorahosted.org/freeipa/ticket/4225 The patch does not seem to apply against master. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From pviktori at redhat.com Wed Mar 12 11:02:18 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 12 Mar 2014 12:02:18 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <531E1896.3050700@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> Message-ID: <53203EBA.6060605@redhat.com> On 03/10/2014 08:55 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 02/27/2014 10:18 PM, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>> Updated patch based on feedback from Foreman team. I added a new URI, >>>> /features, which Foreman uses to determine what capabilities a proxy >>>> has. >>>> >>>> rob >>> >>> On my VMs, where the first request is handled properly but the server >>> hangs on the second one. I gave you access to the machines for >>> investigation. >> >> Sent you something out-of-band but in short, I wasn't able to reproduce >> on your reproducing VMs :-( Ping me tomorrow and we'll try it together. It ended up a combination of my mistake and a bug in GSSProxy. At least you found the bug. https://fedorahosted.org/gss-proxy/ticket/121 >>> Please add the Python libraries (python-cherrypy, python-requests, >>> python-kerberos) to BuildRequires. Otherwise the build fails due to >>> pylint errors. >> >> Fixed. >> >>> >>> In the man page: >>> >>>> +Create a host or user whose credentials will be used by the server to >>>> make requests and add it to the role: >>>> + >>>> + $ ipa user\-add \-\-first=Smartproxy \-\-last=Serversmartproxy >>>> + $ ipa role\-add\-member \-\-users=smartproxy 'Smartproxy management' >>> >>> the first command should be >>> ipa user-add smartproxy --first=Smartproxy --last=Serversmartproxy >>> since by default the username is 'sserversmartproxy'. >> >> The problem was a missing space before smartproxy. I have the login name >> last in this example. Fixed. >> >>> >>> A nitpick regarding the systemd service: according to [0], Type=forking >>> should be avoided. Is there a reason against setting Type=simple, and >>> removing the PID file? >> >> Because I wasn't able to get this working with cherrypy daemon mode. >> AFAICT it forks itself and systemd wouldn't end up with the right pid so >> can't stop the service. > > And now the updated patch. The changes are super-minor. > > rob > One last nitpick: the IPAErrors get encoded as JSON but the Content-Encoding is set to text/html. It's a one-line change so I went ahead and tested with it. ACK from me if you agree. I spoke to Martin and he's still not satisfied with needing the COPR repo on f20. I think we can live with it though. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1106-7+pviktori-rest.patch Type: text/x-patch Size: 47657 bytes Desc: not available URL: From lkrispen at redhat.com Wed Mar 12 11:12:09 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 12 Mar 2014 12:12:09 +0100 Subject: [Freeipa-devel] DNSSEC: upgrade path to Vault In-Reply-To: <531EE667.5060700@redhat.com> References: <52FD02B7.3060404@redhat.com> <530CD22D.7010806@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> <531D98A8.8090207@redhat.com> <531D9D37.70201@redhat.com> <531EE667.5060700@redhat.com> Message-ID: <53204109.4010804@redhat.com> On 03/11/2014 11:33 AM, Petr Spacek wrote: > On 10.3.2014 12:08, Martin Kosek wrote: >> On 03/10/2014 11:49 AM, Petr Spacek wrote: >>> On 7.3.2014 17:33, Dmitri Pal wrote: >>>> I do not think it is the right architectural approach to try to fix >>>> a specific >>>> use case with one off solution while we already know that we need a >>>> key storage. >>>> I would rather do things right and reusable than jam them into the >>>> currently >>>> proposed release boundaries. >>> I want to make clear that I'm not opposed to Vault in general. I'm >>> questioning >>> the necessity of Vault from the beginning because it will delay DNSSEC >>> significantly. >> >> +1, I also now see number of scenarios where Vault will be needed. >> >>> >>> One of the proposals in this thread is to use something simple for >>> DNSSEC keys >>> (with few lines of Python code) and migrate DNSSEC with Vault when >>> Vault is >>> available and stable enough (in some later release). >>> >>>> I understand that Vault brings a lot of work to the table. But let >>>> us do it >>>> right and if it does not fit into 4.0 let us do it in 4.1. >>> We will have one huge release with DNSSEC + Vault at once if we to >>> postpone >>> DNSSEC to the same release as Vault. >>> >>> As a result, it would be harder to debug it because we will have to >>> find if >>> something is broken because of: >>> - DNSSEC-IPA integration >>> - Vault-IPA integration >>> - DNSSEC-Vault integration. >>> >>> I don't think it is a good idea to make such huge release. >>> >>> "Release early, release often" >>> >> >> I must say I tend to agree with Petr. If the "poor man's solution" of >> DNSSEC >> without Vault does not cost us too much time and it would seem that >> the Vault >> is not going to squeeze in 4.0 deadlines, I would rather release the >> poor man's >> solution in 4.0 and switch to Vault when it's available in 4.1. >> >> This would let our users test the non-Vault parts of our DNSSEC solution >> instead of waiting to test a perfect solution. > > Yesterday we have agreed that DNSSEC support is not going to depend on > Vault from the beginning and that we can migrate to Vault later. > > Here I'm proposing safe upgrade path from non-vault to Vault solution. > > After all, it seems relatively easy. > > TL;DR version > ============= > Use information in cn=masters to detect if there are old replicas and > temporarily convert new keys from Vault to LDAP storage (until all old > replicas are deleted). > > Full version > ============ > IPA 4.0 is going to have OpenDNSSEC key generator on a single IPA > server and separate key import/export daemon (i.e. script called from > cron or something like that) on all IPA servers. > > In 4.0, we can add new LDAP objects for DNSSEC-related IPA services > (please propose better names :-): > - key generator: > cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example > > > - key imported/exporter: > cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example > > > > Initial state before upgrade: > - N IPA 4.0 replicas > - N DNSSECKeyImporterv1 service instances (i.e. key distribution for > IPA 4.0) > - 1 OpenDNSSECv1 service instance (key generator) > > Now we want to upgrade a first replica to IPA 4.1. For simplicity, > let's add a *requirement* to upgrade the replica with OpenDNSSECv1 > first. (We can generalize the procedure if this requirement is not > acceptable.) > > Upgrade procedure: > - stop OpenDNSSECv1 service > - stop DNSSECKeyImporterv1 service > - convert OpenDNSSECv1 database to OpenDNSSECv2 > This step is not related to Vault. We need to covert local SQLite > database from single-node OpenDNSSEC to LDAP-backed distributed > OpenDNSSEC. do we need to convert SQLite ? I thought in phase 1 we would have scripts exporting from OpenDNSSEC database and store in ldap, then the data already exist in ldap. We would ned to replace the sofhthsm module by our own pkcs11 module using ldap dn directly > > - convert private keys from LDAP to Vault *but let them in LDAP for a > while*. > - walk through cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example and check if > there are any other replicas with DNSSECKeyImporterv1 service: > a) No such replica exists -> delete old-fashioned keys from LDAP. > b) Another replica with DNSSECKeyImporterv1 service exists: > - *Temporarily* run DNSSECKeyImporterv2 which will do one-way key > conversion from Vault to LDAP. > - DNSSECKeyImporterv2 can check e.g. daily if all DNSSECKeyImporterv1 > instances were deleted or not. Then it can delete old-fashioned keys > from LDAP and also stop itself when all old replicas were deleted (and > compatibility mode is not needed anymore). > > This approach removes time constraints from upgrade procedure and > prevents DNS servers from failing when update is delayed etc. As a > result, admin can upgrade replica-by-replica at will. > From pviktori at redhat.com Wed Mar 12 11:17:37 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 12 Mar 2014 12:17:37 +0100 Subject: [Freeipa-devel] [PATCH] 0471 permission_add: Remove permission entry if adding the ACI fails In-Reply-To: <20140312092040.GB2735@redhat.com> References: <530762FE.7080703@redhat.com> <20140311140817.GB12206@redhat.com> <531F2731.6030303@redhat.com> <20140312092040.GB2735@redhat.com> Message-ID: <53204251.4090909@redhat.com> On 03/12/2014 10:20 AM, Jan Pazdziora wrote: > On Tue, Mar 11, 2014 at 04:09:37PM +0100, Petr Viktorin wrote: >> >> Unfortunately, yes, these operations are racy. When something fails, >> or when doing two operations simultaneously, it is possible that the >> objects are not both added. >> If that happens, it is the ACI that should be missing. The >> permission is added first, and the ACI is deleted first. This means >> that when things fail, access is denied, which is both more secure >> and easier to spot than having a stray ACI floating around. >> >> (In the long term, I'd really like to see a DS plugin for >> permission/ACI sync, so we can leverage transactions -- IPA is >> really the wrong layer to re-implement transactions in.) >> >> To answer your question, if the permission+ACI is already in LDAP, >> the call will fail with a DuplicateEntry error and post_callback >> won't get called. >> >> For the case that another permission_add command is called to add a >> permission of the same name, the existence of the permission entry >> acts as a "lock": while it's there, the other permission_add will >> fail, and removing it ("releasing the lock") is the last thing done >> in the error handler. >> >> I guess it would be good to add a comment saying this. > > Thank you for the explanation. > > In that case, ack on the patch, provided you add a nice comment. ;-) > Thanks, added comment and pushed to master: d3a34591a807f1420042ddbb53b3d5ac846927aa -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0471.2-permission_add-Remove-permission-entry-if-adding-the.patch Type: text/x-patch Size: 3603 bytes Desc: not available URL: From pviktori at redhat.com Wed Mar 12 11:20:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 12 Mar 2014 12:20:29 +0100 Subject: [Freeipa-devel] [PATCH] 0149: ipa-sam: ipa-sam: cache gid to sid and uid to sid requests in idmap cache In-Reply-To: <20140312100201.GC7893@localhost.localdomain> References: <20140311170942.GG16644@redhat.com> <20140311204851.GA7893@localhost.localdomain> <20140311210429.GI16644@redhat.com> <20140312100201.GC7893@localhost.localdomain> Message-ID: <532042FD.7090301@redhat.com> On 03/12/2014 11:02 AM, Sumit Bose wrote: > On Tue, Mar 11, 2014 at 11:04:29PM +0200, Alexander Bokovoy wrote: >> On Tue, 11 Mar 2014, Sumit Bose wrote: >>> On Tue, Mar 11, 2014 at 07:09:42PM +0200, Alexander Bokovoy wrote: >>>> Hi, >>>> >>>> >>>> Add idmap_cache calls to ipa-sam to prevent huge numbers of LDAP calls >>>> to the >>>> directory service for gid/uid<->sid resolution. >>>> >>>> Additionally, this patch further reduces number of queries by: >>>> - fast fail on uidNumber=0 which doesn't exist in FreeIPA, >>>> - return fallback group correctly when looking up user primary group as is >>>> done during init, >>>> - checking for group objectclass in case insensitive way >>>> >>>> Based on the patch by Jason Woods >>>> >>>> https://fedorahosted.org/freeipa/ticket/4234 >>>> and >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1073829 >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1074314 >>> >>> I didn't had a chance to run some test so far, but here are my comments >>> for the code. I will run some tests tomorrow. >> Fixed the code according to the comments. >> >> I've also changed the patch author to Jason as majority of the work was >> done by him, I only made it closer to what is expected in Samba and >> FreeIPA. > > Patch looks good and the basic functionality like adding a trust is > still working. > > ACK Pushed to: master: d6a7923f71eb69bac53d6ff904086a9abd103dbc ipa-3-3: 13cd4faf551d7781d27c36bef0e7cbf515e072d2 -- Petr? From mkosek at redhat.com Wed Mar 12 11:25:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 12 Mar 2014 12:25:13 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53203EBA.6060605@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> <53203EBA.6060605@redhat.! com> Message-ID: <53204419.7020106@redhat.com> On 03/12/2014 12:02 PM, Petr Viktorin wrote: > On 03/10/2014 08:55 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 02/27/2014 10:18 PM, Rob Crittenden wrote: >>>>> Rob Crittenden wrote: >>>>> Updated patch based on feedback from Foreman team. I added a new URI, >>>>> /features, which Foreman uses to determine what capabilities a proxy >>>>> has. >>>>> >>>>> rob >>>> >>>> On my VMs, where the first request is handled properly but the server >>>> hangs on the second one. I gave you access to the machines for >>>> investigation. >>> >>> Sent you something out-of-band but in short, I wasn't able to reproduce >>> on your reproducing VMs :-( Ping me tomorrow and we'll try it together. > > It ended up a combination of my mistake and a bug in GSSProxy. At least you > found the bug. https://fedorahosted.org/gss-proxy/ticket/121 > >>>> Please add the Python libraries (python-cherrypy, python-requests, >>>> python-kerberos) to BuildRequires. Otherwise the build fails due to >>>> pylint errors. >>> >>> Fixed. >>> >>>> >>>> In the man page: >>>> >>>>> +Create a host or user whose credentials will be used by the server to >>>>> make requests and add it to the role: >>>>> + >>>>> + $ ipa user\-add \-\-first=Smartproxy \-\-last=Serversmartproxy >>>>> + $ ipa role\-add\-member \-\-users=smartproxy 'Smartproxy management' >>>> >>>> the first command should be >>>> ipa user-add smartproxy --first=Smartproxy --last=Serversmartproxy >>>> since by default the username is 'sserversmartproxy'. >>> >>> The problem was a missing space before smartproxy. I have the login name >>> last in this example. Fixed. >>> >>>> >>>> A nitpick regarding the systemd service: according to [0], Type=forking >>>> should be avoided. Is there a reason against setting Type=simple, and >>>> removing the PID file? >>> >>> Because I wasn't able to get this working with cherrypy daemon mode. >>> AFAICT it forks itself and systemd wouldn't end up with the right pid so >>> can't stop the service. >> >> And now the updated patch. The changes are super-minor. >> >> rob >> > > One last nitpick: the IPAErrors get encoded as JSON but the Content-Encoding is > set to text/html. It's a one-line change so I went ahead and tested with it. > ACK from me if you agree. > > I spoke to Martin and he's still not satisfied with needing the COPR repo on > f20. I think we can live with it though. > Yes, he is not. I still think it is very inconvenient to unconditionally force everyone to import some COPR repo on all machines where he want to build and use FreeIPA even though they do not need freeipa-server-smartproxy at all. Here is an idea - add a conditional switch to freeipa.spec similar to CLIENT_ONLY which would control building the smartproxy and make it off by default. It would be only turned on for our F21 builds in the future. This is something I could live with. Martin From pspacek at redhat.com Wed Mar 12 12:09:32 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 12 Mar 2014 13:09:32 +0100 Subject: [Freeipa-devel] DNSSEC: upgrade path to Vault In-Reply-To: <53204109.4010804@redhat.com> References: <52FD02B7.3060404@redhat.com> <530CDF66.4000609@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> <531D98A8.8090207@redhat.com> <531D9D37.70201@redhat.com> <531EE667.5060700@redhat.com> <53204109.4010804@redhat.com> Message-ID: <53204E7C.1090601@redhat.com> On 12.3.2014 12:12, Ludwig Krispenz wrote: > On 03/11/2014 11:33 AM, Petr Spacek wrote: >> On 10.3.2014 12:08, Martin Kosek wrote: >>> On 03/10/2014 11:49 AM, Petr Spacek wrote: >>>> On 7.3.2014 17:33, Dmitri Pal wrote: >>>>> I do not think it is the right architectural approach to try to fix a >>>>> specific >>>>> use case with one off solution while we already know that we need a key >>>>> storage. >>>>> I would rather do things right and reusable than jam them into the currently >>>>> proposed release boundaries. >>>> I want to make clear that I'm not opposed to Vault in general. I'm >>>> questioning >>>> the necessity of Vault from the beginning because it will delay DNSSEC >>>> significantly. >>> >>> +1, I also now see number of scenarios where Vault will be needed. >>> >>>> >>>> One of the proposals in this thread is to use something simple for DNSSEC >>>> keys >>>> (with few lines of Python code) and migrate DNSSEC with Vault when Vault is >>>> available and stable enough (in some later release). >>>> >>>>> I understand that Vault brings a lot of work to the table. But let us do it >>>>> right and if it does not fit into 4.0 let us do it in 4.1. >>>> We will have one huge release with DNSSEC + Vault at once if we to postpone >>>> DNSSEC to the same release as Vault. >>>> >>>> As a result, it would be harder to debug it because we will have to find if >>>> something is broken because of: >>>> - DNSSEC-IPA integration >>>> - Vault-IPA integration >>>> - DNSSEC-Vault integration. >>>> >>>> I don't think it is a good idea to make such huge release. >>>> >>>> "Release early, release often" >>>> >>> >>> I must say I tend to agree with Petr. If the "poor man's solution" of DNSSEC >>> without Vault does not cost us too much time and it would seem that the Vault >>> is not going to squeeze in 4.0 deadlines, I would rather release the poor >>> man's >>> solution in 4.0 and switch to Vault when it's available in 4.1. >>> >>> This would let our users test the non-Vault parts of our DNSSEC solution >>> instead of waiting to test a perfect solution. >> >> Yesterday we have agreed that DNSSEC support is not going to depend on Vault >> from the beginning and that we can migrate to Vault later. >> >> Here I'm proposing safe upgrade path from non-vault to Vault solution. >> >> After all, it seems relatively easy. >> >> TL;DR version >> ============= >> Use information in cn=masters to detect if there are old replicas and >> temporarily convert new keys from Vault to LDAP storage (until all old >> replicas are deleted). >> >> Full version >> ============ >> IPA 4.0 is going to have OpenDNSSEC key generator on a single IPA server and >> separate key import/export daemon (i.e. script called from cron or something >> like that) on all IPA servers. >> >> In 4.0, we can add new LDAP objects for DNSSEC-related IPA services (please >> propose better names :-): >> - key generator: >> cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example >> >> - key imported/exporter: >> cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example >> >> >> >> Initial state before upgrade: >> - N IPA 4.0 replicas >> - N DNSSECKeyImporterv1 service instances (i.e. key distribution for IPA 4.0) >> - 1 OpenDNSSECv1 service instance (key generator) >> >> Now we want to upgrade a first replica to IPA 4.1. For simplicity, let's add >> a *requirement* to upgrade the replica with OpenDNSSECv1 first. (We can >> generalize the procedure if this requirement is not acceptable.) >> >> Upgrade procedure: >> - stop OpenDNSSECv1 service >> - stop DNSSECKeyImporterv1 service >> - convert OpenDNSSECv1 database to OpenDNSSECv2 >> This step is not related to Vault. We need to covert local SQLite database >> from single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC. > do we need to convert SQLite ? I thought in phase 1 we would have scripts > exporting from OpenDNSSEC database and store in ldap, then the data already > exist in ldap. We would ned to replace the sofhthsm module by our own pkcs11 > module using ldap dn directly I'm sorry for not being clear. The short-term plain is going to be executed without significant changes: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm This discussion is more about potential problems with upgrade from short-term solution to the long-term one - I'm updating https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm right now. To answer your question about SQLite database: We will have *encryption keys* in LDAP already from the very beginning (exported to LDAP by a script) so upgrade from export script to PKCS#11 module should be be smooth. The problem is with various metadata stored in OpenDNSSEC's database so we will have to convert them to LDAP. In short-term we have neither intent nor time to design a LDAP schema for OpenDNSSEC database, just for the keys. Does it clear the confusion? -- Petr^2 Spacek From lkrispen at redhat.com Wed Mar 12 13:07:02 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 12 Mar 2014 14:07:02 +0100 Subject: [Freeipa-devel] DNSSEC: upgrade path to Vault In-Reply-To: <53204E7C.1090601@redhat.com> References: <52FD02B7.3060404@redhat.com> <1393356125.18299.67.camel@willson.li.ssimo.org> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> <531D98A8.8090207@redhat.com> <531D9D37.70201@redhat.com> <531EE667.5060700@redhat.com> <53204109.4010804@redhat.com> <53204E7C.1090601@redhat.com> Message-ID: <53205BF6.30309@redhat.com> On 03/12/2014 01:09 PM, Petr Spacek wrote: > On 12.3.2014 12:12, Ludwig Krispenz wrote: >> On 03/11/2014 11:33 AM, Petr Spacek wrote: >>> On 10.3.2014 12:08, Martin Kosek wrote: >>>> On 03/10/2014 11:49 AM, Petr Spacek wrote: >>>>> On 7.3.2014 17:33, Dmitri Pal wrote: >>>>>> I do not think it is the right architectural approach to try to >>>>>> fix a >>>>>> specific >>>>>> use case with one off solution while we already know that we need >>>>>> a key >>>>>> storage. >>>>>> I would rather do things right and reusable than jam them into >>>>>> the currently >>>>>> proposed release boundaries. >>>>> I want to make clear that I'm not opposed to Vault in general. I'm >>>>> questioning >>>>> the necessity of Vault from the beginning because it will delay >>>>> DNSSEC >>>>> significantly. >>>> >>>> +1, I also now see number of scenarios where Vault will be needed. >>>> >>>>> >>>>> One of the proposals in this thread is to use something simple for >>>>> DNSSEC >>>>> keys >>>>> (with few lines of Python code) and migrate DNSSEC with Vault when >>>>> Vault is >>>>> available and stable enough (in some later release). >>>>> >>>>>> I understand that Vault brings a lot of work to the table. But >>>>>> let us do it >>>>>> right and if it does not fit into 4.0 let us do it in 4.1. >>>>> We will have one huge release with DNSSEC + Vault at once if we to >>>>> postpone >>>>> DNSSEC to the same release as Vault. >>>>> >>>>> As a result, it would be harder to debug it because we will have >>>>> to find if >>>>> something is broken because of: >>>>> - DNSSEC-IPA integration >>>>> - Vault-IPA integration >>>>> - DNSSEC-Vault integration. >>>>> >>>>> I don't think it is a good idea to make such huge release. >>>>> >>>>> "Release early, release often" >>>>> >>>> >>>> I must say I tend to agree with Petr. If the "poor man's solution" >>>> of DNSSEC >>>> without Vault does not cost us too much time and it would seem that >>>> the Vault >>>> is not going to squeeze in 4.0 deadlines, I would rather release >>>> the poor >>>> man's >>>> solution in 4.0 and switch to Vault when it's available in 4.1. >>>> >>>> This would let our users test the non-Vault parts of our DNSSEC >>>> solution >>>> instead of waiting to test a perfect solution. >>> >>> Yesterday we have agreed that DNSSEC support is not going to depend >>> on Vault >>> from the beginning and that we can migrate to Vault later. >>> >>> Here I'm proposing safe upgrade path from non-vault to Vault solution. >>> >>> After all, it seems relatively easy. >>> >>> TL;DR version >>> ============= >>> Use information in cn=masters to detect if there are old replicas and >>> temporarily convert new keys from Vault to LDAP storage (until all old >>> replicas are deleted). >>> >>> Full version >>> ============ >>> IPA 4.0 is going to have OpenDNSSEC key generator on a single IPA >>> server and >>> separate key import/export daemon (i.e. script called from cron or >>> something >>> like that) on all IPA servers. >>> >>> In 4.0, we can add new LDAP objects for DNSSEC-related IPA services >>> (please >>> propose better names :-): >>> - key generator: >>> cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example >>> >>> >>> - key imported/exporter: >>> cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example >>> >>> >>> >>> >>> Initial state before upgrade: >>> - N IPA 4.0 replicas >>> - N DNSSECKeyImporterv1 service instances (i.e. key distribution for >>> IPA 4.0) >>> - 1 OpenDNSSECv1 service instance (key generator) >>> >>> Now we want to upgrade a first replica to IPA 4.1. For simplicity, >>> let's add >>> a *requirement* to upgrade the replica with OpenDNSSECv1 first. (We can >>> generalize the procedure if this requirement is not acceptable.) >>> >>> Upgrade procedure: >>> - stop OpenDNSSECv1 service >>> - stop DNSSECKeyImporterv1 service >>> - convert OpenDNSSECv1 database to OpenDNSSECv2 >>> This step is not related to Vault. We need to covert local SQLite >>> database >>> from single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC. >> do we need to convert SQLite ? I thought in phase 1 we would have >> scripts >> exporting from OpenDNSSEC database and store in ldap, then the data >> already >> exist in ldap. We would ned to replace the sofhthsm module by our own >> pkcs11 >> module using ldap dn directly > > I'm sorry for not being clear. > > The short-term plain is going to be executed without significant changes: > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm > > > This discussion is more about potential problems with upgrade from > short-term solution to the long-term one - I'm updating > https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm > > right now. > > To answer your question about SQLite database: > We will have *encryption keys* in LDAP already from the very beginning > (exported to LDAP by a script) so upgrade from export script to > PKCS#11 module should be be smooth. > > The problem is with various metadata stored in OpenDNSSEC's database > so we will have to convert them to LDAP. In short-term we have neither > intent nor time to design a LDAP schema for OpenDNSSEC database, just > for the keys. the schema proposal contains attributes for the metadata, so this should be ok. But I think right now the export function available in opendnsssec/softhsm only exports keys. We would have to have sql scripts to read and convert the sqlite3 database > > Does it clear the confusion? > From pvoborni at redhat.com Wed Mar 12 14:41:31 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 12 Mar 2014 15:41:31 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <5319FD75.2010108@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> <530F3106.7090505@redhat.com> <1393516297.3562.8.camel@localhost.localdomain> <530F6804.3090507@redhat.com> <5319FD75.2010108@redhat.com> Message-ID: <5320721B.5070306@redhat.com> On 7.3.2014 18:10, Petr Vobornik wrote: > Attaching new version of 537 which adds combobox control for owner > attribute instead of textbox. > > All other patches are attached as well to reduce confusion in case of > ACK :). > > The entire patchset was rebased. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0531-3-Added-empty-value-meaning-to-boolean-formatter.patch Type: text/x-patch Size: 2787 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0532-2-Declarative-replacement-of-array-item-in-specificati.patch Type: text/x-patch Size: 3635 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0533-2-Fixed-doc-examples-in-Spec_mod.patch Type: text/x-patch Size: 1310 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0534-2-Password-Dialog.patch Type: text/x-patch Size: 11243 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0535-2-Use-general-password-dialog-for-host-OTP.patch Type: text/x-patch Size: 6300 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0536-2-Fix-handling-of-action-visibility-change-in-action-p.patch Type: text/x-patch Size: 1525 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0537-7-UI-for-OTP-tokens.patch Type: text/x-patch Size: 16490 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0538-2-UI-for-radius-proxy.patch Type: text/x-patch Size: 7697 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0539-2-UI-for-managing-user-auth-types.patch Type: text/x-patch Size: 2002 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0540-3-Added-QRcode-generation-to-Web-UI.patch Type: text/x-patch Size: 33171 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0541-3-Support-OTP-in-form-based-auth.patch Type: text/x-patch Size: 3617 bytes Desc: not available URL: From swalter at redhat.com Wed Mar 12 15:14:01 2014 From: swalter at redhat.com (Stef Walter) Date: Wed, 12 Mar 2014 16:14:01 +0100 Subject: [Freeipa-devel] LDAP schema for PKCS#11 In-Reply-To: <531758B4.8050004@redhat.com> References: <53146CC4.8010200@redhat.com> <53147A50.3070901@redhat.com> <531483F1.6070005@redhat.com> <53148911.4090606@redhat.com> <53148B97.4020900@redhat.com> <53148CA5.2040009@redhat.com> <5314909E.9030502@redhat.com> <531716A4.6060600@redhat.com> <531758B4.8050004@redhat.com> Message-ID: <532079B9.80907@redhat.com> On 05.03.2014 18:02, Jan Cholasta wrote: > On 5.3.2014 13:20, Stef Walter wrote: >> On 03.03.2014 15:24, Jan Cholasta wrote: >>> On 3.3.2014 15:07, Stef Walter wrote: >>>> On 03.03.2014 15:03, Jan Cholasta wrote: >>>>> If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust >>>>> objects from the module? >>>> >>>> No. This is the spec for storing trust policy in PKCS#11 that we've >>>> been >>>> working on: >>>> >>>> http://p11-glue.freedesktop.org/doc/storing-trust-policy/ >>>> >>>> It's a far more extensible and future proof model. The p11-kit-trust >>>> module stores/loads these sorts of objects, and additionally also >>>> generates NSS trust objects on the fly so that NSS can consume the >>>> information. >>>> >>>> It doesn't do that last bit for third party sources, but it could given >>>> code :) >>> >>> Code is not a problem :) >>> >>> What would be the best way to provide trust policy to p11-kit from a >>> third party PKCS#11 module, if not NSS trust objects? >> >> I obviously think that using the new stuff linked above would be best. >> It's future proof and models this comprehensively. That would allow >> extracting compat trust anchors to files (for crypto libraries that >> don't yet support looking it up trust via PKCS#11). >> >> But I understand if you're hesitant to commit to this spec that's in >> development (albeit already implemented). > > Actually, I like it. Is everything mentioned at > > going to be standardized? Yes, that's the goal. Several people have been involved in reviewing the spec, and I'm going through a second batch of reviews from the NSS guys. Stef From pspacek at redhat.com Wed Mar 12 15:28:15 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 12 Mar 2014 16:28:15 +0100 Subject: [Freeipa-devel] DNSSEC: upgrade path to Vault In-Reply-To: <53205BF6.30309@redhat.com> References: <52FD02B7.3060404@redhat.com> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> <531D98A8.8090207@redhat.com> <531D9D37.70201@redhat.com> <531EE667.5060700@redhat.com> <53204109.4010804@redhat.com> <53204E7C.1090601@redhat.com> <53205BF6.30309@redhat.com> Message-ID: <53207D0F.7020403@redhat.com> On 12.3.2014 14:07, Ludwig Krispenz wrote: > > On 03/12/2014 01:09 PM, Petr Spacek wrote: >> On 12.3.2014 12:12, Ludwig Krispenz wrote: >>> On 03/11/2014 11:33 AM, Petr Spacek wrote: >>>> On 10.3.2014 12:08, Martin Kosek wrote: >>>>> On 03/10/2014 11:49 AM, Petr Spacek wrote: >>>>>> On 7.3.2014 17:33, Dmitri Pal wrote: >>>>>>> I do not think it is the right architectural approach to try to fix a >>>>>>> specific >>>>>>> use case with one off solution while we already know that we need a key >>>>>>> storage. >>>>>>> I would rather do things right and reusable than jam them into the >>>>>>> currently >>>>>>> proposed release boundaries. >>>>>> I want to make clear that I'm not opposed to Vault in general. I'm >>>>>> questioning >>>>>> the necessity of Vault from the beginning because it will delay DNSSEC >>>>>> significantly. >>>>> >>>>> +1, I also now see number of scenarios where Vault will be needed. >>>>> >>>>>> >>>>>> One of the proposals in this thread is to use something simple for DNSSEC >>>>>> keys >>>>>> (with few lines of Python code) and migrate DNSSEC with Vault when Vault is >>>>>> available and stable enough (in some later release). >>>>>> >>>>>>> I understand that Vault brings a lot of work to the table. But let us >>>>>>> do it >>>>>>> right and if it does not fit into 4.0 let us do it in 4.1. >>>>>> We will have one huge release with DNSSEC + Vault at once if we to postpone >>>>>> DNSSEC to the same release as Vault. >>>>>> >>>>>> As a result, it would be harder to debug it because we will have to find if >>>>>> something is broken because of: >>>>>> - DNSSEC-IPA integration >>>>>> - Vault-IPA integration >>>>>> - DNSSEC-Vault integration. >>>>>> >>>>>> I don't think it is a good idea to make such huge release. >>>>>> >>>>>> "Release early, release often" >>>>>> >>>>> >>>>> I must say I tend to agree with Petr. If the "poor man's solution" of DNSSEC >>>>> without Vault does not cost us too much time and it would seem that the >>>>> Vault >>>>> is not going to squeeze in 4.0 deadlines, I would rather release the poor >>>>> man's >>>>> solution in 4.0 and switch to Vault when it's available in 4.1. >>>>> >>>>> This would let our users test the non-Vault parts of our DNSSEC solution >>>>> instead of waiting to test a perfect solution. >>>> >>>> Yesterday we have agreed that DNSSEC support is not going to depend on Vault >>>> from the beginning and that we can migrate to Vault later. >>>> >>>> Here I'm proposing safe upgrade path from non-vault to Vault solution. >>>> >>>> After all, it seems relatively easy. >>>> >>>> TL;DR version >>>> ============= >>>> Use information in cn=masters to detect if there are old replicas and >>>> temporarily convert new keys from Vault to LDAP storage (until all old >>>> replicas are deleted). >>>> >>>> Full version >>>> ============ >>>> IPA 4.0 is going to have OpenDNSSEC key generator on a single IPA server and >>>> separate key import/export daemon (i.e. script called from cron or something >>>> like that) on all IPA servers. >>>> >>>> In 4.0, we can add new LDAP objects for DNSSEC-related IPA services (please >>>> propose better names :-): >>>> - key generator: >>>> cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example >>>> >>>> - key imported/exporter: >>>> cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example >>>> >>>> >>>> >>>> >>>> Initial state before upgrade: >>>> - N IPA 4.0 replicas >>>> - N DNSSECKeyImporterv1 service instances (i.e. key distribution for IPA 4.0) >>>> - 1 OpenDNSSECv1 service instance (key generator) >>>> >>>> Now we want to upgrade a first replica to IPA 4.1. For simplicity, let's add >>>> a *requirement* to upgrade the replica with OpenDNSSECv1 first. (We can >>>> generalize the procedure if this requirement is not acceptable.) >>>> >>>> Upgrade procedure: >>>> - stop OpenDNSSECv1 service >>>> - stop DNSSECKeyImporterv1 service >>>> - convert OpenDNSSECv1 database to OpenDNSSECv2 >>>> This step is not related to Vault. We need to covert local SQLite database >>>> from single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC. >>> do we need to convert SQLite ? I thought in phase 1 we would have scripts >>> exporting from OpenDNSSEC database and store in ldap, then the data already >>> exist in ldap. We would ned to replace the sofhthsm module by our own pkcs11 >>> module using ldap dn directly >> >> I'm sorry for not being clear. >> >> The short-term plain is going to be executed without significant changes: >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm >> >> >> This discussion is more about potential problems with upgrade from >> short-term solution to the long-term one - I'm updating >> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm >> right now. >> >> To answer your question about SQLite database: >> We will have *encryption keys* in LDAP already from the very beginning >> (exported to LDAP by a script) so upgrade from export script to PKCS#11 >> module should be be smooth. >> >> The problem is with various metadata stored in OpenDNSSEC's database so we >> will have to convert them to LDAP. In short-term we have neither intent nor >> time to design a LDAP schema for OpenDNSSEC database, just for the keys. > the schema proposal contains attributes for the metadata, so this should be The current schema stores only PKCS#11 metadata but nothing about key&signing policy and other DNSSEC-related stuff. We don't have complete schema and we don't have to have it now. Look at the SQLite database in opendnssecv143.sqlite3.bz2 - it is pretty complex. We don't have time to prepare schema & port OpenDNSSECv1 to LDAP backend. (Other aspect is that the schema is different for OpenDNSSEC v2.) > ok. But I think right now the export function available in opendnsssec/softhsm > only exports keys. We would have to have sql scripts to read and convert the > sqlite3 database Yes, we will have to have such script for upgrades from short-term -> long-term solution. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: opendnssecv143.sqlite3.bz2 Type: application/x-bzip Size: 19530 bytes Desc: not available URL: From jcholast at redhat.com Wed Mar 12 15:31:57 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 12 Mar 2014 16:31:57 +0100 Subject: [Freeipa-devel] LDAP schema for PKCS#11 In-Reply-To: <532079B9.80907@redhat.com> References: <53146CC4.8010200@redhat.com> <53147A50.3070901@redhat.com> <531483F1.6070005@redhat.com> <53148911.4090606@redhat.com> <53148B97.4020900@redhat.com> <53148CA5.2040009@redhat.com> <5314909E.9030502@redhat.com> <531716A4.6060600@redhat.com> <531758B4.8050004@redhat.com> <532079B9.80907@redhat.com> Message-ID: <53207DED.3030001@redhat.com> On 12.3.2014 16:14, Stef Walter wrote: > On 05.03.2014 18:02, Jan Cholasta wrote: >> On 5.3.2014 13:20, Stef Walter wrote: >>> On 03.03.2014 15:24, Jan Cholasta wrote: >>>> On 3.3.2014 15:07, Stef Walter wrote: >>>>> On 03.03.2014 15:03, Jan Cholasta wrote: >>>>>> If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS trust >>>>>> objects from the module? >>>>> >>>>> No. This is the spec for storing trust policy in PKCS#11 that we've >>>>> been >>>>> working on: >>>>> >>>>> http://p11-glue.freedesktop.org/doc/storing-trust-policy/ >>>>> >>>>> It's a far more extensible and future proof model. The p11-kit-trust >>>>> module stores/loads these sorts of objects, and additionally also >>>>> generates NSS trust objects on the fly so that NSS can consume the >>>>> information. >>>>> >>>>> It doesn't do that last bit for third party sources, but it could given >>>>> code :) >>>> >>>> Code is not a problem :) >>>> >>>> What would be the best way to provide trust policy to p11-kit from a >>>> third party PKCS#11 module, if not NSS trust objects? >>> >>> I obviously think that using the new stuff linked above would be best. >>> It's future proof and models this comprehensively. That would allow >>> extracting compat trust anchors to files (for crypto libraries that >>> don't yet support looking it up trust via PKCS#11). >>> >>> But I understand if you're hesitant to commit to this spec that's in >>> development (albeit already implemented). >> >> Actually, I like it. Is everything mentioned at >> >> going to be standardized? > > Yes, that's the goal. Several people have been involved in reviewing the > spec, and I'm going through a second batch of reviews from the NSS guys. Great! Do you expect any big changes to happen during the review, or can the spec be considered stable enough to base an LDAP schema on it? Honza -- Jan Cholasta From lkrispen at redhat.com Wed Mar 12 15:54:29 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 12 Mar 2014 16:54:29 +0100 Subject: [Freeipa-devel] DNSSEC: upgrade path to Vault In-Reply-To: <53207D0F.7020403@redhat.com> References: <52FD02B7.3060404@redhat.com> <530DF46F.5090409@redhat.com> <1393426820.18299.163.camel@willson.li.ssimo.org> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> <531D98A8.8090207@redhat.com> <531D9D37.70201@redhat.com> <531EE667.5060700@redhat.com> <53204109.4010804@redhat.com> <53204E7C.1090601@redhat.com> <53205BF6.30309@redhat.com> <53207D0F.7020403@red! hat.com> Message-ID: <53208335.9000507@redhat.com> On 03/12/2014 04:28 PM, Petr Spacek wrote: > On 12.3.2014 14:07, Ludwig Krispenz wrote: >> >> On 03/12/2014 01:09 PM, Petr Spacek wrote: >>> On 12.3.2014 12:12, Ludwig Krispenz wrote: >>>> On 03/11/2014 11:33 AM, Petr Spacek wrote: >>>>> On 10.3.2014 12:08, Martin Kosek wrote: >>>>>> On 03/10/2014 11:49 AM, Petr Spacek wrote: >>>>>>> On 7.3.2014 17:33, Dmitri Pal wrote: >>>>>>>> I do not think it is the right architectural approach to try to >>>>>>>> fix a >>>>>>>> specific >>>>>>>> use case with one off solution while we already know that we >>>>>>>> need a key >>>>>>>> storage. >>>>>>>> I would rather do things right and reusable than jam them into the >>>>>>>> currently >>>>>>>> proposed release boundaries. >>>>>>> I want to make clear that I'm not opposed to Vault in general. I'm >>>>>>> questioning >>>>>>> the necessity of Vault from the beginning because it will delay >>>>>>> DNSSEC >>>>>>> significantly. >>>>>> >>>>>> +1, I also now see number of scenarios where Vault will be needed. >>>>>> >>>>>>> >>>>>>> One of the proposals in this thread is to use something simple >>>>>>> for DNSSEC >>>>>>> keys >>>>>>> (with few lines of Python code) and migrate DNSSEC with Vault >>>>>>> when Vault is >>>>>>> available and stable enough (in some later release). >>>>>>> >>>>>>>> I understand that Vault brings a lot of work to the table. But >>>>>>>> let us >>>>>>>> do it >>>>>>>> right and if it does not fit into 4.0 let us do it in 4.1. >>>>>>> We will have one huge release with DNSSEC + Vault at once if we >>>>>>> to postpone >>>>>>> DNSSEC to the same release as Vault. >>>>>>> >>>>>>> As a result, it would be harder to debug it because we will have >>>>>>> to find if >>>>>>> something is broken because of: >>>>>>> - DNSSEC-IPA integration >>>>>>> - Vault-IPA integration >>>>>>> - DNSSEC-Vault integration. >>>>>>> >>>>>>> I don't think it is a good idea to make such huge release. >>>>>>> >>>>>>> "Release early, release often" >>>>>>> >>>>>> >>>>>> I must say I tend to agree with Petr. If the "poor man's >>>>>> solution" of DNSSEC >>>>>> without Vault does not cost us too much time and it would seem >>>>>> that the >>>>>> Vault >>>>>> is not going to squeeze in 4.0 deadlines, I would rather release >>>>>> the poor >>>>>> man's >>>>>> solution in 4.0 and switch to Vault when it's available in 4.1. >>>>>> >>>>>> This would let our users test the non-Vault parts of our DNSSEC >>>>>> solution >>>>>> instead of waiting to test a perfect solution. >>>>> >>>>> Yesterday we have agreed that DNSSEC support is not going to >>>>> depend on Vault >>>>> from the beginning and that we can migrate to Vault later. >>>>> >>>>> Here I'm proposing safe upgrade path from non-vault to Vault >>>>> solution. >>>>> >>>>> After all, it seems relatively easy. >>>>> >>>>> TL;DR version >>>>> ============= >>>>> Use information in cn=masters to detect if there are old replicas and >>>>> temporarily convert new keys from Vault to LDAP storage (until all >>>>> old >>>>> replicas are deleted). >>>>> >>>>> Full version >>>>> ============ >>>>> IPA 4.0 is going to have OpenDNSSEC key generator on a single IPA >>>>> server and >>>>> separate key import/export daemon (i.e. script called from cron or >>>>> something >>>>> like that) on all IPA servers. >>>>> >>>>> In 4.0, we can add new LDAP objects for DNSSEC-related IPA >>>>> services (please >>>>> propose better names :-): >>>>> - key generator: >>>>> cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example >>>>> >>>>> >>>>> - key imported/exporter: >>>>> cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Initial state before upgrade: >>>>> - N IPA 4.0 replicas >>>>> - N DNSSECKeyImporterv1 service instances (i.e. key distribution >>>>> for IPA 4.0) >>>>> - 1 OpenDNSSECv1 service instance (key generator) >>>>> >>>>> Now we want to upgrade a first replica to IPA 4.1. For simplicity, >>>>> let's add >>>>> a *requirement* to upgrade the replica with OpenDNSSECv1 first. >>>>> (We can >>>>> generalize the procedure if this requirement is not acceptable.) >>>>> >>>>> Upgrade procedure: >>>>> - stop OpenDNSSECv1 service >>>>> - stop DNSSECKeyImporterv1 service >>>>> - convert OpenDNSSECv1 database to OpenDNSSECv2 >>>>> This step is not related to Vault. We need to covert local SQLite >>>>> database >>>>> from single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC. >>>> do we need to convert SQLite ? I thought in phase 1 we would have >>>> scripts >>>> exporting from OpenDNSSEC database and store in ldap, then the data >>>> already >>>> exist in ldap. We would ned to replace the sofhthsm module by our >>>> own pkcs11 >>>> module using ldap dn directly >>> >>> I'm sorry for not being clear. >>> >>> The short-term plain is going to be executed without significant >>> changes: >>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm >>> >>> >>> >>> This discussion is more about potential problems with upgrade from >>> short-term solution to the long-term one - I'm updating >>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm >>> >>> right now. >>> >>> To answer your question about SQLite database: >>> We will have *encryption keys* in LDAP already from the very beginning >>> (exported to LDAP by a script) so upgrade from export script to PKCS#11 >>> module should be be smooth. >>> >>> The problem is with various metadata stored in OpenDNSSEC's database >>> so we >>> will have to convert them to LDAP. In short-term we have neither >>> intent nor >>> time to design a LDAP schema for OpenDNSSEC database, just for the >>> keys. >> the schema proposal contains attributes for the metadata, so this >> should be > The current schema stores only PKCS#11 metadata but nothing about > key&signing policy and other DNSSEC-related stuff. > > We don't have complete schema and we don't have to have it now. Look > at the SQLite database in opendnssecv143.sqlite3.bz2 - it is pretty > complex. ok, so this is not the softhsm pkcs11 sqlite database, but a db containing other dnssec data, you didn't say that we need ldap schema for this and for which subset of it > > We don't have time to prepare schema & port OpenDNSSECv1 to LDAP > backend. (Other aspect is that the schema is different for OpenDNSSEC > v2.) > >> ok. But I think right now the export function available in >> opendnsssec/softhsm >> only exports keys. We would have to have sql scripts to read and >> convert the >> sqlite3 database > > Yes, we will have to have such script for upgrades from short-term -> > long-term solution. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Mar 12 15:56:50 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 12 Mar 2014 17:56:50 +0200 Subject: [Freeipa-devel] [PATCH] 0150: make sure SID is always returned as unicode from dcerpc.py Message-ID: <20140312155650.GJ16644@redhat.com> Hi, Trusted domain SID could be obtained through different means. When it is fetched from the AD DC via LDAP, it needs to be extracted from a default context and explicitly converted to unicode. https://fedorahosted.org/freeipa/ticket/4246 -- / Alexander Bokovoy -------------- next part -------------- >From 8fa83d284052de5e4bc66efbfe6096b5c5b00ccc Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 12 Mar 2014 17:51:43 +0200 Subject: [PATCH 2/2] ipaserver/dcerpc: make sure to always return unicode SID of the trust domain Trusted domain SID could be obtained through different means. When it is fetched from the AD DC via LDAP, it needs to be extracted from a default context and explicitly converted to unicode. https://fedorahosted.org/freeipa/ticket/4246 --- ipaserver/dcerpc.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 9e03b34..3b89adc 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -750,7 +750,7 @@ class TrustDomainInstance(object): def parse_naming_context(self, context): naming_ref = re.compile('.*.*') - return naming_ref.match(context).group(1) + return unicode(naming_ref.match(context).group(1)) def retrieve(self, remote_host): self.init_lsa_pipe(remote_host) -- 1.8.3.1 From amisnyov at redhat.com Wed Mar 12 16:23:54 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Wed, 12 Mar 2014 17:23:54 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <5320721B.5070306@redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> <530F3106.7090505@redhat.com> <1393516297.3562.8.camel@localhost.localdomain> <530F6804.3090507@redhat.com> <5319FD75.2010108@redhat.com> <5320721B.5070306@redhat.com> Message-ID: <20140312172354.09480e2f@unused-4-246.brq.redhat.com> On Wed, 12 Mar 2014 15:41:31 +0100 Petr Vobornik wrote: > On 7.3.2014 18:10, Petr Vobornik wrote: > > Attaching new version of 537 which adds combobox control for owner > > attribute instead of textbox. > > > > All other patches are attached as well to reduce confusion in case > > of ACK :). > > > > > > The entire patchset was rebased. Review log: - add otp token: OK - delete otp token: OK - bulk delete: OK - edit otp token: OK - single disable token: OK - single enable token: OK - bulk enable token: OK - bulk disable token: OK - configuration url working: OK - after bulk operation, checkboxes for items unchecked, which is good, but the bulk check checkbox remains checked, propose: either all checkboxes should remain checked, or all of them unchecked - https://fedorahosted.org/freeipa/ticket/4245 - validity fields accept non existing timeframe(ie start: 2013-01-01 00:00:00Z, end: 2012-01-01 00:00:00Z) - https://fedorahosted.org/freeipa/ticket/4244 - after edit, screen doesn't go back to list, any other action errors with a "[UUID]: OTP token not found" because of uniqueid change - https://fedorahosted.org/freeipa/ticket/4227 all the opened tickets are not the scope of this patch, so ACK greets Adam From pviktori at redhat.com Wed Mar 12 16:31:01 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 12 Mar 2014 17:31:01 +0100 Subject: [Freeipa-devel] [PATCH] 531-541 OTP UI In-Reply-To: <20140312172354.09480e2f@unused-4-246.brq.redhat.com> References: <52D40FD7.5090301@redhat.com> <52F8D034.2040009@redhat.com> <53076180.7020103@redhat.com> <530F3106.7090505@redhat.com> <1393516297.3562.8.camel@localhost.localdomain> <530F6804.3090507@redhat.com> <5319FD75.2010108@redhat.com> <5320721B.5070306@redhat.com> <20140312172354.09480e2f@unused-4-246.brq.redhat.com> Message-ID: <53208BC5.8070506@redhat.com> On 03/12/2014 05:23 PM, Misnyovszki Adam wrote: > On Wed, 12 Mar 2014 15:41:31 +0100 > Petr Vobornik wrote: > >> On 7.3.2014 18:10, Petr Vobornik wrote: >>> Attaching new version of 537 which adds combobox control for owner >>> attribute instead of textbox. >>> >>> All other patches are attached as well to reduce confusion in case >>> of ACK :). >>> >>> >> >> The entire patchset was rebased. > > > Review log: > - add otp token: OK > - delete otp token: OK > - bulk delete: OK > - edit otp token: OK > - single disable token: OK > - single enable token: OK > - bulk enable token: OK > - bulk disable token: OK > - configuration url working: OK > - after bulk operation, checkboxes for items unchecked, which is good, > but the bulk check checkbox remains checked, propose: either all > checkboxes should remain checked, or all of them unchecked - > https://fedorahosted.org/freeipa/ticket/4245 > - validity fields accept non existing timeframe(ie start: 2013-01-01 > 00:00:00Z, end: 2012-01-01 00:00:00Z) - > https://fedorahosted.org/freeipa/ticket/4244 > - after edit, screen doesn't go back to list, any other action errors > with a "[UUID]: OTP token not found" because of uniqueid change - > https://fedorahosted.org/freeipa/ticket/4227 > > all the opened tickets are not the scope of this patch, so > ACK Pushed to master: 723166aebeacc17f87b3b274c0f9ae0b58bf8a74 -- Petr? From mkosek at redhat.com Wed Mar 12 16:42:13 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 12 Mar 2014 17:42:13 +0100 Subject: [Freeipa-devel] [PATCH] 0150: make sure SID is always returned as unicode from dcerpc.py In-Reply-To: <20140312155650.GJ16644@redhat.com> References: <20140312155650.GJ16644@redhat.com> Message-ID: <53208E65.2060807@redhat.com> On 03/12/2014 04:56 PM, Alexander Bokovoy wrote: > Hi, > > Trusted domain SID could be obtained through different means. When it is > fetched from the AD DC via LDAP, it needs to be extracted from a default > context and explicitly converted to unicode. > > https://fedorahosted.org/freeipa/ticket/4246 This only works for ADs without subdomains. When there are subdomains, AD does not allow us to retrieve them and command fails right after creating the truyst trust object: # echo Secret123 | ipa trust-add tbad.example.com --trust-secretipa: ERROR: AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides, for example # ipa trust-fetch-domains tbad.example.com ipa: ERROR: AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides, for example When I refreshed FreeIPA domains on AD said, it started working again: # ipa trust-fetch-domains tbad.example.com -------------------------------------------- List of trust domains successfully refreshed -------------------------------------------- Realm name: child.tbad.example.com Domain NetBIOS name: CHILD Domain Security Identifier: S-1-5-21-972585150-1048339146-1910910075 ---------------------------- Number of entries returned 1 ---------------------------- Martin From amisnyov at redhat.com Wed Mar 12 16:51:03 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Wed, 12 Mar 2014 17:51:03 +0100 Subject: [Freeipa-devel] [PATCH] 549 webui: use unique ids for checkboxes In-Reply-To: <530CCEF4.4060905@redhat.com> References: <530CCEF4.4060905@redhat.com> Message-ID: <20140312175103.6273a630@unused-4-246.brq.redhat.com> On Tue, 25 Feb 2014 18:12:20 +0100 Petr Vobornik wrote: > This is a minor fix. Please don't close ticket 3904 yet if committed. > > Checkboxes have not used unique ids across the whole UI. It broke > checking by clicking on label for later displayed instances. It > became serious problem when rcue introduced new checkbox styles with > 'label clicking' as default check method. > > https://fedorahosted.org/freeipa/ticket/3904 ACK From pspacek at redhat.com Wed Mar 12 17:08:18 2014 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 12 Mar 2014 18:08:18 +0100 Subject: [Freeipa-devel] DNSSEC: LDAP schema requirements In-Reply-To: <53208335.9000507@redhat.com> References: <52FD02B7.3060404@redhat.com> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> <531D98A8.8090207@redhat.com> <531D9D37.70201@redhat.com> <531EE667.5060700@redhat.com> <53204109.4010804@redhat.com> <53204E7C.1090601@redhat.com> <53205BF6.30309@redhat.com> <53207D0F.7020403@red! hat.com> <53208335.9000507@redhat.com> Message-ID: <53209482.9060201@redhat.com> On 12.3.2014 16:54, Ludwig Krispenz wrote: > > On 03/12/2014 04:28 PM, Petr Spacek wrote: >> On 12.3.2014 14:07, Ludwig Krispenz wrote: >>> >>> On 03/12/2014 01:09 PM, Petr Spacek wrote: >>>> On 12.3.2014 12:12, Ludwig Krispenz wrote: >>>>> On 03/11/2014 11:33 AM, Petr Spacek wrote: >>>>>> On 10.3.2014 12:08, Martin Kosek wrote: >>>>>>> On 03/10/2014 11:49 AM, Petr Spacek wrote: >>>>>>>> On 7.3.2014 17:33, Dmitri Pal wrote: >>>>>>>>> I do not think it is the right architectural approach to try to fix a >>>>>>>>> specific >>>>>>>>> use case with one off solution while we already know that we need a key >>>>>>>>> storage. >>>>>>>>> I would rather do things right and reusable than jam them into the >>>>>>>>> currently >>>>>>>>> proposed release boundaries. >>>>>>>> I want to make clear that I'm not opposed to Vault in general. I'm >>>>>>>> questioning >>>>>>>> the necessity of Vault from the beginning because it will delay DNSSEC >>>>>>>> significantly. >>>>>>> >>>>>>> +1, I also now see number of scenarios where Vault will be needed. >>>>>>> >>>>>>>> >>>>>>>> One of the proposals in this thread is to use something simple for DNSSEC >>>>>>>> keys >>>>>>>> (with few lines of Python code) and migrate DNSSEC with Vault when >>>>>>>> Vault is >>>>>>>> available and stable enough (in some later release). >>>>>>>> >>>>>>>>> I understand that Vault brings a lot of work to the table. But let us >>>>>>>>> do it >>>>>>>>> right and if it does not fit into 4.0 let us do it in 4.1. >>>>>>>> We will have one huge release with DNSSEC + Vault at once if we to >>>>>>>> postpone >>>>>>>> DNSSEC to the same release as Vault. >>>>>>>> >>>>>>>> As a result, it would be harder to debug it because we will have to >>>>>>>> find if >>>>>>>> something is broken because of: >>>>>>>> - DNSSEC-IPA integration >>>>>>>> - Vault-IPA integration >>>>>>>> - DNSSEC-Vault integration. >>>>>>>> >>>>>>>> I don't think it is a good idea to make such huge release. >>>>>>>> >>>>>>>> "Release early, release often" >>>>>>>> >>>>>>> >>>>>>> I must say I tend to agree with Petr. If the "poor man's solution" of >>>>>>> DNSSEC >>>>>>> without Vault does not cost us too much time and it would seem that the >>>>>>> Vault >>>>>>> is not going to squeeze in 4.0 deadlines, I would rather release the poor >>>>>>> man's >>>>>>> solution in 4.0 and switch to Vault when it's available in 4.1. >>>>>>> >>>>>>> This would let our users test the non-Vault parts of our DNSSEC solution >>>>>>> instead of waiting to test a perfect solution. >>>>>> >>>>>> Yesterday we have agreed that DNSSEC support is not going to depend on >>>>>> Vault >>>>>> from the beginning and that we can migrate to Vault later. >>>>>> >>>>>> Here I'm proposing safe upgrade path from non-vault to Vault solution. >>>>>> >>>>>> After all, it seems relatively easy. >>>>>> >>>>>> TL;DR version >>>>>> ============= >>>>>> Use information in cn=masters to detect if there are old replicas and >>>>>> temporarily convert new keys from Vault to LDAP storage (until all old >>>>>> replicas are deleted). >>>>>> >>>>>> Full version >>>>>> ============ >>>>>> IPA 4.0 is going to have OpenDNSSEC key generator on a single IPA server >>>>>> and >>>>>> separate key import/export daemon (i.e. script called from cron or >>>>>> something >>>>>> like that) on all IPA servers. >>>>>> >>>>>> In 4.0, we can add new LDAP objects for DNSSEC-related IPA services (please >>>>>> propose better names :-): >>>>>> - key generator: >>>>>> cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example >>>>>> >>>>>> >>>>>> - key imported/exporter: >>>>>> cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Initial state before upgrade: >>>>>> - N IPA 4.0 replicas >>>>>> - N DNSSECKeyImporterv1 service instances (i.e. key distribution for IPA >>>>>> 4.0) >>>>>> - 1 OpenDNSSECv1 service instance (key generator) >>>>>> >>>>>> Now we want to upgrade a first replica to IPA 4.1. For simplicity, let's >>>>>> add >>>>>> a *requirement* to upgrade the replica with OpenDNSSECv1 first. (We can >>>>>> generalize the procedure if this requirement is not acceptable.) >>>>>> >>>>>> Upgrade procedure: >>>>>> - stop OpenDNSSECv1 service >>>>>> - stop DNSSECKeyImporterv1 service >>>>>> - convert OpenDNSSECv1 database to OpenDNSSECv2 >>>>>> This step is not related to Vault. We need to covert local SQLite database >>>>>> from single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC. >>>>> do we need to convert SQLite ? I thought in phase 1 we would have scripts >>>>> exporting from OpenDNSSEC database and store in ldap, then the data already >>>>> exist in ldap. We would ned to replace the sofhthsm module by our own pkcs11 >>>>> module using ldap dn directly >>>> >>>> I'm sorry for not being clear. >>>> >>>> The short-term plain is going to be executed without significant changes: >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm >>>> >>>> >>>> >>>> This discussion is more about potential problems with upgrade from >>>> short-term solution to the long-term one - I'm updating >>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm >>>> >>>> right now. >>>> >>>> To answer your question about SQLite database: >>>> We will have *encryption keys* in LDAP already from the very beginning >>>> (exported to LDAP by a script) so upgrade from export script to PKCS#11 >>>> module should be be smooth. >>>> >>>> The problem is with various metadata stored in OpenDNSSEC's database so we >>>> will have to convert them to LDAP. In short-term we have neither intent nor >>>> time to design a LDAP schema for OpenDNSSEC database, just for the keys. >>> the schema proposal contains attributes for the metadata, so this should be >> The current schema stores only PKCS#11 metadata but nothing about >> key&signing policy and other DNSSEC-related stuff. >> >> We don't have complete schema and we don't have to have it now. Look at the >> SQLite database in opendnssecv143.sqlite3.bz2 - it is pretty complex. > ok, so this is not the softhsm pkcs11 sqlite database, but a db containing > other dnssec data, you didn't say that we need ldap schema for this and for > which subset of it I'm sorry for the confusion. Let me clarify it: For short-term we need this: =========================== 1) A future-proof schema for key material storage. This will be used by scripts in short-term and my PKCS#11 module in long-term. It needs to be same. There is nothing specific to DNSSEC. This schema is being designed on http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema (This is your original proposal - I have moved it to freeipa.org :-)) 2) Some minimal subset of DNSSEC-specific metadata required for converting key material from LDAP to BIND key files as we already discussed before. This will include just few timestamps, nothing huge. This small schema will be used by scripts in short-term and by OpenDNSSEC in long-term. So we also need to design it in a future-proof way but this should be relatively simple in comparison with the PKCS#11 schema. There is no design page for it right now because I'm still looking into OpenDNSSEC sources to make sure that I'm not missing something important. For long-term we need this: ========================== 3) Prepare full LDAP schema for OpenDNSSEC v2 and migration scripts from OpenDNSSEC v1 (with SQL backend) to v2 (with LDAP backend). 4) (optionally) Prepare a schema amendment for PKCS#11 which will allow us to store keys in Vault instead of plain LDAP. This will be most probably one new objectClass for private keys or something like that. Maybe we can design it now and make PKCS#11 to return ENOTIMPLEMENTED if it encounters the new objectClass. Petr^2 Spacek >> We don't have time to prepare schema & port OpenDNSSECv1 to LDAP backend. >> (Other aspect is that the schema is different for OpenDNSSEC v2.) >> >>> ok. But I think right now the export function available in opendnsssec/softhsm >>> only exports keys. We would have to have sql scripts to read and convert the >>> sqlite3 database >> >> Yes, we will have to have such script for upgrades from short-term -> >> long-term solution. From abokovoy at redhat.com Wed Mar 12 17:13:32 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 12 Mar 2014 19:13:32 +0200 Subject: [Freeipa-devel] [PATCH] 0150: make sure SID is always returned as unicode from dcerpc.py In-Reply-To: <53208E65.2060807@redhat.com> References: <20140312155650.GJ16644@redhat.com> <53208E65.2060807@redhat.com> Message-ID: <20140312171332.GK16644@redhat.com> On Wed, 12 Mar 2014, Martin Kosek wrote: >On 03/12/2014 04:56 PM, Alexander Bokovoy wrote: >> Hi, >> >> Trusted domain SID could be obtained through different means. When it is >> fetched from the AD DC via LDAP, it needs to be extracted from a default >> context and explicitly converted to unicode. >> >> https://fedorahosted.org/freeipa/ticket/4246 > >This only works for ADs without subdomains. When there are subdomains, AD does >not allow us to retrieve them and command fails right after creating the truyst >trust object: > ># echo Secret123 | ipa trust-add tbad.example.com --trust-secretipa: ERROR: AD >domain controller complains about communication sequence. It may mean >unsynchronized time on both sides, for example > ># ipa trust-fetch-domains tbad.example.com >ipa: ERROR: AD domain controller complains about communication sequence. It may >mean unsynchronized time on both sides, for example > >When I refreshed FreeIPA domains on AD said, it started working again: > ># ipa trust-fetch-domains tbad.example.com >-------------------------------------------- >List of trust domains successfully refreshed >-------------------------------------------- > Realm name: child.tbad.example.com > Domain NetBIOS name: CHILD > Domain Security Identifier: S-1-5-21-972585150-1048339146-1910910075 >---------------------------- >Number of entries returned 1 >---------------------------- Yep. We cannot run trust-fetch-domains at this point, neither we can verify the trust as we don't have AD admin credentials. Additional patch is attached to not run trust-fetch-domains automatically in this case. Note documentation update request. -- / Alexander Bokovoy -------------- next part -------------- >From 828219b886265920d631fc5026d17d7f2f853d66 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 12 Mar 2014 19:01:00 +0200 Subject: [PATCH 3/3] trust: do not fetch subdomains in case shared secret was used to set up the trust Until incoming trust is validated from AD side, we cannot run any operations against AD using the trust. Also, Samba currently does not suport verifying trust against the other party (returns WERR_NOT_SUPPORTED). This needs to be added to the documentation: When using 'ipa trust-add ad.domain --trust-secret', one has to manually validate incoming trust using forest trust properties in AD Domains and Trusts tool. Once incoming trust is validated at AD side, use IPA command 'ipa trust-fetch-domains ad.domain' to retrieve topology of the AD forest. From this point on the trust should be usable. https://fedorahosted.org/freeipa/ticket/4246 --- ipalib/plugins/trust.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index fe39568..f57cf7d 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -462,7 +462,8 @@ sides. # for AD trusts, regardless of the type of idranges associated with it # Note that fetch_domains_from_trust will add needed ranges for # the algorithmic ID mapping case. - if options.get('trust_type') == u'ad': + if (options.get('trust_type') == u'ad' and + options.get('trust_secret') is None): domains = fetch_domains_from_trust(self, self.trustinstance, result['result'], **options) -- 1.8.3.1 From mkosek at redhat.com Wed Mar 12 17:17:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 12 Mar 2014 18:17:54 +0100 Subject: [Freeipa-devel] [PATCH] 0150: make sure SID is always returned as unicode from dcerpc.py In-Reply-To: <20140312171332.GK16644@redhat.com> References: <20140312155650.GJ16644@redhat.com> <53208E65.2060807@redhat.com> <20140312171332.GK16644@redhat.com> Message-ID: <532096C2.7090202@redhat.com> On 03/12/2014 06:13 PM, Alexander Bokovoy wrote: > On Wed, 12 Mar 2014, Martin Kosek wrote: >> On 03/12/2014 04:56 PM, Alexander Bokovoy wrote: >>> Hi, >>> >>> Trusted domain SID could be obtained through different means. When it is >>> fetched from the AD DC via LDAP, it needs to be extracted from a default >>> context and explicitly converted to unicode. >>> >>> https://fedorahosted.org/freeipa/ticket/4246 >> >> This only works for ADs without subdomains. When there are subdomains, AD does >> not allow us to retrieve them and command fails right after creating the truyst >> trust object: >> >> # echo Secret123 | ipa trust-add tbad.example.com --trust-secretipa: ERROR: AD >> domain controller complains about communication sequence. It may mean >> unsynchronized time on both sides, for example >> >> # ipa trust-fetch-domains tbad.example.com >> ipa: ERROR: AD domain controller complains about communication sequence. It may >> mean unsynchronized time on both sides, for example >> >> When I refreshed FreeIPA domains on AD said, it started working again: >> >> # ipa trust-fetch-domains tbad.example.com >> -------------------------------------------- >> List of trust domains successfully refreshed >> -------------------------------------------- >> Realm name: child.tbad.example.com >> Domain NetBIOS name: CHILD >> Domain Security Identifier: S-1-5-21-972585150-1048339146-1910910075 >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- > Yep. We cannot run trust-fetch-domains at this point, neither we can > verify the trust as we don't have AD admin credentials. > > Additional patch is attached to not run trust-fetch-domains > automatically in this case. Note documentation update request. Works as a charm, ACK. Pushed both patches to: master: 34d644ebdf9f887441ef82d71b4f101206d897a8 ipa-3-3: a9fab2fc26be33e7296578961e61f2faec4f9061 Martin From lkrispen at redhat.com Wed Mar 12 17:29:59 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Wed, 12 Mar 2014 18:29:59 +0100 Subject: [Freeipa-devel] DNSSEC: LDAP schema requirements In-Reply-To: <53209482.9060201@redhat.com> References: <52FD02B7.3060404@redhat.com> <5315CC35.9080503@redhat.com> <1393946811.22047.75.camel@willson.li.ssimo.org> <5315F888.8040805@redhat.com> <5315FE83.403@redhat.com> <531602AC.60605@redhat.com> <531617F0.3030201@redhat.com> <1393960784.22047.78.camel@willson.li.ssimo.org> <1393962538.22047.82.camel@willson.li.ssi! mo.org> <531636C5.6010304@redhat.com> <1393967754.22047.97.camel@willson.li.ssimo.org> <531647C8.5090807@redhat.com> <1393970034.22047.109.camel@willson.li.ssimo.org> <5316504A.9090303@redhat.com> <53171319.6030007@redhat.com> <1394028254.14651.10.camel@willson.li.ssimo.org> <531742D0.9050203@redhat.com> <1394035600.14651.13.camel@willson.li.ssimo.org> <5319F4CF.3000406@redhat.com> <531D98A8.8090207@redhat.com> <531D9D37.70201@redhat.com> <531EE667.5060700@redhat.com> <53204109.4010804@redhat.com> <53204E7C.1090601@redhat.com> <53205BF6.30309@redhat.com> <53207D0F.7020403@red! hat.com> <53208335.9000507@redhat.com> <53209482.9060201@redhat.com> Message-ID: <53209997.3030109@redhat.com> On 03/12/2014 06:08 PM, Petr Spacek wrote: > On 12.3.2014 16:54, Ludwig Krispenz wrote: >> >> On 03/12/2014 04:28 PM, Petr Spacek wrote: >>> On 12.3.2014 14:07, Ludwig Krispenz wrote: >>>> >>>> On 03/12/2014 01:09 PM, Petr Spacek wrote: >>>>> On 12.3.2014 12:12, Ludwig Krispenz wrote: >>>>>> On 03/11/2014 11:33 AM, Petr Spacek wrote: >>>>>>> On 10.3.2014 12:08, Martin Kosek wrote: >>>>>>>> On 03/10/2014 11:49 AM, Petr Spacek wrote: >>>>>>>>> On 7.3.2014 17:33, Dmitri Pal wrote: >>>>>>>>>> I do not think it is the right architectural approach to try >>>>>>>>>> to fix a >>>>>>>>>> specific >>>>>>>>>> use case with one off solution while we already know that we >>>>>>>>>> need a key >>>>>>>>>> storage. >>>>>>>>>> I would rather do things right and reusable than jam them >>>>>>>>>> into the >>>>>>>>>> currently >>>>>>>>>> proposed release boundaries. >>>>>>>>> I want to make clear that I'm not opposed to Vault in general. >>>>>>>>> I'm >>>>>>>>> questioning >>>>>>>>> the necessity of Vault from the beginning because it will >>>>>>>>> delay DNSSEC >>>>>>>>> significantly. >>>>>>>> >>>>>>>> +1, I also now see number of scenarios where Vault will be needed. >>>>>>>> >>>>>>>>> >>>>>>>>> One of the proposals in this thread is to use something simple >>>>>>>>> for DNSSEC >>>>>>>>> keys >>>>>>>>> (with few lines of Python code) and migrate DNSSEC with Vault >>>>>>>>> when >>>>>>>>> Vault is >>>>>>>>> available and stable enough (in some later release). >>>>>>>>> >>>>>>>>>> I understand that Vault brings a lot of work to the table. >>>>>>>>>> But let us >>>>>>>>>> do it >>>>>>>>>> right and if it does not fit into 4.0 let us do it in 4.1. >>>>>>>>> We will have one huge release with DNSSEC + Vault at once if >>>>>>>>> we to >>>>>>>>> postpone >>>>>>>>> DNSSEC to the same release as Vault. >>>>>>>>> >>>>>>>>> As a result, it would be harder to debug it because we will >>>>>>>>> have to >>>>>>>>> find if >>>>>>>>> something is broken because of: >>>>>>>>> - DNSSEC-IPA integration >>>>>>>>> - Vault-IPA integration >>>>>>>>> - DNSSEC-Vault integration. >>>>>>>>> >>>>>>>>> I don't think it is a good idea to make such huge release. >>>>>>>>> >>>>>>>>> "Release early, release often" >>>>>>>>> >>>>>>>> >>>>>>>> I must say I tend to agree with Petr. If the "poor man's >>>>>>>> solution" of >>>>>>>> DNSSEC >>>>>>>> without Vault does not cost us too much time and it would seem >>>>>>>> that the >>>>>>>> Vault >>>>>>>> is not going to squeeze in 4.0 deadlines, I would rather >>>>>>>> release the poor >>>>>>>> man's >>>>>>>> solution in 4.0 and switch to Vault when it's available in 4.1. >>>>>>>> >>>>>>>> This would let our users test the non-Vault parts of our DNSSEC >>>>>>>> solution >>>>>>>> instead of waiting to test a perfect solution. >>>>>>> >>>>>>> Yesterday we have agreed that DNSSEC support is not going to >>>>>>> depend on >>>>>>> Vault >>>>>>> from the beginning and that we can migrate to Vault later. >>>>>>> >>>>>>> Here I'm proposing safe upgrade path from non-vault to Vault >>>>>>> solution. >>>>>>> >>>>>>> After all, it seems relatively easy. >>>>>>> >>>>>>> TL;DR version >>>>>>> ============= >>>>>>> Use information in cn=masters to detect if there are old >>>>>>> replicas and >>>>>>> temporarily convert new keys from Vault to LDAP storage (until >>>>>>> all old >>>>>>> replicas are deleted). >>>>>>> >>>>>>> Full version >>>>>>> ============ >>>>>>> IPA 4.0 is going to have OpenDNSSEC key generator on a single >>>>>>> IPA server >>>>>>> and >>>>>>> separate key import/export daemon (i.e. script called from cron or >>>>>>> something >>>>>>> like that) on all IPA servers. >>>>>>> >>>>>>> In 4.0, we can add new LDAP objects for DNSSEC-related IPA >>>>>>> services (please >>>>>>> propose better names :-): >>>>>>> - key generator: >>>>>>> cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example >>>>>>> >>>>>>> >>>>>>> >>>>>>> - key imported/exporter: >>>>>>> cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Initial state before upgrade: >>>>>>> - N IPA 4.0 replicas >>>>>>> - N DNSSECKeyImporterv1 service instances (i.e. key distribution >>>>>>> for IPA >>>>>>> 4.0) >>>>>>> - 1 OpenDNSSECv1 service instance (key generator) >>>>>>> >>>>>>> Now we want to upgrade a first replica to IPA 4.1. For >>>>>>> simplicity, let's >>>>>>> add >>>>>>> a *requirement* to upgrade the replica with OpenDNSSECv1 first. >>>>>>> (We can >>>>>>> generalize the procedure if this requirement is not acceptable.) >>>>>>> >>>>>>> Upgrade procedure: >>>>>>> - stop OpenDNSSECv1 service >>>>>>> - stop DNSSECKeyImporterv1 service >>>>>>> - convert OpenDNSSECv1 database to OpenDNSSECv2 >>>>>>> This step is not related to Vault. We need to covert local >>>>>>> SQLite database >>>>>>> from single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC. >>>>>> do we need to convert SQLite ? I thought in phase 1 we would have >>>>>> scripts >>>>>> exporting from OpenDNSSEC database and store in ldap, then the >>>>>> data already >>>>>> exist in ldap. We would ned to replace the sofhthsm module by our >>>>>> own pkcs11 >>>>>> module using ldap dn directly >>>>> >>>>> I'm sorry for not being clear. >>>>> >>>>> The short-term plain is going to be executed without significant >>>>> changes: >>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm >>>>> >>>>> >>>>> >>>>> >>>>> This discussion is more about potential problems with upgrade from >>>>> short-term solution to the long-term one - I'm updating >>>>> https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm >>>>> >>>>> >>>>> right now. >>>>> >>>>> To answer your question about SQLite database: >>>>> We will have *encryption keys* in LDAP already from the very >>>>> beginning >>>>> (exported to LDAP by a script) so upgrade from export script to >>>>> PKCS#11 >>>>> module should be be smooth. >>>>> >>>>> The problem is with various metadata stored in OpenDNSSEC's >>>>> database so we >>>>> will have to convert them to LDAP. In short-term we have neither >>>>> intent nor >>>>> time to design a LDAP schema for OpenDNSSEC database, just for the >>>>> keys. >>>> the schema proposal contains attributes for the metadata, so this >>>> should be >>> The current schema stores only PKCS#11 metadata but nothing about >>> key&signing policy and other DNSSEC-related stuff. >>> >>> We don't have complete schema and we don't have to have it now. Look >>> at the >>> SQLite database in opendnssecv143.sqlite3.bz2 - it is pretty complex. >> ok, so this is not the softhsm pkcs11 sqlite database, but a db >> containing >> other dnssec data, you didn't say that we need ldap schema for this >> and for >> which subset of it > > I'm sorry for the confusion. Let me clarify it: > > For short-term we need this: > =========================== > 1) A future-proof schema for key material storage. > This will be used by scripts in short-term and my PKCS#11 module in > long-term. It needs to be same. There is nothing specific to DNSSEC. > This schema is being designed on > http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema > (This is your original proposal - I have moved it to freeipa.org :-)) thanks, I will then do the updates there > > 2) Some minimal subset of DNSSEC-specific metadata required for > converting key material from LDAP to BIND key files as we already > discussed before. This will include just few timestamps, nothing huge. > This small schema will be used by scripts in short-term and by > OpenDNSSEC in long-term. So we also need to design it in a > future-proof way but this should be relatively simple in comparison > with the PKCS#11 schema. > There is no design page for it right now because I'm still looking > into OpenDNSSEC sources to make sure that I'm not missing something > important. > > > For long-term we need this: > ========================== > 3) Prepare full LDAP schema for OpenDNSSEC v2 and migration scripts > from OpenDNSSEC v1 (with SQL backend) to v2 (with LDAP backend). ok, this was not clear to me > > 4) (optionally) Prepare a schema amendment for PKCS#11 which will > allow us to store keys in Vault instead of plain LDAP. This will be > most probably one new objectClass for private keys or something like > that. Maybe we can design it now and make PKCS#11 to return > ENOTIMPLEMENTED if it encounters the new objectClass. > > Petr^2 Spacek > >>> We don't have time to prepare schema & port OpenDNSSECv1 to LDAP >>> backend. >>> (Other aspect is that the schema is different for OpenDNSSEC v2.) >>> >>>> ok. But I think right now the export function available in >>>> opendnsssec/softhsm >>>> only exports keys. We would have to have sql scripts to read and >>>> convert the >>>> sqlite3 database >>> >>> Yes, we will have to have such script for upgrades from short-term -> >>> long-term solution. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Wed Mar 12 18:48:11 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 12 Mar 2014 14:48:11 -0400 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53203EBA.6060605@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD3274.9060401@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> <53203EBA.6060605@redhat.! com> Message-ID: <5320ABEB.1080308@redhat.com> Petr Viktorin wrote: > On 03/10/2014 08:55 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 02/27/2014 10:18 PM, Rob Crittenden wrote: >>>>> Rob Crittenden wrote: >>>>> Updated patch based on feedback from Foreman team. I added a new URI, >>>>> /features, which Foreman uses to determine what capabilities a proxy >>>>> has. >>>>> >>>>> rob >>>> >>>> On my VMs, where the first request is handled properly but the server >>>> hangs on the second one. I gave you access to the machines for >>>> investigation. >>> >>> Sent you something out-of-band but in short, I wasn't able to reproduce >>> on your reproducing VMs :-( Ping me tomorrow and we'll try it together. > > It ended up a combination of my mistake and a bug in GSSProxy. At least > you found the bug. https://fedorahosted.org/gss-proxy/ticket/121 > >>>> Please add the Python libraries (python-cherrypy, python-requests, >>>> python-kerberos) to BuildRequires. Otherwise the build fails due to >>>> pylint errors. >>> >>> Fixed. >>> >>>> >>>> In the man page: >>>> >>>>> +Create a host or user whose credentials will be used by the server to >>>>> make requests and add it to the role: >>>>> + >>>>> + $ ipa user\-add \-\-first=Smartproxy \-\-last=Serversmartproxy >>>>> + $ ipa role\-add\-member \-\-users=smartproxy 'Smartproxy management' >>>> >>>> the first command should be >>>> ipa user-add smartproxy --first=Smartproxy --last=Serversmartproxy >>>> since by default the username is 'sserversmartproxy'. >>> >>> The problem was a missing space before smartproxy. I have the login name >>> last in this example. Fixed. >>> >>>> >>>> A nitpick regarding the systemd service: according to [0], Type=forking >>>> should be avoided. Is there a reason against setting Type=simple, and >>>> removing the PID file? >>> >>> Because I wasn't able to get this working with cherrypy daemon mode. >>> AFAICT it forks itself and systemd wouldn't end up with the right pid so >>> can't stop the service. >> >> And now the updated patch. The changes are super-minor. >> >> rob >> > > One last nitpick: the IPAErrors get encoded as JSON but the > Content-Encoding is set to text/html. It's a one-line change so I went > ahead and tested with it. ACK from me if you agree. +1 Here are a couple more enhancements I'm considering, this seems simpler than inter-diff since it is so small. Here is why I made the changes, in order: I doubled the calls to create the connection but one isn't in a try/except!? Remove the obvious one. We currently completely eat GSSAPI errors, I figure we should log failures. IPA stores the principal in the request context so using that will save a GSSAPI call (and as we learned, a lock in gssproxy). I included your content-type change. rob diff --git a/smartproxy/ipa-smartproxy b/smartproxy/ipa-smartproxy index d5e8f22..ba50cef 100755 --- a/smartproxy/ipa-smartproxy +++ b/smartproxy/ipa-smartproxy @@ -32,6 +32,7 @@ from cherrypy.process import plugins from ipalib import api from ipalib import errors from ipalib import util +from ipalib.request import context from ipaserver.rpcserver import json_encode_binary from ipapython.version import VERSION @@ -83,12 +84,12 @@ def Command(command, *args, **options): message="Not a local request" ) - if not api.Backend.rpcclient.isconnected(): - api.Backend.rpcclient.connect() try: if not api.Backend.rpcclient.isconnected(): api.Backend.rpcclient.connect() except errors.CCacheError, e: + cherrypy.log(msg="Kerberos error: %s" % e, + context='IPA', traceback=False) raise IPAError( status=401, message=e @@ -171,9 +172,11 @@ class IPAError(cherrypy.HTTPError): error = {'message': 'Unable to handle error message type %s' % type(self._mess age)} + principal = getattr(context, 'principal', None) + response.headers["Content-Type"] = "application/json;charset= utf-8" response.body = json.dumps({'error': error, 'id': 0, - 'principal': util.get_current_principal (), + 'principal': principal, 'result': None, 'version': VERSION}, sort_keys=True, indent=2) From pviktori at redhat.com Wed Mar 12 18:59:39 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 12 Mar 2014 19:59:39 +0100 Subject: [Freeipa-devel] [PATCHES] 172-196 Refactor certificate renewal code In-Reply-To: <531DAA0F.9080300@redhat.com> References: <525FD641.20202@redhat.com> <526009D7.2040702@redhat.com> <5260175E.50809@redhat.com> <531DAA0F.9080300@redhat.com> Message-ID: <5320AE9B.6040303@redhat.com> On 03/10/2014 01:03 PM, Jan Cholasta wrote: > On 17.10.2013 18:59, Jan Cholasta wrote: >> On 17.10.2013 18:01, Petr Viktorin wrote: >>> On 10/17/2013 02:21 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> this patchset contains refactoring of the certificate renewal code, >>>> which will be the base for CA certificate renewal. >>>> >>>> The biggest change is a new certmonger CA helper >>>> dogtag-ipa-ca-renew-agent, which replaces >>>> dogtag-ipa-retrieve-agent-submit as well as parts of certmonger >>>> post-commands used in certificate renewal. It provides more flexibility >>>> when doing renewals and allows unified certmonger configuration on both >>>> CA master and clones. >>>> >>>> How to test: Test both CA-ful and CA-less server and replica installs >>>> and upgrades, check that certmonger is configured properly and >>>> certificate renewal works (see >>>> https://fedorahosted.org/freeipa/ticket/2803#comment:17 for details). Certmonger is not configured/started in CA-less installs. I tested fresh installs and upgrades; renewals work fine for me. 161-184 look OK 185: one more nitpick: cert = entry['usercertificate'][0] Shouldn't that use entry.single_value? 186-189 look OK 190: Is fqdn = entries[0].dn[1].value return api.env.host == fqdn safe? Can they differ in case, for example? 191-196 look OK > Note that patches 178 & 179 were already pushed. Also, patch 190 was > changed to store information about which CA instance is master in LDAP. -- Petr? From mkosek at redhat.com Thu Mar 13 08:09:20 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Mar 2014 09:09:20 +0100 Subject: [Freeipa-devel] [PATCH] 461 Update Dogtag 9 database during replica installation Message-ID: <532167B0.8080600@redhat.com> When Dogtag 10 based FreeIPA replica is being installed for a Dogtag 9 based master, the PKI database is not updated and miss several ACLs which prevent some of the PKI functions, e.g. an ability to create other clones. Add an update file to do the database update. Content is based on recommendation from PKI team: * https://bugzilla.redhat.com/show_bug.cgi?id=1075118#c9 This update file can be removed when Dogtag database upgrades are done in PKI component. Upstream tickets: * https://fedorahosted.org/pki/ticket/710 (database upgrade framework) * https://fedorahosted.org/pki/ticket/906 (checking database version) https://fedorahosted.org/freeipa/ticket/4243 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-461-update-dogtag-9-database-during-replica-installation.patch Type: text/x-patch Size: 4310 bytes Desc: not available URL: From pspacek at redhat.com Thu Mar 13 08:40:42 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 13 Mar 2014 09:40:42 +0100 Subject: [Freeipa-devel] emerging standard for hosts/passwords policy/automount/netgroups in LDAP Message-ID: <53216F0A.9040105@redhat.com> Hello list, FYI I have come across following RFC drafts: (please start with the first one :-) http://www.ietf.org/id/draft-bannister-dbis-mapping-03.txt http://tools.ietf.org/html/draft-bannister-dbis-passwd-02 http://www.ietf.org/id/draft-bannister-dbis-policy-03.txt http://tools.ietf.org/html/draft-bannister-dbis-netgroup-02 http://tools.ietf.org/html/draft-bannister-dbis-automounter-02 http://tools.ietf.org/html/draft-bannister-dbis-hosts-04 I didn't study them in detail but it seems like an attempt to standardize Directory User Agent (DUA) profiles for various things like automounter etc. Maybe we can contact the author and coordinate/harmonize what possible. At first glance automount spec seems incompatible with RFC2307bis schema, maybe that is one of things we can discuss and try to solve. -- Petr^2 Spacek From pspacek at redhat.com Thu Mar 13 08:50:26 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 13 Mar 2014 09:50:26 +0100 Subject: [Freeipa-devel] emerging standard for System for Cross-Domain Identity Management Message-ID: <53217152.5070905@redhat.com> Hello list, my journey to the IETF land revealed following RFC drafts: System for Cross-Domain Identity Management 2. SCIM User Scenarios 2.1. Background & Context The System for Cross-domain Identity Management (SCIM) specification is designed to make managing user identity in cloud based applications and services easier. http://tools.ietf.org/html/draft-ietf-scim-use-cases-01 http://tools.ietf.org/html/draft-ietf-scim-api-03 http://tools.ietf.org/html/draft-ietf-scim-core-schema-03 I didn't study them in detail but the title seems to be interesting enough to justify this e-mail. Have a nice day! -- Petr^2 Spacek From pspacek at redhat.com Thu Mar 13 09:08:20 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 13 Mar 2014 10:08:20 +0100 Subject: [Freeipa-devel] LDAP Queue Length Control for better LDAP client performance? Message-ID: <53217584.4000904@redhat.com> Hello list, my journey to the IETF wonderland revealed one more RFC draft: LDAP Queue Length Control http://tools.ietf.org/html/draft-hollstein-queuelength-control-01 I have no idea if this can really improve LDAP client performance or not but IMHO it is worth exploring it. Maybe only an IPA replica with thousands of SSSD clients could benefit from it, I don't know. I have finally ran out of notes from yesterday so you don't need to worry about more RFC drafts - today :-) -- Petr^2 Spacek From pviktori at redhat.com Thu Mar 13 10:11:30 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 13 Mar 2014 11:11:30 +0100 Subject: [Freeipa-devel] [PATCH] 549 webui: use unique ids for checkboxes In-Reply-To: <20140312175103.6273a630@unused-4-246.brq.redhat.com> References: <530CCEF4.4060905@redhat.com> <20140312175103.6273a630@unused-4-246.brq.redhat.com> Message-ID: <53218452.2070502@redhat.com> On 03/12/2014 05:51 PM, Misnyovszki Adam wrote: > On Tue, 25 Feb 2014 18:12:20 +0100 > Petr Vobornik wrote: > >> This is a minor fix. Please don't close ticket 3904 yet if committed. >> >> Checkboxes have not used unique ids across the whole UI. It broke >> checking by clicking on label for later displayed instances. It >> became serious problem when rcue introduced new checkbox styles with >> 'label clicking' as default check method. >> >> https://fedorahosted.org/freeipa/ticket/3904 > > ACK Pushed to master: 65bde3ecd7dc0b2d51fd7c3faf49edbe662151e2 -- Petr? From tbabej at redhat.com Thu Mar 13 11:45:29 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 13 Mar 2014 12:45:29 +0100 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range Message-ID: <53219A59.9060901@redhat.com> Hi, Changes the code in the idrange_del method to not only check for the root domains that match the SID in the IDRange, but for the SIDs of subdomains of trusts as well. https://fedorahosted.org/freeipa/ticket/4247 -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0157-Prohibit-deletion-of-active-subdomain-range.patch Type: text/x-patch Size: 2096 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 13 11:52:29 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Mar 2014 12:52:29 +0100 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range In-Reply-To: <53219A59.9060901@redhat.com> References: <53219A59.9060901@redhat.com> Message-ID: <53219BFD.1090803@redhat.com> On 03/13/2014 12:45 PM, Tomas Babej wrote: > Hi, > > Changes the code in the idrange_del method to not only check for > the root domains that match the SID in the IDRange, but for the > SIDs of subdomains of trusts as well. > > https://fedorahosted.org/freeipa/ticket/4247 This is a very complicated validation procedure IMO. Lot of subcommands, lot of LDAP searches. Why can't we do just one LDAP search with - base api.env.container_trusts - scope SUB - filter (&(objectclass=ipaNTTrustedDomain)(ipanttrusteddomainsid=range_sid)) When errors.NotFound is raised, we are OK. When it is not raised, we have a problem. Wouldn't it be simpler? Martin From abokovoy at redhat.com Thu Mar 13 11:59:11 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Mar 2014 13:59:11 +0200 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range In-Reply-To: <53219A59.9060901@redhat.com> References: <53219A59.9060901@redhat.com> Message-ID: <20140313115911.GL16644@redhat.com> On Thu, 13 Mar 2014, Tomas Babej wrote: >Hi, > >Changes the code in the idrange_del method to not only check for >the root domains that match the SID in the IDRange, but for the >SIDs of subdomains of trusts as well. > >https://fedorahosted.org/freeipa/ticket/4247 > >-- >Tomas Babej >Associate Software Engeneer | Red Hat | Identity Management >RHCE | Brno Site | IRC: tbabej | freeipa.org > > >>From e8c83773d8164d87d79062931b642df76fc479da Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Thu, 13 Mar 2014 12:36:17 +0100 >Subject: [PATCH] Prohibit deletion of active subdomain range > >Changes the code in the idrange_del method to not only check for >the root domains that match the SID in the IDRange, but for the >SIDs of subdomains of trusts as well. > >https://fedorahosted.org/freeipa/ticket/4247 >--- > ipalib/plugins/idrange.py | 23 +++++++++++++++++------ > 1 file changed, 17 insertions(+), 6 deletions(-) > >diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py >index 3a92d9898cc03f517b0f2bb75093eeb741cff646..ff6cdbc94ce479d0d8863cc5dfb1c074e7f3a5ad 100644 >--- a/ipalib/plugins/idrange.py >+++ b/ipalib/plugins/idrange.py >@@ -568,13 +568,24 @@ class idrange_del(LDAPDelete): > > if range_sid is not None: > range_sid = range_sid[0] >- result = api.Command['trust_find'](ipanttrusteddomainsid=range_sid) > >- if result['count'] > 0: >- raise errors.DependentEntry( >- label='Active Trust', >- key=keys[0], >- dependent=result['result'][0]['cn'][0]) >+ # We need to check all the subdomains of all trusts, so we iterate >+ # over all active trusts >+ active_trusts = api.Command['trust_find']() >+ >+ for trust in active_trusts['result']: >+ matching_domains = api.Command['trustdomain_find']( >+ trust['cn'][0], >+ ipanttrusteddomainsid=range_sid >+ ) >+ >+ # If there's a active domain of a trust that this range >+ # belongs to, raise an DependentEntry error >+ if matching_domains['count'] > 0: >+ raise errors.DependentEntry( >+ label='Active Trust domain', >+ key=keys[0], >+ dependent=matching_domains['result'][0]['cn'][0]) > > return dn ACK. -- / Alexander Bokovoy From mkosek at redhat.com Thu Mar 13 12:01:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Mar 2014 13:01:19 +0100 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range In-Reply-To: <20140313115911.GL16644@redhat.com> References: <53219A59.9060901@redhat.com> <20140313115911.GL16644@redhat.com> Message-ID: <53219E0F.9040302@redhat.com> On 03/13/2014 12:59 PM, Alexander Bokovoy wrote: > On Thu, 13 Mar 2014, Tomas Babej wrote: >> Hi, >> >> Changes the code in the idrange_del method to not only check for >> the root domains that match the SID in the IDRange, but for the >> SIDs of subdomains of trusts as well. >> >> https://fedorahosted.org/freeipa/ticket/4247 >> >> -- >> Tomas Babej >> Associate Software Engeneer | Red Hat | Identity Management >> RHCE | Brno Site | IRC: tbabej | freeipa.org >> >> > >>> From e8c83773d8164d87d79062931b642df76fc479da Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Thu, 13 Mar 2014 12:36:17 +0100 >> Subject: [PATCH] Prohibit deletion of active subdomain range >> >> Changes the code in the idrange_del method to not only check for >> the root domains that match the SID in the IDRange, but for the >> SIDs of subdomains of trusts as well. >> >> https://fedorahosted.org/freeipa/ticket/4247 >> --- >> ipalib/plugins/idrange.py | 23 +++++++++++++++++------ >> 1 file changed, 17 insertions(+), 6 deletions(-) >> >> diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py >> index >> 3a92d9898cc03f517b0f2bb75093eeb741cff646..ff6cdbc94ce479d0d8863cc5dfb1c074e7f3a5ad >> 100644 >> --- a/ipalib/plugins/idrange.py >> +++ b/ipalib/plugins/idrange.py >> @@ -568,13 +568,24 @@ class idrange_del(LDAPDelete): >> >> if range_sid is not None: >> range_sid = range_sid[0] >> - result = api.Command['trust_find'](ipanttrusteddomainsid=range_sid) >> >> - if result['count'] > 0: >> - raise errors.DependentEntry( >> - label='Active Trust', >> - key=keys[0], >> - dependent=result['result'][0]['cn'][0]) >> + # We need to check all the subdomains of all trusts, so we iterate >> + # over all active trusts >> + active_trusts = api.Command['trust_find']() >> + >> + for trust in active_trusts['result']: >> + matching_domains = api.Command['trustdomain_find']( >> + trust['cn'][0], >> + ipanttrusteddomainsid=range_sid >> + ) >> + >> + # If there's a active domain of a trust that this range >> + # belongs to, raise an DependentEntry error >> + if matching_domains['count'] > 0: >> + raise errors.DependentEntry( >> + label='Active Trust domain', >> + key=keys[0], >> + dependent=matching_domains['result'][0]['cn'][0]) >> >> return dn > > ACK. NACK from me - too complicated and uneffective. Please check my review for details. Martin From abokovoy at redhat.com Thu Mar 13 12:01:37 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Mar 2014 14:01:37 +0200 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range In-Reply-To: <53219BFD.1090803@redhat.com> References: <53219A59.9060901@redhat.com> <53219BFD.1090803@redhat.com> Message-ID: <20140313120137.GM16644@redhat.com> On Thu, 13 Mar 2014, Martin Kosek wrote: >On 03/13/2014 12:45 PM, Tomas Babej wrote: >> Hi, >> >> Changes the code in the idrange_del method to not only check for >> the root domains that match the SID in the IDRange, but for the >> SIDs of subdomains of trusts as well. >> >> https://fedorahosted.org/freeipa/ticket/4247 > >This is a very complicated validation procedure IMO. Lot of subcommands, lot of >LDAP searches. > >Why can't we do just one LDAP search with >- base api.env.container_trusts >- scope SUB >- filter (&(objectclass=ipaNTTrustedDomain)(ipanttrusteddomainsid=range_sid)) > >When errors.NotFound is raised, we are OK. When it is not raised, we have a >problem. > >Wouldn't it be simpler? No. Please do not do optimization here. It is a code that is called very rarely and expressiveness is more important here than optimizing access to couple of entries in LDAP. -- / Alexander Bokovoy From mkosek at redhat.com Thu Mar 13 12:06:12 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Mar 2014 13:06:12 +0100 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range In-Reply-To: <20140313120137.GM16644@redhat.com> References: <53219A59.9060901@redhat.com> <53219BFD.1090803@redhat.com> <20140313120137.GM16644@redhat.com> Message-ID: <53219F34.2070209@redhat.com> On 03/13/2014 01:01 PM, Alexander Bokovoy wrote: > On Thu, 13 Mar 2014, Martin Kosek wrote: >> On 03/13/2014 12:45 PM, Tomas Babej wrote: >>> Hi, >>> >>> Changes the code in the idrange_del method to not only check for >>> the root domains that match the SID in the IDRange, but for the >>> SIDs of subdomains of trusts as well. >>> >>> https://fedorahosted.org/freeipa/ticket/4247 >> >> This is a very complicated validation procedure IMO. Lot of subcommands, lot of >> LDAP searches. >> >> Why can't we do just one LDAP search with >> - base api.env.container_trusts >> - scope SUB >> - filter (&(objectclass=ipaNTTrustedDomain)(ipanttrusteddomainsid=range_sid)) >> >> When errors.NotFound is raised, we are OK. When it is not raised, we have a >> problem. >> >> Wouldn't it be simpler? > > No. Please do not do optimization here. It is a code that is called very > rarely and expressiveness is more important here than optimizing access > to couple of entries in LDAP. > I am not optimizing - I am actually making the validation much simpler. What is more simple and straightforward? A) One ldap.find_entries call B) A loop, numerous subcommands and LDAP searches Martin From abokovoy at redhat.com Thu Mar 13 12:10:57 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Mar 2014 14:10:57 +0200 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range In-Reply-To: <53219F34.2070209@redhat.com> References: <53219A59.9060901@redhat.com> <53219BFD.1090803@redhat.com> <20140313120137.GM16644@redhat.com> <53219F34.2070209@redhat.com> Message-ID: <20140313121057.GN16644@redhat.com> On Thu, 13 Mar 2014, Martin Kosek wrote: >On 03/13/2014 01:01 PM, Alexander Bokovoy wrote: >> On Thu, 13 Mar 2014, Martin Kosek wrote: >>> On 03/13/2014 12:45 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> Changes the code in the idrange_del method to not only check for >>>> the root domains that match the SID in the IDRange, but for the >>>> SIDs of subdomains of trusts as well. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4247 >>> >>> This is a very complicated validation procedure IMO. Lot of subcommands, lot of >>> LDAP searches. >>> >>> Why can't we do just one LDAP search with >>> - base api.env.container_trusts >>> - scope SUB >>> - filter (&(objectclass=ipaNTTrustedDomain)(ipanttrusteddomainsid=range_sid)) >>> >>> When errors.NotFound is raised, we are OK. When it is not raised, we have a >>> problem. >>> >>> Wouldn't it be simpler? >> >> No. Please do not do optimization here. It is a code that is called very >> rarely and expressiveness is more important here than optimizing access >> to couple of entries in LDAP. >> > >I am not optimizing - I am actually making the validation much simpler. What is >more simple and straightforward? > >A) One ldap.find_entries call >B) A loop, numerous subcommands and LDAP searches So far I've been successful in keeping details on how trust objects are represented in LDAP hidden from the rest of the framework code by encapsulating it all in trust.py. The change you propose will make it leaking to idrange.py. If we start changing the structure (which is maintained by ipasam module, not the framework), we will have more maintenance problems with the code spread out. -- / Alexander Bokovoy From mkosek at redhat.com Thu Mar 13 12:20:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Mar 2014 13:20:31 +0100 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range In-Reply-To: <20140313121057.GN16644@redhat.com> References: <53219A59.9060901@redhat.com> <53219BFD.1090803@redhat.com> <20140313120137.GM16644@redhat.com> <53219F34.2070209@redhat.com> <20140313121057.GN16644@redhat.com> Message-ID: <5321A28F.5040608@redhat.com> On 03/13/2014 01:10 PM, Alexander Bokovoy wrote: > On Thu, 13 Mar 2014, Martin Kosek wrote: >> On 03/13/2014 01:01 PM, Alexander Bokovoy wrote: >>> On Thu, 13 Mar 2014, Martin Kosek wrote: >>>> On 03/13/2014 12:45 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> Changes the code in the idrange_del method to not only check for >>>>> the root domains that match the SID in the IDRange, but for the >>>>> SIDs of subdomains of trusts as well. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4247 >>>> >>>> This is a very complicated validation procedure IMO. Lot of subcommands, >>>> lot of >>>> LDAP searches. >>>> >>>> Why can't we do just one LDAP search with >>>> - base api.env.container_trusts >>>> - scope SUB >>>> - filter (&(objectclass=ipaNTTrustedDomain)(ipanttrusteddomainsid=range_sid)) >>>> >>>> When errors.NotFound is raised, we are OK. When it is not raised, we have a >>>> problem. >>>> >>>> Wouldn't it be simpler? >>> >>> No. Please do not do optimization here. It is a code that is called very >>> rarely and expressiveness is more important here than optimizing access >>> to couple of entries in LDAP. >>> >> >> I am not optimizing - I am actually making the validation much simpler. What is >> more simple and straightforward? >> >> A) One ldap.find_entries call >> B) A loop, numerous subcommands and LDAP searches > > So far I've been successful in keeping details on how trust objects are > represented in LDAP hidden from the rest of the framework code by > encapsulating it all in trust.py. The change you propose will > make it leaking to idrange.py. If we start changing the structure (which > is maintained by ipasam module, not the framework), we will have more > maintenance problems with the code spread out. Ok, I can see your point, but I am still not sure it warrants that complicated validation and a new dependency between commands. You cannot that easily change the structure of the subdomains anyway as it would break all older servers which expect the subdomains to be where they are. In plugins, we do LDAP searches in cases like this one quite regularly IMO, it is not something unprecendented. And there is a good reason, simple LDAP call is much easier and less error prone to changes in our frameworks than calling subcommands. One glitch or a change in the subcommand can break not only the subcommand, but it's all callers. Martin From pspacek at redhat.com Thu Mar 13 12:28:36 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 13 Mar 2014 13:28:36 +0100 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range In-Reply-To: <5321A28F.5040608@redhat.com> References: <53219A59.9060901@redhat.com> <53219BFD.1090803@redhat.com> <20140313120137.GM16644@redhat.com> <53219F34.2070209@redhat.com> <20140313121057.GN16644@redhat.com> <5321A28F.5040608@redhat.com> Message-ID: <5321A474.4070905@redhat.com> On 13.3.2014 13:20, Martin Kosek wrote: > On 03/13/2014 01:10 PM, Alexander Bokovoy wrote: >> On Thu, 13 Mar 2014, Martin Kosek wrote: >>> On 03/13/2014 01:01 PM, Alexander Bokovoy wrote: >>>> On Thu, 13 Mar 2014, Martin Kosek wrote: >>>>> On 03/13/2014 12:45 PM, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> Changes the code in the idrange_del method to not only check for >>>>>> the root domains that match the SID in the IDRange, but for the >>>>>> SIDs of subdomains of trusts as well. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4247 >>>>> >>>>> This is a very complicated validation procedure IMO. Lot of subcommands, >>>>> lot of >>>>> LDAP searches. >>>>> >>>>> Why can't we do just one LDAP search with >>>>> - base api.env.container_trusts >>>>> - scope SUB >>>>> - filter (&(objectclass=ipaNTTrustedDomain)(ipanttrusteddomainsid=range_sid)) >>>>> >>>>> When errors.NotFound is raised, we are OK. When it is not raised, we have a >>>>> problem. >>>>> >>>>> Wouldn't it be simpler? >>>> >>>> No. Please do not do optimization here. It is a code that is called very >>>> rarely and expressiveness is more important here than optimizing access >>>> to couple of entries in LDAP. >>>> >>> >>> I am not optimizing - I am actually making the validation much simpler. What is >>> more simple and straightforward? >>> >>> A) One ldap.find_entries call >>> B) A loop, numerous subcommands and LDAP searches >> >> So far I've been successful in keeping details on how trust objects are >> represented in LDAP hidden from the rest of the framework code by >> encapsulating it all in trust.py. The change you propose will >> make it leaking to idrange.py. If we start changing the structure (which >> is maintained by ipasam module, not the framework), we will have more >> maintenance problems with the code spread out. > > Ok, I can see your point, but I am still not sure it warrants that complicated > validation and a new dependency between commands. You cannot that easily change > the structure of the subdomains anyway as it would break all older servers > which expect the subdomains to be where they are. > > In plugins, we do LDAP searches in cases like this one quite regularly IMO, it > is not something unprecendented. And there is a good reason, simple LDAP call > is much easier and less error prone to changes in our frameworks than calling > subcommands. One glitch or a change in the subcommand can break not only the > subcommand, but it's all callers. Note that you can encapsulate the search proposed by Martin in a function defined in trusts.py so it doesn't need to be implemented idrange.py. It is just a matter of finding the right name for it. -- Petr^2 Spacek From abokovoy at redhat.com Thu Mar 13 12:33:31 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Mar 2014 14:33:31 +0200 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range In-Reply-To: <5321A474.4070905@redhat.com> References: <53219A59.9060901@redhat.com> <53219BFD.1090803@redhat.com> <20140313120137.GM16644@redhat.com> <53219F34.2070209@redhat.com> <20140313121057.GN16644@redhat.com> <5321A28F.5040608@redhat.com> <5321A474.4070905@redhat.com> Message-ID: <20140313123331.GO16644@redhat.com> On Thu, 13 Mar 2014, Petr Spacek wrote: >On 13.3.2014 13:20, Martin Kosek wrote: >>On 03/13/2014 01:10 PM, Alexander Bokovoy wrote: >>>On Thu, 13 Mar 2014, Martin Kosek wrote: >>>>On 03/13/2014 01:01 PM, Alexander Bokovoy wrote: >>>>>On Thu, 13 Mar 2014, Martin Kosek wrote: >>>>>>On 03/13/2014 12:45 PM, Tomas Babej wrote: >>>>>>>Hi, >>>>>>> >>>>>>>Changes the code in the idrange_del method to not only check for >>>>>>>the root domains that match the SID in the IDRange, but for the >>>>>>>SIDs of subdomains of trusts as well. >>>>>>> >>>>>>>https://fedorahosted.org/freeipa/ticket/4247 >>>>>> >>>>>>This is a very complicated validation procedure IMO. Lot of subcommands, >>>>>>lot of >>>>>>LDAP searches. >>>>>> >>>>>>Why can't we do just one LDAP search with >>>>>>- base api.env.container_trusts >>>>>>- scope SUB >>>>>>- filter (&(objectclass=ipaNTTrustedDomain)(ipanttrusteddomainsid=range_sid)) >>>>>> >>>>>>When errors.NotFound is raised, we are OK. When it is not raised, we have a >>>>>>problem. >>>>>> >>>>>>Wouldn't it be simpler? >>>>> >>>>>No. Please do not do optimization here. It is a code that is called very >>>>>rarely and expressiveness is more important here than optimizing access >>>>>to couple of entries in LDAP. >>>>> >>>> >>>>I am not optimizing - I am actually making the validation much simpler. What is >>>>more simple and straightforward? >>>> >>>>A) One ldap.find_entries call >>>>B) A loop, numerous subcommands and LDAP searches >>> >>>So far I've been successful in keeping details on how trust objects are >>>represented in LDAP hidden from the rest of the framework code by >>>encapsulating it all in trust.py. The change you propose will >>>make it leaking to idrange.py. If we start changing the structure (which >>>is maintained by ipasam module, not the framework), we will have more >>>maintenance problems with the code spread out. >> >>Ok, I can see your point, but I am still not sure it warrants that complicated >>validation and a new dependency between commands. You cannot that easily change >>the structure of the subdomains anyway as it would break all older servers >>which expect the subdomains to be where they are. >> >>In plugins, we do LDAP searches in cases like this one quite regularly IMO, it >>is not something unprecendented. And there is a good reason, simple LDAP call >>is much easier and less error prone to changes in our frameworks than calling >>subcommands. One glitch or a change in the subcommand can break not only the >>subcommand, but it's all callers. > >Note that you can encapsulate the search proposed by Martin in a >function defined in trusts.py so it doesn't need to be implemented >idrange.py. > >It is just a matter of finding the right name for it. I wanted to propose that as well. We already have conditional import of ipaserver.dcerpc, we can use ipalibs.plugins.trust import for that helper, just don't export it through API. -- / Alexander Bokovoy From mkosek at redhat.com Thu Mar 13 12:36:48 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Mar 2014 13:36:48 +0100 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range In-Reply-To: <20140313123331.GO16644@redhat.com> References: <53219A59.9060901@redhat.com> <53219BFD.1090803@redhat.com> <20140313120137.GM16644@redhat.com> <53219F34.2070209@redhat.com> <20140313121057.GN16644@redhat.com> <5321A28F.5040608@redhat.com> <5321A474.4070905@redhat.com> <20140313123331.GO16644@redhat.com> Message-ID: <5321A660.2060200@redhat.com> On 03/13/2014 01:33 PM, Alexander Bokovoy wrote: > On Thu, 13 Mar 2014, Petr Spacek wrote: >> On 13.3.2014 13:20, Martin Kosek wrote: >>> On 03/13/2014 01:10 PM, Alexander Bokovoy wrote: >>>> On Thu, 13 Mar 2014, Martin Kosek wrote: >>>>> On 03/13/2014 01:01 PM, Alexander Bokovoy wrote: >>>>>> On Thu, 13 Mar 2014, Martin Kosek wrote: >>>>>>> On 03/13/2014 12:45 PM, Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Changes the code in the idrange_del method to not only check for >>>>>>>> the root domains that match the SID in the IDRange, but for the >>>>>>>> SIDs of subdomains of trusts as well. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4247 >>>>>>> >>>>>>> This is a very complicated validation procedure IMO. Lot of subcommands, >>>>>>> lot of >>>>>>> LDAP searches. >>>>>>> >>>>>>> Why can't we do just one LDAP search with >>>>>>> - base api.env.container_trusts >>>>>>> - scope SUB >>>>>>> - filter >>>>>>> (&(objectclass=ipaNTTrustedDomain)(ipanttrusteddomainsid=range_sid)) >>>>>>> >>>>>>> When errors.NotFound is raised, we are OK. When it is not raised, we have a >>>>>>> problem. >>>>>>> >>>>>>> Wouldn't it be simpler? >>>>>> >>>>>> No. Please do not do optimization here. It is a code that is called very >>>>>> rarely and expressiveness is more important here than optimizing access >>>>>> to couple of entries in LDAP. >>>>>> >>>>> >>>>> I am not optimizing - I am actually making the validation much simpler. >>>>> What is >>>>> more simple and straightforward? >>>>> >>>>> A) One ldap.find_entries call >>>>> B) A loop, numerous subcommands and LDAP searches >>>> >>>> So far I've been successful in keeping details on how trust objects are >>>> represented in LDAP hidden from the rest of the framework code by >>>> encapsulating it all in trust.py. The change you propose will >>>> make it leaking to idrange.py. If we start changing the structure (which >>>> is maintained by ipasam module, not the framework), we will have more >>>> maintenance problems with the code spread out. >>> >>> Ok, I can see your point, but I am still not sure it warrants that complicated >>> validation and a new dependency between commands. You cannot that easily change >>> the structure of the subdomains anyway as it would break all older servers >>> which expect the subdomains to be where they are. >>> >>> In plugins, we do LDAP searches in cases like this one quite regularly IMO, it >>> is not something unprecendented. And there is a good reason, simple LDAP call >>> is much easier and less error prone to changes in our frameworks than calling >>> subcommands. One glitch or a change in the subcommand can break not only the >>> subcommand, but it's all callers. >> >> Note that you can encapsulate the search proposed by Martin in a function >> defined in trusts.py so it doesn't need to be implemented idrange.py. >> >> It is just a matter of finding the right name for it. > I wanted to propose that as well. > > We already have conditional import of ipaserver.dcerpc, we can use > ipalibs.plugins.trust import for that helper, just don't export it > through API. > This may work as well, we just need to be cautious in the idrange plugin so that the idrange-del works even when ipa-server-trust-ad package is not installed on the system (which would probably break current patch too, when I am thinking about it). Martin From jcholast at redhat.com Thu Mar 13 12:41:31 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 13 Mar 2014 13:41:31 +0100 Subject: [Freeipa-devel] [PATCHES] 172-196 Refactor certificate renewal code In-Reply-To: <5320AE9B.6040303@redhat.com> References: <525FD641.20202@redhat.com> <526009D7.2040702@redhat.com> <5260175E.50809@redhat.com> <531DAA0F.9080300@redhat.com> <5320AE9B.6040303@redhat.com> Message-ID: <5321A77B.3090003@redhat.com> On 12.3.2014 19:59, Petr Viktorin wrote: > On 03/10/2014 01:03 PM, Jan Cholasta wrote: >> On 17.10.2013 18:59, Jan Cholasta wrote: >>> On 17.10.2013 18:01, Petr Viktorin wrote: >>>> On 10/17/2013 02:21 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> this patchset contains refactoring of the certificate renewal code, >>>>> which will be the base for CA certificate renewal. >>>>> >>>>> The biggest change is a new certmonger CA helper >>>>> dogtag-ipa-ca-renew-agent, which replaces >>>>> dogtag-ipa-retrieve-agent-submit as well as parts of certmonger >>>>> post-commands used in certificate renewal. It provides more >>>>> flexibility >>>>> when doing renewals and allows unified certmonger configuration on >>>>> both >>>>> CA master and clones. >>>>> >>>>> How to test: Test both CA-ful and CA-less server and replica installs >>>>> and upgrades, check that certmonger is configured properly and >>>>> certificate renewal works (see >>>>> https://fedorahosted.org/freeipa/ticket/2803#comment:17 for details). > > Certmonger is not configured/started in CA-less installs. That's expected. > > I tested fresh installs and upgrades; renewals work fine for me. > > 161-184 look OK > > 185: one more nitpick: > cert = entry['usercertificate'][0] > Shouldn't that use entry.single_value? I did not feel like changing this, because this is used in the original code and the userCertificate LDAP attribute is multi-value. > > 186-189 look OK > > 190: Is > fqdn = entries[0].dn[1].value > return api.env.host == fqdn > safe? Can they differ in case, for example? I guess so, will fix. > > 191-196 look OK > >> Note that patches 178 & 179 were already pushed. Also, patch 190 was >> changed to store information about which CA instance is master in LDAP. > > -- Jan Cholasta From mkosek at redhat.com Thu Mar 13 12:45:44 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Mar 2014 13:45:44 +0100 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range In-Reply-To: <5321A660.2060200@redhat.com> References: <53219A59.9060901@redhat.com> <53219BFD.1090803@redhat.com> <20140313120137.GM16644@redhat.com> <53219F34.2070209@redhat.com> <20140313121057.GN16644@redhat.com> <5321A28F.5040608@redhat.com> <5321A474.4070905@redhat.com> <20140313123331.GO16644@redhat.com> <5321A660.2060200@redhat.com> Message-ID: <5321A878.4080002@redhat.com> On 03/13/2014 01:36 PM, Martin Kosek wrote: > On 03/13/2014 01:33 PM, Alexander Bokovoy wrote: >> On Thu, 13 Mar 2014, Petr Spacek wrote: >>> On 13.3.2014 13:20, Martin Kosek wrote: >>>> On 03/13/2014 01:10 PM, Alexander Bokovoy wrote: >>>>> On Thu, 13 Mar 2014, Martin Kosek wrote: >>>>>> On 03/13/2014 01:01 PM, Alexander Bokovoy wrote: >>>>>>> On Thu, 13 Mar 2014, Martin Kosek wrote: >>>>>>>> On 03/13/2014 12:45 PM, Tomas Babej wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Changes the code in the idrange_del method to not only check for >>>>>>>>> the root domains that match the SID in the IDRange, but for the >>>>>>>>> SIDs of subdomains of trusts as well. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4247 >>>>>>>> >>>>>>>> This is a very complicated validation procedure IMO. Lot of subcommands, >>>>>>>> lot of >>>>>>>> LDAP searches. >>>>>>>> >>>>>>>> Why can't we do just one LDAP search with >>>>>>>> - base api.env.container_trusts >>>>>>>> - scope SUB >>>>>>>> - filter >>>>>>>> (&(objectclass=ipaNTTrustedDomain)(ipanttrusteddomainsid=range_sid)) >>>>>>>> >>>>>>>> When errors.NotFound is raised, we are OK. When it is not raised, we have a >>>>>>>> problem. >>>>>>>> >>>>>>>> Wouldn't it be simpler? >>>>>>> >>>>>>> No. Please do not do optimization here. It is a code that is called very >>>>>>> rarely and expressiveness is more important here than optimizing access >>>>>>> to couple of entries in LDAP. >>>>>>> >>>>>> >>>>>> I am not optimizing - I am actually making the validation much simpler. >>>>>> What is >>>>>> more simple and straightforward? >>>>>> >>>>>> A) One ldap.find_entries call >>>>>> B) A loop, numerous subcommands and LDAP searches >>>>> >>>>> So far I've been successful in keeping details on how trust objects are >>>>> represented in LDAP hidden from the rest of the framework code by >>>>> encapsulating it all in trust.py. The change you propose will >>>>> make it leaking to idrange.py. If we start changing the structure (which >>>>> is maintained by ipasam module, not the framework), we will have more >>>>> maintenance problems with the code spread out. >>>> >>>> Ok, I can see your point, but I am still not sure it warrants that complicated >>>> validation and a new dependency between commands. You cannot that easily change >>>> the structure of the subdomains anyway as it would break all older servers >>>> which expect the subdomains to be where they are. >>>> >>>> In plugins, we do LDAP searches in cases like this one quite regularly IMO, it >>>> is not something unprecendented. And there is a good reason, simple LDAP call >>>> is much easier and less error prone to changes in our frameworks than calling >>>> subcommands. One glitch or a change in the subcommand can break not only the >>>> subcommand, but it's all callers. >>> >>> Note that you can encapsulate the search proposed by Martin in a function >>> defined in trusts.py so it doesn't need to be implemented idrange.py. >>> >>> It is just a matter of finding the right name for it. >> I wanted to propose that as well. >> >> We already have conditional import of ipaserver.dcerpc, we can use >> ipalibs.plugins.trust import for that helper, just don't export it >> through API. >> > > This may work as well, we just need to be cautious in the idrange plugin so > that the idrange-del works even when ipa-server-trust-ad package is not > installed on the system (which would probably break current patch too, when I > am thinking about it). > > Martin I take it back - it is not so good idea. You may be running this command on a master without ipa-server-trust-ad installed, but which may be however installed on other IPA master and thus we do want to check for the trustdomains. We need to enclose this check to simple LDAP call in idrange.py as I said in the beginning. Martin From pviktori at redhat.com Thu Mar 13 12:46:50 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 13 Mar 2014 13:46:50 +0100 Subject: [Freeipa-devel] [PATCH] 0496 ipaserver.install.service: Fix estimated time display Message-ID: <5321A8BA.5090709@redhat.com> Hello, The time estimate display is broken, so I wrote a test for it. Also the bug should be fixed now. https://fedorahosted.org/freeipa/ticket/4242 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0496-ipaserver.install.service-Fix-estimated-time-display.patch Type: text/x-patch Size: 4478 bytes Desc: not available URL: From abokovoy at redhat.com Thu Mar 13 12:47:39 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Mar 2014 14:47:39 +0200 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range In-Reply-To: <5321A878.4080002@redhat.com> References: <53219A59.9060901@redhat.com> <53219BFD.1090803@redhat.com> <20140313120137.GM16644@redhat.com> <53219F34.2070209@redhat.com> <20140313121057.GN16644@redhat.com> <5321A28F.5040608@redhat.com> <5321A474.4070905@redhat.com> <20140313123331.GO16644@redhat.com> <5321A660.2060200@redhat.com> <5321A878.4080002@redhat.com> Message-ID: <20140313124739.GP16644@redhat.com> On Thu, 13 Mar 2014, Martin Kosek wrote: >On 03/13/2014 01:36 PM, Martin Kosek wrote: >> On 03/13/2014 01:33 PM, Alexander Bokovoy wrote: >>> On Thu, 13 Mar 2014, Petr Spacek wrote: >>>> On 13.3.2014 13:20, Martin Kosek wrote: >>>>> On 03/13/2014 01:10 PM, Alexander Bokovoy wrote: >>>>>> On Thu, 13 Mar 2014, Martin Kosek wrote: >>>>>>> On 03/13/2014 01:01 PM, Alexander Bokovoy wrote: >>>>>>>> On Thu, 13 Mar 2014, Martin Kosek wrote: >>>>>>>>> On 03/13/2014 12:45 PM, Tomas Babej wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Changes the code in the idrange_del method to not only check for >>>>>>>>>> the root domains that match the SID in the IDRange, but for the >>>>>>>>>> SIDs of subdomains of trusts as well. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4247 >>>>>>>>> >>>>>>>>> This is a very complicated validation procedure IMO. Lot of subcommands, >>>>>>>>> lot of >>>>>>>>> LDAP searches. >>>>>>>>> >>>>>>>>> Why can't we do just one LDAP search with >>>>>>>>> - base api.env.container_trusts >>>>>>>>> - scope SUB >>>>>>>>> - filter >>>>>>>>> (&(objectclass=ipaNTTrustedDomain)(ipanttrusteddomainsid=range_sid)) >>>>>>>>> >>>>>>>>> When errors.NotFound is raised, we are OK. When it is not raised, we have a >>>>>>>>> problem. >>>>>>>>> >>>>>>>>> Wouldn't it be simpler? >>>>>>>> >>>>>>>> No. Please do not do optimization here. It is a code that is called very >>>>>>>> rarely and expressiveness is more important here than optimizing access >>>>>>>> to couple of entries in LDAP. >>>>>>>> >>>>>>> >>>>>>> I am not optimizing - I am actually making the validation much simpler. >>>>>>> What is >>>>>>> more simple and straightforward? >>>>>>> >>>>>>> A) One ldap.find_entries call >>>>>>> B) A loop, numerous subcommands and LDAP searches >>>>>> >>>>>> So far I've been successful in keeping details on how trust objects are >>>>>> represented in LDAP hidden from the rest of the framework code by >>>>>> encapsulating it all in trust.py. The change you propose will >>>>>> make it leaking to idrange.py. If we start changing the structure (which >>>>>> is maintained by ipasam module, not the framework), we will have more >>>>>> maintenance problems with the code spread out. >>>>> >>>>> Ok, I can see your point, but I am still not sure it warrants that complicated >>>>> validation and a new dependency between commands. You cannot that easily change >>>>> the structure of the subdomains anyway as it would break all older servers >>>>> which expect the subdomains to be where they are. >>>>> >>>>> In plugins, we do LDAP searches in cases like this one quite regularly IMO, it >>>>> is not something unprecendented. And there is a good reason, simple LDAP call >>>>> is much easier and less error prone to changes in our frameworks than calling >>>>> subcommands. One glitch or a change in the subcommand can break not only the >>>>> subcommand, but it's all callers. >>>> >>>> Note that you can encapsulate the search proposed by Martin in a function >>>> defined in trusts.py so it doesn't need to be implemented idrange.py. >>>> >>>> It is just a matter of finding the right name for it. >>> I wanted to propose that as well. >>> >>> We already have conditional import of ipaserver.dcerpc, we can use >>> ipalibs.plugins.trust import for that helper, just don't export it >>> through API. >>> >> >> This may work as well, we just need to be cautious in the idrange plugin so >> that the idrange-del works even when ipa-server-trust-ad package is not >> installed on the system (which would probably break current patch too, when I >> am thinking about it). >> >> Martin > >I take it back - it is not so good idea. You may be running this command on a >master without ipa-server-trust-ad installed, but which may be however >installed on other IPA master and thus we do want to check for the trustdomains. > >We need to enclose this check to simple LDAP call in idrange.py as I said in >the beginning. Ok, this is an argument I agree with. Tomas, could you please change the code correspondingly? -- / Alexander Bokovoy From pviktori at redhat.com Thu Mar 13 13:01:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 13 Mar 2014 14:01:14 +0100 Subject: [Freeipa-devel] [PATCHES] 0473-0477+0497 Managed permission updater, part 1 In-Reply-To: <5319953E.708@redhat.com> References: <530DB78A.4040003@redhat.com> <53108B41.50700@redhat.com> <53109370.7010905@redhat.com> <53149B54.2050308@redhat.com> <53171D1D.2010408@redhat.com> <5319953E.708@redhat.com> Message-ID: <5321AC1A.70608@redhat.com> On 03/07/2014 10:45 AM, Martin Kosek wrote: > On 03/05/2014 01:48 PM, Petr Viktorin wrote: >> On 03/03/2014 04:10 PM, Petr Viktorin wrote: >>> On 02/28/2014 02:47 PM, Petr Viktorin wrote: >>>> On 02/28/2014 02:12 PM, Martin Kosek wrote: >>>>> On 02/26/2014 10:44 AM, Petr Viktorin wrote: >>>>>> Hello, >>>>>> Here are a few fixes/improvements, and the first part of a managed >>>>>> permission >>>>>> updater. >>>>>> >>>>>> The patches should go in this order but don't need to be ACKed/pushed >>>>>> all at once. >>>>>> >>>>>> >>>>>> Design: >>>>>> http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater >>>>>> >>>>>> >>>>>> >>>>>> Part of the work for: https://fedorahosted.org/freeipa/ticket/3566 >>>>>> >>>>>> >>>>>> This part is a "preview" of sorts, to get the basic mechanism and the >>>>>> metadata >>>>>> format reviewed before I add all of the default read permissions. >>>>>> It implements the first section of "Default Permission Updater" in >>>>>> the design; >>>>>> "Replacing legacy default permissions" and "Removing the global >>>>>> anonymous read >>>>>> ACI" is left for later. >>>>>> Metadata is added for the netgroup plugin* for starters >> [...] >>>>>> >>>>> >>>>> 1) 476: Typo in test name: >>>>> >>>>> + desc='Search fo rnonexisting permission with ":" in the >>>>> name', >>>> >>>> Will fix. >> >> Fixed >> >>>>> 2) 477: do we want to log anything when permission is up to date? >>>>> >>>>> + try: >>>>> + ldap.update_entry(entry) >>>>> + except errors.EmptyModlist: >>>>> + return >>>> >>>> I don't think that's needed, after all that's the expected behavior in >>>> all but the first upgrade. >>>> But I'll be happy to add it if you think it would be better. >> >> I've added a DEBUG message here. >> >> [...] >>>>> 4) I have been quite resilient to the prefixes for the permissions, >>>>> but it >>>>> seems it is the easier possible approach to fix conflicts with user >>>>> permissions >>>>> without having to check that later for every upgrade or doing more >>>>> complex >>>>> stuff like multiple RDNs or different container for system and user >>>>> permissions. >>>>> >>>>> I am now just thinking about the prefixing. Now you use this name: >>>>> >>>>> ipa:Read Netgroups >>>>> >>>>> Would it be "nicer" to use: >>>>> >>>>> IPA:Read Netgroups >>>>> or >>>>> IPA: Read Netgroups >>>>> or even >>>>> [IPA] Read Netgroups >>>>> ? :-) >>>> >>>> Bikeshedding time! >>>> Everyone on the list, please chime in! >>> >>> Bikeshedding results from today's meeting: >>> >>> "ipa: " pviktori++ >>> "System: " mkosek++ simo+ ab++ >>> "Builtin: " simo++ pvo+ >>> "Default:" >>> >>> The winner is "System: ", so I'll go and change to that. >> >> Done. > > Thanks. The patch set looks good now, I just see that the update process may > not be optimal After I run the upgrade second time, it still tries to update > the ACI even though there was no change done to the permission object and > should thus raise errors.EmptyModlist and skip the ACI update: > > 2014-03-07T09:44:34Z INFO Updating managed permissions for netgroup > 2014-03-07T09:44:34Z INFO Updating managed permission: System: Read Netgroups > 2014-03-07T09:44:34Z DEBUG Updating ACI for managed permission: System: Read > Netgroups > 2014-03-07T09:44:34Z DEBUG Removing ACI u'(targetattr = "cn || description || > hostcategory || ipaenabledflag || ipauniqueid || nisdomainname || > usercategory")(targetfilter = "(objectclass=ipanisnetgroup)")(version 3.0;acl > "permission:System: Read Netgroups";allow (read,compare,search) userdn = > "ldap:///all";)' from cn=ng,cn=alt,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > 2014-03-07T09:44:34Z DEBUG Adding ACI u'(targetattr = "cn || description || > hostcategory || ipaenabledflag || ipauniqueid || nisdomainname || > usercategory")(targetfilter = "(objectclass=ipanisnetgroup)")(version 3.0;acl > "permission:System: Read Netgroups";allow (read,compare,search) userdn = > "ldap:///all";)' to cn=ng,cn=alt,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com > 2014-03-07T09:44:34Z INFO No changes to ACI > 2014-03-07T09:44:34Z INFO Updating managed permission: System: Read Netgroup > Membership > > Any idea what could cause this? Ah, you're right. The updater tried to remove the 'top' objectclass, since it found that in the permission but it wasn't in permission.object_class. I added 'top' to the list in a new patch. There was a minor conflict with master; I'm attaching the whole rebased patchset for convenience. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0473.3-Allow-indexing-API-object-types-by-class.patch Type: text/x-patch Size: 4114 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0474.3-permission-find-Fix-handling-of-the-search-term-for-.patch Type: text/x-patch Size: 3667 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0475.3-test_permission_plugin-Fix-tests-that-make-too-broad.patch Type: text/x-patch Size: 6973 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0476.3-Allow-modifying-permissions-with-in-the-name.patch Type: text/x-patch Size: 11003 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0477.3-Add-Object-metadata-and-update-plugin-for-managed-pe.patch Type: text/x-patch Size: 9082 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0497.3-permission-plugin-Add-top-to-the-list-of-object-clas.patch Type: text/x-patch Size: 1502 bytes Desc: not available URL: From dpal at redhat.com Thu Mar 13 13:29:29 2014 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 13 Mar 2014 09:29:29 -0400 Subject: [Freeipa-devel] emerging standard for hosts/passwords policy/automount/netgroups in LDAP In-Reply-To: <53216F0A.9040105@redhat.com> References: <53216F0A.9040105@redhat.com> Message-ID: <5321B2B9.9030605@redhat.com> On 03/13/2014 04:40 AM, Petr Spacek wrote: > Hello list, > > FYI I have come across following RFC drafts: > > (please start with the first one :-) > http://www.ietf.org/id/draft-bannister-dbis-mapping-03.txt > http://tools.ietf.org/html/draft-bannister-dbis-passwd-02 > http://www.ietf.org/id/draft-bannister-dbis-policy-03.txt > http://tools.ietf.org/html/draft-bannister-dbis-netgroup-02 > http://tools.ietf.org/html/draft-bannister-dbis-automounter-02 > http://tools.ietf.org/html/draft-bannister-dbis-hosts-04 This is a bad idea to have hosts in LDAP. We already discussed it couple years ago. > > I didn't study them in detail but it seems like an attempt to > standardize Directory User Agent (DUA) profiles for various things > like automounter etc. > > Maybe we can contact the author and coordinate/harmonize what possible. +1 > > At first glance automount spec seems incompatible with RFC2307bis > schema, maybe that is one of things we can discuss and try to solve. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Thu Mar 13 13:41:52 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 13 Mar 2014 09:41:52 -0400 Subject: [Freeipa-devel] [PATCH] 0496 ipaserver.install.service: Fix estimated time display In-Reply-To: <5321A8BA.5090709@redhat.com> References: <5321A8BA.5090709@redhat.com> Message-ID: <5321B5A0.2090100@redhat.com> Petr Viktorin wrote: > Hello, > The time estimate display is broken, so I wrote a test for it. > Also the bug should be fixed now. > > https://fedorahosted.org/freeipa/ticket/4242 ACK From mkosek at redhat.com Thu Mar 13 14:15:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Mar 2014 15:15:25 +0100 Subject: [Freeipa-devel] [PATCH] 461 Update Dogtag 9 database during replica installation In-Reply-To: <532167B0.8080600@redhat.com> References: <532167B0.8080600@redhat.com> Message-ID: <5321BD7D.2000304@redhat.com> On 03/13/2014 09:09 AM, Martin Kosek wrote: > When Dogtag 10 based FreeIPA replica is being installed for a Dogtag 9 > based master, the PKI database is not updated and miss several ACLs > which prevent some of the PKI functions, e.g. an ability to create > other clones. > > Add an update file to do the database update. Content is based on > recommendation from PKI team: > * https://bugzilla.redhat.com/show_bug.cgi?id=1075118#c9 > > This update file can be removed when Dogtag database upgrades are done > in PKI component. Upstream tickets: > * https://fedorahosted.org/pki/ticket/710 (database upgrade framework) > * https://fedorahosted.org/pki/ticket/906 (checking database version) > > https://fedorahosted.org/freeipa/ticket/4243 I found few issues with the patch: - New update file was not added to Makefile.am - PKI was not restarted after LDAP updates so it did not pick up the ACLs and replica installation will crash anyway. Now the PKI is always restarted at the end of server/replica installation. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-461-2-update-dogtag-9-database-during-replica-installation.patch Type: text/x-patch Size: 5848 bytes Desc: not available URL: From rmeggins at redhat.com Thu Mar 13 14:20:33 2014 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 13 Mar 2014 08:20:33 -0600 Subject: [Freeipa-devel] LDAP Queue Length Control for better LDAP client performance? In-Reply-To: <53217584.4000904@redhat.com> References: <53217584.4000904@redhat.com> Message-ID: <5321BEB1.2090909@redhat.com> On 03/13/2014 03:08 AM, Petr Spacek wrote: > Hello list, > > my journey to the IETF wonderland revealed one more RFC draft: > > LDAP Queue Length Control > http://tools.ietf.org/html/draft-hollstein-queuelength-control-01 > > I have no idea if this can really improve LDAP client performance or > not but IMHO it is worth exploring it. > > Maybe only an IPA replica with thousands of SSSD clients could benefit > from it, I don't know. > > I have finally ran out of notes from yesterday so you don't need to > worry about more RFC drafts - today :-) > 389 allows you to turn on and off TCP Nagle (TCP_NODELAY) and TCP_CORK. Someone could try running different workloads with different settings for these to see if it makes a difference. From amisnyov at redhat.com Thu Mar 13 14:45:04 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Thu, 13 Mar 2014 15:45:04 +0100 Subject: [Freeipa-devel] [PATCH] 546 webui: Datetime parsing and formatting In-Reply-To: <5318695B.4080100@redhat.com> References: <530CCD58.5030403@redhat.com> <20140306130132.3813166b@unused-4-246.brq.redhat.com> <5318695B.4080100@redhat.com> Message-ID: <20140313154504.3fabb613@unused-4-246.brq.redhat.com> On Thu, 06 Mar 2014 13:26:03 +0100 Petr Vobornik wrote: > On 6.3.2014 13:01, Misnyovszki Adam wrote: > > On Tue, 25 Feb 2014 18:05:28 +0100 > > Petr Vobornik wrote: > > > >> prerequisite for patch 547, 548 > >> depends on tbabej's datetime patch > >> > >> this patch implements: > >> - output_formatter in field. It should be used in par with > >> formatter. Formatter serves for datasource->widget conversion, > >> output_formatter for widget->datasource format conversion. > >> - datetime module which parses/format strings in subset of ISO 8601 > >> and LDAP generalized time format to Date. > >> - utc formatter replaced with new datetime formatter > >> - datetime_validator introduced > >> - new datetime field, extension of text field, which by default > >> uses datetime formatter and validator > >> > >> Dojo was regenerated to include dojo/string module > >> > >> https://fedorahosted.org/freeipa/ticket/4194 > > > > Hi, > > these are the results of my review: > > - if incorrect number specified for any of the parts(ie 2013-01-01 > > 25:00:00), then it counts forward(result: 2013-01-02 01:00:00), > > does it supposed to work this way? at least some warning should be > > given to the user, that the date is incorrect(imho) > > It's standard behavior of JavaScript Date object's setUTCFullYear > method. I did not find better methods which would not require pulling > third-party lib or do real evaluation of the dates. > > In the end it's not that bad. > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/setUTCFullYear > > > - couldn't test non utc datetime input(no test cases in the ui yet), > > but other tests(integration and ui) passed which are connected to > > this issue > > Non UTC are not supported therefore it's disabled. But there are unit > tests in test/utils_tests.js > > > - validity fields accept non existing timeframe(ie start: 2013-01-01 > > 00:00:00Z, end: 2012-01-01 00:00:00Z) > > I don't think it's checked even on a server. Maybe it should be. > > > - validity fields only accept UTC time, it's good > > > > so besides that timeframe issue(which the api should handle i > > think), it's an ACK > > > > Be careful, it should be pushed to master with pvoborni's 531-541 > > and 546-548, wait for the review of those! > > > > Greets: > > Adam > > ACK, can push to master. Adam From mkosek at redhat.com Thu Mar 13 14:53:26 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Mar 2014 15:53:26 +0100 Subject: [Freeipa-devel] [PATCH] 0235 tests: Use ipa-getkeytab from /usr/sbin instead of the in-tree one In-Reply-To: <531739E3.1080603@redhat.com> References: <51ADD407.6020100@redhat.com> <1370350403.2744.15.camel@willson.li.ssimo.org> <51AE06A5.4030301@redhat.com> <1370360902.2744.40.camel@willson.li.ssimo.org> <5241B121.6090203@redhat.com> <531739E3.1080603@redhat.com> Message-ID: <5321C666.4010104@redhat.com> On 03/05/2014 03:51 PM, Petr Viktorin wrote: > On 09/24/2013 05:34 PM, Petr Viktorin wrote: >> On 06/04/2013 05:48 PM, Simo Sorce wrote: >>> On Tue, 2013-06-04 at 17:24 +0200, Petr Viktorin wrote: >>>> On 06/04/2013 02:53 PM, Simo Sorce wrote: >>>>> On Tue, 2013-06-04 at 13:48 +0200, Petr Viktorin wrote: >>>>>> Hardcoding the in-tree location for ipa-getkeytab makes testing >>>>>> outside >>>>>> the source tree impossible. This patch makes the tests use the >>>>>> installed >>>>>> location. >>>>>> >>>>>> In other places the test suite assumes IPA is installed system-wide, >>>>>> even if running from the source tree. >>>>>> I know I frequently forget to run `make` before testing, which >>>>>> makes the >>>>>> ipa-getkeytab tests fail. So this patch would work well for me (and >>>>>> probably other Python devs), but I guess others might be used to `make >>>>>> test` checking what `make` built. >>>>>> >>>>>> C developers, are you OK with e.g. adding `cp ipa-client/ipa-getkeytab >>>>>> /usr/sbin/ipa-getkeytab` to your testing workflow? >>>>> >>>>> Absolutely not. >>>>> >>>>>> Or should this be made configurable (or auto-detected)? >>>>> >>>>> You must not break a machine just to do make test. >>>>> >>>>> I often do make test, then make rpms and install rpms, I *never* >>>>> directly install on my development machine or VMs, I always go through >>>>> RPM in order to keep the system clean, and tests repeatable. >>>> >>>> I do the same except I never run make test on the development machine -- >>>> without IPA installed the tests don't work. >>>> >>>>> ipa-getkeytab specifically do not need root to be tested so I really do >>>>> not see that copying over a system path would ever be a good idea. >>>>> >>>>> Simo. >>>> >>>> >>>> With this version of the patch, the tests use ipa-getkeytab from $PATH, >>>> and the in-tree directory is added to PATH in make-test. Out-of-tree >>>> tests don't use make-test so they will use the system PATH. >>>> Is that OK? >>>> >>> >>> Sounds good to me. >>> >>> Simo. >>> >> >> Ping, could someone look at this patch? >> It should fix 7 of the 11 failures that happen when running the test >> suite out of tree. >> > > Attaching a slightly updated version. Any takers? Fixed the test failures for me. It should also help our CI to remove some more common failures - ACK. Pushed to master: 05f612e58a4954162dcaa724585869819ca77672 Martin From pviktori at redhat.com Thu Mar 13 15:00:43 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 13 Mar 2014 16:00:43 +0100 Subject: [Freeipa-devel] [PATCH] 546 webui: Datetime parsing and formatting In-Reply-To: <20140313154504.3fabb613@unused-4-246.brq.redhat.com> References: <530CCD58.5030403@redhat.com> <20140306130132.3813166b@unused-4-246.brq.redhat.com> <5318695B.4080100@redhat.com> <20140313154504.3fabb613@unused-4-246.brq.redhat.com> Message-ID: <5321C81B.10808@redhat.com> On 03/13/2014 03:45 PM, Misnyovszki Adam wrote: > On Thu, 06 Mar 2014 13:26:03 +0100 > Petr Vobornik wrote: > >> On 6.3.2014 13:01, Misnyovszki Adam wrote: >>> On Tue, 25 Feb 2014 18:05:28 +0100 >>> Petr Vobornik wrote: >>> >>>> prerequisite for patch 547, 548 >>>> depends on tbabej's datetime patch >>>> >>>> this patch implements: >>>> - output_formatter in field. It should be used in par with >>>> formatter. Formatter serves for datasource->widget conversion, >>>> output_formatter for widget->datasource format conversion. >>>> - datetime module which parses/format strings in subset of ISO 8601 >>>> and LDAP generalized time format to Date. >>>> - utc formatter replaced with new datetime formatter >>>> - datetime_validator introduced >>>> - new datetime field, extension of text field, which by default >>>> uses datetime formatter and validator >>>> >>>> Dojo was regenerated to include dojo/string module >>>> >>>> https://fedorahosted.org/freeipa/ticket/4194 >>> >>> Hi, >>> these are the results of my review: >>> - if incorrect number specified for any of the parts(ie 2013-01-01 >>> 25:00:00), then it counts forward(result: 2013-01-02 01:00:00), >>> does it supposed to work this way? at least some warning should be >>> given to the user, that the date is incorrect(imho) >> >> It's standard behavior of JavaScript Date object's setUTCFullYear >> method. I did not find better methods which would not require pulling >> third-party lib or do real evaluation of the dates. >> >> In the end it's not that bad. >> >> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/setUTCFullYear >> >>> - couldn't test non utc datetime input(no test cases in the ui yet), >>> but other tests(integration and ui) passed which are connected to >>> this issue >> >> Non UTC are not supported therefore it's disabled. But there are unit >> tests in test/utils_tests.js >> >>> - validity fields accept non existing timeframe(ie start: 2013-01-01 >>> 00:00:00Z, end: 2012-01-01 00:00:00Z) >> >> I don't think it's checked even on a server. Maybe it should be. >> >>> - validity fields only accept UTC time, it's good >>> >>> so besides that timeframe issue(which the api should handle i >>> think), it's an ACK >>> >>> Be careful, it should be pushed to master with pvoborni's 531-541 >>> and 546-548, wait for the review of those! >>> >>> Greets: >>> Adam >> >> > > > ACK, > can push to master. > Adam Pushed to master: 870a5daf24c165069fe6f546bb3710f9b3880538 -- Petr? From amisnyov at redhat.com Thu Mar 13 15:13:52 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Thu, 13 Mar 2014 16:13:52 +0100 Subject: [Freeipa-devel] [PATCH] 548 webui: change ipatokennotbefore and ipatokennotafter types to datetime In-Reply-To: <530CCE75.7010808@redhat.com> References: <530CCE75.7010808@redhat.com> Message-ID: <20140313161352.5d432865@unused-4-246.brq.redhat.com> On Tue, 25 Feb 2014 18:10:13 +0100 Petr Vobornik wrote: > Depends on tbabej's patches # 137, 140 and pvoborni's 546 and 531-541. > > https://fedorahosted.org/freeipa/ticket/3369 ACK From tbabej at redhat.com Thu Mar 13 15:28:53 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 13 Mar 2014 16:28:53 +0100 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range In-Reply-To: <20140313124739.GP16644@redhat.com> References: <53219A59.9060901@redhat.com> <53219BFD.1090803@redhat.com> <20140313120137.GM16644@redhat.com> <53219F34.2070209@redhat.com> <20140313121057.GN16644@redhat.com> <5321A28F.5040608@redhat.com> <5321A474.4070905@redhat.com> <20140313123331.GO16644@redhat.com> <5321A660.2060200@redhat.com> <5321A878.4080002@redhat.com> <20140313124739.GP16644@redhat.com> Message-ID: <5321CEB5.5070404@redhat.com> On 03/13/2014 01:47 PM, Alexander Bokovoy wrote: > On Thu, 13 Mar 2014, Martin Kosek wrote: >> On 03/13/2014 01:36 PM, Martin Kosek wrote: >>> On 03/13/2014 01:33 PM, Alexander Bokovoy wrote: >>>> On Thu, 13 Mar 2014, Petr Spacek wrote: >>>>> On 13.3.2014 13:20, Martin Kosek wrote: >>>>>> On 03/13/2014 01:10 PM, Alexander Bokovoy wrote: >>>>>>> On Thu, 13 Mar 2014, Martin Kosek wrote: >>>>>>>> On 03/13/2014 01:01 PM, Alexander Bokovoy wrote: >>>>>>>>> On Thu, 13 Mar 2014, Martin Kosek wrote: >>>>>>>>>> On 03/13/2014 12:45 PM, Tomas Babej wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Changes the code in the idrange_del method to not only check >>>>>>>>>>> for >>>>>>>>>>> the root domains that match the SID in the IDRange, but for the >>>>>>>>>>> SIDs of subdomains of trusts as well. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4247 >>>>>>>>>> >>>>>>>>>> This is a very complicated validation procedure IMO. Lot of >>>>>>>>>> subcommands, >>>>>>>>>> lot of >>>>>>>>>> LDAP searches. >>>>>>>>>> >>>>>>>>>> Why can't we do just one LDAP search with >>>>>>>>>> - base api.env.container_trusts >>>>>>>>>> - scope SUB >>>>>>>>>> - filter >>>>>>>>>> (&(objectclass=ipaNTTrustedDomain)(ipanttrusteddomainsid=range_sid)) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> When errors.NotFound is raised, we are OK. When it is not >>>>>>>>>> raised, we have a >>>>>>>>>> problem. >>>>>>>>>> >>>>>>>>>> Wouldn't it be simpler? >>>>>>>>> >>>>>>>>> No. Please do not do optimization here. It is a code that is >>>>>>>>> called very >>>>>>>>> rarely and expressiveness is more important here than >>>>>>>>> optimizing access >>>>>>>>> to couple of entries in LDAP. >>>>>>>>> >>>>>>>> >>>>>>>> I am not optimizing - I am actually making the validation much >>>>>>>> simpler. >>>>>>>> What is >>>>>>>> more simple and straightforward? >>>>>>>> >>>>>>>> A) One ldap.find_entries call >>>>>>>> B) A loop, numerous subcommands and LDAP searches >>>>>>> >>>>>>> So far I've been successful in keeping details on how trust >>>>>>> objects are >>>>>>> represented in LDAP hidden from the rest of the framework code by >>>>>>> encapsulating it all in trust.py. The change you propose will >>>>>>> make it leaking to idrange.py. If we start changing the >>>>>>> structure (which >>>>>>> is maintained by ipasam module, not the framework), we will have >>>>>>> more >>>>>>> maintenance problems with the code spread out. >>>>>> >>>>>> Ok, I can see your point, but I am still not sure it warrants >>>>>> that complicated >>>>>> validation and a new dependency between commands. You cannot that >>>>>> easily change >>>>>> the structure of the subdomains anyway as it would break all >>>>>> older servers >>>>>> which expect the subdomains to be where they are. >>>>>> >>>>>> In plugins, we do LDAP searches in cases like this one quite >>>>>> regularly IMO, it >>>>>> is not something unprecendented. And there is a good reason, >>>>>> simple LDAP call >>>>>> is much easier and less error prone to changes in our frameworks >>>>>> than calling >>>>>> subcommands. One glitch or a change in the subcommand can break >>>>>> not only the >>>>>> subcommand, but it's all callers. >>>>> >>>>> Note that you can encapsulate the search proposed by Martin in a >>>>> function >>>>> defined in trusts.py so it doesn't need to be implemented idrange.py. >>>>> >>>>> It is just a matter of finding the right name for it. >>>> I wanted to propose that as well. >>>> >>>> We already have conditional import of ipaserver.dcerpc, we can use >>>> ipalibs.plugins.trust import for that helper, just don't export it >>>> through API. >>>> >>> >>> This may work as well, we just need to be cautious in the idrange >>> plugin so >>> that the idrange-del works even when ipa-server-trust-ad package is not >>> installed on the system (which would probably break current patch >>> too, when I >>> am thinking about it). >>> >>> Martin >> >> I take it back - it is not so good idea. You may be running this >> command on a >> master without ipa-server-trust-ad installed, but which may be however >> installed on other IPA master and thus we do want to check for the >> trustdomains. >> >> We need to enclose this check to simple LDAP call in idrange.py as I >> said in >> the beginning. > Ok, this is an argument I agree with. > > Tomas, could you please change the code correspondingly? Sure. Here is the updated patch. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0157-2-Prohibit-deletion-of-active-subdomain-range.patch Type: text/x-patch Size: 2065 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 13 15:40:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Mar 2014 16:40:23 +0100 Subject: [Freeipa-devel] [PATCH] 461 Update Dogtag 9 database during replica installation In-Reply-To: <5321BD7D.2000304@redhat.com> References: <532167B0.8080600@redhat.com> <5321BD7D.2000304@redhat.com> Message-ID: <5321D167.2080201@redhat.com> On 03/13/2014 03:15 PM, Martin Kosek wrote: > On 03/13/2014 09:09 AM, Martin Kosek wrote: >> When Dogtag 10 based FreeIPA replica is being installed for a Dogtag 9 >> based master, the PKI database is not updated and miss several ACLs >> which prevent some of the PKI functions, e.g. an ability to create >> other clones. >> >> Add an update file to do the database update. Content is based on >> recommendation from PKI team: >> * https://bugzilla.redhat.com/show_bug.cgi?id=1075118#c9 >> >> This update file can be removed when Dogtag database upgrades are done >> in PKI component. Upstream tickets: >> * https://fedorahosted.org/pki/ticket/710 (database upgrade framework) >> * https://fedorahosted.org/pki/ticket/906 (checking database version) >> >> https://fedorahosted.org/freeipa/ticket/4243 > > I found few issues with the patch: > - New update file was not added to Makefile.am > - PKI was not restarted after LDAP updates so it did not pick up the ACLs and > replica installation will crash anyway. Now the PKI is always restarted at the > end of server/replica installation. > > Martin FYI - I was just confirmed that this patch finally fixed the issue even in automatized environment (beaker). Martin From pvoborni at redhat.com Thu Mar 13 15:55:53 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 13 Mar 2014 16:55:53 +0100 Subject: [Freeipa-devel] [PATCH] 550 webui-css: improve radio, checkbox keyboard support and color In-Reply-To: <5319D8F7.7080304@redhat.com> References: <5319D8F7.7080304@redhat.com> Message-ID: <5321D509.1020004@redhat.com> On 7.3.2014 15:34, Petr Vobornik wrote: > checkboxes and radio buttons: > - do not change color on hover when disabled > - are focusable and checkable by keyboard again. This uses a little > trick where the real checkbox is hidden under the artificial > checkbox. That way it has the same position and therefore it > works even in containers with overflow set. > > https://fedorahosted.org/freeipa/ticket/4217 > Self-NACK. Breaks Automount Key deletion in ipa/ui/#/e/automountmap/keys/ -- Petr Vobornik From tbabej at redhat.com Thu Mar 13 15:58:04 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 13 Mar 2014 16:58:04 +0100 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range In-Reply-To: <5321CEB5.5070404@redhat.com> References: <53219A59.9060901@redhat.com> <53219BFD.1090803@redhat.com> <20140313120137.GM16644@redhat.com> <53219F34.2070209@redhat.com> <20140313121057.GN16644@redhat.com> <5321A28F.5040608@redhat.com> <5321A474.4070905@redhat.com> <20140313123331.GO16644@redhat.com> <5321A660.2060200@redhat.com> <5321A878.4080002@redhat.com> <20140313124739.GP16644@redhat.com> <5321CEB5.5070404@redhat.com> Message-ID: <5321D58C.108@redhat.com> On 03/13/2014 04:28 PM, Tomas Babej wrote: > On 03/13/2014 01:47 PM, Alexander Bokovoy wrote: >> On Thu, 13 Mar 2014, Martin Kosek wrote: >>> On 03/13/2014 01:36 PM, Martin Kosek wrote: >>>> On 03/13/2014 01:33 PM, Alexander Bokovoy wrote: >>>>> On Thu, 13 Mar 2014, Petr Spacek wrote: >>>>>> On 13.3.2014 13:20, Martin Kosek wrote: >>>>>>> On 03/13/2014 01:10 PM, Alexander Bokovoy wrote: >>>>>>>> On Thu, 13 Mar 2014, Martin Kosek wrote: >>>>>>>>> On 03/13/2014 01:01 PM, Alexander Bokovoy wrote: >>>>>>>>>> On Thu, 13 Mar 2014, Martin Kosek wrote: >>>>>>>>>>> On 03/13/2014 12:45 PM, Tomas Babej wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Changes the code in the idrange_del method to not only check >>>>>>>>>>>> for >>>>>>>>>>>> the root domains that match the SID in the IDRange, but for the >>>>>>>>>>>> SIDs of subdomains of trusts as well. >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4247 >>>>>>>>>>> This is a very complicated validation procedure IMO. Lot of >>>>>>>>>>> subcommands, >>>>>>>>>>> lot of >>>>>>>>>>> LDAP searches. >>>>>>>>>>> >>>>>>>>>>> Why can't we do just one LDAP search with >>>>>>>>>>> - base api.env.container_trusts >>>>>>>>>>> - scope SUB >>>>>>>>>>> - filter >>>>>>>>>>> (&(objectclass=ipaNTTrustedDomain)(ipanttrusteddomainsid=range_sid)) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> When errors.NotFound is raised, we are OK. When it is not >>>>>>>>>>> raised, we have a >>>>>>>>>>> problem. >>>>>>>>>>> >>>>>>>>>>> Wouldn't it be simpler? >>>>>>>>>> No. Please do not do optimization here. It is a code that is >>>>>>>>>> called very >>>>>>>>>> rarely and expressiveness is more important here than >>>>>>>>>> optimizing access >>>>>>>>>> to couple of entries in LDAP. >>>>>>>>>> >>>>>>>>> I am not optimizing - I am actually making the validation much >>>>>>>>> simpler. >>>>>>>>> What is >>>>>>>>> more simple and straightforward? >>>>>>>>> >>>>>>>>> A) One ldap.find_entries call >>>>>>>>> B) A loop, numerous subcommands and LDAP searches >>>>>>>> So far I've been successful in keeping details on how trust >>>>>>>> objects are >>>>>>>> represented in LDAP hidden from the rest of the framework code by >>>>>>>> encapsulating it all in trust.py. The change you propose will >>>>>>>> make it leaking to idrange.py. If we start changing the >>>>>>>> structure (which >>>>>>>> is maintained by ipasam module, not the framework), we will have >>>>>>>> more >>>>>>>> maintenance problems with the code spread out. >>>>>>> Ok, I can see your point, but I am still not sure it warrants >>>>>>> that complicated >>>>>>> validation and a new dependency between commands. You cannot that >>>>>>> easily change >>>>>>> the structure of the subdomains anyway as it would break all >>>>>>> older servers >>>>>>> which expect the subdomains to be where they are. >>>>>>> >>>>>>> In plugins, we do LDAP searches in cases like this one quite >>>>>>> regularly IMO, it >>>>>>> is not something unprecendented. And there is a good reason, >>>>>>> simple LDAP call >>>>>>> is much easier and less error prone to changes in our frameworks >>>>>>> than calling >>>>>>> subcommands. One glitch or a change in the subcommand can break >>>>>>> not only the >>>>>>> subcommand, but it's all callers. >>>>>> Note that you can encapsulate the search proposed by Martin in a >>>>>> function >>>>>> defined in trusts.py so it doesn't need to be implemented idrange.py. >>>>>> >>>>>> It is just a matter of finding the right name for it. >>>>> I wanted to propose that as well. >>>>> >>>>> We already have conditional import of ipaserver.dcerpc, we can use >>>>> ipalibs.plugins.trust import for that helper, just don't export it >>>>> through API. >>>>> >>>> This may work as well, we just need to be cautious in the idrange >>>> plugin so >>>> that the idrange-del works even when ipa-server-trust-ad package is not >>>> installed on the system (which would probably break current patch >>>> too, when I >>>> am thinking about it). >>>> >>>> Martin >>> I take it back - it is not so good idea. You may be running this >>> command on a >>> master without ipa-server-trust-ad installed, but which may be however >>> installed on other IPA master and thus we do want to check for the >>> trustdomains. >>> >>> We need to enclose this check to simple LDAP call in idrange.py as I >>> said in >>> the beginning. >> Ok, this is an argument I agree with. >> >> Tomas, could you please change the code correspondingly? > Sure. Here is the updated patch. > Slightly improved patch with better control flow. Thanks for the reviews. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0157-3-Prohibit-deletion-of-active-subdomain-range.patch Type: text/x-patch Size: 2081 bytes Desc: not available URL: From abokovoy at redhat.com Thu Mar 13 16:11:08 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 13 Mar 2014 18:11:08 +0200 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range In-Reply-To: <5321D58C.108@redhat.com> References: <53219F34.2070209@redhat.com> <20140313121057.GN16644@redhat.com> <5321A28F.5040608@redhat.com> <5321A474.4070905@redhat.com> <20140313123331.GO16644@redhat.com> <5321A660.2060200@redhat.com> <5321A878.4080002@redhat.com> <20140313124739.GP16644@redhat.com> <5321CEB5.5070404@redhat.com> <5321D58C.108@redhat.com> Message-ID: <20140313161108.GQ16644@redhat.com> On Thu, 13 Mar 2014, Tomas Babej wrote: >>> >>> Tomas, could you please change the code correspondingly? >> Sure. Here is the updated patch. >> >Slightly improved patch with better control flow. Thanks for the reviews. > >-- >Tomas Babej >Associate Software Engeneer | Red Hat | Identity Management >RHCE | Brno Site | IRC: tbabej | freeipa.org > >From 31362721d8477fc6c44341edd34c3335d881613d Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Thu, 13 Mar 2014 12:36:17 +0100 >Subject: [PATCH] Prohibit deletion of active subdomain range > >Changes the code in the idrange_del method to not only check for >the root domains that match the SID in the IDRange, but for the >SIDs of subdomains of trusts as well. > >https://fedorahosted.org/freeipa/ticket/4247 >--- > ipalib/plugins/idrange.py | 20 ++++++++++++++++---- > 1 file changed, 16 insertions(+), 4 deletions(-) > >diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py >index 3a92d9898cc03f517b0f2bb75093eeb741cff646..91d8525dbc0c5a294e3d2782c58ef14af2d5a972 100644 >--- a/ipalib/plugins/idrange.py >+++ b/ipalib/plugins/idrange.py >@@ -567,14 +567,26 @@ class idrange_del(LDAPDelete): > range_sid = old_attrs.get('ipanttrusteddomainsid') > > if range_sid is not None: >+ # Search for trusted domain with SID specified in the ID range entry > range_sid = range_sid[0] >- result = api.Command['trust_find'](ipanttrusteddomainsid=range_sid) >+ domain_filter=('(&(objectclass=ipaNTTrustedDomain)' >+ '(ipanttrusteddomainsid=%s))' % range_sid) > >- if result['count'] > 0: >+ try: >+ (trust_domains, truncated) = ldap.find_entries( >+ base_dn=DN(api.env.container_trusts, api.env.basedn), >+ filter=domain_filter) >+ except errors.NotFound: >+ pass >+ else: >+ # If there's an entry, it means that there's active domain >+ # of a trust that this range belongs to, so raise a >+ # DependentEntry error > raise errors.DependentEntry( >- label='Active Trust', >+ label='Active Trust domain', > key=keys[0], >- dependent=result['result'][0]['cn'][0]) >+ dependent=trust_domains[0].dn[0].value) >+ > > return dn > ACK now. -- / Alexander Bokovoy From pviktori at redhat.com Thu Mar 13 17:12:54 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 13 Mar 2014 18:12:54 +0100 Subject: [Freeipa-devel] [PATCH 0157] Prohibit deletion of active subdomain range In-Reply-To: <20140313161108.GQ16644@redhat.com> References: <53219F34.2070209@redhat.com> <20140313121057.GN16644@redhat.com> <5321A28F.5040608@redhat.com> <5321A474.4070905@redhat.com> <20140313123331.GO16644@redhat.com> <5321A660.2060200@redhat.com> <5321A878.4080002@redhat.com> <20140313124739.GP16644@redhat.com> <5321CEB5.5070404@redhat.com> <5321D58C.108@redhat.com> <20140313161108.GQ16644@redhat.com> Message-ID: <5321E716.8050103@redhat.com> On 03/13/2014 05:11 PM, Alexander Bokovoy wrote: > On Thu, 13 Mar 2014, Tomas Babej wrote: >>>> >>>> Tomas, could you please change the code correspondingly? >>> Sure. Here is the updated patch. >>> >> Slightly improved patch with better control flow. Thanks for the reviews. >> >> -- >> Tomas Babej >> Associate Software Engeneer | Red Hat | Identity Management >> RHCE | Brno Site | IRC: tbabej | freeipa.org >> > >> From 31362721d8477fc6c44341edd34c3335d881613d Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Thu, 13 Mar 2014 12:36:17 +0100 >> Subject: [PATCH] Prohibit deletion of active subdomain range >> >> Changes the code in the idrange_del method to not only check for >> the root domains that match the SID in the IDRange, but for the >> SIDs of subdomains of trusts as well. >> >> https://fedorahosted.org/freeipa/ticket/4247 >> --- >> ipalib/plugins/idrange.py | 20 ++++++++++++++++---- >> 1 file changed, 16 insertions(+), 4 deletions(-) >> >> diff --git a/ipalib/plugins/idrange.py b/ipalib/plugins/idrange.py >> index >> 3a92d9898cc03f517b0f2bb75093eeb741cff646..91d8525dbc0c5a294e3d2782c58ef14af2d5a972 >> 100644 >> --- a/ipalib/plugins/idrange.py >> +++ b/ipalib/plugins/idrange.py >> @@ -567,14 +567,26 @@ class idrange_del(LDAPDelete): >> range_sid = old_attrs.get('ipanttrusteddomainsid') >> >> if range_sid is not None: >> + # Search for trusted domain with SID specified in the ID >> range entry >> range_sid = range_sid[0] >> - result = >> api.Command['trust_find'](ipanttrusteddomainsid=range_sid) >> + domain_filter=('(&(objectclass=ipaNTTrustedDomain)' >> + '(ipanttrusteddomainsid=%s))' % range_sid) >> >> - if result['count'] > 0: >> + try: >> + (trust_domains, truncated) = ldap.find_entries( >> + base_dn=DN(api.env.container_trusts, >> api.env.basedn), >> + filter=domain_filter) >> + except errors.NotFound: >> + pass >> + else: >> + # If there's an entry, it means that there's active >> domain >> + # of a trust that this range belongs to, so raise a >> + # DependentEntry error >> raise errors.DependentEntry( >> - label='Active Trust', >> + label='Active Trust domain', >> key=keys[0], >> - dependent=result['result'][0]['cn'][0]) >> + dependent=trust_domains[0].dn[0].value) >> + >> >> return dn >> > > ACK now. Pushed to: master: 62426970b7b2abd7941ce5df1f1f0e5554ec5a7d ipa-3-3: 8e7b209ed2f7f82bd9dee75a23cc867a3b69a9a8 -- Petr? From pviktori at redhat.com Thu Mar 13 17:16:02 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 13 Mar 2014 18:16:02 +0100 Subject: [Freeipa-devel] [PATCH] 0496 ipaserver.install.service: Fix estimated time display In-Reply-To: <5321B5A0.2090100@redhat.com> References: <5321A8BA.5090709@redhat.com> <5321B5A0.2090100@redhat.com> Message-ID: <5321E7D2.30309@redhat.com> On 03/13/2014 02:41 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> Hello, >> The time estimate display is broken, so I wrote a test for it. >> Also the bug should be fixed now. >> >> https://fedorahosted.org/freeipa/ticket/4242 > > ACK > Pushed to master: 7c9fa8fad96c039b96939f8df8d740ad6b50eec9 -- Petr? From simo at redhat.com Thu Mar 13 17:24:26 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 13 Mar 2014 13:24:26 -0400 Subject: [Freeipa-devel] emerging standard for hosts/passwords policy/automount/netgroups in LDAP In-Reply-To: <53216F0A.9040105@redhat.com> References: <53216F0A.9040105@redhat.com> Message-ID: <1394731466.32465.233.camel@willson.li.ssimo.org> On Thu, 2014-03-13 at 09:40 +0100, Petr Spacek wrote: > Hello list, > > FYI I have come across following RFC drafts: > > (please start with the first one :-) > http://www.ietf.org/id/draft-bannister-dbis-mapping-03.txt > http://tools.ietf.org/html/draft-bannister-dbis-passwd-02 > http://www.ietf.org/id/draft-bannister-dbis-policy-03.txt > http://tools.ietf.org/html/draft-bannister-dbis-netgroup-02 > http://tools.ietf.org/html/draft-bannister-dbis-automounter-02 > http://tools.ietf.org/html/draft-bannister-dbis-hosts-04 > > I didn't study them in detail but it seems like an attempt to standardize > Directory User Agent (DUA) profiles for various things like automounter etc. > > Maybe we can contact the author and coordinate/harmonize what possible. > > At first glance automount spec seems incompatible with RFC2307bis schema, > maybe that is one of things we can discuss and try to solve. > I've had a somewhat heated discussion on the relevant IETF list with the author. Let's say we do not agree on many things, feel free to read archives on ldapext mailing list :-) The discussion petered out a while ago. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Thu Mar 13 17:26:03 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 13 Mar 2014 18:26:03 +0100 Subject: [Freeipa-devel] [PATCHES] 0489-0495 Add the extratargetfilter virtual attribute to permissions In-Reply-To: <531DEAF2.9090506@redhat.com> References: <531A167F.7010302@redhat.com> <531DEAF2.9090506@redhat.com> Message-ID: <5321EA2B.1030902@redhat.com> On 03/10/2014 05:40 PM, Petr Viktorin wrote: > On 03/07/2014 07:57 PM, Petr Viktorin wrote: >> Hello, >> This implements https://fedorahosted.org/freeipa/ticket/4216 >> >> It feels like permissions have gone full circle, from being managed by >> virtual attributes, to storing all data in LDAP and exposing that, to >> exposing mainly virtual attributes after all. The good part is that the >> virtual attributes are now just a layer on top of well-structured LDAP >> entries. >> >> >> To the point: extratargetfilter lists all target filters that are not >> implied by --memberof or --user. The list is writable; changing it will >> preserve the implied filters. By default the full underlying list is not >> shown, you can use --all or --raw for that. >> In CLI, extratargetfilter is now named simply --filter, and the >> underlying ipapermtargetfilter is named --rawfilter. >> >> There are still some cases where the illusion is not complete: >> >> - When searching, extratargetfilter and ipapermtargetfilter behave the >> same, they search the full list. >> >> - When adding a filter that matches the requirements for --memberof or >> --type, the filter will be "used" for that option instead: >> >> $ ipa permission-add testperm --type user --perm write >> --filter='(memberOf=cn=admins,cn=groups,cn=accounts,$SUFFIX)' >> --------------------------- >> Added permission "testperm" >> --------------------------- >> Permission name: testperm >> Permissions: write >> Bind rule type: permission >> Subtree: cn=users,cn=accounts,$SUFFIX >> Member of group: admins >> Type: user >> >> >> >> Patches: >> >> 0489 - Outputting extratargetfilter >> 0490 - Writing extratargetfilter >> 0491 - CLI names for the options >> 0492 - Tests for the above >> 0493 - Searching by extratargetfilter >> 0494 - Fix an existing bug in --memberof >> 0495 - This uses the information made available in the previous patches >> to polish a rough edge of the --memberof/--user options. >> > > Attaching rebased patches. Petr? found that extratargetfilter allowed the filter to be changed on managed permissions. Attached patches fix this. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0489.3-permission-plugin-Output-the-extratargetfilter-virtu.patch Type: text/x-patch Size: 46428 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0490.3-permission-plugin-Write-support-for-extratargetfilte.patch Type: text/x-patch Size: 9898 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0491.3-permission-CLI-Rename-filter-to-rawfilter-extratarge.patch Type: text/x-patch Size: 8504 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0492.3-permission-plugin-Add-tests-for-extratargetfilter.patch Type: text/x-patch Size: 13890 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0493.3-permission-plugin-Support-searching-by-extratargetfi.patch Type: text/x-patch Size: 3552 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0494.3-permission-plugin-Do-not-fail-on-non-DN-memberof-fil.patch Type: text/x-patch Size: 1424 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0495.3-permission-plugin-Do-not-change-extra-target-filters.patch Type: text/x-patch Size: 9656 bytes Desc: not available URL: From simo at redhat.com Thu Mar 13 18:17:19 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 13 Mar 2014 14:17:19 -0400 Subject: [Freeipa-devel] emerging standard for System for Cross-Domain Identity Management In-Reply-To: <53217152.5070905@redhat.com> References: <53217152.5070905@redhat.com> Message-ID: <1394734639.32465.254.camel@willson.li.ssimo.org> On Thu, 2014-03-13 at 09:50 +0100, Petr Spacek wrote: > Hello list, > > my journey to the IETF land revealed following RFC drafts: > > System for Cross-Domain Identity Management > 2. SCIM User Scenarios > 2.1. Background & Context > The System for Cross-domain Identity Management (SCIM) specification > is designed to make managing user identity in cloud based > applications and services easier. > > http://tools.ietf.org/html/draft-ietf-scim-use-cases-01 > http://tools.ietf.org/html/draft-ietf-scim-api-03 I haven't read this in detail but soiunds like a useful reference should we want to build a basic REST API for user/group management, but with these things the devil is generally in the details. > http://tools.ietf.org/html/draft-ietf-scim-core-schema-03 > > I didn't study them in detail but the title seems to be interesting enough to > justify this e-mail. > > Have a nice day! > -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Mar 13 20:39:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 13 Mar 2014 21:39:18 +0100 Subject: [Freeipa-devel] emerging standard for System for Cross-Domain Identity Management In-Reply-To: <1394734639.32465.254.camel@willson.li.ssimo.org> References: <53217152.5070905@redhat.com> <1394734639.32465.254.camel@willson.li.ssimo.org> Message-ID: <53221776.60406@redhat.com> On 03/13/2014 07:17 PM, Simo Sorce wrote: > On Thu, 2014-03-13 at 09:50 +0100, Petr Spacek wrote: >> Hello list, >> >> my journey to the IETF land revealed following RFC drafts: >> >> System for Cross-Domain Identity Management >> 2. SCIM User Scenarios >> 2.1. Background & Context >> The System for Cross-domain Identity Management (SCIM) specification >> is designed to make managing user identity in cloud based >> applications and services easier. >> >> http://tools.ietf.org/html/draft-ietf-scim-use-cases-01 >> http://tools.ietf.org/html/draft-ietf-scim-api-03 > > I haven't read this in detail but soiunds like a useful reference should > we want to build a basic REST API for user/group management, but with > these things the devil is generally in the details. I saw several SCIM presentations on the last LDAPConn. LDAP+REST pretty much resonated through the entire conference. There are few related presentations there too: http://lanyrd.com/2013/ldapcon/ Martin From lkrispen at redhat.com Fri Mar 14 08:15:28 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Fri, 14 Mar 2014 09:15:28 +0100 Subject: [Freeipa-devel] LDAP Queue Length Control for better LDAP client performance? In-Reply-To: <5321BEB1.2090909@redhat.com> References: <53217584.4000904@redhat.com> <5321BEB1.2090909@redhat.com> Message-ID: <5322BAA0.3010705@redhat.com> On 03/13/2014 03:20 PM, Rich Megginson wrote: > On 03/13/2014 03:08 AM, Petr Spacek wrote: >> Hello list, >> >> my journey to the IETF wonderland revealed one more RFC draft: >> >> LDAP Queue Length Control >> http://tools.ietf.org/html/draft-hollstein-queuelength-control-01 >> >> I have no idea if this can really improve LDAP client performance or >> not but IMHO it is worth exploring it. >> >> Maybe only an IPA replica with thousands of SSSD clients could >> benefit from it, I don't know. >> >> I have finally ran out of notes from yesterday so you don't need to >> worry about more RFC drafts - today :-) >> > > 389 allows you to turn on and off TCP Nagle (TCP_NODELAY) and > TCP_CORK. Someone could try running different workloads with > different settings for these to see if it makes a difference. and we haven't been able so far to find a setup which really shows a difference of the settings. In this draft the control of behaviour is moved up to the ldap layer and I have doubts that it will give a measurable effect, in general it introduces some overhead to check if the contropl is set, to buffer the responses,... , which might be low but affects all connections > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Fri Mar 14 09:08:23 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 14 Mar 2014 10:08:23 +0100 Subject: [Freeipa-devel] [PATCH] 462 Fix idrange unit test failure Message-ID: <5322C707.5080706@redhat.com> Pushed as a one liner to master, ipa-3-3. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-462-fix-idrange-unit-test-failure.patch Type: text/x-patch Size: 1178 bytes Desc: not available URL: From mkosek at redhat.com Fri Mar 14 09:18:08 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 14 Mar 2014 10:18:08 +0100 Subject: [Freeipa-devel] [PATCHES] 0489-0495 Add the extratargetfilter virtual attribute to permissions In-Reply-To: <5321EA2B.1030902@redhat.com> References: <531A167F.7010302@redhat.com> <531DEAF2.9090506@redhat.com> <5321EA2B.1030902@redhat.com> Message-ID: <5322C950.5070401@redhat.com> On 03/13/2014 06:26 PM, Petr Viktorin wrote: > On 03/10/2014 05:40 PM, Petr Viktorin wrote: >> On 03/07/2014 07:57 PM, Petr Viktorin wrote: >>> Hello, >>> This implements https://fedorahosted.org/freeipa/ticket/4216 >>> >>> It feels like permissions have gone full circle, from being managed by >>> virtual attributes, to storing all data in LDAP and exposing that, to >>> exposing mainly virtual attributes after all. The good part is that the >>> virtual attributes are now just a layer on top of well-structured LDAP >>> entries. >>> >>> >>> To the point: extratargetfilter lists all target filters that are not >>> implied by --memberof or --user. The list is writable; changing it will >>> preserve the implied filters. By default the full underlying list is not >>> shown, you can use --all or --raw for that. >>> In CLI, extratargetfilter is now named simply --filter, and the >>> underlying ipapermtargetfilter is named --rawfilter. >>> >>> There are still some cases where the illusion is not complete: >>> >>> - When searching, extratargetfilter and ipapermtargetfilter behave the >>> same, they search the full list. >>> >>> - When adding a filter that matches the requirements for --memberof or >>> --type, the filter will be "used" for that option instead: >>> >>> $ ipa permission-add testperm --type user --perm write >>> --filter='(memberOf=cn=admins,cn=groups,cn=accounts,$SUFFIX)' >>> --------------------------- >>> Added permission "testperm" >>> --------------------------- >>> Permission name: testperm >>> Permissions: write >>> Bind rule type: permission >>> Subtree: cn=users,cn=accounts,$SUFFIX >>> Member of group: admins >>> Type: user >>> >>> >>> >>> Patches: >>> >>> 0489 - Outputting extratargetfilter >>> 0490 - Writing extratargetfilter >>> 0491 - CLI names for the options >>> 0492 - Tests for the above >>> 0493 - Searching by extratargetfilter >>> 0494 - Fix an existing bug in --memberof >>> 0495 - This uses the information made available in the previous patches >>> to polish a rough edge of the --memberof/--user options. >>> >> >> Attaching rebased patches. > > Petr? found that extratargetfilter allowed the filter to be changed on managed > permissions. Attached patches fix this. > Thanks for the fix. I tested and checked the whole patch set and looks and works good. Pushed to master: 64cc4d81cce2143f13b9ddad946473d58bc42b36 Martin From abokovoy at redhat.com Fri Mar 14 09:29:40 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 14 Mar 2014 11:29:40 +0200 Subject: [Freeipa-devel] [PATCH] 461 Update Dogtag 9 database during replica installation In-Reply-To: <5321D167.2080201@redhat.com> References: <532167B0.8080600@redhat.com> <5321BD7D.2000304@redhat.com> <5321D167.2080201@redhat.com> Message-ID: <20140314092940.GA15585@redhat.com> On Thu, 13 Mar 2014, Martin Kosek wrote: >On 03/13/2014 03:15 PM, Martin Kosek wrote: >> On 03/13/2014 09:09 AM, Martin Kosek wrote: >>> When Dogtag 10 based FreeIPA replica is being installed for a Dogtag 9 >>> based master, the PKI database is not updated and miss several ACLs >>> which prevent some of the PKI functions, e.g. an ability to create >>> other clones. >>> >>> Add an update file to do the database update. Content is based on >>> recommendation from PKI team: >>> * https://bugzilla.redhat.com/show_bug.cgi?id=1075118#c9 >>> >>> This update file can be removed when Dogtag database upgrades are done >>> in PKI component. Upstream tickets: >>> * https://fedorahosted.org/pki/ticket/710 (database upgrade framework) >>> * https://fedorahosted.org/pki/ticket/906 (checking database version) >>> >>> https://fedorahosted.org/freeipa/ticket/4243 >> >> I found few issues with the patch: >> - New update file was not added to Makefile.am >> - PKI was not restarted after LDAP updates so it did not pick up the ACLs and >> replica installation will crash anyway. Now the PKI is always restarted at the >> end of server/replica installation. >> >> Martin > >FYI - I was just confirmed that this patch finally fixed the issue even in >automatized environment (beaker). ACK. With this patch in place, can we release 3.3.6 and update FreeIPA in Fedora 19 and Fedora 20? There are already reports on IRC from people trying to migrate via replica from CentOS to Fedora. -- / Alexander Bokovoy From pviktori at redhat.com Fri Mar 14 11:25:32 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Mar 2014 12:25:32 +0100 Subject: [Freeipa-devel] [PATCH] 461 Update Dogtag 9 database during replica installation In-Reply-To: <20140314092940.GA15585@redhat.com> References: <532167B0.8080600@redhat.com> <5321BD7D.2000304@redhat.com> <5321D167.2080201@redhat.com> <20140314092940.GA15585@redhat.com> Message-ID: <5322E72C.2020600@redhat.com> On 03/14/2014 10:29 AM, Alexander Bokovoy wrote: > On Thu, 13 Mar 2014, Martin Kosek wrote: >> On 03/13/2014 03:15 PM, Martin Kosek wrote: >>> On 03/13/2014 09:09 AM, Martin Kosek wrote: >>>> When Dogtag 10 based FreeIPA replica is being installed for a Dogtag 9 >>>> based master, the PKI database is not updated and miss several ACLs >>>> which prevent some of the PKI functions, e.g. an ability to create >>>> other clones. >>>> >>>> Add an update file to do the database update. Content is based on >>>> recommendation from PKI team: >>>> * https://bugzilla.redhat.com/show_bug.cgi?id=1075118#c9 >>>> >>>> This update file can be removed when Dogtag database upgrades are done >>>> in PKI component. Upstream tickets: >>>> * https://fedorahosted.org/pki/ticket/710 (database upgrade >>>> framework) >>>> * https://fedorahosted.org/pki/ticket/906 (checking database >>>> version) >>>> >>>> https://fedorahosted.org/freeipa/ticket/4243 >>> >>> I found few issues with the patch: >>> - New update file was not added to Makefile.am >>> - PKI was not restarted after LDAP updates so it did not pick up the >>> ACLs and >>> replica installation will crash anyway. Now the PKI is always >>> restarted at the >>> end of server/replica installation. >>> >>> Martin >> >> FYI - I was just confirmed that this patch finally fixed the issue >> even in >> automatized environment (beaker). > > ACK. > > With this patch in place, can we release 3.3.6 and update FreeIPA in > Fedora 19 and Fedora 20? There are already reports on IRC from people > trying to migrate via replica from CentOS to Fedora. I have started testing this on RHEL 6.4 (master) ? f20 git master with this patch (replica), but ran into https://fedorahosted.org/pki/ticket/816. I don't think we should release until that is fixed. -- Petr? From abokovoy at redhat.com Fri Mar 14 11:37:43 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 14 Mar 2014 13:37:43 +0200 Subject: [Freeipa-devel] [PATCH] 461 Update Dogtag 9 database during replica installation In-Reply-To: <5322E72C.2020600@redhat.com> References: <532167B0.8080600@redhat.com> <5321BD7D.2000304@redhat.com> <5321D167.2080201@redhat.com> <20140314092940.GA15585@redhat.com> <5322E72C.2020600@redhat.com> Message-ID: <20140314113743.GT16644@redhat.com> On Fri, 14 Mar 2014, Petr Viktorin wrote: >On 03/14/2014 10:29 AM, Alexander Bokovoy wrote: >>On Thu, 13 Mar 2014, Martin Kosek wrote: >>>On 03/13/2014 03:15 PM, Martin Kosek wrote: >>>>On 03/13/2014 09:09 AM, Martin Kosek wrote: >>>>>When Dogtag 10 based FreeIPA replica is being installed for a Dogtag 9 >>>>>based master, the PKI database is not updated and miss several ACLs >>>>>which prevent some of the PKI functions, e.g. an ability to create >>>>>other clones. >>>>> >>>>>Add an update file to do the database update. Content is based on >>>>>recommendation from PKI team: >>>>> * https://bugzilla.redhat.com/show_bug.cgi?id=1075118#c9 >>>>> >>>>>This update file can be removed when Dogtag database upgrades are done >>>>>in PKI component. Upstream tickets: >>>>> * https://fedorahosted.org/pki/ticket/710 (database upgrade >>>>>framework) >>>>> * https://fedorahosted.org/pki/ticket/906 (checking database >>>>>version) >>>>> >>>>>https://fedorahosted.org/freeipa/ticket/4243 >>>> >>>>I found few issues with the patch: >>>>- New update file was not added to Makefile.am >>>>- PKI was not restarted after LDAP updates so it did not pick up the >>>>ACLs and >>>>replica installation will crash anyway. Now the PKI is always >>>>restarted at the >>>>end of server/replica installation. >>>> >>>>Martin >>> >>>FYI - I was just confirmed that this patch finally fixed the issue >>>even in >>>automatized environment (beaker). >> >>ACK. >> >>With this patch in place, can we release 3.3.6 and update FreeIPA in >>Fedora 19 and Fedora 20? There are already reports on IRC from people >>trying to migrate via replica from CentOS to Fedora. > >I have started testing this on RHEL 6.4 (master) ? f20 git master >with this patch (replica), but ran into >https://fedorahosted.org/pki/ticket/816. I don't think we should >release until that is fixed. Did you try git master or ipa-3-3 branch? It is unclear from your description. For the record, https://gist.githubusercontent.com/josh-at-knoesis/9536155/raw/ef04f209e4815c7cafc4f43289c6c186d420b5ee/freeipa-error_2014-04-13a.txt contains dirsrv logs for the replica built from CentOS 6.5 to Fedora 19 (FreeIPA 3.3). -- / Alexander Bokovoy From pviktori at redhat.com Fri Mar 14 12:34:13 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Mar 2014 13:34:13 +0100 Subject: [Freeipa-devel] [PATCH] 461 Update Dogtag 9 database during replica installation In-Reply-To: <20140314113743.GT16644@redhat.com> References: <532167B0.8080600@redhat.com> <5321BD7D.2000304@redhat.com> <5321D167.2080201@redhat.com> <20140314092940.GA15585@redhat.com> <5322E72C.2020600@redhat.com> <20140314113743.GT16644@redhat.com> Message-ID: <5322F745.6050305@redhat.com> On 03/14/2014 12:37 PM, Alexander Bokovoy wrote: > On Fri, 14 Mar 2014, Petr Viktorin wrote: >> On 03/14/2014 10:29 AM, Alexander Bokovoy wrote: >>> On Thu, 13 Mar 2014, Martin Kosek wrote: >>>> On 03/13/2014 03:15 PM, Martin Kosek wrote: >>>>> On 03/13/2014 09:09 AM, Martin Kosek wrote: >>>>>> When Dogtag 10 based FreeIPA replica is being installed for a >>>>>> Dogtag 9 >>>>>> based master, the PKI database is not updated and miss several ACLs >>>>>> which prevent some of the PKI functions, e.g. an ability to create >>>>>> other clones. >>>>>> >>>>>> Add an update file to do the database update. Content is based on >>>>>> recommendation from PKI team: >>>>>> * https://bugzilla.redhat.com/show_bug.cgi?id=1075118#c9 >>>>>> >>>>>> This update file can be removed when Dogtag database upgrades are >>>>>> done >>>>>> in PKI component. Upstream tickets: >>>>>> * https://fedorahosted.org/pki/ticket/710 (database upgrade >>>>>> framework) >>>>>> * https://fedorahosted.org/pki/ticket/906 (checking database >>>>>> version) >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/4243 >>>>> >>>>> I found few issues with the patch: >>>>> - New update file was not added to Makefile.am >>>>> - PKI was not restarted after LDAP updates so it did not pick up the >>>>> ACLs and >>>>> replica installation will crash anyway. Now the PKI is always >>>>> restarted at the >>>>> end of server/replica installation. >>>>> >>>>> Martin >>>> >>>> FYI - I was just confirmed that this patch finally fixed the issue >>>> even in >>>> automatized environment (beaker). >>> >>> ACK. >>> >>> With this patch in place, can we release 3.3.6 and update FreeIPA in >>> Fedora 19 and Fedora 20? There are already reports on IRC from people >>> trying to migrate via replica from CentOS to Fedora. >> >> I have started testing this on RHEL 6.4 (master) ? f20 git master with >> this patch (replica), but ran into >> https://fedorahosted.org/pki/ticket/816. I don't think we should >> release until that is fixed. > Did you try git master or ipa-3-3 branch? It is unclear from your > description. I got the same problem on both. I haven't tried on f19 yet; it may be a f20 only issue. > For the record, > > https://gist.githubusercontent.com/josh-at-knoesis/9536155/raw/ef04f209e4815c7cafc4f43289c6c186d420b5ee/freeipa-error_2014-04-13a.txt > > > contains dirsrv logs for the replica built from CentOS 6.5 to Fedora 19 > (FreeIPA 3.3). > -- Petr? From mkosek at redhat.com Fri Mar 14 13:19:12 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 14 Mar 2014 14:19:12 +0100 Subject: [Freeipa-devel] [PATCH] 463 Increase Kerberos KDC configuration estimation time Message-ID: <532301D0.1050107@redhat.com> This step usually takes about 5 minutes. Current estimated time of 30 seconds is misleading and may make admins think that the installation is stuck. Change the estimation to 5 minutes. --- CC-ing Jakub who raised exactly this issue. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-463-increase-kerberos-kdc-configuration-estimation-time.patch Type: text/x-patch Size: 1145 bytes Desc: not available URL: From nalin at redhat.com Fri Mar 14 13:20:24 2014 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 14 Mar 2014 09:20:24 -0400 Subject: [Freeipa-devel] [PATCH] BuildRequires: rhino in .spec file Message-ID: <20140314132024.GA20223@redhat.com> When I try to scratch build master using 'make srpm' and koji, the build log includes multiple errors like this: ../../util/make-ui.sh Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main Those classes are provided by the 'rhino' package in Raw Hide, so I suggest adding it as a build-time requirement. Nalin -------------- next part -------------- >From b8b146c09c9c77105f4f48743cd6d59ca6903f16 Mon Sep 17 00:00:00 2001 From: Nalin Dahyabhai Date: Thu, 13 Mar 2014 17:09:49 -0400 Subject: [PATCH] Add missing dependency We use Java classes which are bundled with rhino when uglifying Javascript sources at build-time, so we need rhino at build-time. --- freeipa.spec.in | 1 + 1 file changed, 1 insertion(+) diff --git a/freeipa.spec.in b/freeipa.spec.in index e851313..c17e939 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -74,6 +74,7 @@ BuildRequires: check BuildRequires: libsss_idmap-devel BuildRequires: libsss_nss_idmap-devel BuildRequires: java-1.7.0-openjdk +BuildRequires: rhino BuildRequires: libverto-devel BuildRequires: systemd BuildRequires: libunistring-devel -- 1.9.0 From rcritten at redhat.com Fri Mar 14 13:21:55 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 14 Mar 2014 09:21:55 -0400 Subject: [Freeipa-devel] [PATCH] 463 Increase Kerberos KDC configuration estimation time In-Reply-To: <532301D0.1050107@redhat.com> References: <532301D0.1050107@redhat.com> Message-ID: <53230273.6050105@redhat.com> Martin Kosek wrote: > This step usually takes about 5 minutes. Current estimated time of > 30 seconds is misleading and may make admins think that the installation > is stuck. Change the estimation to 5 minutes. > > --- > > CC-ing Jakub who raised exactly this issue. It is entirely dependent upon how much entropy is available. I think 5 minutes is far too large. It may be overkill to check /proc/sys/kernel/random/entropy_avail to do the estimate. rob From pviktori at redhat.com Fri Mar 14 13:27:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Mar 2014 14:27:46 +0100 Subject: [Freeipa-devel] [PATCH] 461 Update Dogtag 9 database during replica installation In-Reply-To: <5322F745.6050305@redhat.com> References: <532167B0.8080600@redhat.com> <5321BD7D.2000304@redhat.com> <5321D167.2080201@redhat.com> <20140314092940.GA15585@redhat.com> <5322E72C.2020600@redhat.com> <20140314113743.GT16644@redhat.com> <5322F745.6050305@redhat.com> Message-ID: <532303D2.1050405@redhat.com> On 03/14/2014 01:34 PM, Petr Viktorin wrote: > On 03/14/2014 12:37 PM, Alexander Bokovoy wrote: >> On Fri, 14 Mar 2014, Petr Viktorin wrote: >>> On 03/14/2014 10:29 AM, Alexander Bokovoy wrote: >>>> On Thu, 13 Mar 2014, Martin Kosek wrote: >>>>> On 03/13/2014 03:15 PM, Martin Kosek wrote: >>>>>> On 03/13/2014 09:09 AM, Martin Kosek wrote: >>>>>>> When Dogtag 10 based FreeIPA replica is being installed for a >>>>>>> Dogtag 9 >>>>>>> based master, the PKI database is not updated and miss several ACLs >>>>>>> which prevent some of the PKI functions, e.g. an ability to create >>>>>>> other clones. >>>>>>> >>>>>>> Add an update file to do the database update. Content is based on >>>>>>> recommendation from PKI team: >>>>>>> * https://bugzilla.redhat.com/show_bug.cgi?id=1075118#c9 >>>>>>> >>>>>>> This update file can be removed when Dogtag database upgrades are >>>>>>> done >>>>>>> in PKI component. Upstream tickets: >>>>>>> * https://fedorahosted.org/pki/ticket/710 (database upgrade >>>>>>> framework) >>>>>>> * https://fedorahosted.org/pki/ticket/906 (checking database >>>>>>> version) >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4243 >>>>>> >>>>>> I found few issues with the patch: >>>>>> - New update file was not added to Makefile.am >>>>>> - PKI was not restarted after LDAP updates so it did not pick up the >>>>>> ACLs and >>>>>> replica installation will crash anyway. Now the PKI is always >>>>>> restarted at the >>>>>> end of server/replica installation. >>>>>> >>>>>> Martin >>>>> >>>>> FYI - I was just confirmed that this patch finally fixed the issue >>>>> even in >>>>> automatized environment (beaker). >>>> >>>> ACK. >>>> >>>> With this patch in place, can we release 3.3.6 and update FreeIPA in >>>> Fedora 19 and Fedora 20? There are already reports on IRC from people >>>> trying to migrate via replica from CentOS to Fedora. >>> >>> I have started testing this on RHEL 6.4 (master) ? f20 git master with >>> this patch (replica), but ran into >>> https://fedorahosted.org/pki/ticket/816. I don't think we should >>> release until that is fixed. >> Did you try git master or ipa-3-3 branch? It is unclear from your >> description. > > I got the same problem on both. I haven't tried on f19 yet; it may be a > f20 only issue. The issue is unrelated to this patch, so ACK from me. Pushed to: master: b3c2197b7e4ed18a7febe3efa6396c2272ebccca ipa-3-3: 9bc032f9ec0c44e83550d6f87f72e9395c3093d9 -- Petr? From mkosek at redhat.com Fri Mar 14 13:34:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 14 Mar 2014 14:34:54 +0100 Subject: [Freeipa-devel] [PATCH] 463 Increase Kerberos KDC configuration estimation time In-Reply-To: <53230273.6050105@redhat.com> References: <532301D0.1050107@redhat.com> <53230273.6050105@redhat.com> Message-ID: <5323057E.8060506@redhat.com> On 03/14/2014 02:21 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> This step usually takes about 5 minutes. Current estimated time of >> 30 seconds is misleading and may make admins think that the installation >> is stuck. Change the estimation to 5 minutes. >> >> --- >> >> CC-ing Jakub who raised exactly this issue. > > It is entirely dependent upon how much entropy is available. I think 5 minutes > is far too large. It may be overkill to check > /proc/sys/kernel/random/entropy_avail to do the estimate. > > rob > Hm, I knew why I did not commit the patch and waited for a second opinion. A proper fix indeed depends on system entropy so we may either increase the time for some average we see in our VMs (and thus let people with enough entropy be happy about shorter duration time) or scratch my patch and implement something more robust, either based on available entropy or by giving a time range like "30 seconds - 10 minutes, depending on available system entropy". Martin From pvoborni at redhat.com Fri Mar 14 13:50:47 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 14 Mar 2014 14:50:47 +0100 Subject: [Freeipa-devel] [PATCH] BuildRequires: rhino in .spec file In-Reply-To: <20140314132024.GA20223@redhat.com> References: <20140314132024.GA20223@redhat.com> Message-ID: <53230937.5070305@redhat.com> On 14.3.2014 14:20, Nalin Dahyabhai wrote: > When I try to scratch build master using 'make srpm' and koji, the build > log includes multiple errors like this: > ../../util/make-ui.sh > Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main > Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main > Error: Could not find or load main class org.mozilla.javascript.tools.shell.Main > > Those classes are provided by the 'rhino' package in Raw Hide, so I > suggest adding it as a build-time requirement. > > Nalin > ACK java-1.7.0-opnjdk no longer pulls rhino. Caused by: http://pkgs.fedoraproject.org/cgit/java-1.7.0-openjdk.git/commit/?id=63ecc0b8d60970f6d1d80f822cebf78441beb56a -- Petr Vobornik From pvoborni at redhat.com Fri Mar 14 14:31:30 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 14 Mar 2014 15:31:30 +0100 Subject: [Freeipa-devel] [PATCH] BuildRequires: rhino in .spec file In-Reply-To: <53230937.5070305@redhat.com> References: <20140314132024.GA20223@redhat.com> <53230937.5070305@redhat.com> Message-ID: <532312C2.4010509@redhat.com> On 14.3.2014 14:50, Petr Vobornik wrote: > On 14.3.2014 14:20, Nalin Dahyabhai wrote: >> When I try to scratch build master using 'make srpm' and koji, the build >> log includes multiple errors like this: >> ../../util/make-ui.sh >> Error: Could not find or load main class >> org.mozilla.javascript.tools.shell.Main >> Error: Could not find or load main class >> org.mozilla.javascript.tools.shell.Main >> Error: Could not find or load main class >> org.mozilla.javascript.tools.shell.Main >> >> Those classes are provided by the 'rhino' package in Raw Hide, so I >> suggest adding it as a build-time requirement. >> >> Nalin >> > > ACK > > java-1.7.0-opnjdk no longer pulls rhino. Caused by: > http://pkgs.fedoraproject.org/cgit/java-1.7.0-openjdk.git/commit/?id=63ecc0b8d60970f6d1d80f822cebf78441beb56a > Pushed to master: 35b7c1d909adb1d36bcfd4b3ba8993d5c1ed1a14 -- Petr Vobornik From pviktori at redhat.com Fri Mar 14 15:27:58 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Mar 2014 16:27:58 +0100 Subject: [Freeipa-devel] [PATCHES] 0473-0477+0497 Managed permission updater, part 1 In-Reply-To: <5321AC1A.70608@redhat.com> References: <530DB78A.4040003@redhat.com> <53108B41.50700@redhat.com> <53109370.7010905@redhat.com> <53149B54.2050308@redhat.com> <53171D1D.2010408@redhat.com> <5319953E.708@redhat.com> <5321AC1A.70608@redhat.com> Message-ID: <53231FFE.8000606@redhat.com> On 03/13/2014 02:01 PM, Petr Viktorin wrote: > On 03/07/2014 10:45 AM, Martin Kosek wrote: >> On 03/05/2014 01:48 PM, Petr Viktorin wrote: >>> On 03/03/2014 04:10 PM, Petr Viktorin wrote: >>>> On 02/28/2014 02:47 PM, Petr Viktorin wrote: >>>>> On 02/28/2014 02:12 PM, Martin Kosek wrote: >>>>>> On 02/26/2014 10:44 AM, Petr Viktorin wrote: >>>>>>> Hello, >>>>>>> Here are a few fixes/improvements, and the first part of a managed >>>>>>> permission >>>>>>> updater. >>>>>>> >>>>>>> The patches should go in this order but don't need to be >>>>>>> ACKed/pushed >>>>>>> all at once. >>>>>>> >>>>>>> >>>>>>> Design: >>>>>>> http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Part of the work for: https://fedorahosted.org/freeipa/ticket/3566 >>>>>>> >>>>>>> >>>>>>> This part is a "preview" of sorts, to get the basic mechanism and >>>>>>> the >>>>>>> metadata >>>>>>> format reviewed before I add all of the default read permissions. >>>>>>> It implements the first section of "Default Permission Updater" in >>>>>>> the design; >>>>>>> "Replacing legacy default permissions" and "Removing the global >>>>>>> anonymous read >>>>>>> ACI" is left for later. >>>>>>> Metadata is added for the netgroup plugin* for starters >>> [...] >>>>>>> >>>>>> >>>>>> 1) 476: Typo in test name: >>>>>> >>>>>> + desc='Search fo rnonexisting permission with ":" in the >>>>>> name', >>>>> >>>>> Will fix. >>> >>> Fixed >>> >>>>>> 2) 477: do we want to log anything when permission is up to date? >>>>>> >>>>>> + try: >>>>>> + ldap.update_entry(entry) >>>>>> + except errors.EmptyModlist: >>>>>> + return >>>>> >>>>> I don't think that's needed, after all that's the expected behavior in >>>>> all but the first upgrade. >>>>> But I'll be happy to add it if you think it would be better. >>> >>> I've added a DEBUG message here. >>> >>> [...] >>>>>> 4) I have been quite resilient to the prefixes for the permissions, >>>>>> but it >>>>>> seems it is the easier possible approach to fix conflicts with user >>>>>> permissions >>>>>> without having to check that later for every upgrade or doing more >>>>>> complex >>>>>> stuff like multiple RDNs or different container for system and user >>>>>> permissions. >>>>>> >>>>>> I am now just thinking about the prefixing. Now you use this name: >>>>>> >>>>>> ipa:Read Netgroups >>>>>> >>>>>> Would it be "nicer" to use: >>>>>> >>>>>> IPA:Read Netgroups >>>>>> or >>>>>> IPA: Read Netgroups >>>>>> or even >>>>>> [IPA] Read Netgroups >>>>>> ? :-) >>>>> >>>>> Bikeshedding time! >>>>> Everyone on the list, please chime in! >>>> >>>> Bikeshedding results from today's meeting: >>>> >>>> "ipa: " pviktori++ >>>> "System: " mkosek++ simo+ ab++ >>>> "Builtin: " simo++ pvo+ >>>> "Default:" >>>> >>>> The winner is "System: ", so I'll go and change to that. >>> >>> Done. >> >> Thanks. The patch set looks good now, I just see that the update >> process may >> not be optimal After I run the upgrade second time, it still tries to >> update >> the ACI even though there was no change done to the permission object and >> should thus raise errors.EmptyModlist and skip the ACI update: >> >> 2014-03-07T09:44:34Z INFO Updating managed permissions for netgroup >> 2014-03-07T09:44:34Z INFO Updating managed permission: System: Read >> Netgroups >> 2014-03-07T09:44:34Z DEBUG Updating ACI for managed permission: >> System: Read >> Netgroups >> 2014-03-07T09:44:34Z DEBUG Removing ACI u'(targetattr = "cn || >> description || >> hostcategory || ipaenabledflag || ipauniqueid || nisdomainname || >> usercategory")(targetfilter = "(objectclass=ipanisnetgroup)")(version >> 3.0;acl >> "permission:System: Read Netgroups";allow (read,compare,search) userdn = >> "ldap:///all";)' from >> cn=ng,cn=alt,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >> 2014-03-07T09:44:34Z DEBUG Adding ACI u'(targetattr = "cn || >> description || >> hostcategory || ipaenabledflag || ipauniqueid || nisdomainname || >> usercategory")(targetfilter = "(objectclass=ipanisnetgroup)")(version >> 3.0;acl >> "permission:System: Read Netgroups";allow (read,compare,search) userdn = >> "ldap:///all";)' to >> cn=ng,cn=alt,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >> 2014-03-07T09:44:34Z INFO No changes to ACI >> 2014-03-07T09:44:34Z INFO Updating managed permission: System: Read >> Netgroup >> Membership >> >> Any idea what could cause this? > > Ah, you're right. The updater tried to remove the 'top' objectclass, > since it found that in the permission but it wasn't in > permission.object_class. > I added 'top' to the list in a new patch. > > There was a minor conflict with master; I'm attaching the whole rebased > patchset for convenience. Rebased again. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0473.4-Allow-indexing-API-object-types-by-class.patch Type: text/x-patch Size: 4114 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0474.4-permission-find-Fix-handling-of-the-search-term-for-.patch Type: text/x-patch Size: 3667 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0475.4-test_permission_plugin-Fix-tests-that-make-too-broad.patch Type: text/x-patch Size: 6973 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0476.4-Allow-modifying-permissions-with-in-the-name.patch Type: text/x-patch Size: 11043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0477.4-Add-Object-metadata-and-update-plugin-for-managed-pe.patch Type: text/x-patch Size: 9082 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0497.4-permission-plugin-Add-top-to-the-list-of-object-clas.patch Type: text/x-patch Size: 1502 bytes Desc: not available URL: From amisnyov at redhat.com Fri Mar 14 16:31:49 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Fri, 14 Mar 2014 17:31:49 +0100 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added Message-ID: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> Hi, automember-rebuild uses asynchronous 389 task, and returned success even if the task didn't run. This patch fixes this issue adding a --nowait parameter to 'ipa automember-rebuild', defaulting to False, thus when the script runs without it, it waits for the 'nstaskexitcode' attribute, which means the task has finished, according to http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. Old usage can be enabled using --nowait. https://fedorahosted.org/freeipa/ticket/4239 Request for comments: - Should I add a parameter to specify the polling time? (now 1ms) - Should I add a parameter to specify the maximum polling number? Now if something fails about creating the task, it polls forever. - Obviously, if these parameters should be added, there should be a reasonable default for them (~ Required=False, Default=X). Thanks, Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0007-1-automember-rebuild-nowait-feature-added.patch Type: text/x-patch Size: 2565 bytes Desc: not available URL: From swalter at redhat.com Fri Mar 14 17:23:08 2014 From: swalter at redhat.com (Stef Walter) Date: Fri, 14 Mar 2014 18:23:08 +0100 Subject: [Freeipa-devel] LDAP schema for PKCS#11 In-Reply-To: <53207DED.3030001@redhat.com> References: <53146CC4.8010200@redhat.com> <53147A50.3070901@redhat.com> <531483F1.6070005@redhat.com> <53148911.4090606@redhat.com> <53148B97.4020900@redhat.com> <53148CA5.2040009@redhat.com> <5314909E.9030502@redhat.com> <531716A4.6060600@redhat.com> <531758B4.8050004@redhat.com> <532079B9.80907@redhat.com> <53207DED.3030001@redhat.com> Message-ID: <53233AFC.2090405@redhat.com> On 12.03.2014 16:31, Jan Cholasta wrote: > On 12.3.2014 16:14, Stef Walter wrote: >> On 05.03.2014 18:02, Jan Cholasta wrote: >>> On 5.3.2014 13:20, Stef Walter wrote: >>>> On 03.03.2014 15:24, Jan Cholasta wrote: >>>>> On 3.3.2014 15:07, Stef Walter wrote: >>>>>> On 03.03.2014 15:03, Jan Cholasta wrote: >>>>>>> If you plug a PKCS#11 module into p11-kit, will p11-kit use NSS >>>>>>> trust >>>>>>> objects from the module? >>>>>> >>>>>> No. This is the spec for storing trust policy in PKCS#11 that we've >>>>>> been >>>>>> working on: >>>>>> >>>>>> http://p11-glue.freedesktop.org/doc/storing-trust-policy/ >>>>>> >>>>>> It's a far more extensible and future proof model. The p11-kit-trust >>>>>> module stores/loads these sorts of objects, and additionally also >>>>>> generates NSS trust objects on the fly so that NSS can consume the >>>>>> information. >>>>>> >>>>>> It doesn't do that last bit for third party sources, but it could >>>>>> given >>>>>> code :) >>>>> >>>>> Code is not a problem :) >>>>> >>>>> What would be the best way to provide trust policy to p11-kit from a >>>>> third party PKCS#11 module, if not NSS trust objects? >>>> >>>> I obviously think that using the new stuff linked above would be best. >>>> It's future proof and models this comprehensively. That would allow >>>> extracting compat trust anchors to files (for crypto libraries that >>>> don't yet support looking it up trust via PKCS#11). >>>> >>>> But I understand if you're hesitant to commit to this spec that's in >>>> development (albeit already implemented). >>> >>> Actually, I like it. Is everything mentioned at >>> >>> >>> going to be standardized? >> >> Yes, that's the goal. Several people have been involved in reviewing the >> spec, and I'm going through a second batch of reviews from the NSS guys. > > Great! Do you expect any big changes to happen during the review, or can > the spec be considered stable enough to base an LDAP schema on it? I'd like to think so. Yes. Stef From pviktori at redhat.com Fri Mar 14 17:24:27 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Mar 2014 18:24:27 +0100 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> Message-ID: <53233B4B.1040002@redhat.com> On 03/14/2014 05:31 PM, Misnyovszki Adam wrote: > Hi, > > automember-rebuild uses asynchronous 389 task, and returned success > even if the task didn't run. This patch fixes this issue adding a > --nowait parameter to 'ipa automember-rebuild', defaulting to False, > thus when the script runs without it, it waits for the 'nstaskexitcode' > attribute, which means the task has finished, according to > http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. > Old usage can be enabled using --nowait. > > https://fedorahosted.org/freeipa/ticket/4239 Thanks for the patch! > Request for comments: > - Should I add a parameter to specify the polling time? (now 1ms) 1ms is way too small, remember this can run on a busy server. I'd make it a second, or even several seconds. I don't think we need an option for it. If someone wants to micromanage they're free to use --nowait and poll manually. > - Should I add a parameter to specify the maximum polling number? Now > if something fails about creating the task, it polls forever. I wouldn't worry about limiting the poll count; if there's a stuck task the admin has bigger problems. Just make sure the polling will stop when the task entry is deleted (!!). > - Obviously, if these parameters should be added, there should be a > reasonable default for them (~ Required=False, Default=X). > > Thanks, > Adam > > > freeipa-amisnyov-0007-1-automember-rebuild-nowait-feature-added.patch > > >>From 62215a10a826d9e529ac861b40c1f1bf68823472 Mon Sep 17 00:00:00 2001 > From: Adam Misnyovszki > Date: Fri, 14 Mar 2014 17:22:09 +0100 > Subject: [PATCH] automember rebuild nowait feature added > > automember-rebuild uses asynchronous 389 task, and returned success even if the task didn't run. this patch fixes this issue adding a --nowait parameter to 'ipa automember-rebuild', defaulting to False, thus when the script runs without it, it waits for the 'nstaskexitcode' attribute, which means the task has finished. Old usage can be enabled using --nowait. Please limit the commit message lines to about 60-75 characters. > > https://fedorahosted.org/freeipa/ticket/4239 > --- > ipalib/plugins/automember.py | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/ipalib/plugins/automember.py b/ipalib/plugins/automember.py > index a12bfb52522e38bc083d0750dc66c894a4aeba53..1f36b36b63bf94345f48e18867dbdd3316d6ecb0 100644 > --- a/ipalib/plugins/automember.py > +++ b/ipalib/plugins/automember.py > @@ -17,6 +17,7 @@ > # You should have received a copy of the GNU General Public License > # along with this program. If not, see. > import uuid > +import time > import ldap as _ldap Style nitpick: When you're touching imports, you can add a blank line between standard library imports (uuid, time) and third-party imports (ldap), and another one between third-party and IPA imports. http://legacy.python.org/dev/peps/pep-0008/#imports > from ipalib import api, errors, Str, StrEnum, _, ngettext > from ipalib.plugins.baseldap import * > @@ -623,6 +624,13 @@ class automember_rebuild(Command): > label=_('Hosts'), > doc=_('Rebuild membership for specified hosts'), > ), > + Flag( > + 'nowait', > + required=False, We generally specify the 'required' status of an option by a symbol following the name: 'nowait' - required, single value 'nowait+' - required, multivalue 'nowait?' - optional, single value 'nowait*' - optional, multivalue > + default=False, > + label=_('No wait'), > + doc=_('Don\'t wait for rebuilding membership'), Style nitpick: Use double quotes around the string to avoid the backslash. > + ), > ) > has_output = output.standard_value > msg_summary = _('Automember rebuild membership task completed') This may not be true; leave out the msg_summary class attribute and add an appropriate 'summary' in execute's return value. > @@ -707,6 +715,23 @@ class automember_rebuild(Command): > scope=['sub'] > ) > ldap.add_entry(entry) > + > + while options.get('nowait'): A subjective style nitpick: Using `while` with a constant is creative, but maybe it would be more readable to spell out if+while True. > + tasks = ldap.get_entries( > + DN( > + ('cn', cn), > + ('cn', 'automember rebuild membership'), > + ('cn', 'tasks'), > + ('cn', 'config'), > + ), > + ) You can use ldap.get_entry to get a single entry. Both ldap.get_entry and ldap.get_entries will raise a NotFound exception if no entries are found, you'll need to handle that. > + if len(tasks) > 0: With get_entry that is unnecessary, but in the future, prefer if tasks: for checking if a list is nonempty. > + task = tasks[0] > + if 'nstaskexitcode' in task.single_value: An entry's `single_value` dict has the same keys as the entry, so if 'nstaskexitcode' in task: would suffice. > + return dict(result=task.single_value['nstaskexitcode'] == '0', value=unicode(task.single_value['nstaskexitcode'])) If something goes wrong, you should raise an exception, not return result=False. Go through ipalib.errors, see if there's a suitable one already. Try to keep lines to 79 characters or less. > + time.sleep(0.001) > + > return dict(result=True, value=u'') > > api.register(automember_rebuild) For extra credit, you could make a separate patch to modernize the plugin registration for the whole automember module; see: http://www.freeipa.org/page/Coding_Best_Practices#Decorator-based_plugin_registration -- Petr? From rcritten at redhat.com Fri Mar 14 17:26:15 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 14 Mar 2014 13:26:15 -0400 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> Message-ID: <53233BB7.9010104@redhat.com> Misnyovszki Adam wrote: > Hi, > > automember-rebuild uses asynchronous 389 task, and returned success > even if the task didn't run. This patch fixes this issue adding a > --nowait parameter to 'ipa automember-rebuild', defaulting to False, > thus when the script runs without it, it waits for the 'nstaskexitcode' > attribute, which means the task has finished, according to > http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. > Old usage can be enabled using --nowait. > > https://fedorahosted.org/freeipa/ticket/4239 > > Request for comments: > - Should I add a parameter to specify the polling time? (now 1ms) > - Should I add a parameter to specify the maximum polling number? Now > if something fails about creating the task, it polls forever. > - Obviously, if these parameters should be added, there should be a > reasonable default for them (~ Required=False, Default=X). I don't think you need a polling time, esp since this is hidden from the user, but I think that is probably too short and you may end up hammering the LDAP server. I also wonder if there should be some maximum wait time. I don't like loops that can never exit. I'm at a loss for what that time should be though. And we'd need to spell out that we gave up waiting, not that the task necessarily failed. So rather than having a polling time option, rename nowait into wait_for=20, so wait for 20 seconds. Or something like that. I'd suggest using get_entry since you already know the full DN and there is only ever one. It would make this much more readable. I wonder if some top-level documentation should be added to flesh this out some more. This does, for example, return False in one case. The meaning for that should be spelled out. rob From pvoborni at redhat.com Fri Mar 14 17:37:05 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 14 Mar 2014 18:37:05 +0100 Subject: [Freeipa-devel] [PATCH] 548 webui: change ipatokennotbefore and ipatokennotafter types to datetime In-Reply-To: <530CCE75.7010808@redhat.com> References: <530CCE75.7010808@redhat.com> Message-ID: <53233E41.2040606@redhat.com> On 25.2.2014 18:10, Petr Vobornik wrote: > Depends on tbabej's patches # 137, 140 and pvoborni's 546 and 531-541. > > https://fedorahosted.org/freeipa/ticket/3369 > > Attaching rebased patch. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0548-1-webui-change-ipatokennotbefore-and-ipatokennotafter-.patch Type: text/x-patch Size: 1869 bytes Desc: not available URL: From pvoborni at redhat.com Fri Mar 14 17:39:14 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 14 Mar 2014 18:39:14 +0100 Subject: [Freeipa-devel] [PATCH] 550 webui-css: improve radio, checkbox keyboard support and color In-Reply-To: <5321D509.1020004@redhat.com> References: <5319D8F7.7080304@redhat.com> <5321D509.1020004@redhat.com> Message-ID: <53233EC2.2060302@redhat.com> On 13.3.2014 16:55, Petr Vobornik wrote: > On 7.3.2014 15:34, Petr Vobornik wrote: >> checkboxes and radio buttons: >> - do not change color on hover when disabled >> - are focusable and checkable by keyboard again. This uses a little >> trick where the real checkbox is hidden under the artificial >> checkbox. That way it has the same position and therefore it >> works even in containers with overflow set. >> >> https://fedorahosted.org/freeipa/ticket/4217 >> > > Self-NACK. > > Breaks Automount Key deletion in ipa/ui/#/e/automountmap/keys/ Fixed in attached patch #551. Also attaching new version of #550 with CI fixes. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0551-webui-do-not-use-dom-for-getting-selected-automount-.patch Type: text/x-patch Size: 2542 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0550-1-webui-css-improve-radio-checkbox-keyboard-support-an.patch Type: text/x-patch Size: 8270 bytes Desc: not available URL: From pvoborni at redhat.com Fri Mar 14 17:47:26 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 14 Mar 2014 18:47:26 +0100 Subject: [Freeipa-devel] [PATCH] 552-557 Permissions v2 Web UI Message-ID: <532340AE.9030900@redhat.com> Main ACI UI changes are in patch #557. The rest are prerequisites. These changes requested the unpopular update of JSON metadata files - it's for tests. This patch(#552) is compressed, otherwise it has 930KB. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0557-webui-change-permissions-UI-to-v2.patch Type: text/x-patch Size: 42061 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0556-webui-reflect-enabled-state-in-child-widgets-of-a-mu.patch Type: text/x-patch Size: 2249 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0555-webui-do-not-create-hr-delimiter-between-sections.patch Type: text/x-patch Size: 1056 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0554-webui-better-check-for-existing-options-in-attribute.patch Type: text/x-patch Size: 1477 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0553-webui-fix-unit-tests.patch Type: text/x-patch Size: 15291 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0551-webui-do-not-use-dom-for-getting-selected-automount-.patch Type: text/x-patch Size: 2542 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0552-webui-static-update-metadata-files.patch.tar.xz Type: application/x-xz Size: 25000 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 14 18:53:44 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 14 Mar 2014 19:53:44 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <5320ABEB.1080308@redhat.com> References: <52D99F70.3060305@redhat.com> <52DD4D03.1050302@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> <53203EBA.6060605@redhat.! com> <5320ABEB.1080308@redha! t.com> Message-ID: <53235038.5090501@redhat.com> On 03/12/2014 07:48 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 03/10/2014 08:55 PM, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 02/27/2014 10:18 PM, Rob Crittenden wrote: >>>>>> Rob Crittenden wrote: >>>>>> Updated patch based on feedback from Foreman team. I added a new URI, >>>>>> /features, which Foreman uses to determine what capabilities a proxy >>>>>> has. >>>>>> >>>>>> rob >>>>> >>>>> On my VMs, where the first request is handled properly but the server >>>>> hangs on the second one. I gave you access to the machines for >>>>> investigation. >>>> >>>> Sent you something out-of-band but in short, I wasn't able to reproduce >>>> on your reproducing VMs :-( Ping me tomorrow and we'll try it together. >> >> It ended up a combination of my mistake and a bug in GSSProxy. At least >> you found the bug. https://fedorahosted.org/gss-proxy/ticket/121 >> >>>>> Please add the Python libraries (python-cherrypy, python-requests, >>>>> python-kerberos) to BuildRequires. Otherwise the build fails due to >>>>> pylint errors. >>>> >>>> Fixed. >>>> >>>>> >>>>> In the man page: >>>>> >>>>>> +Create a host or user whose credentials will be used by the >>>>>> server to >>>>>> make requests and add it to the role: >>>>>> + >>>>>> + $ ipa user\-add \-\-first=Smartproxy \-\-last=Serversmartproxy >>>>>> + $ ipa role\-add\-member \-\-users=smartproxy 'Smartproxy >>>>>> management' >>>>> >>>>> the first command should be >>>>> ipa user-add smartproxy --first=Smartproxy >>>>> --last=Serversmartproxy >>>>> since by default the username is 'sserversmartproxy'. >>>> >>>> The problem was a missing space before smartproxy. I have the login >>>> name >>>> last in this example. Fixed. >>>> >>>>> >>>>> A nitpick regarding the systemd service: according to [0], >>>>> Type=forking >>>>> should be avoided. Is there a reason against setting Type=simple, and >>>>> removing the PID file? >>>> >>>> Because I wasn't able to get this working with cherrypy daemon mode. >>>> AFAICT it forks itself and systemd wouldn't end up with the right >>>> pid so >>>> can't stop the service. >>> >>> And now the updated patch. The changes are super-minor. >>> >>> rob >>> >> >> One last nitpick: the IPAErrors get encoded as JSON but the >> Content-Encoding is set to text/html. It's a one-line change so I went >> ahead and tested with it. ACK from me if you agree. > > +1 > > Here are a couple more enhancements I'm considering, this seems simpler > than inter-diff since it is so small. Not really. Having a patch file with a sequence+revision number you can refer to has its merits. Especially in a hairy thread like this one. Also one of our MUAs wrapped the lines, I had to undo that manually. > Here is why I made the changes, in order: > > I doubled the calls to create the connection but one isn't in a > try/except!? Remove the obvious one. > > We currently completely eat GSSAPI errors, I figure we should log failures. > > IPA stores the principal in the request context so using that will save > a GSSAPI call (and as we learned, a lock in gssproxy). > > I included your content-type change. These changes look good. I'm almost done testing but I need to call it a week. Sorry for not catching that last time, but your patch doesn't add a *versioned* BuildRequres on python-kerberos, instead it adds a duplicate unversioned one. So lint (and thus the build) will fail if the old python-kerberos version is installed. A possible a solution to the build trouble would be to just add a lint exception now, and open a ticket to remove it later. That way the build succeeds despite the older version, and the new python-kerberos is only needed when installing freeipa-server-foreman-smartproxy. That should make everyone happy, including Martin. Unfortunately our lint exception mechanism doesn't work on modules, so this needs a somewhat nastier hack. The attaching a patch that does this (and I'm pasting a simple diff below). Does that look okay to push? -- Petr? diff --git a/freeipa.spec.in b/freeipa.spec.in index 80de52e..9b56ec1 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -79,7 +79,6 @@ BuildRequires: libverto-devel BuildRequires: systemd BuildRequires: libunistring-devel BuildRequires: python-lesscpy -BuildRequires: python-kerberos BuildRequires: python-cherrypy BuildRequires: python-requests diff --git a/make-lint b/make-lint index 40483a6..89e091b 100755 --- a/make-lint +++ b/make-lint @@ -114,6 +114,12 @@ class IPATypeChecker(TypeChecker): return attrs def visit_getattr(self, node): + + # TODO: temporary hack to enable building with older python-kerberos + # TODO: remove when we BuildRequire python-kerberos 1.1-14 + if node.attrname == 'authGSSClientInquireCred': + return + try: inferred = list(node.expr.infer()) except InferenceError: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1106-8+pviktori-rest.patch Type: text/x-patch Size: 48356 bytes Desc: not available URL: From rcritten at redhat.com Fri Mar 14 18:58:24 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 14 Mar 2014 14:58:24 -0400 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53235038.5090501@redhat.com> References: <52D99F70.3060305@redhat.com> <52DE3BCB.5030107@redhat.com> <52E01649.7060002@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> <53203EBA.6060605@redhat.! com> <5320ABEB.1080308@redha! t.com> <53235038.5090501@red! hat.com> Message-ID: <53235150.4050306@redhat.com> Petr Viktorin wrote: > On 03/12/2014 07:48 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 03/10/2014 08:55 PM, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 02/27/2014 10:18 PM, Rob Crittenden wrote: >>>>>>> Rob Crittenden wrote: >>>>>>> Updated patch based on feedback from Foreman team. I added a new >>>>>>> URI, >>>>>>> /features, which Foreman uses to determine what capabilities a proxy >>>>>>> has. >>>>>>> >>>>>>> rob >>>>>> >>>>>> On my VMs, where the first request is handled properly but the server >>>>>> hangs on the second one. I gave you access to the machines for >>>>>> investigation. >>>>> >>>>> Sent you something out-of-band but in short, I wasn't able to >>>>> reproduce >>>>> on your reproducing VMs :-( Ping me tomorrow and we'll try it >>>>> together. >>> >>> It ended up a combination of my mistake and a bug in GSSProxy. At least >>> you found the bug. https://fedorahosted.org/gss-proxy/ticket/121 >>> >>>>>> Please add the Python libraries (python-cherrypy, python-requests, >>>>>> python-kerberos) to BuildRequires. Otherwise the build fails due to >>>>>> pylint errors. >>>>> >>>>> Fixed. >>>>> >>>>>> >>>>>> In the man page: >>>>>> >>>>>>> +Create a host or user whose credentials will be used by the >>>>>>> server to >>>>>>> make requests and add it to the role: >>>>>>> + >>>>>>> + $ ipa user\-add \-\-first=Smartproxy \-\-last=Serversmartproxy >>>>>>> + $ ipa role\-add\-member \-\-users=smartproxy 'Smartproxy >>>>>>> management' >>>>>> >>>>>> the first command should be >>>>>> ipa user-add smartproxy --first=Smartproxy >>>>>> --last=Serversmartproxy >>>>>> since by default the username is 'sserversmartproxy'. >>>>> >>>>> The problem was a missing space before smartproxy. I have the login >>>>> name >>>>> last in this example. Fixed. >>>>> >>>>>> >>>>>> A nitpick regarding the systemd service: according to [0], >>>>>> Type=forking >>>>>> should be avoided. Is there a reason against setting Type=simple, and >>>>>> removing the PID file? >>>>> >>>>> Because I wasn't able to get this working with cherrypy daemon mode. >>>>> AFAICT it forks itself and systemd wouldn't end up with the right >>>>> pid so >>>>> can't stop the service. >>>> >>>> And now the updated patch. The changes are super-minor. >>>> >>>> rob >>>> >>> >>> One last nitpick: the IPAErrors get encoded as JSON but the >>> Content-Encoding is set to text/html. It's a one-line change so I went >>> ahead and tested with it. ACK from me if you agree. >> >> +1 >> >> Here are a couple more enhancements I'm considering, this seems simpler >> than inter-diff since it is so small. > > Not really. Having a patch file with a sequence+revision number you can > refer to has its merits. Especially in a hairy thread like this one. > Also one of our MUAs wrapped the lines, I had to undo that manually. > >> Here is why I made the changes, in order: >> >> I doubled the calls to create the connection but one isn't in a >> try/except!? Remove the obvious one. >> >> We currently completely eat GSSAPI errors, I figure we should log >> failures. >> >> IPA stores the principal in the request context so using that will save >> a GSSAPI call (and as we learned, a lock in gssproxy). >> >> I included your content-type change. > > These changes look good. > I'm almost done testing but I need to call it a week. Awesome, thanks. > > Sorry for not catching that last time, but your patch doesn't add a > *versioned* BuildRequres on python-kerberos, instead it adds a duplicate > unversioned one. So lint (and thus the build) will fail if the old > python-kerberos version is installed. > > A possible a solution to the build trouble would be to just add a lint > exception now, and open a ticket to remove it later. That way the build > succeeds despite the older version, and the new python-kerberos is only > needed when installing freeipa-server-foreman-smartproxy. > That should make everyone happy, including Martin. > Unfortunately our lint exception mechanism doesn't work on modules, so > this needs a somewhat nastier hack. > The attaching a patch that does this (and I'm pasting a simple diff > below). Does that look okay to push? I'm trying to find a better solution to all this. I may end up taking Martin's suggestion of rawhide-only to avoid this sort of thing. The deal with the smartproxy is that you can/should be able to run it on any IPA-enrolled client, so you can run it directly on the Foreman box, with the IPA server somewhere else. What this means is that someone could probably fairly easily package this up for other distributions and if we end up with a Fedora-only python-kerberos patch then smartproxy is Fedora-only as well. So I'm trying to get some movement out of upstream on this but it's been crickets for weeks. I think in the context of the calendar server PyKerberos is small potatoes so doesn't get much lovin'. I'll amp up the nagging to get some sort of response, even if it is "stop nagging us!" rob From mkosek at redhat.com Mon Mar 17 08:23:02 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 17 Mar 2014 09:23:02 +0100 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <53233B4B.1040002@redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233B4B.1040002@redhat.com> Message-ID: <5326B0E6.6010703@redhat.com> On 03/14/2014 06:24 PM, Petr Viktorin wrote: > On 03/14/2014 05:31 PM, Misnyovszki Adam wrote: >> Hi, >> >> automember-rebuild uses asynchronous 389 task, and returned success >> even if the task didn't run. This patch fixes this issue adding a >> --nowait parameter to 'ipa automember-rebuild', defaulting to False, >> thus when the script runs without it, it waits for the 'nstaskexitcode' >> attribute, which means the task has finished, according to >> http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. >> Old usage can be enabled using --nowait. >> >> https://fedorahosted.org/freeipa/ticket/4239 > > Thanks for the patch! > >> Request for comments: ... > A subjective style nitpick: Using `while` with a constant is creative, but > maybe it would be more readable to spell out if+while True. > >> + tasks = ldap.get_entries( >> + DN( >> + ('cn', cn), >> + ('cn', 'automember rebuild membership'), >> + ('cn', 'tasks'), >> + ('cn', 'config'), >> + ), >> + ) > > You can use ldap.get_entry to get a single entry. Both ldap.get_entry and > ldap.get_entries will raise a NotFound exception if no entries are found, > you'll need to handle that. Additionally, that DN is already defined few lines above. I would rather have that in a variable and used twice than having it constructed twice. Martin From pviktori at redhat.com Mon Mar 17 11:21:43 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 17 Mar 2014 12:21:43 +0100 Subject: [Freeipa-devel] [PATCH] 0497 Add Nathaniel McCallum to .mailmap Message-ID: <5326DAC7.6020200@redhat.com> It turns out Nathaniel used a personal e-mail in one of the patches. Add it to the .mailmap. Pushed as one-liner to master: c4d00fdd15d043365e8473a1083723d574cb64b2 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0497-Add-Nathaniel-McCallum-to-.mailmap.patch Type: text/x-patch Size: 905 bytes Desc: not available URL: From pviktori at redhat.com Mon Mar 17 11:56:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 17 Mar 2014 12:56:14 +0100 Subject: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy In-Reply-To: <53235150.4050306@redhat.com> References: <52D99F70.3060305@redhat.com> <52E1167B.9050605@redhat.com> <52E80BAD.7010400@redhat.com> <52E81498.7040204@redhat.com> <52F89A5B.2090707@redhat.com> <52FD5037.10204@redhat.com> <52FDD74D.3050504@redhat.com> <52FE7442.9060806@redhat.com> <52FE77E4.1060701@redhat.com> <52FE85AF.4080608@redhat.com> <52FE902E.2050000@redhat.com> <52FE9230.3030906@redhat.com> <52FE939B.9040207@redhat.com> <52FE982E.2010604@redhat.com> <5301BE93.4020203@redhat.com> <5302530F.8010705@redhat.com> <53025E4F.2020201@redhat.com> <53026426.8080907@redhat.com> <530266ED.9020508@redhat.com> <53027B65.2020106@redhat.com> <53027DD6.50903@redhat.com> <530285CF.101@redhat.com> <53029721.9040508@redhat.com> <530772AB.2060409@redhat.com> <530FABC0.3060601@redhat.com> <531DDC79.1000406@redhat.com> <531E1832.7020908@redhat.com> <531E1896.3050700@redhat.com> <53203EBA.6060605@redhat.! com> <5320ABEB.1080308@redha! t.com> <53235038.5090501@red! hat.com> <53235150.4050306@redhat.com> Message-ID: <5326E2DE.3010006@redhat.com> On 03/14/2014 07:58 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 03/12/2014 07:48 PM, Rob Crittenden wrote: [...] >>> >>> Here are a couple more enhancements I'm considering, this seems simpler >>> than inter-diff since it is so small. >> >> Not really. Having a patch file with a sequence+revision number you can >> refer to has its merits. Especially in a hairy thread like this one. >> Also one of our MUAs wrapped the lines, I had to undo that manually. >> >>> Here is why I made the changes, in order: >>> >>> I doubled the calls to create the connection but one isn't in a >>> try/except!? Remove the obvious one. >>> >>> We currently completely eat GSSAPI errors, I figure we should log >>> failures. >>> >>> IPA stores the principal in the request context so using that will save >>> a GSSAPI call (and as we learned, a lock in gssproxy). >>> >>> I included your content-type change. >> >> These changes look good. >> I'm almost done testing but I need to call it a week. > > Awesome, thanks. ACK on the functionality. >> Sorry for not catching that last time, but your patch doesn't add a >> *versioned* BuildRequres on python-kerberos, instead it adds a duplicate >> unversioned one. So lint (and thus the build) will fail if the old >> python-kerberos version is installed. >> >> A possible a solution to the build trouble would be to just add a lint >> exception now, and open a ticket to remove it later. That way the build >> succeeds despite the older version, and the new python-kerberos is only >> needed when installing freeipa-server-foreman-smartproxy. >> That should make everyone happy, including Martin. >> Unfortunately our lint exception mechanism doesn't work on modules, so >> this needs a somewhat nastier hack. >> The attaching a patch that does this (and I'm pasting a simple diff >> below). Does that look okay to push? > > I'm trying to find a better solution to all this. I may end up taking > Martin's suggestion of rawhide-only to avoid this sort of thing. Looks like you'll still need to silence pylint on f20 in that case. > The deal with the smartproxy is that you can/should be able to run it on > any IPA-enrolled client, so you can run it directly on the Foreman box, > with the IPA server somewhere else. What this means is that someone > could probably fairly easily package this up for other distributions and > if we end up with a Fedora-only python-kerberos patch then smartproxy is > Fedora-only as well. > > So I'm trying to get some movement out of upstream on this but it's been > crickets for weeks. I think in the context of the calendar server > PyKerberos is small potatoes so doesn't get much lovin'. I'll amp up the > nagging to get some sort of response, even if it is "stop nagging us!" > > rob Good luck! -- Petr? From pvoborni at redhat.com Mon Mar 17 14:16:09 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 17 Mar 2014 15:16:09 +0100 Subject: [Freeipa-devel] [PATCH] 558 webui: remove hover effect from disabled action button Message-ID: <532703A9.3090104@redhat.com> https://fedorahosted.org/freeipa/ticket/4256 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0558-webui-remove-hover-effect-from-disabled-action-butto.patch Type: text/x-patch Size: 760 bytes Desc: not available URL: From pviktori at redhat.com Mon Mar 17 14:22:31 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 17 Mar 2014 15:22:31 +0100 Subject: [Freeipa-devel] [PATCH] 552-557 Permissions v2 Web UI In-Reply-To: <532340AE.9030900@redhat.com> References: <532340AE.9030900@redhat.com> Message-ID: <53270527.8030202@redhat.com> On 03/14/2014 06:47 PM, Petr Vobornik wrote: > Main ACI UI changes are in patch #557. The rest are prerequisites. With this UI it is impossible to change from "Type-based" permissions to "General" ones. This seems to be remaining from the old model where permissions were type/filter/subtree/targetgroup were "classes" of a permission rather than co-existing as attributes. Rather the Target section should IMO look the same for all (non-managed) permissions, with the first items being: Type: [drop-down with a None option] Subtree: [textbox that is disabled when a Type is selected] The Subtree should be a one-line textbox. It would be acceptable if the whole DN doesn't always fit, it's the first part that's important. Remember to only send Subtree if Type is (staying as | being set to) None. Also, the Add dialog should use this instead of the "Define by". With managed permissions, if I try to change both included/excluded attribute list and the effective attributes, I get a validation error, which is good in CLI but it doesn't work well for the UI. I think it would be better to move "Managed permission overrides" below "Target", and make it read-only. And perhaps rename it to something like "Attribute breakdown". Managing the included/excluded lists directly is only useful for upgrades with a heavily customized policy, and for upgrades you need the CLI anyway. Normally, having only the attribute list editable should be fine. For SYSTEM permissions (those which only have the SYSTEM flag), such as 'Add Automember Rebuild Membership Task', Permissions should not be editable. For old-style permissions (those without any flags), nothing is editable but everything should be. The attributelevelrights are missing because the entry doesn't have the ipaPermissionV2 objectclass yet (although it's being reported, which is "my" bug -- #4257). I filed these tickets based on face-to-face discussion about this and the UI in general: https://fedorahosted.org/freeipa/ticket/4253 Attribute box un permission UI is too small https://fedorahosted.org/freeipa/ticket/4254 Managed permission UI: use read-only fields instead of disabled ones https://fedorahosted.org/freeipa/ticket/4255 Web UI: Display "Loading" message when a list of entries is being loaded > These changes requested the unpopular update of JSON metadata files - > it's for tests. This patch(#552) is compressed, otherwise it has 930KB. :( -- Petr? From tbabej at redhat.com Mon Mar 17 15:32:29 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 17 Mar 2014 16:32:29 +0100 Subject: [Freeipa-devel] [PATCH 0158] Extend ipa-range-check DS plugin to handle range types Message-ID: <5327158D.1020408@redhat.com> Hi, The ipa-range-check plugin used to determine the range type depending on the value of the attributes such as RID or secondary RID base. This approached caused variety of issues since the portfolio of ID range types expanded. The patch makes sure the following rules are implemented: * No ID range pair can overlap on base ranges, with exception of two ipa-ad-trust-posix ranges belonging to the same forest * For any ID range pair of ranges belonging to the same domain: * Both ID ranges must be of the same type * For ranges of ipa-ad-trust type or ipa-local type: * Primary RID ranges can not overlap * For ranges of ipa-local type: * Primary and secondary RID ranges can not overlap * Secondary RID ranges cannot overlap For the implementation part, the plugin was extended with a domain ID to forest root domain ID mapping derivation capabilities. https://fedorahosted.org/freeipa/ticket/4137 Test coverage coming soon! -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0158-Extend-ipa-range-check-DS-plugin-to-handle-range-typ.patch Type: text/x-patch Size: 17679 bytes Desc: not available URL: From pvoborni at redhat.com Mon Mar 17 16:13:41 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 17 Mar 2014 17:13:41 +0100 Subject: [Freeipa-devel] [PATCH] 558 webui: remove hover effect from disabled action button In-Reply-To: <532703A9.3090104@redhat.com> References: <532703A9.3090104@redhat.com> Message-ID: <53271F35.6060208@redhat.com> On 17.3.2014 15:16, Petr Vobornik wrote: > https://fedorahosted.org/freeipa/ticket/4256 > Petr3 found that the effect is still there when the button is focused. It's caused by another bug - https://fedorahosted.org/freeipa/ticket/4258 Disabled action buttons are focusable New revision of the patch adds CSS styles which fix the appearance of focused disabled button (symptom treatment). Rationale: 4256 is a regression but 4258 is not. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0558-1-webui-remove-hover-effect-from-disabled-action-butto.patch Type: text/x-patch Size: 837 bytes Desc: not available URL: From pviktori at redhat.com Mon Mar 17 16:21:16 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 17 Mar 2014 17:21:16 +0100 Subject: [Freeipa-devel] [PATCH] 0498 permission plugin: Do not add the ipapermissionv2 for output Message-ID: <532720FC.7050003@redhat.com> This fixes an extra objectclass being added to legacy permissions in permission-{show,find} output. For the other attributes, we want to show what would be there if the permission was upgraded, but for objectclass and flags we want to show exactly what is in LDAP. https://fedorahosted.org/freeipa/ticket/4257 For all the tests to pass, apply this on top of my patch 0475 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0498-permission-plugin-Do-not-add-the-ipapermissionv2-for.patch Type: text/x-patch Size: 3736 bytes Desc: not available URL: From pviktori at redhat.com Mon Mar 17 17:37:50 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 17 Mar 2014 18:37:50 +0100 Subject: [Freeipa-devel] [PATCH] 558 webui: remove hover effect from disabled action button In-Reply-To: <53271F35.6060208@redhat.com> References: <532703A9.3090104@redhat.com> <53271F35.6060208@redhat.com> Message-ID: <532732EE.30800@redhat.com> On 03/17/2014 05:13 PM, Petr Vobornik wrote: > On 17.3.2014 15:16, Petr Vobornik wrote: >> https://fedorahosted.org/freeipa/ticket/4256 >> > > Petr3 found that the effect is still there when the button is focused. > > It's caused by another bug - > https://fedorahosted.org/freeipa/ticket/4258 Disabled action buttons are > focusable > > New revision of the patch adds CSS styles which fix the appearance of > focused disabled button (symptom treatment). > > Rationale: 4256 is a regression but 4258 is not. > This solves it for me. ACK, pushed to master: c82c598163996997570807827e02de11ca541c94 -- Petr? From marco.disabatino at tirasa.net Tue Mar 18 08:02:13 2014 From: marco.disabatino at tirasa.net (Marco Di Sabatino Di Diodoro) Date: Tue, 18 Mar 2014 09:02:13 +0100 Subject: [Freeipa-devel] Talking json/rpc with java client Message-ID: Hi all, what are the requirements or packages that a client must have to call JSON/RPC with java? We have a 401 error. If we talking to freeipa json web api via curl it works. Suggestions? M -- Dott. Marco Di Sabatino Di Diodoro Tel. +39 3939065570 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~mdisabatino/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Mar 18 08:19:17 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Mar 2014 10:19:17 +0200 Subject: [Freeipa-devel] [PATCH 0158] Extend ipa-range-check DS plugin to handle range types In-Reply-To: <5327158D.1020408@redhat.com> References: <5327158D.1020408@redhat.com> Message-ID: <20140318081917.GZ16644@redhat.com> On Mon, 17 Mar 2014, Tomas Babej wrote: >Hi, > >The ipa-range-check plugin used to determine the range type depending >on the value of the attributes such as RID or secondary RID base. This >approached caused variety of issues since the portfolio of ID range >types expanded. > >The patch makes sure the following rules are implemented: > * No ID range pair can overlap on base ranges, with exception > of two ipa-ad-trust-posix ranges belonging to the same forest > * For any ID range pair of ranges belonging to the same domain: > * Both ID ranges must be of the same type > * For ranges of ipa-ad-trust type or ipa-local type: > * Primary RID ranges can not overlap > * For ranges of ipa-local type: > * Primary and secondary RID ranges can not overlap > * Secondary RID ranges cannot overlap > >For the implementation part, the plugin was extended with a domain ID >to forest root domain ID mapping derivation capabilities. > >https://fedorahosted.org/freeipa/ticket/4137 > >Test coverage coming soon! I don't really like that you are using a list here. The list is built and then destroyed in preop callback every time we process the range object, so it is one-off operation. Now, when you fetch trust domain objects to build the list, why can't you use an array directly? Given that all you need the list for is to map domain to a trust (if any) and trust name is the name of the root level domain, you can simply make an array of a struct (name, root) where root is a and index to the same array or -1 if this is the root domain itself. > > >-- >Tomas Babej >Associate Software Engeneer | Red Hat | Identity Management >RHCE | Brno Site | IRC: tbabej | freeipa.org > > >>From 0d038fb71f02fab5320e4843be80feb34c5c3303 Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Wed, 5 Mar 2014 12:28:18 +0100 >Subject: [PATCH] Extend ipa-range-check DS plugin to handle range types > >The ipa-range-check plugin used to determine the range type depending >on the value of the attributes such as RID or secondary RID base. This >approached caused variety of issues since the portfolio of ID range >types expanded. > >The patch makes sure the following rules are implemented: > * No ID range pair can overlap on base ranges, with exception > of two ipa-ad-trust-posix ranges belonging to the same forest > * For any ID range pair of ranges belonging to the same domain: > * Both ID ranges must be of the same type > * For ranges of ipa-ad-trust type or ipa-local type: > * Primary RID ranges can not overlap > * For ranges of ipa-local type: > * Primary and secondary RID ranges can not overlap > * Secondary RID ranges cannot overlap > >For the implementation part, the plugin was extended with a domain ID >to forest root domain ID mapping derivation capabilities. > >https://fedorahosted.org/freeipa/ticket/4137 >--- > .../ipa-range-check/ipa_range_check.c | 322 ++++++++++++++++++--- > 1 file changed, 284 insertions(+), 38 deletions(-) > >diff --git a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >index 391e2259b6eced31fed399c927cfe44c1d3e237e..2360e42025a0146a43c3237914c8165d35714a68 100644 >--- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >+++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >@@ -47,10 +47,17 @@ > #define IPA_CN "cn" > #define IPA_BASE_ID "ipaBaseID" > #define IPA_ID_RANGE_SIZE "ipaIDRangeSize" >+#define IPA_RANGE_TYPE "ipaRangeType" > #define IPA_BASE_RID "ipaBaseRID" > #define IPA_SECONDARY_BASE_RID "ipaSecondaryBaseRID" > #define IPA_DOMAIN_ID "ipaNTTrustedDomainSID" > #define RANGES_FILTER "objectclass=ipaIDRange" >+#define DOMAIN_ID_FILTER "ipaNTTrustedDomainSID=*" >+ >+#define AD_TRUST_RANGE_TYPE "ipa-ad-trust" >+#define AD_TRUST_POSIX_RANGE_TYPE "ipa-ad-trust-posix" >+#define LOCAL_RANGE_TYPE "ipa-local" >+ > > #define IPA_PLUGIN_NAME "ipa-range-check" > #define IPA_RANGE_CHECK_FEATURE_DESC "IPA ID range check plugin" >@@ -72,13 +79,225 @@ struct ipa_range_check_ctx { > struct range_info { > char *name; > char *domain_id; >+ char *forest_root_id; >+ char *id_range_type; > uint32_t base_id; > uint32_t id_range_size; > uint32_t base_rid; > uint32_t secondary_base_rid; > }; > >-static int slapi_entry_to_range_info(struct slapi_entry *entry, >+struct domain_info { >+ char *domain_id; >+ char *forest_root_id; >+ struct domain_info *next; >+}; >+ >+ >+static struct domain_info* map_domain_to_root(struct domain_info *head, >+ struct slapi_entry *domain, >+ struct slapi_entry *root_domain){ >+ >+ struct domain_info* new_head = NULL; >+ new_head = (struct domain_info*) malloc(sizeof(struct domain_info)); >+ if (new_head == NULL) { >+ return NULL; >+ } >+ >+ new_head->domain_id = slapi_entry_attr_get_charptr(domain, >+ IPA_DOMAIN_ID); >+ new_head->forest_root_id = slapi_entry_attr_get_charptr(root_domain, >+ IPA_DOMAIN_ID); >+ new_head->next = head; >+ >+ return new_head; >+} >+ >+/* Searches for the domain_info struct with the specified domain_id >+ * in the linked list. Returns the forest root domain's ID, or NULL for >+ * local ranges. */ >+ >+static char* get_forest_root_id(struct domain_info *head, char* domain_id) { >+ >+ /* For local ranges there is no forest root domain, >+ * so consider only ranges with domain_id set */ >+ if (domain_id != NULL) { >+ while(head) { >+ if (strcasecmp(head->domain_id, domain_id) == 0) { >+ return head->forest_root_id; >+ } >+ head = head->next; >+ } >+ } >+ >+ return NULL; >+} >+ >+ >+/* >+ * This function builds a mapping from domain ID to forest >+ * root domain ID. >+ */ >+ >+static struct domain_info* build_domain_to_forest_root_map(struct domain_info *head, >+ struct ipa_range_check_ctx *ctx){ >+ >+ Slapi_PBlock *root_domain_search_pb = NULL; >+ Slapi_PBlock *child_domain_search_pb = NULL; >+ Slapi_Entry **root_domain_entries = NULL; >+ Slapi_Entry **child_domain_entries = NULL; >+ Slapi_DN *base_dn = NULL; >+ Slapi_RDN *rdn = NULL; >+ >+ int search_result; >+ int ret; >+ >+ /* Set the base DN for the search to cn=ad, cn=trusts, $SUFFIX */ >+ base_dn = slapi_sdn_new_dn_byref(ctx->base_dn); >+ if (base_dn == NULL) { >+ LOG_FATAL("Failed to convert base DN.\n"); >+ ret = LDAP_OPERATIONS_ERROR; >+ goto done; >+ } >+ >+ rdn = slapi_rdn_new(); >+ if (rdn == NULL) { >+ LOG_FATAL("Failed to obtain RDN struct.\n"); >+ ret = LDAP_OPERATIONS_ERROR; >+ goto done; >+ } >+ >+ slapi_rdn_add(rdn, "cn", "trusts"); >+ slapi_sdn_add_rdn(base_dn, rdn); >+ slapi_rdn_done(rdn); >+ >+ slapi_rdn_add(rdn, "cn", "ad"); >+ slapi_sdn_add_rdn(base_dn, rdn); >+ slapi_rdn_done(rdn); >+ >+ /* Allocate a new parameter block */ >+ root_domain_search_pb = slapi_pblock_new(); >+ if (root_domain_search_pb == NULL) { >+ LOG_FATAL("Failed to create new pblock.\n"); >+ ret = LDAP_OPERATIONS_ERROR; >+ //goto done; >+ } >+ >+ /* Search for all the root domains, note the LDAP_SCOPE_ONELEVEL */ >+ slapi_search_internal_set_pb(root_domain_search_pb, >+ slapi_sdn_get_dn(base_dn), >+ LDAP_SCOPE_ONELEVEL, DOMAIN_ID_FILTER, >+ NULL, 0, NULL, NULL, ctx->plugin_id, 0); >+ >+ ret = slapi_search_internal_pb(root_domain_search_pb); >+ if (ret != 0) { >+ LOG_FATAL("Starting internal search failed.\n"); >+ goto done; >+ } >+ >+ ret = slapi_pblock_get(root_domain_search_pb, SLAPI_PLUGIN_INTOP_RESULT, &search_result); >+ if (ret != 0 || search_result != LDAP_SUCCESS) { >+ LOG_FATAL("Internal search failed.\n"); >+ ret = LDAP_OPERATIONS_ERROR; >+ goto done; >+ } >+ >+ ret = slapi_pblock_get(root_domain_search_pb, SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, >+ &root_domain_entries); >+ >+ if (ret != 0) { >+ LOG_FATAL("Failed to read searched root domain entries.\n"); >+ goto done; >+ } >+ >+ if (root_domain_entries == NULL || root_domain_entries[0] == NULL) { >+ LOG("No existing root domain entries.\n"); >+ ret = 0; >+ goto done; >+ } >+ >+ /* now we iterate over root domains */ >+ for (int i = 0; root_domain_entries[i] != NULL; i++) { >+ /* map root domain to itself */ >+ head = map_domain_to_root(head, >+ root_domain_entries[i], >+ root_domain_entries[i]); >+ if (head == NULL) { >+ LOG_FATAL("Error when allocating new domain_info struct."); >+ goto child_done; >+ } >+ >+ /* let's reuse the variables */ >+ child_domain_search_pb = NULL; >+ child_domain_entries = NULL; >+ >+ /* allocate a new parameter block */ >+ child_domain_search_pb = slapi_pblock_new(); >+ if (child_domain_search_pb == NULL) { >+ LOG_FATAL("Failed to create new pblock.\n"); >+ ret = LDAP_OPERATIONS_ERROR; >+ goto child_done; >+ } >+ >+ /* search for all the child domains, note the LDAP_SCOPE_ONELEVEL */ >+ slapi_search_internal_set_pb(child_domain_search_pb, >+ slapi_entry_get_dn_const(root_domain_entries[i]), >+ LDAP_SCOPE_ONELEVEL, DOMAIN_ID_FILTER, >+ NULL, 0, NULL, NULL, ctx->plugin_id, 0); >+ >+ ret = slapi_search_internal_pb(child_domain_search_pb); >+ if (ret != 0) { >+ LOG_FATAL("Starting internal search failed.\n"); >+ goto child_done; >+ } >+ >+ ret = slapi_pblock_get(child_domain_search_pb, SLAPI_PLUGIN_INTOP_RESULT, &search_result); >+ if (ret != 0 || search_result != LDAP_SUCCESS) { >+ LOG_FATAL("Internal search failed.\n"); >+ ret = LDAP_OPERATIONS_ERROR; >+ goto child_done; >+ } >+ >+ ret = slapi_pblock_get(child_domain_search_pb, SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, >+ &child_domain_entries); >+ >+ if (ret != 0) { >+ LOG_FATAL("Failed to read searched child domain entries.\n"); >+ goto child_done; >+ } >+ >+ if (child_domain_entries == NULL || child_domain_entries[0] == NULL) { >+ LOG("No existing child domain entries.\n"); >+ ret = 0; >+ goto child_done; >+ } >+ >+ /* Now we iterate over child domains */ >+ for (int j = 0; child_domain_entries[j] != NULL; j++) { >+ >+ /* map each child domain to the root domain */ >+ head = map_domain_to_root(head, >+ child_domain_entries[j], >+ root_domain_entries[i]); >+ >+ } >+ >+ child_done: >+ slapi_free_search_results_internal(child_domain_search_pb); >+ slapi_pblock_destroy(child_domain_search_pb); >+ } >+ >+done: >+ slapi_free_search_results_internal(root_domain_search_pb); >+ slapi_pblock_destroy(root_domain_search_pb); >+ slapi_rdn_free(&rdn); >+ >+ return head; >+ >+} >+ >+static int slapi_entry_to_range_info(struct domain_info *domain_info_head, >+ struct slapi_entry *entry, > struct range_info **_range) > { > int ret; >@@ -97,6 +316,9 @@ static int slapi_entry_to_range_info(struct slapi_entry *entry, > } > > range->domain_id = slapi_entry_attr_get_charptr(entry, IPA_DOMAIN_ID); >+ range->id_range_type = slapi_entry_attr_get_charptr(entry, IPA_RANGE_TYPE); >+ range->forest_root_id = get_forest_root_id(domain_info_head, >+ range->domain_id); > > ul_val = slapi_entry_attr_get_ulong(entry, IPA_BASE_ID); > if (ul_val == 0 || ul_val >= UINT32_MAX) { >@@ -161,58 +383,67 @@ static bool intervals_overlap(uint32_t x, uint32_t base, uint32_t x_size, uint32 > * | | / \ | > * new range: base rid sec_rid > **/ >-static int ranges_overlap(struct range_info *r1, struct range_info *r2) >+static int check_ranges(struct range_info *r1, struct range_info *r2) > { >+ /* Do not check overlaps of range with the range itself */ > if (r1->name != NULL && r2->name != NULL && > strcasecmp(r1->name, r2->name) == 0) { > return 0; > } > >- /* check if base range overlaps with existing base range */ >- if (intervals_overlap(r1->base_id, r2->base_id, >- r1->id_range_size, r2->id_range_size)){ >- return 1; >+ /* Check if base range overlaps with existing base range. >+ * Exception: ipa-ad-trust-posix ranges from the same forest */ >+ if (!(strcasecmp(r1->id_range_type, AD_TRUST_POSIX_RANGE_TYPE) && >+ strcasecmp(r2->id_range_type, AD_TRUST_POSIX_RANGE_TYPE) && >+ r1->forest_root_id != NULL && r2->forest_root_id !=NULL && >+ strcasecmp(r1->forest_root_id, r2->forest_root_id) == 0)) { >+ >+ if (intervals_overlap(r1->base_id, r2->base_id, >+ r1->id_range_size, r2->id_range_size)){ >+ return 1; >+ } >+ > } > >- /* if both base_rid and secondary_base_rid = 0, the rid range is not set */ >- bool rid_ranges_set = (r1->base_rid != 0 || r1->secondary_base_rid != 0) && >- (r2->base_rid != 0 || r2->secondary_base_rid != 0); >- >- /** >- * ipaNTTrustedDomainSID is not set for local ranges, use it to >- * determine the type of the range **/ >- bool local_ranges = r1->domain_id == NULL && r2->domain_id == NULL; >- >+ /* Following checks apply for the ranges from the same domain */ > bool ranges_from_same_domain = > (r1->domain_id == NULL && r2->domain_id == NULL) || > (r1->domain_id != NULL && r2->domain_id != NULL && > strcasecmp(r1->domain_id, r2->domain_id) == 0); > >- /** >- * in case rid range is not set or ranges belong to different domains >- * we can skip rid range tests as they are irrelevant **/ >- if (rid_ranges_set && ranges_from_same_domain){ >- >- /* check if rid range overlaps with existing rid range */ >- if (intervals_overlap(r1->base_rid, r2->base_rid, >- r1->id_range_size, r2->id_range_size)) >- return 2; >- >- /** >- * The following 3 checks are relevant only if both ranges are local. >- * Check if secondary rid range overlaps with existing secondary rid >- * range. **/ >- if (local_ranges){ >+ if (ranges_from_same_domain) { >+ >+ /* Ranges from the same domain must have the same type */ >+ if (strcasecmp(r1->id_range_type, r2->id_range_type) != 0) { >+ return 6; >+ } >+ >+ /* For ipa-local or ipa-ad-trust range types primary RID ranges should >+ * not overlap */ >+ if (strcasecmp(r1->id_range_type, AD_TRUST_RANGE_TYPE) == 0 || >+ strcasecmp(r1->id_range_type, LOCAL_RANGE_TYPE) == 0) { >+ >+ /* Check if rid range overlaps with existing rid range */ >+ if (intervals_overlap(r1->base_rid, r2->base_rid, >+ r1->id_range_size, r2->id_range_size)) >+ return 2; >+ } >+ >+ /* The following 3 checks are relevant only if both ranges are local. */ >+ if (strcasecmp(r1->id_range_type, LOCAL_RANGE_TYPE) == 0){ >+ >+ /* Check if secondary RID range overlaps with existing secondary or >+ * primary RID range. */ > if (intervals_overlap(r1->secondary_base_rid, > r2->secondary_base_rid, r1->id_range_size, r2->id_range_size)) > return 3; > >- /* check if rid range overlaps with existing secondary rid range */ >+ /* Check if RID range overlaps with existing secondary RID range */ > if (intervals_overlap(r1->base_rid, r2->secondary_base_rid, > r1->id_range_size, r2->id_range_size)) > return 4; > >- /* check if secondary rid range overlaps with existing rid range */ >+ /* Check if secondary RID range overlaps with existing RID range */ > if (intervals_overlap(r1->secondary_base_rid, r2->base_rid, > r1->id_range_size, r2->id_range_size)) > return 5; >@@ -248,9 +479,10 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype) > int search_result; > Slapi_Entry **search_entries = NULL; > size_t c; >- int no_overlap = 0; >+ int ranges_valid = 0; > const char *check_attr; > char *errmsg = NULL; >+ struct domain_info *domain_info_head = NULL; > > ret = slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, &is_repl_op); > if (ret != 0) { >@@ -337,7 +569,10 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype) > goto done; > } > >- ret = slapi_entry_to_range_info(entry, &new_range); >+ /* build a linked list of domain_info structs */ >+ domain_info_head = build_domain_to_forest_root_map(domain_info_head, ctx); >+ >+ ret = slapi_entry_to_range_info(domain_info_head, entry, &new_range); > if (ret != 0) { > LOG_FATAL("Failed to convert LDAP entry to range struct.\n"); > goto done; >@@ -381,19 +616,20 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype) > } > > for (c = 0; search_entries[c] != NULL; c++) { >- ret = slapi_entry_to_range_info(search_entries[c], &old_range); >+ ret = slapi_entry_to_range_info(domain_info_head, search_entries[c], >+ &old_range); > if (ret != 0) { > LOG_FATAL("Failed to convert LDAP entry to range struct.\n"); > goto done; > } > >- no_overlap = ranges_overlap(new_range, old_range); >+ ranges_valid = check_ranges(new_range, old_range); > free(old_range); > old_range = NULL; >- if (no_overlap != 0) { >+ if (ranges_valid != 0) { > ret = LDAP_CONSTRAINT_VIOLATION; > >- switch (no_overlap){ >+ switch (ranges_valid){ > case 1: > errmsg = "New base range overlaps with existing base range."; > break; >@@ -409,6 +645,8 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype) > case 5: > errmsg = "New secondary rid range overlaps with existing primary rid range."; > break; >+ case 6: >+ errmsg = "New ID range has invalid type. All ranges in the same domain must be of the same type."; > default: > errmsg = "New range overlaps with existing one."; > break; >@@ -432,6 +670,14 @@ done: > slapi_entry_free(entry); > } > >+ /* Remove the domain info linked list from memory */ >+ struct domain_info *next; >+ while(domain_info_head) { >+ next = domain_info_head->next; >+ free(domain_info_head); >+ domain_info_head = next; >+ } >+ > if (ret != 0) { > if (errmsg == NULL) { > errmsg = "Range Check error"; >-- >1.8.5.3 > >_______________________________________________ >Freeipa-devel mailing list >Freeipa-devel at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-devel -- / Alexander Bokovoy From mkosek at redhat.com Tue Mar 18 09:00:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 18 Mar 2014 10:00:42 +0100 Subject: [Freeipa-devel] Talking json/rpc with java client In-Reply-To: References: Message-ID: <53280B3A.9080002@redhat.com> On 03/18/2014 09:02 AM, Marco Di Sabatino Di Diodoro wrote: > Hi all, > > what are the requirements or packages that a client must have to call JSON/RPC with java? We have a 401 error. > If we talking to freeipa json web api via curl it works. > > Suggestions? > M CCing Jan and Jan - either of them should be able to help. Martin From jpazdziora at redhat.com Tue Mar 18 09:10:35 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 18 Mar 2014 10:10:35 +0100 Subject: [Freeipa-devel] Talking json/rpc with java client In-Reply-To: References: Message-ID: <20140318091035.GA9052@redhat.com> On Tue, Mar 18, 2014 at 09:02:13AM +0100, Marco Di Sabatino Di Diodoro wrote: > > what are the requirements or packages that a client must have to call JSON/RPC with java? We have a 401 error. What packages / code do you attempt to use when you get that 401? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From massimiliano.perrone at tirasa.net Tue Mar 18 09:48:18 2014 From: massimiliano.perrone at tirasa.net (Massimiliano Perrone (tirasa.net)) Date: Tue, 18 Mar 2014 10:48:18 +0100 Subject: [Freeipa-devel] Talking json/rpc with java client In-Reply-To: <20140318091035.GA9052@redhat.com> References: <20140318091035.GA9052@redhat.com> Message-ID: <53281662.3030105@tirasa.net> On 03/18/2014 10:10 AM, Jan Pazdziora wrote: > On Tue, Mar 18, 2014 at 09:02:13AM +0100, Marco Di Sabatino Di Diodoro wrote: >> what are the requirements or packages that a client must have to call JSON/RPC with java? We have a 401 error. > What packages / code do you attempt to use when you get that 401? > Hi guys, first of all thanks for your replies. Summarizing... 1) On FreeIPA server I created a keytab executing following commands: *) ipa host-add ebano.example.com *) ipa service-add HTTP/ebano.example.com *) ipa-getkeytab -s olmo.example.com -p HTTP/ebano.example.com -k /tmp/ebano.keytab *) scp /tmp/ebano.keytab root at ebano:/var/tmp 2) On ebano (the client machine) I have a Java client based on HttpClient 3.1 that uses this java.security.auth.login.config file: ######################################### un.security.jgss.login { com.sun.security.auth.module.Krb5LoginModule required client=TRUE refreshKrb5Config=true useKeyTab=true keyTab="/var/tmp/ebano.keytab" principal="HTTP/ebano.example.com"; }; com.sun.security.jgss.initiate { com.sun.security.auth.module.Krb5LoginModule required client=TRUE refreshKrb5Config=true useKeyTab=true keyTab="/var/tmp/ebano.keytab" principal="HTTP/ebano.example.com"; }; com.sun.security.jgss.accept { com.sun.security.auth.module.Krb5LoginModule required client=TRUE refreshKrb5Config=true useKeyTab=true keyTab="/var/tmp/ebano.keytab" principal="HTTP/ebano.example.com"; }; ######################################### As you can see in attached log file, I can negotiate authentication on FreeIPA server and final response from it is a 401 10:16:36.407 [net.tirasa.freeipa.FreeIPA.main()] DEBUG org.apache.http.wire - << "{" 10:16:36.407 [net.tirasa.freeipa.FreeIPA.main()] DEBUG org.apache.http.wire - << "[\n]" 10:16:36.407 [net.tirasa.freeipa.FreeIPA.main()] DEBUG org.apache.http.wire - << " "error": {[\n]" 10:16:36.407 [net.tirasa.freeipa.FreeIPA.main()] DEBUG org.apache.http.wire - << " "code": 1101, [\n]" 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG org.apache.http.wire - << " "message": "did not receive Kerberos credentials", [\n]" 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG org.apache.http.wire - << " "name": {[\n]" 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG org.apache.http.wire - << " "__base64__": "Q0NhY2hlRXJyb3I="[\n]" 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG org.apache.http.wire - << " }[\n]" 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG org.apache.http.wire - << " }, [\n]" 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG org.apache.http.wire - << " "id": null, [\n]" 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG org.apache.http.wire - << " "principal": "UNKNOWN", [\n]" 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG org.apache.http.wire - << " "result": null, [\n]" 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG org.apache.http.wire - << " "version": "3.3.4"[\n]" 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG org.apache.http.wire - << "}" But... Reading Kerberos server log I noticed that a right curl based call generates a mar 18 08:20:12 olmo.example.com krb5kdc[1423](info): TGS_REQ (1 etypes {18}) 192.168.0.105: ISSUE: authtime 1395072185, etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM mar 18 08:20:13 olmo.example.com krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime 1395072185, etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for ldap/olmo.example.com at EXAMPLE.COM whereas Java client generates a mar 17 19:48:21 olmo.example.com krb5kdc[1423](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.105: NEEDED_PREAUTH: HTTP/ebano.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required mar 17 19:48:21 olmo.example.com krb5kdc[1423](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.105: ISSUE: authtime 1395082101, etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM mar 17 19:48:21 olmo.example.com krb5kdc[1423](info): TGS_REQ (6 etypes {18 17 16 23 1 3}) 192.168.0.105: ISSUE: authtime 1395082101, etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for HTTP/olmo.example.com at EXAMPLE.COM The difference between the two calls is on the last TGS_REQ; because the first one is on ldap/olmo.example.com at EXAMPLE.COM and it's OK whereas the second one is on HTTP/olmo.example.com at EXAMPLE.COM that returns a 401 (I suppose). Where's the error? Thanks for your help. -- Massimiliano Perrone Tel +39 393 9121310 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.example.com Apache Syncope PMC Member http://people.apache.org/~massi/ "L'apprendere molte cose non insegna l'intelligenza" (Eraclito) -------------- next part -------------- A non-text attachment was scrubbed... Name: httpclient.log Type: text/x-log Size: 33784 bytes Desc: not available URL: From abokovoy at redhat.com Tue Mar 18 10:26:43 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Mar 2014 12:26:43 +0200 Subject: [Freeipa-devel] Talking json/rpc with java client In-Reply-To: <53281662.3030105@tirasa.net> References: <20140318091035.GA9052@redhat.com> <53281662.3030105@tirasa.net> Message-ID: <20140318102643.GC16644@redhat.com> On Tue, 18 Mar 2014, Massimiliano Perrone (tirasa.net) wrote: >On 03/18/2014 10:10 AM, Jan Pazdziora wrote: >>On Tue, Mar 18, 2014 at 09:02:13AM +0100, Marco Di Sabatino Di Diodoro wrote: >>>what are the requirements or packages that a client must have to call JSON/RPC with java? We have a 401 error. >>What packages / code do you attempt to use when you get that 401? >> > >Hi guys, first of all thanks for your replies. > >Summarizing... > >1) On FreeIPA server I created a keytab executing following commands: > *) ipa host-add ebano.example.com > *) ipa service-add HTTP/ebano.example.com > *) ipa-getkeytab -s olmo.example.com -p >HTTP/ebano.example.com -k /tmp/ebano.keytab > *) scp /tmp/ebano.keytab root at ebano:/var/tmp > >2) On ebano (the client machine) I have a Java client based on >HttpClient 3.1 that uses this java.security.auth.login.config file: >######################################### >un.security.jgss.login { > com.sun.security.auth.module.Krb5LoginModule required > client=TRUE > refreshKrb5Config=true > useKeyTab=true > keyTab="/var/tmp/ebano.keytab" > principal="HTTP/ebano.example.com"; >}; > >com.sun.security.jgss.initiate { > com.sun.security.auth.module.Krb5LoginModule required > client=TRUE > refreshKrb5Config=true > useKeyTab=true > keyTab="/var/tmp/ebano.keytab" > principal="HTTP/ebano.example.com"; > >}; > >com.sun.security.jgss.accept { > com.sun.security.auth.module.Krb5LoginModule required > client=TRUE > refreshKrb5Config=true > useKeyTab=true > keyTab="/var/tmp/ebano.keytab" > principal="HTTP/ebano.example.com"; >}; >######################################### > >As you can see in attached log file, I can negotiate authentication >on FreeIPA server and final response from it is a 401 > >10:16:36.407 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >org.apache.http.wire - << "{" >10:16:36.407 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >org.apache.http.wire - << "[\n]" >10:16:36.407 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >org.apache.http.wire - << " "error": {[\n]" >10:16:36.407 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >org.apache.http.wire - << " "code": 1101, [\n]" >10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >org.apache.http.wire - << " "message": "did not receive >Kerberos credentials", [\n]" >10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >org.apache.http.wire - << " "name": {[\n]" >10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >org.apache.http.wire - << " "__base64__": >"Q0NhY2hlRXJyb3I="[\n]" >10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >org.apache.http.wire - << " }[\n]" >10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >org.apache.http.wire - << " }, [\n]" >10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >org.apache.http.wire - << " "id": null, [\n]" >10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >org.apache.http.wire - << " "principal": "UNKNOWN", [\n]" >10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >org.apache.http.wire - << " "result": null, [\n]" >10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >org.apache.http.wire - << " "version": "3.3.4"[\n]" >10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >org.apache.http.wire - << "}" > >But... > >Reading Kerberos server log I noticed that a right curl based call >generates a >mar 18 08:20:12 olmo.example.com krb5kdc[1423](info): TGS_REQ (1 >etypes {18}) 192.168.0.105: ISSUE: authtime 1395072185, etypes >{rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for >krbtgt/EXAMPLE.COM at EXAMPLE.COM >mar 18 08:20:13 olmo.example.com krb5kdc[1423](info): TGS_REQ (6 >etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime >1395072185, etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for >ldap/olmo.example.com at EXAMPLE.COM > >whereas Java client generates a > >mar 17 19:48:21 olmo.example.com krb5kdc[1423](info): AS_REQ (4 >etypes {18 17 16 23}) 192.168.0.105: NEEDED_PREAUTH: >HTTP/ebano.example.com at EXAMPLE.COM for >krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication >required >mar 17 19:48:21 olmo.example.com krb5kdc[1423](info): AS_REQ (4 >etypes {18 17 16 23}) 192.168.0.105: ISSUE: authtime 1395082101, >etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for >krbtgt/EXAMPLE.COM at EXAMPLE.COM >mar 17 19:48:21 olmo.example.com krb5kdc[1423](info): TGS_REQ (6 >etypes {18 17 16 23 1 3}) 192.168.0.105: ISSUE: authtime 1395082101, >etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for >HTTP/olmo.example.com at EXAMPLE.COM > >The difference between the two calls is on the last TGS_REQ; because >the first one is on ldap/olmo.example.com at EXAMPLE.COM and it's OK >whereas the second one is on HTTP/olmo.example.com at EXAMPLE.COM that >returns a 401 (I suppose). > >Where's the error? Am I correct that you have a user connecting to HTTP/ebano.example.com and then HTTP/ebano.example.com wants to talk to HTTP/olmo.example.com using credentials of the user? FreeIPA uses constraint delegation of the credentials, with the help of S4U2Proxy extension. You need to allow HTTP/ebano.example.com to delegate credentials to HTTP/olmo.example.com. I have written an article how to do that: https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html -- / Alexander Bokovoy From pviktori at redhat.com Tue Mar 18 11:02:06 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 18 Mar 2014 12:02:06 +0100 Subject: [Freeipa-devel] [PATCHES] 0499-0502 permission CLI: rename --permissions to --right Message-ID: <532827AE.5040403@redhat.com> Hello, This renames --permissions to --right. The old name is kept as a deprecated alias. FreeIPA didn't have a mechanism for doing this, so I added one. Also, while I was digging around in this part, I made the new IntEnum (and all future Enums) act like StrEnum in --help output. https://fedorahosted.org/freeipa/ticket/4231 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0499-cli-Clean-up-imports.patch Type: text/x-patch Size: 1291 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0500-cli-Show-list-of-values-in-help-for-all-Enums.patch Type: text/x-patch Size: 1680 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0501-cli-Add-mechanism-for-deprecated-option-name-aliases.patch Type: text/x-patch Size: 4366 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0502-permission-CLI-rename-permissions-to-right.patch Type: text/x-patch Size: 5098 bytes Desc: not available URL: From pviktori at redhat.com Tue Mar 18 11:42:09 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 18 Mar 2014 12:42:09 +0100 Subject: [Freeipa-devel] [PATCH] 0147: ipaserver/rpcserver: catch ACIError and return proper message for out-of-realm users In-Reply-To: <20140312103713.GE2735@redhat.com> References: <20140306100323.GN16644@redhat.com> <20140312103713.GE2735@redhat.com> Message-ID: <53283111.1090003@redhat.com> On 03/12/2014 11:37 AM, Jan Pazdziora wrote: > On Thu, Mar 06, 2014 at 12:03:23PM +0200, Alexander Bokovoy wrote: >> Hi, >> >> we had similar issue in past, in jsonserver_session() class, fixed by >> 0292ebd1 which Tomas did for ticket https://fedorahosted.org/freeipa/ticket/3252 >> >> This one is for non-sessioned call: >> https://fedorahosted.org/freeipa/ticket/4225 > > The patch does not seem to apply against master. > The __call__ method was consolidated in KerberosWSGIExecutioner in commit 6a2b7094. If the PublicError handling -- success status with marshalled error -- is not enough, we can add the try/except there. -- Petr? From pvoborni at redhat.com Tue Mar 18 12:09:09 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 18 Mar 2014 13:09:09 +0100 Subject: [Freeipa-devel] [PATCH] 552-557 Permissions v2 Web UI In-Reply-To: <53270527.8030202@redhat.com> References: <532340AE.9030900@redhat.com> <53270527.8030202@redhat.com> Message-ID: <53283765.2080402@redhat.com> New revision for patch patch #557 attached. On 17.3.2014 15:22, Petr Viktorin wrote: > On 03/14/2014 06:47 PM, Petr Vobornik wrote: >> Main ACI UI changes are in patch #557. The rest are prerequisites. > > With this UI it is impossible to change from "Type-based" permissions to > "General" ones. This seems to be remaining from the old model where > permissions were type/filter/subtree/targetgroup were "classes" of a > permission rather than co-existing as attributes. > > Rather the Target section should IMO look the same for all (non-managed) > permissions, with the first items being: > Type: [drop-down with a None option] > Subtree: [textbox that is disabled when a Type is selected] > > The Subtree should be a one-line textbox. It would be acceptable if the > whole DN doesn't always fit, it's the first part that's important. > > Remember to only send Subtree if Type is (staying as | being set to) None. > > Also, the Add dialog should use this instead of the "Define by". Done > > > > With managed permissions, if I try to change both included/excluded > attribute list and the effective attributes, I get a validation error, > which is good in CLI but it doesn't work well for the UI. > > I think it would be better to move "Managed permission overrides" below > "Target", and make it read-only. And perhaps rename it to something like > "Attribute breakdown". > Managing the included/excluded lists directly is only useful for > upgrades with a heavily customized policy, and for upgrades you need the > CLI anyway. Normally, having only the attribute list editable should be > fine. Done > > > > For SYSTEM permissions (those which only have the SYSTEM flag), such as > 'Add Automember Rebuild Membership Task', Permissions should not be > editable. > For old-style permissions (those without any flags), nothing is editable > but everything should be. The attributelevelrights are missing because > the entry doesn't have the ipaPermissionV2 objectclass yet (although > it's being reported, which is "my" bug -- #4257). Fields were set to be editable if attributes level rights are missing. > > > I filed these tickets based on face-to-face discussion about this and > the UI in general: > https://fedorahosted.org/freeipa/ticket/4253 Attribute box un permission > UI is too small > https://fedorahosted.org/freeipa/ticket/4254 Managed permission UI: use > read-only fields instead of disabled ones > https://fedorahosted.org/freeipa/ticket/4255 Web UI: Display "Loading" > message when a list of entries is being loaded > > >> These changes requested the unpopular update of JSON metadata files - >> it's for tests. This patch(#552) is compressed, otherwise it has 930KB. > > :( > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0557-1-webui-change-permissions-UI-to-v2.patch Type: text/x-patch Size: 46244 bytes Desc: not available URL: From pviktori at redhat.com Tue Mar 18 13:34:29 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 18 Mar 2014 14:34:29 +0100 Subject: [Freeipa-devel] [DOC] 0006 Chapter 5 update In-Reply-To: <1380214338.2142.9.camel@unused-4-145.brq.redhat.com> References: <1380214338.2142.9.camel@unused-4-145.brq.redhat.com> Message-ID: <53284B65.9000601@redhat.com> On 09/26/2013 06:52 PM, Martin Basti wrote: > Patch for chapter 5 > > Contains patch for ticket > https://fedorahosted.org/freeipa/ticket/3842 Hello, Thanks for the patches! Next time, when you do multiple changes, please split them into multiple patches. Each of the bullet points in the commit message could have been a separate patch. However splitting the patch now is probably not worth the effort. I did however split the whitespace fixes to make my job easier. I also rebased a minor conflict. Attaching the patches for convenience. In section 5.1.3 the examples are missing the [user at ipaserver ~] prompt. In section 5.2.2.2 there's an extra `$` prompt that's not present in other syntax examples. Section 5.2.4.1. should not be an ordered list since it presents two ways to do the same thing. In Table 5.3, instead of removing posixgroup altogether you should mention that it's only added for POSIX groups. Otherwise the changes look good. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-docs-pviktori-0001-Chapter-5-Users-Remove-trailing-whitespace.patch Type: text/x-patch Size: 47849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0006+pviktori-Chapter-5-fixed-images-examples-added-new-TIPs.patch Type: text/x-patch Size: 1922066 bytes Desc: not available URL: From pviktori at redhat.com Tue Mar 18 14:07:35 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 18 Mar 2014 15:07:35 +0100 Subject: [Freeipa-devel] [PATCH] 552-557 Permissions v2 Web UI In-Reply-To: <53283765.2080402@redhat.com> References: <532340AE.9030900@redhat.com> <53270527.8030202@redhat.com> <53283765.2080402@redhat.com> Message-ID: <53285327.9060907@redhat.com> On 03/18/2014 01:09 PM, Petr Vobornik wrote: > New revision for patch patch #557 attached. > > On 17.3.2014 15:22, Petr Viktorin wrote: >> On 03/14/2014 06:47 PM, Petr Vobornik wrote: >>> Main ACI UI changes are in patch #557. The rest are prerequisites. >> >> With this UI it is impossible to change from "Type-based" permissions to >> "General" ones. This seems to be remaining from the old model where >> permissions were type/filter/subtree/targetgroup were "classes" of a >> permission rather than co-existing as attributes. >> >> Rather the Target section should IMO look the same for all (non-managed) >> permissions, with the first items being: >> Type: [drop-down with a None option] >> Subtree: [textbox that is disabled when a Type is selected] >> >> The Subtree should be a one-line textbox. It would be acceptable if the >> whole DN doesn't always fit, it's the first part that's important. >> >> Remember to only send Subtree if Type is (staying as | being set to) >> None. >> >> Also, the Add dialog should use this instead of the "Define by". > > Done > >> >> >> >> With managed permissions, if I try to change both included/excluded >> attribute list and the effective attributes, I get a validation error, >> which is good in CLI but it doesn't work well for the UI. >> >> I think it would be better to move "Managed permission overrides" below >> "Target", and make it read-only. And perhaps rename it to something like >> "Attribute breakdown". >> Managing the included/excluded lists directly is only useful for >> upgrades with a heavily customized policy, and for upgrades you need the >> CLI anyway. Normally, having only the attribute list editable should be >> fine. > > Done > >> >> >> >> For SYSTEM permissions (those which only have the SYSTEM flag), such as >> 'Add Automember Rebuild Membership Task', Permissions should not be >> editable. >> For old-style permissions (those without any flags), nothing is editable >> but everything should be. The attributelevelrights are missing because >> the entry doesn't have the ipaPermissionV2 objectclass yet (although >> it's being reported, which is "my" bug -- #4257). > > Fields were set to be editable if attributes level rights are missing. That solves things for normal legacy permissions, but not for the SYSTEM ones - those should be completely read-only. Also, changing the Permisisons checkboxes on these permissions doesn't mark them dirty. Otherwise the patches work great! -- Petr? From pviktori at redhat.com Tue Mar 18 14:45:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 18 Mar 2014 15:45:46 +0100 Subject: [Freeipa-devel] [PATCH] Review: rga-0005 Fix order of synchronizing time when running ipa-client-install Message-ID: <53285C1A.6010409@redhat.com> AFAIK this patch was only posted to Trac, where it was kind of forgotten. Let's move it to the mailing list. It looks & works fine, ACK for those aspects. But Dmitri had some concerns about the validity of the ticket itself: > Unusual but not critical. In future this can be an OTP prompt rather than > password prompt and making sure time is correct on both sides might be > more critical. I do not see a big problem with a slight delay. Banks now > prompt people for user name on one page and then for password on another. > It is a common practice. I would think that decoupling the prompts and > getting people used to it is a benefit rather than a hassle. The trend > of prompting for user and password independently should continue. > We should make it more usable if there are usability concerns but IMO we > should not be trying to push people back to traditional notion of "user > name and password are always together". They are not. It may be common practice but it doesn't really make sense to temporally split related actions if there's no need for it. It is annoying. In the banks case, the login pages follow one another, they don't insert some completely unrelated output in the middle of the login process. If we want to teach new expectations to users, ipa-client-install is not the place to do it. The OTP case will work since with the patch, time is synced before both prompts. The comment gives a good reason to move the ticket to Backlog, but since we have a fix I'd like to push it. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0005-Fix-order-of-synchronizing-time-when-running-ipa-cli.patch Type: text/x-patch Size: 3577 bytes Desc: not available URL: From rcritten at redhat.com Tue Mar 18 14:50:38 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 18 Mar 2014 10:50:38 -0400 Subject: [Freeipa-devel] [PATCH] Review: rga-0005 Fix order of synchronizing time when running ipa-client-install In-Reply-To: <53285C1A.6010409@redhat.com> References: <53285C1A.6010409@redhat.com> Message-ID: <53285D3E.3050700@redhat.com> Petr Viktorin wrote: > AFAIK this patch was only posted to Trac, where it was kind of > forgotten. Let's move it to the mailing list. > > It looks & works fine, ACK for those aspects. But Dmitri had some > concerns about the validity of the ticket itself: > >> Unusual but not critical. In future this can be an OTP prompt rather than >> password prompt and making sure time is correct on both sides might be >> more critical. I do not see a big problem with a slight delay. Banks now >> prompt people for user name on one page and then for password on another. >> It is a common practice. I would think that decoupling the prompts and >> getting people used to it is a benefit rather than a hassle. The trend >> of prompting for user and password independently should continue. >> We should make it more usable if there are usability concerns but IMO we >> should not be trying to push people back to traditional notion of "user >> name and password are always together". They are not. > > It may be common practice but it doesn't really make sense to temporally > split related actions if there's no need for it. It is annoying. In the > banks case, the login pages follow one another, they don't insert some > completely unrelated output in the middle of the login process. > If we want to teach new expectations to users, ipa-client-install is not > the place to do it. > The OTP case will work since with the patch, time is synced before both > prompts. > > The comment gives a good reason to move the ticket to Backlog, but since > we have a fix I'd like to push it. IIRC Alexander purposely put the time sync in here to ensure that at the time we actually obtain the password time is in sync. I can't say I always agreed with that, but it does make a certain amount of sense. rob From pviktori at redhat.com Tue Mar 18 15:04:46 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 18 Mar 2014 16:04:46 +0100 Subject: [Freeipa-devel] [PATCH] Review: rga-0005 Fix order of synchronizing time when running ipa-client-install In-Reply-To: <53285D3E.3050700@redhat.com> References: <53285C1A.6010409@redhat.com> <53285D3E.3050700@redhat.com> Message-ID: <5328608E.8070403@redhat.com> On 03/18/2014 03:50 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> AFAIK this patch was only posted to Trac, where it was kind of >> forgotten. Let's move it to the mailing list. >> >> It looks & works fine, ACK for those aspects. But Dmitri had some >> concerns about the validity of the ticket itself: >> >>> Unusual but not critical. In future this can be an OTP prompt rather >>> than >>> password prompt and making sure time is correct on both sides might be >>> more critical. I do not see a big problem with a slight delay. Banks now >>> prompt people for user name on one page and then for password on >>> another. >>> It is a common practice. I would think that decoupling the prompts and >>> getting people used to it is a benefit rather than a hassle. The trend >>> of prompting for user and password independently should continue. >>> We should make it more usable if there are usability concerns but IMO we >>> should not be trying to push people back to traditional notion of "user >>> name and password are always together". They are not. >> >> It may be common practice but it doesn't really make sense to temporally >> split related actions if there's no need for it. It is annoying. In the >> banks case, the login pages follow one another, they don't insert some >> completely unrelated output in the middle of the login process. >> If we want to teach new expectations to users, ipa-client-install is not >> the place to do it. >> The OTP case will work since with the patch, time is synced before both >> prompts. >> >> The comment gives a good reason to move the ticket to Backlog, but since >> we have a fix I'd like to push it. > > IIRC Alexander purposely put the time sync in here to ensure that at the > time we actually obtain the password time is in sync. I can't say I > always agreed with that, but it does make a certain amount of sense. Was that really a conscious decision? The only thing between the old and new calls of the sync is the actual password entry. I don't think we should worry about clocks de-syncing while the admin enters a password. -- Petr? From tbabej at redhat.com Tue Mar 18 15:06:38 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 18 Mar 2014 16:06:38 +0100 Subject: [Freeipa-devel] [PATCH 0158] Extend ipa-range-check DS plugin to handle range types In-Reply-To: <20140318081917.GZ16644@redhat.com> References: <5327158D.1020408@redhat.com> <20140318081917.GZ16644@redhat.com> Message-ID: <532860FE.2040203@redhat.com> On 03/18/2014 09:19 AM, Alexander Bokovoy wrote: > On Mon, 17 Mar 2014, Tomas Babej wrote: >> Hi, >> >> The ipa-range-check plugin used to determine the range type depending >> on the value of the attributes such as RID or secondary RID base. This >> approached caused variety of issues since the portfolio of ID range >> types expanded. >> >> The patch makes sure the following rules are implemented: >> * No ID range pair can overlap on base ranges, with exception >> of two ipa-ad-trust-posix ranges belonging to the same forest >> * For any ID range pair of ranges belonging to the same domain: >> * Both ID ranges must be of the same type >> * For ranges of ipa-ad-trust type or ipa-local type: >> * Primary RID ranges can not overlap >> * For ranges of ipa-local type: >> * Primary and secondary RID ranges can not overlap >> * Secondary RID ranges cannot overlap >> >> For the implementation part, the plugin was extended with a domain ID >> to forest root domain ID mapping derivation capabilities. >> >> https://fedorahosted.org/freeipa/ticket/4137 >> >> Test coverage coming soon! > > I don't really like that you are using a list here. The list is built > and then destroyed in preop callback every time we process the range > object, so it is one-off operation. Now, when you fetch trust domain > objects to build the list, why can't you use an array directly? > > Given that all you need the list for is to map domain to a trust (if > any) and trust name is the name of the root level domain, you can simply > make an array of a struct (name, root) where root is a and index to the > same array or -1 if this is the root domain itself. I don't see much benefit of using array over linked list in this case. In both cases, we would need to build the data container, and it would be one-off operation (once for the ADD/MOD operation). Additionaly, using linked list, I can only pass around the pointer to the head of the list, instead of passing around the array and it's size. I reworked the part of the patch that fetches the data from the LDAP as we discussed. Instead of performing multiple LDAP searches, we do a single extra search per operation. > > > >> >> >> -- >> Tomas Babej >> Associate Software Engeneer | Red Hat | Identity Management >> RHCE | Brno Site | IRC: tbabej | freeipa.org >> >> > >>> From 0d038fb71f02fab5320e4843be80feb34c5c3303 Mon Sep 17 00:00:00 2001 >> From: Tomas Babej >> Date: Wed, 5 Mar 2014 12:28:18 +0100 >> Subject: [PATCH] Extend ipa-range-check DS plugin to handle range types >> >> The ipa-range-check plugin used to determine the range type depending >> on the value of the attributes such as RID or secondary RID base. This >> approached caused variety of issues since the portfolio of ID range >> types expanded. >> >> The patch makes sure the following rules are implemented: >> * No ID range pair can overlap on base ranges, with exception >> of two ipa-ad-trust-posix ranges belonging to the same forest >> * For any ID range pair of ranges belonging to the same domain: >> * Both ID ranges must be of the same type >> * For ranges of ipa-ad-trust type or ipa-local type: >> * Primary RID ranges can not overlap >> * For ranges of ipa-local type: >> * Primary and secondary RID ranges can not overlap >> * Secondary RID ranges cannot overlap >> >> For the implementation part, the plugin was extended with a domain ID >> to forest root domain ID mapping derivation capabilities. >> >> https://fedorahosted.org/freeipa/ticket/4137 >> --- >> .../ipa-range-check/ipa_range_check.c | 322 >> ++++++++++++++++++--- >> 1 file changed, 284 insertions(+), 38 deletions(-) >> >> diff --git >> a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >> b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >> index >> 391e2259b6eced31fed399c927cfe44c1d3e237e..2360e42025a0146a43c3237914c8165d35714a68 >> 100644 >> --- a/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >> +++ b/daemons/ipa-slapi-plugins/ipa-range-check/ipa_range_check.c >> @@ -47,10 +47,17 @@ >> #define IPA_CN "cn" >> #define IPA_BASE_ID "ipaBaseID" >> #define IPA_ID_RANGE_SIZE "ipaIDRangeSize" >> +#define IPA_RANGE_TYPE "ipaRangeType" >> #define IPA_BASE_RID "ipaBaseRID" >> #define IPA_SECONDARY_BASE_RID "ipaSecondaryBaseRID" >> #define IPA_DOMAIN_ID "ipaNTTrustedDomainSID" >> #define RANGES_FILTER "objectclass=ipaIDRange" >> +#define DOMAIN_ID_FILTER "ipaNTTrustedDomainSID=*" >> + >> +#define AD_TRUST_RANGE_TYPE "ipa-ad-trust" >> +#define AD_TRUST_POSIX_RANGE_TYPE "ipa-ad-trust-posix" >> +#define LOCAL_RANGE_TYPE "ipa-local" >> + >> >> #define IPA_PLUGIN_NAME "ipa-range-check" >> #define IPA_RANGE_CHECK_FEATURE_DESC "IPA ID range check plugin" >> @@ -72,13 +79,225 @@ struct ipa_range_check_ctx { >> struct range_info { >> char *name; >> char *domain_id; >> + char *forest_root_id; >> + char *id_range_type; >> uint32_t base_id; >> uint32_t id_range_size; >> uint32_t base_rid; >> uint32_t secondary_base_rid; >> }; >> >> -static int slapi_entry_to_range_info(struct slapi_entry *entry, >> +struct domain_info { >> + char *domain_id; >> + char *forest_root_id; >> + struct domain_info *next; >> +}; >> + >> + >> +static struct domain_info* map_domain_to_root(struct domain_info *head, >> + struct slapi_entry >> *domain, >> + struct slapi_entry >> *root_domain){ >> + >> + struct domain_info* new_head = NULL; >> + new_head = (struct domain_info*) malloc(sizeof(struct >> domain_info)); >> + if (new_head == NULL) { >> + return NULL; >> + } >> + >> + new_head->domain_id = slapi_entry_attr_get_charptr(domain, >> + IPA_DOMAIN_ID); >> + new_head->forest_root_id = >> slapi_entry_attr_get_charptr(root_domain, >> + >> IPA_DOMAIN_ID); >> + new_head->next = head; >> + >> + return new_head; >> +} >> + >> +/* Searches for the domain_info struct with the specified domain_id >> + * in the linked list. Returns the forest root domain's ID, or NULL for >> + * local ranges. */ >> + >> +static char* get_forest_root_id(struct domain_info *head, char* >> domain_id) { >> + >> + /* For local ranges there is no forest root domain, >> + * so consider only ranges with domain_id set */ >> + if (domain_id != NULL) { >> + while(head) { >> + if (strcasecmp(head->domain_id, domain_id) == 0) { >> + return head->forest_root_id; >> + } >> + head = head->next; >> + } >> + } >> + >> + return NULL; >> +} >> + >> + >> +/* >> + * This function builds a mapping from domain ID to forest >> + * root domain ID. >> + */ >> + >> +static struct domain_info* build_domain_to_forest_root_map(struct >> domain_info *head, >> + struct >> ipa_range_check_ctx *ctx){ >> + >> + Slapi_PBlock *root_domain_search_pb = NULL; >> + Slapi_PBlock *child_domain_search_pb = NULL; >> + Slapi_Entry **root_domain_entries = NULL; >> + Slapi_Entry **child_domain_entries = NULL; >> + Slapi_DN *base_dn = NULL; >> + Slapi_RDN *rdn = NULL; >> + >> + int search_result; >> + int ret; >> + >> + /* Set the base DN for the search to cn=ad, cn=trusts, $SUFFIX */ >> + base_dn = slapi_sdn_new_dn_byref(ctx->base_dn); >> + if (base_dn == NULL) { >> + LOG_FATAL("Failed to convert base DN.\n"); >> + ret = LDAP_OPERATIONS_ERROR; >> + goto done; >> + } >> + >> + rdn = slapi_rdn_new(); >> + if (rdn == NULL) { >> + LOG_FATAL("Failed to obtain RDN struct.\n"); >> + ret = LDAP_OPERATIONS_ERROR; >> + goto done; >> + } >> + >> + slapi_rdn_add(rdn, "cn", "trusts"); >> + slapi_sdn_add_rdn(base_dn, rdn); >> + slapi_rdn_done(rdn); >> + >> + slapi_rdn_add(rdn, "cn", "ad"); >> + slapi_sdn_add_rdn(base_dn, rdn); >> + slapi_rdn_done(rdn); >> + >> + /* Allocate a new parameter block */ >> + root_domain_search_pb = slapi_pblock_new(); >> + if (root_domain_search_pb == NULL) { >> + LOG_FATAL("Failed to create new pblock.\n"); >> + ret = LDAP_OPERATIONS_ERROR; >> + //goto done; >> + } >> + >> + /* Search for all the root domains, note the LDAP_SCOPE_ONELEVEL */ >> + slapi_search_internal_set_pb(root_domain_search_pb, >> + slapi_sdn_get_dn(base_dn), >> + LDAP_SCOPE_ONELEVEL, DOMAIN_ID_FILTER, >> + NULL, 0, NULL, NULL, >> ctx->plugin_id, 0); >> + >> + ret = slapi_search_internal_pb(root_domain_search_pb); >> + if (ret != 0) { >> + LOG_FATAL("Starting internal search failed.\n"); >> + goto done; >> + } >> + >> + ret = slapi_pblock_get(root_domain_search_pb, >> SLAPI_PLUGIN_INTOP_RESULT, &search_result); >> + if (ret != 0 || search_result != LDAP_SUCCESS) { >> + LOG_FATAL("Internal search failed.\n"); >> + ret = LDAP_OPERATIONS_ERROR; >> + goto done; >> + } >> + >> + ret = slapi_pblock_get(root_domain_search_pb, >> SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, >> + &root_domain_entries); >> + >> + if (ret != 0) { >> + LOG_FATAL("Failed to read searched root domain entries.\n"); >> + goto done; >> + } >> + >> + if (root_domain_entries == NULL || root_domain_entries[0] == >> NULL) { >> + LOG("No existing root domain entries.\n"); >> + ret = 0; >> + goto done; >> + } >> + >> + /* now we iterate over root domains */ >> + for (int i = 0; root_domain_entries[i] != NULL; i++) { >> + /* map root domain to itself */ >> + head = map_domain_to_root(head, >> + root_domain_entries[i], >> + root_domain_entries[i]); >> + if (head == NULL) { >> + LOG_FATAL("Error when allocating new domain_info struct."); >> + goto child_done; >> + } >> + >> + /* let's reuse the variables */ >> + child_domain_search_pb = NULL; >> + child_domain_entries = NULL; >> + >> + /* allocate a new parameter block */ >> + child_domain_search_pb = slapi_pblock_new(); >> + if (child_domain_search_pb == NULL) { >> + LOG_FATAL("Failed to create new pblock.\n"); >> + ret = LDAP_OPERATIONS_ERROR; >> + goto child_done; >> + } >> + >> + /* search for all the child domains, note the >> LDAP_SCOPE_ONELEVEL */ >> + slapi_search_internal_set_pb(child_domain_search_pb, >> + >> slapi_entry_get_dn_const(root_domain_entries[i]), >> + LDAP_SCOPE_ONELEVEL, >> DOMAIN_ID_FILTER, >> + NULL, 0, NULL, NULL, >> ctx->plugin_id, 0); >> + >> + ret = slapi_search_internal_pb(child_domain_search_pb); >> + if (ret != 0) { >> + LOG_FATAL("Starting internal search failed.\n"); >> + goto child_done; >> + } >> + >> + ret = slapi_pblock_get(child_domain_search_pb, >> SLAPI_PLUGIN_INTOP_RESULT, &search_result); >> + if (ret != 0 || search_result != LDAP_SUCCESS) { >> + LOG_FATAL("Internal search failed.\n"); >> + ret = LDAP_OPERATIONS_ERROR; >> + goto child_done; >> + } >> + >> + ret = slapi_pblock_get(child_domain_search_pb, >> SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, >> + &child_domain_entries); >> + >> + if (ret != 0) { >> + LOG_FATAL("Failed to read searched child domain >> entries.\n"); >> + goto child_done; >> + } >> + >> + if (child_domain_entries == NULL || child_domain_entries[0] >> == NULL) { >> + LOG("No existing child domain entries.\n"); >> + ret = 0; >> + goto child_done; >> + } >> + >> + /* Now we iterate over child domains */ >> + for (int j = 0; child_domain_entries[j] != NULL; j++) { >> + >> + /* map each child domain to the root domain */ >> + head = map_domain_to_root(head, >> + child_domain_entries[j], >> + root_domain_entries[i]); >> + >> + } >> + >> + child_done: >> + slapi_free_search_results_internal(child_domain_search_pb); >> + slapi_pblock_destroy(child_domain_search_pb); >> + } >> + >> +done: >> + slapi_free_search_results_internal(root_domain_search_pb); >> + slapi_pblock_destroy(root_domain_search_pb); >> + slapi_rdn_free(&rdn); >> + >> + return head; >> + >> +} >> + >> +static int slapi_entry_to_range_info(struct domain_info >> *domain_info_head, >> + struct slapi_entry *entry, >> struct range_info **_range) >> { >> int ret; >> @@ -97,6 +316,9 @@ static int slapi_entry_to_range_info(struct >> slapi_entry *entry, >> } >> >> range->domain_id = slapi_entry_attr_get_charptr(entry, >> IPA_DOMAIN_ID); >> + range->id_range_type = slapi_entry_attr_get_charptr(entry, >> IPA_RANGE_TYPE); >> + range->forest_root_id = get_forest_root_id(domain_info_head, >> + range->domain_id); >> >> ul_val = slapi_entry_attr_get_ulong(entry, IPA_BASE_ID); >> if (ul_val == 0 || ul_val >= UINT32_MAX) { >> @@ -161,58 +383,67 @@ static bool intervals_overlap(uint32_t x, >> uint32_t base, uint32_t x_size, uint32 >> * | | / \ | >> * new range: base rid sec_rid >> **/ >> -static int ranges_overlap(struct range_info *r1, struct range_info *r2) >> +static int check_ranges(struct range_info *r1, struct range_info *r2) >> { >> + /* Do not check overlaps of range with the range itself */ >> if (r1->name != NULL && r2->name != NULL && >> strcasecmp(r1->name, r2->name) == 0) { >> return 0; >> } >> >> - /* check if base range overlaps with existing base range */ >> - if (intervals_overlap(r1->base_id, r2->base_id, >> - r1->id_range_size, r2->id_range_size)){ >> - return 1; >> + /* Check if base range overlaps with existing base range. >> + * Exception: ipa-ad-trust-posix ranges from the same forest */ >> + if (!(strcasecmp(r1->id_range_type, AD_TRUST_POSIX_RANGE_TYPE) && >> + strcasecmp(r2->id_range_type, AD_TRUST_POSIX_RANGE_TYPE) && >> + r1->forest_root_id != NULL && r2->forest_root_id !=NULL && >> + strcasecmp(r1->forest_root_id, r2->forest_root_id) == 0)) { >> + >> + if (intervals_overlap(r1->base_id, r2->base_id, >> + r1->id_range_size, r2->id_range_size)){ >> + return 1; >> + } >> + >> } >> >> - /* if both base_rid and secondary_base_rid = 0, the rid range is >> not set */ >> - bool rid_ranges_set = (r1->base_rid != 0 || >> r1->secondary_base_rid != 0) && >> - (r2->base_rid != 0 || >> r2->secondary_base_rid != 0); >> - >> - /** >> - * ipaNTTrustedDomainSID is not set for local ranges, use it to >> - * determine the type of the range **/ >> - bool local_ranges = r1->domain_id == NULL && r2->domain_id == NULL; >> - >> + /* Following checks apply for the ranges from the same domain */ >> bool ranges_from_same_domain = >> (r1->domain_id == NULL && r2->domain_id == NULL) || >> (r1->domain_id != NULL && r2->domain_id != NULL && >> strcasecmp(r1->domain_id, r2->domain_id) == 0); >> >> - /** >> - * in case rid range is not set or ranges belong to different >> domains >> - * we can skip rid range tests as they are irrelevant **/ >> - if (rid_ranges_set && ranges_from_same_domain){ >> - >> - /* check if rid range overlaps with existing rid range */ >> - if (intervals_overlap(r1->base_rid, r2->base_rid, >> - r1->id_range_size, r2->id_range_size)) >> - return 2; >> - >> - /** >> - * The following 3 checks are relevant only if both ranges >> are local. >> - * Check if secondary rid range overlaps with existing >> secondary rid >> - * range. **/ >> - if (local_ranges){ >> + if (ranges_from_same_domain) { >> + >> + /* Ranges from the same domain must have the same type */ >> + if (strcasecmp(r1->id_range_type, r2->id_range_type) != 0) { >> + return 6; >> + } >> + >> + /* For ipa-local or ipa-ad-trust range types primary RID >> ranges should >> + * not overlap */ >> + if (strcasecmp(r1->id_range_type, AD_TRUST_RANGE_TYPE) == 0 || >> + strcasecmp(r1->id_range_type, LOCAL_RANGE_TYPE) == 0) { >> + >> + /* Check if rid range overlaps with existing rid range */ >> + if (intervals_overlap(r1->base_rid, r2->base_rid, >> + r1->id_range_size, r2->id_range_size)) >> + return 2; >> + } >> + >> + /* The following 3 checks are relevant only if both ranges >> are local. */ >> + if (strcasecmp(r1->id_range_type, LOCAL_RANGE_TYPE) == 0){ >> + >> + /* Check if secondary RID range overlaps with existing >> secondary or >> + * primary RID range. */ >> if (intervals_overlap(r1->secondary_base_rid, >> r2->secondary_base_rid, r1->id_range_size, >> r2->id_range_size)) >> return 3; >> >> - /* check if rid range overlaps with existing secondary >> rid range */ >> + /* Check if RID range overlaps with existing secondary >> RID range */ >> if (intervals_overlap(r1->base_rid, r2->secondary_base_rid, >> r1->id_range_size, r2->id_range_size)) >> return 4; >> >> - /* check if secondary rid range overlaps with existing >> rid range */ >> + /* Check if secondary RID range overlaps with existing >> RID range */ >> if (intervals_overlap(r1->secondary_base_rid, r2->base_rid, >> r1->id_range_size, r2->id_range_size)) >> return 5; >> @@ -248,9 +479,10 @@ static int ipa_range_check_pre_op(Slapi_PBlock >> *pb, int modtype) >> int search_result; >> Slapi_Entry **search_entries = NULL; >> size_t c; >> - int no_overlap = 0; >> + int ranges_valid = 0; >> const char *check_attr; >> char *errmsg = NULL; >> + struct domain_info *domain_info_head = NULL; >> >> ret = slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, >> &is_repl_op); >> if (ret != 0) { >> @@ -337,7 +569,10 @@ static int ipa_range_check_pre_op(Slapi_PBlock >> *pb, int modtype) >> goto done; >> } >> >> - ret = slapi_entry_to_range_info(entry, &new_range); >> + /* build a linked list of domain_info structs */ >> + domain_info_head = >> build_domain_to_forest_root_map(domain_info_head, ctx); >> + >> + ret = slapi_entry_to_range_info(domain_info_head, entry, >> &new_range); >> if (ret != 0) { >> LOG_FATAL("Failed to convert LDAP entry to range struct.\n"); >> goto done; >> @@ -381,19 +616,20 @@ static int ipa_range_check_pre_op(Slapi_PBlock >> *pb, int modtype) >> } >> >> for (c = 0; search_entries[c] != NULL; c++) { >> - ret = slapi_entry_to_range_info(search_entries[c], &old_range); >> + ret = slapi_entry_to_range_info(domain_info_head, >> search_entries[c], >> + &old_range); >> if (ret != 0) { >> LOG_FATAL("Failed to convert LDAP entry to range >> struct.\n"); >> goto done; >> } >> >> - no_overlap = ranges_overlap(new_range, old_range); >> + ranges_valid = check_ranges(new_range, old_range); >> free(old_range); >> old_range = NULL; >> - if (no_overlap != 0) { >> + if (ranges_valid != 0) { >> ret = LDAP_CONSTRAINT_VIOLATION; >> >> - switch (no_overlap){ >> + switch (ranges_valid){ >> case 1: >> errmsg = "New base range overlaps with existing base >> range."; >> break; >> @@ -409,6 +645,8 @@ static int ipa_range_check_pre_op(Slapi_PBlock >> *pb, int modtype) >> case 5: >> errmsg = "New secondary rid range overlaps with >> existing primary rid range."; >> break; >> + case 6: >> + errmsg = "New ID range has invalid type. All ranges >> in the same domain must be of the same type."; >> default: >> errmsg = "New range overlaps with existing one."; >> break; >> @@ -432,6 +670,14 @@ done: >> slapi_entry_free(entry); >> } >> >> + /* Remove the domain info linked list from memory */ >> + struct domain_info *next; >> + while(domain_info_head) { >> + next = domain_info_head->next; >> + free(domain_info_head); >> + domain_info_head = next; >> + } >> + >> if (ret != 0) { >> if (errmsg == NULL) { >> errmsg = "Range Check error"; >> -- >> 1.8.5.3 >> > >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0159-2-Extend-ipa-range-check-DS-plugin-to-handle-range-typ.patch Type: text/x-patch Size: 16091 bytes Desc: not available URL: From abokovoy at redhat.com Tue Mar 18 15:08:22 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Mar 2014 17:08:22 +0200 Subject: [Freeipa-devel] [PATCH] Review: rga-0005 Fix order of synchronizing time when running ipa-client-install In-Reply-To: <53285C1A.6010409@redhat.com> References: <53285C1A.6010409@redhat.com> Message-ID: <20140318150822.GE16644@redhat.com> On Tue, 18 Mar 2014, Petr Viktorin wrote: > AFAIK this patch was only posted to Trac, where it was kind of > forgotten. Let's move it to the mailing list. > > It looks & works fine, ACK for those aspects. But Dmitri had some > concerns about the validity of the ticket itself: > >> Unusual but not critical. In future this can be an OTP prompt rather than >> password prompt and making sure time is correct on both sides might be >> more critical. I do not see a big problem with a slight delay. Banks now >> prompt people for user name on one page and then for password on another. >> It is a common practice. I would think that decoupling the prompts and >> getting people used to it is a benefit rather than a hassle. The trend >> of prompting for user and password independently should continue. >> We should make it more usable if there are usability concerns but IMO we >> should not be trying to push people back to traditional notion of "user >> name and password are always together". They are not. > > It may be common practice but it doesn't really make sense to > temporally split related actions if there's no need for it. It is > annoying. In the banks case, the login pages follow one another, they > don't insert some completely unrelated output in the middle of the > login process. If we want to teach new expectations to users, > ipa-client-install is not the place to do it. > The OTP case will work since with the patch, time is synced before > both prompts. > > The comment gives a good reason to move the ticket to Backlog, but > since we have a fix I'd like to push it. I'm ok with moving time sync prior to the user prompt. With newer Kerberos we also have means to defeat time issues as KDC and services can get time difference accounted from the TGT. I don't think there was any specific reason into splitting the sequence up, just time sync was put immediately before the operation where correct time mattered. So, there is no need to read in tea leaves too much. ;) -- / Alexander Bokovoy From abokovoy at redhat.com Tue Mar 18 15:09:02 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Mar 2014 17:09:02 +0200 Subject: [Freeipa-devel] [PATCH] Review: rga-0005 Fix order of synchronizing time when running ipa-client-install In-Reply-To: <5328608E.8070403@redhat.com> References: <53285C1A.6010409@redhat.com> <53285D3E.3050700@redhat.com> <5328608E.8070403@redhat.com> Message-ID: <20140318150902.GF16644@redhat.com> On Tue, 18 Mar 2014, Petr Viktorin wrote: >On 03/18/2014 03:50 PM, Rob Crittenden wrote: >>Petr Viktorin wrote: >>>AFAIK this patch was only posted to Trac, where it was kind of >>>forgotten. Let's move it to the mailing list. >>> >>>It looks & works fine, ACK for those aspects. But Dmitri had some >>>concerns about the validity of the ticket itself: >>> >>>>Unusual but not critical. In future this can be an OTP prompt rather >>>>than >>>>password prompt and making sure time is correct on both sides might be >>>>more critical. I do not see a big problem with a slight delay. Banks now >>>>prompt people for user name on one page and then for password on >>>>another. >>>>It is a common practice. I would think that decoupling the prompts and >>>>getting people used to it is a benefit rather than a hassle. The trend >>>>of prompting for user and password independently should continue. >>>>We should make it more usable if there are usability concerns but IMO we >>>>should not be trying to push people back to traditional notion of "user >>>>name and password are always together". They are not. >>> >>>It may be common practice but it doesn't really make sense to temporally >>>split related actions if there's no need for it. It is annoying. In the >>>banks case, the login pages follow one another, they don't insert some >>>completely unrelated output in the middle of the login process. >>>If we want to teach new expectations to users, ipa-client-install is not >>>the place to do it. >>>The OTP case will work since with the patch, time is synced before both >>>prompts. >>> >>>The comment gives a good reason to move the ticket to Backlog, but since >>>we have a fix I'd like to push it. >> >>IIRC Alexander purposely put the time sync in here to ensure that at the >>time we actually obtain the password time is in sync. I can't say I >>always agreed with that, but it does make a certain amount of sense. > >Was that really a conscious decision? >The only thing between the old and new calls of the sync is the >actual password entry. I don't think we should worry about clocks >de-syncing while the admin enters a password. See my other answer. :) -- / Alexander Bokovoy From redhatrises at gmail.com Tue Mar 18 15:17:53 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 18 Mar 2014 09:17:53 -0600 Subject: [Freeipa-devel] [PATCH] Review: rga-0005 Fix order of synchronizing time when running ipa-client-install In-Reply-To: <20140318150902.GF16644@redhat.com> References: <53285C1A.6010409@redhat.com> <53285D3E.3050700@redhat.com> <5328608E.8070403@redhat.com> <20140318150902.GF16644@redhat.com> Message-ID: Patch was posted for review on Feb 19th, but may have missed due to volume, priorities, etc. What always seemed odd to me was where the time sync occurred not the association of entering a password immediately after a user prompt. It made more sense to me to have time sync before any configuration or krb usage/user prompts in general. Gabe On Tue, Mar 18, 2014 at 9:09 AM, Alexander Bokovoy wrote: > On Tue, 18 Mar 2014, Petr Viktorin wrote: > >> On 03/18/2014 03:50 PM, Rob Crittenden wrote: >> >>> Petr Viktorin wrote: >>> >>>> AFAIK this patch was only posted to Trac, where it was kind of >>>> forgotten. Let's move it to the mailing list. >>>> >>>> It looks & works fine, ACK for those aspects. But Dmitri had some >>>> concerns about the validity of the ticket itself: >>>> >>>> Unusual but not critical. In future this can be an OTP prompt rather >>>>> than >>>>> password prompt and making sure time is correct on both sides might be >>>>> more critical. I do not see a big problem with a slight delay. Banks >>>>> now >>>>> prompt people for user name on one page and then for password on >>>>> another. >>>>> It is a common practice. I would think that decoupling the prompts and >>>>> getting people used to it is a benefit rather than a hassle. The trend >>>>> of prompting for user and password independently should continue. >>>>> We should make it more usable if there are usability concerns but IMO >>>>> we >>>>> should not be trying to push people back to traditional notion of "user >>>>> name and password are always together". They are not. >>>>> >>>> >>>> It may be common practice but it doesn't really make sense to temporally >>>> split related actions if there's no need for it. It is annoying. In the >>>> banks case, the login pages follow one another, they don't insert some >>>> completely unrelated output in the middle of the login process. >>>> If we want to teach new expectations to users, ipa-client-install is not >>>> the place to do it. >>>> The OTP case will work since with the patch, time is synced before both >>>> prompts. >>>> >>>> The comment gives a good reason to move the ticket to Backlog, but since >>>> we have a fix I'd like to push it. >>>> >>> >>> IIRC Alexander purposely put the time sync in here to ensure that at the >>> time we actually obtain the password time is in sync. I can't say I >>> always agreed with that, but it does make a certain amount of sense. >>> >> >> Was that really a conscious decision? >> The only thing between the old and new calls of the sync is the actual >> password entry. I don't think we should worry about clocks de-syncing while >> the admin enters a password. >> > See my other answer. :) > > -- > / Alexander Bokovoy > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Mar 18 15:45:30 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Mar 2014 17:45:30 +0200 Subject: [Freeipa-devel] [PATCH 0158] Extend ipa-range-check DS plugin to handle range types In-Reply-To: <532860FE.2040203@redhat.com> References: <5327158D.1020408@redhat.com> <20140318081917.GZ16644@redhat.com> <532860FE.2040203@redhat.com> Message-ID: <20140318154530.GG16644@redhat.com> On Tue, 18 Mar 2014, Tomas Babej wrote: > >On 03/18/2014 09:19 AM, Alexander Bokovoy wrote: >> On Mon, 17 Mar 2014, Tomas Babej wrote: >>> Hi, >>> >>> The ipa-range-check plugin used to determine the range type depending >>> on the value of the attributes such as RID or secondary RID base. This >>> approached caused variety of issues since the portfolio of ID range >>> types expanded. >>> >>> The patch makes sure the following rules are implemented: >>> * No ID range pair can overlap on base ranges, with exception >>> of two ipa-ad-trust-posix ranges belonging to the same forest >>> * For any ID range pair of ranges belonging to the same domain: >>> * Both ID ranges must be of the same type >>> * For ranges of ipa-ad-trust type or ipa-local type: >>> * Primary RID ranges can not overlap >>> * For ranges of ipa-local type: >>> * Primary and secondary RID ranges can not overlap >>> * Secondary RID ranges cannot overlap >>> >>> For the implementation part, the plugin was extended with a domain ID >>> to forest root domain ID mapping derivation capabilities. >>> >>> https://fedorahosted.org/freeipa/ticket/4137 >>> >>> Test coverage coming soon! >> >> I don't really like that you are using a list here. The list is built >> and then destroyed in preop callback every time we process the range >> object, so it is one-off operation. Now, when you fetch trust domain >> objects to build the list, why can't you use an array directly? >> >> Given that all you need the list for is to map domain to a trust (if >> any) and trust name is the name of the root level domain, you can simply >> make an array of a struct (name, root) where root is a and index to the >> same array or -1 if this is the root domain itself. > >I don't see much benefit of using array over linked list in this case. >In both cases, we would need to build the data container, and it would >be one-off operation (once for the ADD/MOD operation). > >Additionaly, using linked list, I can only pass around the pointer to >the head of the list, instead of passing around the array and it's >size. If you make a {NULL, NULL} entry as the last one, no need to pass array size. But anyway... >I reworked the part of the patch that fetches the data from the LDAP as >we discussed. Instead of performing multiple LDAP searches, we do a >single extra search per operation. See comments below. >+static struct domain_info* build_domain_to_forest_root_map(struct domain_info *head, >+ struct ipa_range_check_ctx *ctx){ >+ >+ Slapi_PBlock *trusted_domain_search_pb = NULL; >+ Slapi_Entry **trusted_domain_entries = NULL; >+ Slapi_DN *base_dn = NULL; >+ Slapi_RDN *rdn = NULL; >+ >+ int search_result; >+ int ret; >+ >+ /* Set the base DN for the search to cn=ad, cn=trusts, $SUFFIX */ >+ base_dn = slapi_sdn_new_dn_byref(ctx->base_dn); >+ if (base_dn == NULL) { >+ LOG_FATAL("Failed to convert base DN.\n"); >+ ret = LDAP_OPERATIONS_ERROR; >+ goto done; >+ } >+ >+ rdn = slapi_rdn_new(); >+ if (rdn == NULL) { >+ LOG_FATAL("Failed to obtain RDN struct.\n"); >+ ret = LDAP_OPERATIONS_ERROR; >+ goto done; >+ } >+ >+ slapi_rdn_add(rdn, "cn", "trusts"); >+ slapi_sdn_add_rdn(base_dn, rdn); >+ slapi_rdn_done(rdn); >+ >+ slapi_rdn_add(rdn, "cn", "ad"); >+ slapi_sdn_add_rdn(base_dn, rdn); >+ slapi_rdn_done(rdn); given that slapi_search_internal_set_pb() wants 'const char *base', why not use asprintf() instead? Here is what we do in ipa-kdb: ret = asprintf(&base, "cn=ad,cn=trusts,%s", ipactx->base); if (ret == -1) { ret = ENOMEM; goto done; } That's enough, IMHO. 389-ds internally will anyway create new sdn explicitly from a string you've passed. >+ >+ /* Allocate a new parameter block */ >+ trusted_domain_search_pb = slapi_pblock_new(); >+ if (trusted_domain_search_pb == NULL) { >+ LOG_FATAL("Failed to create new pblock.\n"); >+ ret = LDAP_OPERATIONS_ERROR; in done: label you don't deal with 'ret' at all. Do you need it? >+ //goto done; is it goto or not? >+ } >+ >+ /* Search for all the root domains, note the LDAP_SCOPE_ONELEVEL */ >+ slapi_search_internal_set_pb(trusted_domain_search_pb, >+ slapi_sdn_get_dn(base_dn), here just use 'base_dn'. >+ LDAP_SCOPE_SUBTREE, DOMAIN_ID_FILTER, >+ NULL, 0, NULL, NULL, ctx->plugin_id, 0); >+ >+ ret = slapi_search_internal_pb(trusted_domain_search_pb); >+ if (ret != 0) { >+ LOG_FATAL("Starting internal search failed.\n"); >+ goto done; make sure you are consistent with 'ret' -- either handling it or not, and if overriding with LDAP_OPERATIONS_ERROR, make sure it is overridden everywhere. >+ } >+ >+ ret = slapi_pblock_get(trusted_domain_search_pb, SLAPI_PLUGIN_INTOP_RESULT, &search_result); >+ if (ret != 0 || search_result != LDAP_SUCCESS) { >+ LOG_FATAL("Internal search failed.\n"); >+ ret = LDAP_OPERATIONS_ERROR; >+ goto done; >+ } same here >+ >+ ret = slapi_pblock_get(trusted_domain_search_pb, SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, >+ &trusted_domain_entries); >+ >+ if (ret != 0) { >+ LOG_FATAL("Failed to read searched root domain entries.\n"); same here >+ goto done; >+ } >+ >+ if (trusted_domain_entries == NULL || trusted_domain_entries[0] == NULL) { >+ LOG("No existing root domain entries.\n"); >+ ret = 0; >+ goto done; >+ } Here as well >+ >+ /* now we iterate the domains and determine which of them are root domains */ >+ for (int i = 0; trusted_domain_entries[i] != NULL; i++) { >+ >+ ret = slapi_sdn_isparent(base_dn, >+ slapi_entry_get_sdn(trusted_domain_entries[i])); >+ >+ /* trusted domain is root domain */ >+ if (ret == 1) { >+ map_domain_to_root(head, >+ trusted_domain_entries[i], >+ trusted_domain_entries[i]); >+ } >+ else { >+ /* we need to search for the root domain */ >+ for (int j = 0; trusted_domain_entries[j] != NULL; j++) { >+ ret = slapi_sdn_isparent( >+ slapi_entry_get_sdn(trusted_domain_entries[j]), >+ slapi_entry_get_sdn(trusted_domain_entries[i])); >+ >+ /* match, set the jth domain as the root domain for the ith */ >+ if (ret == 1) { >+ map_domain_to_root(head, >+ trusted_domain_entries[i], >+ trusted_domain_entries[j]); >+ break; >+ } >+ } >+ } >+ } >+ >+done: >+ slapi_free_search_results_internal(trusted_domain_search_pb); >+ slapi_pblock_destroy(trusted_domain_search_pb); >+ slapi_rdn_free(&rdn); >+ >+ return head; >+ >+} >+ >+static int slapi_entry_to_range_info(struct domain_info *domain_info_head, >+ struct slapi_entry *entry, > struct range_info **_range) > { > int ret; >@@ -97,6 +273,9 @@ static int slapi_entry_to_range_info(struct slapi_entry *entry, > } > > range->domain_id = slapi_entry_attr_get_charptr(entry, IPA_DOMAIN_ID); >+ range->id_range_type = slapi_entry_attr_get_charptr(entry, IPA_RANGE_TYPE); >+ range->forest_root_id = get_forest_root_id(domain_info_head, >+ range->domain_id); > > ul_val = slapi_entry_attr_get_ulong(entry, IPA_BASE_ID); > if (ul_val == 0 || ul_val >= UINT32_MAX) { >@@ -161,58 +340,67 @@ static bool intervals_overlap(uint32_t x, uint32_t base, uint32_t x_size, uint32 > * | | / \ | > * new range: base rid sec_rid > **/ >-static int ranges_overlap(struct range_info *r1, struct range_info *r2) >+static int check_ranges(struct range_info *r1, struct range_info *r2) > { >+ /* Do not check overlaps of range with the range itself */ > if (r1->name != NULL && r2->name != NULL && > strcasecmp(r1->name, r2->name) == 0) { > return 0; > } > >- /* check if base range overlaps with existing base range */ >- if (intervals_overlap(r1->base_id, r2->base_id, >- r1->id_range_size, r2->id_range_size)){ >- return 1; >+ /* Check if base range overlaps with existing base range. >+ * Exception: ipa-ad-trust-posix ranges from the same forest */ >+ if (!(strcasecmp(r1->id_range_type, AD_TRUST_POSIX_RANGE_TYPE) && >+ strcasecmp(r2->id_range_type, AD_TRUST_POSIX_RANGE_TYPE) && >+ r1->forest_root_id != NULL && r2->forest_root_id !=NULL && >+ strcasecmp(r1->forest_root_id, r2->forest_root_id) == 0)) { >+ >+ if (intervals_overlap(r1->base_id, r2->base_id, >+ r1->id_range_size, r2->id_range_size)){ >+ return 1; >+ } >+ > } > >- /* if both base_rid and secondary_base_rid = 0, the rid range is not set */ >- bool rid_ranges_set = (r1->base_rid != 0 || r1->secondary_base_rid != 0) && >- (r2->base_rid != 0 || r2->secondary_base_rid != 0); >- >- /** >- * ipaNTTrustedDomainSID is not set for local ranges, use it to >- * determine the type of the range **/ >- bool local_ranges = r1->domain_id == NULL && r2->domain_id == NULL; >- >+ /* Following checks apply for the ranges from the same domain */ > bool ranges_from_same_domain = > (r1->domain_id == NULL && r2->domain_id == NULL) || > (r1->domain_id != NULL && r2->domain_id != NULL && > strcasecmp(r1->domain_id, r2->domain_id) == 0); > >- /** >- * in case rid range is not set or ranges belong to different domains >- * we can skip rid range tests as they are irrelevant **/ >- if (rid_ranges_set && ranges_from_same_domain){ >- >- /* check if rid range overlaps with existing rid range */ >- if (intervals_overlap(r1->base_rid, r2->base_rid, >- r1->id_range_size, r2->id_range_size)) >- return 2; >- >- /** >- * The following 3 checks are relevant only if both ranges are local. >- * Check if secondary rid range overlaps with existing secondary rid >- * range. **/ >- if (local_ranges){ >+ if (ranges_from_same_domain) { >+ >+ /* Ranges from the same domain must have the same type */ >+ if (strcasecmp(r1->id_range_type, r2->id_range_type) != 0) { >+ return 6; >+ } >+ >+ /* For ipa-local or ipa-ad-trust range types primary RID ranges should >+ * not overlap */ >+ if (strcasecmp(r1->id_range_type, AD_TRUST_RANGE_TYPE) == 0 || >+ strcasecmp(r1->id_range_type, LOCAL_RANGE_TYPE) == 0) { >+ >+ /* Check if rid range overlaps with existing rid range */ >+ if (intervals_overlap(r1->base_rid, r2->base_rid, >+ r1->id_range_size, r2->id_range_size)) >+ return 2; >+ } >+ >+ /* The following 3 checks are relevant only if both ranges are local. */ >+ if (strcasecmp(r1->id_range_type, LOCAL_RANGE_TYPE) == 0){ >+ >+ /* Check if secondary RID range overlaps with existing secondary or >+ * primary RID range. */ > if (intervals_overlap(r1->secondary_base_rid, > r2->secondary_base_rid, r1->id_range_size, r2->id_range_size)) > return 3; > >- /* check if rid range overlaps with existing secondary rid range */ >+ /* Check if RID range overlaps with existing secondary RID range */ > if (intervals_overlap(r1->base_rid, r2->secondary_base_rid, > r1->id_range_size, r2->id_range_size)) > return 4; > >- /* check if secondary rid range overlaps with existing rid range */ >+ /* Check if secondary RID range overlaps with existing RID range */ > if (intervals_overlap(r1->secondary_base_rid, r2->base_rid, > r1->id_range_size, r2->id_range_size)) > return 5; >@@ -248,9 +436,10 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype) > int search_result; > Slapi_Entry **search_entries = NULL; > size_t c; >- int no_overlap = 0; >+ int ranges_valid = 0; > const char *check_attr; > char *errmsg = NULL; >+ struct domain_info *domain_info_head = NULL; > > ret = slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, &is_repl_op); > if (ret != 0) { >@@ -337,7 +526,10 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype) > goto done; > } > >- ret = slapi_entry_to_range_info(entry, &new_range); >+ /* build a linked list of domain_info structs */ >+ domain_info_head = build_domain_to_forest_root_map(domain_info_head, ctx); >+ >+ ret = slapi_entry_to_range_info(domain_info_head, entry, &new_range); > if (ret != 0) { > LOG_FATAL("Failed to convert LDAP entry to range struct.\n"); > goto done; >@@ -381,19 +573,20 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype) > } > > for (c = 0; search_entries[c] != NULL; c++) { >- ret = slapi_entry_to_range_info(search_entries[c], &old_range); >+ ret = slapi_entry_to_range_info(domain_info_head, search_entries[c], >+ &old_range); > if (ret != 0) { > LOG_FATAL("Failed to convert LDAP entry to range struct.\n"); > goto done; > } > >- no_overlap = ranges_overlap(new_range, old_range); >+ ranges_valid = check_ranges(new_range, old_range); > free(old_range); > old_range = NULL; >- if (no_overlap != 0) { >+ if (ranges_valid != 0) { > ret = LDAP_CONSTRAINT_VIOLATION; > >- switch (no_overlap){ >+ switch (ranges_valid){ > case 1: > errmsg = "New base range overlaps with existing base range."; > break; >@@ -409,6 +602,8 @@ static int ipa_range_check_pre_op(Slapi_PBlock *pb, int modtype) > case 5: > errmsg = "New secondary rid range overlaps with existing primary rid range."; > break; >+ case 6: >+ errmsg = "New ID range has invalid type. All ranges in the same domain must be of the same type."; > default: > errmsg = "New range overlaps with existing one."; > break; >@@ -432,6 +627,14 @@ done: > slapi_entry_free(entry); > } > >+ /* Remove the domain info linked list from memory */ >+ struct domain_info *next; >+ while(domain_info_head) { >+ next = domain_info_head->next; >+ free(domain_info_head); >+ domain_info_head = next; >+ } Who would clean up all the strings in each record? I think we also have the issue in the original code with freeing range objects. A mere free(new_range) is not enough. >+ > if (ret != 0) { > if (errmsg == NULL) { > errmsg = "Range Check error"; >-- >1.8.5.3 > -- / Alexander Bokovoy From pvoborni at redhat.com Tue Mar 18 15:56:21 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 18 Mar 2014 16:56:21 +0100 Subject: [Freeipa-devel] [PATCH] 552-557 Permissions v2 Web UI In-Reply-To: <53285327.9060907@redhat.com> References: <532340AE.9030900@redhat.com> <53270527.8030202@redhat.com> <53283765.2080402@redhat.com> <53285327.9060907@redhat.com> Message-ID: <53286CA5.8060105@redhat.com> On 18.3.2014 15:07, Petr Viktorin wrote: > On 03/18/2014 01:09 PM, Petr Vobornik wrote: >> New revision for patch patch #557 attached. >> >> On 17.3.2014 15:22, Petr Viktorin wrote: >>> On 03/14/2014 06:47 PM, Petr Vobornik wrote: >>>> Main ACI UI changes are in patch #557. The rest are prerequisites. >>> >>> With this UI it is impossible to change from "Type-based" permissions to >>> "General" ones. This seems to be remaining from the old model where >>> permissions were type/filter/subtree/targetgroup were "classes" of a >>> permission rather than co-existing as attributes. >>> >>> Rather the Target section should IMO look the same for all (non-managed) >>> permissions, with the first items being: >>> Type: [drop-down with a None option] >>> Subtree: [textbox that is disabled when a Type is selected] >>> >>> The Subtree should be a one-line textbox. It would be acceptable if the >>> whole DN doesn't always fit, it's the first part that's important. >>> >>> Remember to only send Subtree if Type is (staying as | being set to) >>> None. >>> >>> Also, the Add dialog should use this instead of the "Define by". >> >> Done >> >>> >>> >>> >>> With managed permissions, if I try to change both included/excluded >>> attribute list and the effective attributes, I get a validation error, >>> which is good in CLI but it doesn't work well for the UI. >>> >>> I think it would be better to move "Managed permission overrides" below >>> "Target", and make it read-only. And perhaps rename it to something like >>> "Attribute breakdown". >>> Managing the included/excluded lists directly is only useful for >>> upgrades with a heavily customized policy, and for upgrades you need the >>> CLI anyway. Normally, having only the attribute list editable should be >>> fine. >> >> Done >> >>> >>> >>> >>> For SYSTEM permissions (those which only have the SYSTEM flag), such as >>> 'Add Automember Rebuild Membership Task', Permissions should not be >>> editable. >>> For old-style permissions (those without any flags), nothing is editable >>> but everything should be. The attributelevelrights are missing because >>> the entry doesn't have the ipaPermissionV2 objectclass yet (although >>> it's being reported, which is "my" bug -- #4257). >> >> Fields were set to be editable if attributes level rights are missing. > > That solves things for normal legacy permissions, but not for the SYSTEM > ones - those should be completely read-only. > > Also, changing the Permisisons checkboxes on these permissions doesn't > mark them dirty. > > Otherwise the patches work great! > Fixed New versions of 556 and 557 attached. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0556-1-webui-reflect-enabled-state-in-child-widgets-of-a-mu.patch Type: text/x-patch Size: 2544 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0557-2-webui-change-permissions-UI-to-v2.patch Type: text/x-patch Size: 47270 bytes Desc: not available URL: From massimiliano.perrone at tirasa.net Tue Mar 18 16:03:17 2014 From: massimiliano.perrone at tirasa.net (Massimiliano Perrone (tirasa.net)) Date: Tue, 18 Mar 2014 17:03:17 +0100 Subject: [Freeipa-devel] Talking json/rpc with java client In-Reply-To: <20140318102643.GC16644@redhat.com> References: <20140318091035.GA9052@redhat.com> <53281662.3030105@tirasa.net> <20140318102643.GC16644@redhat.com> Message-ID: <53286E45.4000605@tirasa.net> On 03/18/2014 11:26 AM, Alexander Bokovoy wrote: > On Tue, 18 Mar 2014, Massimiliano Perrone (tirasa.net) wrote: >> On 03/18/2014 10:10 AM, Jan Pazdziora wrote: >>> On Tue, Mar 18, 2014 at 09:02:13AM +0100, Marco Di Sabatino Di >>> Diodoro wrote: >>>> what are the requirements or packages that a client must have to >>>> call JSON/RPC with java? We have a 401 error. >>> What packages / code do you attempt to use when you get that 401? >>> >> >> Hi guys, first of all thanks for your replies. >> >> Summarizing... >> >> 1) On FreeIPA server I created a keytab executing following commands: >> *) ipa host-add ebano.example.com >> *) ipa service-add HTTP/ebano.example.com >> *) ipa-getkeytab -s olmo.example.com -p HTTP/ebano.example.com >> -k /tmp/ebano.keytab >> *) scp /tmp/ebano.keytab root at ebano:/var/tmp >> >> 2) On ebano (the client machine) I have a Java client based on >> HttpClient 3.1 that uses this java.security.auth.login.config file: >> ######################################### >> un.security.jgss.login { >> com.sun.security.auth.module.Krb5LoginModule required >> client=TRUE >> refreshKrb5Config=true >> useKeyTab=true >> keyTab="/var/tmp/ebano.keytab" >> principal="HTTP/ebano.example.com"; >> }; >> >> com.sun.security.jgss.initiate { >> com.sun.security.auth.module.Krb5LoginModule required >> client=TRUE >> refreshKrb5Config=true >> useKeyTab=true >> keyTab="/var/tmp/ebano.keytab" >> principal="HTTP/ebano.example.com"; >> >> }; >> >> com.sun.security.jgss.accept { >> com.sun.security.auth.module.Krb5LoginModule required >> client=TRUE >> refreshKrb5Config=true >> useKeyTab=true >> keyTab="/var/tmp/ebano.keytab" >> principal="HTTP/ebano.example.com"; >> }; >> ######################################### >> >> As you can see in attached log file, I can negotiate authentication >> on FreeIPA server and final response from it is a 401 >> >> 10:16:36.407 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >> org.apache.http.wire - << "{" >> 10:16:36.407 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >> org.apache.http.wire - << "[\n]" >> 10:16:36.407 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >> org.apache.http.wire - << " "error": {[\n]" >> 10:16:36.407 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >> org.apache.http.wire - << " "code": 1101, [\n]" >> 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >> org.apache.http.wire - << " "message": "did not receive >> Kerberos credentials", [\n]" >> 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >> org.apache.http.wire - << " "name": {[\n]" >> 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >> org.apache.http.wire - << " "__base64__": >> "Q0NhY2hlRXJyb3I="[\n]" >> 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >> org.apache.http.wire - << " }[\n]" >> 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >> org.apache.http.wire - << " }, [\n]" >> 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >> org.apache.http.wire - << " "id": null, [\n]" >> 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >> org.apache.http.wire - << " "principal": "UNKNOWN", [\n]" >> 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >> org.apache.http.wire - << " "result": null, [\n]" >> 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >> org.apache.http.wire - << " "version": "3.3.4"[\n]" >> 10:16:36.408 [net.tirasa.freeipa.FreeIPA.main()] DEBUG >> org.apache.http.wire - << "}" >> >> But... >> >> Reading Kerberos server log I noticed that a right curl based call >> generates a >> mar 18 08:20:12 olmo.example.com krb5kdc[1423](info): TGS_REQ (1 >> etypes {18}) 192.168.0.105: ISSUE: authtime 1395072185, etypes >> {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for >> krbtgt/EXAMPLE.COM at EXAMPLE.COM >> mar 18 08:20:13 olmo.example.com krb5kdc[1423](info): TGS_REQ (6 >> etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime >> 1395072185, etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for >> ldap/olmo.example.com at EXAMPLE.COM >> >> whereas Java client generates a >> >> mar 17 19:48:21 olmo.example.com krb5kdc[1423](info): AS_REQ (4 >> etypes {18 17 16 23}) 192.168.0.105: NEEDED_PREAUTH: >> HTTP/ebano.example.com at EXAMPLE.COM for >> krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required >> mar 17 19:48:21 olmo.example.com krb5kdc[1423](info): AS_REQ (4 >> etypes {18 17 16 23}) 192.168.0.105: ISSUE: authtime 1395082101, >> etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for >> krbtgt/EXAMPLE.COM at EXAMPLE.COM >> mar 17 19:48:21 olmo.example.com krb5kdc[1423](info): TGS_REQ (6 >> etypes {18 17 16 23 1 3}) 192.168.0.105: ISSUE: authtime 1395082101, >> etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for >> HTTP/olmo.example.com at EXAMPLE.COM >> >> The difference between the two calls is on the last TGS_REQ; because >> the first one is on ldap/olmo.example.com at EXAMPLE.COM and it's OK >> whereas the second one is on HTTP/olmo.example.com at EXAMPLE.COM that >> returns a 401 (I suppose). >> >> Where's the error? > Am I correct that you have a user connecting to HTTP/ebano.example.com > and then HTTP/ebano.example.com wants to talk to HTTP/olmo.example.com > using credentials of the user? > > FreeIPA uses constraint delegation of the credentials, with the help of > S4U2Proxy extension. You need to allow HTTP/ebano.example.com to delegate > credentials to HTTP/olmo.example.com. > > I have written an article how to do that: > https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html > > Hi Alexander, thanks for your reply. I read carefully your interesting post and I follow it to delegate HTTP/ebano.example.com credentials to HTTP/olmo.example.com. Now, two questions: 1) How can I check that my configuration, now is ok? Because this ldapsearch returns result: 0 ldapsearch -Y GSSAPI -H ldap://olmo.tirasa.net -b "cn=s4u2proxy,cn=etc,dc=example,dc=com" "cn=ipa-http-delegation-targets" dn 2) This time however I read also /var/log/httpd/error_log and I noticed this: ############# [Tue Mar 18 16:38:14.117207 2014] [:error] [pid 11268] ipa: ERROR: 500 Internal Server Error: jsonserver_kerb.__call__: KRB5CCNAME not defined in HTTP request environment ############# whereas LDAP logs are OK. In your opinion, I have this error because of wrong environment configuration or other cause? Thanks in advance Massi -- Massimiliano Perrone Tel +39 393 9121310 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~massi/ "L'apprendere molte cose non insegna l'intelligenza" (Eraclito) From redhatrises at gmail.com Tue Mar 18 16:11:21 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 18 Mar 2014 10:11:21 -0600 Subject: [Freeipa-devel] Use of NetworkManager - to disable or not disable Message-ID: All, Looking at https://fedorahosted.org/freeipa/ticket/4156, I wanted to see if disabling NetworkManager is still required or not. I could see in some environments admins may disable it so having it in the docs wouldn't be a bad idea IMHO. Thoughts? Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Mar 18 16:26:07 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Mar 2014 18:26:07 +0200 Subject: [Freeipa-devel] Talking json/rpc with java client In-Reply-To: <53286E45.4000605@tirasa.net> References: <20140318091035.GA9052@redhat.com> <53281662.3030105@tirasa.net> <20140318102643.GC16644@redhat.com> <53286E45.4000605@tirasa.net> Message-ID: <20140318162607.GH16644@redhat.com> On Tue, 18 Mar 2014, Massimiliano Perrone (tirasa.net) wrote: >>>The difference between the two calls is on the last TGS_REQ; >>>because the first one is on ldap/olmo.example.com at EXAMPLE.COM and >>>it's OK whereas the second one is on >>>HTTP/olmo.example.com at EXAMPLE.COM that returns a 401 (I suppose). >>> >>>Where's the error? >>Am I correct that you have a user connecting to HTTP/ebano.example.com >>and then HTTP/ebano.example.com wants to talk to HTTP/olmo.example.com >>using credentials of the user? >> >>FreeIPA uses constraint delegation of the credentials, with the help of >>S4U2Proxy extension. You need to allow HTTP/ebano.example.com to delegate >>credentials to HTTP/olmo.example.com. >> >>I have written an article how to do that: >>https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html >> >> >Hi Alexander, thanks for your reply. >I read carefully your interesting post and I follow it to delegate >HTTP/ebano.example.com credentials to HTTP/olmo.example.com. > >Now, two questions: >1) How can I check that my configuration, now is ok? Because this >ldapsearch returns result: 0 > >ldapsearch -Y GSSAPI -H ldap://olmo.tirasa.net -b >"cn=s4u2proxy,cn=etc,dc=example,dc=com" >"cn=ipa-http-delegation-targets" dn You need to create these delegation entries yourself, like the article says. Note that your app talks to IPA server's HTTP service, so create dn: cn=ebano-http-delegation,cn=s4u2proxy,cn=etc,dc=example,dc=com objectClass: ipaKrb5DelegationACL objectClass: groupOfPrincipals objectClass: top cn: ebano-http-delegation memberPrincipal: HTTP/ebano.example.com at EXAMPLE.COM ipaAllowedTarget: cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com This entry says: "HTTP/ebano.example.com is allowed to delegate users' credentials to whatever Kerberos principal is a member of cn=ebano-http-delegation-targets group" Now, this is the group: dn: cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com objectClass: groupOfPrincipals objectClass: top cn: ebano-http-delegation-targets memberPrincipal: HTTP/olomo.example.com at EXAMPLE.COM With these two entries we would have HTTP/ebano.example.com allowed to delegate users' credentials to HTTP/olomo.example.com You don't need to allow HTTP/olomo.example.com to further delegate credentials to ldap/olomo.example.com because this entry already exists -- each IPA master's HTTP service is allowed to delegate users' credentials to own ldap/ service. >2) This time however I read also /var/log/httpd/error_log and I >noticed this: >############# >[Tue Mar 18 16:38:14.117207 2014] [:error] [pid 11268] ipa: ERROR: >500 Internal Server Error: >jsonserver_kerb.__call__: KRB5CCNAME not defined in HTTP request environment >############# >whereas LDAP logs are OK. >In your opinion, I have this error because of wrong environment >configuration or other cause? This is most likely because you have no Kerberos ticket available. -- / Alexander Bokovoy From abokovoy at redhat.com Tue Mar 18 16:26:48 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 18 Mar 2014 18:26:48 +0200 Subject: [Freeipa-devel] Use of NetworkManager - to disable or not disable In-Reply-To: References: Message-ID: <20140318162648.GI16644@redhat.com> On Tue, 18 Mar 2014, Gabe Alford wrote: >All, > >Looking at https://fedorahosted.org/freeipa/ticket/4156, I wanted to see if >disabling NetworkManager is still required or not. I could see in some >environments admins may disable it so having it in the docs wouldn't be a >bad idea IMHO. Thoughts? At least in Fedora 18+ and RHEL 7.0 beta is is not required anymore. -- / Alexander Bokovoy From rcritten at redhat.com Tue Mar 18 18:24:27 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 18 Mar 2014 14:24:27 -0400 Subject: [Freeipa-devel] Use of NetworkManager - to disable or not disable In-Reply-To: References: Message-ID: <53288F5B.1070205@redhat.com> Gabe Alford wrote: > All, > > Looking at https://fedorahosted.org/freeipa/ticket/4156, I wanted to see > if disabling NetworkManager is still required or not. I could see in > some environments admins may disable it so having it in the docs > wouldn't be a bad idea IMHO. Thoughts? > > Gabe > > This recommendation dates back to much earlier versions of Fedora (like 10+ releases ago) and doesn't really apply any more, at least in my development experience. I've been leaving NM enabled for quite some time now, F16 and beyond at least, and haven't had any issues. rob From redhatrises at gmail.com Wed Mar 19 01:29:56 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 18 Mar 2014 19:29:56 -0600 Subject: [Freeipa-devel] [PATCH] [DOC] login as another user in the WebUI Message-ID: All, Just added a couple of steps under section 4.3.6 Let me know if I need to change anything. https://fedorahosted.org/freeipa/ticket/3064 Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0009-DOC-Log-into-the-Web-UI-as-another-user.patch Type: text/x-patch Size: 1757 bytes Desc: not available URL: From redhatrises at gmail.com Wed Mar 19 01:31:31 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Tue, 18 Mar 2014 19:31:31 -0600 Subject: [Freeipa-devel] [PATCH] typo in migrate-ds Message-ID: All, It looks like the only typos exist in the uk and fr .po files for this ticket https://fedorahosted.org/freeipa/ticket/2546 Point me in the right direction if I am wrong. Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0006-fix-typo-in-ipa-v-migrate-ds.patch Type: text/x-patch Size: 1760 bytes Desc: not available URL: From pvoborni at redhat.com Wed Mar 19 09:35:22 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Mar 2014 10:35:22 +0100 Subject: [Freeipa-devel] [PATCH] [DOC] login as another user in the WebUI In-Reply-To: References: Message-ID: <532964DA.90308@redhat.com> On 19.3.2014 02:29, Gabe Alford wrote: > All, > > Just added a couple of steps under section 4.3.6 > > Let me know if I need to change anything. > > https://fedorahosted.org/freeipa/ticket/3064 > > Thanks, > > Gabe > > Hello Gabe, thank you for the patch. Main issue, even though it looks like a nitpick, is that you mix tabs and spaces. Tabs would be better since the rest of the file uses them. Content is OK. I'd like to add that in step 3 user doesn't have to use forms-based auth. He can also obtain TGT using kinit with credentials for different user. So basically: 1) kdestroy 2) logout 3) kinit anotheruser 4) open web ui -- Petr Vobornik From pviktori at redhat.com Wed Mar 19 09:52:10 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 19 Mar 2014 10:52:10 +0100 Subject: [Freeipa-devel] [PATCH] 552-557 Permissions v2 Web UI In-Reply-To: <53286CA5.8060105@redhat.com> References: <532340AE.9030900@redhat.com> <53270527.8030202@redhat.com> <53283765.2080402@redhat.com> <53285327.9060907@redhat.com> <53286CA5.8060105@redhat.com> Message-ID: <532968CA.6060609@redhat.com> On 03/18/2014 04:56 PM, Petr Vobornik wrote: > On 18.3.2014 15:07, Petr Viktorin wrote: >> On 03/18/2014 01:09 PM, Petr Vobornik wrote: >>> New revision for patch patch #557 attached. >>> >>> On 17.3.2014 15:22, Petr Viktorin wrote: >>>> On 03/14/2014 06:47 PM, Petr Vobornik wrote: >>>>> Main ACI UI changes are in patch #557. The rest are prerequisites. >>>> >>>> With this UI it is impossible to change from "Type-based" >>>> permissions to >>>> "General" ones. This seems to be remaining from the old model where >>>> permissions were type/filter/subtree/targetgroup were "classes" of a >>>> permission rather than co-existing as attributes. >>>> >>>> Rather the Target section should IMO look the same for all >>>> (non-managed) >>>> permissions, with the first items being: >>>> Type: [drop-down with a None option] >>>> Subtree: [textbox that is disabled when a Type is selected] >>>> >>>> The Subtree should be a one-line textbox. It would be acceptable if the >>>> whole DN doesn't always fit, it's the first part that's important. >>>> >>>> Remember to only send Subtree if Type is (staying as | being set to) >>>> None. >>>> >>>> Also, the Add dialog should use this instead of the "Define by". >>> >>> Done >>> >>>> >>>> >>>> >>>> With managed permissions, if I try to change both included/excluded >>>> attribute list and the effective attributes, I get a validation error, >>>> which is good in CLI but it doesn't work well for the UI. >>>> >>>> I think it would be better to move "Managed permission overrides" below >>>> "Target", and make it read-only. And perhaps rename it to something >>>> like >>>> "Attribute breakdown". >>>> Managing the included/excluded lists directly is only useful for >>>> upgrades with a heavily customized policy, and for upgrades you need >>>> the >>>> CLI anyway. Normally, having only the attribute list editable should be >>>> fine. >>> >>> Done >>> >>>> >>>> >>>> >>>> For SYSTEM permissions (those which only have the SYSTEM flag), such as >>>> 'Add Automember Rebuild Membership Task', Permissions should not be >>>> editable. >>>> For old-style permissions (those without any flags), nothing is >>>> editable >>>> but everything should be. The attributelevelrights are missing because >>>> the entry doesn't have the ipaPermissionV2 objectclass yet (although >>>> it's being reported, which is "my" bug -- #4257). >>> >>> Fields were set to be editable if attributes level rights are missing. >> >> That solves things for normal legacy permissions, but not for the SYSTEM >> ones - those should be completely read-only. >> >> Also, changing the Permisisons checkboxes on these permissions doesn't >> mark them dirty. >> >> Otherwise the patches work great! >> > > Fixed > > New versions of 556 and 557 attached. > Great, thanks! ACK for the functionality, I can't really judge the javascript though. -- Petr? From mbasti at redhat.com Wed Mar 19 12:43:54 2014 From: mbasti at redhat.com (Martin Basti) Date: Wed, 19 Mar 2014 13:43:54 +0100 Subject: [Freeipa-devel] [DOC] 0006 Chapter 5 update In-Reply-To: <53284B65.9000601@redhat.com> References: <1380214338.2142.9.camel@unused-4-145.brq.redhat.com> <53284B65.9000601@redhat.com> Message-ID: <1395233034.2317.9.camel@unused-4-145.brq.redhat.com> On Tue, 2014-03-18 at 14:34 +0100, Petr Viktorin wrote: > On 09/26/2013 06:52 PM, Martin Basti wrote: > > Patch for chapter 5 > > > > Contains patch for ticket > > https://fedorahosted.org/freeipa/ticket/3842 > > Hello, > Thanks for the patches! > > Next time, when you do multiple changes, please split them into multiple > patches. Each of the bullet points in the commit message could have been > a separate patch. > However splitting the patch now is probably not worth the effort. > > I did however split the whitespace fixes to make my job easier. I also > rebased a minor conflict. Attaching the patches for convenience. > > In section 5.1.3 the examples are missing the [user at ipaserver ~] prompt. Added. > In section 5.2.2.2 there's an extra `$` prompt that's not present in > other syntax examples. Removed extra '$'. > > Section 5.2.4.1. should not be an ordered list since it presents two > ways to do the same thing. Moved to unnumbered list. > In Table 5.3, instead of removing posixgroup altogether you should > mention that it's only added for POSIX groups. Added footnote. > > Otherwise the changes look good. > Thank you for review. Updated patch attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-docs-pviktori-0001-Chapter-5-Users-Remove-trailing-whitespace.patch Type: text/x-patch Size: 47850 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0006-2+pviktori-Chapter-5-fixed-images-examples-added-new-TIPs.patch Type: text/x-patch Size: 1923864 bytes Desc: not available URL: From jcholast at redhat.com Wed Mar 19 13:33:12 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 19 Mar 2014 14:33:12 +0100 Subject: [Freeipa-devel] [PATCHES] 172-196 Refactor certificate renewal code In-Reply-To: <5321A77B.3090003@redhat.com> References: <525FD641.20202@redhat.com> <526009D7.2040702@redhat.com> <5260175E.50809@redhat.com> <531DAA0F.9080300@redhat.com> <5320AE9B.6040303@redhat.com> <5321A77B.3090003@redhat.com> Message-ID: <53299C98.2090308@redhat.com> On 13.3.2014 13:41, Jan Cholasta wrote: > On 12.3.2014 19:59, Petr Viktorin wrote: >> Certmonger is not configured/started in CA-less installs. > > That's expected. > >> >> I tested fresh installs and upgrades; renewals work fine for me. >> >> 161-184 look OK >> >> 185: one more nitpick: >> cert = entry['usercertificate'][0] >> Shouldn't that use entry.single_value? > > I did not feel like changing this, because this is used in the original > code and the userCertificate LDAP attribute is multi-value. > >> >> 186-189 look OK >> >> 190: Is >> fqdn = entries[0].dn[1].value >> return api.env.host == fqdn >> safe? Can they differ in case, for example? > > I guess so, will fix. > >> >> 191-196 look OK >> >>> Note that patches 178 & 179 were already pushed. Also, patch 190 was >>> changed to store information about which CA instance is master in LDAP. Updated patches attached. Note that I changed the path for CSR export to /var/lib/ipa/ca.csr to make it more SELinux-friendly (not in the policy yet, see ). -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-172.2-Move-CACERT-definition-to-a-single-place.patch Type: text/x-patch Size: 13423 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-173.2-Do-not-create-CA-certificate-files-in-CA-less-server.patch Type: text/x-patch Size: 1928 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-174.2-Use-LDAP-API-to-upload-CA-certificate-instead-of-lda.patch Type: text/x-patch Size: 2811 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-175.2-Upload-CA-certificate-from-DS-NSS-database-in-CA-les.patch Type: text/x-patch Size: 3169 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-176.2-Remove-unused-method-export_ca_cert-of-dsinstance.patch Type: text/x-patch Size: 979 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-177.2-Show-progress-when-enabling-SSL-in-DS-in-ipa-server-.patch Type: text/x-patch Size: 3276 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-180.2-Use-certmonger-D-Bus-API-to-configure-certmonger-in-.patch Type: text/x-patch Size: 4923 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-181.2-Add-new-certmonger-CA-helper-dogtag-ipa-ca-renew-age.patch Type: text/x-patch Size: 4170 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-182.2-Update-pkcs10-module-functions-to-always-load-CSRs-a.patch Type: text/x-patch Size: 5484 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-183.2-Remove-unused-function-get_subjectaltname-from-the-c.patch Type: text/x-patch Size: 1324 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-184.2-Add-function-for-parsing-friendly-name-from-certific.patch Type: text/x-patch Size: 2869 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-185.2-Support-retrieving-renewed-certificates-from-LDAP-in.patch Type: text/x-patch Size: 3515 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-186.2-Use-dogtag-ipa-ca-renew-agent-to-retrieve-renewed-ce.patch Type: text/x-patch Size: 5177 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-187.2-Remove-dogtag-ipa-retrieve-agent-submit.patch Type: text/x-patch Size: 4906 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-188.2-Support-storing-renewed-certificates-to-LDAP-in-dogt.patch Type: text/x-patch Size: 5516 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-189.2-Use-dogtag-ipa-ca-renew-agent-to-track-certificates-.patch Type: text/x-patch Size: 13042 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-190.2-Store-information-about-which-CA-server-is-master-in.patch Type: text/x-patch Size: 5346 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-191.2-Make-the-default-dogtag-ipa-ca-renew-agent-behavior-.patch Type: text/x-patch Size: 2858 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-192.2-Merge-restart_pkicad-functionality-to-renew_ca_cert-.patch Type: text/x-patch Size: 7777 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-193.2-Merge-restart_httpd-functionality-to-renew_ra_cert.patch Type: text/x-patch Size: 2238 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-194.2-Use-the-same-certmonger-configuration-for-both-CA-ma.patch Type: text/x-patch Size: 9618 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-195.2-Update-certmonger-configuration-in-ipa-upgradeconfig.patch Type: text/x-patch Size: 7235 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-196.2-Support-exporting-CSRs-in-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 1745 bytes Desc: not available URL: From pvoborni at redhat.com Wed Mar 19 15:02:06 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Mar 2014 16:02:06 +0100 Subject: [Freeipa-devel] [PATCH] 559 webui: update license information of used third party code Message-ID: <5329B16E.6060600@redhat.com> I have some cleanup and refactoring patches which were created along with RCUE login effort. They are not that much connected so I'm sending them now (in 4 mails) to make the subsequent review smaller. [PATCH] webui: update license information of used third party code Reflects: - adding of RCUE styles along with Bootstrap 2.0. - removal of jQuery BBQ plugin - removal of rhino enviroment for selenium which was used in old UI tests -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0559-webui-update-license-information-of-used-third-party.patch Type: text/x-patch Size: 15903 bytes Desc: not available URL: From pvoborni at redhat.com Wed Mar 19 15:02:12 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Mar 2014 16:02:12 +0100 Subject: [Freeipa-devel] [PATCH] 560 webui: rename domNode to dom_node Message-ID: <5329B174.9060407@redhat.com> - unites domNode and dom_node usage to dom_node -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0560-webui-rename-domNode-to-dom_node.patch Type: text/x-patch Size: 9378 bytes Desc: not available URL: From pvoborni at redhat.com Wed Mar 19 15:02:19 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Mar 2014 16:02:19 +0100 Subject: [Freeipa-devel] [PATCH] 561 webui: make navigation module independent on app module Message-ID: <5329B17B.10503@redhat.com> When some module used 'freeipa/navigation' it pulled the entire Web UI because navigation depended on app. This patch splits the app into two modules: app and app_container. App specifies the entities which are part of final application. app_container module represents the application boot classes. Navigation now depends on app_container. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0561-webui-make-navigation-module-independent-on-app-modu.patch Type: text/x-patch Size: 9295 bytes Desc: not available URL: From pvoborni at redhat.com Wed Mar 19 15:02:29 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 19 Mar 2014 16:02:29 +0100 Subject: [Freeipa-devel] [PATCH] 562-563 webui: move RPC code from IPA module to its own module Message-ID: <5329B185.5030706@redhat.com> depends on path #561(make navigation module independent on app module) [PATCH] 562 webui: move RPC code from IPA module to its own module - moves RPC code from ipa.js to it's own module - part of ongoing effort where the ultimate goal is to get rid of ipa.js and IPA namespace [PATCH] 563 webui: replace IPA.command usage with rpc.command Replace all IPA.command, IPA.batch_command and IPA.concurrent_command usages by equivalents from rpc module. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0562-webui-move-RPC-code-from-IPA-module-to-its-own-modul.patch Type: text/x-patch Size: 57931 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0563-webui-replace-IPA.command-usage-with-rpc.command.patch Type: text/x-patch Size: 52886 bytes Desc: not available URL: From simo at redhat.com Wed Mar 19 15:19:41 2014 From: simo at redhat.com (Simo Sorce) Date: Wed, 19 Mar 2014 11:19:41 -0400 Subject: [Freeipa-devel] [PATCH] 559 webui: update license information of used third party code In-Reply-To: <5329B16E.6060600@redhat.com> References: <5329B16E.6060600@redhat.com> Message-ID: <1395242381.26633.22.camel@willson.li.ssimo.org> On Wed, 2014-03-19 at 16:02 +0100, Petr Vobornik wrote: > I have some cleanup and refactoring patches which were created along > with RCUE login effort. > > They are not that much connected so I'm sending them now (in 4 mails) to > make the subsequent review smaller. > > > [PATCH] webui: update license information of used third party code > Reflects: > - adding of RCUE styles along with Bootstrap 2.0. > - removal of jQuery BBQ plugin > - removal of rhino enviroment for selenium which was used in old UI tests ACK Simo. -- Simo Sorce * Red Hat, Inc * New York From amisnyov at redhat.com Wed Mar 19 15:32:19 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Wed, 19 Mar 2014 16:32:19 +0100 Subject: [Freeipa-devel] [PATCH] 550 webui-css: improve radio, checkbox keyboard support and color In-Reply-To: <53233EC2.2060302@redhat.com> References: <5319D8F7.7080304@redhat.com> <5321D509.1020004@redhat.com> <53233EC2.2060302@redhat.com> Message-ID: <20140319163219.1e41f100@unused-4-246.brq.redhat.com> On Fri, 14 Mar 2014 18:39:14 +0100 Petr Vobornik wrote: > On 13.3.2014 16:55, Petr Vobornik wrote: > > On 7.3.2014 15:34, Petr Vobornik wrote: > >> checkboxes and radio buttons: > >> - do not change color on hover when disabled > >> - are focusable and checkable by keyboard again. This uses a little > >> trick where the real checkbox is hidden under the artificial > >> checkbox. That way it has the same position and therefore it > >> works even in containers with overflow set. > >> > >> https://fedorahosted.org/freeipa/ticket/4217 > >> > > > > Self-NACK. > > > > Breaks Automount Key deletion in ipa/ui/#/e/automountmap/keys/ > > Fixed in attached patch #551. > > Also attaching new version of #550 with CI fixes. works now, ACK Greets Adam From abokovoy at redhat.com Wed Mar 19 15:37:49 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 19 Mar 2014 17:37:49 +0200 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <1392993378.23210.15.camel@localhost.localdomain> References: <20140213131253.GR8040@redhat.com> <20140217103204.GA16644@redhat.com> <20140219210150.GD16644@redhat.com> <20140219212558.GE16644@redhat.com> <20140220112706.GJ16644@redhat.com> <20140220123338.GK16644@redhat.com> <1392905964.1957.0.camel@localhost.localdomain> <1392922612.23210.3.camel@localhost.localdomain> <20140220220859.GR16644@redhat.com> <1392993378.23210.15.camel@localhost.localdomain> Message-ID: <20140319153749.GL16644@redhat.com> On Fri, 21 Feb 2014, Nathaniel McCallum wrote: >On Fri, 2014-02-21 at 00:08 +0200, Alexander Bokovoy wrote: >> On Thu, 20 Feb 2014, Nathaniel McCallum wrote: >> >> > >>There is an error in libotp's find() function which assumes that >> >> > >>get_basedn() always returns non-NULL value. This is not true for at >> >> > >>least cn=Directory Manager. >> >> > >> >> >> > >>Patch attached. >> >> > >More fixes required, now that Thierry produced the fix for 389-ds ticket >> >> > >47699 which allows to re-arrange schema-compat and ipa-pwd-extop >> >> > >plugins. I'm getting crash in find() in libotp.c for internal search in >> >> > >some other conditions but at least user dn now is the correct one. >> >> > > >> >> > >Stay tuned. >> >> > OK, finally I've got it working -- my last patch had error which could >> >> > be attributed to the late night time. >> >> > >> >> > New patch is attached to fix libotp to work properly with empty base dn >> >> > (such as cn=Directory Manager). >> >> > >> >> > Also I'm attaching the patch that sets precedence of schema-compat >> >> > plugin to 49 (less than default 50). With this patch and 389-ds with >> >> > patch from ticket 47699 compat tree binds work with OTP. >> >> > >> >> > When updated 389-ds-base will be released, we'll need to add Requires: >> >> > to our RPM spec to depend on it. Without the updated 389-ds-base compat >> >> > tree binds will not work with OTP but the rest will be working fine. >> >> > >> >> > Finally, ACK to all OTP patches. >> >> >> >> ACK to both of these patches. >> > >> >I've merged the first patch here -- >> >https://www.redhat.com/archives/freeipa-devel/2014-February/msg00341.html >> > >> >I just realized the second patch shouldn't be ACK'd until we have a new >> >389DS release with the fix. When that happens, reissue this patch with >> >an update versioned require. >> No, it can be safely merged as 389DS will use default precedence (50) unless >> the fix is there. So the worst we get is the same as now -- OTP binds >> will not work over compat tree. And when 389DS will be upgraded, they >> will start working after 389DS restart. > >But this patch doesn't actually do anything until we get the new version >of 389DS. If we are ever going to add a versioned dependency on the new >389DS for this feature, it should go in this patch. Otherwise, it is an >ACK from me. New 389-DS is in Fedora 20 updates stable and Rawhide already. 389-ds-base-1.3.2.16-1.fc20. Also, selinux-policy 3.12.1-135 is now in Fedora 20 updates testing, providing multiple policy enhancements that make possible Apache process to work with kernel-based credentials caches. Attached patch makes use of the new packages. -- / Alexander Bokovoy -------------- next part -------------- >From 22d00b5413952f6a6ef2840341dd143999c9ad6e Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 19 Mar 2014 17:31:49 +0200 Subject: [PATCH] freeipa.spec.in: update dependencies to 389-ds and selinux-policy 389-ds-base 1.3.2.16 implements reordering of sub-plugins based on the ordering of the main plugin. We need it to make OTP working over compat tree. selinux-polic 3.12.1-135 fixes issues which prevented httpd to work with kernel keyring-based credentials caches. This change is Fedora 20+. --- freeipa.spec.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index c17e939..8658ea8 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -21,7 +21,7 @@ Source0: freeipa-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) %if ! %{ONLY_CLIENT} -BuildRequires: 389-ds-base-devel >= 1.3.2.11 +BuildRequires: 389-ds-base-devel >= 1.3.2.16 BuildRequires: svrcore-devel BuildRequires: policycoreutils >= %{POLICYCOREUTILSVER} BuildRequires: systemd-units @@ -98,7 +98,7 @@ Group: System Environment/Base Requires: %{name}-python = %{version}-%{release} Requires: %{name}-client = %{version}-%{release} Requires: %{name}-admintools = %{version}-%{release} -Requires: 389-ds-base >= 1.3.2.11 +Requires: 389-ds-base >= 1.3.2.16 Requires: openldap-clients > 2.4.35-4 %if 0%{?fedora} == 18 Requires: nss >= 3.14.3-2 @@ -139,7 +139,7 @@ Requires: python-memcached Requires: systemd-units >= 38 Requires(pre): systemd-units Requires(post): systemd-units -Requires: selinux-policy >= 3.12.1-65 +Requires: selinux-policy >= 3.12.1-135 Requires(post): selinux-policy-base Requires: slapi-nis >= 0.47.7 Requires: pki-ca >= 10.0.4 -- 1.8.5.3 From amisnyov at redhat.com Wed Mar 19 16:03:33 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Wed, 19 Mar 2014 17:03:33 +0100 Subject: [Freeipa-devel] [PATCH] 552-557 Permissions v2 Web UI In-Reply-To: <532968CA.6060609@redhat.com> References: <532340AE.9030900@redhat.com> <53270527.8030202@redhat.com> <53283765.2080402@redhat.com> <53285327.9060907@redhat.com> <53286CA5.8060105@redhat.com> <532968CA.6060609@redhat.com> Message-ID: <20140319170333.29113ef8@unused-4-246.brq.redhat.com> On Wed, 19 Mar 2014 10:52:10 +0100 Petr Viktorin wrote: > On 03/18/2014 04:56 PM, Petr Vobornik wrote: > > On 18.3.2014 15:07, Petr Viktorin wrote: > >> On 03/18/2014 01:09 PM, Petr Vobornik wrote: > >>> New revision for patch patch #557 attached. > >>> > >>> On 17.3.2014 15:22, Petr Viktorin wrote: > >>>> On 03/14/2014 06:47 PM, Petr Vobornik wrote: > >>>>> Main ACI UI changes are in patch #557. The rest are > >>>>> prerequisites. > >>>> > >>>> With this UI it is impossible to change from "Type-based" > >>>> permissions to > >>>> "General" ones. This seems to be remaining from the old model > >>>> where permissions were type/filter/subtree/targetgroup were > >>>> "classes" of a permission rather than co-existing as attributes. > >>>> > >>>> Rather the Target section should IMO look the same for all > >>>> (non-managed) > >>>> permissions, with the first items being: > >>>> Type: [drop-down with a None option] > >>>> Subtree: [textbox that is disabled when a Type is selected] > >>>> > >>>> The Subtree should be a one-line textbox. It would be acceptable > >>>> if the whole DN doesn't always fit, it's the first part that's > >>>> important. > >>>> > >>>> Remember to only send Subtree if Type is (staying as | being set > >>>> to) None. > >>>> > >>>> Also, the Add dialog should use this instead of the "Define by". > >>> > >>> Done > >>> > >>>> > >>>> > >>>> > >>>> With managed permissions, if I try to change both > >>>> included/excluded attribute list and the effective attributes, I > >>>> get a validation error, which is good in CLI but it doesn't work > >>>> well for the UI. > >>>> > >>>> I think it would be better to move "Managed permission > >>>> overrides" below "Target", and make it read-only. And perhaps > >>>> rename it to something like > >>>> "Attribute breakdown". > >>>> Managing the included/excluded lists directly is only useful for > >>>> upgrades with a heavily customized policy, and for upgrades you > >>>> need the > >>>> CLI anyway. Normally, having only the attribute list editable > >>>> should be fine. > >>> > >>> Done > >>> > >>>> > >>>> > >>>> > >>>> For SYSTEM permissions (those which only have the SYSTEM flag), > >>>> such as 'Add Automember Rebuild Membership Task', Permissions > >>>> should not be editable. > >>>> For old-style permissions (those without any flags), nothing is > >>>> editable > >>>> but everything should be. The attributelevelrights are missing > >>>> because the entry doesn't have the ipaPermissionV2 objectclass > >>>> yet (although it's being reported, which is "my" bug -- #4257). > >>> > >>> Fields were set to be editable if attributes level rights are > >>> missing. > >> > >> That solves things for normal legacy permissions, but not for the > >> SYSTEM ones - those should be completely read-only. > >> > >> Also, changing the Permisisons checkboxes on these permissions > >> doesn't mark them dirty. > >> > >> Otherwise the patches work great! > >> > > > > Fixed > > > > New versions of 556 and 557 attached. > > > > Great, thanks! > ACK for the functionality, I can't really judge the javascript though. > ACK for the code and the test, besides these two issues(don't know if it has to be corrected): 555: - typo in commit message(~delimeter) 557: - install/ui/test/aci_tests.js tab error at first row Greets: Adam From redhatrises at gmail.com Wed Mar 19 23:03:56 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 19 Mar 2014 17:03:56 -0600 Subject: [Freeipa-devel] [PATCH] [DOC] login as another user in the WebUI In-Reply-To: <532964DA.90308@redhat.com> References: <532964DA.90308@redhat.com> Message-ID: Thanks for the review. Here's an updated patch. Gabe On Wed, Mar 19, 2014 at 3:35 AM, Petr Vobornik wrote: > On 19.3.2014 02:29, Gabe Alford wrote: > >> All, >> >> Just added a couple of steps under section 4.3.6 >> >> Let me know if I need to change anything. >> >> https://fedorahosted.org/freeipa/ticket/3064 >> >> Thanks, >> >> Gabe >> >> >> > Hello Gabe, > > thank you for the patch. > > Main issue, even though it looks like a nitpick, is that you mix tabs and > spaces. Tabs would be better since the rest of the file uses them. > > Content is OK. I'd like to add that in step 3 user doesn't have to use > forms-based auth. He can also obtain TGT using kinit with credentials for > different user. > > So basically: > 1) kdestroy > 2) logout > 3) kinit anotheruser > 4) open web ui > -- > Petr Vobornik > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0009-2-DOC-Log-into-the-Web-UI-as-another-user.patch Type: text/x-patch Size: 1677 bytes Desc: not available URL: From pvoborni at redhat.com Thu Mar 20 08:00:40 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 20 Mar 2014 09:00:40 +0100 Subject: [Freeipa-devel] [PATCH] 550 webui-css: improve radio, checkbox keyboard support and color In-Reply-To: <20140319163219.1e41f100@unused-4-246.brq.redhat.com> References: <5319D8F7.7080304@redhat.com> <5321D509.1020004@redhat.com> <53233EC2.2060302@redhat.com> <20140319163219.1e41f100@unused-4-246.brq.redhat.com> Message-ID: <532AA028.8070802@redhat.com> On 19.3.2014 16:32, Misnyovszki Adam wrote: > On Fri, 14 Mar 2014 18:39:14 +0100 > Petr Vobornik wrote: > >> On 13.3.2014 16:55, Petr Vobornik wrote: >>> On 7.3.2014 15:34, Petr Vobornik wrote: >>>> checkboxes and radio buttons: >>>> - do not change color on hover when disabled >>>> - are focusable and checkable by keyboard again. This uses a little >>>> trick where the real checkbox is hidden under the artificial >>>> checkbox. That way it has the same position and therefore it >>>> works even in containers with overflow set. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4217 >>>> >>> >>> Self-NACK. >>> >>> Breaks Automount Key deletion in ipa/ui/#/e/automountmap/keys/ >> >> Fixed in attached patch #551. >> >> Also attaching new version of #550 with CI fixes. > > works now, > ACK > > Greets > Adam > Pushed to master: * fddb2212bc3394068ba0cd6aebbfcf2e77cb6def webui-css: improve radio,checkbox keyboard support and color * ffab72cc79d31c59d49d40b4f66852e767821fa6 webui: do not use dom for getting selected automount keys -- Petr Vobornik From pvoborni at redhat.com Thu Mar 20 09:06:29 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 20 Mar 2014 10:06:29 +0100 Subject: [Freeipa-devel] [PATCH] 552-557 Permissions v2 Web UI In-Reply-To: <20140319170333.29113ef8@unused-4-246.brq.redhat.com> References: <532340AE.9030900@redhat.com> <53270527.8030202@redhat.com> <53283765.2080402@redhat.com> <53285327.9060907@redhat.com> <53286CA5.8060105@redhat.com> <532968CA.6060609@redhat.com> <20140319170333.29113ef8@unused-4-246.brq.redhat.com> Message-ID: <532AAF95.9070305@redhat.com> On 19.3.2014 17:03, Misnyovszki Adam wrote: > On Wed, 19 Mar 2014 10:52:10 +0100 > Petr Viktorin wrote: > >> On 03/18/2014 04:56 PM, Petr Vobornik wrote: >>> On 18.3.2014 15:07, Petr Viktorin wrote: >>>> On 03/18/2014 01:09 PM, Petr Vobornik wrote: >>>>> New revision for patch patch #557 attached. >>>>> >>>>> On 17.3.2014 15:22, Petr Viktorin wrote: >>>>>> On 03/14/2014 06:47 PM, Petr Vobornik wrote: >>>>>>> Main ACI UI changes are in patch #557. The rest are >>>>>>> prerequisites. >>>>>> >>>>>> With this UI it is impossible to change from "Type-based" >>>>>> permissions to >>>>>> "General" ones. This seems to be remaining from the old model >>>>>> where permissions were type/filter/subtree/targetgroup were >>>>>> "classes" of a permission rather than co-existing as attributes. >>>>>> >>>>>> Rather the Target section should IMO look the same for all >>>>>> (non-managed) >>>>>> permissions, with the first items being: >>>>>> Type: [drop-down with a None option] >>>>>> Subtree: [textbox that is disabled when a Type is selected] >>>>>> >>>>>> The Subtree should be a one-line textbox. It would be acceptable >>>>>> if the whole DN doesn't always fit, it's the first part that's >>>>>> important. >>>>>> >>>>>> Remember to only send Subtree if Type is (staying as | being set >>>>>> to) None. >>>>>> >>>>>> Also, the Add dialog should use this instead of the "Define by". >>>>> >>>>> Done >>>>> >>>>>> >>>>>> >>>>>> >>>>>> With managed permissions, if I try to change both >>>>>> included/excluded attribute list and the effective attributes, I >>>>>> get a validation error, which is good in CLI but it doesn't work >>>>>> well for the UI. >>>>>> >>>>>> I think it would be better to move "Managed permission >>>>>> overrides" below "Target", and make it read-only. And perhaps >>>>>> rename it to something like >>>>>> "Attribute breakdown". >>>>>> Managing the included/excluded lists directly is only useful for >>>>>> upgrades with a heavily customized policy, and for upgrades you >>>>>> need the >>>>>> CLI anyway. Normally, having only the attribute list editable >>>>>> should be fine. >>>>> >>>>> Done >>>>> >>>>>> >>>>>> >>>>>> >>>>>> For SYSTEM permissions (those which only have the SYSTEM flag), >>>>>> such as 'Add Automember Rebuild Membership Task', Permissions >>>>>> should not be editable. p>>>>>> For old-style permissions (those without any flags), nothing is >>>>>> editable >>>>>> but everything should be. The attributelevelrights are missing >>>>>> because the entry doesn't have the ipaPermissionV2 objectclass >>>>>> yet (although it's being reported, which is "my" bug -- #4257). >>>>> >>>>> Fields were set to be editable if attributes level rights are >>>>> missing. >>>> >>>> That solves things for normal legacy permissions, but not for the >>>> SYSTEM ones - those should be completely read-only. >>>> >>>> Also, changing the Permisisons checkboxes on these permissions >>>> doesn't mark them dirty. >>>> >>>> Otherwise the patches work great! >>>> >>> >>> Fixed >>> >>> New versions of 556 and 557 attached. >>> >> >> Great, thanks! >> ACK for the functionality, I can't really judge the javascript though. >> > > ACK for the code and the test, besides these two issues(don't know if it > has to be corrected): > 555: > - typo in commit message(~delimeter) fixed before push > 557: > - install/ui/test/aci_tests.js tab error at first row fixed before push > > Greets: > Adam > pushed to master: * 1ff095333e9c5eb90b160c619d65f823f1f9f0a0 webui-static: update metadata files * 80324fcb23ba6559487ba29074b608dc2bbf4945 webui: fix unit tests * c93dd068e475a46da7d58619c83db8832ff81ba1 webui: better check for existing options in attributes_widgets * d40dd17fb1658731d6df8dc805a44421f99dab38 webui: do not create
delimiter between sections * 4de360fd2c9ec2c67737821ddeb1c5a0b34737b1 webui: reflect enabled state in child widgets of a multivalued widget * 5efcb240ce4b304ecc9f90a9bb70e1f85436d5c0 webui: change permissions UI to v2 -- Petr Vobornik From pvoborni at redhat.com Thu Mar 20 09:12:17 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 20 Mar 2014 10:12:17 +0100 Subject: [Freeipa-devel] [PATCH] 559 webui: update license information of used third party code In-Reply-To: <1395242381.26633.22.camel@willson.li.ssimo.org> References: <5329B16E.6060600@redhat.com> <1395242381.26633.22.camel@willson.li.ssimo.org> Message-ID: <532AB0F1.8040801@redhat.com> On 19.3.2014 16:19, Simo Sorce wrote: > On Wed, 2014-03-19 at 16:02 +0100, Petr Vobornik wrote: >> I have some cleanup and refactoring patches which were created along >> with RCUE login effort. >> >> They are not that much connected so I'm sending them now (in 4 mails) to >> make the subsequent review smaller. >> >> >> [PATCH] webui: update license information of used third party code >> Reflects: >> - adding of RCUE styles along with Bootstrap 2.0. >> - removal of jQuery BBQ plugin >> - removal of rhino enviroment for selenium which was used in old UI tests > > ACK > Simo. > Pushed to master: 90275e2f541413d2fe1a20bbbca381d4117f8712 -- Petr Vobornik From mkosek at redhat.com Thu Mar 20 08:39:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Mar 2014 09:39:42 +0100 Subject: [Freeipa-devel] [PATCH] 464 Proxy PKI clone /ca/ee/ca/profileSubmit URI Message-ID: <532AA94E.3070906@redhat.com> PKI change done in ticket https://fedorahosted.org/pki/ticket/816 requires the PKI Clone's SSL Server certificate to be issued by it's associated PKI master. Allow this call on IPA master. https://fedorahosted.org/freeipa/ticket/4265 --- We will need this change in upcoming FreeIPA 3.3.5 which would be then needed both in F19 and F20 to make the F20 cloning work again. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-464-proxy-pki-clone-ca-ee-ca-profilesubmit-uri.patch Type: text/x-patch Size: 1475 bytes Desc: not available URL: From pviktori at redhat.com Thu Mar 20 10:06:41 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Mar 2014 11:06:41 +0100 Subject: [Freeipa-devel] [PATCH] Review: rga-0005 Fix order of synchronizing time when running ipa-client-install In-Reply-To: References: <53285C1A.6010409@redhat.com> <53285D3E.3050700@redhat.com> <5328608E.8070403@redhat.com> <20140318150902.GF16644@redhat.com> Message-ID: <532ABDB1.9070401@redhat.com> On 03/18/2014 04:17 PM, Gabe Alford wrote: > Patch was posted for review on Feb 19th, but may have missed due to > volume, priorities, etc. We (freeipa commiters) try to give priority to reviewing patches, but this one fell through the cracks. Sorry for that! Please feel free ask for status or bug someone personally if this ever happens again. Patch pushed to master: 1f4869a3fa35b837b7734146a30249a294d0ad4e Thanks for the contribution, and again sorry for the delay. -- Petr? From massimiliano.perrone at tirasa.net Thu Mar 20 09:32:46 2014 From: massimiliano.perrone at tirasa.net (Massimiliano Perrone (tirasa.net)) Date: Thu, 20 Mar 2014 10:32:46 +0100 Subject: [Freeipa-devel] Talking json/rpc with java client In-Reply-To: <20140318162607.GH16644@redhat.com> References: <20140318091035.GA9052@redhat.com> <53281662.3030105@tirasa.net> <20140318102643.GC16644@redhat.com> <53286E45.4000605@tirasa.net> <20140318162607.GH16644@redhat.com> Message-ID: <532AB5BE.2070409@tirasa.net> On 03/18/2014 05:26 PM, Alexander Bokovoy wrote: > On Tue, 18 Mar 2014, Massimiliano Perrone (example.com) wrote: >>>> The difference between the two calls is on the last TGS_REQ; >>>> because the first one is on ldap/olmo.example.com at EXAMPLE.COM and >>>> it's OK whereas the second one is on >>>> HTTP/olmo.example.com at EXAMPLE.COM that returns a 401 (I suppose). >>>> >>>> Where's the error? >>> Am I correct that you have a user connecting to HTTP/ebano.example.com >>> and then HTTP/ebano.example.com wants to talk to HTTP/olmo.example.com >>> using credentials of the user? >>> >>> FreeIPA uses constraint delegation of the credentials, with the help of >>> S4U2Proxy extension. You need to allow HTTP/ebano.example.com to >>> delegate >>> credentials to HTTP/olmo.example.com. >>> >>> I have written an article how to do that: >>> https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html >>> >>> >>> >> Hi Alexander, thanks for your reply. >> I read carefully your interesting post and I follow it to delegate >> HTTP/ebano.example.com credentials to HTTP/olmo.example.com. >> >> Now, two questions: >> 1) How can I check that my configuration, now is ok? Because this >> ldapsearch returns result: 0 >> >> ldapsearch -Y GSSAPI -H ldap://olmo.example.com -b >> "cn=s4u2proxy,cn=etc,dc=example,dc=com" >> "cn=ipa-http-delegation-targets" dn > You need to create these delegation entries yourself, like the article > says. Note that your app talks to IPA server's HTTP service, so create > > dn: cn=ebano-http-delegation,cn=s4u2proxy,cn=etc,dc=example,dc=com > objectClass: ipaKrb5DelegationACL > objectClass: groupOfPrincipals > objectClass: top > cn: ebano-http-delegation > memberPrincipal: HTTP/ebano.example.com at EXAMPLE.COM > ipaAllowedTarget: > cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com > > This entry says: "HTTP/ebano.example.com is allowed to delegate users' > credentials to whatever Kerberos principal is a member of > cn=ebano-http-delegation-targets group" > > Now, this is the group: > dn: > cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com > objectClass: groupOfPrincipals > objectClass: top > cn: ebano-http-delegation-targets > memberPrincipal: HTTP/olomo.example.com at EXAMPLE.COM > > With these two entries we would have HTTP/ebano.example.com allowed to > delegate users' credentials to HTTP/olomo.example.com Hi Alexander, thanks for your patience. I followed your suggestions but the result is always the same. Trying with curl, of course, it works. My doubt now is why curl generates this log on kerberos server mar 20 10:22:20 olmo.example.com krb5kdc[5091](info): TGS_REQ (1 etypes {18}) 192.168.0.105: ISSUE: authtime 1395301975, etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM mar 20 10:22:21 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime 1395301975, etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for ldap/olmo.example.com at EXAMPLE.COM whereas java generates this other one mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.105: NEEDED_PREAUTH: HTTP/ebano.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication required mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.0.105: ISSUE: authtime 1395307449, etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 etypes {18 17 16 23 1 3}) 192.168.0.105: ISSUE: authtime 1395307449, etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for HTTP/olmo.example.com at EXAMPLE.COM As you can see, the first one uses admin on ldap service, the second one uses HTTP/ebano.example.com on HTTP service. Can I do the same call with Java? I also attached LDAP log file of two calls. Massi > > You don't need to allow HTTP/olomo.example.com to further delegate > credentials to ldap/olomo.example.com because this entry already exists > -- each IPA master's HTTP service is allowed to delegate users' > credentials to own ldap/ service. > >> 2) This time however I read also /var/log/httpd/error_log and I >> noticed this: >> ############# >> [Tue Mar 18 16:38:14.117207 2014] [:error] [pid 11268] ipa: ERROR: >> 500 Internal Server Error: >> jsonserver_kerb.__call__: KRB5CCNAME not defined in HTTP request >> environment >> ############# >> whereas LDAP logs are OK. >> In your opinion, I have this error because of wrong environment >> configuration or other cause? > This is most likely because you have no Kerberos ticket available. > > -- Massimiliano Perrone Tel +39 393 9121310 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.example.com Apache Syncope PMC Member http://people.apache.org/~massi/ "L'apprendere molte cose non insegna l'intelligenza" (Eraclito) -------------- next part -------------- [20/Mar/2014:10:10:14 +0100] conn=4 op=165 SRCH base="dc=tirasa,dc=net" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=HTTP/ebano.tirasa.net at TIRASA.NET))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [20/Mar/2014:10:10:14 +0100] conn=4 op=165 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:10:14 +0100] conn=4 op=166 SRCH base="cn=TIRASA.NET,cn=kerberos,dc=tirasa,dc=net" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [20/Mar/2014:10:10:14 +0100] conn=4 op=166 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:10:14 +0100] conn=4 op=167 SRCH base="dc=tirasa,dc=net" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/TIRASA.NET at TIRASA.NET)(krbPrincipalName=krbtgt/TIRASA.NET at TIRASA.NET)))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [20/Mar/2014:10:10:14 +0100] conn=4 op=167 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:10:14 +0100] conn=4 op=168 SRCH base="cn=global_policy,cn=TIRASA.NET,cn=kerberos,dc=tirasa,dc=net" scope=0 filter="(objectClass=*)" attrs="krbMaxPwdLife krbMinPwdLife krbPwdMinDiffChars krbPwdMinLength krbPwdHistoryLength krbPwdMaxFailure krbPwdFailureCountInterval krbPwdLockoutDuration" [20/Mar/2014:10:10:14 +0100] conn=4 op=168 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:10:14 +0100] conn=4 op=169 SRCH base="dc=tirasa,dc=net" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=HTTP/ebano.tirasa.net at TIRASA.NET))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [20/Mar/2014:10:10:14 +0100] conn=4 op=169 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:10:14 +0100] conn=4 op=170 SRCH base="cn=TIRASA.NET,cn=kerberos,dc=tirasa,dc=net" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [20/Mar/2014:10:10:14 +0100] conn=4 op=170 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:10:14 +0100] conn=4 op=171 SRCH base="dc=tirasa,dc=net" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/TIRASA.NET at TIRASA.NET)(krbPrincipalName=krbtgt/TIRASA.NET at TIRASA.NET)))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [20/Mar/2014:10:10:14 +0100] conn=4 op=171 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:10:14 +0100] conn=4 op=172 SRCH base="cn=global_policy,cn=TIRASA.NET,cn=kerberos,dc=tirasa,dc=net" scope=0 filter="(objectClass=*)" attrs="krbMaxPwdLife krbMinPwdLife krbPwdMinDiffChars krbPwdMinLength krbPwdHistoryLength krbPwdMaxFailure krbPwdFailureCountInterval krbPwdLockoutDuration" [20/Mar/2014:10:10:14 +0100] conn=4 op=172 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:10:14 +0100] conn=4 op=173 SRCH base="cn=ad,cn=trusts,dc=tirasa,dc=net" scope=2 filter="(objectClass=ipaNTTrustedDomain)" attrs=ALL [20/Mar/2014:10:10:14 +0100] conn=4 op=173 RESULT err=32 tag=101 nentries=0 etime=0 [20/Mar/2014:10:10:14 +0100] conn=4 op=174 SRCH base="krbprincipalname=HTTP/ebano.tirasa.net at TIRASA.NET,cn=services,cn=accounts,dc=tirasa,dc=net" scope=0 filter="(objectClass=*)" attrs="objectClass uid cn fqdn gidNumber krbPrincipalName krbCanonicalName krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbLastAdminUnlock krbTicketFlags ipaNTSecurityIdentifier ipaNTLogonScript ipaNTProfilePath ipaNTHomeDirectory ipaNTHomeDirectoryDrive" [20/Mar/2014:10:10:14 +0100] conn=4 op=174 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:10:14 +0100] conn=4 op=175 SRCH base="cn=ebano.tirasa.net,cn=masters,cn=ipa,cn=etc,dc=tirasa,dc=net" scope=0 filter="(objectClass=*)" attrs=ALL [20/Mar/2014:10:10:14 +0100] conn=4 op=175 RESULT err=32 tag=101 nentries=0 etime=0 [20/Mar/2014:10:10:14 +0100] conn=4 op=176 MOD dn="krbprincipalname=HTTP/ebano.tirasa.net at TIRASA.NET,cn=services,cn=accounts,dc=tirasa,dc=net" [20/Mar/2014:10:10:14 +0100] conn=4 op=176 RESULT err=0 tag=103 nentries=0 etime=0 [20/Mar/2014:10:10:14 +0100] conn=4 op=177 SRCH base="dc=tirasa,dc=net" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=krbtgt/TIRASA.NET at TIRASA.NET))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [20/Mar/2014:10:10:14 +0100] conn=4 op=177 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:10:14 +0100] conn=4 op=178 SRCH base="dc=tirasa,dc=net" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=HTTP/olmo.tirasa.net at TIRASA.NET)(krbPrincipalName=HTTP/olmo.tirasa.net at TIRASA.NET)))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [20/Mar/2014:10:10:14 +0100] conn=4 op=178 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:10:14 +0100] conn=4 op=179 SRCH base="cn=TIRASA.NET,cn=kerberos,dc=tirasa,dc=net" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [20/Mar/2014:10:10:14 +0100] conn=4 op=179 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:10:14 +0100] conn=4 op=180 SRCH base="dc=tirasa,dc=net" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=HTTP/ebano.tirasa.net at TIRASA.NET))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [20/Mar/2014:10:10:14 +0100] conn=4 op=180 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:10:14 +0100] conn=4 op=181 SRCH base="cn=TIRASA.NET,cn=kerberos,dc=tirasa,dc=net" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [20/Mar/2014:10:10:14 +0100] conn=4 op=181 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:10:22 +0100] conn=6 op=13 SRCH base="ou=certificateRepository,ou=ca,o=ipaca" scope=1 filter="(certStatus=INVALID)" attrs="objectClass serialno notBefore notAfter duration extension subjectName userCertificate version algorithmId signingAlgorithmId publicKeyData" [20/Mar/2014:10:10:22 +0100] conn=6 op=13 SORT notBefore [20/Mar/2014:10:10:22 +0100] conn=6 op=13 VLV 200:0:20140320101022Z 1:0 (0) [20/Mar/2014:10:10:22 +0100] conn=6 op=13 RESULT err=0 tag=101 nentries=0 etime=0 [20/Mar/2014:10:10:22 +0100] conn=6 op=14 SRCH base="ou=certificateRepository,ou=ca,o=ipaca" scope=1 filter="(certStatus=VALID)" attrs="objectClass serialno notBefore notAfter duration extension subjectName userCertificate version algorithmId signingAlgorithmId publicKeyData" [20/Mar/2014:10:10:22 +0100] conn=6 op=14 SORT notAfter [20/Mar/2014:10:10:22 +0100] conn=6 op=14 VLV 200:0:20140320101022Z 1:10 (0) [20/Mar/2014:10:10:22 +0100] conn=6 op=14 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:10:22 +0100] conn=6 op=15 SRCH base="ou=certificateRepository,ou=ca,o=ipaca" scope=1 filter="(certStatus=REVOKED)" attrs="objectClass revokedOn serialno revInfo notAfter notBefore duration extension subjectName userCertificate version algorithmId signingAlgorithmId publicKeyData" [20/Mar/2014:10:10:22 +0100] conn=6 op=15 VLV 200:0:20140320101022Z 0:0 (0) [20/Mar/2014:10:10:22 +0100] conn=6 op=15 RESULT err=0 tag=101 nentries=0 etime=0 notes=U [20/Mar/2014:10:10:22 +0100] conn=6 op=16 SRCH base="ou=certificateRepository,ou=ca,o=ipaca" scope=0 filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="description" [20/Mar/2014:10:10:22 +0100] conn=6 op=16 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:10:26 +0100] conn=14 op=4 SRCH base="ou=sessions,ou=Security Domain,o=ipaca" scope=2 filter="(objectClass=securityDomainSessionEntry)" attrs="cn" [20/Mar/2014:10:10:26 +0100] conn=14 op=4 RESULT err=32 tag=101 nentries=0 etime=0 -------------- next part -------------- [20/Mar/2014:10:09:18 +0100] conn=4 op=155 SRCH base="dc=tirasa,dc=net" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=krbtgt/TIRASA.NET at TIRASA.NET))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [20/Mar/2014:10:09:18 +0100] conn=4 op=155 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:18 +0100] conn=4 op=156 SRCH base="dc=tirasa,dc=net" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/TIRASA.NET at TIRASA.NET)(krbPrincipalName=krbtgt/TIRASA.NET at TIRASA.NET)))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [20/Mar/2014:10:09:18 +0100] conn=4 op=156 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:18 +0100] conn=4 op=157 SRCH base="dc=tirasa,dc=net" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=admin at TIRASA.NET))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [20/Mar/2014:10:09:18 +0100] conn=4 op=157 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:18 +0100] conn=4 op=158 SRCH base="cn=TIRASA.NET,cn=kerberos,dc=tirasa,dc=net" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [20/Mar/2014:10:09:18 +0100] conn=4 op=158 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:18 +0100] conn=4 op=159 SRCH base="dc=tirasa,dc=net" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=krbtgt/TIRASA.NET at TIRASA.NET))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [20/Mar/2014:10:09:18 +0100] conn=4 op=159 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:18 +0100] conn=19 fd=90 slot=90 connection from 192.168.0.106 to 192.168.0.106 [20/Mar/2014:10:09:18 +0100] conn=4 op=160 SRCH base="dc=tirasa,dc=net" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/olmo.tirasa.net at TIRASA.NET)(krbPrincipalName=ldap/olmo.tirasa.net at TIRASA.NET)))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [20/Mar/2014:10:09:18 +0100] conn=4 op=160 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:18 +0100] conn=4 op=161 SRCH base="cn=TIRASA.NET,cn=kerberos,dc=tirasa,dc=net" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [20/Mar/2014:10:09:18 +0100] conn=4 op=161 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:18 +0100] conn=4 op=162 SRCH base="dc=tirasa,dc=net" scope=2 filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal))(krbPrincipalName=admin at TIRASA.NET))" attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias krbUPEnabled krbPrincipalKey krbTicketPolicyReference krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData ipaUserAuthType objectClass" [20/Mar/2014:10:09:18 +0100] conn=4 op=162 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:18 +0100] conn=4 op=163 SRCH base="cn=TIRASA.NET,cn=kerberos,dc=tirasa,dc=net" scope=0 filter="(objectClass=krbticketpolicyaux)" attrs="krbMaxTicketLife krbMaxRenewableAge krbTicketFlags" [20/Mar/2014:10:09:18 +0100] conn=4 op=163 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:18 +0100] conn=19 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [20/Mar/2014:10:09:18 +0100] conn=19 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [20/Mar/2014:10:09:19 +0100] conn=19 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [20/Mar/2014:10:09:19 +0100] conn=19 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [20/Mar/2014:10:09:19 +0100] conn=19 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [20/Mar/2014:10:09:19 +0100] conn=19 op=3 SRCH base="cn=ipaconfig,cn=etc,dc=tirasa,dc=net" scope=0 filter="(objectClass=*)" attrs=ALL [20/Mar/2014:10:09:19 +0100] conn=19 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net" [20/Mar/2014:10:09:19 +0100] conn=19 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=4 SRCH base="cn=schema" scope=0 filter="(objectClass=*)" attrs="attributeTypes objectClasses" [20/Mar/2014:10:09:19 +0100] conn=19 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=5 SRCH base="cn=users,cn=accounts,dc=tirasa,dc=net" scope=1 filter="(objectClass=posixaccount)" attrs="telephoneNumber sshpubkeyfp uid title loginShell * uidNumber gidNumber sn homeDirectory mail givenName nsAccountLock aci" [20/Mar/2014:10:09:19 +0100] conn=19 op=5 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=6 SRCH base="cn=admins,cn=groups,cn=accounts,dc=tirasa,dc=net" scope=0 filter="(|(member=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberHost=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberUser=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net))" attrs="memberOf" [20/Mar/2014:10:09:19 +0100] conn=19 op=6 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=7 SRCH base="cn=replication administrators,cn=privileges,cn=pbac,dc=tirasa,dc=net" scope=0 filter="(|(member=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberHost=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberUser=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net))" attrs="memberOf" [20/Mar/2014:10:09:19 +0100] conn=19 op=7 RESULT err=0 tag=101 nentries=0 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=8 SRCH base="cn=add replication agreements,cn=permissions,cn=pbac,dc=tirasa,dc=net" scope=0 filter="(|(member=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberHost=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberUser=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net))" attrs="memberOf" [20/Mar/2014:10:09:19 +0100] conn=19 op=8 RESULT err=0 tag=101 nentries=0 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=9 SRCH base="cn=modify replication agreements,cn=permissions,cn=pbac,dc=tirasa,dc=net" scope=0 filter="(|(member=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberHost=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberUser=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net))" attrs="memberOf" [20/Mar/2014:10:09:19 +0100] conn=19 op=9 RESULT err=0 tag=101 nentries=0 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=10 SRCH base="cn=remove replication agreements,cn=permissions,cn=pbac,dc=tirasa,dc=net" scope=0 filter="(|(member=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberHost=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberUser=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net))" attrs="memberOf" [20/Mar/2014:10:09:19 +0100] conn=19 op=10 RESULT err=0 tag=101 nentries=0 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=11 SRCH base="cn=modify dna range,cn=permissions,cn=pbac,dc=tirasa,dc=net" scope=0 filter="(|(member=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberHost=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberUser=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net))" attrs="memberOf" [20/Mar/2014:10:09:19 +0100] conn=19 op=11 RESULT err=0 tag=101 nentries=0 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=12 SRCH base="cn=host enrollment,cn=privileges,cn=pbac,dc=tirasa,dc=net" scope=0 filter="(|(member=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberHost=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberUser=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net))" attrs="memberOf" [20/Mar/2014:10:09:19 +0100] conn=19 op=12 RESULT err=0 tag=101 nentries=0 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=13 SRCH base="cn=manage host keytab,cn=permissions,cn=pbac,dc=tirasa,dc=net" scope=0 filter="(|(member=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberHost=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberUser=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net))" attrs="memberOf" [20/Mar/2014:10:09:19 +0100] conn=19 op=13 RESULT err=0 tag=101 nentries=0 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=14 SRCH base="cn=enroll a host,cn=permissions,cn=pbac,dc=tirasa,dc=net" scope=0 filter="(|(member=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberHost=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberUser=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net))" attrs="memberOf" [20/Mar/2014:10:09:19 +0100] conn=19 op=14 RESULT err=0 tag=101 nentries=0 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=15 SRCH base="cn=add krbprincipalname to a host,cn=permissions,cn=pbac,dc=tirasa,dc=net" scope=0 filter="(|(member=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberHost=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberUser=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net))" attrs="memberOf" [20/Mar/2014:10:09:19 +0100] conn=19 op=15 RESULT err=0 tag=101 nentries=0 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=16 SRCH base="cn=unlock user accounts,cn=permissions,cn=pbac,dc=tirasa,dc=net" scope=0 filter="(|(member=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberHost=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberUser=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net))" attrs="memberOf" [20/Mar/2014:10:09:19 +0100] conn=19 op=16 RESULT err=0 tag=101 nentries=0 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=17 SRCH base="cn=manage service keytab,cn=permissions,cn=pbac,dc=tirasa,dc=net" scope=0 filter="(|(member=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberHost=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberUser=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net))" attrs="memberOf" [20/Mar/2014:10:09:19 +0100] conn=19 op=17 RESULT err=0 tag=101 nentries=0 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=18 SRCH base="cn=trust admins,cn=groups,cn=accounts,dc=tirasa,dc=net" scope=0 filter="(|(member=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberHost=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net)(memberUser=uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net))" attrs="memberOf" [20/Mar/2014:10:09:19 +0100] conn=19 op=18 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=19 SRCH base="uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net" scope=0 filter="(userPassword=*)" attrs="userPassword" [20/Mar/2014:10:09:19 +0100] conn=19 op=19 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=20 SRCH base="uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net" scope=0 filter="(krbPrincipalKey=*)" attrs="krbPrincipalKey" [20/Mar/2014:10:09:19 +0100] conn=19 op=20 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=21 SRCH base="uid=admin,cn=users,cn=accounts,dc=tirasa,dc=net" scope=0 filter="(objectClass=*)" attrs="ipaSshPubKey" [20/Mar/2014:10:09:19 +0100] conn=19 op=21 RESULT err=0 tag=101 nentries=1 etime=0 [20/Mar/2014:10:09:19 +0100] conn=19 op=22 UNBIND [20/Mar/2014:10:09:19 +0100] conn=19 op=22 fd=90 closed - U1 From abokovoy at redhat.com Thu Mar 20 10:31:19 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 20 Mar 2014 12:31:19 +0200 Subject: [Freeipa-devel] Talking json/rpc with java client In-Reply-To: <532AB5BE.2070409@tirasa.net> References: <20140318091035.GA9052@redhat.com> <53281662.3030105@tirasa.net> <20140318102643.GC16644@redhat.com> <53286E45.4000605@tirasa.net> <20140318162607.GH16644@redhat.com> <532AB5BE.2070409@tirasa.net> Message-ID: <20140320103119.GO16644@redhat.com> On Thu, 20 Mar 2014, Massimiliano Perrone (tirasa.net) wrote: >On 03/18/2014 05:26 PM, Alexander Bokovoy wrote: >>On Tue, 18 Mar 2014, Massimiliano Perrone (example.com) wrote: >>>>>The difference between the two calls is on the last TGS_REQ; >>>>>because the first one is on ldap/olmo.example.com at EXAMPLE.COM >>>>>and it's OK whereas the second one is on >>>>>HTTP/olmo.example.com at EXAMPLE.COM that returns a 401 (I >>>>>suppose). >>>>> >>>>>Where's the error? >>>>Am I correct that you have a user connecting to HTTP/ebano.example.com >>>>and then HTTP/ebano.example.com wants to talk to HTTP/olmo.example.com >>>>using credentials of the user? >>>> >>>>FreeIPA uses constraint delegation of the credentials, with the help of >>>>S4U2Proxy extension. You need to allow HTTP/ebano.example.com >>>>to delegate >>>>credentials to HTTP/olmo.example.com. >>>> >>>>I have written an article how to do that: >>>>https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html >>>> >>>> >>>> >>>Hi Alexander, thanks for your reply. >>>I read carefully your interesting post and I follow it to >>>delegate HTTP/ebano.example.com credentials to >>>HTTP/olmo.example.com. >>> >>>Now, two questions: >>>1) How can I check that my configuration, now is ok? Because this >>>ldapsearch returns result: 0 >>> >>>ldapsearch -Y GSSAPI -H ldap://olmo.example.com -b >>>"cn=s4u2proxy,cn=etc,dc=example,dc=com" >>>"cn=ipa-http-delegation-targets" dn >>You need to create these delegation entries yourself, like the article >>says. Note that your app talks to IPA server's HTTP service, so create >> >>dn: cn=ebano-http-delegation,cn=s4u2proxy,cn=etc,dc=example,dc=com >>objectClass: ipaKrb5DelegationACL >>objectClass: groupOfPrincipals >>objectClass: top >>cn: ebano-http-delegation >>memberPrincipal: HTTP/ebano.example.com at EXAMPLE.COM >>ipaAllowedTarget: cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com >> >>This entry says: "HTTP/ebano.example.com is allowed to delegate users' >>credentials to whatever Kerberos principal is a member of >>cn=ebano-http-delegation-targets group" >> >>Now, this is the group: >>dn: cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com >>objectClass: groupOfPrincipals >>objectClass: top >>cn: ebano-http-delegation-targets >>memberPrincipal: HTTP/olomo.example.com at EXAMPLE.COM >> >>With these two entries we would have HTTP/ebano.example.com allowed to >>delegate users' credentials to HTTP/olomo.example.com > >Hi Alexander, thanks for your patience. >I followed your suggestions but the result is always the same. > >Trying with curl, of course, it works. > >My doubt now is why curl generates this log on kerberos server > >mar 20 10:22:20 olmo.example.com krb5kdc[5091](info): TGS_REQ (1 >etypes {18}) 192.168.0.105: ISSUE: authtime 1395301975, etypes >{rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for >krbtgt/EXAMPLE.COM at EXAMPLE.COM >mar 20 10:22:21 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 >etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime >1395301975, etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for >ldap/olmo.example.com at EXAMPLE.COM This is effect of S4U extension working correctly. >whereas java generates this other one > >mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 >etypes {18 17 16 23}) 192.168.0.105: NEEDED_PREAUTH: >HTTP/ebano.example.com at EXAMPLE.COM for >krbtgt/EXAMPLE.COM at EXAMPLE.COM, Additional pre-authentication >required >mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 >etypes {18 17 16 23}) 192.168.0.105: ISSUE: authtime 1395307449, >etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for >krbtgt/EXAMPLE.COM at EXAMPLE.COM >mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 >etypes {18 17 16 23 1 3}) 192.168.0.105: ISSUE: authtime 1395307449, >etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for >HTTP/olmo.example.com at EXAMPLE.COM > >As you can see, the first one uses admin on ldap service, the second >one uses HTTP/ebano.example.com on HTTP service. This means your Java application doesn't use S4U extension or doesn't know about that. >Can I do the same call with Java? At this point we need to set clear what Java are you using. http://download.java.net/jdk8/docs/technotes/guides/security/jgss/jgss-features.html tells that S4U extensions (we use S4U2Proxy here) was added in Java SE 8. -- / Alexander Bokovoy From pvoborni at redhat.com Thu Mar 20 11:03:18 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 20 Mar 2014 12:03:18 +0100 Subject: [Freeipa-devel] [PATCH] [DOC] login as another user in the WebUI In-Reply-To: References: <532964DA.90308@redhat.com> Message-ID: <532ACAF6.7050202@redhat.com> On 20.3.2014 00:03, Gabe Alford wrote: > Thanks for the review. Here's an updated patch. > > Gabe ACK Pushed to master: befe9632c4636a151f5e4ed11a58e7e48ba8c877 > > > On Wed, Mar 19, 2014 at 3:35 AM, Petr Vobornik wrote: > >> On 19.3.2014 02:29, Gabe Alford wrote: >> >>> All, >>> >>> Just added a couple of steps under section 4.3.6 >>> >>> Let me know if I need to change anything. >>> >>> https://fedorahosted.org/freeipa/ticket/3064 >>> >>> Thanks, >>> >>> Gabe >>> >>> >>> >> Hello Gabe, >> >> thank you for the patch. >> >> Main issue, even though it looks like a nitpick, is that you mix tabs and >> spaces. Tabs would be better since the rest of the file uses them. >> >> Content is OK. I'd like to add that in step 3 user doesn't have to use >> forms-based auth. He can also obtain TGT using kinit with credentials for >> different user. >> >> So basically: >> 1) kdestroy >> 2) logout >> 3) kinit anotheruser >> 4) open web ui >> -- >> Petr Vobornik >> > -- Petr Vobornik From rcritten at redhat.com Thu Mar 20 12:29:19 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 20 Mar 2014 08:29:19 -0400 Subject: [Freeipa-devel] Talking json/rpc with java client In-Reply-To: <20140320103119.GO16644@redhat.com> References: <20140318091035.GA9052@redhat.com> <53281662.3030105@tirasa.net> <20140318102643.GC16644@redhat.com> <53286E45.4000605@tirasa.net> <20140318162607.GH16644@redhat.com> <532AB5BE.2070409@tirasa.net> <20140320103119.GO16644@redhat.com> Message-ID: <532ADF1F.8000002@redhat.com> Alexander Bokovoy wrote: > On Thu, 20 Mar 2014, Massimiliano Perrone (tirasa.net) wrote: >> On 03/18/2014 05:26 PM, Alexander Bokovoy wrote: >>> On Tue, 18 Mar 2014, Massimiliano Perrone (example.com) wrote: >>>>>> The difference between the two calls is on the last TGS_REQ; >>>>>> because the first one is on ldap/olmo.example.com at EXAMPLE.COM and >>>>>> it's OK whereas the second one is on >>>>>> HTTP/olmo.example.com at EXAMPLE.COM that returns a 401 (I suppose). >>>>>> >>>>>> Where's the error? >>>>> Am I correct that you have a user connecting to HTTP/ebano.example.com >>>>> and then HTTP/ebano.example.com wants to talk to HTTP/olmo.example.com >>>>> using credentials of the user? >>>>> >>>>> FreeIPA uses constraint delegation of the credentials, with the >>>>> help of >>>>> S4U2Proxy extension. You need to allow HTTP/ebano.example.com to >>>>> delegate >>>>> credentials to HTTP/olmo.example.com. >>>>> >>>>> I have written an article how to do that: >>>>> https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html >>>>> >>>>> >>>>> >>>>> >>>> Hi Alexander, thanks for your reply. >>>> I read carefully your interesting post and I follow it to delegate >>>> HTTP/ebano.example.com credentials to HTTP/olmo.example.com. >>>> >>>> Now, two questions: >>>> 1) How can I check that my configuration, now is ok? Because this >>>> ldapsearch returns result: 0 >>>> >>>> ldapsearch -Y GSSAPI -H ldap://olmo.example.com -b >>>> "cn=s4u2proxy,cn=etc,dc=example,dc=com" >>>> "cn=ipa-http-delegation-targets" dn >>> You need to create these delegation entries yourself, like the article >>> says. Note that your app talks to IPA server's HTTP service, so create >>> >>> dn: cn=ebano-http-delegation,cn=s4u2proxy,cn=etc,dc=example,dc=com >>> objectClass: ipaKrb5DelegationACL >>> objectClass: groupOfPrincipals >>> objectClass: top >>> cn: ebano-http-delegation >>> memberPrincipal: HTTP/ebano.example.com at EXAMPLE.COM >>> ipaAllowedTarget: >>> cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com >>> >>> This entry says: "HTTP/ebano.example.com is allowed to delegate users' >>> credentials to whatever Kerberos principal is a member of >>> cn=ebano-http-delegation-targets group" >>> >>> Now, this is the group: >>> dn: >>> cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com >>> objectClass: groupOfPrincipals >>> objectClass: top >>> cn: ebano-http-delegation-targets >>> memberPrincipal: HTTP/olomo.example.com at EXAMPLE.COM >>> >>> With these two entries we would have HTTP/ebano.example.com allowed to >>> delegate users' credentials to HTTP/olomo.example.com >> >> Hi Alexander, thanks for your patience. >> I followed your suggestions but the result is always the same. >> >> Trying with curl, of course, it works. >> >> My doubt now is why curl generates this log on kerberos server >> >> mar 20 10:22:20 olmo.example.com krb5kdc[5091](info): TGS_REQ (1 >> etypes {18}) 192.168.0.105: ISSUE: authtime 1395301975, etypes {rep=18 >> tkt=18 ses=18}, admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM >> mar 20 10:22:21 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 >> etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime 1395301975, >> etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for >> ldap/olmo.example.com at EXAMPLE.COM > This is effect of S4U extension working correctly. > >> whereas java generates this other one >> >> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 etypes >> {18 17 16 23}) 192.168.0.105: NEEDED_PREAUTH: >> HTTP/ebano.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, >> Additional pre-authentication required >> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 etypes >> {18 17 16 23}) 192.168.0.105: ISSUE: authtime 1395307449, etypes >> {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for >> krbtgt/EXAMPLE.COM at EXAMPLE.COM >> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 >> etypes {18 17 16 23 1 3}) 192.168.0.105: ISSUE: authtime 1395307449, >> etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for >> HTTP/olmo.example.com at EXAMPLE.COM >> >> As you can see, the first one uses admin on ldap service, the second >> one uses HTTP/ebano.example.com on HTTP service. > This means your Java application doesn't use S4U extension or doesn't > know about that. > >> Can I do the same call with Java? > At this point we need to set clear what Java are you using. > > http://download.java.net/jdk8/docs/technotes/guides/security/jgss/jgss-features.html > > tells that S4U extensions (we use S4U2Proxy here) was added in Java SE 8. > The client doesn't do the S4U2Proxy work though, so this shouldn't matter, right? I think what I'd suggest is to use the keytab you're using in java in the curl test: $ kinit -kt /path/to/keytab HTTP/ebano.example.com $ curl ... Then you'll be comparing apples to apples. rob From abokovoy at redhat.com Thu Mar 20 12:47:15 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 20 Mar 2014 14:47:15 +0200 Subject: [Freeipa-devel] Talking json/rpc with java client In-Reply-To: <532ADF1F.8000002@redhat.com> References: <20140318091035.GA9052@redhat.com> <53281662.3030105@tirasa.net> <20140318102643.GC16644@redhat.com> <53286E45.4000605@tirasa.net> <20140318162607.GH16644@redhat.com> <532AB5BE.2070409@tirasa.net> <20140320103119.GO16644@redhat.com> <532ADF1F.8000002@redhat.com> Message-ID: <20140320124715.GP16644@redhat.com> On Thu, 20 Mar 2014, Rob Crittenden wrote: >Alexander Bokovoy wrote: >>On Thu, 20 Mar 2014, Massimiliano Perrone (tirasa.net) wrote: >>>On 03/18/2014 05:26 PM, Alexander Bokovoy wrote: >>>>On Tue, 18 Mar 2014, Massimiliano Perrone (example.com) wrote: >>>>>>>The difference between the two calls is on the last TGS_REQ; >>>>>>>because the first one is on ldap/olmo.example.com at EXAMPLE.COM and >>>>>>>it's OK whereas the second one is on >>>>>>>HTTP/olmo.example.com at EXAMPLE.COM that returns a 401 (I suppose). >>>>>>> >>>>>>>Where's the error? >>>>>>Am I correct that you have a user connecting to HTTP/ebano.example.com >>>>>>and then HTTP/ebano.example.com wants to talk to HTTP/olmo.example.com >>>>>>using credentials of the user? >>>>>> >>>>>>FreeIPA uses constraint delegation of the credentials, with the >>>>>>help of >>>>>>S4U2Proxy extension. You need to allow HTTP/ebano.example.com to >>>>>>delegate >>>>>>credentials to HTTP/olmo.example.com. >>>>>> >>>>>>I have written an article how to do that: >>>>>>https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Hi Alexander, thanks for your reply. >>>>>I read carefully your interesting post and I follow it to delegate >>>>>HTTP/ebano.example.com credentials to HTTP/olmo.example.com. >>>>> >>>>>Now, two questions: >>>>>1) How can I check that my configuration, now is ok? Because this >>>>>ldapsearch returns result: 0 >>>>> >>>>>ldapsearch -Y GSSAPI -H ldap://olmo.example.com -b >>>>>"cn=s4u2proxy,cn=etc,dc=example,dc=com" >>>>>"cn=ipa-http-delegation-targets" dn >>>>You need to create these delegation entries yourself, like the article >>>>says. Note that your app talks to IPA server's HTTP service, so create >>>> >>>>dn: cn=ebano-http-delegation,cn=s4u2proxy,cn=etc,dc=example,dc=com >>>>objectClass: ipaKrb5DelegationACL >>>>objectClass: groupOfPrincipals >>>>objectClass: top >>>>cn: ebano-http-delegation >>>>memberPrincipal: HTTP/ebano.example.com at EXAMPLE.COM >>>>ipaAllowedTarget: >>>>cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com >>>> >>>>This entry says: "HTTP/ebano.example.com is allowed to delegate users' >>>>credentials to whatever Kerberos principal is a member of >>>>cn=ebano-http-delegation-targets group" >>>> >>>>Now, this is the group: >>>>dn: >>>>cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com >>>>objectClass: groupOfPrincipals >>>>objectClass: top >>>>cn: ebano-http-delegation-targets >>>>memberPrincipal: HTTP/olomo.example.com at EXAMPLE.COM >>>> >>>>With these two entries we would have HTTP/ebano.example.com allowed to >>>>delegate users' credentials to HTTP/olomo.example.com >>> >>>Hi Alexander, thanks for your patience. >>>I followed your suggestions but the result is always the same. >>> >>>Trying with curl, of course, it works. >>> >>>My doubt now is why curl generates this log on kerberos server >>> >>>mar 20 10:22:20 olmo.example.com krb5kdc[5091](info): TGS_REQ (1 >>>etypes {18}) 192.168.0.105: ISSUE: authtime 1395301975, etypes {rep=18 >>>tkt=18 ses=18}, admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM >>>mar 20 10:22:21 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 >>>etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime 1395301975, >>>etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for >>>ldap/olmo.example.com at EXAMPLE.COM >>This is effect of S4U extension working correctly. >> >>>whereas java generates this other one >>> >>>mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 etypes >>>{18 17 16 23}) 192.168.0.105: NEEDED_PREAUTH: >>>HTTP/ebano.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, >>>Additional pre-authentication required >>>mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 etypes >>>{18 17 16 23}) 192.168.0.105: ISSUE: authtime 1395307449, etypes >>>{rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for >>>krbtgt/EXAMPLE.COM at EXAMPLE.COM >>>mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 >>>etypes {18 17 16 23 1 3}) 192.168.0.105: ISSUE: authtime 1395307449, >>>etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for >>>HTTP/olmo.example.com at EXAMPLE.COM >>> >>>As you can see, the first one uses admin on ldap service, the second >>>one uses HTTP/ebano.example.com on HTTP service. >>This means your Java application doesn't use S4U extension or doesn't >>know about that. >> >>>Can I do the same call with Java? >>At this point we need to set clear what Java are you using. >> >>http://download.java.net/jdk8/docs/technotes/guides/security/jgss/jgss-features.html >> >>tells that S4U extensions (we use S4U2Proxy here) was added in Java SE 8. >> > >The client doesn't do the S4U2Proxy work though, so this shouldn't >matter, right? My point is that the client will not do what he expects unless S4U2Proxy is used in Java and that requires Java 8 platform, released on March 18th 2014. That is, if there is a user talking to the Java client and then Java client turning to IPA LDAP or web server with constraint delegation. This is something I tried to get clarification for in the original discussion. -- / Alexander Bokovoy From tbabej at redhat.com Thu Mar 20 12:49:30 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 20 Mar 2014 13:49:30 +0100 Subject: [Freeipa-devel] [PATCH 0159] ipatests: test_trust: Change expected home directories for Message-ID: <532AE3DA.1040904@redhat.com> Hi, Information from the AD about the home directories is not leveraged at all, but is generated from the username and domain. Fix the assumptions in the tests. Also changes 'Subdomain Test User' to 'Subdomaintest User' to be more consistent. https://fedorahosted.org/freeipa/ticket/4184 -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0159-ipatests-test_trust-Change-expected-home-directories.patch Type: text/x-patch Size: 2678 bytes Desc: not available URL: From simo at redhat.com Thu Mar 20 13:09:12 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 20 Mar 2014 09:09:12 -0400 Subject: [Freeipa-devel] Talking json/rpc with java client In-Reply-To: <20140320124715.GP16644@redhat.com> References: <20140318091035.GA9052@redhat.com> <53281662.3030105@tirasa.net> <20140318102643.GC16644@redhat.com> <53286E45.4000605@tirasa.net> <20140318162607.GH16644@redhat.com> <532AB5BE.2070409@tirasa.net> <20140320103119.GO16644@redhat.com> <532ADF1F.8000002@redhat.com> <20140320124715.GP16644@redhat.com> Message-ID: <1395320952.26633.37.camel@willson.li.ssimo.org> On Thu, 2014-03-20 at 14:47 +0200, Alexander Bokovoy wrote: > On Thu, 20 Mar 2014, Rob Crittenden wrote: > >Alexander Bokovoy wrote: > >>On Thu, 20 Mar 2014, Massimiliano Perrone (tirasa.net) wrote: > >>>On 03/18/2014 05:26 PM, Alexander Bokovoy wrote: > >>>>On Tue, 18 Mar 2014, Massimiliano Perrone (example.com) wrote: > >>>>>>>The difference between the two calls is on the last TGS_REQ; > >>>>>>>because the first one is on ldap/olmo.example.com at EXAMPLE.COM and > >>>>>>>it's OK whereas the second one is on > >>>>>>>HTTP/olmo.example.com at EXAMPLE.COM that returns a 401 (I suppose). > >>>>>>> > >>>>>>>Where's the error? > >>>>>>Am I correct that you have a user connecting to HTTP/ebano.example.com > >>>>>>and then HTTP/ebano.example.com wants to talk to HTTP/olmo.example.com > >>>>>>using credentials of the user? > >>>>>> > >>>>>>FreeIPA uses constraint delegation of the credentials, with the > >>>>>>help of > >>>>>>S4U2Proxy extension. You need to allow HTTP/ebano.example.com to > >>>>>>delegate > >>>>>>credentials to HTTP/olmo.example.com. > >>>>>> > >>>>>>I have written an article how to do that: > >>>>>>https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>Hi Alexander, thanks for your reply. > >>>>>I read carefully your interesting post and I follow it to delegate > >>>>>HTTP/ebano.example.com credentials to HTTP/olmo.example.com. > >>>>> > >>>>>Now, two questions: > >>>>>1) How can I check that my configuration, now is ok? Because this > >>>>>ldapsearch returns result: 0 > >>>>> > >>>>>ldapsearch -Y GSSAPI -H ldap://olmo.example.com -b > >>>>>"cn=s4u2proxy,cn=etc,dc=example,dc=com" > >>>>>"cn=ipa-http-delegation-targets" dn > >>>>You need to create these delegation entries yourself, like the article > >>>>says. Note that your app talks to IPA server's HTTP service, so create > >>>> > >>>>dn: cn=ebano-http-delegation,cn=s4u2proxy,cn=etc,dc=example,dc=com > >>>>objectClass: ipaKrb5DelegationACL > >>>>objectClass: groupOfPrincipals > >>>>objectClass: top > >>>>cn: ebano-http-delegation > >>>>memberPrincipal: HTTP/ebano.example.com at EXAMPLE.COM > >>>>ipaAllowedTarget: > >>>>cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com > >>>> > >>>>This entry says: "HTTP/ebano.example.com is allowed to delegate users' > >>>>credentials to whatever Kerberos principal is a member of > >>>>cn=ebano-http-delegation-targets group" > >>>> > >>>>Now, this is the group: > >>>>dn: > >>>>cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com > >>>>objectClass: groupOfPrincipals > >>>>objectClass: top > >>>>cn: ebano-http-delegation-targets > >>>>memberPrincipal: HTTP/olomo.example.com at EXAMPLE.COM > >>>> > >>>>With these two entries we would have HTTP/ebano.example.com allowed to > >>>>delegate users' credentials to HTTP/olomo.example.com > >>> > >>>Hi Alexander, thanks for your patience. > >>>I followed your suggestions but the result is always the same. > >>> > >>>Trying with curl, of course, it works. > >>> > >>>My doubt now is why curl generates this log on kerberos server > >>> > >>>mar 20 10:22:20 olmo.example.com krb5kdc[5091](info): TGS_REQ (1 > >>>etypes {18}) 192.168.0.105: ISSUE: authtime 1395301975, etypes {rep=18 > >>>tkt=18 ses=18}, admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM > >>>mar 20 10:22:21 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 > >>>etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime 1395301975, > >>>etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for > >>>ldap/olmo.example.com at EXAMPLE.COM > >>This is effect of S4U extension working correctly. > >> > >>>whereas java generates this other one > >>> > >>>mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 etypes > >>>{18 17 16 23}) 192.168.0.105: NEEDED_PREAUTH: > >>>HTTP/ebano.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, > >>>Additional pre-authentication required > >>>mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 etypes > >>>{18 17 16 23}) 192.168.0.105: ISSUE: authtime 1395307449, etypes > >>>{rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for > >>>krbtgt/EXAMPLE.COM at EXAMPLE.COM > >>>mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 > >>>etypes {18 17 16 23 1 3}) 192.168.0.105: ISSUE: authtime 1395307449, > >>>etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for > >>>HTTP/olmo.example.com at EXAMPLE.COM > >>> > >>>As you can see, the first one uses admin on ldap service, the second > >>>one uses HTTP/ebano.example.com on HTTP service. > >>This means your Java application doesn't use S4U extension or doesn't > >>know about that. > >> > >>>Can I do the same call with Java? > >>At this point we need to set clear what Java are you using. > >> > >>http://download.java.net/jdk8/docs/technotes/guides/security/jgss/jgss-features.html > >> > >>tells that S4U extensions (we use S4U2Proxy here) was added in Java SE 8. > >> > > > >The client doesn't do the S4U2Proxy work though, so this shouldn't > >matter, right? > My point is that the client will not do what he expects unless S4U2Proxy > is used in Java and that requires Java 8 platform, released on March > 18th 2014. I think you can use earlier Java versions but tell them to use the native GSSAPI library (and perhaps sprinkle a little bit of GSS-Proxy in the back for fun. > That is, if there is a user talking to the Java client and > then Java client turning to IPA LDAP or web server with constraint > delegation. > > This is something I tried to get clarification for in the original > discussion. > > -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Thu Mar 20 13:09:17 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Mar 2014 14:09:17 +0100 Subject: [Freeipa-devel] [DOC] 0006 Chapter 5 update In-Reply-To: <1395233034.2317.9.camel@unused-4-145.brq.redhat.com> References: <1380214338.2142.9.camel@unused-4-145.brq.redhat.com> <53284B65.9000601@redhat.com> <1395233034.2317.9.camel@unused-4-145.brq.redhat.com> Message-ID: <532AE87D.2020104@redhat.com> On 03/19/2014 01:43 PM, Martin Basti wrote: > On Tue, 2014-03-18 at 14:34 +0100, Petr Viktorin wrote: >> On 09/26/2013 06:52 PM, Martin Basti wrote: >>> Patch for chapter 5 >>> >>> Contains patch for ticket >>> https://fedorahosted.org/freeipa/ticket/3842 >> >> Hello, >> Thanks for the patches! >> >> Next time, when you do multiple changes, please split them into multiple >> patches. Each of the bullet points in the commit message could have been >> a separate patch. >> However splitting the patch now is probably not worth the effort. >> >> I did however split the whitespace fixes to make my job easier. I also >> rebased a minor conflict. Attaching the patches for convenience. >> >> In section 5.1.3 the examples are missing the [user at ipaserver ~] prompt. > Added. > >> In section 5.2.2.2 there's an extra `$` prompt that's not present in >> other syntax examples. > Removed extra '$'. >> >> Section 5.2.4.1. should not be an ordered list since it presents two >> ways to do the same thing. > Moved to unnumbered list. > >> In Table 5.3, instead of removing posixgroup altogether you should >> mention that it's only added for POSIX groups. > Added footnote. >> >> Otherwise the changes look good. >> > > Thank you for review. > Updated patch attached. > Thanks! ACK, pushed to master: 50f0658ec634adf91e4794f8bcbb79e318472835 -- Petr? From amisnyov at redhat.com Thu Mar 20 13:19:51 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Thu, 20 Mar 2014 14:19:51 +0100 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <53233BB7.9010104@redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> Message-ID: <20140320141951.152522d4@unused-4-246.brq.redhat.com> On Fri, 14 Mar 2014 13:26:15 -0400 Rob Crittenden wrote: > Misnyovszki Adam wrote: > > Hi, > > > > automember-rebuild uses asynchronous 389 task, and returned success > > even if the task didn't run. This patch fixes this issue adding a > > --nowait parameter to 'ipa automember-rebuild', defaulting to False, > > thus when the script runs without it, it waits for the > > 'nstaskexitcode' attribute, which means the task has finished, > > according to > > http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. > > Old usage can be enabled using --nowait. > > > > https://fedorahosted.org/freeipa/ticket/4239 > > > > Request for comments: > > - Should I add a parameter to specify the polling time? (now 1ms) > > - Should I add a parameter to specify the maximum polling number? > > Now if something fails about creating the task, it polls forever. > > - Obviously, if these parameters should be added, there should be a > > reasonable default for them (~ Required=False, Default=X). > > I don't think you need a polling time, esp since this is hidden from > the user, but I think that is probably too short and you may end up > hammering the LDAP server. > > I also wonder if there should be some maximum wait time. I don't like > loops that can never exit. I'm at a loss for what that time should be > though. And we'd need to spell out that we gave up waiting, not that > the task necessarily failed. So rather than having a polling time > option, rename nowait into wait_for=20, so wait for 20 seconds. Or > something like that. > > I'd suggest using get_entry since you already know the full DN and > there is only ever one. It would make this much more readable. > > I wonder if some top-level documentation should be added to flesh > this out some more. This does, for example, return False in one case. > The meaning for that should be spelled out. > > rob Hi, personally I would keep --no-wait, with a delay of 1 seconds, and a maximum waiting time for 60 seconds. Questions is, do we need to parameterize with other parameters(wait-for to the maximum time, and/or poll-delay for the delay time, both not required), or it is not a case which worth to develop? Greets Adam From pviktori at redhat.com Thu Mar 20 13:26:54 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 20 Mar 2014 14:26:54 +0100 Subject: [Freeipa-devel] [PATCH] 0503 test_integration.tasks: Do not fail cleanup if backup directory does not exist Message-ID: <532AEC9E.5030804@redhat.com> Hello, This should fix a bug in integration tests. See commit message. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0503-test_integration.tasks-Do-not-fail-in-cleanup.patch Type: text/x-patch Size: 1330 bytes Desc: not available URL: From massimiliano.perrone at tirasa.net Thu Mar 20 13:32:57 2014 From: massimiliano.perrone at tirasa.net (Massimiliano Perrone (tirasa.net)) Date: Thu, 20 Mar 2014 14:32:57 +0100 Subject: [Freeipa-devel] Talking json/rpc with java client In-Reply-To: <532ADF1F.8000002@redhat.com> References: <20140318091035.GA9052@redhat.com> <53281662.3030105@tirasa.net> <20140318102643.GC16644@redhat.com> <53286E45.4000605@tirasa.net> <20140318162607.GH16644@redhat.com> <532AB5BE.2070409@tirasa.net> <20140320103119.GO16644@redhat.com> <532ADF1F.8000002@redhat.com> Message-ID: <532AEE09.2010108@tirasa.net> On 03/20/2014 01:29 PM, Rob Crittenden wrote: > Alexander Bokovoy wrote: >> On Thu, 20 Mar 2014, Massimiliano Perrone (tirasa.net) wrote: >>> On 03/18/2014 05:26 PM, Alexander Bokovoy wrote: >>>> On Tue, 18 Mar 2014, Massimiliano Perrone (example.com) wrote: >>>>>>> The difference between the two calls is on the last TGS_REQ; >>>>>>> because the first one is on ldap/olmo.example.com at EXAMPLE.COM and >>>>>>> it's OK whereas the second one is on >>>>>>> HTTP/olmo.example.com at EXAMPLE.COM that returns a 401 (I suppose). >>>>>>> >>>>>>> Where's the error? >>>>>> Am I correct that you have a user connecting to >>>>>> HTTP/ebano.example.com >>>>>> and then HTTP/ebano.example.com wants to talk to >>>>>> HTTP/olmo.example.com >>>>>> using credentials of the user? >>>>>> >>>>>> FreeIPA uses constraint delegation of the credentials, with the >>>>>> help of >>>>>> S4U2Proxy extension. You need to allow HTTP/ebano.example.com to >>>>>> delegate >>>>>> credentials to HTTP/olmo.example.com. >>>>>> >>>>>> I have written an article how to do that: >>>>>> https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Hi Alexander, thanks for your reply. >>>>> I read carefully your interesting post and I follow it to delegate >>>>> HTTP/ebano.example.com credentials to HTTP/olmo.example.com. >>>>> >>>>> Now, two questions: >>>>> 1) How can I check that my configuration, now is ok? Because this >>>>> ldapsearch returns result: 0 >>>>> >>>>> ldapsearch -Y GSSAPI -H ldap://olmo.example.com -b >>>>> "cn=s4u2proxy,cn=etc,dc=example,dc=com" >>>>> "cn=ipa-http-delegation-targets" dn >>>> You need to create these delegation entries yourself, like the article >>>> says. Note that your app talks to IPA server's HTTP service, so create >>>> >>>> dn: cn=ebano-http-delegation,cn=s4u2proxy,cn=etc,dc=example,dc=com >>>> objectClass: ipaKrb5DelegationACL >>>> objectClass: groupOfPrincipals >>>> objectClass: top >>>> cn: ebano-http-delegation >>>> memberPrincipal: HTTP/ebano.example.com at EXAMPLE.COM >>>> ipaAllowedTarget: >>>> cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com >>>> >>>> This entry says: "HTTP/ebano.example.com is allowed to delegate users' >>>> credentials to whatever Kerberos principal is a member of >>>> cn=ebano-http-delegation-targets group" >>>> >>>> Now, this is the group: >>>> dn: >>>> cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com >>>> objectClass: groupOfPrincipals >>>> objectClass: top >>>> cn: ebano-http-delegation-targets >>>> memberPrincipal: HTTP/olomo.example.com at EXAMPLE.COM >>>> >>>> With these two entries we would have HTTP/ebano.example.com allowed to >>>> delegate users' credentials to HTTP/olomo.example.com >>> >>> Hi Alexander, thanks for your patience. >>> I followed your suggestions but the result is always the same. >>> >>> Trying with curl, of course, it works. >>> >>> My doubt now is why curl generates this log on kerberos server >>> >>> mar 20 10:22:20 olmo.example.com krb5kdc[5091](info): TGS_REQ (1 >>> etypes {18}) 192.168.0.105: ISSUE: authtime 1395301975, etypes {rep=18 >>> tkt=18 ses=18}, admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM >>> mar 20 10:22:21 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 >>> etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime 1395301975, >>> etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for >>> ldap/olmo.example.com at EXAMPLE.COM >> This is effect of S4U extension working correctly. >> >>> whereas java generates this other one >>> >>> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 etypes >>> {18 17 16 23}) 192.168.0.105: NEEDED_PREAUTH: >>> HTTP/ebano.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, >>> Additional pre-authentication required >>> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 etypes >>> {18 17 16 23}) 192.168.0.105: ISSUE: authtime 1395307449, etypes >>> {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for >>> krbtgt/EXAMPLE.COM at EXAMPLE.COM >>> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 >>> etypes {18 17 16 23 1 3}) 192.168.0.105: ISSUE: authtime 1395307449, >>> etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for >>> HTTP/olmo.example.com at EXAMPLE.COM >>> >>> As you can see, the first one uses admin on ldap service, the second >>> one uses HTTP/ebano.example.com on HTTP service. >> This means your Java application doesn't use S4U extension or doesn't >> know about that. >> >>> Can I do the same call with Java? >> At this point we need to set clear what Java are you using. >> >> http://download.java.net/jdk8/docs/technotes/guides/security/jgss/jgss-features.html >> >> >> tells that S4U extensions (we use S4U2Proxy here) was added in Java >> SE 8. >> > > The client doesn't do the S4U2Proxy work though, so this shouldn't > matter, right? > > I think what I'd suggest is to use the keytab you're using in java in > the curl test: > > $ kinit -kt /path/to/keytab HTTP/ebano.example.com > $ curl ... > Curl call is OK also with ebano keytab. Kerberos server log: mar 20 14:29:56 olmo.tirasa.net krb5kdc[5091](info): TGS_REQ (1 etypes {18}) 192.168.0.105: ISSUE: authtime 1395321990, etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.tirasa.net at TIRASA.NET for krbtgt/TIRASA.NET at TIRASA.NET mar 20 14:29:56 olmo.tirasa.net krb5kdc[5091](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime 1395321990, etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.tirasa.net at TIRASA.NET for ldap/olmo.tirasa.net at TIRASA.NET ------------------> HTTP/ebano.tirasa.net at TIRASA.NET for ldap/olmo.tirasa.net at TIRASA.NET > Then you'll be comparing apples to apples. > > rob -- Massimiliano Perrone Tel +39 393 9121310 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~massi/ "L'apprendere molte cose non insegna l'intelligenza" (Eraclito) From mkosek at redhat.com Thu Mar 20 14:39:07 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 20 Mar 2014 15:39:07 +0100 Subject: [Freeipa-devel] [PATCH] 0503 test_integration.tasks: Do not fail cleanup if backup directory does not exist In-Reply-To: <532AEC9E.5030804@redhat.com> References: <532AEC9E.5030804@redhat.com> Message-ID: <532AFD8B.2050004@redhat.com> On 03/20/2014 02:26 PM, Petr Viktorin wrote: > Hello, > This should fix a bug in integration tests. See commit message. Looks good to me. Should fix I was seeing in Jenkins. ACK. Pushed to master, ipa-3-3. Martin From amisnyov at redhat.com Thu Mar 20 15:22:00 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Thu, 20 Mar 2014 16:22:00 +0100 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <20140320141951.152522d4@unused-4-246.brq.redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> Message-ID: <20140320162200.1de0e391@unused-4-246.brq.redhat.com> On Thu, 20 Mar 2014 14:19:51 +0100 Misnyovszki Adam wrote: > On Fri, 14 Mar 2014 13:26:15 -0400 > Rob Crittenden wrote: > > > Misnyovszki Adam wrote: > > > Hi, > > > > > > automember-rebuild uses asynchronous 389 task, and returned > > > success even if the task didn't run. This patch fixes this issue > > > adding a --nowait parameter to 'ipa automember-rebuild', > > > defaulting to False, thus when the script runs without it, it > > > waits for the 'nstaskexitcode' attribute, which means the task > > > has finished, according to > > > http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. > > > Old usage can be enabled using --nowait. > > > > > > https://fedorahosted.org/freeipa/ticket/4239 > > > > > > Request for comments: > > > - Should I add a parameter to specify the polling time? (now 1ms) > > > - Should I add a parameter to specify the maximum polling number? > > > Now if something fails about creating the task, it polls forever. > > > - Obviously, if these parameters should be added, there should be > > > a reasonable default for them (~ Required=False, Default=X). > > > > I don't think you need a polling time, esp since this is hidden from > > the user, but I think that is probably too short and you may end up > > hammering the LDAP server. > > > > I also wonder if there should be some maximum wait time. I don't > > like loops that can never exit. I'm at a loss for what that time > > should be though. And we'd need to spell out that we gave up > > waiting, not that the task necessarily failed. So rather than > > having a polling time option, rename nowait into wait_for=20, so > > wait for 20 seconds. Or something like that. > > > > I'd suggest using get_entry since you already know the full DN and > > there is only ever one. It would make this much more readable. > > > > I wonder if some top-level documentation should be added to flesh > > this out some more. This does, for example, return False in one > > case. The meaning for that should be spelled out. > > > > rob > > Hi, > personally I would keep --no-wait, with a delay of 1 seconds, and a > maximum waiting time for 60 seconds. Questions is, do we need to > parameterize with other parameters(wait-for to the maximum time, > and/or poll-delay for the delay time, both not required), or it is > not a case which worth to develop? > Greets > Adam Hi, here are the corrections Petr asked, also the other patch conatins the plugin registration refactor. Thanks Adam > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0007-2-automember-rebuild-nowait-feature-added.patch Type: text/x-patch Size: 4520 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0008-plugin-registration-refactoring-for-automembership.patch Type: text/x-patch Size: 4994 bytes Desc: not available URL: From amisnyov at redhat.com Thu Mar 20 15:51:33 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Thu, 20 Mar 2014 16:51:33 +0100 Subject: [Freeipa-devel] [PATCH] 560 webui: rename domNode to dom_node In-Reply-To: <5329B174.9060407@redhat.com> References: <5329B174.9060407@redhat.com> Message-ID: <20140320165133.4ef44cdd@unused-4-246.brq.redhat.com> On Wed, 19 Mar 2014 16:02:12 +0100 Petr Vobornik wrote: > - unites domNode and dom_node usage to dom_node Nack, install/ui/test/details_tests.js:236 install/ui/test/details_tests.js:242 only finds element, because context(ie domNode) is undefined, so it falls back to html, not the best idea install/ui/src/freeipa/widgets/App.js:55 not sure if this causes errors, but it's worth renaming for consistency Greets, Adam From pspacek at redhat.com Thu Mar 20 17:09:06 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 20 Mar 2014 18:09:06 +0100 Subject: [Freeipa-devel] [PATCHES] 172-196 Refactor certificate renewal code In-Reply-To: <53299C98.2090308@redhat.com> References: <525FD641.20202@redhat.com> <526009D7.2040702@redhat.com> <5260175E.50809@redhat.com> <531DAA0F.9080300@redhat.com> <5320AE9B.6040303@redhat.com> <5321A77B.3090003@redhat.com> <53299C98.2090308@redhat.com> Message-ID: <532B20B2.6070600@redhat.com> On 19.3.2014 14:33, Jan Cholasta wrote: > freeipa-jcholast-190.2-Store-information-about-which-CA-server-is-master-in.patch > > >>From 147ab524032902f29b8c3048cdaf21c5606f2274 Mon Sep 17 00:00:00 2001 > From: Jan Cholasta > Date: Wed, 16 Oct 2013 08:51:06 +0000 > Subject: [PATCH 17/23] Store information about which CA server is master in > LDAP. > > --- > install/tools/ipa-server-install | 2 +- > ipaserver/install/cainstance.py | 17 ++++++++++- > ipaserver/install/plugins/ca_master.py | 56 ++++++++++++++++++++++++++++++++++ > ipaserver/install/service.py | 4 +-- > 4 files changed, 75 insertions(+), 4 deletions(-) > create mode 100644 ipaserver/install/plugins/ca_master.py > > diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install > index dfe192a..a77ad71 100755 > --- a/install/tools/ipa-server-install > +++ b/install/tools/ipa-server-install > @@ -1114,7 +1114,7 @@ def main(): > if setup_ca: > # We need to ldap_enable the CA now that DS is up and running > ca.ldap_enable('CA', host_name, dm_password, > - ipautil.realm_to_suffix(realm_name)) > + ipautil.realm_to_suffix(realm_name), ['master']) > > # This is done within stopped_service context, which restarts CA > ca.enable_client_auth_to_db() > diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py > index 227cea0..c7a459d 100644 > --- a/ipaserver/install/cainstance.py > +++ b/ipaserver/install/cainstance.py > @@ -1603,8 +1603,23 @@ class CAInstance(service.Service): > gone or no longer performing certain duties then it is their > responsibility to handle changes on upgrades. > """ > + if not self.admin_conn: > + self.ldap_connect() > + > + base_dn = DN(('cn', 'masters'), ('cn', 'ipa'), ('cn', 'etc'), > + api.env.basedn) > + filter = '(&(cn=CA)(ipaConfigString=master))' > + try: > + entries = self.admin_conn.get_entries( > + base_dn=base_dn, filter=filter, attrs_list=[]) > + except errors.NotFound: > + pass > + else: > + fqdn = entries[0].dn[1].value > + return api.env.host.lower() == fqdn.lower() Please use python-dns to compare DNS names. This is fragile as you know :-) Thanks! -- Petr^2 Spacek From jhrozek at redhat.com Thu Mar 20 17:26:25 2014 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 20 Mar 2014 18:26:25 +0100 Subject: [Freeipa-devel] [PATCH 0159] ipatests: test_trust: Change expected home directories for In-Reply-To: <532AE3DA.1040904@redhat.com> References: <532AE3DA.1040904@redhat.com> Message-ID: <20140320172625.GG25606@hendrix.brq.redhat.com> On Thu, Mar 20, 2014 at 01:49:30PM +0100, Tomas Babej wrote: > Hi, > > Information from the AD about the home directories is not leveraged at > all, but is generated from the username and domain. Fix the assumptions > in the tests. Right, until we enhance the extop plugin to send the full set of POSIX information. > > Also changes 'Subdomain Test User' to 'Subdomaintest User' to be more > consistent. > > https://fedorahosted.org/freeipa/ticket/4184 I haven't tried the patch, but the intent is good and the code looks good to me. Visual ACK. From amisnyov at redhat.com Thu Mar 20 18:20:40 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Thu, 20 Mar 2014 19:20:40 +0100 Subject: [Freeipa-devel] [PATCHES] 0499-0502 permission CLI: rename --permissions to --right In-Reply-To: <532827AE.5040403@redhat.com> References: <532827AE.5040403@redhat.com> Message-ID: <20140320192040.02da0270@unused-4-246.brq.redhat.com> On Tue, 18 Mar 2014 12:02:06 +0100 Petr Viktorin wrote: > Hello, > This renames --permissions to --right. The old name is kept as a > deprecated alias. > FreeIPA didn't have a mechanism for doing this, so I added one. > Also, while I was digging around in this part, I made the new IntEnum > (and all future Enums) act like StrEnum in --help output. > > > https://fedorahosted.org/freeipa/ticket/4231 > 499 ACK 500 ACK 501 ACK - although should it allow mixing deprecated and current aliases(eg --permission=read --right=write)? - works fine with cli / webui also - help displays nicely 502 - tested with more than one deprecated alias - API.txt validation doesn't match, although it has the same output: Got StrEnum('ipapermright', attribute=True, cli_name='right', deprecated_cli_aliases=set(['testalias', 'permissions']), multivalue=True, required=False, values=(u'read', u'search', u'compare', u'write', u'add', u'delete', u'all')) Expected StrEnum('ipapermright', attribute=True, cli_name='right', deprecated_cli_aliases=set(['testalias','permissions']), multivalue=True, required=False, values=(u'read', u'search', u'compare', u'write', u'add', u'delete', u'all')) API.txt: option: StrEnum('ipapermright', attribute=True, cli_name='right', deprecated_cli_aliases=set(['testalias','permissions']), multivalue=True, required=False, values=(u'read', u'search', u'compare', u'write', u'add', u'delete', u'all')) ipalib/plugins/permission.py: StrEnum( 'ipapermright*', cli_name='right', deprecated_cli_aliases={'permissions','testalias'}, label=_('Granted rights'), doc=_('Rights to grant ' '(read, search, compare, write, add, delete, all)'), values=(u'read', u'search', u'compare', u'write', u'add', u'delete', u'all'), ), don't know if it is a problem anyways - other tests(cli, webui) works fine for me - unit tests related to this ran as expected so besides the multiple deprecated_cli_aliases issue, it's an ACK Greets Adam From pviktori at redhat.com Fri Mar 21 08:46:05 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Mar 2014 09:46:05 +0100 Subject: [Freeipa-devel] [PATCHES] 172-196 Refactor certificate renewal code In-Reply-To: <53299C98.2090308@redhat.com> References: <525FD641.20202@redhat.com> <526009D7.2040702@redhat.com> <5260175E.50809@redhat.com> <531DAA0F.9080300@redhat.com> <5320AE9B.6040303@redhat.com> <5321A77B.3090003@redhat.com> <53299C98.2090308@redhat.com> Message-ID: <532BFC4D.4090101@redhat.com> On 03/19/2014 02:33 PM, Jan Cholasta wrote: > On 13.3.2014 13:41, Jan Cholasta wrote: >> On 12.3.2014 19:59, Petr Viktorin wrote: >>> Certmonger is not configured/started in CA-less installs. >> >> That's expected. >> >>> >>> I tested fresh installs and upgrades; renewals work fine for me. >>> >>> 161-184 look OK >>> >>> 185: one more nitpick: >>> cert = entry['usercertificate'][0] >>> Shouldn't that use entry.single_value? >> >> I did not feel like changing this, because this is used in the original >> code and the userCertificate LDAP attribute is multi-value. Could you add a comment saying we don't care which of the certificates is returned? For me `entry[...][0]` is a red flag, since the order usually stays the same but it's not guaranteed, so it can change in the worst moment. If nothing else we shouldn't be leaving it in the code as an example of ipaldap usage. >> >>> >>> 186-189 look OK >>> >>> 190: Is >>> fqdn = entries[0].dn[1].value >>> return api.env.host == fqdn >>> safe? Can they differ in case, for example? >> >> I guess so, will fix. >> >>> >>> 191-196 look OK >>> >>>> Note that patches 178 & 179 were already pushed. Also, patch 190 was >>>> changed to store information about which CA instance is master in LDAP. > > Updated patches attached. > > Note that I changed the path for CSR export to /var/lib/ipa/ca.csr to > make it more SELinux-friendly (not in the policy yet, see > ). > -- Petr? From amisnyov at redhat.com Fri Mar 21 09:13:55 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Fri, 21 Mar 2014 10:13:55 +0100 Subject: [Freeipa-devel] [PATCH]Extending user plugin with employeenumber field In-Reply-To: <53076B73.9020008@redhat.com> References: <1796318445.1683710.1392993953023.JavaMail.zimbra@redhat.com> <53076B73.9020008@redhat.com> Message-ID: <20140321101355.06e5efaa@unused-4-246.brq.redhat.com> On Fri, 21 Feb 2014 16:06:27 +0100 Petr Vobornik wrote: > On 21.2.2014 15:45, Adam Misnyovszki wrote: > > Hi, > > According to http://tools.ietf.org/html/rfc2798 ipa client and web > > ui extended with employeenumber field. > > > > https://fedorahosted.org/freeipa/ticket/4165 > > > > Question is, that should we extend user with other fields which are > > in the RFC, (carLicense, departmentNumber, employeeType, etc) if we > > already touched this code? > > > > Thanks > > Adam > > > > > + Int('employeenumber?', > + label=_('Employee ID'), > + minvalue=1, > + ), > > > Why Int and different label? IMO it should be Str and 'Employee > Number' > > 2.4. Employee Number > > Numeric or alphanumeric identifier assigned to a person, typically > based on order of hire or association with an organization. > Single valued. > > ( 2.16.840.1.113730.3.1.3 > NAME 'employeeNumber' > DESC 'numerically identifies an employee within an > organization' EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 > SINGLE-VALUE ) > Hi, fixed, also some other fields added. Note, that according to the rfc, licence plate field should be multivalue, should I cange that(it is an existing field). Also, should I write test cases(especially for preferredlanguage)? Greets Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0005-2-Extending-user-plugin-with-inetOrgPerson-fields.patch Type: text/x-patch Size: 9993 bytes Desc: not available URL: From amisnyov at redhat.com Fri Mar 21 09:29:18 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Fri, 21 Mar 2014 10:29:18 +0100 Subject: [Freeipa-devel] [PATCH] typo in migrate-ds In-Reply-To: References: Message-ID: <20140321102918.571ea265@unused-4-246.brq.redhat.com> On Tue, 18 Mar 2014 19:31:31 -0600 Gabe Alford wrote: > All, > > It looks like the only typos exist in the uk and fr .po files for this > ticket > https://fedorahosted.org/freeipa/ticket/2546 > > Point me in the right direction if I am wrong. > > Thanks, > > Gabe ACK, thanks for the patch! Greets Adam From pviktori at redhat.com Fri Mar 21 09:29:24 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Mar 2014 10:29:24 +0100 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <20140320162200.1de0e391@unused-4-246.brq.redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> Message-ID: <532C0674.3030206@redhat.com> On 03/20/2014 04:22 PM, Misnyovszki Adam wrote: > On Thu, 20 Mar 2014 14:19:51 +0100 > Misnyovszki Adam wrote: > >> On Fri, 14 Mar 2014 13:26:15 -0400 >> Rob Crittenden wrote: >> >>> Misnyovszki Adam wrote: >>>> Hi, >>>> >>>> automember-rebuild uses asynchronous 389 task, and returned >>>> success even if the task didn't run. This patch fixes this issue >>>> adding a --nowait parameter to 'ipa automember-rebuild', >>>> defaulting to False, thus when the script runs without it, it >>>> waits for the 'nstaskexitcode' attribute, which means the task >>>> has finished, according to >>>> http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. >>>> Old usage can be enabled using --nowait. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4239 >>>> >>>> Request for comments: >>>> - Should I add a parameter to specify the polling time? (now 1ms) >>>> - Should I add a parameter to specify the maximum polling number? >>>> Now if something fails about creating the task, it polls forever. >>>> - Obviously, if these parameters should be added, there should be >>>> a reasonable default for them (~ Required=False, Default=X). >>> >>> I don't think you need a polling time, esp since this is hidden from >>> the user, but I think that is probably too short and you may end up >>> hammering the LDAP server. >>> >>> I also wonder if there should be some maximum wait time. I don't >>> like loops that can never exit. I'm at a loss for what that time >>> should be though. And we'd need to spell out that we gave up >>> waiting, not that the task necessarily failed. So rather than >>> having a polling time option, rename nowait into wait_for=20, so >>> wait for 20 seconds. Or something like that. >>> >>> I'd suggest using get_entry since you already know the full DN and >>> there is only ever one. It would make this much more readable. >>> >>> I wonder if some top-level documentation should be added to flesh >>> this out some more. This does, for example, return False in one >>> case. The meaning for that should be spelled out. >>> >>> rob >> >> Hi, >> personally I would keep --no-wait, with a delay of 1 seconds, and a >> maximum waiting time for 60 seconds. Questions is, do we need to >> parameterize with other parameters(wait-for to the maximum time, >> and/or poll-delay for the delay time, both not required), or it is >> not a case which worth to develop? >> Greets >> Adam > > Hi, > here are the corrections Petr asked, also the other patch conatins the > plugin registration refactor. Thanks! You forgot an alternate summary for the --no-wait case. (Make sure to output the DN in this case, so it's possible to poll for it.) Instead of `task['nstaskexitcode'][0]` please use `task.single_value['nstaskexitcode']`. Here: raise errors.DatabaseError( desc=_("Automember rebuild membership task failed"), info=_("nstaskexitcode = '%s'" % str(task['nstaskexitcode'][0]))) there's no need to call str() on %'s argument. Also, use natural language (like "Task exit code: %s"), otherwise there's no need to mark the message for translation. -- Petr? From pviktori at redhat.com Fri Mar 21 09:33:00 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Mar 2014 10:33:00 +0100 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <532C0674.3030206@redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> Message-ID: <532C074C.1020903@redhat.com> On 03/21/2014 10:29 AM, Petr Viktorin wrote: > On 03/20/2014 04:22 PM, Misnyovszki Adam wrote: >> On Thu, 20 Mar 2014 14:19:51 +0100 >> Misnyovszki Adam wrote: >> >>> On Fri, 14 Mar 2014 13:26:15 -0400 >>> Rob Crittenden wrote: >>> >>>> Misnyovszki Adam wrote: >>>>> Hi, >>>>> >>>>> automember-rebuild uses asynchronous 389 task, and returned >>>>> success even if the task didn't run. This patch fixes this issue >>>>> adding a --nowait parameter to 'ipa automember-rebuild', >>>>> defaulting to False, thus when the script runs without it, it >>>>> waits for the 'nstaskexitcode' attribute, which means the task >>>>> has finished, according to >>>>> http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. >>>>> >>>>> Old usage can be enabled using --nowait. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/4239 >>>>> >>>>> Request for comments: >>>>> - Should I add a parameter to specify the polling time? (now 1ms) >>>>> - Should I add a parameter to specify the maximum polling number? >>>>> Now if something fails about creating the task, it polls forever. >>>>> - Obviously, if these parameters should be added, there should be >>>>> a reasonable default for them (~ Required=False, Default=X). >>>> >>>> I don't think you need a polling time, esp since this is hidden from >>>> the user, but I think that is probably too short and you may end up >>>> hammering the LDAP server. >>>> >>>> I also wonder if there should be some maximum wait time. I don't >>>> like loops that can never exit. I'm at a loss for what that time >>>> should be though. And we'd need to spell out that we gave up >>>> waiting, not that the task necessarily failed. So rather than >>>> having a polling time option, rename nowait into wait_for=20, so >>>> wait for 20 seconds. Or something like that. >>>> >>>> I'd suggest using get_entry since you already know the full DN and >>>> there is only ever one. It would make this much more readable. >>>> >>>> I wonder if some top-level documentation should be added to flesh >>>> this out some more. This does, for example, return False in one >>>> case. The meaning for that should be spelled out. >>>> >>>> rob >>> >>> Hi, >>> personally I would keep --no-wait, with a delay of 1 seconds, and a >>> maximum waiting time for 60 seconds. Questions is, do we need to >>> parameterize with other parameters(wait-for to the maximum time, >>> and/or poll-delay for the delay time, both not required), or it is >>> not a case which worth to develop? >>> Greets >>> Adam >> >> Hi, >> here are the corrections Petr asked, also the other patch conatins the >> plugin registration refactor. > > > Thanks! > > You forgot an alternate summary for the --no-wait case. (Make sure to > output the DN in this case, so it's possible to poll for it.) > > > > Instead of `task['nstaskexitcode'][0]` please use > `task.single_value['nstaskexitcode']`. > > Here: > > raise errors.DatabaseError( > desc=_("Automember rebuild membership task failed"), > info=_("nstaskexitcode = '%s'" % str(task['nstaskexitcode'][0]))) > > there's no need to call str() on %'s argument. > Also, use natural language (like "Task exit code: %s"), otherwise > there's no need to mark the message for translation. > > And one more thing: Please bump the minor version in the VERSION file when API.txt changes. -- Petr? From amisnyov at redhat.com Fri Mar 21 10:00:51 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Fri, 21 Mar 2014 11:00:51 +0100 Subject: [Freeipa-devel] [PATCH]Extending user plugin with employeenumber field In-Reply-To: <20140321101355.06e5efaa@unused-4-246.brq.redhat.com> References: <1796318445.1683710.1392993953023.JavaMail.zimbra@redhat.com> <53076B73.9020008@redhat.com> <20140321101355.06e5efaa@unused-4-246.brq.redhat.com> Message-ID: <20140321110051.1a50f943@unused-4-246.brq.redhat.com> On Fri, 21 Mar 2014 10:13:55 +0100 Misnyovszki Adam wrote: > On Fri, 21 Feb 2014 16:06:27 +0100 > Petr Vobornik wrote: > > > On 21.2.2014 15:45, Adam Misnyovszki wrote: > > > Hi, > > > According to http://tools.ietf.org/html/rfc2798 ipa client and web > > > ui extended with employeenumber field. > > > > > > https://fedorahosted.org/freeipa/ticket/4165 > > > > > > Question is, that should we extend user with other fields which > > > are in the RFC, (carLicense, departmentNumber, employeeType, etc) > > > if we already touched this code? > > > > > > Thanks > > > Adam > > > > > > > > > + Int('employeenumber?', > > + label=_('Employee ID'), > > + minvalue=1, > > + ), > > > > > > Why Int and different label? IMO it should be Str and 'Employee > > Number' > > > > 2.4. Employee Number > > > > Numeric or alphanumeric identifier assigned to a person, > > typically based on order of hire or association with an > > organization. Single valued. > > > > ( 2.16.840.1.113730.3.1.3 > > NAME 'employeeNumber' > > DESC 'numerically identifies an employee within an > > organization' EQUALITY caseIgnoreMatch > > SUBSTR caseIgnoreSubstringsMatch > > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 > > SINGLE-VALUE ) > > > Hi, > fixed, also some other fields added. Note, that according to the rfc, > licence plate field should be multivalue, should I cange that(it is an > existing field). Also, should I write test cases(especially for > preferredlanguage)? > Greets > Adam self NACK, VERSION bump because API change Greets Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0005-3-Extending-user-plugin-with-inetOrgPerson-fields.patch Type: text/x-patch Size: 10535 bytes Desc: not available URL: From pviktori at redhat.com Fri Mar 21 10:14:43 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Mar 2014 11:14:43 +0100 Subject: [Freeipa-devel] [PATCHES] 0499-0502 permission CLI: rename --permissions to --right In-Reply-To: <20140320192040.02da0270@unused-4-246.brq.redhat.com> References: <532827AE.5040403@redhat.com> <20140320192040.02da0270@unused-4-246.brq.redhat.com> Message-ID: <532C1113.6050009@redhat.com> On 03/20/2014 07:20 PM, Misnyovszki Adam wrote: > On Tue, 18 Mar 2014 12:02:06 +0100 > Petr Viktorin wrote: > >> Hello, >> This renames --permissions to --right. The old name is kept as a >> deprecated alias. >> FreeIPA didn't have a mechanism for doing this, so I added one. >> Also, while I was digging around in this part, I made the new IntEnum >> (and all future Enums) act like StrEnum in --help output. >> >> >> https://fedorahosted.org/freeipa/ticket/4231 >> > > 499 ACK > 500 ACK > 501 ACK > - although should it allow mixing deprecated and current aliases(eg > --permission=read --right=write)? You're right, this is a strange edge case, but detecting this would need need a much more complicated approach than sharing the option's `dest`. I don't think it's worth it. > - works fine with cli / webui also > - help displays nicely > 502 > - tested with more than one deprecated alias - API.txt validation > doesn't match, although it has the same output: > Got StrEnum('ipapermright', attribute=True, cli_name='right', > deprecated_cli_aliases=set(['testalias', 'permissions']), > multivalue=True, required=False, values=(u'read', u'search', > u'compare', u'write', u'add', u'delete', u'all')) > Expected StrEnum('ipapermright', attribute=True, cli_name='right', > deprecated_cli_aliases=set(['testalias','permissions']), > multivalue=True, required=False, values=(u'read', u'search', > u'compare', u'write', u'add', u'delete', u'all')) > > API.txt: > option: StrEnum('ipapermright', attribute=True, > cli_name='right', > deprecated_cli_aliases=set(['testalias','permissions']), > multivalue=True, required=False, values=(u'read', u'search', > u'compare', u'write', u'add', u'delete', u'all')) > ipalib/plugins/permission.py: > StrEnum( > 'ipapermright*', > cli_name='right', > deprecated_cli_aliases={'permissions','testalias'}, > label=_('Granted > rights'), > doc=_('Rights to grant > ' > '(read, search, compare, write, add, delete, > all)'), > values=(u'read', u'search', > u'compare', > u'write', u'add', u'delete', > u'all'), > ), > don't know if it is a problem anyways > - other tests(cli, webui) works fine for me > - unit tests related to this ran as expected > so besides the multiple deprecated_cli_aliases issue, it's an ACK It looks like you've edited API.txt by hand and forgot a space after the comma in ['testalias','permissions']. Does it work if you use makeapi to regenerate API.txt? -- Petr? From amisnyov at redhat.com Fri Mar 21 11:00:32 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Fri, 21 Mar 2014 12:00:32 +0100 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <532C074C.1020903@redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> Message-ID: <20140321120032.23243622@unused-4-246.brq.redhat.com> On Fri, 21 Mar 2014 10:33:00 +0100 Petr Viktorin wrote: > On 03/21/2014 10:29 AM, Petr Viktorin wrote: > > On 03/20/2014 04:22 PM, Misnyovszki Adam wrote: > >> On Thu, 20 Mar 2014 14:19:51 +0100 > >> Misnyovszki Adam wrote: > >> > >>> On Fri, 14 Mar 2014 13:26:15 -0400 > >>> Rob Crittenden wrote: > >>> > >>>> Misnyovszki Adam wrote: > >>>>> Hi, > >>>>> > >>>>> automember-rebuild uses asynchronous 389 task, and returned > >>>>> success even if the task didn't run. This patch fixes this issue > >>>>> adding a --nowait parameter to 'ipa automember-rebuild', > >>>>> defaulting to False, thus when the script runs without it, it > >>>>> waits for the 'nstaskexitcode' attribute, which means the task > >>>>> has finished, according to > >>>>> http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. > >>>>> > >>>>> Old usage can be enabled using --nowait. > >>>>> > >>>>> https://fedorahosted.org/freeipa/ticket/4239 > >>>>> > >>>>> Request for comments: > >>>>> - Should I add a parameter to specify the polling time? (now > >>>>> 1ms) > >>>>> - Should I add a parameter to specify the maximum polling > >>>>> number? Now if something fails about creating the task, it > >>>>> polls forever. > >>>>> - Obviously, if these parameters should be added, there should > >>>>> be a reasonable default for them (~ Required=False, Default=X). > >>>> > >>>> I don't think you need a polling time, esp since this is hidden > >>>> from the user, but I think that is probably too short and you > >>>> may end up hammering the LDAP server. > >>>> > >>>> I also wonder if there should be some maximum wait time. I don't > >>>> like loops that can never exit. I'm at a loss for what that time > >>>> should be though. And we'd need to spell out that we gave up > >>>> waiting, not that the task necessarily failed. So rather than > >>>> having a polling time option, rename nowait into wait_for=20, so > >>>> wait for 20 seconds. Or something like that. > >>>> > >>>> I'd suggest using get_entry since you already know the full DN > >>>> and there is only ever one. It would make this much more > >>>> readable. > >>>> > >>>> I wonder if some top-level documentation should be added to flesh > >>>> this out some more. This does, for example, return False in one > >>>> case. The meaning for that should be spelled out. > >>>> > >>>> rob > >>> > >>> Hi, > >>> personally I would keep --no-wait, with a delay of 1 seconds, and > >>> a maximum waiting time for 60 seconds. Questions is, do we need to > >>> parameterize with other parameters(wait-for to the maximum time, > >>> and/or poll-delay for the delay time, both not required), or it is > >>> not a case which worth to develop? > >>> Greets > >>> Adam > >> > >> Hi, > >> here are the corrections Petr asked, also the other patch conatins > >> the plugin registration refactor. > > > > > > Thanks! > > > > You forgot an alternate summary for the --no-wait case. (Make sure > > to output the DN in this case, so it's possible to poll for it.) > > > > > > > > Instead of `task['nstaskexitcode'][0]` please use > > `task.single_value['nstaskexitcode']`. > > > > Here: > > > > raise errors.DatabaseError( > > desc=_("Automember rebuild membership task failed"), > > info=_("nstaskexitcode = '%s'" % > > str(task['nstaskexitcode'][0]))) > > > > there's no need to call str() on %'s argument. > > Also, use natural language (like "Task exit code: %s"), otherwise > > there's no need to mark the message for translation. > > > > > > And one more thing: Please bump the minor version in the VERSION file > when API.txt changes. > > Hi, everything is corrected! Greets Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0007-3-automember-rebuild-nowait-feature-added.patch Type: text/x-patch Size: 5118 bytes Desc: not available URL: From amisnyov at redhat.com Fri Mar 21 11:10:48 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Fri, 21 Mar 2014 12:10:48 +0100 Subject: [Freeipa-devel] [PATCHES] 0499-0502 permission CLI: rename --permissions to --right In-Reply-To: <532C1113.6050009@redhat.com> References: <532827AE.5040403@redhat.com> <20140320192040.02da0270@unused-4-246.brq.redhat.com> <532C1113.6050009@redhat.com> Message-ID: <20140321121048.62b6878a@unused-4-246.brq.redhat.com> On Fri, 21 Mar 2014 11:14:43 +0100 Petr Viktorin wrote: > On 03/20/2014 07:20 PM, Misnyovszki Adam wrote: > > On Tue, 18 Mar 2014 12:02:06 +0100 > > Petr Viktorin wrote: > > > >> Hello, > >> This renames --permissions to --right. The old name is kept as a > >> deprecated alias. > >> FreeIPA didn't have a mechanism for doing this, so I added one. > >> Also, while I was digging around in this part, I made the new > >> IntEnum (and all future Enums) act like StrEnum in --help output. > >> > >> > >> https://fedorahosted.org/freeipa/ticket/4231 > >> > > > > 499 ACK > > 500 ACK > > 501 ACK > > - although should it allow mixing deprecated and current > > aliases(eg --permission=read --right=write)? > > You're right, this is a strange edge case, but detecting this would > need need a much more complicated approach than sharing the option's > `dest`. I don't think it's worth it. > > > - works fine with cli / webui also > > - help displays nicely > > 502 > > - tested with more than one deprecated alias - API.txt validation > > doesn't match, although it has the same output: > > Got StrEnum('ipapermright', attribute=True, cli_name='right', > > deprecated_cli_aliases=set(['testalias', 'permissions']), > > multivalue=True, required=False, values=(u'read', u'search', > > u'compare', u'write', u'add', u'delete', u'all')) > > Expected StrEnum('ipapermright', attribute=True, cli_name='right', > > deprecated_cli_aliases=set(['testalias','permissions']), > > multivalue=True, required=False, values=(u'read', u'search', > > u'compare', u'write', u'add', u'delete', u'all')) > > > > API.txt: > > option: StrEnum('ipapermright', attribute=True, > > cli_name='right', > > deprecated_cli_aliases=set(['testalias','permissions']), > > multivalue=True, required=False, values=(u'read', u'search', > > u'compare', u'write', u'add', u'delete', u'all')) > > ipalib/plugins/permission.py: > > StrEnum( > > 'ipapermright*', > > cli_name='right', > > deprecated_cli_aliases={'permissions','testalias'}, > > label=_('Granted > > rights'), > > doc=_('Rights to grant > > ' > > '(read, search, compare, write, add, delete, > > all)'), > > values=(u'read', u'search', > > u'compare', > > u'write', u'add', u'delete', > > u'all'), > > ), > > don't know if it is a problem anyways > > - other tests(cli, webui) works fine for me > > - unit tests related to this ran as expected > > so besides the multiple deprecated_cli_aliases issue, it's an ACK > > It looks like you've edited API.txt by hand and forgot a space after > the comma in ['testalias','permissions']. Does it work if you use > makeapi to regenerate API.txt? > You are right, my mistake, with ./makeapi, it works, even when the CLI got this for parameters: --right=read --permission=search --testparam=write ACK Greets Adam From pviktori at redhat.com Fri Mar 21 11:38:22 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Mar 2014 12:38:22 +0100 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <20140321120032.23243622@unused-4-246.brq.redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> <20140321120032.23243622@unused-4-246.brq.redhat.com> Message-ID: <532C24AE.8090406@redhat.com> On 03/21/2014 12:00 PM, Misnyovszki Adam wrote: > On Fri, 21 Mar 2014 10:33:00 +0100 > Petr Viktorin wrote: > >> On 03/21/2014 10:29 AM, Petr Viktorin wrote: >>> On 03/20/2014 04:22 PM, Misnyovszki Adam wrote: >>>> On Thu, 20 Mar 2014 14:19:51 +0100 >>>> Misnyovszki Adam wrote: >>>> >>>>> On Fri, 14 Mar 2014 13:26:15 -0400 >>>>> Rob Crittenden wrote: >>>>> >>>>>> Misnyovszki Adam wrote: >>>>>>> Hi, >>>>>>> >>>>>>> automember-rebuild uses asynchronous 389 task, and returned >>>>>>> success even if the task didn't run. This patch fixes this issue >>>>>>> adding a --nowait parameter to 'ipa automember-rebuild', >>>>>>> defaulting to False, thus when the script runs without it, it >>>>>>> waits for the 'nstaskexitcode' attribute, which means the task >>>>>>> has finished, according to >>>>>>> http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. >>>>>>> >>>>>>> Old usage can be enabled using --nowait. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/4239 >>>>>>> >>>>>>> Request for comments: >>>>>>> - Should I add a parameter to specify the polling time? (now >>>>>>> 1ms) >>>>>>> - Should I add a parameter to specify the maximum polling >>>>>>> number? Now if something fails about creating the task, it >>>>>>> polls forever. >>>>>>> - Obviously, if these parameters should be added, there should >>>>>>> be a reasonable default for them (~ Required=False, Default=X). >>>>>> >>>>>> I don't think you need a polling time, esp since this is hidden >>>>>> from the user, but I think that is probably too short and you >>>>>> may end up hammering the LDAP server. >>>>>> >>>>>> I also wonder if there should be some maximum wait time. I don't >>>>>> like loops that can never exit. I'm at a loss for what that time >>>>>> should be though. And we'd need to spell out that we gave up >>>>>> waiting, not that the task necessarily failed. So rather than >>>>>> having a polling time option, rename nowait into wait_for=20, so >>>>>> wait for 20 seconds. Or something like that. >>>>>> >>>>>> I'd suggest using get_entry since you already know the full DN >>>>>> and there is only ever one. It would make this much more >>>>>> readable. >>>>>> >>>>>> I wonder if some top-level documentation should be added to flesh >>>>>> this out some more. This does, for example, return False in one >>>>>> case. The meaning for that should be spelled out. >>>>>> >>>>>> rob >>>>> >>>>> Hi, >>>>> personally I would keep --no-wait, with a delay of 1 seconds, and >>>>> a maximum waiting time for 60 seconds. Questions is, do we need to >>>>> parameterize with other parameters(wait-for to the maximum time, >>>>> and/or poll-delay for the delay time, both not required), or it is >>>>> not a case which worth to develop? >>>>> Greets >>>>> Adam >>>> >>>> Hi, >>>> here are the corrections Petr asked, also the other patch conatins >>>> the plugin registration refactor. >>> >>> >>> Thanks! >>> >>> You forgot an alternate summary for the --no-wait case. (Make sure >>> to output the DN in this case, so it's possible to poll for it.) >>> >>> >>> >>> Instead of `task['nstaskexitcode'][0]` please use >>> `task.single_value['nstaskexitcode']`. There's one more `task['nstaskexitcode'][0]`. (Perhaps putting it in a variable would be better?) >>> >>> Here: >>> >>> raise errors.DatabaseError( >>> desc=_("Automember rebuild membership task failed"), >>> info=_("nstaskexitcode = '%s'" % >>> str(task['nstaskexitcode'][0]))) >>> >>> there's no need to call str() on %'s argument. >>> Also, use natural language (like "Task exit code: %s"), otherwise >>> there's no need to mark the message for translation. >>> >>> >> >> And one more thing: Please bump the minor version in the VERSION file >> when API.txt changes. >> >> > > Hi, > everything is corrected! > Greets > Adam > Sorry for dragging this so long, but: The DN should not be a part of the summary, because that makes it hard to parse when using the API. It should be returned as a part of the result. To do that, you'd need to change the output type: has_output = output.standard_entry has_output_params = ( DNParam( 'dn', label=_('Task automember'), doc=_('DN of the started task'), ), ) and provide a dict in result, instead of True. (And with --no-wait, add the dn to that dict.) -- Petr? From pviktori at redhat.com Fri Mar 21 11:50:24 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Mar 2014 12:50:24 +0100 Subject: [Freeipa-devel] [PATCHES] 0499-0502 permission CLI: rename --permissions to --right In-Reply-To: <20140321121048.62b6878a@unused-4-246.brq.redhat.com> References: <532827AE.5040403@redhat.com> <20140320192040.02da0270@unused-4-246.brq.redhat.com> <532C1113.6050009@redhat.com> <20140321121048.62b6878a@unused-4-246.brq.redhat.com> Message-ID: <532C2780.9090101@redhat.com> On 03/21/2014 12:10 PM, Misnyovszki Adam wrote: > On Fri, 21 Mar 2014 11:14:43 +0100 > Petr Viktorin wrote: > >> On 03/20/2014 07:20 PM, Misnyovszki Adam wrote: >>> On Tue, 18 Mar 2014 12:02:06 +0100 >>> Petr Viktorin wrote: >>> >>>> Hello, >>>> This renames --permissions to --right. The old name is kept as a >>>> deprecated alias. >>>> FreeIPA didn't have a mechanism for doing this, so I added one. >>>> Also, while I was digging around in this part, I made the new >>>> IntEnum (and all future Enums) act like StrEnum in --help output. >>>> >>>> >>>> https://fedorahosted.org/freeipa/ticket/4231 >>>> >>> >>> 499 ACK >>> 500 ACK >>> 501 ACK >>> - although should it allow mixing deprecated and current >>> aliases(eg --permission=read --right=write)? >> >> You're right, this is a strange edge case, but detecting this would >> need need a much more complicated approach than sharing the option's >> `dest`. I don't think it's worth it. >> >>> - works fine with cli / webui also >>> - help displays nicely >>> 502 >>> - tested with more than one deprecated alias - API.txt validation >>> doesn't match, although it has the same output: >>> Got StrEnum('ipapermright', attribute=True, cli_name='right', >>> deprecated_cli_aliases=set(['testalias', 'permissions']), >>> multivalue=True, required=False, values=(u'read', u'search', >>> u'compare', u'write', u'add', u'delete', u'all')) >>> Expected StrEnum('ipapermright', attribute=True, cli_name='right', >>> deprecated_cli_aliases=set(['testalias','permissions']), >>> multivalue=True, required=False, values=(u'read', u'search', >>> u'compare', u'write', u'add', u'delete', u'all')) >>> >>> API.txt: >>> option: StrEnum('ipapermright', attribute=True, >>> cli_name='right', >>> deprecated_cli_aliases=set(['testalias','permissions']), >>> multivalue=True, required=False, values=(u'read', u'search', >>> u'compare', u'write', u'add', u'delete', u'all')) >>> ipalib/plugins/permission.py: >>> StrEnum( >>> 'ipapermright*', >>> cli_name='right', >>> deprecated_cli_aliases={'permissions','testalias'}, >>> label=_('Granted >>> rights'), >>> doc=_('Rights to grant >>> ' >>> '(read, search, compare, write, add, delete, >>> all)'), >>> values=(u'read', u'search', >>> u'compare', >>> u'write', u'add', u'delete', >>> u'all'), >>> ), >>> don't know if it is a problem anyways >>> - other tests(cli, webui) works fine for me >>> - unit tests related to this ran as expected >>> so besides the multiple deprecated_cli_aliases issue, it's an ACK >> >> It looks like you've edited API.txt by hand and forgot a space after >> the comma in ['testalias','permissions']. Does it work if you use >> makeapi to regenerate API.txt? >> > > You are right, my mistake, with ./makeapi, it works, even when the CLI > got this for parameters: > --right=read --permission=search --testparam=write > > ACK Thanks for the review! > Greets > Adam > Adam commented in person that I should bump VERSION; I did that as an additional one-liner change. Pushed to master: 801b2fd4588b8b40b74140f26b12eb190306d260 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0502.2-permission-CLI-rename-permissions-to-right.patch Type: text/x-patch Size: 5649 bytes Desc: not available URL: From mkosek at redhat.com Fri Mar 21 11:55:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 21 Mar 2014 12:55:19 +0100 Subject: [Freeipa-devel] [PATCH] typo in migrate-ds In-Reply-To: <20140321102918.571ea265@unused-4-246.brq.redhat.com> References: <20140321102918.571ea265@unused-4-246.brq.redhat.com> Message-ID: <532C28A7.9070401@redhat.com> On 03/21/2014 10:29 AM, Misnyovszki Adam wrote: > On Tue, 18 Mar 2014 19:31:31 -0600 > Gabe Alford wrote: > >> All, >> >> It looks like the only typos exist in the uk and fr .po files for this >> ticket >> https://fedorahosted.org/freeipa/ticket/2546 >> >> Point me in the right direction if I am wrong. >> >> Thanks, >> >> Gabe > > ACK, thanks for the patch! > > Greets > Adam I am personally not sure this is the right solution. Shouldn't this be rather re-generated from Transifex instead editing .po files directly? CCing Petr. Martin From mkosek at redhat.com Fri Mar 21 11:58:47 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 21 Mar 2014 12:58:47 +0100 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <532C24AE.8090406@redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> <20140321120032.23243622@unused-4-246.brq.redhat.com> <532C24AE.8090406@redhat.com> Message-ID: <532C2977.7070401@redhat.com> On 03/21/2014 12:38 PM, Petr Viktorin wrote: > On 03/21/2014 12:00 PM, Misnyovszki Adam wrote: >> On Fri, 21 Mar 2014 10:33:00 +0100 >> Petr Viktorin wrote: >> >>> On 03/21/2014 10:29 AM, Petr Viktorin wrote: >>>> On 03/20/2014 04:22 PM, Misnyovszki Adam wrote: >>>>> On Thu, 20 Mar 2014 14:19:51 +0100 >>>>> Misnyovszki Adam wrote: >>>>> >>>>>> On Fri, 14 Mar 2014 13:26:15 -0400 >>>>>> Rob Crittenden wrote: >>>>>> >>>>>>> Misnyovszki Adam wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> automember-rebuild uses asynchronous 389 task, and returned >>>>>>>> success even if the task didn't run. This patch fixes this issue >>>>>>>> adding a --nowait parameter to 'ipa automember-rebuild', >>>>>>>> defaulting to False, thus when the script runs without it, it >>>>>>>> waits for the 'nstaskexitcode' attribute, which means the task >>>>>>>> has finished, according to >>>>>>>> http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. >>>>>>>> >>>>>>>> >>>>>>>> Old usage can be enabled using --nowait. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/4239 >>>>>>>> >>>>>>>> Request for comments: >>>>>>>> - Should I add a parameter to specify the polling time? (now >>>>>>>> 1ms) >>>>>>>> - Should I add a parameter to specify the maximum polling >>>>>>>> number? Now if something fails about creating the task, it >>>>>>>> polls forever. >>>>>>>> - Obviously, if these parameters should be added, there should >>>>>>>> be a reasonable default for them (~ Required=False, Default=X). >>>>>>> >>>>>>> I don't think you need a polling time, esp since this is hidden >>>>>>> from the user, but I think that is probably too short and you >>>>>>> may end up hammering the LDAP server. >>>>>>> >>>>>>> I also wonder if there should be some maximum wait time. I don't >>>>>>> like loops that can never exit. I'm at a loss for what that time >>>>>>> should be though. And we'd need to spell out that we gave up >>>>>>> waiting, not that the task necessarily failed. So rather than >>>>>>> having a polling time option, rename nowait into wait_for=20, so >>>>>>> wait for 20 seconds. Or something like that. >>>>>>> >>>>>>> I'd suggest using get_entry since you already know the full DN >>>>>>> and there is only ever one. It would make this much more >>>>>>> readable. >>>>>>> >>>>>>> I wonder if some top-level documentation should be added to flesh >>>>>>> this out some more. This does, for example, return False in one >>>>>>> case. The meaning for that should be spelled out. >>>>>>> >>>>>>> rob >>>>>> >>>>>> Hi, >>>>>> personally I would keep --no-wait, with a delay of 1 seconds, and >>>>>> a maximum waiting time for 60 seconds. Questions is, do we need to >>>>>> parameterize with other parameters(wait-for to the maximum time, >>>>>> and/or poll-delay for the delay time, both not required), or it is >>>>>> not a case which worth to develop? >>>>>> Greets >>>>>> Adam >>>>> >>>>> Hi, >>>>> here are the corrections Petr asked, also the other patch conatins >>>>> the plugin registration refactor. >>>> >>>> >>>> Thanks! >>>> >>>> You forgot an alternate summary for the --no-wait case. (Make sure >>>> to output the DN in this case, so it's possible to poll for it.) >>>> >>>> >>>> >>>> Instead of `task['nstaskexitcode'][0]` please use >>>> `task.single_value['nstaskexitcode']`. > > There's one more `task['nstaskexitcode'][0]`. (Perhaps putting it in a variable > would be better?) > >>>> >>>> Here: >>>> >>>> raise errors.DatabaseError( >>>> desc=_("Automember rebuild membership task failed"), >>>> info=_("nstaskexitcode = '%s'" % >>>> str(task['nstaskexitcode'][0]))) >>>> >>>> there's no need to call str() on %'s argument. >>>> Also, use natural language (like "Task exit code: %s"), otherwise >>>> there's no need to mark the message for translation. >>>> >>>> >>> >>> And one more thing: Please bump the minor version in the VERSION file >>> when API.txt changes. >>> >>> >> >> Hi, >> everything is corrected! >> Greets >> Adam >> > > Sorry for dragging this so long, but: > The DN should not be a part of the summary, because that makes it hard to parse > when using the API. It should be returned as a part of the result. > To do that, you'd need to change the output type: > > has_output = output.standard_entry > has_output_params = ( > DNParam( > 'dn', > label=_('Task automember'), > doc=_('DN of the started task'), > ), > ) > > and provide a dict in result, instead of True. (And with --no-wait, add the dn > to that dict.) > Do really want to use 'dn' for the DNParam? dn is already used for standard entry DN when --all is used, right? "automembertaskdn" may be better. Also, "Task automember" label sounds strange to me, would "Automember task DN" be better? Martin From pviktori at redhat.com Fri Mar 21 12:06:21 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Mar 2014 13:06:21 +0100 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <532C2977.7070401@redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> <20140321120032.23243622@unused-4-246.brq.redhat.com> <532C24AE.8090406@redhat.com> <532C2977.7070401@redhat.com> Message-ID: <532C2B3D.9010401@redhat.com> On 03/21/2014 12:58 PM, Martin Kosek wrote: > On 03/21/2014 12:38 PM, Petr Viktorin wrote: >> On 03/21/2014 12:00 PM, Misnyovszki Adam wrote: >>> On Fri, 21 Mar 2014 10:33:00 +0100 >>> Petr Viktorin wrote: >>> >>>> On 03/21/2014 10:29 AM, Petr Viktorin wrote: >>>>> On 03/20/2014 04:22 PM, Misnyovszki Adam wrote: >>>>>> On Thu, 20 Mar 2014 14:19:51 +0100 >>>>>> Misnyovszki Adam wrote: >>>>>> >>>>>>> On Fri, 14 Mar 2014 13:26:15 -0400 >>>>>>> Rob Crittenden wrote: >>>>>>> >>>>>>>> Misnyovszki Adam wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> automember-rebuild uses asynchronous 389 task, and returned >>>>>>>>> success even if the task didn't run. This patch fixes this issue >>>>>>>>> adding a --nowait parameter to 'ipa automember-rebuild', >>>>>>>>> defaulting to False, thus when the script runs without it, it >>>>>>>>> waits for the 'nstaskexitcode' attribute, which means the task >>>>>>>>> has finished, according to >>>>>>>>> http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. >>>>>>>>> >>>>>>>>> >>>>>>>>> Old usage can be enabled using --nowait. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4239 >>>>>>>>> >>>>>>>>> Request for comments: >>>>>>>>> - Should I add a parameter to specify the polling time? (now >>>>>>>>> 1ms) >>>>>>>>> - Should I add a parameter to specify the maximum polling >>>>>>>>> number? Now if something fails about creating the task, it >>>>>>>>> polls forever. >>>>>>>>> - Obviously, if these parameters should be added, there should >>>>>>>>> be a reasonable default for them (~ Required=False, Default=X). >>>>>>>> >>>>>>>> I don't think you need a polling time, esp since this is hidden >>>>>>>> from the user, but I think that is probably too short and you >>>>>>>> may end up hammering the LDAP server. >>>>>>>> >>>>>>>> I also wonder if there should be some maximum wait time. I don't >>>>>>>> like loops that can never exit. I'm at a loss for what that time >>>>>>>> should be though. And we'd need to spell out that we gave up >>>>>>>> waiting, not that the task necessarily failed. So rather than >>>>>>>> having a polling time option, rename nowait into wait_for=20, so >>>>>>>> wait for 20 seconds. Or something like that. >>>>>>>> >>>>>>>> I'd suggest using get_entry since you already know the full DN >>>>>>>> and there is only ever one. It would make this much more >>>>>>>> readable. >>>>>>>> >>>>>>>> I wonder if some top-level documentation should be added to flesh >>>>>>>> this out some more. This does, for example, return False in one >>>>>>>> case. The meaning for that should be spelled out. >>>>>>>> >>>>>>>> rob >>>>>>> >>>>>>> Hi, >>>>>>> personally I would keep --no-wait, with a delay of 1 seconds, and >>>>>>> a maximum waiting time for 60 seconds. Questions is, do we need to >>>>>>> parameterize with other parameters(wait-for to the maximum time, >>>>>>> and/or poll-delay for the delay time, both not required), or it is >>>>>>> not a case which worth to develop? >>>>>>> Greets >>>>>>> Adam >>>>>> >>>>>> Hi, >>>>>> here are the corrections Petr asked, also the other patch conatins >>>>>> the plugin registration refactor. >>>>> >>>>> >>>>> Thanks! >>>>> >>>>> You forgot an alternate summary for the --no-wait case. (Make sure >>>>> to output the DN in this case, so it's possible to poll for it.) >>>>> >>>>> >>>>> >>>>> Instead of `task['nstaskexitcode'][0]` please use >>>>> `task.single_value['nstaskexitcode']`. >> >> There's one more `task['nstaskexitcode'][0]`. (Perhaps putting it in a variable >> would be better?) >> >>>>> >>>>> Here: >>>>> >>>>> raise errors.DatabaseError( >>>>> desc=_("Automember rebuild membership task failed"), >>>>> info=_("nstaskexitcode = '%s'" % >>>>> str(task['nstaskexitcode'][0]))) >>>>> >>>>> there's no need to call str() on %'s argument. >>>>> Also, use natural language (like "Task exit code: %s"), otherwise >>>>> there's no need to mark the message for translation. >>>>> >>>>> >>>> >>>> And one more thing: Please bump the minor version in the VERSION file >>>> when API.txt changes. >>>> >>>> >>> >>> Hi, >>> everything is corrected! >>> Greets >>> Adam >>> >> >> Sorry for dragging this so long, but: >> The DN should not be a part of the summary, because that makes it hard to parse >> when using the API. It should be returned as a part of the result. >> To do that, you'd need to change the output type: >> >> has_output = output.standard_entry >> has_output_params = ( >> DNParam( >> 'dn', >> label=_('Task automember'), >> doc=_('DN of the started task'), >> ), >> ) >> >> and provide a dict in result, instead of True. (And with --no-wait, add the dn >> to that dict.) >> > > Do really want to use 'dn' for the DNParam? dn is already used for standard > entry DN when --all is used, right? "automembertaskdn" may be better. Well, I think "DN of the added entry" is exactly what this is. > Also, "Task automember" label sounds strange to me, would "Automember task DN" > be better? I meant "Task DN", sorry for the thinko. -- Petr? From pviktori at redhat.com Fri Mar 21 12:09:21 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 21 Mar 2014 13:09:21 +0100 Subject: [Freeipa-devel] [PATCH] typo in migrate-ds In-Reply-To: <532C28A7.9070401@redhat.com> References: <20140321102918.571ea265@unused-4-246.brq.redhat.com> <532C28A7.9070401@redhat.com> Message-ID: <532C2BF1.8050005@redhat.com> On 03/21/2014 12:55 PM, Martin Kosek wrote: > On 03/21/2014 10:29 AM, Misnyovszki Adam wrote: >> On Tue, 18 Mar 2014 19:31:31 -0600 >> Gabe Alford wrote: >> >>> All, >>> >>> It looks like the only typos exist in the uk and fr .po files for this >>> ticket >>> https://fedorahosted.org/freeipa/ticket/2546 >>> >>> Point me in the right direction if I am wrong. >>> >>> Thanks, >>> >>> Gabe >> >> ACK, thanks for the patch! >> >> Greets >> Adam > > I am personally not sure this is the right solution. Shouldn't this be rather > re-generated from Transifex instead editing .po files directly? CCing Petr. We generally prefer Transifex, but Git is perfectly fine in my book. Pushed to master: 20c716ec9a69a4a24ff4138471a0ce457cabf99c FWIW, Transifex is a closed-source no-cost-for-FOSS webapp, same model as Github. I'm not entirely sure how having that in our preferred workflow got past Simo -- Petr? From simo at redhat.com Fri Mar 21 12:47:05 2014 From: simo at redhat.com (Simo Sorce) Date: Fri, 21 Mar 2014 08:47:05 -0400 Subject: [Freeipa-devel] [PATCH] typo in migrate-ds In-Reply-To: <532C2BF1.8050005@redhat.com> References: <20140321102918.571ea265@unused-4-246.brq.redhat.com> <532C28A7.9070401@redhat.com> <532C2BF1.8050005@redhat.com> Message-ID: <1395406025.26633.66.camel@willson.li.ssimo.org> On Fri, 2014-03-21 at 13:09 +0100, Petr Viktorin wrote: > On 03/21/2014 12:55 PM, Martin Kosek wrote: > > On 03/21/2014 10:29 AM, Misnyovszki Adam wrote: > >> On Tue, 18 Mar 2014 19:31:31 -0600 > >> Gabe Alford wrote: > >> > >>> All, > >>> > >>> It looks like the only typos exist in the uk and fr .po files for this > >>> ticket > >>> https://fedorahosted.org/freeipa/ticket/2546 > >>> > >>> Point me in the right direction if I am wrong. > >>> > >>> Thanks, > >>> > >>> Gabe > >> > >> ACK, thanks for the patch! > >> > >> Greets > >> Adam > > > > I am personally not sure this is the right solution. Shouldn't this be rather > > re-generated from Transifex instead editing .po files directly? CCing Petr. > > We generally prefer Transifex, but Git is perfectly fine in my book. > > Pushed to master: 20c716ec9a69a4a24ff4138471a0ce457cabf99c > > > FWIW, Transifex is a closed-source no-cost-for-FOSS webapp, same model > as Github. I'm not entirely sure how having that in our preferred > workflow got past Simo It wasn't like that when we started using it :-/ Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Fri Mar 21 14:17:20 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 21 Mar 2014 15:17:20 +0100 Subject: [Freeipa-devel] [PATCH] 564 webui-ci: fix test_rebuild_membership_hosts on server without DNS Message-ID: <532C49F0.9030100@redhat.com> Host adder dialog differs on installations with and without DNS. Previous test used values for adding hosts which were suitable only for IPA servers installed with DNS. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0564-webui-ci-fix-test_rebuild_membership_hosts-on-server.patch Type: text/x-patch Size: 2180 bytes Desc: not available URL: From massimiliano.perrone at tirasa.net Fri Mar 21 15:52:57 2014 From: massimiliano.perrone at tirasa.net (Massimiliano Perrone (tirasa.net)) Date: Fri, 21 Mar 2014 16:52:57 +0100 Subject: [Freeipa-devel] Talking json/rpc with java client In-Reply-To: <1395320952.26633.37.camel@willson.li.ssimo.org> References: <20140318091035.GA9052@redhat.com> <53281662.3030105@tirasa.net> <20140318102643.GC16644@redhat.com> <53286E45.4000605@tirasa.net> <20140318162607.GH16644@redhat.com> <532AB5BE.2070409@tirasa.net> <20140320103119.GO16644@redhat.com> <532ADF1F.8000002@redhat.com> <20140320124715.GP16644@redhat.com> <1395320952.26633.37.camel@willson.li.ssimo.org> Message-ID: <532C6059.7060602@tirasa.net> On 03/20/2014 02:09 PM, Simo Sorce wrote: > On Thu, 2014-03-20 at 14:47 +0200, Alexander Bokovoy wrote: >> On Thu, 20 Mar 2014, Rob Crittenden wrote: >>> Alexander Bokovoy wrote: >>>> On Thu, 20 Mar 2014, Massimiliano Perrone (example.com) wrote: >>>>> On 03/18/2014 05:26 PM, Alexander Bokovoy wrote: >>>>>> On Tue, 18 Mar 2014, Massimiliano Perrone (example.com) wrote: >>>>>>>>> The difference between the two calls is on the last TGS_REQ; >>>>>>>>> because the first one is on ldap/olmo.example.com at EXAMPLE.COM and >>>>>>>>> it's OK whereas the second one is on >>>>>>>>> HTTP/olmo.example.com at EXAMPLE.COM that returns a 401 (I suppose). >>>>>>>>> >>>>>>>>> Where's the error? >>>>>>>> Am I correct that you have a user connecting to HTTP/ebano.example.com >>>>>>>> and then HTTP/ebano.example.com wants to talk to HTTP/olmo.example.com >>>>>>>> using credentials of the user? >>>>>>>> >>>>>>>> FreeIPA uses constraint delegation of the credentials, with the >>>>>>>> help of >>>>>>>> S4U2Proxy extension. You need to allow HTTP/ebano.example.com to >>>>>>>> delegate >>>>>>>> credentials to HTTP/olmo.example.com. >>>>>>>> >>>>>>>> I have written an article how to do that: >>>>>>>> https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Hi Alexander, thanks for your reply. >>>>>>> I read carefully your interesting post and I follow it to delegate >>>>>>> HTTP/ebano.example.com credentials to HTTP/olmo.example.com. >>>>>>> >>>>>>> Now, two questions: >>>>>>> 1) How can I check that my configuration, now is ok? Because this >>>>>>> ldapsearch returns result: 0 >>>>>>> >>>>>>> ldapsearch -Y GSSAPI -H ldap://olmo.example.com -b >>>>>>> "cn=s4u2proxy,cn=etc,dc=example,dc=com" >>>>>>> "cn=ipa-http-delegation-targets" dn >>>>>> You need to create these delegation entries yourself, like the article >>>>>> says. Note that your app talks to IPA server's HTTP service, so create >>>>>> >>>>>> dn: cn=ebano-http-delegation,cn=s4u2proxy,cn=etc,dc=example,dc=com >>>>>> objectClass: ipaKrb5DelegationACL >>>>>> objectClass: groupOfPrincipals >>>>>> objectClass: top >>>>>> cn: ebano-http-delegation >>>>>> memberPrincipal: HTTP/ebano.example.com at EXAMPLE.COM >>>>>> ipaAllowedTarget: >>>>>> cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com >>>>>> >>>>>> This entry says: "HTTP/ebano.example.com is allowed to delegate users' >>>>>> credentials to whatever Kerberos principal is a member of >>>>>> cn=ebano-http-delegation-targets group" >>>>>> >>>>>> Now, this is the group: >>>>>> dn: >>>>>> cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com >>>>>> objectClass: groupOfPrincipals >>>>>> objectClass: top >>>>>> cn: ebano-http-delegation-targets >>>>>> memberPrincipal: HTTP/olomo.example.com at EXAMPLE.COM >>>>>> >>>>>> With these two entries we would have HTTP/ebano.example.com allowed to >>>>>> delegate users' credentials to HTTP/olomo.example.com >>>>> Hi Alexander, thanks for your patience. >>>>> I followed your suggestions but the result is always the same. >>>>> >>>>> Trying with curl, of course, it works. >>>>> >>>>> My doubt now is why curl generates this log on kerberos server >>>>> >>>>> mar 20 10:22:20 olmo.example.com krb5kdc[5091](info): TGS_REQ (1 >>>>> etypes {18}) 192.168.0.105: ISSUE: authtime 1395301975, etypes {rep=18 >>>>> tkt=18 ses=18}, admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM >>>>> mar 20 10:22:21 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 >>>>> etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime 1395301975, >>>>> etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for >>>>> ldap/olmo.example.com at EXAMPLE.COM >>>> This is effect of S4U extension working correctly. >>>> >>>>> whereas java generates this other one >>>>> >>>>> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 etypes >>>>> {18 17 16 23}) 192.168.0.105: NEEDED_PREAUTH: >>>>> HTTP/ebano.example.com at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, >>>>> Additional pre-authentication required >>>>> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 etypes >>>>> {18 17 16 23}) 192.168.0.105: ISSUE: authtime 1395307449, etypes >>>>> {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for >>>>> krbtgt/EXAMPLE.COM at EXAMPLE.COM >>>>> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 >>>>> etypes {18 17 16 23 1 3}) 192.168.0.105: ISSUE: authtime 1395307449, >>>>> etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for >>>>> HTTP/olmo.example.com at EXAMPLE.COM >>>>> >>>>> As you can see, the first one uses admin on ldap service, the second >>>>> one uses HTTP/ebano.example.com on HTTP service. >>>> This means your Java application doesn't use S4U extension or doesn't >>>> know about that. >>>> >>>>> Can I do the same call with Java? >>>> At this point we need to set clear what Java are you using. >>>> >>>> http://download.java.net/jdk8/docs/technotes/guides/security/jgss/jgss-features.html >>>> >>>> tells that S4U extensions (we use S4U2Proxy here) was added in Java SE 8. >>>> >>> The client doesn't do the S4U2Proxy work though, so this shouldn't >>> matter, right? >> My point is that the client will not do what he expects unless S4U2Proxy >> is used in Java and that requires Java 8 platform, released on March >> 18th 2014. > I think you can use earlier Java versions but tell them to use the > native GSSAPI library (and perhaps sprinkle a little bit of GSS-Proxy in > the back for fun. Here I'm again :) I wrote a GSSClient [1] obtaining: ################################################### java.io.IOException: Server returned HTTP response code: 401 for URL: https://olmo.example.com/ipa/json ################################################### Other info from kerberos client: ################################################### Ordering keys wrt default_tkt_enctypes list Using builtin default etypes for default_tkt_enctypes default etypes for default_tkt_enctypes: 18 17 16 23 1 3. >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >>> KrbAsRep cons in KrbAsReq.getReply HTTP/ebano.example.com principal is HTTP/ebano.example.com at EXAMPLE.COM Will use keytab Commit Succeeded Found ticket for HTTP/ebano.example.com at EXAMPLE.COM to go to krbtgt/EXAMPLE.COM at EXAMPLE.COM expiring on Sat Mar 22 16:38:37 CET 2014 Entered Krb5Context.initSecContext with state=STATE_NEW Service ticket not found in the subject <--------------------------------------------------------------- >>> Credentials acquireServiceCreds: same realm Using builtin default etypes for default_tgs_enctypes default etypes for default_tgs_enctypes: 18 17 16 23 1 3. >>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >>> KrbKdcReq send: kdc=olmo.example.com UDP:88, timeout=30000, number of retries =3, #bytes=681 >>> KDCCommunication: kdc=olmo.example.com UDP:88, timeout=30000,Attempt =1, #bytes=681 >>> KrbKdcReq send: #bytes read=642 >>> KdcAccessibility: remove olmo.example.com >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >>> KrbApReq: APOptions are 00100000 00000000 00000000 00000000 >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType Krb5Context setting mySeqNumber to: 1042307601 Created InitSecContextToken: 0000: 01 00 6E 82 02 4E 30 82 02 4A A0 03 02 01 05 A1 ..n..N0..J...... 0010: 03 02 01 0E A2 07 03 05 00 20 00 00 00 A3 82 01 ......... ...... 0020: 52 61 82 01 4E 30 82 01 4A A0 03 02 01 05 A1 0C Ra..N0..J....... 0030: 1B 0A 54 49 52 41 53 41 2E 4E 45 54 A2 22 30 20 ..EXAMPLE.COM."0 0040: A0 03 02 01 01 A1 19 30 17 1B 04 6C 64 61 70 1B .......0...ldap. 0050: 0F 6F 6C 6D 6F 2E 74 69 72 61 73 61 2E 6E 65 74 .olmo.example.com 0060: A3 82 01 0F 30 82 01 0B A0 03 02 01 12 A1 03 02 ....0........... 0070: 01 02 A2 81 FE 04 81 FB F9 8C FE 4F A0 4E 4B 34 ...........O.NK4 0080: BC 3D A7 E4 05 4E AC 91 58 58 9B 7C 18 72 7E 16 .=...N..XX...r.. 0090: DA 4B 29 1F 52 D7 30 7A 9E FF 18 4C 68 9A 18 DF .K).R.0z...Lh... 00A0: 66 03 F7 55 75 40 DC 38 AC 21 5B 7F C0 70 DB DD f..Uu at .8.![..p.. 00B0: 37 63 7A E2 C4 89 E1 6A B9 29 6D 30 62 1E F1 3E 7cz....j.)m0b..> 00C0: 18 B0 A7 FB 1C 43 F9 33 D6 61 57 D0 26 DA 9E AB .....C.3.aW.&... 00D0: C7 04 3F D0 DC 36 0F 95 B9 AD 5B 1B 64 A8 59 21 ..?..6....[.d.Y! 00E0: E6 32 47 43 49 EA F8 61 38 D6 52 0A 92 A9 78 5F .2GCI..a8.R...x_ 00F0: F7 BE B6 AE B9 0A 47 51 31 44 0D 67 74 D6 E5 71 ......GQ1D.gt..q 0100: CA 85 46 09 FE F1 4D 90 E5 7C 7A 26 22 7D 39 41 ..F...M...z&".9A 0110: 03 2D AB 5A E5 48 26 E7 D5 4A 20 0B 67 54 91 15 .-.Z.H&..J .gT.. 0120: 37 23 A3 68 4D 67 88 0D 9A 4D 01 FA 8A 30 B0 2F 7#.hMg...M...0./ 0130: 57 6A 64 8E A5 7B 2E DB C1 93 07 0B 02 8A FC B7 Wjd............. 0140: BB 6B FD BD 83 DA F7 72 E6 D6 F8 4B BA 06 E4 ED .k.....r...K.... 0150: 20 C2 EA 53 F6 6F F8 BB 0F E4 EF B4 51 15 BB 13 ..S.o......Q... 0160: EB 57 A4 10 F2 C1 36 0B B1 45 6C FA 38 36 9C F9 .W....6..El.86.. 0170: E2 75 BC A4 81 DE 30 81 DB A0 03 02 01 12 A2 81 .u....0......... 0180: D3 04 81 D0 D6 75 77 89 A0 B7 F9 26 64 04 D4 51 .....uw....&d..Q 0190: DD 27 10 A3 B7 8F 1B 88 8C 20 4D A2 25 BF 3D 11 .'....... M.%.=. 01A0: 36 B1 EA 3B C7 BF FE C4 20 42 12 3C 1D 60 CD DB 6..;.... B.<.`.. 01B0: D7 CB 5B 58 25 6D B9 68 6D 32 9F 8C 90 D1 0B 18 ..[X%m.hm2...... 01C0: 90 4D B4 90 8B 17 2A F5 C5 B2 17 AD A7 6A 1F 2C .M....*......j., 01D0: FD BF 2E EA 9C 27 CC 73 68 9B E7 D1 59 99 9D 64 .....'.sh...Y..d 01E0: 08 53 8F 03 88 3B DF 36 5B 24 DC A0 78 F6 DF 6C .S...;.6[$..x..l 01F0: 3C CB FC 84 C9 6B 24 1B DD F0 6F E3 1F 01 CC 94 <....k$...o..... 0200: 2B 40 F7 6C 8D 9A E8 20 05 0A 44 16 64 55 29 B2 + at .l... ..D.dU). 0210: 48 CC 1E C7 B0 99 AE B0 91 87 B1 EB BC 6B F3 8D H............k.. 0220: A9 1B 3C A1 65 97 91 8A B1 9A 25 CB 7B D8 11 99 ..<.e.....%..... 0230: 91 E6 F0 2A AB 5D 21 DA C7 A5 CC AD FA 79 76 33 ...*.]!......yv3 0240: B8 7E ED 1C FE C0 3B 2E C5 9E 71 51 42 9C 0B 47 ......;...qQB..G 0250: 5A 4F 05 DE ZO.. ################################################### As you can see in the row indicated by the arrow there's: Entered Krb5Context.initSecContext with state=STATE_NEW Service ticket not found in the subject <--------------------------------------------------------------- Is this right? PS: next step is JAVA_8 installation to follow Alexander suggestions. [1] https://github.com/massx1/KerberosExample/blob/master/src/main/java/net/tirasa/kerberosexample/GSSClient.java > >> That is, if there is a user talking to the Java client and >> then Java client turning to IPA LDAP or web server with constraint >> delegation. >> >> This is something I tried to get clarification for in the original >> discussion. >> >> > -- Massimiliano Perrone Tel +39 393 9121310 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.example.com Apache Syncope PMC Member http://people.apache.org/~massi/ "L'apprendere molte cose non insegna l'intelligenza" (Eraclito) From abokovoy at redhat.com Sun Mar 23 21:17:53 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 23 Mar 2014 23:17:53 +0200 Subject: [Freeipa-devel] [PATCH 0038] Fix generation of invalid OTP URIs In-Reply-To: <1392052150.17145.28.camel@localhost.localdomain> References: <1392052150.17145.28.camel@localhost.localdomain> Message-ID: <20140323211753.GB3482@redhat.com> On Mon, 10 Feb 2014, Nathaniel McCallum wrote: >Patch attached. >>From e7eac9997750ee1a8ce864746dbc6faa54de766b Mon Sep 17 00:00:00 2001 >From: Nathaniel McCallum >Date: Mon, 10 Feb 2014 12:07:51 -0500 >Subject: [PATCH] Fix generation of invalid OTP URIs > >--- > ipalib/plugins/otptoken.py | 9 +++++++++ > 1 file changed, 9 insertions(+) > >diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py >index 5a5d35d153e7b3698aeebe1e93831b48a8b8f91e..ff92efa11776171b09993060e0805c8ffa6806da 100644 >--- a/ipalib/plugins/otptoken.py >+++ b/ipalib/plugins/otptoken.py >@@ -202,6 +202,15 @@ class otptoken_add(LDAPCreate): > ) > > def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): >+ # These are values we always want to write to LDAP. So if they are >+ # specified as a value that evaluates to False (i.e. None), delete them >+ # and fill in the defaults below. >+ for attr in ('ipatokentotpclockoffset', 'ipatokentotptimestep', >+ 'ipatokenotpalgorithm', 'ipatokenotpdigits', >+ 'ipatokenotpkey'): >+ if attr in entry_attrs and not entry_attrs[attr]: >+ del entry_attrs[attr] >+ > # Set defaults. This needs to happen on the server side because we may > # have global configurable defaults in the near future. > options.setdefault('type', TOKEN_TYPES[0]) ACK. Since this patch rotted a bit, attaching rebased version. -- / Alexander Bokovoy -------------- next part -------------- >From c9d7909da5129b969a851913df48366d0e0a3f1f Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum Date: Mon, 10 Feb 2014 12:07:51 -0500 Subject: [PATCH] Fix generation of invalid OTP URIs --- ipalib/plugins/otptoken.py | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py index 9152539..8987c99 100644 --- a/ipalib/plugins/otptoken.py +++ b/ipalib/plugins/otptoken.py @@ -233,6 +233,15 @@ class otptoken_add(LDAPCreate): ) def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + # These are values we always want to write to LDAP. So if they are + # specified as a value that evaluates to False (i.e. None), delete them + # and fill in the defaults below. + for attr in ('ipatokentotpclockoffset', 'ipatokentotptimestep', + 'ipatokenotpalgorithm', 'ipatokenotpdigits', + 'ipatokenotpkey'): + if attr in entry_attrs and not entry_attrs[attr]: + del entry_attrs[attr] + # Set the object class and defaults for specific token types entry_attrs['objectclass'] = otptoken.object_class + ['ipatoken' + options['type']] for ttype, tattrs in TOKEN_TYPES.items(): -- 1.8.5.3 From abokovoy at redhat.com Sun Mar 23 21:26:57 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 23 Mar 2014 23:26:57 +0200 Subject: [Freeipa-devel] OTP work, what's left? Message-ID: <20140323212657.GC3482@redhat.com> Hi! I've updated my COPR repo with current git master versions of FreeIPA and SSSD with few added patches on top that close OTP gaps (Nathaniel's patch 0038 and Jakub Hrozek's patch for password changes). With these patches we currently lack following parts of the OTP work: - OTP sync client. Still in development, patches and approach need additional review/discussion on the list - Password change in WebUI fails when OTP token exist for the user. More detailed examination is needed, I'm getting ACIError. http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ -- / Alexander Bokovoy From abokovoy at redhat.com Sun Mar 23 21:34:06 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 23 Mar 2014 23:34:06 +0200 Subject: [Freeipa-devel] [PATCH 0159] ipatests: test_trust: Change expected home directories for In-Reply-To: <532AE3DA.1040904@redhat.com> References: <532AE3DA.1040904@redhat.com> Message-ID: <20140323213406.GE3482@redhat.com> On Thu, 20 Mar 2014, Tomas Babej wrote: >Hi, > >Information from the AD about the home directories is not leveraged at >all, but is generated from the username and domain. Fix the assumptions >in the tests. > >Also changes 'Subdomain Test User' to 'Subdomaintest User' to be more >consistent. > >https://fedorahosted.org/freeipa/ticket/4184 ACK. -- / Alexander Bokovoy From abokovoy at redhat.com Sun Mar 23 21:35:15 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 23 Mar 2014 23:35:15 +0200 Subject: [Freeipa-devel] [PATCH] 464 Proxy PKI clone /ca/ee/ca/profileSubmit URI In-Reply-To: <532AA94E.3070906@redhat.com> References: <532AA94E.3070906@redhat.com> Message-ID: <20140323213515.GF3482@redhat.com> On Thu, 20 Mar 2014, Martin Kosek wrote: >PKI change done in ticket https://fedorahosted.org/pki/ticket/816 >requires the PKI Clone's SSL Server certificate to be issued by >it's associated PKI master. > >Allow this call on IPA master. > >https://fedorahosted.org/freeipa/ticket/4265 > >--- > >We will need this change in upcoming FreeIPA 3.3.5 which would be then needed >both in F19 and F20 to make the F20 cloning work again. > >Martin >From 3cbeb946d72c6d3136ad8ae75d8f6719e6db06f4 Mon Sep 17 00:00:00 2001 >From: Martin Kosek >Date: Thu, 20 Mar 2014 09:34:53 +0100 >Subject: [PATCH] Proxy PKI clone /ca/ee/ca/profileSubmit URI > >PKI change done in ticket https://fedorahosted.org/pki/ticket/816 >requires the PKI Clone's SSL Server certificate to be issued by >it's associated PKI master. > >Allow this call on IPA master. > >https://fedorahosted.org/freeipa/ticket/4265 >--- > install/conf/ipa-pki-proxy.conf | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/install/conf/ipa-pki-proxy.conf b/install/conf/ipa-pki-proxy.conf >index 6f0463242b75a58cf63a38e62c23fa372aeacf64..224cdd45b5b5f72671a179570fd15772fe8cfaab 100644 >--- a/install/conf/ipa-pki-proxy.conf >+++ b/install/conf/ipa-pki-proxy.conf >@@ -1,9 +1,9 @@ >-# VERSION 3 - DO NOT REMOVE THIS LINE >+# VERSION 4 - DO NOT REMOVE THIS LINE > > ProxyRequests Off > > # matches for ee port >- >+ > NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate > NSSVerifyClient none > ProxyPassMatch ajp://localhost:$DOGTAG_PORT ACK, straightforward fix. -- / Alexander Bokovoy From mkosek at redhat.com Mon Mar 24 08:53:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 24 Mar 2014 09:53:54 +0100 Subject: [Freeipa-devel] [PATCH 0159] ipatests: test_trust: Change expected home directories for In-Reply-To: <20140323213406.GE3482@redhat.com> References: <532AE3DA.1040904@redhat.com> <20140323213406.GE3482@redhat.com> Message-ID: <532FF2A2.7050407@redhat.com> On 03/23/2014 10:34 PM, Alexander Bokovoy wrote: > On Thu, 20 Mar 2014, Tomas Babej wrote: >> Hi, >> >> Information from the AD about the home directories is not leveraged at >> all, but is generated from the username and domain. Fix the assumptions >> in the tests. >> >> Also changes 'Subdomain Test User' to 'Subdomaintest User' to be more >> consistent. >> >> https://fedorahosted.org/freeipa/ticket/4184 > ACK. Thanks both to Jakub and Alexander for review. Pushed to master, ipa-3-3. Martin From amisnyov at redhat.com Mon Mar 24 10:42:21 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Mon, 24 Mar 2014 11:42:21 +0100 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <532C2B3D.9010401@redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> <20140321120032.23243622@unused-4-246.brq.redhat.com> <532C24AE.8090406@redhat.com> <532C2977.7070401@redhat.com> <532C2B3D.9010401@redhat.com> Message-ID: <20140324114221.6ae6b214@unused-4-246.brq.redhat.com> On Fri, 21 Mar 2014 13:06:21 +0100 Petr Viktorin wrote: > On 03/21/2014 12:58 PM, Martin Kosek wrote: > > On 03/21/2014 12:38 PM, Petr Viktorin wrote: > >> On 03/21/2014 12:00 PM, Misnyovszki Adam wrote: > >>> On Fri, 21 Mar 2014 10:33:00 +0100 > >>> Petr Viktorin wrote: > >>> > >>>> On 03/21/2014 10:29 AM, Petr Viktorin wrote: > >>>>> On 03/20/2014 04:22 PM, Misnyovszki Adam wrote: > >>>>>> On Thu, 20 Mar 2014 14:19:51 +0100 > >>>>>> Misnyovszki Adam wrote: > >>>>>> > >>>>>>> On Fri, 14 Mar 2014 13:26:15 -0400 > >>>>>>> Rob Crittenden wrote: > >>>>>>> > >>>>>>>> Misnyovszki Adam wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> automember-rebuild uses asynchronous 389 task, and returned > >>>>>>>>> success even if the task didn't run. This patch fixes this > >>>>>>>>> issue adding a --nowait parameter to 'ipa > >>>>>>>>> automember-rebuild', defaulting to False, thus when the > >>>>>>>>> script runs without it, it waits for the 'nstaskexitcode' > >>>>>>>>> attribute, which means the task has finished, according to > >>>>>>>>> http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Old usage can be enabled using --nowait. > >>>>>>>>> > >>>>>>>>> https://fedorahosted.org/freeipa/ticket/4239 > >>>>>>>>> > >>>>>>>>> Request for comments: > >>>>>>>>> - Should I add a parameter to specify the polling time? (now > >>>>>>>>> 1ms) > >>>>>>>>> - Should I add a parameter to specify the maximum polling > >>>>>>>>> number? Now if something fails about creating the task, it > >>>>>>>>> polls forever. > >>>>>>>>> - Obviously, if these parameters should be added, there > >>>>>>>>> should be a reasonable default for them (~ Required=False, > >>>>>>>>> Default=X). > >>>>>>>> > >>>>>>>> I don't think you need a polling time, esp since this is > >>>>>>>> hidden from the user, but I think that is probably too short > >>>>>>>> and you may end up hammering the LDAP server. > >>>>>>>> > >>>>>>>> I also wonder if there should be some maximum wait time. I > >>>>>>>> don't like loops that can never exit. I'm at a loss for what > >>>>>>>> that time should be though. And we'd need to spell out that > >>>>>>>> we gave up waiting, not that the task necessarily failed. So > >>>>>>>> rather than having a polling time option, rename nowait into > >>>>>>>> wait_for=20, so wait for 20 seconds. Or something like that. > >>>>>>>> > >>>>>>>> I'd suggest using get_entry since you already know the full > >>>>>>>> DN and there is only ever one. It would make this much more > >>>>>>>> readable. > >>>>>>>> > >>>>>>>> I wonder if some top-level documentation should be added to > >>>>>>>> flesh this out some more. This does, for example, return > >>>>>>>> False in one case. The meaning for that should be spelled > >>>>>>>> out. > >>>>>>>> > >>>>>>>> rob > >>>>>>> > >>>>>>> Hi, > >>>>>>> personally I would keep --no-wait, with a delay of 1 seconds, > >>>>>>> and a maximum waiting time for 60 seconds. Questions is, do > >>>>>>> we need to parameterize with other parameters(wait-for to the > >>>>>>> maximum time, and/or poll-delay for the delay time, both not > >>>>>>> required), or it is not a case which worth to develop? > >>>>>>> Greets > >>>>>>> Adam > >>>>>> > >>>>>> Hi, > >>>>>> here are the corrections Petr asked, also the other patch > >>>>>> conatins the plugin registration refactor. > >>>>> > >>>>> > >>>>> Thanks! > >>>>> > >>>>> You forgot an alternate summary for the --no-wait case. (Make > >>>>> sure to output the DN in this case, so it's possible to poll > >>>>> for it.) > >>>>> > >>>>> > >>>>> > >>>>> Instead of `task['nstaskexitcode'][0]` please use > >>>>> `task.single_value['nstaskexitcode']`. > >> > >> There's one more `task['nstaskexitcode'][0]`. (Perhaps putting it > >> in a variable would be better?) > >> > >>>>> > >>>>> Here: > >>>>> > >>>>> raise errors.DatabaseError( > >>>>> desc=_("Automember rebuild membership task failed"), > >>>>> info=_("nstaskexitcode = '%s'" % > >>>>> str(task['nstaskexitcode'][0]))) > >>>>> > >>>>> there's no need to call str() on %'s argument. > >>>>> Also, use natural language (like "Task exit code: %s"), > >>>>> otherwise there's no need to mark the message for translation. > >>>>> > >>>>> > >>>> > >>>> And one more thing: Please bump the minor version in the VERSION > >>>> file when API.txt changes. > >>>> > >>>> > >>> > >>> Hi, > >>> everything is corrected! > >>> Greets > >>> Adam > >>> > >> > >> Sorry for dragging this so long, but: > >> The DN should not be a part of the summary, because that makes it > >> hard to parse when using the API. It should be returned as a part > >> of the result. To do that, you'd need to change the output type: > >> > >> has_output = output.standard_entry > >> has_output_params = ( > >> DNParam( > >> 'dn', > >> label=_('Task automember'), > >> doc=_('DN of the started task'), > >> ), > >> ) > >> > >> and provide a dict in result, instead of True. (And with > >> --no-wait, add the dn to that dict.) > >> > > > > Do really want to use 'dn' for the DNParam? dn is already used for > > standard entry DN when --all is used, right? "automembertaskdn" may > > be better. > > Well, I think "DN of the added entry" is exactly what this is. > > > Also, "Task automember" label sounds strange to me, would > > "Automember task DN" be better? > > I meant "Task DN", sorry for the thinko. > > One more thing, which came to my mind after reviewing the code for myself once again, if the task fails with an exit code other than 0, there is a DatabaseError raised, which is just fine. But in the info, should I specify not only the exit code, but also the DN of the task, or is it unnecessary? Thanks Adam From pvoborni at redhat.com Mon Mar 24 10:46:36 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 24 Mar 2014 11:46:36 +0100 Subject: [Freeipa-devel] [PATCH 0038] Fix generation of invalid OTP URIs In-Reply-To: <20140323211753.GB3482@redhat.com> References: <1392052150.17145.28.camel@localhost.localdomain> <20140323211753.GB3482@redhat.com> Message-ID: <53300D0C.8080607@redhat.com> On 23.3.2014 22:17, Alexander Bokovoy wrote: > On Mon, 10 Feb 2014, Nathaniel McCallum wrote: >> Patch attached. > >>> From e7eac9997750ee1a8ce864746dbc6faa54de766b Mon Sep 17 00:00:00 2001 >> From: Nathaniel McCallum >> Date: Mon, 10 Feb 2014 12:07:51 -0500 >> Subject: [PATCH] Fix generation of invalid OTP URIs >> >> --- >> ipalib/plugins/otptoken.py | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py >> index >> 5a5d35d153e7b3698aeebe1e93831b48a8b8f91e..ff92efa11776171b09993060e0805c8ffa6806da >> 100644 >> --- a/ipalib/plugins/otptoken.py >> +++ b/ipalib/plugins/otptoken.py >> @@ -202,6 +202,15 @@ class otptoken_add(LDAPCreate): >> ) >> >> def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, >> **options): >> + # These are values we always want to write to LDAP. So if >> they are >> + # specified as a value that evaluates to False (i.e. None), >> delete them >> + # and fill in the defaults below. >> + for attr in ('ipatokentotpclockoffset', 'ipatokentotptimestep', >> + 'ipatokenotpalgorithm', 'ipatokenotpdigits', >> + 'ipatokenotpkey'): >> + if attr in entry_attrs and not entry_attrs[attr]: >> + del entry_attrs[attr] >> + >> # Set defaults. This needs to happen on the server side >> because we may >> # have global configurable defaults in the near future. >> options.setdefault('type', TOKEN_TYPES[0]) > ACK. > > > Since this patch rotted a bit, attaching rebased version. > IMO we should not push this patch. Wasn't it superseded by: https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=21ff4f920e4ff7c1e2870024f007f067fc3cf6c8 ? -- Petr Vobornik From abokovoy at redhat.com Mon Mar 24 11:07:17 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 24 Mar 2014 13:07:17 +0200 Subject: [Freeipa-devel] [PATCH 0038] Fix generation of invalid OTP URIs In-Reply-To: <53300D0C.8080607@redhat.com> References: <1392052150.17145.28.camel@localhost.localdomain> <20140323211753.GB3482@redhat.com> <53300D0C.8080607@redhat.com> Message-ID: <20140324110717.GC21211@redhat.com> On Mon, 24 Mar 2014, Petr Vobornik wrote: >On 23.3.2014 22:17, Alexander Bokovoy wrote: >>On Mon, 10 Feb 2014, Nathaniel McCallum wrote: >>>Patch attached. >> >>>>From e7eac9997750ee1a8ce864746dbc6faa54de766b Mon Sep 17 00:00:00 2001 >>>From: Nathaniel McCallum >>>Date: Mon, 10 Feb 2014 12:07:51 -0500 >>>Subject: [PATCH] Fix generation of invalid OTP URIs >>> >>>--- >>>ipalib/plugins/otptoken.py | 9 +++++++++ >>>1 file changed, 9 insertions(+) >>> >>>diff --git a/ipalib/plugins/otptoken.py b/ipalib/plugins/otptoken.py >>>index >>>5a5d35d153e7b3698aeebe1e93831b48a8b8f91e..ff92efa11776171b09993060e0805c8ffa6806da >>>100644 >>>--- a/ipalib/plugins/otptoken.py >>>+++ b/ipalib/plugins/otptoken.py >>>@@ -202,6 +202,15 @@ class otptoken_add(LDAPCreate): >>> ) >>> >>> def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, >>>**options): >>>+ # These are values we always want to write to LDAP. So if >>>they are >>>+ # specified as a value that evaluates to False (i.e. None), >>>delete them >>>+ # and fill in the defaults below. >>>+ for attr in ('ipatokentotpclockoffset', 'ipatokentotptimestep', >>>+ 'ipatokenotpalgorithm', 'ipatokenotpdigits', >>>+ 'ipatokenotpkey'): >>>+ if attr in entry_attrs and not entry_attrs[attr]: >>>+ del entry_attrs[attr] >>>+ >>> # Set defaults. This needs to happen on the server side >>>because we may >>> # have global configurable defaults in the near future. >>> options.setdefault('type', TOKEN_TYPES[0]) >>ACK. >> >> >>Since this patch rotted a bit, attaching rebased version. >> > >IMO we should not push this patch. > >Wasn't it superseded by: https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=21ff4f920e4ff7c1e2870024f007f067fc3cf6c8 >? I knew I missed one of patches when looking up. Thanks! This one can be ignored then. -- / Alexander Bokovoy From massimiliano.perrone at tirasa.net Mon Mar 24 11:35:48 2014 From: massimiliano.perrone at tirasa.net (Massimiliano Perrone (tirasa.net)) Date: Mon, 24 Mar 2014 12:35:48 +0100 Subject: [Freeipa-devel] Talking json/rpc with java client In-Reply-To: <532C6059.7060602@tirasa.net> References: <20140318091035.GA9052@redhat.com> <53281662.3030105@tirasa.net> <20140318102643.GC16644@redhat.com> <53286E45.4000605@tirasa.net> <20140318162607.GH16644@redhat.com> <532AB5BE.2070409@tirasa.net> <20140320103119.GO16644@redhat.com> <532ADF1F.8000002@redhat.com> <20140320124715.GP16644@redhat.com> <1395320952.26633.37.camel@willson.li.ssimo.org> <532C6059.7060602@tirasa.net> Message-ID: <53301894.6050403@tirasa.net> On 03/21/2014 04:52 PM, Massimiliano Perrone (tirasa.net) wrote: > On 03/20/2014 02:09 PM, Simo Sorce wrote: >> On Thu, 2014-03-20 at 14:47 +0200, Alexander Bokovoy wrote: >>> On Thu, 20 Mar 2014, Rob Crittenden wrote: >>>> Alexander Bokovoy wrote: >>>>> On Thu, 20 Mar 2014, Massimiliano Perrone (example.com) wrote: >>>>>> On 03/18/2014 05:26 PM, Alexander Bokovoy wrote: >>>>>>> On Tue, 18 Mar 2014, Massimiliano Perrone (example.com) wrote: >>>>>>>>>> The difference between the two calls is on the last TGS_REQ; >>>>>>>>>> because the first one is on ldap/olmo.example.com at EXAMPLE.COM >>>>>>>>>> and >>>>>>>>>> it's OK whereas the second one is on >>>>>>>>>> HTTP/olmo.example.com at EXAMPLE.COM that returns a 401 (I >>>>>>>>>> suppose). >>>>>>>>>> >>>>>>>>>> Where's the error? >>>>>>>>> Am I correct that you have a user connecting to >>>>>>>>> HTTP/ebano.example.com >>>>>>>>> and then HTTP/ebano.example.com wants to talk to >>>>>>>>> HTTP/olmo.example.com >>>>>>>>> using credentials of the user? >>>>>>>>> >>>>>>>>> FreeIPA uses constraint delegation of the credentials, with the >>>>>>>>> help of >>>>>>>>> S4U2Proxy extension. You need to allow HTTP/ebano.example.com to >>>>>>>>> delegate >>>>>>>>> credentials to HTTP/olmo.example.com. >>>>>>>>> >>>>>>>>> I have written an article how to do that: >>>>>>>>> https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Hi Alexander, thanks for your reply. >>>>>>>> I read carefully your interesting post and I follow it to delegate >>>>>>>> HTTP/ebano.example.com credentials to HTTP/olmo.example.com. >>>>>>>> >>>>>>>> Now, two questions: >>>>>>>> 1) How can I check that my configuration, now is ok? Because this >>>>>>>> ldapsearch returns result: 0 >>>>>>>> >>>>>>>> ldapsearch -Y GSSAPI -H ldap://olmo.example.com -b >>>>>>>> "cn=s4u2proxy,cn=etc,dc=example,dc=com" >>>>>>>> "cn=ipa-http-delegation-targets" dn >>>>>>> You need to create these delegation entries yourself, like the >>>>>>> article >>>>>>> says. Note that your app talks to IPA server's HTTP service, so >>>>>>> create >>>>>>> >>>>>>> dn: cn=ebano-http-delegation,cn=s4u2proxy,cn=etc,dc=example,dc=com >>>>>>> objectClass: ipaKrb5DelegationACL >>>>>>> objectClass: groupOfPrincipals >>>>>>> objectClass: top >>>>>>> cn: ebano-http-delegation >>>>>>> memberPrincipal: HTTP/ebano.example.com at EXAMPLE.COM >>>>>>> ipaAllowedTarget: >>>>>>> cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com >>>>>>> >>>>>>> >>>>>>> This entry says: "HTTP/ebano.example.com is allowed to delegate >>>>>>> users' >>>>>>> credentials to whatever Kerberos principal is a member of >>>>>>> cn=ebano-http-delegation-targets group" >>>>>>> >>>>>>> Now, this is the group: >>>>>>> dn: >>>>>>> cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com >>>>>>> >>>>>>> objectClass: groupOfPrincipals >>>>>>> objectClass: top >>>>>>> cn: ebano-http-delegation-targets >>>>>>> memberPrincipal: HTTP/olomo.example.com at EXAMPLE.COM >>>>>>> >>>>>>> With these two entries we would have HTTP/ebano.example.com >>>>>>> allowed to >>>>>>> delegate users' credentials to HTTP/olomo.example.com >>>>>> Hi Alexander, thanks for your patience. >>>>>> I followed your suggestions but the result is always the same. >>>>>> >>>>>> Trying with curl, of course, it works. >>>>>> >>>>>> My doubt now is why curl generates this log on kerberos server >>>>>> >>>>>> mar 20 10:22:20 olmo.example.com krb5kdc[5091](info): TGS_REQ (1 >>>>>> etypes {18}) 192.168.0.105: ISSUE: authtime 1395301975, etypes >>>>>> {rep=18 >>>>>> tkt=18 ses=18}, admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM >>>>>> mar 20 10:22:21 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 >>>>>> etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime >>>>>> 1395301975, >>>>>> etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for >>>>>> ldap/olmo.example.com at EXAMPLE.COM >>>>> This is effect of S4U extension working correctly. >>>>> >>>>>> whereas java generates this other one >>>>>> >>>>>> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 >>>>>> etypes >>>>>> {18 17 16 23}) 192.168.0.105: NEEDED_PREAUTH: >>>>>> HTTP/ebano.example.com at EXAMPLE.COM for >>>>>> krbtgt/EXAMPLE.COM at EXAMPLE.COM, >>>>>> Additional pre-authentication required >>>>>> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 >>>>>> etypes >>>>>> {18 17 16 23}) 192.168.0.105: ISSUE: authtime 1395307449, etypes >>>>>> {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for >>>>>> krbtgt/EXAMPLE.COM at EXAMPLE.COM >>>>>> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 >>>>>> etypes {18 17 16 23 1 3}) 192.168.0.105: ISSUE: authtime 1395307449, >>>>>> etypes {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM >>>>>> for >>>>>> HTTP/olmo.example.com at EXAMPLE.COM >>>>>> >>>>>> As you can see, the first one uses admin on ldap service, the second >>>>>> one uses HTTP/ebano.example.com on HTTP service. >>>>> This means your Java application doesn't use S4U extension or doesn't >>>>> know about that. >>>>> >>>>>> Can I do the same call with Java? >>>>> At this point we need to set clear what Java are you using. >>>>> >>>>> http://download.java.net/jdk8/docs/technotes/guides/security/jgss/jgss-features.html >>>>> >>>>> >>>>> tells that S4U extensions (we use S4U2Proxy here) was added in >>>>> Java SE 8. >>>>> >>>> The client doesn't do the S4U2Proxy work though, so this shouldn't >>>> matter, right? >>> My point is that the client will not do what he expects unless >>> S4U2Proxy >>> is used in Java and that requires Java 8 platform, released on March >>> 18th 2014. >> I think you can use earlier Java versions but tell them to use the >> native GSSAPI library (and perhaps sprinkle a little bit of GSS-Proxy in >> the back for fun. > > Here I'm again :) > > I wrote a GSSClient [1] obtaining: > ################################################### > java.io.IOException: Server returned HTTP response code: 401 for URL: > https://olmo.example.com/ipa/json > ################################################### > > Other info from kerberos client: > ################################################### > Ordering keys wrt default_tkt_enctypes list > Using builtin default etypes for default_tkt_enctypes > default etypes for default_tkt_enctypes: 18 17 16 23 1 3. > >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType > >>> KrbAsRep cons in KrbAsReq.getReply HTTP/ebano.example.com > principal is HTTP/ebano.example.com at EXAMPLE.COM > Will use keytab > Commit Succeeded > > Found ticket for HTTP/ebano.example.com at EXAMPLE.COM to go to > krbtgt/EXAMPLE.COM at EXAMPLE.COM expiring on Sat Mar 22 16:38:37 CET 2014 > Entered Krb5Context.initSecContext with state=STATE_NEW > Service ticket not found in the subject > <--------------------------------------------------------------- > >>> Credentials acquireServiceCreds: same realm > Using builtin default etypes for default_tgs_enctypes > default etypes for default_tgs_enctypes: 18 17 16 23 1 3. > >>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType > >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType > >>> KrbKdcReq send: kdc=olmo.example.com UDP:88, timeout=30000, number > of retries =3, #bytes=681 > >>> KDCCommunication: kdc=olmo.example.com UDP:88, > timeout=30000,Attempt =1, #bytes=681 > >>> KrbKdcReq send: #bytes read=642 > >>> KdcAccessibility: remove olmo.example.com > >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType > >>> KrbApReq: APOptions are 00100000 00000000 00000000 00000000 > >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType > Krb5Context setting mySeqNumber to: 1042307601 > Created InitSecContextToken: > 0000: 01 00 6E 82 02 4E 30 82 02 4A A0 03 02 01 05 A1 ..n..N0..J...... > 0010: 03 02 01 0E A2 07 03 05 00 20 00 00 00 A3 82 01 ......... ...... > 0020: 52 61 82 01 4E 30 82 01 4A A0 03 02 01 05 A1 0C Ra..N0..J....... > 0030: 1B 0A 54 49 52 41 53 41 2E 4E 45 54 A2 22 30 20 ..EXAMPLE.COM."0 > 0040: A0 03 02 01 01 A1 19 30 17 1B 04 6C 64 61 70 1B .......0...ldap. > 0050: 0F 6F 6C 6D 6F 2E 74 69 72 61 73 61 2E 6E 65 74 .olmo.example.com > 0060: A3 82 01 0F 30 82 01 0B A0 03 02 01 12 A1 03 02 ....0........... > 0070: 01 02 A2 81 FE 04 81 FB F9 8C FE 4F A0 4E 4B 34 ...........O.NK4 > 0080: BC 3D A7 E4 05 4E AC 91 58 58 9B 7C 18 72 7E 16 .=...N..XX...r.. > 0090: DA 4B 29 1F 52 D7 30 7A 9E FF 18 4C 68 9A 18 DF .K).R.0z...Lh... > 00A0: 66 03 F7 55 75 40 DC 38 AC 21 5B 7F C0 70 DB DD f..Uu at .8.![..p.. > 00B0: 37 63 7A E2 C4 89 E1 6A B9 29 6D 30 62 1E F1 3E 7cz....j.)m0b..> > 00C0: 18 B0 A7 FB 1C 43 F9 33 D6 61 57 D0 26 DA 9E AB .....C.3.aW.&... > 00D0: C7 04 3F D0 DC 36 0F 95 B9 AD 5B 1B 64 A8 59 21 ..?..6....[.d.Y! > 00E0: E6 32 47 43 49 EA F8 61 38 D6 52 0A 92 A9 78 5F .2GCI..a8.R...x_ > 00F0: F7 BE B6 AE B9 0A 47 51 31 44 0D 67 74 D6 E5 71 ......GQ1D.gt..q > 0100: CA 85 46 09 FE F1 4D 90 E5 7C 7A 26 22 7D 39 41 ..F...M...z&".9A > 0110: 03 2D AB 5A E5 48 26 E7 D5 4A 20 0B 67 54 91 15 .-.Z.H&..J .gT.. > 0120: 37 23 A3 68 4D 67 88 0D 9A 4D 01 FA 8A 30 B0 2F 7#.hMg...M...0./ > 0130: 57 6A 64 8E A5 7B 2E DB C1 93 07 0B 02 8A FC B7 Wjd............. > 0140: BB 6B FD BD 83 DA F7 72 E6 D6 F8 4B BA 06 E4 ED .k.....r...K.... > 0150: 20 C2 EA 53 F6 6F F8 BB 0F E4 EF B4 51 15 BB 13 ..S.o......Q... > 0160: EB 57 A4 10 F2 C1 36 0B B1 45 6C FA 38 36 9C F9 .W....6..El.86.. > 0170: E2 75 BC A4 81 DE 30 81 DB A0 03 02 01 12 A2 81 .u....0......... > 0180: D3 04 81 D0 D6 75 77 89 A0 B7 F9 26 64 04 D4 51 .....uw....&d..Q > 0190: DD 27 10 A3 B7 8F 1B 88 8C 20 4D A2 25 BF 3D 11 .'....... M.%.=. > 01A0: 36 B1 EA 3B C7 BF FE C4 20 42 12 3C 1D 60 CD DB 6..;.... B.<.`.. > 01B0: D7 CB 5B 58 25 6D B9 68 6D 32 9F 8C 90 D1 0B 18 ..[X%m.hm2...... > 01C0: 90 4D B4 90 8B 17 2A F5 C5 B2 17 AD A7 6A 1F 2C .M....*......j., > 01D0: FD BF 2E EA 9C 27 CC 73 68 9B E7 D1 59 99 9D 64 .....'.sh...Y..d > 01E0: 08 53 8F 03 88 3B DF 36 5B 24 DC A0 78 F6 DF 6C .S...;.6[$..x..l > 01F0: 3C CB FC 84 C9 6B 24 1B DD F0 6F E3 1F 01 CC 94 <....k$...o..... > 0200: 2B 40 F7 6C 8D 9A E8 20 05 0A 44 16 64 55 29 B2 + at .l... ..D.dU). > 0210: 48 CC 1E C7 B0 99 AE B0 91 87 B1 EB BC 6B F3 8D H............k.. > 0220: A9 1B 3C A1 65 97 91 8A B1 9A 25 CB 7B D8 11 99 ..<.e.....%..... > 0230: 91 E6 F0 2A AB 5D 21 DA C7 A5 CC AD FA 79 76 33 ...*.]!......yv3 > 0240: B8 7E ED 1C FE C0 3B 2E C5 9E 71 51 42 9C 0B 47 ......;...qQB..G > 0250: 5A 4F 05 DE ZO.. > ################################################### > > As you can see in the row indicated by the arrow there's: > Entered Krb5Context.initSecContext with state=STATE_NEW > Service ticket not found in the subject > <--------------------------------------------------------------- > Is this right? Hi guys, sorry for the noise... Maybe this informations can help us to understand the root cause of our problem. httpd access_log 192.168.0.176 - HTTP/ebano.tirasa.net at TIRASA.NET [24/Mar/2014:12:21:57 +0100] "POST /ipa/json HTTP/1.1" 500 272 httpd error_log [Mon Mar 24 12:21:57.971182 2014] [:error] [pid 24462] ipa: ERROR: 500 Internal Server Error: jsonserver_kerb.__call__: KRB5CCNAME not defined in HTTP request environment > > PS: next step is JAVA_8 installation to follow Alexander suggestions. > > [1] > https://github.com/massx1/KerberosExample/blob/master/src/main/java/net/tirasa/kerberosexample/GSSClient.java >> >>> That is, if there is a user talking to the Java client and >>> then Java client turning to IPA LDAP or web server with constraint >>> delegation. >>> >>> This is something I tried to get clarification for in the original >>> discussion. >>> >>> >> > > -- Massimiliano Perrone Tel +39 393 9121310 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~massi/ "L'apprendere molte cose non insegna l'intelligenza" (Eraclito) From massimiliano.perrone at tirasa.net Mon Mar 24 12:14:38 2014 From: massimiliano.perrone at tirasa.net (Massimiliano Perrone (tirasa.net)) Date: Mon, 24 Mar 2014 13:14:38 +0100 Subject: [Freeipa-devel] Talking json/rpc with java client In-Reply-To: <53301894.6050403@tirasa.net> References: <20140318091035.GA9052@redhat.com> <53281662.3030105@tirasa.net> <20140318102643.GC16644@redhat.com> <53286E45.4000605@tirasa.net> <20140318162607.GH16644@redhat.com> <532AB5BE.2070409@tirasa.net> <20140320103119.GO16644@redhat.com> <532ADF1F.8000002@redhat.com> <20140320124715.GP16644@redhat.com> <1395320952.26633.37.camel@willson.li.ssimo.org> <532C6059.7060602@tirasa.net> <53301894.6050403@tirasa.net> Message-ID: <533021AE.1060208@tirasa.net> On 03/24/2014 12:35 PM, Massimiliano Perrone (tirasa.net) wrote: > On 03/21/2014 04:52 PM, Massimiliano Perrone (tirasa.net) wrote: >> On 03/20/2014 02:09 PM, Simo Sorce wrote: >>> On Thu, 2014-03-20 at 14:47 +0200, Alexander Bokovoy wrote: >>>> On Thu, 20 Mar 2014, Rob Crittenden wrote: >>>>> Alexander Bokovoy wrote: >>>>>> On Thu, 20 Mar 2014, Massimiliano Perrone (example.com) wrote: >>>>>>> On 03/18/2014 05:26 PM, Alexander Bokovoy wrote: >>>>>>>> On Tue, 18 Mar 2014, Massimiliano Perrone (example.com) wrote: >>>>>>>>>>> The difference between the two calls is on the last TGS_REQ; >>>>>>>>>>> because the first one is on >>>>>>>>>>> ldap/olmo.example.com at EXAMPLE.COM and >>>>>>>>>>> it's OK whereas the second one is on >>>>>>>>>>> HTTP/olmo.example.com at EXAMPLE.COM that returns a 401 (I >>>>>>>>>>> suppose). >>>>>>>>>>> >>>>>>>>>>> Where's the error? >>>>>>>>>> Am I correct that you have a user connecting to >>>>>>>>>> HTTP/ebano.example.com >>>>>>>>>> and then HTTP/ebano.example.com wants to talk to >>>>>>>>>> HTTP/olmo.example.com >>>>>>>>>> using credentials of the user? >>>>>>>>>> >>>>>>>>>> FreeIPA uses constraint delegation of the credentials, with the >>>>>>>>>> help of >>>>>>>>>> S4U2Proxy extension. You need to allow HTTP/ebano.example.com to >>>>>>>>>> delegate >>>>>>>>>> credentials to HTTP/olmo.example.com. >>>>>>>>>> >>>>>>>>>> I have written an article how to do that: >>>>>>>>>> https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/index.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Hi Alexander, thanks for your reply. >>>>>>>>> I read carefully your interesting post and I follow it to >>>>>>>>> delegate >>>>>>>>> HTTP/ebano.example.com credentials to HTTP/olmo.example.com. >>>>>>>>> >>>>>>>>> Now, two questions: >>>>>>>>> 1) How can I check that my configuration, now is ok? Because this >>>>>>>>> ldapsearch returns result: 0 >>>>>>>>> >>>>>>>>> ldapsearch -Y GSSAPI -H ldap://olmo.example.com -b >>>>>>>>> "cn=s4u2proxy,cn=etc,dc=example,dc=com" >>>>>>>>> "cn=ipa-http-delegation-targets" dn >>>>>>>> You need to create these delegation entries yourself, like the >>>>>>>> article >>>>>>>> says. Note that your app talks to IPA server's HTTP service, so >>>>>>>> create >>>>>>>> >>>>>>>> dn: cn=ebano-http-delegation,cn=s4u2proxy,cn=etc,dc=example,dc=com >>>>>>>> objectClass: ipaKrb5DelegationACL >>>>>>>> objectClass: groupOfPrincipals >>>>>>>> objectClass: top >>>>>>>> cn: ebano-http-delegation >>>>>>>> memberPrincipal: HTTP/ebano.example.com at EXAMPLE.COM >>>>>>>> ipaAllowedTarget: >>>>>>>> cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com >>>>>>>> >>>>>>>> >>>>>>>> This entry says: "HTTP/ebano.example.com is allowed to delegate >>>>>>>> users' >>>>>>>> credentials to whatever Kerberos principal is a member of >>>>>>>> cn=ebano-http-delegation-targets group" >>>>>>>> >>>>>>>> Now, this is the group: >>>>>>>> dn: >>>>>>>> cn=ebano-http-delegation-targets,cn=s4u2proxy,cn=etc,dc=example,dc=com >>>>>>>> >>>>>>>> objectClass: groupOfPrincipals >>>>>>>> objectClass: top >>>>>>>> cn: ebano-http-delegation-targets >>>>>>>> memberPrincipal: HTTP/olomo.example.com at EXAMPLE.COM >>>>>>>> >>>>>>>> With these two entries we would have HTTP/ebano.example.com >>>>>>>> allowed to >>>>>>>> delegate users' credentials to HTTP/olomo.example.com >>>>>>> Hi Alexander, thanks for your patience. >>>>>>> I followed your suggestions but the result is always the same. >>>>>>> >>>>>>> Trying with curl, of course, it works. >>>>>>> >>>>>>> My doubt now is why curl generates this log on kerberos server >>>>>>> >>>>>>> mar 20 10:22:20 olmo.example.com krb5kdc[5091](info): TGS_REQ (1 >>>>>>> etypes {18}) 192.168.0.105: ISSUE: authtime 1395301975, etypes >>>>>>> {rep=18 >>>>>>> tkt=18 ses=18}, admin at EXAMPLE.COM for >>>>>>> krbtgt/EXAMPLE.COM at EXAMPLE.COM >>>>>>> mar 20 10:22:21 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 >>>>>>> etypes {18 17 16 23 25 26}) 192.168.0.106: ISSUE: authtime >>>>>>> 1395301975, >>>>>>> etypes {rep=18 tkt=18 ses=18}, admin at EXAMPLE.COM for >>>>>>> ldap/olmo.example.com at EXAMPLE.COM >>>>>> This is effect of S4U extension working correctly. >>>>>> >>>>>>> whereas java generates this other one >>>>>>> >>>>>>> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 >>>>>>> etypes >>>>>>> {18 17 16 23}) 192.168.0.105: NEEDED_PREAUTH: >>>>>>> HTTP/ebano.example.com at EXAMPLE.COM for >>>>>>> krbtgt/EXAMPLE.COM at EXAMPLE.COM, >>>>>>> Additional pre-authentication required >>>>>>> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): AS_REQ (4 >>>>>>> etypes >>>>>>> {18 17 16 23}) 192.168.0.105: ISSUE: authtime 1395307449, etypes >>>>>>> {rep=18 tkt=18 ses=18}, HTTP/ebano.example.com at EXAMPLE.COM for >>>>>>> krbtgt/EXAMPLE.COM at EXAMPLE.COM >>>>>>> mar 20 10:24:09 olmo.example.com krb5kdc[5091](info): TGS_REQ (6 >>>>>>> etypes {18 17 16 23 1 3}) 192.168.0.105: ISSUE: authtime >>>>>>> 1395307449, >>>>>>> etypes {rep=18 tkt=18 ses=18}, >>>>>>> HTTP/ebano.example.com at EXAMPLE.COM for >>>>>>> HTTP/olmo.example.com at EXAMPLE.COM >>>>>>> >>>>>>> As you can see, the first one uses admin on ldap service, the >>>>>>> second >>>>>>> one uses HTTP/ebano.example.com on HTTP service. >>>>>> This means your Java application doesn't use S4U extension or >>>>>> doesn't >>>>>> know about that. >>>>>> >>>>>>> Can I do the same call with Java? >>>>>> At this point we need to set clear what Java are you using. >>>>>> >>>>>> http://download.java.net/jdk8/docs/technotes/guides/security/jgss/jgss-features.html >>>>>> >>>>>> >>>>>> tells that S4U extensions (we use S4U2Proxy here) was added in >>>>>> Java SE 8. >>>>>> >>>>> The client doesn't do the S4U2Proxy work though, so this shouldn't >>>>> matter, right? >>>> My point is that the client will not do what he expects unless >>>> S4U2Proxy >>>> is used in Java and that requires Java 8 platform, released on March >>>> 18th 2014. >>> I think you can use earlier Java versions but tell them to use the >>> native GSSAPI library (and perhaps sprinkle a little bit of >>> GSS-Proxy in >>> the back for fun. >> >> Here I'm again :) >> >> I wrote a GSSClient [1] obtaining: >> ################################################### >> java.io.IOException: Server returned HTTP response code: 401 for URL: >> https://olmo.example.com/ipa/json >> ################################################### >> >> Other info from kerberos client: >> ################################################### >> Ordering keys wrt default_tkt_enctypes list >> Using builtin default etypes for default_tkt_enctypes >> default etypes for default_tkt_enctypes: 18 17 16 23 1 3. >> >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >> >>> KrbAsRep cons in KrbAsReq.getReply HTTP/ebano.example.com >> principal is HTTP/ebano.example.com at EXAMPLE.COM >> Will use keytab >> Commit Succeeded >> >> Found ticket for HTTP/ebano.example.com at EXAMPLE.COM to go to >> krbtgt/EXAMPLE.COM at EXAMPLE.COM expiring on Sat Mar 22 16:38:37 CET 2014 >> Entered Krb5Context.initSecContext with state=STATE_NEW >> Service ticket not found in the subject >> <--------------------------------------------------------------- >> >>> Credentials acquireServiceCreds: same realm >> Using builtin default etypes for default_tgs_enctypes >> default etypes for default_tgs_enctypes: 18 17 16 23 1 3. >> >>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType >> >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >> >>> KrbKdcReq send: kdc=olmo.example.com UDP:88, timeout=30000, >> number of retries =3, #bytes=681 >> >>> KDCCommunication: kdc=olmo.example.com UDP:88, >> timeout=30000,Attempt =1, #bytes=681 >> >>> KrbKdcReq send: #bytes read=642 >> >>> KdcAccessibility: remove olmo.example.com >> >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >> >>> KrbApReq: APOptions are 00100000 00000000 00000000 00000000 >> >>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType >> Krb5Context setting mySeqNumber to: 1042307601 >> Created InitSecContextToken: >> 0000: 01 00 6E 82 02 4E 30 82 02 4A A0 03 02 01 05 A1 ..n..N0..J...... >> 0010: 03 02 01 0E A2 07 03 05 00 20 00 00 00 A3 82 01 ......... ...... >> 0020: 52 61 82 01 4E 30 82 01 4A A0 03 02 01 05 A1 0C Ra..N0..J....... >> 0030: 1B 0A 54 49 52 41 53 41 2E 4E 45 54 A2 22 30 20 ..EXAMPLE.COM."0 >> 0040: A0 03 02 01 01 A1 19 30 17 1B 04 6C 64 61 70 1B .......0...ldap. >> 0050: 0F 6F 6C 6D 6F 2E 74 69 72 61 73 61 2E 6E 65 74 >> .olmo.example.com >> 0060: A3 82 01 0F 30 82 01 0B A0 03 02 01 12 A1 03 02 ....0........... >> 0070: 01 02 A2 81 FE 04 81 FB F9 8C FE 4F A0 4E 4B 34 ...........O.NK4 >> 0080: BC 3D A7 E4 05 4E AC 91 58 58 9B 7C 18 72 7E 16 .=...N..XX...r.. >> 0090: DA 4B 29 1F 52 D7 30 7A 9E FF 18 4C 68 9A 18 DF .K).R.0z...Lh... >> 00A0: 66 03 F7 55 75 40 DC 38 AC 21 5B 7F C0 70 DB DD f..Uu at .8.![..p.. >> 00B0: 37 63 7A E2 C4 89 E1 6A B9 29 6D 30 62 1E F1 3E 7cz....j.)m0b..> >> 00C0: 18 B0 A7 FB 1C 43 F9 33 D6 61 57 D0 26 DA 9E AB .....C.3.aW.&... >> 00D0: C7 04 3F D0 DC 36 0F 95 B9 AD 5B 1B 64 A8 59 21 ..?..6....[.d.Y! >> 00E0: E6 32 47 43 49 EA F8 61 38 D6 52 0A 92 A9 78 5F .2GCI..a8.R...x_ >> 00F0: F7 BE B6 AE B9 0A 47 51 31 44 0D 67 74 D6 E5 71 ......GQ1D.gt..q >> 0100: CA 85 46 09 FE F1 4D 90 E5 7C 7A 26 22 7D 39 41 ..F...M...z&".9A >> 0110: 03 2D AB 5A E5 48 26 E7 D5 4A 20 0B 67 54 91 15 .-.Z.H&..J .gT.. >> 0120: 37 23 A3 68 4D 67 88 0D 9A 4D 01 FA 8A 30 B0 2F 7#.hMg...M...0./ >> 0130: 57 6A 64 8E A5 7B 2E DB C1 93 07 0B 02 8A FC B7 Wjd............. >> 0140: BB 6B FD BD 83 DA F7 72 E6 D6 F8 4B BA 06 E4 ED .k.....r...K.... >> 0150: 20 C2 EA 53 F6 6F F8 BB 0F E4 EF B4 51 15 BB 13 ..S.o......Q... >> 0160: EB 57 A4 10 F2 C1 36 0B B1 45 6C FA 38 36 9C F9 .W....6..El.86.. >> 0170: E2 75 BC A4 81 DE 30 81 DB A0 03 02 01 12 A2 81 .u....0......... >> 0180: D3 04 81 D0 D6 75 77 89 A0 B7 F9 26 64 04 D4 51 .....uw....&d..Q >> 0190: DD 27 10 A3 B7 8F 1B 88 8C 20 4D A2 25 BF 3D 11 .'....... M.%.=. >> 01A0: 36 B1 EA 3B C7 BF FE C4 20 42 12 3C 1D 60 CD DB 6..;.... B.<.`.. >> 01B0: D7 CB 5B 58 25 6D B9 68 6D 32 9F 8C 90 D1 0B 18 ..[X%m.hm2...... >> 01C0: 90 4D B4 90 8B 17 2A F5 C5 B2 17 AD A7 6A 1F 2C .M....*......j., >> 01D0: FD BF 2E EA 9C 27 CC 73 68 9B E7 D1 59 99 9D 64 .....'.sh...Y..d >> 01E0: 08 53 8F 03 88 3B DF 36 5B 24 DC A0 78 F6 DF 6C .S...;.6[$..x..l >> 01F0: 3C CB FC 84 C9 6B 24 1B DD F0 6F E3 1F 01 CC 94 <....k$...o..... >> 0200: 2B 40 F7 6C 8D 9A E8 20 05 0A 44 16 64 55 29 B2 + at .l... >> ..D.dU). >> 0210: 48 CC 1E C7 B0 99 AE B0 91 87 B1 EB BC 6B F3 8D H............k.. >> 0220: A9 1B 3C A1 65 97 91 8A B1 9A 25 CB 7B D8 11 99 ..<.e.....%..... >> 0230: 91 E6 F0 2A AB 5D 21 DA C7 A5 CC AD FA 79 76 33 ...*.]!......yv3 >> 0240: B8 7E ED 1C FE C0 3B 2E C5 9E 71 51 42 9C 0B 47 ......;...qQB..G >> 0250: 5A 4F 05 DE ZO.. >> ################################################### >> >> As you can see in the row indicated by the arrow there's: >> Entered Krb5Context.initSecContext with state=STATE_NEW >> Service ticket not found in the subject >> <--------------------------------------------------------------- >> Is this right? > > Hi guys, sorry for the noise... > Maybe this informations can help us to understand the root cause of > our problem. > > httpd access_log > 192.168.0.176 - HTTP/ebano.tirasa.net at TIRASA.NET [24/Mar/2014:12:21:57 > +0100] "POST /ipa/json HTTP/1.1" 500 272 > httpd error_log > [Mon Mar 24 12:21:57.971182 2014] [:error] [pid 24462] ipa: ERROR: 500 > Internal Server Error: jsonserver_kerb.__call__: KRB5CCNAME not > defined in HTTP request environment Other question/information... I don't know if I'm saying something wrong but...... Reading [1] at line 980 I noticed that kinit method sets KRB5CCNAME variable def kinit (self, user, realm, password, ccache_name): 981 # Format the user as a kerberos principal 982 principal = krb5_format_principal_name (user , realm) 983 984 (stdout, stderr, returncode) = ipautil.run (['/usr/bin/kinit', principal], 985 env ={'KRB5CCNAME':ccache_name}, 986 stdin=password, raiseonerr=False) 987 self.debug('kinit: principal=%s returncode=%s, stderr="%s"', 988 principal, returncode, stderr) 989 990 if returncode != 0: 991 raise InvalidSessionPassword (principal=principal, message=unicode (stderr)) Is possible that LoginContext method of Java Kerberos libraries doesn't do the same thing? [1] http://www.freeipa.org/developer-docs/ipaserver.rpcserver-pysrc.html > > >> >> PS: next step is JAVA_8 installation to follow Alexander suggestions. >> >> [1] >> https://github.com/massx1/KerberosExample/blob/master/src/main/java/net/tirasa/kerberosexample/GSSClient.java >>> >>>> That is, if there is a user talking to the Java client and >>>> then Java client turning to IPA LDAP or web server with constraint >>>> delegation. >>>> >>>> This is something I tried to get clarification for in the original >>>> discussion. >>>> >>>> >>> >> >> > > -- Massimiliano Perrone Tel +39 393 9121310 Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.tirasa.net Apache Syncope PMC Member http://people.apache.org/~massi/ "L'apprendere molte cose non insegna l'intelligenza" (Eraclito) -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Mar 24 12:24:34 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 24 Mar 2014 14:24:34 +0200 Subject: [Freeipa-devel] Talking json/rpc with java client In-Reply-To: <533021AE.1060208@tirasa.net> References: <53286E45.4000605@tirasa.net> <20140318162607.GH16644@redhat.com> <532AB5BE.2070409@tirasa.net> <20140320103119.GO16644@redhat.com> <532ADF1F.8000002@redhat.com> <20140320124715.GP16644@redhat.com> <1395320952.26633.37.camel@willson.li.ssimo.org> <532C6059.7060602@tirasa.net> <53301894.6050403@tirasa.net> <533021AE.1060208@tirasa.net> Message-ID: <20140324122434.GF21211@redhat.com> On Mon, 24 Mar 2014, Massimiliano Perrone (tirasa.net) wrote: >>>As you can see in the row indicated by the arrow there's: >>>Entered Krb5Context.initSecContext with state=STATE_NEW >>>Service ticket not found in the subject >>><--------------------------------------------------------------- >>>Is this right? >> >>Hi guys, sorry for the noise... >>Maybe this informations can help us to understand the root cause of >>our problem. >> >>httpd access_log >>192.168.0.176 - HTTP/ebano.tirasa.net at TIRASA.NET >>[24/Mar/2014:12:21:57 +0100] "POST /ipa/json HTTP/1.1" 500 272 >>httpd error_log >>[Mon Mar 24 12:21:57.971182 2014] [:error] [pid 24462] ipa: ERROR: >>500 Internal Server Error: jsonserver_kerb.__call__: KRB5CCNAME not >>defined in HTTP request environment > >Other question/information... >I don't know if I'm saying something wrong but...... >Reading [1] at line 980 I noticed that kinit method sets KRB5CCNAME variable > [skip] > >Is possible that LoginContext method of Java Kerberos libraries >doesn't do the same thing? I don't think so. What the code above is not related. KRB5CCNAME is set by the mod_auth_kerb before handing over request processing to WSGI module. -- / Alexander Bokovoy From npmccallum at redhat.com Mon Mar 24 13:33:33 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 24 Mar 2014 09:33:33 -0400 Subject: [Freeipa-devel] [PATCHES] OTP Patches In-Reply-To: <20140319153749.GL16644@redhat.com> References: <20140213131253.GR8040@redhat.com> <20140217103204.GA16644@redhat.com> <20140219210150.GD16644@redhat.com> <20140219212558.GE16644@redhat.com> <20140220112706.GJ16644@redhat.com> <20140220123338.GK16644@redhat.com> <1392905964.1957.0.camel@localhost.localdomain> <1392922612.23210.3.camel@localhost.localdomain> <20140220220859.GR16644@redhat.com> <1392993378.23210.15.camel@localhost.localdomain> <20140319153749.GL16644@redhat.com> Message-ID: <1395668013.26874.0.camel@localhost.localdomain> On Wed, 2014-03-19 at 17:37 +0200, Alexander Bokovoy wrote: > On Fri, 21 Feb 2014, Nathaniel McCallum wrote: > >On Fri, 2014-02-21 at 00:08 +0200, Alexander Bokovoy wrote: > >> On Thu, 20 Feb 2014, Nathaniel McCallum wrote: > >> >> > >>There is an error in libotp's find() function which assumes that > >> >> > >>get_basedn() always returns non-NULL value. This is not true for at > >> >> > >>least cn=Directory Manager. > >> >> > >> > >> >> > >>Patch attached. > >> >> > >More fixes required, now that Thierry produced the fix for 389-ds ticket > >> >> > >47699 which allows to re-arrange schema-compat and ipa-pwd-extop > >> >> > >plugins. I'm getting crash in find() in libotp.c for internal search in > >> >> > >some other conditions but at least user dn now is the correct one. > >> >> > > > >> >> > >Stay tuned. > >> >> > OK, finally I've got it working -- my last patch had error which could > >> >> > be attributed to the late night time. > >> >> > > >> >> > New patch is attached to fix libotp to work properly with empty base dn > >> >> > (such as cn=Directory Manager). > >> >> > > >> >> > Also I'm attaching the patch that sets precedence of schema-compat > >> >> > plugin to 49 (less than default 50). With this patch and 389-ds with > >> >> > patch from ticket 47699 compat tree binds work with OTP. > >> >> > > >> >> > When updated 389-ds-base will be released, we'll need to add Requires: > >> >> > to our RPM spec to depend on it. Without the updated 389-ds-base compat > >> >> > tree binds will not work with OTP but the rest will be working fine. > >> >> > > >> >> > Finally, ACK to all OTP patches. > >> >> > >> >> ACK to both of these patches. > >> > > >> >I've merged the first patch here -- > >> >https://www.redhat.com/archives/freeipa-devel/2014-February/msg00341.html > >> > > >> >I just realized the second patch shouldn't be ACK'd until we have a new > >> >389DS release with the fix. When that happens, reissue this patch with > >> >an update versioned require. > >> No, it can be safely merged as 389DS will use default precedence (50) unless > >> the fix is there. So the worst we get is the same as now -- OTP binds > >> will not work over compat tree. And when 389DS will be upgraded, they > >> will start working after 389DS restart. > > > >But this patch doesn't actually do anything until we get the new version > >of 389DS. If we are ever going to add a versioned dependency on the new > >389DS for this feature, it should go in this patch. Otherwise, it is an > >ACK from me. > New 389-DS is in Fedora 20 updates stable and Rawhide already. > 389-ds-base-1.3.2.16-1.fc20. Also, selinux-policy 3.12.1-135 is now in > Fedora 20 updates testing, providing multiple policy enhancements that > make possible Apache process to work with kernel-based credentials > caches. > > Attached patch makes use of the new packages. ACK From jpazdziora at redhat.com Mon Mar 24 13:47:29 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 24 Mar 2014 14:47:29 +0100 Subject: [Freeipa-devel] [PATCH 0157] ipa-client-install: Configure sudo to use SSSD as data source In-Reply-To: <5314D6F9.6010008@redhat.com> References: <5314D6F9.6010008@redhat.com> Message-ID: <20140324134729.GI3872@redhat.com> On Mon, Mar 03, 2014 at 08:24:41PM +0100, Tomas Babej wrote: > Hi, > > Makes ipa-client-install configure SSSD as the data provider > for the sudo service by default. This behaviour can be disabled > by using --no-sudo flag. > > https://fedorahosted.org/freeipa/ticket/3358 Ack. Applied against ipa-client-3.0.0-37.el6.x86_64, tried without --no-sudo and sudo was added to sssd.conf's services list and sudoeers added to /etc/nsswitch.conf. Rerun with --uninstall and run again with the --no-sudo parameter, those settings were not longer there. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Mon Mar 24 13:57:30 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 24 Mar 2014 14:57:30 +0100 Subject: [Freeipa-devel] [PATCH 0157] ipa-client-install: Configure sudo to use SSSD as data source In-Reply-To: <20140324134729.GI3872@redhat.com> References: <5314D6F9.6010008@redhat.com> <20140324134729.GI3872@redhat.com> Message-ID: <533039CA.2060007@redhat.com> On 03/24/2014 02:47 PM, Jan Pazdziora wrote: > On Mon, Mar 03, 2014 at 08:24:41PM +0100, Tomas Babej wrote: >> Hi, >> >> Makes ipa-client-install configure SSSD as the data provider >> for the sudo service by default. This behaviour can be disabled >> by using --no-sudo flag. >> >> https://fedorahosted.org/freeipa/ticket/3358 > > Ack. > > Applied against ipa-client-3.0.0-37.el6.x86_64, tried without > --no-sudo and sudo was added to sssd.conf's services list and sudoeers > added to /etc/nsswitch.conf. > > Rerun with --uninstall and run again with the --no-sudo parameter, > those settings were not longer there. > Did you also do the functional test? To ack and push this ticket, following scenario needs to work: 1) IPA clients enroll against IPA server without --no-sudo 2) IPA client user logs in, types "sudo -l", gets all allowed commands (prerequisite is of course to have sudo commands defined on the IPA server) 3) IPA client reboots, IPA client user logs in, types "sudo -l", gets all allowed commands For 2) to work, NIS domain name must be set, nsswitch and SSSD changes must be done For 3) to work, related systemd service preserving NIS domain name setting needs to be enabled Martin From mkosek at redhat.com Mon Mar 24 14:07:09 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 24 Mar 2014 15:07:09 +0100 Subject: [Freeipa-devel] [PATCH] 564 webui-ci: fix test_rebuild_membership_hosts on server without DNS In-Reply-To: <532C49F0.9030100@redhat.com> References: <532C49F0.9030100@redhat.com> Message-ID: <53303C0D.5040403@redhat.com> On 03/21/2014 03:17 PM, Petr Vobornik wrote: > Host adder dialog differs on installations with and without DNS. > Previous test used values for adding hosts which were suitable only for IPA > servers installed with DNS. Thanks for the fix. It looks OK and should fix the CI failure I was seeing. ACK. Pushed to master. Martin From jpazdziora at redhat.com Mon Mar 24 14:27:37 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 24 Mar 2014 15:27:37 +0100 Subject: [Freeipa-devel] [PATCH 0157] ipa-client-install: Configure sudo to use SSSD as data source In-Reply-To: <533039CA.2060007@redhat.com> References: <5314D6F9.6010008@redhat.com> <20140324134729.GI3872@redhat.com> <533039CA.2060007@redhat.com> Message-ID: <20140324142737.GK3872@redhat.com> On Mon, Mar 24, 2014 at 02:57:30PM +0100, Martin Kosek wrote: > On 03/24/2014 02:47 PM, Jan Pazdziora wrote: > > On Mon, Mar 03, 2014 at 08:24:41PM +0100, Tomas Babej wrote: > >> Hi, > >> > >> Makes ipa-client-install configure SSSD as the data provider > >> for the sudo service by default. This behaviour can be disabled > >> by using --no-sudo flag. > >> > >> https://fedorahosted.org/freeipa/ticket/3358 > > > > Ack. > > > > Applied against ipa-client-3.0.0-37.el6.x86_64, tried without > > --no-sudo and sudo was added to sssd.conf's services list and sudoeers > > added to /etc/nsswitch.conf. > > > > Rerun with --uninstall and run again with the --no-sudo parameter, > > those settings were not longer there. > > > > Did you also do the functional test? No. I do not want to get dragged into the discussion of having the correct sssd and sudo and glibc versions and SELinux and stuff. The ticket explicitly talk about setting configuration in config files, which the patch does. > To ack and push this ticket, following > scenario needs to work: Consumption of those configuration changes is really different story, isn't it? > 1) IPA clients enroll against IPA server without --no-sudo > 2) IPA client user logs in, types "sudo -l", gets all allowed commands > (prerequisite is of course to have sudo commands defined on the IPA server) > 3) IPA client reboots, IPA client user logs in, types "sudo -l", gets all > allowed commands > > For 2) to work, NIS domain name must be set, nsswitch and SSSD changes must be done > > For 3) to work, related systemd service preserving NIS domain name setting > needs to be enabled With the commit message only talking about configuring sssd, I assume the NIS domain name mentioned in the ticket will be done by some other patch. To me, the patch does what is advertised in the commit message, and is in line with what the ticket asks to be done. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Mon Mar 24 14:35:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 24 Mar 2014 15:35:19 +0100 Subject: [Freeipa-devel] [PATCH 0157] ipa-client-install: Configure sudo to use SSSD as data source In-Reply-To: <20140324142737.GK3872@redhat.com> References: <5314D6F9.6010008@redhat.com> <20140324134729.GI3872@redhat.com> <533039CA.2060007@redhat.com> <20140324142737.GK3872@redhat.com> Message-ID: <533042A7.1030405@redhat.com> On 03/24/2014 03:27 PM, Jan Pazdziora wrote: > On Mon, Mar 24, 2014 at 02:57:30PM +0100, Martin Kosek wrote: >> On 03/24/2014 02:47 PM, Jan Pazdziora wrote: >>> On Mon, Mar 03, 2014 at 08:24:41PM +0100, Tomas Babej wrote: >>>> Hi, >>>> >>>> Makes ipa-client-install configure SSSD as the data provider >>>> for the sudo service by default. This behaviour can be disabled >>>> by using --no-sudo flag. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3358 >>> >>> Ack. >>> >>> Applied against ipa-client-3.0.0-37.el6.x86_64, tried without >>> --no-sudo and sudo was added to sssd.conf's services list and sudoeers >>> added to /etc/nsswitch.conf. >>> >>> Rerun with --uninstall and run again with the --no-sudo parameter, >>> those settings were not longer there. >>> >> >> Did you also do the functional test? > > No. I do not want to get dragged into the discussion of having the > correct sssd and sudo and glibc versions and SELinux and stuff. The > ticket explicitly talk about setting configuration in config files, > which the patch does. > >> To ack and push this ticket, following >> scenario needs to work: > > Consumption of those configuration changes is really different story, > isn't it? > >> 1) IPA clients enroll against IPA server without --no-sudo >> 2) IPA client user logs in, types "sudo -l", gets all allowed commands >> (prerequisite is of course to have sudo commands defined on the IPA server) >> 3) IPA client reboots, IPA client user logs in, types "sudo -l", gets all >> allowed commands >> >> For 2) to work, NIS domain name must be set, nsswitch and SSSD changes must be done >> >> For 3) to work, related systemd service preserving NIS domain name setting >> needs to be enabled > > With the commit message only talking about configuring sssd, I assume > the NIS domain name mentioned in the ticket will be done by some other > patch. > > To me, the patch does what is advertised in the commit message, and is > in line with what the ticket asks to be done. > To me, it is not. I see your point that the commit message does not promise that FreeIPA client sudo would work after this change, but as this is the sole purpose of https://fedorahosted.org/freeipa/ticket/3358 and these patches are the final "umbrella" patches, let us assume that. To sum it up, I would prefer to push all these related patches and close this ticket when it actually works. Thanks, Martin From mkosek at redhat.com Mon Mar 24 14:43:54 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 24 Mar 2014 15:43:54 +0100 Subject: [Freeipa-devel] [PATCHES] 0473-0477+0497 Managed permission updater, part 1 In-Reply-To: <53231FFE.8000606@redhat.com> References: <530DB78A.4040003@redhat.com> <53108B41.50700@redhat.com> <53109370.7010905@redhat.com> <53149B54.2050308@redhat.com> <53171D1D.2010408@redhat.com> <5319953E.708@redhat.com> <5321AC1A.70608@redhat.com> <53231FFE.8000606@redhat.com> Message-ID: <533044AA.7030802@redhat.com> On 03/14/2014 04:27 PM, Petr Viktorin wrote: > On 03/13/2014 02:01 PM, Petr Viktorin wrote: >> On 03/07/2014 10:45 AM, Martin Kosek wrote: >>> On 03/05/2014 01:48 PM, Petr Viktorin wrote: >>>> On 03/03/2014 04:10 PM, Petr Viktorin wrote: >>>>> On 02/28/2014 02:47 PM, Petr Viktorin wrote: >>>>>> On 02/28/2014 02:12 PM, Martin Kosek wrote: >>>>>>> On 02/26/2014 10:44 AM, Petr Viktorin wrote: >>>>>>>> Hello, >>>>>>>> Here are a few fixes/improvements, and the first part of a managed >>>>>>>> permission >>>>>>>> updater. >>>>>>>> >>>>>>>> The patches should go in this order but don't need to be >>>>>>>> ACKed/pushed >>>>>>>> all at once. >>>>>>>> >>>>>>>> >>>>>>>> Design: >>>>>>>> http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Part of the work for: https://fedorahosted.org/freeipa/ticket/3566 >>>>>>>> >>>>>>>> >>>>>>>> This part is a "preview" of sorts, to get the basic mechanism and >>>>>>>> the >>>>>>>> metadata >>>>>>>> format reviewed before I add all of the default read permissions. >>>>>>>> It implements the first section of "Default Permission Updater" in >>>>>>>> the design; >>>>>>>> "Replacing legacy default permissions" and "Removing the global >>>>>>>> anonymous read >>>>>>>> ACI" is left for later. >>>>>>>> Metadata is added for the netgroup plugin* for starters >>>> [...] >>>>>>>> >>>>>>> >>>>>>> 1) 476: Typo in test name: >>>>>>> >>>>>>> + desc='Search fo rnonexisting permission with ":" in the >>>>>>> name', >>>>>> >>>>>> Will fix. >>>> >>>> Fixed >>>> >>>>>>> 2) 477: do we want to log anything when permission is up to date? >>>>>>> >>>>>>> + try: >>>>>>> + ldap.update_entry(entry) >>>>>>> + except errors.EmptyModlist: >>>>>>> + return >>>>>> >>>>>> I don't think that's needed, after all that's the expected behavior in >>>>>> all but the first upgrade. >>>>>> But I'll be happy to add it if you think it would be better. >>>> >>>> I've added a DEBUG message here. >>>> >>>> [...] >>>>>>> 4) I have been quite resilient to the prefixes for the permissions, >>>>>>> but it >>>>>>> seems it is the easier possible approach to fix conflicts with user >>>>>>> permissions >>>>>>> without having to check that later for every upgrade or doing more >>>>>>> complex >>>>>>> stuff like multiple RDNs or different container for system and user >>>>>>> permissions. >>>>>>> >>>>>>> I am now just thinking about the prefixing. Now you use this name: >>>>>>> >>>>>>> ipa:Read Netgroups >>>>>>> >>>>>>> Would it be "nicer" to use: >>>>>>> >>>>>>> IPA:Read Netgroups >>>>>>> or >>>>>>> IPA: Read Netgroups >>>>>>> or even >>>>>>> [IPA] Read Netgroups >>>>>>> ? :-) >>>>>> >>>>>> Bikeshedding time! >>>>>> Everyone on the list, please chime in! >>>>> >>>>> Bikeshedding results from today's meeting: >>>>> >>>>> "ipa: " pviktori++ >>>>> "System: " mkosek++ simo+ ab++ >>>>> "Builtin: " simo++ pvo+ >>>>> "Default:" >>>>> >>>>> The winner is "System: ", so I'll go and change to that. >>>> >>>> Done. >>> >>> Thanks. The patch set looks good now, I just see that the update >>> process may >>> not be optimal After I run the upgrade second time, it still tries to >>> update >>> the ACI even though there was no change done to the permission object and >>> should thus raise errors.EmptyModlist and skip the ACI update: >>> >>> 2014-03-07T09:44:34Z INFO Updating managed permissions for netgroup >>> 2014-03-07T09:44:34Z INFO Updating managed permission: System: Read >>> Netgroups >>> 2014-03-07T09:44:34Z DEBUG Updating ACI for managed permission: >>> System: Read >>> Netgroups >>> 2014-03-07T09:44:34Z DEBUG Removing ACI u'(targetattr = "cn || >>> description || >>> hostcategory || ipaenabledflag || ipauniqueid || nisdomainname || >>> usercategory")(targetfilter = "(objectclass=ipanisnetgroup)")(version >>> 3.0;acl >>> "permission:System: Read Netgroups";allow (read,compare,search) userdn = >>> "ldap:///all";)' from >>> cn=ng,cn=alt,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >>> 2014-03-07T09:44:34Z DEBUG Adding ACI u'(targetattr = "cn || >>> description || >>> hostcategory || ipaenabledflag || ipauniqueid || nisdomainname || >>> usercategory")(targetfilter = "(objectclass=ipanisnetgroup)")(version >>> 3.0;acl >>> "permission:System: Read Netgroups";allow (read,compare,search) userdn = >>> "ldap:///all";)' to >>> cn=ng,cn=alt,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >>> 2014-03-07T09:44:34Z INFO No changes to ACI >>> 2014-03-07T09:44:34Z INFO Updating managed permission: System: Read >>> Netgroup >>> Membership >>> >>> Any idea what could cause this? >> >> Ah, you're right. The updater tried to remove the 'top' objectclass, >> since it found that in the permission but it wasn't in >> permission.object_class. >> I added 'top' to the list in a new patch. >> >> There was a minor conflict with master; I'm attaching the whole rebased >> patchset for convenience. > > Rebased again. > I see the last issue I found is fixed - works fine. ACK for all patches after you fix another VERSION file conflict. Thanks, Martin From mkosek at redhat.com Mon Mar 24 14:45:25 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 24 Mar 2014 15:45:25 +0100 Subject: [Freeipa-devel] [PATCH] 0498 permission plugin: Do not add the ipapermissionv2 for output In-Reply-To: <532720FC.7050003@redhat.com> References: <532720FC.7050003@redhat.com> Message-ID: <53304505.40807@redhat.com> On 03/17/2014 05:21 PM, Petr Viktorin wrote: > This fixes an extra objectclass being added to legacy permissions in > permission-{show,find} output. For the other attributes, we want to show what > would be there if the permission was upgraded, but for objectclass and flags we > want to show exactly what is in LDAP. > > https://fedorahosted.org/freeipa/ticket/4257 > > For all the tests to pass, apply this on top of my patch 0475 ACK. Pushed to master: 3dcad00b946e72733cccf279ec00b426d902c867 Martin From mkosek at redhat.com Mon Mar 24 16:06:41 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 24 Mar 2014 17:06:41 +0100 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <20140324114221.6ae6b214@unused-4-246.brq.redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> <20140321120032.23243622@unused-4-246.brq.redhat.com> <532C24AE.8090406@redhat.com> <532C2977.7070401@redhat.com> <532C2B3D.9010401@redhat.com> <20140324114221.6ae6b214@unused-4-246.brq.redhat.com> Message-ID: <53305811.20509@redhat.com> On 03/24/2014 11:42 AM, Misnyovszki Adam wrote: > On Fri, 21 Mar 2014 13:06:21 +0100 > Petr Viktorin wrote: > >> On 03/21/2014 12:58 PM, Martin Kosek wrote: >>> On 03/21/2014 12:38 PM, Petr Viktorin wrote: >>>> On 03/21/2014 12:00 PM, Misnyovszki Adam wrote: >>>>> On Fri, 21 Mar 2014 10:33:00 +0100 >>>>> Petr Viktorin wrote: >>>>> >>>>>> On 03/21/2014 10:29 AM, Petr Viktorin wrote: >>>>>>> On 03/20/2014 04:22 PM, Misnyovszki Adam wrote: >>>>>>>> On Thu, 20 Mar 2014 14:19:51 +0100 >>>>>>>> Misnyovszki Adam wrote: >>>>>>>> >>>>>>>>> On Fri, 14 Mar 2014 13:26:15 -0400 >>>>>>>>> Rob Crittenden wrote: >>>>>>>>> >>>>>>>>>> Misnyovszki Adam wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> automember-rebuild uses asynchronous 389 task, and returned >>>>>>>>>>> success even if the task didn't run. This patch fixes this >>>>>>>>>>> issue adding a --nowait parameter to 'ipa >>>>>>>>>>> automember-rebuild', defaulting to False, thus when the >>>>>>>>>>> script runs without it, it waits for the 'nstaskexitcode' >>>>>>>>>>> attribute, which means the task has finished, according to >>>>>>>>>>> http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Old usage can be enabled using --nowait. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4239 >>>>>>>>>>> >>>>>>>>>>> Request for comments: >>>>>>>>>>> - Should I add a parameter to specify the polling time? (now >>>>>>>>>>> 1ms) >>>>>>>>>>> - Should I add a parameter to specify the maximum polling >>>>>>>>>>> number? Now if something fails about creating the task, it >>>>>>>>>>> polls forever. >>>>>>>>>>> - Obviously, if these parameters should be added, there >>>>>>>>>>> should be a reasonable default for them (~ Required=False, >>>>>>>>>>> Default=X). >>>>>>>>>> >>>>>>>>>> I don't think you need a polling time, esp since this is >>>>>>>>>> hidden from the user, but I think that is probably too short >>>>>>>>>> and you may end up hammering the LDAP server. >>>>>>>>>> >>>>>>>>>> I also wonder if there should be some maximum wait time. I >>>>>>>>>> don't like loops that can never exit. I'm at a loss for what >>>>>>>>>> that time should be though. And we'd need to spell out that >>>>>>>>>> we gave up waiting, not that the task necessarily failed. So >>>>>>>>>> rather than having a polling time option, rename nowait into >>>>>>>>>> wait_for=20, so wait for 20 seconds. Or something like that. >>>>>>>>>> >>>>>>>>>> I'd suggest using get_entry since you already know the full >>>>>>>>>> DN and there is only ever one. It would make this much more >>>>>>>>>> readable. >>>>>>>>>> >>>>>>>>>> I wonder if some top-level documentation should be added to >>>>>>>>>> flesh this out some more. This does, for example, return >>>>>>>>>> False in one case. The meaning for that should be spelled >>>>>>>>>> out. >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> personally I would keep --no-wait, with a delay of 1 seconds, >>>>>>>>> and a maximum waiting time for 60 seconds. Questions is, do >>>>>>>>> we need to parameterize with other parameters(wait-for to the >>>>>>>>> maximum time, and/or poll-delay for the delay time, both not >>>>>>>>> required), or it is not a case which worth to develop? >>>>>>>>> Greets >>>>>>>>> Adam >>>>>>>> >>>>>>>> Hi, >>>>>>>> here are the corrections Petr asked, also the other patch >>>>>>>> conatins the plugin registration refactor. >>>>>>> >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> You forgot an alternate summary for the --no-wait case. (Make >>>>>>> sure to output the DN in this case, so it's possible to poll >>>>>>> for it.) >>>>>>> >>>>>>> >>>>>>> >>>>>>> Instead of `task['nstaskexitcode'][0]` please use >>>>>>> `task.single_value['nstaskexitcode']`. >>>> >>>> There's one more `task['nstaskexitcode'][0]`. (Perhaps putting it >>>> in a variable would be better?) >>>> >>>>>>> >>>>>>> Here: >>>>>>> >>>>>>> raise errors.DatabaseError( >>>>>>> desc=_("Automember rebuild membership task failed"), >>>>>>> info=_("nstaskexitcode = '%s'" % >>>>>>> str(task['nstaskexitcode'][0]))) >>>>>>> >>>>>>> there's no need to call str() on %'s argument. >>>>>>> Also, use natural language (like "Task exit code: %s"), >>>>>>> otherwise there's no need to mark the message for translation. >>>>>>> >>>>>>> >>>>>> >>>>>> And one more thing: Please bump the minor version in the VERSION >>>>>> file when API.txt changes. >>>>>> >>>>>> >>>>> >>>>> Hi, >>>>> everything is corrected! >>>>> Greets >>>>> Adam >>>>> >>>> >>>> Sorry for dragging this so long, but: >>>> The DN should not be a part of the summary, because that makes it >>>> hard to parse when using the API. It should be returned as a part >>>> of the result. To do that, you'd need to change the output type: >>>> >>>> has_output = output.standard_entry >>>> has_output_params = ( >>>> DNParam( >>>> 'dn', >>>> label=_('Task automember'), >>>> doc=_('DN of the started task'), >>>> ), >>>> ) >>>> >>>> and provide a dict in result, instead of True. (And with >>>> --no-wait, add the dn to that dict.) >>>> >>> >>> Do really want to use 'dn' for the DNParam? dn is already used for >>> standard entry DN when --all is used, right? "automembertaskdn" may >>> be better. >> >> Well, I think "DN of the added entry" is exactly what this is. >> >>> Also, "Task automember" label sounds strange to me, would >>> "Automember task DN" be better? >> >> I meant "Task DN", sorry for the thinko. >> >> > > One more thing, which came to my mind after reviewing the code for > myself once again, if the task fails with an exit code other than 0, > there is a DatabaseError raised, which is just fine. But in the info, > should I specify not only the exit code, but also the DN of the task, > or is it unnecessary? > Thanks > Adam DS tasks usually have the error in some of their attributes, so if there is such attribute, I would report what the error is. It is easier to use than having to run ldapsearch against the given DN. If there is not such attribute, providing the DN would be a good idea. Martin From npmccallum at redhat.com Mon Mar 24 17:38:29 2014 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 24 Mar 2014 13:38:29 -0400 Subject: [Freeipa-devel] OTP work, what's left? In-Reply-To: <20140323212657.GC3482@redhat.com> References: <20140323212657.GC3482@redhat.com> Message-ID: <1395682709.26874.1.camel@localhost.localdomain> On Sun, 2014-03-23 at 23:26 +0200, Alexander Bokovoy wrote: > Hi! > > I've updated my COPR repo with current git master versions of FreeIPA > and SSSD with few added patches on top that close OTP gaps (Nathaniel's > patch 0038 and Jakub Hrozek's patch for password changes). > > With these patches we currently lack following parts of the OTP work: > > - OTP sync client. Still in development, patches and approach need > additional review/discussion on the list > > - Password change in WebUI fails when OTP token exist for the user. More > detailed examination is needed, I'm getting ACIError. > > > http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ https://fedorahosted.org/freeipa/query?component=OTP&status=!closed That should be a list of the open bugs, including feature requests. Nathaniel From pviktori at redhat.com Tue Mar 25 09:23:56 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 25 Mar 2014 10:23:56 +0100 Subject: [Freeipa-devel] [PATCH] 0454 Test fixes In-Reply-To: <52E7C017.3090407@redhat.com> References: <52E11122.3060401@redhat.com> <52E7C017.3090407@redhat.com> Message-ID: <53314B2C.10705@redhat.com> On 01/28/2014 03:35 PM, Petr Viktorin wrote: > On 01/23/2014 01:54 PM, Petr Viktorin wrote: [...] >> Patch 454 changes the cert generation script for CA-less tests to use >> sequential serial numbers rather than random ones, to prevent collisions. > > This one is still useful though. Ping, could someone review this? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0454-CA-less-tests-Use-sequential-certificate-serial-numb.patch Type: text/x-patch Size: 1431 bytes Desc: not available URL: From sbose at redhat.com Tue Mar 25 10:47:25 2014 From: sbose at redhat.com (Sumit Bose) Date: Tue, 25 Mar 2014 11:47:25 +0100 Subject: [Freeipa-devel] [PATCH] extdom: do not return results from the wrong domain Message-ID: <20140325104725.GQ27091@localhost.localdomain> Hi, since get{grg|pwu}id() cannot be restricted to a certain domain we have to filter results from other domains after the call based on the full-qualified name of the returned object. This patch should fix https://fedorahosted.org/freeipa/ticket/4264 . bye, Sumit -------------- next part -------------- From 1d53cd249b6e1d80770d135190ff9845dad10cf2 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 25 Mar 2014 11:29:58 +0100 Subject: [PATCH] extdom: do not return results from the wrong domain Resolves: https://fedorahosted.org/freeipa/ticket/4264 --- .../ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c index 675fc368042373314e9416dcf7d5866cb8c9871e..025d37dc5eda05c8db43d4e8176fd7898ed32fe7 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c @@ -359,6 +359,9 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, if ((locat = strchr(pg_data->data.pwd.pw_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { if (strcasecmp(locat+1, domain_name) == 0 ) { locat[0] = 0; + } else { + ret = LDAP_NO_SUCH_OBJECT; + goto done; } } res->data.name.object_name = @@ -368,6 +371,9 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, if ((locat = strchr(pg_data->data.grp.gr_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { if (strcasecmp(locat+1, domain_name) == 0) { locat[0] = 0; + } else { + ret = LDAP_NO_SUCH_OBJECT; + goto done; } } res->data.name.object_name = @@ -408,6 +414,9 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, if ((locat = strchr(pg_data->data.pwd.pw_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { if (strcasecmp(locat+1, domain_name) == 0) { locat[0] = 0; + } else { + ret = LDAP_NO_SUCH_OBJECT; + goto done; } } res->data.user.user_name = @@ -428,6 +437,9 @@ int create_response(struct extdom_req *req, struct pwd_grp *pg_data, if ((locat = strchr(pg_data->data.grp.gr_name, SSSD_DOMAIN_SEPARATOR)) != NULL) { if (strcasecmp(locat+1, domain_name) == 0) { locat[0] = 0; + } else { + ret = LDAP_NO_SUCH_OBJECT; + goto done; } } res->data.group.group_name = -- 1.8.5.3 From pspacek at redhat.com Tue Mar 25 11:29:28 2014 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 25 Mar 2014 12:29:28 +0100 Subject: [Freeipa-devel] FYI: [dane] Digest Algorithm Agility discussion Message-ID: <53316898.3020103@redhat.com> Hello list, I think that crypto-folks could be interested in discussion on dane-list: http://www.ietf.org/mail-archive/web/dane/current/msg06599.html As usual, there are two sides in this discussion and some input from an expert could help... Thank you for your time! -- Petr^2 Spacek From pvoborni at redhat.com Tue Mar 25 11:49:24 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Mar 2014 12:49:24 +0100 Subject: [Freeipa-devel] [PATCH] 560 webui: rename domNode to dom_node In-Reply-To: <20140320165133.4ef44cdd@unused-4-246.brq.redhat.com> References: <5329B174.9060407@redhat.com> <20140320165133.4ef44cdd@unused-4-246.brq.redhat.com> Message-ID: <53316D44.80901@redhat.com> On 20.3.2014 16:51, Misnyovszki Adam wrote: > On Wed, 19 Mar 2014 16:02:12 +0100 > Petr Vobornik wrote: > >> - unites domNode and dom_node usage to dom_node > > Nack, > > install/ui/test/details_tests.js:236 > install/ui/test/details_tests.js:242 > > only finds element, because context(ie domNode) is undefined, so it > falls back to html, not the best idea > > install/ui/src/freeipa/widgets/App.js:55 > > not sure if this causes errors, but it's worth renaming for consistency > > Greets, > Adam > all fixed, patch attached. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0560-1-webui-rename-domNode-to-dom_node.patch Type: text/x-patch Size: 10376 bytes Desc: not available URL: From tbabej at redhat.com Tue Mar 25 12:42:45 2014 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 25 Mar 2014 13:42:45 +0100 Subject: [Freeipa-devel] [PATCH] extdom: do not return results from the wrong domain In-Reply-To: <20140325104725.GQ27091@localhost.localdomain> References: <20140325104725.GQ27091@localhost.localdomain> Message-ID: <533179C5.4070402@redhat.com> ACK, patch looks good code wise and resolves the issue. Tomas On 03/25/2014 11:47 AM, Sumit Bose wrote: > Hi, > > since get{grg|pwu}id() cannot be restricted to a certain domain we have > to filter results from other domains after the call based on the > full-qualified name of the returned object. This patch should fix > https://fedorahosted.org/freeipa/ticket/4264 . > > bye, > Sumit > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Tue Mar 25 13:04:58 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 25 Mar 2014 14:04:58 +0100 Subject: [Freeipa-devel] [PATCH] extdom: do not return results from the wrong domain In-Reply-To: <533179C5.4070402@redhat.com> References: <20140325104725.GQ27091@localhost.localdomain> <533179C5.4070402@redhat.com> Message-ID: <53317EFA.4020304@redhat.com> On 03/25/2014 01:42 PM, Tomas Babej wrote: > ACK, patch looks good code wise and resolves the issue. Pushed to: master: c885bc3e49b41490668ed8b62989d71ec1cadf34 ipa-3-3: 2ec7c50f3c475e5ffbf2f73968636c483c6503e7 > > Tomas > > On 03/25/2014 11:47 AM, Sumit Bose wrote: >> Hi, >> >> since get{grg|pwu}id() cannot be restricted to a certain domain we have >> to filter results from other domains after the call based on the >> full-qualified name of the returned object. This patch should fix >> https://fedorahosted.org/freeipa/ticket/4264 . -- Petr? From pviktori at redhat.com Tue Mar 25 13:08:35 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 25 Mar 2014 14:08:35 +0100 Subject: [Freeipa-devel] [PATCH] 464 Proxy PKI clone /ca/ee/ca/profileSubmit URI In-Reply-To: <20140323213515.GF3482@redhat.com> References: <532AA94E.3070906@redhat.com> <20140323213515.GF3482@redhat.com> Message-ID: <53317FD3.8040803@redhat.com> On 03/23/2014 10:35 PM, Alexander Bokovoy wrote: > On Thu, 20 Mar 2014, Martin Kosek wrote: >> PKI change done in ticket https://fedorahosted.org/pki/ticket/816 >> requires the PKI Clone's SSL Server certificate to be issued by >> it's associated PKI master. >> >> Allow this call on IPA master. >> >> https://fedorahosted.org/freeipa/ticket/4265 >> >> --- >> >> We will need this change in upcoming FreeIPA 3.3.5 which would be then >> needed >> both in F19 and F20 to make the F20 cloning work again. >> [...] > ACK, straightforward fix. > Pushed to: master: 6ecc4600e9370a637916360396f18699e4b7f59b ipa-3-3: 8e8a020f8d2476cca321349fa24db4bee95270d8 -- Petr? From pviktori at redhat.com Tue Mar 25 13:18:58 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 25 Mar 2014 14:18:58 +0100 Subject: [Freeipa-devel] [PATCHES] 0473-0477+0497 Managed permission updater, part 1 In-Reply-To: <533044AA.7030802@redhat.com> References: <530DB78A.4040003@redhat.com> <53108B41.50700@redhat.com> <53109370.7010905@redhat.com> <53149B54.2050308@redhat.com> <53171D1D.2010408@redhat.com> <5319953E.708@redhat.com> <5321AC1A.70608@redhat.com> <53231FFE.8000606@redhat.com> <533044AA.7030802@redhat.com> Message-ID: <53318242.6080208@redhat.com> On 03/24/2014 03:43 PM, Martin Kosek wrote: > On 03/14/2014 04:27 PM, Petr Viktorin wrote: >> On 03/13/2014 02:01 PM, Petr Viktorin wrote: >>> On 03/07/2014 10:45 AM, Martin Kosek wrote: >>>> On 03/05/2014 01:48 PM, Petr Viktorin wrote: >>>>> On 03/03/2014 04:10 PM, Petr Viktorin wrote: >>>>>> On 02/28/2014 02:47 PM, Petr Viktorin wrote: >>>>>>> On 02/28/2014 02:12 PM, Martin Kosek wrote: >>>>>>>> On 02/26/2014 10:44 AM, Petr Viktorin wrote: >>>>>>>>> Hello, >>>>>>>>> Here are a few fixes/improvements, and the first part of a managed >>>>>>>>> permission >>>>>>>>> updater. >>>>>>>>> >>>>>>>>> The patches should go in this order but don't need to be >>>>>>>>> ACKed/pushed >>>>>>>>> all at once. >>>>>>>>> >>>>>>>>> >>>>>>>>> Design: >>>>>>>>> http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Part of the work for: https://fedorahosted.org/freeipa/ticket/3566 >>>>>>>>> >>>>>>>>> >>>>>>>>> This part is a "preview" of sorts, to get the basic mechanism and >>>>>>>>> the >>>>>>>>> metadata >>>>>>>>> format reviewed before I add all of the default read permissions. >>>>>>>>> It implements the first section of "Default Permission Updater" in >>>>>>>>> the design; >>>>>>>>> "Replacing legacy default permissions" and "Removing the global >>>>>>>>> anonymous read >>>>>>>>> ACI" is left for later. >>>>>>>>> Metadata is added for the netgroup plugin* for starters >>>>> [...] >>>>>>>>> >>>>>>>> >>>>>>>> 1) 476: Typo in test name: >>>>>>>> >>>>>>>> + desc='Search fo rnonexisting permission with ":" in the >>>>>>>> name', >>>>>>> >>>>>>> Will fix. >>>>> >>>>> Fixed >>>>> >>>>>>>> 2) 477: do we want to log anything when permission is up to date? >>>>>>>> >>>>>>>> + try: >>>>>>>> + ldap.update_entry(entry) >>>>>>>> + except errors.EmptyModlist: >>>>>>>> + return >>>>>>> >>>>>>> I don't think that's needed, after all that's the expected behavior in >>>>>>> all but the first upgrade. >>>>>>> But I'll be happy to add it if you think it would be better. >>>>> >>>>> I've added a DEBUG message here. >>>>> >>>>> [...] >>>>>>>> 4) I have been quite resilient to the prefixes for the permissions, >>>>>>>> but it >>>>>>>> seems it is the easier possible approach to fix conflicts with user >>>>>>>> permissions >>>>>>>> without having to check that later for every upgrade or doing more >>>>>>>> complex >>>>>>>> stuff like multiple RDNs or different container for system and user >>>>>>>> permissions. >>>>>>>> >>>>>>>> I am now just thinking about the prefixing. Now you use this name: >>>>>>>> >>>>>>>> ipa:Read Netgroups >>>>>>>> >>>>>>>> Would it be "nicer" to use: >>>>>>>> >>>>>>>> IPA:Read Netgroups >>>>>>>> or >>>>>>>> IPA: Read Netgroups >>>>>>>> or even >>>>>>>> [IPA] Read Netgroups >>>>>>>> ? :-) >>>>>>> >>>>>>> Bikeshedding time! >>>>>>> Everyone on the list, please chime in! >>>>>> >>>>>> Bikeshedding results from today's meeting: >>>>>> >>>>>> "ipa: " pviktori++ >>>>>> "System: " mkosek++ simo+ ab++ >>>>>> "Builtin: " simo++ pvo+ >>>>>> "Default:" >>>>>> >>>>>> The winner is "System: ", so I'll go and change to that. >>>>> >>>>> Done. >>>> >>>> Thanks. The patch set looks good now, I just see that the update >>>> process may >>>> not be optimal After I run the upgrade second time, it still tries to >>>> update >>>> the ACI even though there was no change done to the permission object and >>>> should thus raise errors.EmptyModlist and skip the ACI update: >>>> >>>> 2014-03-07T09:44:34Z INFO Updating managed permissions for netgroup >>>> 2014-03-07T09:44:34Z INFO Updating managed permission: System: Read >>>> Netgroups >>>> 2014-03-07T09:44:34Z DEBUG Updating ACI for managed permission: >>>> System: Read >>>> Netgroups >>>> 2014-03-07T09:44:34Z DEBUG Removing ACI u'(targetattr = "cn || >>>> description || >>>> hostcategory || ipaenabledflag || ipauniqueid || nisdomainname || >>>> usercategory")(targetfilter = "(objectclass=ipanisnetgroup)")(version >>>> 3.0;acl >>>> "permission:System: Read Netgroups";allow (read,compare,search) userdn = >>>> "ldap:///all";)' from >>>> cn=ng,cn=alt,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >>>> 2014-03-07T09:44:34Z DEBUG Adding ACI u'(targetattr = "cn || >>>> description || >>>> hostcategory || ipaenabledflag || ipauniqueid || nisdomainname || >>>> usercategory")(targetfilter = "(objectclass=ipanisnetgroup)")(version >>>> 3.0;acl >>>> "permission:System: Read Netgroups";allow (read,compare,search) userdn = >>>> "ldap:///all";)' to >>>> cn=ng,cn=alt,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com >>>> 2014-03-07T09:44:34Z INFO No changes to ACI >>>> 2014-03-07T09:44:34Z INFO Updating managed permission: System: Read >>>> Netgroup >>>> Membership >>>> >>>> Any idea what could cause this? >>> >>> Ah, you're right. The updater tried to remove the 'top' objectclass, >>> since it found that in the permission but it wasn't in >>> permission.object_class. >>> I added 'top' to the list in a new patch. >>> >>> There was a minor conflict with master; I'm attaching the whole rebased >>> patchset for convenience. >> >> Rebased again. >> > > I see the last issue I found is fixed - works fine. ACK for all patches after > you fix another VERSION file conflict. > > Thanks, > Martin > Thank you for the review! Pushed to master: c5e61c85e626da61180f84bc80e294ab0eb3757a -- Petr? From pvoborni at redhat.com Tue Mar 25 13:31:15 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 25 Mar 2014 14:31:15 +0100 Subject: [Freeipa-devel] [PATCH]Extending user plugin with employeenumber field In-Reply-To: <20140321110051.1a50f943@unused-4-246.brq.redhat.com> References: <1796318445.1683710.1392993953023.JavaMail.zimbra@redhat.com> <53076B73.9020008@redhat.com> <20140321101355.06e5efaa@unused-4-246.brq.redhat.com> <20140321110051.1a50f943@unused-4-246.brq.redhat.com> Message-ID: <53318523.7000601@redhat.com> On 21.3.2014 11:00, Misnyovszki Adam wrote: > On Fri, 21 Mar 2014 10:13:55 +0100 > Misnyovszki Adam wrote: > >> On Fri, 21 Feb 2014 16:06:27 +0100 >> Petr Vobornik wrote: >> >>> On 21.2.2014 15:45, Adam Misnyovszki wrote: >>>> Hi, >>>> According to http://tools.ietf.org/html/rfc2798 ipa client and web >>>> ui extended with employeenumber field. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4165 >>>> >>>> Question is, that should we extend user with other fields which >>>> are in the RFC, (carLicense, departmentNumber, employeeType, etc) >>>> if we already touched this code? >>>> >>>> Thanks >>>> Adam >>>> >>> >>> >>> + Int('employeenumber?', >>> + label=_('Employee ID'), >>> + minvalue=1, >>> + ), >>> >>> >>> Why Int and different label? IMO it should be Str and 'Employee >>> Number' >>> >>> 2.4. Employee Number >>> >>> Numeric or alphanumeric identifier assigned to a person, >>> typically based on order of hire or association with an >>> organization. Single valued. >>> >>> ( 2.16.840.1.113730.3.1.3 >>> NAME 'employeeNumber' >>> DESC 'numerically identifies an employee within an >>> organization' EQUALITY caseIgnoreMatch >>> SUBSTR caseIgnoreSubstringsMatch >>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 >>> SINGLE-VALUE ) >>> >> Hi, >> fixed, also some other fields added. Note, that according to the rfc, >> licence plate field should be multivalue, should I cange that(it is an >> existing field). yes >> Also, should I write test cases(especially for >> preferredlanguage)? Testing new functionality helps. >> Greets >> Adam > > self NACK, > VERSION bump because API change It requires another rebase. > > Greets > Adam > 1) Is there a reason to have label 'Employee ID' instead of 'Employee Number' which is in RFC 2798? + label=_('Employee ID'), 2) Department number seems to be multivalued as well: ( 2.16.840.1.113730.3.1.2 NAME 'departmentNumber' DESC 'identifies a department within an organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 3) The regex for preferredlanguage: + pattern='^[a-zA-Z]{1,8}[-[a-zA-Z]{1,8}]?$', doesn't match the expression in RFC 2068. It's only part of it. Accept-Language = "Accept-Language" ":" 1#( language-range [ ";" "q" "=" qvalue ] ) language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) http://tools.ietf.org/html/rfc2068#section-14.4 RFC 2798 ( http://tools.ietf.org/html/rfc2798#section-2.7 ) says that you should omit only the `"Accept-Language" ":"` sequence. -- Petr Vobornik From jcholast at redhat.com Tue Mar 25 14:05:20 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Mar 2014 15:05:20 +0100 Subject: [Freeipa-devel] [PATCHES] 172-196 Refactor certificate renewal code In-Reply-To: <532BFC4D.4090101@redhat.com> References: <525FD641.20202@redhat.com> <526009D7.2040702@redhat.com> <5260175E.50809@redhat.com> <531DAA0F.9080300@redhat.com> <5320AE9B.6040303@redhat.com> <5321A77B.3090003@redhat.com> <53299C98.2090308@redhat.com> <532BFC4D.4090101@redhat.com> Message-ID: <53318D20.9090602@redhat.com> On 21.3.2014 09:46, Petr Viktorin wrote: > On 03/19/2014 02:33 PM, Jan Cholasta wrote: >> On 13.3.2014 13:41, Jan Cholasta wrote: >>> On 12.3.2014 19:59, Petr Viktorin wrote: >>>> Certmonger is not configured/started in CA-less installs. >>> >>> That's expected. >>> >>>> >>>> I tested fresh installs and upgrades; renewals work fine for me. >>>> >>>> 161-184 look OK >>>> >>>> 185: one more nitpick: >>>> cert = entry['usercertificate'][0] >>>> Shouldn't that use entry.single_value? >>> >>> I did not feel like changing this, because this is used in the original >>> code and the userCertificate LDAP attribute is multi-value. > > Could you add a comment saying we don't care which of the certificates > is returned? For me `entry[...][0]` is a red flag, since the order > usually stays the same but it's not guaranteed, so it can change in the > worst moment. If nothing else we shouldn't be leaving it in the code as > an example of ipaldap usage. After some consideration I have decided to use single_value after all, because the only way that multiple values could get in the attribute is that someone deliberately put them in there. > >>> >>>> >>>> 186-189 look OK >>>> >>>> 190: Is >>>> fqdn = entries[0].dn[1].value >>>> return api.env.host == fqdn >>>> safe? Can they differ in case, for example? >>> >>> I guess so, will fix. >>> >>>> >>>> 191-196 look OK >>>> >>>>> Note that patches 178 & 179 were already pushed. Also, patch 190 was >>>>> changed to store information about which CA instance is master in >>>>> LDAP. >> >> Updated patches attached. >> >> Note that I changed the path for CSR export to /var/lib/ipa/ca.csr to >> make it more SELinux-friendly (not in the policy yet, see >> ). >> Updated patches attached. Note I have also updated the CA master in LDAP code. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-172.3-Move-CACERT-definition-to-a-single-place.patch Type: text/x-patch Size: 13423 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-173.3-Do-not-create-CA-certificate-files-in-CA-less-server.patch Type: text/x-patch Size: 1928 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-174.3-Use-LDAP-API-to-upload-CA-certificate-instead-of-lda.patch Type: text/x-patch Size: 2811 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-175.3-Upload-CA-certificate-from-DS-NSS-database-in-CA-les.patch Type: text/x-patch Size: 3169 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-176.3-Remove-unused-method-export_ca_cert-of-dsinstance.patch Type: text/x-patch Size: 979 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-177.3-Show-progress-when-enabling-SSL-in-DS-in-ipa-server-.patch Type: text/x-patch Size: 3276 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-180.3-Use-certmonger-D-Bus-API-to-configure-certmonger-in-.patch Type: text/x-patch Size: 4923 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-181.3-Add-new-certmonger-CA-helper-dogtag-ipa-ca-renew-age.patch Type: text/x-patch Size: 4170 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-182.3-Update-pkcs10-module-functions-to-always-load-CSRs-a.patch Type: text/x-patch Size: 5484 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-183.3-Remove-unused-function-get_subjectaltname-from-the-c.patch Type: text/x-patch Size: 1324 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-184.3-Add-function-for-parsing-friendly-name-from-certific.patch Type: text/x-patch Size: 2869 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-185.3-Support-retrieving-renewed-certificates-from-LDAP-in.patch Type: text/x-patch Size: 3525 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-186.3-Use-dogtag-ipa-ca-renew-agent-to-retrieve-renewed-ce.patch Type: text/x-patch Size: 5177 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-187.3-Remove-dogtag-ipa-retrieve-agent-submit.patch Type: text/x-patch Size: 4906 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-188.3-Support-storing-renewed-certificates-to-LDAP-in-dogt.patch Type: text/x-patch Size: 5516 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-189.3-Use-dogtag-ipa-ca-renew-agent-to-track-certificates-.patch Type: text/x-patch Size: 13042 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-190.3-Store-information-about-which-CA-server-is-master-fo.patch Type: text/x-patch Size: 6668 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-191.3-Make-the-default-dogtag-ipa-ca-renew-agent-behavior-.patch Type: text/x-patch Size: 2866 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-192.3-Merge-restart_pkicad-functionality-to-renew_ca_cert-.patch Type: text/x-patch Size: 7785 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-193.3-Merge-restart_httpd-functionality-to-renew_ra_cert.patch Type: text/x-patch Size: 2246 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-194.3-Use-the-same-certmonger-configuration-for-both-CA-ma.patch Type: text/x-patch Size: 9618 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-195.3-Update-certmonger-configuration-in-ipa-upgradeconfig.patch Type: text/x-patch Size: 7235 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-196.3-Support-exporting-CSRs-in-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 1745 bytes Desc: not available URL: From jcholast at redhat.com Tue Mar 25 14:44:32 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Mar 2014 15:44:32 +0100 Subject: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal Message-ID: <53319650.4000303@redhat.com> Hi, the attached patches implement automatic CA certificate renewal as well as the initial version of the CA certificate management tool. Requires my patches 172-196. In order to test, you must install current git version of certmonger (see ) and set SELinux to permissive (see ). Make sure you install certmonger before running ipa-server-install/ipa-replica-install. On F20 you can use RPMs located at . To test automatic renewal, move system time forward (see for more info about certificate renewal testing, nickname of the CA certificate is "caSigningCert cert-pki-ca"). In CA-full installs the renewal should be fully automatic, in CA-less installs you should be alerted via syslog to renew the certificate using ipa-cacert-manage. To test manual renewal, run "ipa-cacert-manage renew". You can run it on any CA master. To make the renewed certificate available on other CA masters, you must run "getcert resubmit -d /etc/pki/pki-tomcat/alias -n 'caSigningCert cert-pki-ca'" on each of them. Note that currently you can't change the chaining of the CA certificate. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-241-Add-function-for-checking-if-certificate-is-self-sig.patch Type: text/x-patch Size: 897 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-242-Support-CA-certificate-renewal-in-dogtag-ipa-ca-rene.patch Type: text/x-patch Size: 2619 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-243-Allow-IPA-master-hosts-to-update-CA-certificate-in-L.patch Type: text/x-patch Size: 1130 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-244-Automatically-update-CA-certificate-in-LDAP-on-renew.patch Type: text/x-patch Size: 2304 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-245-Track-CA-certificate-using-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 5096 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-246-Add-method-for-setting-CA-renewal-master-in-LDAP-to-.patch Type: text/x-patch Size: 1594 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-247-Provide-additional-functions-to-ipapython.certmonger.patch Type: text/x-patch Size: 1791 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-248-Move-external-cert-validation-from-ipa-server-instal.patch Type: text/x-patch Size: 6022 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-249-Add-method-for-verifying-CA-certificates-to-NSSDatab.patch Type: text/x-patch Size: 1646 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-250-Add-permissions-for-CA-certificate-renewal.patch Type: text/x-patch Size: 2917 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-251-Add-CA-certificate-management-tool-ipa-cacert-manage.patch Type: text/x-patch Size: 16475 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-252-Alert-user-when-externally-signed-CA-is-about-to-exp.patch Type: text/x-patch Size: 1717 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-253-Load-sysupgrade.state-on-demand.patch Type: text/x-patch Size: 1349 bytes Desc: not available URL: From pviktori at redhat.com Tue Mar 25 15:07:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 25 Mar 2014 16:07:14 +0100 Subject: [Freeipa-devel] [PATCHES] 172-196 Refactor certificate renewal code In-Reply-To: <53318D20.9090602@redhat.com> References: <525FD641.20202@redhat.com> <526009D7.2040702@redhat.com> <5260175E.50809@redhat.com> <531DAA0F.9080300@redhat.com> <5320AE9B.6040303@redhat.com> <5321A77B.3090003@redhat.com> <53299C98.2090308@redhat.com> <532BFC4D.4090101@redhat.com> <53318D20.9090602@redhat.com> Message-ID: <53319BA2.1040303@redhat.com> On 03/25/2014 03:05 PM, Jan Cholasta wrote: > On 21.3.2014 09:46, Petr Viktorin wrote: >> On 03/19/2014 02:33 PM, Jan Cholasta wrote: [...] >>> >>> Updated patches attached. >>> >>> Note that I changed the path for CSR export to /var/lib/ipa/ca.csr to >>> make it more SELinux-friendly (not in the policy yet, see >>> ). >>> > > Updated patches attached. > > Note I have also updated the CA master in LDAP code. > Looks better! In patch 190, AFAICS the original CAInstance.is_master is now not used anywhere, and its uses were always renewal-related. Is it safe to remove it? -- Petr? From amisnyov at redhat.com Tue Mar 25 14:36:25 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Tue, 25 Mar 2014 15:36:25 +0100 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <53305811.20509@redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> <20140321120032.23243622@unused-4-246.brq.redhat.com> <532C24AE.8090406@redhat.com> <532C2977.7070401@redhat.com> <532C2B3D.9010401@redhat.com> <20140324114221.6ae6b214@unused-4-246.brq.redhat.com> <53305811.20509@redhat.com> Message-ID: <20140325153625.1d6f1187@unused-4-246.brq.redhat.com> On Mon, 24 Mar 2014 17:06:41 +0100 Martin Kosek wrote: > On 03/24/2014 11:42 AM, Misnyovszki Adam wrote: > > On Fri, 21 Mar 2014 13:06:21 +0100 > > Petr Viktorin wrote: > > > >> On 03/21/2014 12:58 PM, Martin Kosek wrote: > >>> On 03/21/2014 12:38 PM, Petr Viktorin wrote: > >>>> On 03/21/2014 12:00 PM, Misnyovszki Adam wrote: > >>>>> On Fri, 21 Mar 2014 10:33:00 +0100 > >>>>> Petr Viktorin wrote: > >>>>> > >>>>>> On 03/21/2014 10:29 AM, Petr Viktorin wrote: > >>>>>>> On 03/20/2014 04:22 PM, Misnyovszki Adam wrote: > >>>>>>>> On Thu, 20 Mar 2014 14:19:51 +0100 > >>>>>>>> Misnyovszki Adam wrote: > >>>>>>>> > >>>>>>>>> On Fri, 14 Mar 2014 13:26:15 -0400 > >>>>>>>>> Rob Crittenden wrote: > >>>>>>>>> > >>>>>>>>>> Misnyovszki Adam wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> automember-rebuild uses asynchronous 389 task, and > >>>>>>>>>>> returned success even if the task didn't run. This patch > >>>>>>>>>>> fixes this issue adding a --nowait parameter to 'ipa > >>>>>>>>>>> automember-rebuild', defaulting to False, thus when the > >>>>>>>>>>> script runs without it, it waits for the 'nstaskexitcode' > >>>>>>>>>>> attribute, which means the task has finished, according to > >>>>>>>>>>> http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Old usage can be enabled using --nowait. > >>>>>>>>>>> > >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4239 > >>>>>>>>>>> > >>>>>>>>>>> Request for comments: > >>>>>>>>>>> - Should I add a parameter to specify the polling time? > >>>>>>>>>>> (now 1ms) > >>>>>>>>>>> - Should I add a parameter to specify the maximum polling > >>>>>>>>>>> number? Now if something fails about creating the task, it > >>>>>>>>>>> polls forever. > >>>>>>>>>>> - Obviously, if these parameters should be added, there > >>>>>>>>>>> should be a reasonable default for them (~ Required=False, > >>>>>>>>>>> Default=X). > >>>>>>>>>> > >>>>>>>>>> I don't think you need a polling time, esp since this is > >>>>>>>>>> hidden from the user, but I think that is probably too > >>>>>>>>>> short and you may end up hammering the LDAP server. > >>>>>>>>>> > >>>>>>>>>> I also wonder if there should be some maximum wait time. I > >>>>>>>>>> don't like loops that can never exit. I'm at a loss for > >>>>>>>>>> what that time should be though. And we'd need to spell > >>>>>>>>>> out that we gave up waiting, not that the task necessarily > >>>>>>>>>> failed. So rather than having a polling time option, > >>>>>>>>>> rename nowait into wait_for=20, so wait for 20 seconds. Or > >>>>>>>>>> something like that. > >>>>>>>>>> > >>>>>>>>>> I'd suggest using get_entry since you already know the full > >>>>>>>>>> DN and there is only ever one. It would make this much more > >>>>>>>>>> readable. > >>>>>>>>>> > >>>>>>>>>> I wonder if some top-level documentation should be added to > >>>>>>>>>> flesh this out some more. This does, for example, return > >>>>>>>>>> False in one case. The meaning for that should be spelled > >>>>>>>>>> out. > >>>>>>>>>> > >>>>>>>>>> rob > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> personally I would keep --no-wait, with a delay of 1 > >>>>>>>>> seconds, and a maximum waiting time for 60 seconds. > >>>>>>>>> Questions is, do we need to parameterize with other > >>>>>>>>> parameters(wait-for to the maximum time, and/or poll-delay > >>>>>>>>> for the delay time, both not required), or it is not a case > >>>>>>>>> which worth to develop? Greets > >>>>>>>>> Adam > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> here are the corrections Petr asked, also the other patch > >>>>>>>> conatins the plugin registration refactor. > >>>>>>> > >>>>>>> > >>>>>>> Thanks! > >>>>>>> > >>>>>>> You forgot an alternate summary for the --no-wait case. (Make > >>>>>>> sure to output the DN in this case, so it's possible to poll > >>>>>>> for it.) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Instead of `task['nstaskexitcode'][0]` please use > >>>>>>> `task.single_value['nstaskexitcode']`. > >>>> > >>>> There's one more `task['nstaskexitcode'][0]`. (Perhaps putting it > >>>> in a variable would be better?) > >>>> > >>>>>>> > >>>>>>> Here: > >>>>>>> > >>>>>>> raise errors.DatabaseError( > >>>>>>> desc=_("Automember rebuild membership task failed"), > >>>>>>> info=_("nstaskexitcode = '%s'" % > >>>>>>> str(task['nstaskexitcode'][0]))) > >>>>>>> > >>>>>>> there's no need to call str() on %'s argument. > >>>>>>> Also, use natural language (like "Task exit code: %s"), > >>>>>>> otherwise there's no need to mark the message for translation. > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> And one more thing: Please bump the minor version in the > >>>>>> VERSION file when API.txt changes. > >>>>>> > >>>>>> > >>>>> > >>>>> Hi, > >>>>> everything is corrected! > >>>>> Greets > >>>>> Adam > >>>>> > >>>> > >>>> Sorry for dragging this so long, but: > >>>> The DN should not be a part of the summary, because that makes it > >>>> hard to parse when using the API. It should be returned as a part > >>>> of the result. To do that, you'd need to change the output type: > >>>> > >>>> has_output = output.standard_entry > >>>> has_output_params = ( > >>>> DNParam( > >>>> 'dn', > >>>> label=_('Task automember'), > >>>> doc=_('DN of the started task'), > >>>> ), > >>>> ) > >>>> > >>>> and provide a dict in result, instead of True. (And with > >>>> --no-wait, add the dn to that dict.) > >>>> > >>> > >>> Do really want to use 'dn' for the DNParam? dn is already used for > >>> standard entry DN when --all is used, right? "automembertaskdn" > >>> may be better. > >> > >> Well, I think "DN of the added entry" is exactly what this is. > >> > >>> Also, "Task automember" label sounds strange to me, would > >>> "Automember task DN" be better? > >> > >> I meant "Task DN", sorry for the thinko. > >> > >> > > > > One more thing, which came to my mind after reviewing the code for > > myself once again, if the task fails with an exit code other than 0, > > there is a DatabaseError raised, which is just fine. But in the > > info, should I specify not only the exit code, but also the DN of > > the task, or is it unnecessary? > > Thanks > > Adam > > DS tasks usually have the error in some of their attributes, so if > there is such attribute, I would report what the error is. It is > easier to use than having to run ldapsearch against the given DN. > > If there is not such attribute, providing the DN would be a good idea. > > Martin Hi, fixed the output parameter issue, and also with that, API is updated. If an error occurs, now the function returns the nstaskstatus attribute, and the DN of the failed task. Also, I added a 3600 second ttl to the task, because the original was a few seconds(I haven't found the default value for that anywhere), to ensure that the task doesn't disappear before interaction is required. Attached the refactor of plugin registration patch also. Greets Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0008-plugin-registration-refactoring-for-automembership.patch Type: text/x-patch Size: 4966 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0007-5-automember-rebuild-nowait-feature-added.patch Type: text/x-patch Size: 5931 bytes Desc: not available URL: From jcholast at redhat.com Tue Mar 25 15:12:35 2014 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 25 Mar 2014 16:12:35 +0100 Subject: [Freeipa-devel] [PATCHES] 172-196 Refactor certificate renewal code In-Reply-To: <53319BA2.1040303@redhat.com> References: <525FD641.20202@redhat.com> <526009D7.2040702@redhat.com> <5260175E.50809@redhat.com> <531DAA0F.9080300@redhat.com> <5320AE9B.6040303@redhat.com> <5321A77B.3090003@redhat.com> <53299C98.2090308@redhat.com> <532BFC4D.4090101@redhat.com> <53318D20.9090602@redhat.com> <53319BA2.1040303@redhat.com> Message-ID: <53319CE3.8050906@redhat.com> On 25.3.2014 16:07, Petr Viktorin wrote: > On 03/25/2014 03:05 PM, Jan Cholasta wrote: >> On 21.3.2014 09:46, Petr Viktorin wrote: >>> On 03/19/2014 02:33 PM, Jan Cholasta wrote: > [...] >>>> >>>> Updated patches attached. >>>> >>>> Note that I changed the path for CSR export to /var/lib/ipa/ca.csr to >>>> make it more SELinux-friendly (not in the policy yet, see >>>> ). >>>> >> >> Updated patches attached. >> >> Note I have also updated the CA master in LDAP code. >> > > Looks better! > In patch 190, AFAICS the original CAInstance.is_master is now not used > anywhere, and its uses were always renewal-related. Is it safe to remove > it? Yes. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-254-Remove-unused-method-is_master-of-CAInstance.patch Type: text/x-patch Size: 1305 bytes Desc: not available URL: From amisnyov at redhat.com Tue Mar 25 15:26:10 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Tue, 25 Mar 2014 16:26:10 +0100 Subject: [Freeipa-devel] [PATCH] 560 webui: rename domNode to dom_node In-Reply-To: <53316D44.80901@redhat.com> References: <5329B174.9060407@redhat.com> <20140320165133.4ef44cdd@unused-4-246.brq.redhat.com> <53316D44.80901@redhat.com> Message-ID: <20140325162610.083b1bc5@unused-4-246.brq.redhat.com> On Tue, 25 Mar 2014 12:49:24 +0100 Petr Vobornik wrote: > On 20.3.2014 16:51, Misnyovszki Adam wrote: > > On Wed, 19 Mar 2014 16:02:12 +0100 > > Petr Vobornik wrote: > > > >> - unites domNode and dom_node usage to dom_node > > > > Nack, > > > > install/ui/test/details_tests.js:236 > > install/ui/test/details_tests.js:242 > > > > only finds element, because context(ie domNode) is undefined, so it > > falls back to html, not the best idea > > > > install/ui/src/freeipa/widgets/App.js:55 > > > > not sure if this causes errors, but it's worth renaming for > > consistency > > > > Greets, > > Adam > > > > all fixed, patch attached. ACK From pviktori at redhat.com Tue Mar 25 15:56:25 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 25 Mar 2014 16:56:25 +0100 Subject: [Freeipa-devel] [PATCHES] 172-196 Refactor certificate renewal code In-Reply-To: <53319CE3.8050906@redhat.com> References: <525FD641.20202@redhat.com> <526009D7.2040702@redhat.com> <5260175E.50809@redhat.com> <531DAA0F.9080300@redhat.com> <5320AE9B.6040303@redhat.com> <5321A77B.3090003@redhat.com> <53299C98.2090308@redhat.com> <532BFC4D.4090101@redhat.com> <53318D20.9090602@redhat.com> <53319BA2.1040303@redhat.com> <53319CE3.8050906@redhat.com> Message-ID: <5331A729.603@redhat.com> On 03/25/2014 04:12 PM, Jan Cholasta wrote: > On 25.3.2014 16:07, Petr Viktorin wrote: >> On 03/25/2014 03:05 PM, Jan Cholasta wrote: >>> On 21.3.2014 09:46, Petr Viktorin wrote: >>>> On 03/19/2014 02:33 PM, Jan Cholasta wrote: >> [...] >>>>> >>>>> Updated patches attached. >>>>> >>>>> Note that I changed the path for CSR export to /var/lib/ipa/ca.csr to >>>>> make it more SELinux-friendly (not in the policy yet, see >>>>> ). >>>>> >>> >>> Updated patches attached. >>> >>> Note I have also updated the CA master in LDAP code. >>> >> >> Looks better! >> In patch 190, AFAICS the original CAInstance.is_master is now not used >> anywhere, and its uses were always renewal-related. Is it safe to remove >> it? > > Yes. > Thanks. Let's get it in then. ACK, pushed to master: 0497d163d9665ed429615952eb12f17fa9ea0fe9 -- Petr? From amisnyov at redhat.com Tue Mar 25 17:26:53 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Tue, 25 Mar 2014 18:26:53 +0100 Subject: [Freeipa-devel] [PATCH]Extending user plugin with employeenumber field In-Reply-To: <53318523.7000601@redhat.com> References: <1796318445.1683710.1392993953023.JavaMail.zimbra@redhat.com> <53076B73.9020008@redhat.com> <20140321101355.06e5efaa@unused-4-246.brq.redhat.com> <20140321110051.1a50f943@unused-4-246.brq.redhat.com> <53318523.7000601@redhat.com> Message-ID: <20140325182653.551fee3d@unused-4-246.brq.redhat.com> On Tue, 25 Mar 2014 14:31:15 +0100 Petr Vobornik wrote: > On 21.3.2014 11:00, Misnyovszki Adam wrote: > > On Fri, 21 Mar 2014 10:13:55 +0100 > > Misnyovszki Adam wrote: > > > >> On Fri, 21 Feb 2014 16:06:27 +0100 > >> Petr Vobornik wrote: > >> > >>> On 21.2.2014 15:45, Adam Misnyovszki wrote: > >>>> Hi, > >>>> According to http://tools.ietf.org/html/rfc2798 ipa client and > >>>> web ui extended with employeenumber field. > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/4165 > >>>> > >>>> Question is, that should we extend user with other fields which > >>>> are in the RFC, (carLicense, departmentNumber, employeeType, etc) > >>>> if we already touched this code? > >>>> > >>>> Thanks > >>>> Adam > >>>> > >>> > >>> > >>> + Int('employeenumber?', > >>> + label=_('Employee ID'), > >>> + minvalue=1, > >>> + ), > >>> > >>> > >>> Why Int and different label? IMO it should be Str and 'Employee > >>> Number' > >>> > >>> 2.4. Employee Number > >>> > >>> Numeric or alphanumeric identifier assigned to a person, > >>> typically based on order of hire or association with an > >>> organization. Single valued. > >>> > >>> ( 2.16.840.1.113730.3.1.3 > >>> NAME 'employeeNumber' > >>> DESC 'numerically identifies an employee within an > >>> organization' EQUALITY caseIgnoreMatch > >>> SUBSTR caseIgnoreSubstringsMatch > >>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 > >>> SINGLE-VALUE ) > >>> > >> Hi, > >> fixed, also some other fields added. Note, that according to the > >> rfc, > > >> licence plate field should be multivalue, should I cange that(it > >> is an existing field). > > yes > > > >> Also, should I write test cases(especially for > >> preferredlanguage)? > > Testing new functionality helps. > > >> Greets > >> Adam > > > > self NACK, > > VERSION bump because API change > > It requires another rebase. > > > > > Greets > > Adam > > > > 1) Is there a reason to have label 'Employee ID' instead of 'Employee > Number' which is in RFC 2798? > > + label=_('Employee ID'), > > > 2) Department number seems to be multivalued as well: > ( 2.16.840.1.113730.3.1.2 > NAME 'departmentNumber' > DESC 'identifies a department within an organization' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > 3) The regex for preferredlanguage: > > + pattern='^[a-zA-Z]{1,8}[-[a-zA-Z]{1,8}]?$', > > doesn't match the expression in RFC 2068. It's only part of it. > > > Accept-Language = "Accept-Language" ":" > 1#( language-range [ ";" "q" "=" qvalue > ] ) > > language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) > > http://tools.ietf.org/html/rfc2068#section-14.4 > > RFC 2798 ( http://tools.ietf.org/html/rfc2798#section-2.7 ) says that > you should omit only the `"Accept-Language" ":"` sequence. > > See the updates in the attached patch. Greets Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0005-4-Extending-user-plugin-with-inetOrgPerson-fields.patch Type: text/x-patch Size: 11760 bytes Desc: not available URL: From pvoborni at redhat.com Wed Mar 26 08:02:34 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 26 Mar 2014 09:02:34 +0100 Subject: [Freeipa-devel] [PATCH] 560 webui: rename domNode to dom_node In-Reply-To: <20140325162610.083b1bc5@unused-4-246.brq.redhat.com> References: <5329B174.9060407@redhat.com> <20140320165133.4ef44cdd@unused-4-246.brq.redhat.com> <53316D44.80901@redhat.com> <20140325162610.083b1bc5@unused-4-246.brq.redhat.com> Message-ID: <5332899A.1010900@redhat.com> On 25.3.2014 16:26, Misnyovszki Adam wrote: > On Tue, 25 Mar 2014 12:49:24 +0100 > Petr Vobornik wrote: > >> On 20.3.2014 16:51, Misnyovszki Adam wrote: >>> On Wed, 19 Mar 2014 16:02:12 +0100 >>> Petr Vobornik wrote: >>> >>>> - unites domNode and dom_node usage to dom_node >>> >>> Nack, >>> >>> install/ui/test/details_tests.js:236 >>> install/ui/test/details_tests.js:242 >>> >>> only finds element, because context(ie domNode) is undefined, so it >>> falls back to html, not the best idea >>> >>> install/ui/src/freeipa/widgets/App.js:55 >>> >>> not sure if this causes errors, but it's worth renaming for >>> consistency >>> >>> Greets, >>> Adam >>> >> >> all fixed, patch attached. > > ACK > Pushed to master: 7fc8d241b2df352adbc51616ae3eb5dc4199a75e -- Petr Vobornik From tbabej at redhat.com Wed Mar 26 11:42:39 2014 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 26 Mar 2014 12:42:39 +0100 Subject: [Freeipa-devel] [PATCH 0160] ipatests: Do not depend on the case of the attributes when Message-ID: <5332BD2F.40203@redhat.com> Hi, In test_trust.py, several tests did case sensitive search on the output of the ipa idrange-show command. This could cause false negatives. Part of: https://fedorahosted.org/freeipa/ticket/4267 -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0160-ipatests-Do-not-depend-on-the-case-of-the-attributes.patch Type: text/x-patch Size: 2342 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 26 11:53:11 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 26 Mar 2014 12:53:11 +0100 Subject: [Freeipa-devel] [PATCH] 465 Add missing dependencies to freeipa-python package Message-ID: <5332BFA7.2020403@redhat.com> python-pyasn1 and python-qrcode were imported by ipalib but not required by python subpackage. https://fedorahosted.org/freeipa/ticket/4275 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-465-add-missing-dependencies-to-freeipa-python-package.patch Type: text/x-patch Size: 1042 bytes Desc: not available URL: From mkosek at redhat.com Wed Mar 26 11:59:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 26 Mar 2014 12:59:28 +0100 Subject: [Freeipa-devel] [PATCH 0160] ipatests: Do not depend on the case of the attributes when In-Reply-To: <5332BD2F.40203@redhat.com> References: <5332BD2F.40203@redhat.com> Message-ID: <5332C120.4090000@redhat.com> On 03/26/2014 12:42 PM, Tomas Babej wrote: > Hi, > > In test_trust.py, several tests did case sensitive search on the output of > the ipa idrange-show command. This could cause false negatives. > > Part of: https://fedorahosted.org/freeipa/ticket/4267 Yup, this should fix the annoying CI error + make this test more resilient to attribute casing changes. ACK. Pushed to master. Martin From pviktori at redhat.com Wed Mar 26 12:15:55 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 26 Mar 2014 13:15:55 +0100 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <20140325153625.1d6f1187@unused-4-246.brq.redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> <20140321120032.23243622@unused-4-246.brq.redhat.com> <532C24AE.8090406@redhat.com> <532C2977.7070401@redhat.com> <532C2B3D.9010401@redhat.com> <20140324114221.6ae6b214@unused-4-246.brq.redhat.com> <53305811.20509@redhat.com> <20140325153625.1d6f1187@unused-4-246.brq.redhat.com> Message-ID: <5332C4FB.4060007@redhat.com> On 03/25/2014 03:36 PM, Misnyovszki Adam wrote: > On Mon, 24 Mar 2014 17:06:41 +0100 > Martin Kosek wrote: > >> On 03/24/2014 11:42 AM, Misnyovszki Adam wrote: >>> On Fri, 21 Mar 2014 13:06:21 +0100 >>> Petr Viktorin wrote: >>> >>>> On 03/21/2014 12:58 PM, Martin Kosek wrote: >>>>> On 03/21/2014 12:38 PM, Petr Viktorin wrote: >>>>>> On 03/21/2014 12:00 PM, Misnyovszki Adam wrote: >>>>>>> On Fri, 21 Mar 2014 10:33:00 +0100 >>>>>>> Petr Viktorin wrote: >>>>>>> >>>>>>>> On 03/21/2014 10:29 AM, Petr Viktorin wrote: >>>>>>>>> On 03/20/2014 04:22 PM, Misnyovszki Adam wrote: >>>>>>>>>> On Thu, 20 Mar 2014 14:19:51 +0100 >>>>>>>>>> Misnyovszki Adam wrote: >>>>>>>>>> >>>>>>>>>>> On Fri, 14 Mar 2014 13:26:15 -0400 >>>>>>>>>>> Rob Crittenden wrote: >>>>>>>>>>> >>>>>>>>>>>> Misnyovszki Adam wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> automember-rebuild uses asynchronous 389 task, and >>>>>>>>>>>>> returned success even if the task didn't run. This patch >>>>>>>>>>>>> fixes this issue adding a --nowait parameter to 'ipa >>>>>>>>>>>>> automember-rebuild', defaulting to False, thus when the >>>>>>>>>>>>> script runs without it, it waits for the 'nstaskexitcode' >>>>>>>>>>>>> attribute, which means the task has finished, according to >>>>>>>>>>>>> http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Old usage can be enabled using --nowait. >>>>>>>>>>>>> >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4239 >>>>>>>>>>>>> >>>>>>>>>>>>> Request for comments: >>>>>>>>>>>>> - Should I add a parameter to specify the polling time? >>>>>>>>>>>>> (now 1ms) >>>>>>>>>>>>> - Should I add a parameter to specify the maximum polling >>>>>>>>>>>>> number? Now if something fails about creating the task, it >>>>>>>>>>>>> polls forever. >>>>>>>>>>>>> - Obviously, if these parameters should be added, there >>>>>>>>>>>>> should be a reasonable default for them (~ Required=False, >>>>>>>>>>>>> Default=X). >>>>>>>>>>>> >>>>>>>>>>>> I don't think you need a polling time, esp since this is >>>>>>>>>>>> hidden from the user, but I think that is probably too >>>>>>>>>>>> short and you may end up hammering the LDAP server. >>>>>>>>>>>> >>>>>>>>>>>> I also wonder if there should be some maximum wait time. I >>>>>>>>>>>> don't like loops that can never exit. I'm at a loss for >>>>>>>>>>>> what that time should be though. And we'd need to spell >>>>>>>>>>>> out that we gave up waiting, not that the task necessarily >>>>>>>>>>>> failed. So rather than having a polling time option, >>>>>>>>>>>> rename nowait into wait_for=20, so wait for 20 seconds. Or >>>>>>>>>>>> something like that. >>>>>>>>>>>> >>>>>>>>>>>> I'd suggest using get_entry since you already know the full >>>>>>>>>>>> DN and there is only ever one. It would make this much more >>>>>>>>>>>> readable. >>>>>>>>>>>> >>>>>>>>>>>> I wonder if some top-level documentation should be added to >>>>>>>>>>>> flesh this out some more. This does, for example, return >>>>>>>>>>>> False in one case. The meaning for that should be spelled >>>>>>>>>>>> out. >>>>>>>>>>>> >>>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> personally I would keep --no-wait, with a delay of 1 >>>>>>>>>>> seconds, and a maximum waiting time for 60 seconds. >>>>>>>>>>> Questions is, do we need to parameterize with other >>>>>>>>>>> parameters(wait-for to the maximum time, and/or poll-delay >>>>>>>>>>> for the delay time, both not required), or it is not a case >>>>>>>>>>> which worth to develop? Greets >>>>>>>>>>> Adam >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> here are the corrections Petr asked, also the other patch >>>>>>>>>> conatins the plugin registration refactor. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> You forgot an alternate summary for the --no-wait case. (Make >>>>>>>>> sure to output the DN in this case, so it's possible to poll >>>>>>>>> for it.) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Instead of `task['nstaskexitcode'][0]` please use >>>>>>>>> `task.single_value['nstaskexitcode']`. >>>>>> >>>>>> There's one more `task['nstaskexitcode'][0]`. (Perhaps putting it >>>>>> in a variable would be better?) >>>>>> >>>>>>>>> >>>>>>>>> Here: >>>>>>>>> >>>>>>>>> raise errors.DatabaseError( >>>>>>>>> desc=_("Automember rebuild membership task failed"), >>>>>>>>> info=_("nstaskexitcode = '%s'" % >>>>>>>>> str(task['nstaskexitcode'][0]))) >>>>>>>>> >>>>>>>>> there's no need to call str() on %'s argument. >>>>>>>>> Also, use natural language (like "Task exit code: %s"), >>>>>>>>> otherwise there's no need to mark the message for translation. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> And one more thing: Please bump the minor version in the >>>>>>>> VERSION file when API.txt changes. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> everything is corrected! >>>>>>> Greets >>>>>>> Adam >>>>>>> >>>>>> >>>>>> Sorry for dragging this so long, but: >>>>>> The DN should not be a part of the summary, because that makes it >>>>>> hard to parse when using the API. It should be returned as a part >>>>>> of the result. To do that, you'd need to change the output type: >>>>>> >>>>>> has_output = output.standard_entry >>>>>> has_output_params = ( >>>>>> DNParam( >>>>>> 'dn', >>>>>> label=_('Task automember'), >>>>>> doc=_('DN of the started task'), >>>>>> ), >>>>>> ) >>>>>> >>>>>> and provide a dict in result, instead of True. (And with >>>>>> --no-wait, add the dn to that dict.) >>>>>> >>>>> >>>>> Do really want to use 'dn' for the DNParam? dn is already used for >>>>> standard entry DN when --all is used, right? "automembertaskdn" >>>>> may be better. >>>> >>>> Well, I think "DN of the added entry" is exactly what this is. >>>> >>>>> Also, "Task automember" label sounds strange to me, would >>>>> "Automember task DN" be better? >>>> >>>> I meant "Task DN", sorry for the thinko. >>>> >>>> >>> >>> One more thing, which came to my mind after reviewing the code for >>> myself once again, if the task fails with an exit code other than 0, >>> there is a DatabaseError raised, which is just fine. But in the >>> info, should I specify not only the exit code, but also the DN of >>> the task, or is it unnecessary? >>> Thanks >>> Adam >> >> DS tasks usually have the error in some of their attributes, so if >> there is such attribute, I would report what the error is. It is >> easier to use than having to run ldapsearch against the given DN. >> >> If there is not such attribute, providing the DN would be a good idea. >> >> Martin > Hi, > fixed the output parameter issue, and also with that, API is updated. > If an error occurs, now the function returns the nstaskstatus attribute, > and the DN of the failed task. Also, I added a 3600 second ttl to the > task, because the original was a few seconds(I haven't found the default > value for that anywhere), to ensure that the task doesn't disappear > before interaction is required. Attached the refactor of plugin > registration patch also. > > Greets > Adam Looks great! I'm just concerned about the error returned when the task takes too long: $ ipa automember-rebuild --type group ipa: ERROR: LDAP timeout I don't think it's sufficiently clear from this that waiting for the task timed out, but the task was actually started successfully. A custom error with a more descriptive message would be useful. Also I've noticed that the "nstaskstatus" of a successful task is: Automember rebuild task finished. Processed (1) entries. This looks helpful; we could return it as the summary. -- Petr? From pviktori at redhat.com Wed Mar 26 12:59:10 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 26 Mar 2014 13:59:10 +0100 Subject: [Freeipa-devel] [PATCH] 465 Add missing dependencies to freeipa-python package In-Reply-To: <5332BFA7.2020403@redhat.com> References: <5332BFA7.2020403@redhat.com> Message-ID: <5332CF1E.2060601@redhat.com> On 03/26/2014 12:53 PM, Martin Kosek wrote: > python-pyasn1 and python-qrcode were imported by ipalib but not > required by python subpackage. > > https://fedorahosted.org/freeipa/ticket/4275 Thanks, ACK, pushed to master: e04da74626dbaef9990833cf1def23da51981a93 -- Petr? From amisnyov at redhat.com Wed Mar 26 13:07:50 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Wed, 26 Mar 2014 14:07:50 +0100 Subject: [Freeipa-devel] [PATCH]Extending user plugin with employeenumber field In-Reply-To: <20140325182653.551fee3d@unused-4-246.brq.redhat.com> References: <1796318445.1683710.1392993953023.JavaMail.zimbra@redhat.com> <53076B73.9020008@redhat.com> <20140321101355.06e5efaa@unused-4-246.brq.redhat.com> <20140321110051.1a50f943@unused-4-246.brq.redhat.com> <53318523.7000601@redhat.com> <20140325182653.551fee3d@unused-4-246.brq.redhat.com> Message-ID: <20140326140750.126d6821@unused-4-246.brq.redhat.com> On Tue, 25 Mar 2014 18:26:53 +0100 Misnyovszki Adam wrote: > On Tue, 25 Mar 2014 14:31:15 +0100 > Petr Vobornik wrote: > > > On 21.3.2014 11:00, Misnyovszki Adam wrote: > > > On Fri, 21 Mar 2014 10:13:55 +0100 > > > Misnyovszki Adam wrote: > > > > > >> On Fri, 21 Feb 2014 16:06:27 +0100 > > >> Petr Vobornik wrote: > > >> > > >>> On 21.2.2014 15:45, Adam Misnyovszki wrote: > > >>>> Hi, > > >>>> According to http://tools.ietf.org/html/rfc2798 ipa client and > > >>>> web ui extended with employeenumber field. > > >>>> > > >>>> https://fedorahosted.org/freeipa/ticket/4165 > > >>>> > > >>>> Question is, that should we extend user with other fields which > > >>>> are in the RFC, (carLicense, departmentNumber, employeeType, > > >>>> etc) if we already touched this code? > > >>>> > > >>>> Thanks > > >>>> Adam > > >>>> > > >>> > > >>> > > >>> + Int('employeenumber?', > > >>> + label=_('Employee ID'), > > >>> + minvalue=1, > > >>> + ), > > >>> > > >>> > > >>> Why Int and different label? IMO it should be Str and 'Employee > > >>> Number' > > >>> > > >>> 2.4. Employee Number > > >>> > > >>> Numeric or alphanumeric identifier assigned to a person, > > >>> typically based on order of hire or association with an > > >>> organization. Single valued. > > >>> > > >>> ( 2.16.840.1.113730.3.1.3 > > >>> NAME 'employeeNumber' > > >>> DESC 'numerically identifies an employee within an > > >>> organization' EQUALITY caseIgnoreMatch > > >>> SUBSTR caseIgnoreSubstringsMatch > > >>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 > > >>> SINGLE-VALUE ) > > >>> > > >> Hi, > > >> fixed, also some other fields added. Note, that according to the > > >> rfc, > > > > >> licence plate field should be multivalue, should I cange that(it > > >> is an existing field). > > > > yes > > > > > > >> Also, should I write test cases(especially for > > >> preferredlanguage)? > > > > Testing new functionality helps. > > > > >> Greets > > >> Adam > > > > > > self NACK, > > > VERSION bump because API change > > > > It requires another rebase. > > > > > > > > Greets > > > Adam > > > > > > > 1) Is there a reason to have label 'Employee ID' instead of > > 'Employee Number' which is in RFC 2798? > > > > + label=_('Employee ID'), > > > > > > 2) Department number seems to be multivalued as well: > > ( 2.16.840.1.113730.3.1.2 > > NAME 'departmentNumber' > > DESC 'identifies a department within an organization' > > EQUALITY caseIgnoreMatch > > SUBSTR caseIgnoreSubstringsMatch > > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > > > 3) The regex for preferredlanguage: > > > > + pattern='^[a-zA-Z]{1,8}[-[a-zA-Z]{1,8}]?$', > > > > doesn't match the expression in RFC 2068. It's only part of it. > > > > > > Accept-Language = "Accept-Language" ":" > > 1#( language-range [ ";" "q" "=" qvalue > > ] ) > > > > language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" > > ) > > > > http://tools.ietf.org/html/rfc2068#section-14.4 > > > > RFC 2798 ( http://tools.ietf.org/html/rfc2798#section-2.7 ) says > > that you should omit only the `"Accept-Language" ":"` sequence. > > > > > > See the updates in the attached patch. > Greets > Adam The preferredLanguage regex pattern and error message has been modified to comply with RFC, according to conversation with Petr. Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0005-5-Extending-user-plugin-with-inetOrgPerson-fields.patch Type: text/x-patch Size: 11968 bytes Desc: not available URL: From amisnyov at redhat.com Wed Mar 26 14:36:13 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Wed, 26 Mar 2014 15:36:13 +0100 Subject: [Freeipa-devel] [PATCH] 561 webui: make navigation module independent on app module In-Reply-To: <5329B17B.10503@redhat.com> References: <5329B17B.10503@redhat.com> Message-ID: <20140326153613.397b00dd@unused-4-246.brq.redhat.com> On Wed, 19 Mar 2014 16:02:19 +0100 Petr Vobornik wrote: > When some module used 'freeipa/navigation' it pulled the entire Web UI > because navigation depended on app. > > This patch splits the app into two modules: app and app_container. > App specifies the entities which are part of final application. > app_container module represents the application boot classes. > Navigation now depends on app_container. Hi, tests ran as expected, and it works, so ACK. Note: there are two typos in copyright, app.js:5(./), app_container.js:1(space before comment), should be corrected before push. Thanks Adam From mkosek at redhat.com Wed Mar 26 17:46:01 2014 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 26 Mar 2014 18:46:01 +0100 Subject: [Freeipa-devel] [PATCH 0113] ipa-client: Set NIS domain name in the installer In-Reply-To: <5314D51E.9040402@redhat.com> References: <5243F02D.9020005@redhat.com> <5284B9E2.3000007@redhat.com> <5314D51E.9040402@redhat.com> Message-ID: <53331259.2090508@redhat.com> On 03/03/2014 08:16 PM, Tomas Babej wrote: > The updated patch addresses all the mentioned issues. > > Also enables systemd's specific domainname service instead of relying > ypbind being present on the system. > > Please note that nisdomainname is not configured on boot time at the > moment. The following bug is the cause: > > https://bugzilla.redhat.com/show_bug.cgi?id=1071951 I spoke with initscripts maintainer, applied little pressure and fixed version is now on its way to updates-testing - initscripts-9.51-2.fc20. Martin From redhatrises at gmail.com Wed Mar 26 23:30:13 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 26 Mar 2014 17:30:13 -0600 Subject: [Freeipa-devel] [PATCH] [DOC] Review section on NetworkManager Message-ID: All, Please review this patch for https://fedorahosted.org/freeipa/ticket/4156 Added links to documentation on configuring NetworkManager. Thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0010-DOC-Update-section-about-use-of-NetworkManager.patch Type: text/x-patch Size: 2991 bytes Desc: not available URL: From redhatrises at gmail.com Wed Mar 26 23:40:41 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Wed, 26 Mar 2014 17:40:41 -0600 Subject: [Freeipa-devel] [PATCH] [DOC] Add note about additional nameservers in resolv.conf Message-ID: All, Please review patch for https://fedorahosted.org/freeipa/ticket/3085 Added note that 'nameserver 127.0.0.1' is added to resolv.conf, that it is recommended to add more replicas to resolv.conf, and the max nameservers allowed in resolv.conf. thanks, Gabe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0011-DOC-Additional-DNS-servers-in-resolv.conf.patch Type: text/x-patch Size: 2272 bytes Desc: not available URL: From pspacek at redhat.com Thu Mar 27 08:42:59 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 27 Mar 2014 09:42:59 +0100 Subject: [Freeipa-devel] [PATCH] [DOC] Add note about additional nameservers in resolv.conf In-Reply-To: References: Message-ID: <5333E493.4020400@redhat.com> On 27.3.2014 00:40, Gabe Alford wrote: > All, > > Please review patch for https://fedorahosted.org/freeipa/ticket/3085 > Added note that 'nameserver 127.0.0.1' is added to resolv.conf, that it is > recommended to add more replicas to resolv.conf, and the max nameservers > allowed in resolv.conf. Thank you for the patch! Conditional ACK, please remove trailing whitespaces before push. -- Petr^2 Spacek From pviktori at redhat.com Thu Mar 27 08:58:48 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 27 Mar 2014 09:58:48 +0100 Subject: [Freeipa-devel] [PATCH] [DOC] Add note about additional nameservers in resolv.conf In-Reply-To: <5333E493.4020400@redhat.com> References: <5333E493.4020400@redhat.com> Message-ID: <5333E848.4020306@redhat.com> On 03/27/2014 09:42 AM, Petr Spacek wrote: > On 27.3.2014 00:40, Gabe Alford wrote: >> All, >> >> Please review patch for https://fedorahosted.org/freeipa/ticket/3085 >> Added note that 'nameserver 127.0.0.1' is added to resolv.conf, that >> it is >> recommended to add more replicas to resolv.conf, and the max nameservers >> allowed in resolv.conf. > > Thank you for the patch! > > Conditional ACK, please remove trailing whitespaces before push. > Thanks! Pushed to docs master: a2f5d7ed8fe49e8ad1cfbf29ddfe563de235e8ac -- Petr? From mbasti at redhat.com Thu Mar 27 09:23:36 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 27 Mar 2014 10:23:36 +0100 Subject: [Freeipa-devel] [PATCH] [DOC] Add note about additional nameservers in resolv.conf In-Reply-To: References: Message-ID: <1395912216.2269.5.camel@unused-4-145.brq.redhat.com> On Wed, 2014-03-26 at 17:40 -0600, Gabe Alford wrote: > All, > > Please review patch for https://fedorahosted.org/freeipa/ticket/3085 > > Added note that 'nameserver 127.0.0.1' is added to resolv.conf, that > it is recommended to add more replicas to resolv.conf, and the max > nameservers allowed in resolv.conf. > Actually, my ipa-server-install puts into /etc/resolv.conf its ip address itself not localhost After fresh install: #cat /etc/resolv.conf search example.com nameserver 10.*.*.* > > thanks, > > > Gabe > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Martin^2 Basti From pspacek at redhat.com Thu Mar 27 09:33:10 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 27 Mar 2014 10:33:10 +0100 Subject: [Freeipa-devel] [PATCH] [DOC] Add note about additional nameservers in resolv.conf In-Reply-To: <1395912216.2269.5.camel@unused-4-145.brq.redhat.com> References: <1395912216.2269.5.camel@unused-4-145.brq.redhat.com> Message-ID: <5333F056.2030100@redhat.com> On 27.3.2014 10:23, Martin Basti wrote: > On Wed, 2014-03-26 at 17:40 -0600, Gabe Alford wrote: >> All, >> >> Please review patch for https://fedorahosted.org/freeipa/ticket/3085 >> >> Added note that 'nameserver 127.0.0.1' is added to resolv.conf, that >> it is recommended to add more replicas to resolv.conf, and the max >> nameservers allowed in resolv.conf. >> > Actually, my ipa-server-install puts into /etc/resolv.conf its ip > address itself not localhost > > After fresh install: > #cat /etc/resolv.conf > search example.com > nameserver 10.*.*.* IMHO /etc/resolv.conf was overwritten by DHCPd (when IPA installation was finished). -- Petr^2 Spacek From mbasti at redhat.com Thu Mar 27 10:14:53 2014 From: mbasti at redhat.com (Martin Basti) Date: Thu, 27 Mar 2014 11:14:53 +0100 Subject: [Freeipa-devel] [PATCH] [DOC] Add note about additional nameservers in resolv.conf In-Reply-To: <5333F056.2030100@redhat.com> References: <1395912216.2269.5.camel@unused-4-145.brq.redhat.com> <5333F056.2030100@redhat.com> Message-ID: <1395915293.2269.7.camel@unused-4-145.brq.redhat.com> On Thu, 2014-03-27 at 10:33 +0100, Petr Spacek wrote: > On 27.3.2014 10:23, Martin Basti wrote: > > On Wed, 2014-03-26 at 17:40 -0600, Gabe Alford wrote: > >> All, > >> > >> Please review patch for https://fedorahosted.org/freeipa/ticket/3085 > >> > >> Added note that 'nameserver 127.0.0.1' is added to resolv.conf, that > >> it is recommended to add more replicas to resolv.conf, and the max > >> nameservers allowed in resolv.conf. > >> > > Actually, my ipa-server-install puts into /etc/resolv.conf its ip > > address itself not localhost > > > > After fresh install: > > #cat /etc/resolv.conf > > search example.com > > nameserver 10.*.*.* > > IMHO /etc/resolv.conf was overwritten by DHCPd (when IPA installation was > finished). > I inspect ipa-server-install source code and installation adds to resolv.conf a real server address. DHCP leave note in resolv.conf when generate it. -- Martin^2 Basti From jpazdziora at redhat.com Thu Mar 27 10:27:13 2014 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 27 Mar 2014 11:27:13 +0100 Subject: [Freeipa-devel] [PATCH] [DOC] Review section on NetworkManager In-Reply-To: References: Message-ID: <20140327102713.GG3872@redhat.com> On Wed, Mar 26, 2014 at 05:30:13PM -0600, Gabe Alford wrote: > All, > > Please review this patch for https://fedorahosted.org/freeipa/ticket/4156 > Added links to documentation on configuring NetworkManager. Thank you for the patch. ACK. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Thu Mar 27 11:45:33 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 27 Mar 2014 12:45:33 +0100 Subject: [Freeipa-devel] FreeIPA 3.3.5 Message-ID: <53340F5D.8070405@redhat.com> Hello all! I think we are close to releasing next bugfixing version on FreeIPA 3.3.5. We have a lot of bug fixes to offer, especially in the AD Trust area. I wrote the changelog to our wiki, fixes or suggestions welcome: http://www.freeipa.org/page/Releases/3.3.5 I have just one last concern though, the remaining PKI clone installation issue I found: https://fedorahosted.org/pki/ticket/933 Do we want to release before this ticket is closed or wait? Question is if fixing Dogtag 10 based clone installation is enough to allow us to release or not. Matthew (CCed), do we have any ETA when the fix would be available? -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pvoborni at redhat.com Thu Mar 27 11:46:15 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 27 Mar 2014 12:46:15 +0100 Subject: [Freeipa-devel] [PATCH] 561 webui: make navigation module independent on app module In-Reply-To: <20140326153613.397b00dd@unused-4-246.brq.redhat.com> References: <5329B17B.10503@redhat.com> <20140326153613.397b00dd@unused-4-246.brq.redhat.com> Message-ID: <53340F87.4080708@redhat.com> On 26.3.2014 15:36, Misnyovszki Adam wrote: > On Wed, 19 Mar 2014 16:02:19 +0100 > Petr Vobornik wrote: > >> When some module used 'freeipa/navigation' it pulled the entire Web UI >> because navigation depended on app. >> >> This patch splits the app into two modules: app and app_container. >> App specifies the entities which are part of final application. >> app_container module represents the application boot classes. >> Navigation now depends on app_container. > > Hi, > tests ran as expected, and it works, so > ACK. > Note: > there are two typos in copyright, app.js:5(./), > app_container.js:1(space before comment), should be corrected before > push. > Thanks > Adam > Typos in comments fixed. Pushed to master: e7bfac1e63360993aea2be91082ca69c478f3cf1 -- Petr Vobornik From tbabej at redhat.com Thu Mar 27 12:11:15 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 27 Mar 2014 13:11:15 +0100 Subject: [Freeipa-devel] [PATCH 0158] Extend ipa-range-check DS plugin to handle range types In-Reply-To: <20140318154530.GG16644@redhat.com> References: <5327158D.1020408@redhat.com> <20140318081917.GZ16644@redhat.com> <532860FE.2040203@redhat.com> <20140318154530.GG16644@redhat.com> Message-ID: <53341563.9050204@redhat.com> The updated version handles the ret variable properly. It also makes sure the memory is properly freed. On 03/18/2014 04:45 PM, Alexander Bokovoy wrote: > On Tue, 18 Mar 2014, Tomas Babej wrote: >> >> On 03/18/2014 09:19 AM, Alexander Bokovoy wrote: >>> On Mon, 17 Mar 2014, Tomas Babej wrote: >>>> Hi, >>>> >>>> The ipa-range-check plugin used to determine the range type depending >>>> on the value of the attributes such as RID or secondary RID base. This >>>> approached caused variety of issues since the portfolio of ID range >>>> types expanded. >>>> >>>> The patch makes sure the following rules are implemented: >>>> * No ID range pair can overlap on base ranges, with exception >>>> of two ipa-ad-trust-posix ranges belonging to the same forest >>>> * For any ID range pair of ranges belonging to the same domain: >>>> * Both ID ranges must be of the same type >>>> * For ranges of ipa-ad-trust type or ipa-local type: >>>> * Primary RID ranges can not overlap >>>> * For ranges of ipa-local type: >>>> * Primary and secondary RID ranges can not overlap >>>> * Secondary RID ranges cannot overlap >>>> >>>> For the implementation part, the plugin was extended with a domain ID >>>> to forest root domain ID mapping derivation capabilities. >>>> >>>> https://fedorahosted.org/freeipa/ticket/4137 >>>> >>>> Test coverage coming soon! >>> >>> I don't really like that you are using a list here. The list is built >>> and then destroyed in preop callback every time we process the range >>> object, so it is one-off operation. Now, when you fetch trust domain >>> objects to build the list, why can't you use an array directly? >>> >>> Given that all you need the list for is to map domain to a trust (if >>> any) and trust name is the name of the root level domain, you can >>> simply >>> make an array of a struct (name, root) where root is a and index to the >>> same array or -1 if this is the root domain itself. >> >> I don't see much benefit of using array over linked list in this case. >> In both cases, we would need to build the data container, and it would >> be one-off operation (once for the ADD/MOD operation). >> >> Additionaly, using linked list, I can only pass around the pointer to >> the head of the list, instead of passing around the array and it's >> size. > If you make a {NULL, NULL} entry as the last one, no need to pass array > size. But anyway... > > >> I reworked the part of the patch that fetches the data from the LDAP as >> we discussed. Instead of performing multiple LDAP searches, we do a >> single extra search per operation. > See comments below. > >> +static struct domain_info* build_domain_to_forest_root_map(struct >> domain_info *head, >> + struct >> ipa_range_check_ctx *ctx){ >> + >> + Slapi_PBlock *trusted_domain_search_pb = NULL; >> + Slapi_Entry **trusted_domain_entries = NULL; >> + Slapi_DN *base_dn = NULL; >> + Slapi_RDN *rdn = NULL; >> + >> + int search_result; >> + int ret; >> + >> + /* Set the base DN for the search to cn=ad, cn=trusts, $SUFFIX */ >> + base_dn = slapi_sdn_new_dn_byref(ctx->base_dn); >> + if (base_dn == NULL) { >> + LOG_FATAL("Failed to convert base DN.\n"); >> + ret = LDAP_OPERATIONS_ERROR; >> + goto done; >> + } >> + >> + rdn = slapi_rdn_new(); >> + if (rdn == NULL) { >> + LOG_FATAL("Failed to obtain RDN struct.\n"); >> + ret = LDAP_OPERATIONS_ERROR; >> + goto done; >> + } >> + >> + slapi_rdn_add(rdn, "cn", "trusts"); >> + slapi_sdn_add_rdn(base_dn, rdn); >> + slapi_rdn_done(rdn); >> + >> + slapi_rdn_add(rdn, "cn", "ad"); >> + slapi_sdn_add_rdn(base_dn, rdn); >> + slapi_rdn_done(rdn); > given that slapi_search_internal_set_pb() wants 'const char *base', why > not use asprintf() instead? > > Here is what we do in ipa-kdb: > ret = asprintf(&base, "cn=ad,cn=trusts,%s", ipactx->base); > if (ret == -1) { > ret = ENOMEM; > goto done; > } > > That's enough, IMHO. 389-ds internally will anyway create new sdn > explicitly from a string you've passed. > >> + >> + /* Allocate a new parameter block */ >> + trusted_domain_search_pb = slapi_pblock_new(); >> + if (trusted_domain_search_pb == NULL) { >> + LOG_FATAL("Failed to create new pblock.\n"); >> + ret = LDAP_OPERATIONS_ERROR; > in done: label you don't deal with 'ret' at all. Do you need it? > >> + //goto done; > is it goto or not? > >> + } >> + >> + /* Search for all the root domains, note the LDAP_SCOPE_ONELEVEL */ >> + slapi_search_internal_set_pb(trusted_domain_search_pb, >> + slapi_sdn_get_dn(base_dn), > here just use 'base_dn'. > >> + LDAP_SCOPE_SUBTREE, DOMAIN_ID_FILTER, >> + NULL, 0, NULL, NULL, >> ctx->plugin_id, 0); >> + >> + ret = slapi_search_internal_pb(trusted_domain_search_pb); >> + if (ret != 0) { >> + LOG_FATAL("Starting internal search failed.\n"); >> + goto done; > make sure you are consistent with 'ret' -- either handling it or not, > and if overriding with LDAP_OPERATIONS_ERROR, make sure it is overridden > everywhere. > >> + } >> + >> + ret = slapi_pblock_get(trusted_domain_search_pb, >> SLAPI_PLUGIN_INTOP_RESULT, &search_result); >> + if (ret != 0 || search_result != LDAP_SUCCESS) { >> + LOG_FATAL("Internal search failed.\n"); >> + ret = LDAP_OPERATIONS_ERROR; >> + goto done; >> + } > same here > >> + >> + ret = slapi_pblock_get(trusted_domain_search_pb, >> SLAPI_PLUGIN_INTOP_SEARCH_ENTRIES, >> + &trusted_domain_entries); >> + >> + if (ret != 0) { >> + LOG_FATAL("Failed to read searched root domain entries.\n"); > same here > >> + goto done; >> + } >> + >> + if (trusted_domain_entries == NULL || trusted_domain_entries[0] >> == NULL) { >> + LOG("No existing root domain entries.\n"); >> + ret = 0; >> + goto done; >> + } > Here as well > >> + >> + /* now we iterate the domains and determine which of them are >> root domains */ >> + for (int i = 0; trusted_domain_entries[i] != NULL; i++) { >> + >> + ret = slapi_sdn_isparent(base_dn, >> + >> slapi_entry_get_sdn(trusted_domain_entries[i])); >> + >> + /* trusted domain is root domain */ >> + if (ret == 1) { >> + map_domain_to_root(head, >> + trusted_domain_entries[i], >> + trusted_domain_entries[i]); >> + } >> + else { >> + /* we need to search for the root domain */ >> + for (int j = 0; trusted_domain_entries[j] != NULL; j++) { >> + ret = slapi_sdn_isparent( >> + >> slapi_entry_get_sdn(trusted_domain_entries[j]), >> + >> slapi_entry_get_sdn(trusted_domain_entries[i])); >> + >> + /* match, set the jth domain as the root domain for >> the ith */ >> + if (ret == 1) { >> + map_domain_to_root(head, >> + trusted_domain_entries[i], >> + trusted_domain_entries[j]); >> + break; >> + } >> + } >> + } >> + } >> + >> +done: >> + slapi_free_search_results_internal(trusted_domain_search_pb); >> + slapi_pblock_destroy(trusted_domain_search_pb); >> + slapi_rdn_free(&rdn); >> + >> + return head; >> + >> +} >> + >> +static int slapi_entry_to_range_info(struct domain_info >> *domain_info_head, >> + struct slapi_entry *entry, >> struct range_info **_range) >> { >> int ret; >> @@ -97,6 +273,9 @@ static int slapi_entry_to_range_info(struct >> slapi_entry *entry, >> } >> >> range->domain_id = slapi_entry_attr_get_charptr(entry, >> IPA_DOMAIN_ID); >> + range->id_range_type = slapi_entry_attr_get_charptr(entry, >> IPA_RANGE_TYPE); >> + range->forest_root_id = get_forest_root_id(domain_info_head, >> + range->domain_id); >> >> ul_val = slapi_entry_attr_get_ulong(entry, IPA_BASE_ID); >> if (ul_val == 0 || ul_val >= UINT32_MAX) { >> @@ -161,58 +340,67 @@ static bool intervals_overlap(uint32_t x, >> uint32_t base, uint32_t x_size, uint32 >> * | | / \ | >> * new range: base rid sec_rid >> **/ >> -static int ranges_overlap(struct range_info *r1, struct range_info *r2) >> +static int check_ranges(struct range_info *r1, struct range_info *r2) >> { >> + /* Do not check overlaps of range with the range itself */ >> if (r1->name != NULL && r2->name != NULL && >> strcasecmp(r1->name, r2->name) == 0) { >> return 0; >> } >> >> - /* check if base range overlaps with existing base range */ >> - if (intervals_overlap(r1->base_id, r2->base_id, >> - r1->id_range_size, r2->id_range_size)){ >> - return 1; >> + /* Check if base range overlaps with existing base range. >> + * Exception: ipa-ad-trust-posix ranges from the same forest */ >> + if (!(strcasecmp(r1->id_range_type, AD_TRUST_POSIX_RANGE_TYPE) && >> + strcasecmp(r2->id_range_type, AD_TRUST_POSIX_RANGE_TYPE) && >> + r1->forest_root_id != NULL && r2->forest_root_id !=NULL && >> + strcasecmp(r1->forest_root_id, r2->forest_root_id) == 0)) { >> + >> + if (intervals_overlap(r1->base_id, r2->base_id, >> + r1->id_range_size, r2->id_range_size)){ >> + return 1; >> + } >> + >> } >> >> - /* if both base_rid and secondary_base_rid = 0, the rid range is >> not set */ >> - bool rid_ranges_set = (r1->base_rid != 0 || >> r1->secondary_base_rid != 0) && >> - (r2->base_rid != 0 || >> r2->secondary_base_rid != 0); >> - >> - /** >> - * ipaNTTrustedDomainSID is not set for local ranges, use it to >> - * determine the type of the range **/ >> - bool local_ranges = r1->domain_id == NULL && r2->domain_id == NULL; >> - >> + /* Following checks apply for the ranges from the same domain */ >> bool ranges_from_same_domain = >> (r1->domain_id == NULL && r2->domain_id == NULL) || >> (r1->domain_id != NULL && r2->domain_id != NULL && >> strcasecmp(r1->domain_id, r2->domain_id) == 0); >> >> - /** >> - * in case rid range is not set or ranges belong to different >> domains >> - * we can skip rid range tests as they are irrelevant **/ >> - if (rid_ranges_set && ranges_from_same_domain){ >> - >> - /* check if rid range overlaps with existing rid range */ >> - if (intervals_overlap(r1->base_rid, r2->base_rid, >> - r1->id_range_size, r2->id_range_size)) >> - return 2; >> - >> - /** >> - * The following 3 checks are relevant only if both ranges >> are local. >> - * Check if secondary rid range overlaps with existing >> secondary rid >> - * range. **/ >> - if (local_ranges){ >> + if (ranges_from_same_domain) { >> + >> + /* Ranges from the same domain must have the same type */ >> + if (strcasecmp(r1->id_range_type, r2->id_range_type) != 0) { >> + return 6; >> + } >> + >> + /* For ipa-local or ipa-ad-trust range types primary RID >> ranges should >> + * not overlap */ >> + if (strcasecmp(r1->id_range_type, AD_TRUST_RANGE_TYPE) == 0 || >> + strcasecmp(r1->id_range_type, LOCAL_RANGE_TYPE) == 0) { >> + >> + /* Check if rid range overlaps with existing rid range */ >> + if (intervals_overlap(r1->base_rid, r2->base_rid, >> + r1->id_range_size, r2->id_range_size)) >> + return 2; >> + } >> + >> + /* The following 3 checks are relevant only if both ranges >> are local. */ >> + if (strcasecmp(r1->id_range_type, LOCAL_RANGE_TYPE) == 0){ >> + >> + /* Check if secondary RID range overlaps with existing >> secondary or >> + * primary RID range. */ >> if (intervals_overlap(r1->secondary_base_rid, >> r2->secondary_base_rid, r1->id_range_size, >> r2->id_range_size)) >> return 3; >> >> - /* check if rid range overlaps with existing secondary >> rid range */ >> + /* Check if RID range overlaps with existing secondary >> RID range */ >> if (intervals_overlap(r1->base_rid, r2->secondary_base_rid, >> r1->id_range_size, r2->id_range_size)) >> return 4; >> >> - /* check if secondary rid range overlaps with existing >> rid range */ >> + /* Check if secondary RID range overlaps with existing >> RID range */ >> if (intervals_overlap(r1->secondary_base_rid, r2->base_rid, >> r1->id_range_size, r2->id_range_size)) >> return 5; >> @@ -248,9 +436,10 @@ static int ipa_range_check_pre_op(Slapi_PBlock >> *pb, int modtype) >> int search_result; >> Slapi_Entry **search_entries = NULL; >> size_t c; >> - int no_overlap = 0; >> + int ranges_valid = 0; >> const char *check_attr; >> char *errmsg = NULL; >> + struct domain_info *domain_info_head = NULL; >> >> ret = slapi_pblock_get(pb, SLAPI_IS_REPLICATED_OPERATION, >> &is_repl_op); >> if (ret != 0) { >> @@ -337,7 +526,10 @@ static int ipa_range_check_pre_op(Slapi_PBlock >> *pb, int modtype) >> goto done; >> } >> >> - ret = slapi_entry_to_range_info(entry, &new_range); >> + /* build a linked list of domain_info structs */ >> + domain_info_head = >> build_domain_to_forest_root_map(domain_info_head, ctx); >> + >> + ret = slapi_entry_to_range_info(domain_info_head, entry, >> &new_range); >> if (ret != 0) { >> LOG_FATAL("Failed to convert LDAP entry to range struct.\n"); >> goto done; >> @@ -381,19 +573,20 @@ static int ipa_range_check_pre_op(Slapi_PBlock >> *pb, int modtype) >> } >> >> for (c = 0; search_entries[c] != NULL; c++) { >> - ret = slapi_entry_to_range_info(search_entries[c], &old_range); >> + ret = slapi_entry_to_range_info(domain_info_head, >> search_entries[c], >> + &old_range); >> if (ret != 0) { >> LOG_FATAL("Failed to convert LDAP entry to range >> struct.\n"); >> goto done; >> } >> >> - no_overlap = ranges_overlap(new_range, old_range); >> + ranges_valid = check_ranges(new_range, old_range); >> free(old_range); >> old_range = NULL; >> - if (no_overlap != 0) { >> + if (ranges_valid != 0) { >> ret = LDAP_CONSTRAINT_VIOLATION; >> >> - switch (no_overlap){ >> + switch (ranges_valid){ >> case 1: >> errmsg = "New base range overlaps with existing base >> range."; >> break; >> @@ -409,6 +602,8 @@ static int ipa_range_check_pre_op(Slapi_PBlock >> *pb, int modtype) >> case 5: >> errmsg = "New secondary rid range overlaps with >> existing primary rid range."; >> break; >> + case 6: >> + errmsg = "New ID range has invalid type. All ranges >> in the same domain must be of the same type."; >> default: >> errmsg = "New range overlaps with existing one."; >> break; >> @@ -432,6 +627,14 @@ done: >> slapi_entry_free(entry); >> } >> >> + /* Remove the domain info linked list from memory */ >> + struct domain_info *next; >> + while(domain_info_head) { >> + next = domain_info_head->next; >> + free(domain_info_head); >> + domain_info_head = next; >> + } > Who would clean up all the strings in each record? > I think we also have the issue in the original code with freeing > range objects. A mere free(new_range) is not enough. > >> + >> if (ret != 0) { >> if (errmsg == NULL) { >> errmsg = "Range Check error"; >> -- >> 1.8.5.3 >> > > -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0158-3-Extend-ipa-range-check-DS-plugin-to-handle-range-typ.patch Type: text/x-patch Size: 16798 bytes Desc: not available URL: From tbabej at redhat.com Thu Mar 27 12:14:52 2014 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 27 Mar 2014 13:14:52 +0100 Subject: [Freeipa-devel] [PATCH 0161] ipa-range-check: Fix memory leaks when freeing range object Message-ID: <5334163C.7060007@redhat.com> Hi, When cleaning the range_info struct, simple free of the struct is not enough, we have to free contents of char pointers in the struct as well. https://fedorahosted.org/freeipa/ticket/4276 -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0161-ipa-range-check-Fix-memory-leaks-when-freeing-range-.patch Type: text/x-patch Size: 2265 bytes Desc: not available URL: From mkosek at redhat.com Thu Mar 27 12:15:04 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 27 Mar 2014 13:15:04 +0100 Subject: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf In-Reply-To: <1392908170.2329.4.camel@unused-4-145.brq.redhat.com> References: <5303801A.40502@redhat.com> <53038511.1050508@redhat.com> <1392741281.12450.18.camel@localhost.localdomain> <5304BB95.1040900@redhat.com> <5304D782.4060704@redhat.com> <1392828905.2352.5.camel@unused-4-145.brq.redhat.com> <530604DC.5090801@redhat.com> <1392908170.2329.4.camel@unused-4-145.brq.redhat.com> Message-ID: <53341648.6070602@redhat.com> On 02/20/2014 03:56 PM, Martin Basti wrote: > On Thu, 2014-02-20 at 14:36 +0100, Petr Spacek wrote: >> On 19.2.2014 17:55, Martin Basti wrote: >>> On Wed, 2014-02-19 at 17:10 +0100, Petr Spacek wrote: >>>> On 19.2.2014 15:11, Petr Spacek wrote: >>>>> On 18.2.2014 17:34, Nathaniel McCallum wrote: >>>>>> On Tue, 2014-02-18 at 17:06 +0100, Petr Viktorin wrote: >>>>>>> On 02/18/2014 04:45 PM, Petr Spacek wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Add wait_for_dns option to default.conf. >>>>>>>> >>>>>>>> This option makes record changes in DNS tree synchronous. >>>>>>>> IPA calls will wait until new data are visible over DNS protocol. >>>>>>>> >>>>>>>> It is intended only for testing - it should prevent tests from >>>>>>>> failing if there is bigger delay between change in LDAP and DNS. >>>>>>>> >>>>>>>> I would recommend value like 10 seconds. >>>>>>> >>>>>>> Here are a few Python nitpicks you requested. >>>>> >>>>> Thank you very much. This new version solves problems you found + adds proper >>>>> handling for real DNS timeouts. >>>>> >>>>>> It seems to me like a more general TimeoutError would be useful in a >>>>>> broader context. DNSTimeout seems overly narrow to me, unless I'm >>>>>> missing something. >>>>> >>>>> I would like to keep them separate. DNSTimeout shouldn't be handled at all >>>>> because it means that your DNS server or database is dead or broken in some >>>>> interesting way. >>>>> >>>>> I assume that generic TimeoutError could be interpreted as 'try it >>>>> again'/'failover' or something like that. >>>>> >>>>> Maybe the DNSTimeout is not the best name, I'm open to suggestions. >>>> >>>> I have sent the old version with new name, gggrrr. >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> Tests failed: >>> test_dns[92]: dnsrecord_add: Add A record to u'ns2' in zone >>> u'zone3.test' ... ok >>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>> runTest >>> self.test(*self.arg) >>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 291, in >>> >>> func = lambda: self.check(nice, **test) >>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 309, in >>> check >>> self.check_output(nice, cmd, args, options, expected, extra_check) >>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 348, in >>> check_output >>> got = api.Command[cmd](*args, **options) >>> File "/root/freeipa/ipalib/frontend.py", line 436, in __call__ >>> ret = self.run(*args, **options) >>> File "/root/freeipa/ipalib/frontend.py", line 761, in run >>> return self.forward(*args, **options) >>> File "/root/freeipa/ipalib/frontend.py", line 782, in forward >>> return self.Backend.rpcclient.forward(self.name, *args, **kw) >>> File "/root/freeipa/ipalib/rpc.py", line 836, in forward >>> return self._call_command(command, params) >>> File "/root/freeipa/ipalib/rpc.py", line 813, in _call_command >>> return command(*params) >>> File "/root/freeipa/ipalib/rpc.py", line 951, in _call >>> return self.__request(name, args) >>> File "/root/freeipa/ipalib/rpc.py", line 945, in __request >>> raise error_class(message=error['message']) >>> DNSTimeout: DNS query timeout: Expected {_kerberos.zone2.test. 86400 IN >>> TXT "IDM.LAB.ENG.BRQ.REDHAT.COM"} got {SERVFAIL} >>> >>> ====================================================================== >>> ERROR: test_dns[51]: dnsrecord_add: Add NS+DNAME record to u'zone2.test' >>> zone record using dnsrecord_add >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>> runTest >>> self.test(*self.arg) >>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 291, in >>> >>> func = lambda: self.check(nice, **test) >>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 309, in >>> check >>> self.check_output(nice, cmd, args, options, expected, extra_check) >>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 348, in >>> check_output >>> got = api.Command[cmd](*args, **options) >>> File "/root/freeipa/ipalib/frontend.py", line 436, in __call__ >>> ret = self.run(*args, **options) >>> File "/root/freeipa/ipalib/frontend.py", line 761, in run >>> return self.forward(*args, **options) >>> File "/root/freeipa/ipalib/frontend.py", line 782, in forward >>> return self.Backend.rpcclient.forward(self.name, *args, **kw) >>> File "/root/freeipa/ipalib/rpc.py", line 836, in forward >>> return self._call_command(command, params) >>> File "/root/freeipa/ipalib/rpc.py", line 813, in _call_command >>> return command(*params) >>> File "/root/freeipa/ipalib/rpc.py", line 951, in _call >>> return self.__request(name, args) >>> File "/root/freeipa/ipalib/rpc.py", line 945, in __request >>> raise error_class(message=error['message']) >>> DNSTimeout: DNS query timeout: Expected {zone2.test. 86400 IN NS >>> ns1.dnszone.test. >>> zone2.test. 86400 IN NS ns1.zone2.test.} got {SERVFAIL} >>> >>> configuration was: wait_for_dns=10 >>> >>> All tests passed without wait_for_dns option. >>> >>> Sometimes at first run, I get only error and testing is interrupted. >> >> I hope I covered all corner cases in this version. >> >> I renamed DNSTimeout exception to DNSDataMismatch in hope that it will be less >> confusing. >> > > A change in patch was required to pass doctest. > With this change ACK. > Updated patch attached. This patch seems to be in limbo for more than one month now. Do I get it right that it is now clear to be pushed? Is wait_for_dns enabled in our DNS test suite so that it is stable? Do we want it to be enabled? Thanks, Martin From amisnyov at redhat.com Thu Mar 27 13:38:25 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Thu, 27 Mar 2014 14:38:25 +0100 Subject: [Freeipa-devel] [PATCH] 562-563 webui: move RPC code from IPA module to its own module In-Reply-To: <5329B185.5030706@redhat.com> References: <5329B185.5030706@redhat.com> Message-ID: <20140327143825.052e13a8@unused-4-246.brq.redhat.com> On Wed, 19 Mar 2014 16:02:29 +0100 Petr Vobornik wrote: > depends on path #561(make navigation module independent on app module) > > [PATCH] 562 webui: move RPC code from IPA module to its own module > > - moves RPC code from ipa.js to it's own module > - part of ongoing effort where the ultimate goal is to get rid of > ipa.js and IPA namespace > > [PATCH] 563 webui: replace IPA.command usage with rpc.command > > Replace all IPA.command, IPA.batch_command and IPA.concurrent_command > usages by equivalents from rpc module. ACK Greets Adam From mkosek at redhat.com Thu Mar 27 13:40:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 27 Mar 2014 14:40:53 +0100 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <52CBF76F.5010200@redhat.com> References: <511A72D9.6090506@redhat.com> <511A75F0.7070801@redhat.com> <1360689791.3838.56.camel@willson.li.ssimo.org> <511B8632.7000709@redhat.com> <5159E560.6030603@redhat.com> <5162CC60.8040008@redhat.com> <516BD9D6.6020800@redhat.com> <52CA9082.3000000@redhat.com> <52CA91C1.3070804@redhat.com> <20140107062328.GE12003@redhat.com> <52CBF76F.5010200@redhat.com> Message-ID: <53342A65.3070808@redhat.com> On 01/07/2014 01:47 PM, Tomas Babej wrote: > > On 01/07/2014 07:23 AM, Alexander Bokovoy wrote: >> On Mon, 06 Jan 2014, Tomas Babej wrote: >>> >>> On 01/06/2014 12:16 PM, Tomas Babej wrote: >>>> On 04/15/2013 12:43 PM, Tomas Babej wrote: >>>>> On 04/08/2013 03:55 PM, Martin Kosek wrote: >>>>>> On 04/01/2013 09:52 PM, Rob Crittenden wrote: >>>>>>> Tomas Babej wrote: >>>>>>>> On 02/12/2013 06:23 PM, Simo Sorce wrote: >>>>>>>>> On Tue, 2013-02-12 at 18:03 +0100, Tomas Babej wrote: >>>>>>>>>> On 02/12/2013 05:50 PM, Tomas Babej wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This patch adds a check for krbprincipalexpiration attribute to >>>>>>>>>>> pre_bind operation >>>>>>>>>>> in ipa-pwd-extop dirsrv plugin. If the principal is expired, >>>>>>>>>>> auth is >>>>>>>>>>> denied and LDAP_INVALID_CREDENTIALS along with the error >>>>>>>>>>> message is >>>>>>>>>>> sent back to the client. Since krbprincipalexpiration >>>>>>>>>>> attribute is >>>>>>>>>> not >>>>>>>>>>> mandatory, if there is no value set, the check is passed. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3305 >>>>>>>>> Comments inline. >>>>>>>>>> @@ -1166,6 +1173,29 @@ static int ipapwd_pre_bind(Slapi_PBlock >>>>>>>>>> *pb) >>>>>>>>>> goto done; >>>>>>>>>> } >>>>>>>>>> + /* check the krbPrincipalExpiration attribute is present */ >>>>>>>>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>>>>>>>>> &attr); >>>>>>>>>> + if (!ret) { >>>>>>>>> ret is not a boolean so probably better ti use (ret != 0) >>>>>>>>> >>>>>>>>>> + /* if it is, check whether the principal has not >>>>>>>>>> expired */ >>>>>>>>>> + >>>>>>>>>> + principal_expire = slapi_entry_attr_get_charptr(entry, >>>>>>>>>> + "krbprincipalexpiration"); >>>>>>>>>> + memset(&expire_tm, 0, sizeof (expire_tm)); >>>>>>>>>> + >>>>>>>>>> + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", >>>>>>>>>> &expire_tm)){ >>>>>>>>> style issue missing space between ) and { >>>>>>>>> >>>>>>>>>> + expire_time = mktime(&expire_tm); >>>>>>>>>> + /* this might have overflown on 32-bit system */ >>>>>>>>> This comment does not help to point out what you want to put in >>>>>>>>> evidence. >>>>>>>>> if there is an overflow what is the consequence ? Or does it >>>>>>>>> mean the >>>>>>>>> next condition is taking that into account ? >>>>>>>> Yeah, this was rather ill-worded. Replaced by a rather verbose >>>>>>>> comment that hopefully clears things out. >>>>>>>>>> + if (current_time > expire_time && expire_time > 0){ >>>>>>>>> style issue missing space between ) and { >>>>>>>>> >>>>>>>>>> + LOG_FATAL("kerberos principal has expired in >>>>>>>>>> user >>>>>>>>>> entry: %s\n", >>>>>>>>>> + dn); >>>>>>>>> I think a better phrasing would be: "The kerberos principal on >>>>>>>>> %s is >>>>>>>>> expired\n" >>>>>>>>> >>>>>>>>>> + errMesg = "Kerberos principal has expired."; >>>>>>>>> s/has/is/ >>>>>>>>> >>>>>>>>> The rest looks good to me. >>>>>>>>> >>>>>>>>> Simo. >>>>>>>> Styling issues fixed and updated patch attached :) >>>>>>> Small nit, the expiration error should probably use 'in' not 'on'. >>>>>>> >>>>>>> I'm not sure LDAP_INVALID_CREDENTIALS is the right return code. This >>>>>>> implies >>>>>>> that the password is wrong. I think that LDAP_UNWILLING_TO_PERFORM >>>>>>> is probably >>>>>>> more correct here. It is what we return on other policy failures. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> Additional findings: >>>>>> >>>>>> 1) Lets not try to get current_time every time, but only when its >>>>>> needed (i.e. >>>>>> krbPrincipalExpiration is set) - AFAIK, it is not so cheap operation: >>>>>> >>>>>> + /* get current time*/ >>>>>> + current_time = time(NULL); >>>>>> >>>>>> 2) Why using slapi_entry_attr_get_charptr and thus let 389-ds find >>>>>> the >>>>>> attribute again when we already have a pointer for the attribute? >>>>>> Would >>>>>> slapi_attr_first_value following slapi_entry_attr_find be faster >>>>>> approach? >>>>>> >>>>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>>>>> &attr); >>>>>> + if (ret != 0) { >>>>>> + /* if it is, check whether the principal has not expired */ >>>>>> + >>>>>> + principal_expire = slapi_entry_attr_get_charptr(entry, >>>>>> + "krbprincipalexpiration"); >>>>>> >>>>>> This way, we would not create a copy of this attribute value - we do >>>>>> not need a >>>>>> copy, we just do check against it. >>>>>> >>>>>> >>>>>> 3) Shouldn't we return -1 in the end when the auth fails? We do that >>>>>> in other >>>>>> pre_callbacks. Otherwise we just return 0 (success): >>>>>> >>>>>> + if (auth_failed){ >>>>>> + slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS, NULL, >>>>>> errMesg, >>>>>> + 0, NULL); >>>>>> + } >>>>>> + >>>>>> return 0; >>>>>> >>>>>> Martin >>>>> Thank you both for the review. I updated and retested the patch, with >>>>> your suggestions incorporated. >>>>> >>>>> Tomas >>>>> >>>> I rebased the patch on top of current master. >>>> >>>> Bumping, since this is planned as part of 3.4 (and there were some >>>> requests for this feature). >>>> >>>> Tomas >>>> >>> >>> I updated the commit message to reflect better what the current version >>> of the patch implements. >>> >>> Tomas >> >>>> From a93d1ec3ca8c7b6e8e754b474257695ba9018e07 Mon Sep 17 00:00:00 2001 >>> From: Tomas Babej >>> Date: Mon, 6 Jan 2014 12:11:24 +0100 >>> Subject: [PATCH] ipa-pwd-extop: Deny LDAP binds for user accounts >>> with expired >>> principal >>> >>> Adds a check for krbprincipalexpiration attribute to pre_bind operation >>> in ipa-pwd-extop dirsrv plugin. If the principal is expired, auth is >>> denied and LDAP_UNWILLING_TO_PERFORM along with the error message is >>> sent back to the client. Since krbprincipalexpiration attribute is not >>> mandatory, if there is no value set, the check is passed. >>> >>> https://fedorahosted.org/freeipa/ticket/3305 >>> --- >>> daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 45 >>> ++++++++++++++++++++++- >>> 1 file changed, 44 insertions(+), 1 deletion(-) >>> >>> diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >>> b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >>> index >>> ef37b5e173359f9404b241c12d8a6dc6e77da128..568cba7189d1575d030b043daee61f713e9bac5f >>> 100644 >>> --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >>> +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c >>> @@ -1389,13 +1389,17 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >>> Slapi_Value *value = NULL; >>> Slapi_Attr *attr = NULL; >>> struct tm expire_tm; >>> + time_t current_time; >>> + time_t expire_time; >>> char *errMesg = "Internal operations error\n"; /* error message */ >>> char *expire = NULL; /* passwordExpirationTime attribute value */ >>> + char *principal_expire = NULL; /* krbPrincipalExpiration >>> attribute value */ >>> char *dn = NULL; /* bind DN */ >>> Slapi_Value *objectclass; >>> int method; /* authentication method */ >>> int ret = 0; >>> char *principal = NULL; >>> + bool auth_failed = false; >>> >>> LOG_TRACE("=>\n"); >>> >>> @@ -1422,7 +1426,7 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >>> const char *attrs_list[] = {SLAPI_USERPWD_ATTR, >>> "krbprincipalkey", "uid", >>> "krbprincipalname", "objectclass", >>> "passwordexpirationtime", >>> "passwordhistory", >>> - NULL}; >>> + "krbprincipalexpiration", NULL}; >>> >>> /* retrieve user entry */ >>> ret = ipapwd_getEntry(dn, &entry, (char **) attrs_list); >>> @@ -1438,6 +1442,39 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >>> goto done; >>> } >>> >>> + /* check the krbPrincipalExpiration attribute is present */ >>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>> &attr); >>> + if (ret == 0) { >>> + ret = slapi_attr_first_value(attr, &value); >>> + >>> + if (ret == 0) { >>> + /* if it is, check whether the principal has not expired */ >>> + principal_expire = slapi_value_get_string(value); >>> + memset(&expire_tm, 0, sizeof (expire_tm)); >>> + >>> + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", >>> &expire_tm)) { >>> + expire_time = mktime(&expire_tm); >>> + >>> + /* get current time */ >>> + current_time = time(NULL); >>> + >>> + /* mktime returns -1 if the tm struct cannot be >>> represented as >>> + * as calendar time (seconds since the Epoch). This >>> might >>> + * happen with tm structs that are ill-formated or >>> on 32-bit >>> + * platforms with dates that would cause overflow >>> + * (year 2038 and later). >>> + * In such cases, skip the expiration check. */ >>> + >>> + if (current_time > expire_time && expire_time > 0) { >>> + LOG_FATAL("kerberos principal in %s is >>> expired\n", dn); >>> + errMesg = "Kerberos principal is expired."; >>> + auth_failed = true; >>> + goto done; >>> + } >>> + } >> I think indenting is broken for these two brackets. >> >> > > Thanks Alexander, fixed. > > Updated version attached. > > Tomas > Simo, Alexander - are you know OK with Tomas' patch? The patch review is now taking more than a year, so I think it would be great to finish it :) Martin From pvoborni at redhat.com Thu Mar 27 13:55:30 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 27 Mar 2014 14:55:30 +0100 Subject: [Freeipa-devel] [PATCH] 562-563 webui: move RPC code from IPA module to its own module In-Reply-To: <20140327143825.052e13a8@unused-4-246.brq.redhat.com> References: <5329B185.5030706@redhat.com> <20140327143825.052e13a8@unused-4-246.brq.redhat.com> Message-ID: <53342DD2.8080102@redhat.com> On 27.3.2014 14:38, Misnyovszki Adam wrote: > On Wed, 19 Mar 2014 16:02:29 +0100 > Petr Vobornik wrote: > >> depends on path #561(make navigation module independent on app module) >> >> [PATCH] 562 webui: move RPC code from IPA module to its own module >> >> - moves RPC code from ipa.js to it's own module >> - part of ongoing effort where the ultimate goal is to get rid of >> ipa.js and IPA namespace >> >> [PATCH] 563 webui: replace IPA.command usage with rpc.command >> >> Replace all IPA.command, IPA.batch_command and IPA.concurrent_command >> usages by equivalents from rpc module. > > ACK > Greets > Adam > Pushed to master: * d5cf0b273ad511d6cb99fbcb900eff528fe172df webui: move RPC code from IPA module to its own module * 06a7a1b3cb277284448dd8344940395f0b29cd70 webui: replace IPA.command usage with rpc.command -- Petr Vobornik From simo at redhat.com Thu Mar 27 14:35:39 2014 From: simo at redhat.com (Simo Sorce) Date: Thu, 27 Mar 2014 10:35:39 -0400 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <52CBF76F.5010200@redhat.com> References: <511A72D9.6090506@redhat.com> <511A75F0.7070801@redhat.com> <1360689791.3838.56.camel@willson.li.ssimo.org> <511B8632.7000709@redhat.com> <5159E560.6030603@redhat.com> <5162CC60.8040008@redhat.com> <516BD9D6.6020800@redhat.com> <52CA9082.3000000@redhat.com> <52CA91C1.3070804@redhat.com> <20140107062328.GE12003@redhat.com> <52CBF76F.5010200@redhat.com> Message-ID: <1395930939.1844.60.camel@willson.li.ssimo.org> this need rebasing due to OTP patches, however comments inline. On Tue, 2014-01-07 at 13:47 +0100, Tomas Babej wrote: > diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c > b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c > index > ef37b5e173359f9404b241c12d8a6dc6e77da128..df74a671c219f9b4aaa407f2ebd68f41669817b4 100644 > --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c > +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c > @@ -1389,13 +1389,17 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) > Slapi_Value *value = NULL; > Slapi_Attr *attr = NULL; > struct tm expire_tm; > + time_t current_time; > + time_t expire_time; > char *errMesg = "Internal operations error\n"; /* error message > */ > char *expire = NULL; /* passwordExpirationTime attribute value */ > + char *principal_expire = NULL; /* krbPrincipalExpiration > attribute value */ > char *dn = NULL; /* bind DN */ > Slapi_Value *objectclass; > int method; /* authentication method */ > int ret = 0; > char *principal = NULL; > + bool auth_failed = false; > > LOG_TRACE("=>\n"); > > @@ -1422,7 +1426,7 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) > const char *attrs_list[] = {SLAPI_USERPWD_ATTR, > "krbprincipalkey", "uid", > "krbprincipalname", "objectclass", > "passwordexpirationtime", > "passwordhistory", > - NULL}; > + "krbprincipalexpiration", NULL}; > > /* retrieve user entry */ > ret = ipapwd_getEntry(dn, &entry, (char **) attrs_list); > @@ -1438,6 +1442,39 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) > goto done; > } > > + /* check the krbPrincipalExpiration attribute is present */ > + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", > &attr); > + if (ret == 0) { > + ret = slapi_attr_first_value(attr, &value); > + > + if (ret == 0) { > + /* if it is, check whether the principal has not expired > */ > + principal_expire = slapi_value_get_string(value); Why not just use a simpler condition from the start of this very nested sequence of checks ? Like: /* check the krbPrincipalExpiration attribute is present */ principal_expire = slapi_entry_attr_get_charptr(entry, "krbPrincipalExpiration") if (principal_expire) { memset(... I do not see the value of digging through the attr with that many calls. > + memset(&expire_tm, 0, sizeof (expire_tm)); > + > + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", > &expire_tm)) { > + expire_time = mktime(&expire_tm); > + > + /* get current time */ > + current_time = time(NULL); > + > + /* mktime returns -1 if the tm struct cannot be > represented as > + * as calendar time (seconds since the Epoch). This > might > + * happen with tm structs that are ill-formated or on > 32-bit > + * platforms with dates that would cause overflow > + * (year 2038 and later). > + * In such cases, skip the expiration check. */ > + > + if (current_time > expire_time && expire_time > 0) { > + LOG_FATAL("kerberos principal in %s is expired > \n", dn); > + errMesg = "Kerberos principal is expired."; This message is sent back to the client, perhaps we should say: "Account is expired", it seem to me a more understandable error for a casual user/admin. > + auth_failed = true; Technically no auth was performed also I am not sure why we need a boolean ? Just set rc = LDAP_UNWILLING_TO_PERFORM ? > + goto done; > + } > + } > + } > + } > + > /* we aren't interested in host principals */ > objectclass = slapi_value_new_string("ipaHost"); > if ((slapi_entry_attr_has_syntax_value(entry, > SLAPI_ATTR_OBJECTCLASS, objectclass)) == 1) { > @@ -1560,6 +1597,12 @@ done: > slapi_entry_free(entry); > free_ipapwd_krbcfg(&krbcfg); > > + if (auth_failed){ > + slapi_send_ldap_result(pb, LDAP_UNWILLING_TO_PERFORM, NULL, > errMesg, and here: if (rc != LDAP_SUCCESS) { slapi_send_ldap_result(pb, rc, NULL, errMesg, 0, NULL); > + 0, NULL); > + return -1; > + } > + > return 0; > } HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From amisnyov at redhat.com Thu Mar 27 14:37:47 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Thu, 27 Mar 2014 15:37:47 +0100 Subject: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added In-Reply-To: <5332C4FB.4060007@redhat.com> References: <20140314173149.30aedb3b@unused-4-246.brq.redhat.com> <53233BB7.9010104@redhat.com> <20140320141951.152522d4@unused-4-246.brq.redhat.com> <20140320162200.1de0e391@unused-4-246.brq.redhat.com> <532C0674.3030206@redhat.com> <532C074C.1020903@redhat.com> <20140321120032.23243622@unused-4-246.brq.redhat.com> <532C24AE.8090406@redhat.com> <532C2977.7070401@redhat.com> <532C2B3D.9010401@redhat.com> <20140324114221.6ae6b214@unused-4-246.brq.redhat.com> <53305811.20509@redhat.com> <20140325153625.1d6f1187@unused-4-246.brq.redhat.com> <5332C4FB.4060007@redhat.com> Message-ID: <20140327153747.4d91dfd4@unused-4-246.brq.redhat.com> On Wed, 26 Mar 2014 13:15:55 +0100 Petr Viktorin wrote: > On 03/25/2014 03:36 PM, Misnyovszki Adam wrote: > > On Mon, 24 Mar 2014 17:06:41 +0100 > > Martin Kosek wrote: > > > >> On 03/24/2014 11:42 AM, Misnyovszki Adam wrote: > >>> On Fri, 21 Mar 2014 13:06:21 +0100 > >>> Petr Viktorin wrote: > >>> > >>>> On 03/21/2014 12:58 PM, Martin Kosek wrote: > >>>>> On 03/21/2014 12:38 PM, Petr Viktorin wrote: > >>>>>> On 03/21/2014 12:00 PM, Misnyovszki Adam wrote: > >>>>>>> On Fri, 21 Mar 2014 10:33:00 +0100 > >>>>>>> Petr Viktorin wrote: > >>>>>>> > >>>>>>>> On 03/21/2014 10:29 AM, Petr Viktorin wrote: > >>>>>>>>> On 03/20/2014 04:22 PM, Misnyovszki Adam wrote: > >>>>>>>>>> On Thu, 20 Mar 2014 14:19:51 +0100 > >>>>>>>>>> Misnyovszki Adam wrote: > >>>>>>>>>> > >>>>>>>>>>> On Fri, 14 Mar 2014 13:26:15 -0400 > >>>>>>>>>>> Rob Crittenden wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Misnyovszki Adam wrote: > >>>>>>>>>>>>> Hi, > >>>>>>>>>>>>> > >>>>>>>>>>>>> automember-rebuild uses asynchronous 389 task, and > >>>>>>>>>>>>> returned success even if the task didn't run. This patch > >>>>>>>>>>>>> fixes this issue adding a --nowait parameter to 'ipa > >>>>>>>>>>>>> automember-rebuild', defaulting to False, thus when the > >>>>>>>>>>>>> script runs without it, it waits for the > >>>>>>>>>>>>> 'nstaskexitcode' attribute, which means the task has > >>>>>>>>>>>>> finished, according to > >>>>>>>>>>>>> http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP#Implementation. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Old usage can be enabled using --nowait. > >>>>>>>>>>>>> > >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4239 > >>>>>>>>>>>>> > >>>>>>>>>>>>> Request for comments: > >>>>>>>>>>>>> - Should I add a parameter to specify the polling time? > >>>>>>>>>>>>> (now 1ms) > >>>>>>>>>>>>> - Should I add a parameter to specify the maximum > >>>>>>>>>>>>> polling number? Now if something fails about creating > >>>>>>>>>>>>> the task, it polls forever. > >>>>>>>>>>>>> - Obviously, if these parameters should be added, there > >>>>>>>>>>>>> should be a reasonable default for them (~ > >>>>>>>>>>>>> Required=False, Default=X). > >>>>>>>>>>>> > >>>>>>>>>>>> I don't think you need a polling time, esp since this is > >>>>>>>>>>>> hidden from the user, but I think that is probably too > >>>>>>>>>>>> short and you may end up hammering the LDAP server. > >>>>>>>>>>>> > >>>>>>>>>>>> I also wonder if there should be some maximum wait time. > >>>>>>>>>>>> I don't like loops that can never exit. I'm at a loss for > >>>>>>>>>>>> what that time should be though. And we'd need to spell > >>>>>>>>>>>> out that we gave up waiting, not that the task > >>>>>>>>>>>> necessarily failed. So rather than having a polling time > >>>>>>>>>>>> option, rename nowait into wait_for=20, so wait for 20 > >>>>>>>>>>>> seconds. Or something like that. > >>>>>>>>>>>> > >>>>>>>>>>>> I'd suggest using get_entry since you already know the > >>>>>>>>>>>> full DN and there is only ever one. It would make this > >>>>>>>>>>>> much more readable. > >>>>>>>>>>>> > >>>>>>>>>>>> I wonder if some top-level documentation should be added > >>>>>>>>>>>> to flesh this out some more. This does, for example, > >>>>>>>>>>>> return False in one case. The meaning for that should be > >>>>>>>>>>>> spelled out. > >>>>>>>>>>>> > >>>>>>>>>>>> rob > >>>>>>>>>>> > >>>>>>>>>>> Hi, > >>>>>>>>>>> personally I would keep --no-wait, with a delay of 1 > >>>>>>>>>>> seconds, and a maximum waiting time for 60 seconds. > >>>>>>>>>>> Questions is, do we need to parameterize with other > >>>>>>>>>>> parameters(wait-for to the maximum time, and/or poll-delay > >>>>>>>>>>> for the delay time, both not required), or it is not a > >>>>>>>>>>> case which worth to develop? Greets > >>>>>>>>>>> Adam > >>>>>>>>>> > >>>>>>>>>> Hi, > >>>>>>>>>> here are the corrections Petr asked, also the other patch > >>>>>>>>>> conatins the plugin registration refactor. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks! > >>>>>>>>> > >>>>>>>>> You forgot an alternate summary for the --no-wait case. > >>>>>>>>> (Make sure to output the DN in this case, so it's possible > >>>>>>>>> to poll for it.) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Instead of `task['nstaskexitcode'][0]` please use > >>>>>>>>> `task.single_value['nstaskexitcode']`. > >>>>>> > >>>>>> There's one more `task['nstaskexitcode'][0]`. (Perhaps putting > >>>>>> it in a variable would be better?) > >>>>>> > >>>>>>>>> > >>>>>>>>> Here: > >>>>>>>>> > >>>>>>>>> raise errors.DatabaseError( > >>>>>>>>> desc=_("Automember rebuild membership task > >>>>>>>>> failed"), info=_("nstaskexitcode = '%s'" % > >>>>>>>>> str(task['nstaskexitcode'][0]))) > >>>>>>>>> > >>>>>>>>> there's no need to call str() on %'s argument. > >>>>>>>>> Also, use natural language (like "Task exit code: %s"), > >>>>>>>>> otherwise there's no need to mark the message for > >>>>>>>>> translation. > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> And one more thing: Please bump the minor version in the > >>>>>>>> VERSION file when API.txt changes. > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> Hi, > >>>>>>> everything is corrected! > >>>>>>> Greets > >>>>>>> Adam > >>>>>>> > >>>>>> > >>>>>> Sorry for dragging this so long, but: > >>>>>> The DN should not be a part of the summary, because that makes > >>>>>> it hard to parse when using the API. It should be returned as > >>>>>> a part of the result. To do that, you'd need to change the > >>>>>> output type: > >>>>>> > >>>>>> has_output = output.standard_entry > >>>>>> has_output_params = ( > >>>>>> DNParam( > >>>>>> 'dn', > >>>>>> label=_('Task automember'), > >>>>>> doc=_('DN of the started task'), > >>>>>> ), > >>>>>> ) > >>>>>> > >>>>>> and provide a dict in result, instead of True. (And with > >>>>>> --no-wait, add the dn to that dict.) > >>>>>> > >>>>> > >>>>> Do really want to use 'dn' for the DNParam? dn is already used > >>>>> for standard entry DN when --all is used, right? > >>>>> "automembertaskdn" may be better. > >>>> > >>>> Well, I think "DN of the added entry" is exactly what this is. > >>>> > >>>>> Also, "Task automember" label sounds strange to me, would > >>>>> "Automember task DN" be better? > >>>> > >>>> I meant "Task DN", sorry for the thinko. > >>>> > >>>> > >>> > >>> One more thing, which came to my mind after reviewing the code for > >>> myself once again, if the task fails with an exit code other than > >>> 0, there is a DatabaseError raised, which is just fine. But in the > >>> info, should I specify not only the exit code, but also the DN of > >>> the task, or is it unnecessary? > >>> Thanks > >>> Adam > >> > >> DS tasks usually have the error in some of their attributes, so if > >> there is such attribute, I would report what the error is. It is > >> easier to use than having to run ldapsearch against the given DN. > >> > >> If there is not such attribute, providing the DN would be a good > >> idea. > >> > >> Martin > > Hi, > > fixed the output parameter issue, and also with that, API is > > updated. If an error occurs, now the function returns the > > nstaskstatus attribute, and the DN of the failed task. Also, I > > added a 3600 second ttl to the task, because the original was a few > > seconds(I haven't found the default value for that anywhere), to > > ensure that the task doesn't disappear before interaction is > > required. Attached the refactor of plugin registration patch also. > > > > Greets > > Adam > > > Looks great! I'm just concerned about the error returned when the > task takes too long: > $ ipa automember-rebuild --type group > ipa: ERROR: LDAP timeout > I don't think it's sufficiently clear from this that waiting for the > task timed out, but the task was actually started successfully. A > custom error with a more descriptive message would be useful. > > > Also I've noticed that the "nstaskstatus" of a successful task is: > Automember rebuild task finished. Processed (1) entries. > This looks helpful; we could return it as the summary. > Hi, both fixed. Greets Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0007-6-automember-rebuild-nowait-feature-added.patch Type: text/x-patch Size: 6840 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0008-plugin-registration-refactoring-for-automembership.patch Type: text/x-patch Size: 4966 bytes Desc: not available URL: From pvoborni at redhat.com Thu Mar 27 15:07:55 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 27 Mar 2014 16:07:55 +0100 Subject: [Freeipa-devel] [PATCH] 565-568 webui: field and widget binding refactoring Message-ID: <53343ECB.8070601@redhat.com> The last refactoring I did while implementing RCUE login or more precisely support for standalone facets which have forms but are not details facets. [PATCH] webui: field and widget binding refactoring This is a Web UI wide change. Fields and Widgets binding was refactored to enable proper two-way binding between them. This should allow to have one source of truth (field) for multiple consumers - widgets or something else. One of the goal is to have fields and widget implementations independent on each other. So that one could use a widget without field or use one field for multiple widgets, etc.. Basically a fields logic was split into separate components: - adapters - parsers & formatters - binder Adapters - extract data from data source (FreeIPA RPC command result) - prepares them for commands. Parsers - parse extracted data to format expected by field - parse widget value to format expected by field Formatters - format field value to format suitable for widgets - format field value to format suitable for adapter Binder - is a communication bridge between field and widget - listens to field's and widget's events and call appropriate methods Some side benefits: - better validation reporting in multivalued widget [PATCH] webui: replace widget's hidden property with visible Hidden was used only in ACI. There is no reason to have two properties which are negations of each other. [PATCH] webui: change widget updated event into value change event This change allow us to use proper two way binding between a field and a widget. In previous implementation field was not changed if something changed the value of a widget in 'update'. Now listeners are notified when the widget value is changed by: calling 'update', 'set_value' or by user change. [PATCH] webui-tests: binding test suite Add basic tests for two-way binding between a field and two widgets -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0565-webui-field-and-widget-binding-refactoring.patch Type: text/x-patch Size: 124248 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0566-webui-replace-widget-s-hidden-property-with-visible.patch Type: text/x-patch Size: 6276 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0567-webui-change-widget-updated-event-into-value-change-.patch Type: text/x-patch Size: 13075 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0568-webui-tests-binding-test-suite.patch Type: text/x-patch Size: 7081 bytes Desc: not available URL: From amisnyov at redhat.com Thu Mar 27 15:56:03 2014 From: amisnyov at redhat.com (Misnyovszki Adam) Date: Thu, 27 Mar 2014 16:56:03 +0100 Subject: [Freeipa-devel] [PATCH]Extending user plugin with employeenumber field In-Reply-To: <20140326140750.126d6821@unused-4-246.brq.redhat.com> References: <1796318445.1683710.1392993953023.JavaMail.zimbra@redhat.com> <53076B73.9020008@redhat.com> <20140321101355.06e5efaa@unused-4-246.brq.redhat.com> <20140321110051.1a50f943@unused-4-246.brq.redhat.com> <53318523.7000601@redhat.com> <20140325182653.551fee3d@unused-4-246.brq.redhat.com> <20140326140750.126d6821@unused-4-246.brq.redhat.com> Message-ID: <20140327165603.2e79792a@unused-4-246.brq.redhat.com> On Wed, 26 Mar 2014 14:07:50 +0100 Misnyovszki Adam wrote: > On Tue, 25 Mar 2014 18:26:53 +0100 > Misnyovszki Adam wrote: > > > On Tue, 25 Mar 2014 14:31:15 +0100 > > Petr Vobornik wrote: > > > > > On 21.3.2014 11:00, Misnyovszki Adam wrote: > > > > On Fri, 21 Mar 2014 10:13:55 +0100 > > > > Misnyovszki Adam wrote: > > > > > > > >> On Fri, 21 Feb 2014 16:06:27 +0100 > > > >> Petr Vobornik wrote: > > > >> > > > >>> On 21.2.2014 15:45, Adam Misnyovszki wrote: > > > >>>> Hi, > > > >>>> According to http://tools.ietf.org/html/rfc2798 ipa client > > > >>>> and web ui extended with employeenumber field. > > > >>>> > > > >>>> https://fedorahosted.org/freeipa/ticket/4165 > > > >>>> > > > >>>> Question is, that should we extend user with other fields > > > >>>> which are in the RFC, (carLicense, departmentNumber, > > > >>>> employeeType, etc) if we already touched this code? > > > >>>> > > > >>>> Thanks > > > >>>> Adam > > > >>>> > > > >>> > > > >>> > > > >>> + Int('employeenumber?', > > > >>> + label=_('Employee ID'), > > > >>> + minvalue=1, > > > >>> + ), > > > >>> > > > >>> > > > >>> Why Int and different label? IMO it should be Str and > > > >>> 'Employee Number' > > > >>> > > > >>> 2.4. Employee Number > > > >>> > > > >>> Numeric or alphanumeric identifier assigned to a person, > > > >>> typically based on order of hire or association with an > > > >>> organization. Single valued. > > > >>> > > > >>> ( 2.16.840.1.113730.3.1.3 > > > >>> NAME 'employeeNumber' > > > >>> DESC 'numerically identifies an employee within an > > > >>> organization' EQUALITY caseIgnoreMatch > > > >>> SUBSTR caseIgnoreSubstringsMatch > > > >>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 > > > >>> SINGLE-VALUE ) > > > >>> > > > >> Hi, > > > >> fixed, also some other fields added. Note, that according to > > > >> the rfc, > > > > > > >> licence plate field should be multivalue, should I cange > > > >> that(it is an existing field). > > > > > > yes > > > > > > > > > >> Also, should I write test cases(especially for > > > >> preferredlanguage)? > > > > > > Testing new functionality helps. > > > > > > >> Greets > > > >> Adam > > > > > > > > self NACK, > > > > VERSION bump because API change > > > > > > It requires another rebase. > > > > > > > > > > > Greets > > > > Adam > > > > > > > > > > 1) Is there a reason to have label 'Employee ID' instead of > > > 'Employee Number' which is in RFC 2798? > > > > > > + label=_('Employee ID'), > > > > > > > > > 2) Department number seems to be multivalued as well: > > > ( 2.16.840.1.113730.3.1.2 > > > NAME 'departmentNumber' > > > DESC 'identifies a department within an organization' > > > EQUALITY caseIgnoreMatch > > > SUBSTR caseIgnoreSubstringsMatch > > > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > > > > > 3) The regex for preferredlanguage: > > > > > > + pattern='^[a-zA-Z]{1,8}[-[a-zA-Z]{1,8}]?$', > > > > > > doesn't match the expression in RFC 2068. It's only part of it. > > > > > > > > > Accept-Language = "Accept-Language" ":" > > > 1#( language-range [ ";" "q" "=" > > > qvalue ] ) > > > > > > language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | > > > "*" ) > > > > > > http://tools.ietf.org/html/rfc2068#section-14.4 > > > > > > RFC 2798 ( http://tools.ietf.org/html/rfc2798#section-2.7 ) says > > > that you should omit only the `"Accept-Language" ":"` sequence. > > > > > > > > > > See the updates in the attached patch. > > Greets > > Adam > > The preferredLanguage regex pattern and error message has been > modified to comply with RFC, according to conversation with Petr. > Thanks > Adam > The regex pattern corrected, unit tests added for preferredlanguage. Greets Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-amisnyov-0005-6-Extending-user-plugin-with-inetOrgPerson-fields.patch Type: text/x-patch Size: 17126 bytes Desc: not available URL: From pspacek at redhat.com Thu Mar 27 16:44:27 2014 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 27 Mar 2014 17:44:27 +0100 Subject: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf In-Reply-To: <53341648.6070602@redhat.com> References: <5303801A.40502@redhat.com> <53038511.1050508@redhat.com> <1392741281.12450.18.camel@localhost.localdomain> <5304BB95.1040900@redhat.com> <5304D782.4060704@redhat.com> <1392828905.2352.5.camel@unused-4-145.brq.redhat.com> <530604DC.5090801@redhat.com> <1392908170.2329.4.camel@unused-4-145.brq.redhat.com> <53341648.6070602@redhat.com> Message-ID: <5334556B.80607@redhat.com> On 27.3.2014 13:15, Martin Kosek wrote: > On 02/20/2014 03:56 PM, Martin Basti wrote: >> On Thu, 2014-02-20 at 14:36 +0100, Petr Spacek wrote: >>> On 19.2.2014 17:55, Martin Basti wrote: >>>> On Wed, 2014-02-19 at 17:10 +0100, Petr Spacek wrote: >>>>> On 19.2.2014 15:11, Petr Spacek wrote: >>>>>> On 18.2.2014 17:34, Nathaniel McCallum wrote: >>>>>>> On Tue, 2014-02-18 at 17:06 +0100, Petr Viktorin wrote: >>>>>>>> On 02/18/2014 04:45 PM, Petr Spacek wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Add wait_for_dns option to default.conf. >>>>>>>>> >>>>>>>>> This option makes record changes in DNS tree synchronous. >>>>>>>>> IPA calls will wait until new data are visible over DNS protocol. >>>>>>>>> >>>>>>>>> It is intended only for testing - it should prevent tests from >>>>>>>>> failing if there is bigger delay between change in LDAP and DNS. >>>>>>>>> >>>>>>>>> I would recommend value like 10 seconds. >>>>>>>> >>>>>>>> Here are a few Python nitpicks you requested. >>>>>> >>>>>> Thank you very much. This new version solves problems you found + adds proper >>>>>> handling for real DNS timeouts. >>>>>> >>>>>>> It seems to me like a more general TimeoutError would be useful in a >>>>>>> broader context. DNSTimeout seems overly narrow to me, unless I'm >>>>>>> missing something. >>>>>> >>>>>> I would like to keep them separate. DNSTimeout shouldn't be handled at all >>>>>> because it means that your DNS server or database is dead or broken in some >>>>>> interesting way. >>>>>> >>>>>> I assume that generic TimeoutError could be interpreted as 'try it >>>>>> again'/'failover' or something like that. >>>>>> >>>>>> Maybe the DNSTimeout is not the best name, I'm open to suggestions. >>>>> >>>>> I have sent the old version with new name, gggrrr. >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> >>>> Tests failed: >>>> test_dns[92]: dnsrecord_add: Add A record to u'ns2' in zone >>>> u'zone3.test' ... ok >>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>>> runTest >>>> self.test(*self.arg) >>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 291, in >>>> >>>> func = lambda: self.check(nice, **test) >>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 309, in >>>> check >>>> self.check_output(nice, cmd, args, options, expected, extra_check) >>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 348, in >>>> check_output >>>> got = api.Command[cmd](*args, **options) >>>> File "/root/freeipa/ipalib/frontend.py", line 436, in __call__ >>>> ret = self.run(*args, **options) >>>> File "/root/freeipa/ipalib/frontend.py", line 761, in run >>>> return self.forward(*args, **options) >>>> File "/root/freeipa/ipalib/frontend.py", line 782, in forward >>>> return self.Backend.rpcclient.forward(self.name, *args, **kw) >>>> File "/root/freeipa/ipalib/rpc.py", line 836, in forward >>>> return self._call_command(command, params) >>>> File "/root/freeipa/ipalib/rpc.py", line 813, in _call_command >>>> return command(*params) >>>> File "/root/freeipa/ipalib/rpc.py", line 951, in _call >>>> return self.__request(name, args) >>>> File "/root/freeipa/ipalib/rpc.py", line 945, in __request >>>> raise error_class(message=error['message']) >>>> DNSTimeout: DNS query timeout: Expected {_kerberos.zone2.test. 86400 IN >>>> TXT "IDM.LAB.ENG.BRQ.REDHAT.COM"} got {SERVFAIL} >>>> >>>> ====================================================================== >>>> ERROR: test_dns[51]: dnsrecord_add: Add NS+DNAME record to u'zone2.test' >>>> zone record using dnsrecord_add >>>> ---------------------------------------------------------------------- >>>> Traceback (most recent call last): >>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>>> runTest >>>> self.test(*self.arg) >>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 291, in >>>> >>>> func = lambda: self.check(nice, **test) >>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 309, in >>>> check >>>> self.check_output(nice, cmd, args, options, expected, extra_check) >>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line 348, in >>>> check_output >>>> got = api.Command[cmd](*args, **options) >>>> File "/root/freeipa/ipalib/frontend.py", line 436, in __call__ >>>> ret = self.run(*args, **options) >>>> File "/root/freeipa/ipalib/frontend.py", line 761, in run >>>> return self.forward(*args, **options) >>>> File "/root/freeipa/ipalib/frontend.py", line 782, in forward >>>> return self.Backend.rpcclient.forward(self.name, *args, **kw) >>>> File "/root/freeipa/ipalib/rpc.py", line 836, in forward >>>> return self._call_command(command, params) >>>> File "/root/freeipa/ipalib/rpc.py", line 813, in _call_command >>>> return command(*params) >>>> File "/root/freeipa/ipalib/rpc.py", line 951, in _call >>>> return self.__request(name, args) >>>> File "/root/freeipa/ipalib/rpc.py", line 945, in __request >>>> raise error_class(message=error['message']) >>>> DNSTimeout: DNS query timeout: Expected {zone2.test. 86400 IN NS >>>> ns1.dnszone.test. >>>> zone2.test. 86400 IN NS ns1.zone2.test.} got {SERVFAIL} >>>> >>>> configuration was: wait_for_dns=10 >>>> >>>> All tests passed without wait_for_dns option. >>>> >>>> Sometimes at first run, I get only error and testing is interrupted. >>> >>> I hope I covered all corner cases in this version. >>> >>> I renamed DNSTimeout exception to DNSDataMismatch in hope that it will be less >>> confusing. >>> >> >> A change in patch was required to pass doctest. >> With this change ACK. >> Updated patch attached. > > This patch seems to be in limbo for more than one month now. Do I get it right > that it is now clear to be pushed? > > Is wait_for_dns enabled in our DNS test suite so that it is stable? Do we want > it to be enabled? Ah, good point. In meantime I have released bind-dyndb-ldap 4.x and nobody complained about race conditions and mysterious errors in test suite. Apparently, it is faster than I expected :-) I will try to finish the patch but I wouldn't enable it if it is not necessary. -- Petr^2 Spacek From mharmsen at redhat.com Thu Mar 27 21:35:31 2014 From: mharmsen at redhat.com (Matthew Harmsen) Date: Thu, 27 Mar 2014 14:35:31 -0700 Subject: [Freeipa-devel] Fwd: Re: FreeIPA 3.3.5 In-Reply-To: <533497C4.8080107@redhat.com> References: <533497C4.8080107@redhat.com> Message-ID: <533499A3.1000900@redhat.com> Re-sending since I am now subscribed to this list. -------- Original Message -------- Subject: Re: FreeIPA 3.3.5 Date: Thu, 27 Mar 2014 14:27:32 -0700 From: Matthew Harmsen To: Martin Kosek , freeipa-devel at redhat.com On 03/27/14 04:45, Martin Kosek wrote: > Hello all! > > I think we are close to releasing next bugfixing version on FreeIPA 3.3.5. We > have a lot of bug fixes to offer, especially in the AD Trust area. I wrote the > changelog to our wiki, fixes or suggestions welcome: > > http://www.freeipa.org/page/Releases/3.3.5 > > I have just one last concern though, the remaining PKI clone installation issue > I found: > > https://fedorahosted.org/pki/ticket/933 > > Do we want to release before this ticket is closed or wait? Question is if > fixing Dogtag 10 based clone installation is enough to allow us to release or > not. Matthew (CCed), do we have any ETA when the fix would be available? > Ticket #933 is next on my list, but I must replicate the issue first, and then come up with a patch. My best guess is that I would not have anything before sometime next week. This issue only involves replicating a FreeIPA system which is using Dogtag 9 (e. g. - RHEL 6, Fedora 17) to a Free IPA system using Dogtag 10.1 (e. g. - Fedora 20 - the change was made in pki-core-10.1.1.fc20). Regardless of your decision, this issue will be the next bug fixed, and it is planned to be included in the next build (e. g. - pki-core-10.1.2.fc20). -- Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From redhatrises at gmail.com Fri Mar 28 01:09:08 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Thu, 27 Mar 2014 19:09:08 -0600 Subject: [Freeipa-devel] [PATCH] [DOC] Add note about additional nameservers in resolv.conf In-Reply-To: <1395915293.2269.7.camel@unused-4-145.brq.redhat.com> References: <1395912216.2269.5.camel@unused-4-145.brq.redhat.com> <5333F056.2030100@redhat.com> <1395915293.2269.7.camel@unused-4-145.brq.redhat.com> Message-ID: I believe that Martin is right about the server installer no longer putting 127.0.0.1 in the resolv.conf. Here is a mod patch to address Martin's concern if the note needs to be changed to show a real IP address. Gabe On Thu, Mar 27, 2014 at 4:14 AM, Martin Basti wrote: > On Thu, 2014-03-27 at 10:33 +0100, Petr Spacek wrote: > > On 27.3.2014 10:23, Martin Basti wrote: > > > On Wed, 2014-03-26 at 17:40 -0600, Gabe Alford wrote: > > >> All, > > >> > > >> Please review patch for https://fedorahosted.org/freeipa/ticket/3085 > > >> > > >> Added note that 'nameserver 127.0.0.1' is added to resolv.conf, that > > >> it is recommended to add more replicas to resolv.conf, and the max > > >> nameservers allowed in resolv.conf. > > >> > > > Actually, my ipa-server-install puts into /etc/resolv.conf its ip > > > address itself not localhost > > > > > > After fresh install: > > > #cat /etc/resolv.conf > > > search example.com > > > nameserver 10.*.*.* > > > > IMHO /etc/resolv.conf was overwritten by DHCPd (when IPA installation was > > finished). > > > > I inspect ipa-server-install source code and installation adds to > resolv.conf a real server address. > > DHCP leave note in resolv.conf when generate it. > > -- > Martin^2 Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0012-DOC-Update-resolv.conf-nameserver-note-to-reflect-re.patch Type: text/x-patch Size: 1286 bytes Desc: not available URL: From pspacek at redhat.com Fri Mar 28 07:38:04 2014 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 28 Mar 2014 08:38:04 +0100 Subject: [Freeipa-devel] [PATCH] [DOC] Add note about additional nameservers in resolv.conf In-Reply-To: References: <1395912216.2269.5.camel@unused-4-145.brq.redhat.com> <5333F056.2030100@redhat.com> <1395915293.2269.7.camel@unused-4-145.brq.redhat.com> Message-ID: <533526DC.1080803@redhat.com> On 28.3.2014 02:09, Gabe Alford wrote: > I believe that Martin is right about the server installer no longer putting > 127.0.0.1 in the resolv.conf. Here is a mod patch to address Martin's > concern if the note needs to be changed to show a real IP address. Okay, that is new for me :-) Conditional ACK. Please change the IP address before push to something from: http://tools.ietf.org/html/rfc5737#section-3 192.0.2.1 sounds like a good candidate. Thanks! Petr^2 Spacek > On Thu, Mar 27, 2014 at 4:14 AM, Martin Basti wrote: > >> On Thu, 2014-03-27 at 10:33 +0100, Petr Spacek wrote: >>> On 27.3.2014 10:23, Martin Basti wrote: >>>> On Wed, 2014-03-26 at 17:40 -0600, Gabe Alford wrote: >>>>> All, >>>>> >>>>> Please review patch for https://fedorahosted.org/freeipa/ticket/3085 >>>>> >>>>> Added note that 'nameserver 127.0.0.1' is added to resolv.conf, that >>>>> it is recommended to add more replicas to resolv.conf, and the max >>>>> nameservers allowed in resolv.conf. >>>>> >>>> Actually, my ipa-server-install puts into /etc/resolv.conf its ip >>>> address itself not localhost >>>> >>>> After fresh install: >>>> #cat /etc/resolv.conf >>>> search example.com >>>> nameserver 10.*.*.* >>> >>> IMHO /etc/resolv.conf was overwritten by DHCPd (when IPA installation was >>> finished). >>> >> >> I inspect ipa-server-install source code and installation adds to >> resolv.conf a real server address. >> >> DHCP leave note in resolv.conf when generate it. From mkosek at redhat.com Fri Mar 28 07:42:11 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 28 Mar 2014 08:42:11 +0100 Subject: [Freeipa-devel] [PATCH 0113] ipa-client: Set NIS domain name in the installer In-Reply-To: <53331259.2090508@redhat.com> References: <5243F02D.9020005@redhat.com> <5284B9E2.3000007@redhat.com> <5314D51E.9040402@redhat.com> <53331259.2090508@redhat.com> Message-ID: <533527D3.5040302@redhat.com> On 03/26/2014 06:46 PM, Martin Kosek wrote: > On 03/03/2014 08:16 PM, Tomas Babej wrote: >> The updated patch addresses all the mentioned issues. >> >> Also enables systemd's specific domainname service instead of relying >> ypbind being present on the system. >> >> Please note that nisdomainname is not configured on boot time at the >> moment. The following bug is the cause: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1071951 > > I spoke with initscripts maintainer, applied little pressure and fixed version > is now on its way to updates-testing - initscripts-9.51-2.fc20. > > Martin Tomas, did you test the referred build? If yes, it would be great to give it a karma so that it gets soon to stable update repo: https://admin.fedoraproject.org/updates/FEDORA-2014-4376/initscripts-9.51-2.fc20 Thanks, Martin From mkosek at redhat.com Fri Mar 28 07:55:27 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 28 Mar 2014 08:55:27 +0100 Subject: [Freeipa-devel] [PATCH 0157] ipa-client-install: Configure sudo to use SSSD as data source In-Reply-To: <5314D6F9.6010008@redhat.com> References: <5314D6F9.6010008@redhat.com> Message-ID: <53352AEF.9050901@redhat.com> On 03/03/2014 08:24 PM, Tomas Babej wrote: > Hi, > > Makes ipa-client-install configure SSSD as the data provider > for the sudo service by default. This behaviour can be disabled > by using --no-sudo flag. > > https://fedorahosted.org/freeipa/ticket/3358 By the way when I was discussing this ticket with Jan Pazdziora, he had a good suggestion that it would be nice if we have a test for sudo integration. Given that SUDO management in FreeIPA is pretty widely used and given that this ticket now makes it much more easier to configure and use it, it would be nice to make our best to avoid breaking it upstream. Having an integration test which would add some sudo rules, some targeted directly on the given host entry, some targeted on a hostgroup with that entry and then testing if "sudo -l" gives correct results would be great. If we also test the more complicated SUDO options like -runasuser, -runasgroup with isolated user/group, it would be great. I am not sure if ipatests/test_xmlrpc/test_sudorule_plugin.py should be extended to also do the functional checks or if there should be a separate test, I will leave that up to you and Petr (CCed). Martin From pviktori at redhat.com Fri Mar 28 08:37:14 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 28 Mar 2014 09:37:14 +0100 Subject: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf In-Reply-To: <5334556B.80607@redhat.com> References: <5303801A.40502@redhat.com> <53038511.1050508@redhat.com> <1392741281.12450.18.camel@localhost.localdomain> <5304BB95.1040900@redhat.com> <5304D782.4060704@redhat.com> <1392828905.2352.5.camel@unused-4-145.brq.redhat.com> <530604DC.5090801@redhat.com> <1392908170.2329.4.camel@unused-4-145.brq.redhat.com> <53341648.6070602@redhat.com> <5334556B.80607@redhat.com> Message-ID: <533534BA.1020702@redhat.com> On 03/27/2014 05:44 PM, Petr Spacek wrote: > On 27.3.2014 13:15, Martin Kosek wrote: >> On 02/20/2014 03:56 PM, Martin Basti wrote: >>> On Thu, 2014-02-20 at 14:36 +0100, Petr Spacek wrote: >>>> On 19.2.2014 17:55, Martin Basti wrote: >>>>> On Wed, 2014-02-19 at 17:10 +0100, Petr Spacek wrote: >>>>>> On 19.2.2014 15:11, Petr Spacek wrote: >>>>>>> On 18.2.2014 17:34, Nathaniel McCallum wrote: >>>>>>>> On Tue, 2014-02-18 at 17:06 +0100, Petr Viktorin wrote: >>>>>>>>> On 02/18/2014 04:45 PM, Petr Spacek wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Add wait_for_dns option to default.conf. >>>>>>>>>> >>>>>>>>>> This option makes record changes in DNS tree synchronous. >>>>>>>>>> IPA calls will wait until new data are visible over DNS protocol. >>>>>>>>>> >>>>>>>>>> It is intended only for testing - it should prevent tests from >>>>>>>>>> failing if there is bigger delay between change in LDAP and DNS. >>>>>>>>>> >>>>>>>>>> I would recommend value like 10 seconds. >>>>>>>>> >>>>>>>>> Here are a few Python nitpicks you requested. >>>>>>> >>>>>>> Thank you very much. This new version solves problems you found + >>>>>>> adds proper >>>>>>> handling for real DNS timeouts. >>>>>>> >>>>>>>> It seems to me like a more general TimeoutError would be useful >>>>>>>> in a >>>>>>>> broader context. DNSTimeout seems overly narrow to me, unless I'm >>>>>>>> missing something. >>>>>>> >>>>>>> I would like to keep them separate. DNSTimeout shouldn't be >>>>>>> handled at all >>>>>>> because it means that your DNS server or database is dead or >>>>>>> broken in some >>>>>>> interesting way. >>>>>>> >>>>>>> I assume that generic TimeoutError could be interpreted as 'try it >>>>>>> again'/'failover' or something like that. >>>>>>> >>>>>>> Maybe the DNSTimeout is not the best name, I'm open to suggestions. >>>>>> >>>>>> I have sent the old version with new name, gggrrr. >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>>> Tests failed: >>>>> test_dns[92]: dnsrecord_add: Add A record to u'ns2' in zone >>>>> u'zone3.test' ... ok >>>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>>>> runTest >>>>> self.test(*self.arg) >>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>> 291, in >>>>> >>>>> func = lambda: self.check(nice, **test) >>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>> 309, in >>>>> check >>>>> self.check_output(nice, cmd, args, options, expected, >>>>> extra_check) >>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>> 348, in >>>>> check_output >>>>> got = api.Command[cmd](*args, **options) >>>>> File "/root/freeipa/ipalib/frontend.py", line 436, in __call__ >>>>> ret = self.run(*args, **options) >>>>> File "/root/freeipa/ipalib/frontend.py", line 761, in run >>>>> return self.forward(*args, **options) >>>>> File "/root/freeipa/ipalib/frontend.py", line 782, in forward >>>>> return self.Backend.rpcclient.forward(self.name, *args, **kw) >>>>> File "/root/freeipa/ipalib/rpc.py", line 836, in forward >>>>> return self._call_command(command, params) >>>>> File "/root/freeipa/ipalib/rpc.py", line 813, in _call_command >>>>> return command(*params) >>>>> File "/root/freeipa/ipalib/rpc.py", line 951, in _call >>>>> return self.__request(name, args) >>>>> File "/root/freeipa/ipalib/rpc.py", line 945, in __request >>>>> raise error_class(message=error['message']) >>>>> DNSTimeout: DNS query timeout: Expected {_kerberos.zone2.test. >>>>> 86400 IN >>>>> TXT "IDM.LAB.ENG.BRQ.REDHAT.COM"} got {SERVFAIL} >>>>> >>>>> ====================================================================== >>>>> ERROR: test_dns[51]: dnsrecord_add: Add NS+DNAME record to >>>>> u'zone2.test' >>>>> zone record using dnsrecord_add >>>>> ---------------------------------------------------------------------- >>>>> Traceback (most recent call last): >>>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>>>> runTest >>>>> self.test(*self.arg) >>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>> 291, in >>>>> >>>>> func = lambda: self.check(nice, **test) >>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>> 309, in >>>>> check >>>>> self.check_output(nice, cmd, args, options, expected, >>>>> extra_check) >>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>> 348, in >>>>> check_output >>>>> got = api.Command[cmd](*args, **options) >>>>> File "/root/freeipa/ipalib/frontend.py", line 436, in __call__ >>>>> ret = self.run(*args, **options) >>>>> File "/root/freeipa/ipalib/frontend.py", line 761, in run >>>>> return self.forward(*args, **options) >>>>> File "/root/freeipa/ipalib/frontend.py", line 782, in forward >>>>> return self.Backend.rpcclient.forward(self.name, *args, **kw) >>>>> File "/root/freeipa/ipalib/rpc.py", line 836, in forward >>>>> return self._call_command(command, params) >>>>> File "/root/freeipa/ipalib/rpc.py", line 813, in _call_command >>>>> return command(*params) >>>>> File "/root/freeipa/ipalib/rpc.py", line 951, in _call >>>>> return self.__request(name, args) >>>>> File "/root/freeipa/ipalib/rpc.py", line 945, in __request >>>>> raise error_class(message=error['message']) >>>>> DNSTimeout: DNS query timeout: Expected {zone2.test. 86400 IN NS >>>>> ns1.dnszone.test. >>>>> zone2.test. 86400 IN NS ns1.zone2.test.} got {SERVFAIL} >>>>> >>>>> configuration was: wait_for_dns=10 >>>>> >>>>> All tests passed without wait_for_dns option. >>>>> >>>>> Sometimes at first run, I get only error and testing is interrupted. >>>> >>>> I hope I covered all corner cases in this version. >>>> >>>> I renamed DNSTimeout exception to DNSDataMismatch in hope that it >>>> will be less >>>> confusing. >>>> >>> >>> A change in patch was required to pass doctest. >>> With this change ACK. >>> Updated patch attached. >> >> This patch seems to be in limbo for more than one month now. Do I get >> it right >> that it is now clear to be pushed? >> >> Is wait_for_dns enabled in our DNS test suite so that it is stable? Do >> we want >> it to be enabled? > > Ah, good point. In meantime I have released bind-dyndb-ldap 4.x and > nobody complained Let me do that then! > about race conditions and mysterious errors in test > suite. Sometimes (very rarely) there are some mysterious failures in the DNS tests. They just don't get noticed too much because the ones from automember rebuild are far more frequent. > Apparently, it is faster than I expected :-) > > I will try to finish the patch but I wouldn't enable it if it is not > necessary. -- Petr? From mkosek at redhat.com Fri Mar 28 08:43:46 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 28 Mar 2014 09:43:46 +0100 Subject: [Freeipa-devel] [PATCH 0015] Add wait_for_dns option to default.conf In-Reply-To: <533534BA.1020702@redhat.com> References: <5303801A.40502@redhat.com> <53038511.1050508@redhat.com> <1392741281.12450.18.camel@localhost.localdomain> <5304BB95.1040900@redhat.com> <5304D782.4060704@redhat.com> <1392828905.2352.5.camel@unused-4-145.brq.redhat.com> <530604DC.5090801@redhat.com> <1392908170.2329.4.camel@unused-4-145.brq.redhat.com> <53341648.6070602@redhat.com> <5334556B.80607@redhat.com> <533534BA.1020702@redhat.com> Message-ID: <53353642.4000909@redhat.com> On 03/28/2014 09:37 AM, Petr Viktorin wrote: > On 03/27/2014 05:44 PM, Petr Spacek wrote: >> On 27.3.2014 13:15, Martin Kosek wrote: >>> On 02/20/2014 03:56 PM, Martin Basti wrote: >>>> On Thu, 2014-02-20 at 14:36 +0100, Petr Spacek wrote: >>>>> On 19.2.2014 17:55, Martin Basti wrote: >>>>>> On Wed, 2014-02-19 at 17:10 +0100, Petr Spacek wrote: >>>>>>> On 19.2.2014 15:11, Petr Spacek wrote: >>>>>>>> On 18.2.2014 17:34, Nathaniel McCallum wrote: >>>>>>>>> On Tue, 2014-02-18 at 17:06 +0100, Petr Viktorin wrote: >>>>>>>>>> On 02/18/2014 04:45 PM, Petr Spacek wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Add wait_for_dns option to default.conf. >>>>>>>>>>> >>>>>>>>>>> This option makes record changes in DNS tree synchronous. >>>>>>>>>>> IPA calls will wait until new data are visible over DNS protocol. >>>>>>>>>>> >>>>>>>>>>> It is intended only for testing - it should prevent tests from >>>>>>>>>>> failing if there is bigger delay between change in LDAP and DNS. >>>>>>>>>>> >>>>>>>>>>> I would recommend value like 10 seconds. >>>>>>>>>> >>>>>>>>>> Here are a few Python nitpicks you requested. >>>>>>>> >>>>>>>> Thank you very much. This new version solves problems you found + >>>>>>>> adds proper >>>>>>>> handling for real DNS timeouts. >>>>>>>> >>>>>>>>> It seems to me like a more general TimeoutError would be useful >>>>>>>>> in a >>>>>>>>> broader context. DNSTimeout seems overly narrow to me, unless I'm >>>>>>>>> missing something. >>>>>>>> >>>>>>>> I would like to keep them separate. DNSTimeout shouldn't be >>>>>>>> handled at all >>>>>>>> because it means that your DNS server or database is dead or >>>>>>>> broken in some >>>>>>>> interesting way. >>>>>>>> >>>>>>>> I assume that generic TimeoutError could be interpreted as 'try it >>>>>>>> again'/'failover' or something like that. >>>>>>>> >>>>>>>> Maybe the DNSTimeout is not the best name, I'm open to suggestions. >>>>>>> >>>>>>> I have sent the old version with new name, gggrrr. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Freeipa-devel mailing list >>>>>>> Freeipa-devel at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>>> >>>>>> Tests failed: >>>>>> test_dns[92]: dnsrecord_add: Add A record to u'ns2' in zone >>>>>> u'zone3.test' ... ok >>>>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>>>>> runTest >>>>>> self.test(*self.arg) >>>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>>> 291, in >>>>>> >>>>>> func = lambda: self.check(nice, **test) >>>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>>> 309, in >>>>>> check >>>>>> self.check_output(nice, cmd, args, options, expected, >>>>>> extra_check) >>>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>>> 348, in >>>>>> check_output >>>>>> got = api.Command[cmd](*args, **options) >>>>>> File "/root/freeipa/ipalib/frontend.py", line 436, in __call__ >>>>>> ret = self.run(*args, **options) >>>>>> File "/root/freeipa/ipalib/frontend.py", line 761, in run >>>>>> return self.forward(*args, **options) >>>>>> File "/root/freeipa/ipalib/frontend.py", line 782, in forward >>>>>> return self.Backend.rpcclient.forward(self.name, *args, **kw) >>>>>> File "/root/freeipa/ipalib/rpc.py", line 836, in forward >>>>>> return self._call_command(command, params) >>>>>> File "/root/freeipa/ipalib/rpc.py", line 813, in _call_command >>>>>> return command(*params) >>>>>> File "/root/freeipa/ipalib/rpc.py", line 951, in _call >>>>>> return self.__request(name, args) >>>>>> File "/root/freeipa/ipalib/rpc.py", line 945, in __request >>>>>> raise error_class(message=error['message']) >>>>>> DNSTimeout: DNS query timeout: Expected {_kerberos.zone2.test. >>>>>> 86400 IN >>>>>> TXT "IDM.LAB.ENG.BRQ.REDHAT.COM"} got {SERVFAIL} >>>>>> >>>>>> ====================================================================== >>>>>> ERROR: test_dns[51]: dnsrecord_add: Add NS+DNAME record to >>>>>> u'zone2.test' >>>>>> zone record using dnsrecord_add >>>>>> ---------------------------------------------------------------------- >>>>>> Traceback (most recent call last): >>>>>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>>>>> runTest >>>>>> self.test(*self.arg) >>>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>>> 291, in >>>>>> >>>>>> func = lambda: self.check(nice, **test) >>>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>>> 309, in >>>>>> check >>>>>> self.check_output(nice, cmd, args, options, expected, >>>>>> extra_check) >>>>>> File "/root/freeipa/ipatests/test_xmlrpc/xmlrpc_test.py", line >>>>>> 348, in >>>>>> check_output >>>>>> got = api.Command[cmd](*args, **options) >>>>>> File "/root/freeipa/ipalib/frontend.py", line 436, in __call__ >>>>>> ret = self.run(*args, **options) >>>>>> File "/root/freeipa/ipalib/frontend.py", line 761, in run >>>>>> return self.forward(*args, **options) >>>>>> File "/root/freeipa/ipalib/frontend.py", line 782, in forward >>>>>> return self.Backend.rpcclient.forward(self.name, *args, **kw) >>>>>> File "/root/freeipa/ipalib/rpc.py", line 836, in forward >>>>>> return self._call_command(command, params) >>>>>> File "/root/freeipa/ipalib/rpc.py", line 813, in _call_command >>>>>> return command(*params) >>>>>> File "/root/freeipa/ipalib/rpc.py", line 951, in _call >>>>>> return self.__request(name, args) >>>>>> File "/root/freeipa/ipalib/rpc.py", line 945, in __request >>>>>> raise error_class(message=error['message']) >>>>>> DNSTimeout: DNS query timeout: Expected {zone2.test. 86400 IN NS >>>>>> ns1.dnszone.test. >>>>>> zone2.test. 86400 IN NS ns1.zone2.test.} got {SERVFAIL} >>>>>> >>>>>> configuration was: wait_for_dns=10 >>>>>> >>>>>> All tests passed without wait_for_dns option. >>>>>> >>>>>> Sometimes at first run, I get only error and testing is interrupted. >>>>> >>>>> I hope I covered all corner cases in this version. >>>>> >>>>> I renamed DNSTimeout exception to DNSDataMismatch in hope that it >>>>> will be less >>>>> confusing. >>>>> >>>> >>>> A change in patch was required to pass doctest. >>>> With this change ACK. >>>> Updated patch attached. >>> >>> This patch seems to be in limbo for more than one month now. Do I get >>> it right >>> that it is now clear to be pushed? >>> >>> Is wait_for_dns enabled in our DNS test suite so that it is stable? Do >>> we want >>> it to be enabled? >> >> Ah, good point. In meantime I have released bind-dyndb-ldap 4.x and >> nobody complained > > Let me do that then! > >> about race conditions and mysterious errors in test >> suite. > > Sometimes (very rarely) there are some mysterious failures in the DNS tests. > They just don't get noticed too much because the ones from automember rebuild > are far more frequent. Yes, I suspect they may be caused by the issue you tried to fix. I would really like having our tests stable and not dependent on the right timing. Therefore, if your patch makes that happen and is OK, I would prefer to merge it + enable it for our test suite. Martin From mkosek at redhat.com Fri Mar 28 09:08:53 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 28 Mar 2014 10:08:53 +0100 Subject: [Freeipa-devel] [PATCH] 466-467 Add requires for new pki-core Message-ID: <53353C25.6080203@redhat.com> Fixes PKI installation errors on Fedora 19 and 20, respectively. 466 is for master branch, 467 is for ipa-3-3 branch. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-466-add-requires-for-pki-core-10.1.1-1.fc20.patch Type: text/x-patch Size: 821 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-467-add-requires-for-pki-core-10.0.7-1.fc19.patch Type: text/x-patch Size: 821 bytes Desc: not available URL: From mkosek at redhat.com Fri Mar 28 09:17:19 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 28 Mar 2014 10:17:19 +0100 Subject: [Freeipa-devel] OTP work, what's left? In-Reply-To: <20140323212657.GC3482@redhat.com> References: <20140323212657.GC3482@redhat.com> Message-ID: <53353E1F.2080809@redhat.com> On 03/23/2014 10:26 PM, Alexander Bokovoy wrote: > Hi! > > I've updated my COPR repo with current git master versions of FreeIPA > and SSSD with few added patches on top that close OTP gaps (Nathaniel's > patch 0038 and Jakub Hrozek's patch for password changes). > > With these patches we currently lack following parts of the OTP work: > > - OTP sync client. Still in development, patches and approach need > additional review/discussion on the list > > - Password change in WebUI fails when OTP token exist for the user. More > detailed examination is needed, I'm getting ACIError. > > > http://copr.fedoraproject.org/coprs/abbra/freeipa-otp-unstable/ Alexander or Nathaniel, I see you progressed with the OTP development a lot, good job. Please provide a clean list of patches + information who acked what so that it can be pushed to master. Hint: "OTP Patches" thread is too chaotic for me to follow. Martin From abokovoy at redhat.com Fri Mar 28 09:21:12 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 28 Mar 2014 11:21:12 +0200 Subject: [Freeipa-devel] [PATCH] 466-467 Add requires for new pki-core In-Reply-To: <53353C25.6080203@redhat.com> References: <53353C25.6080203@redhat.com> Message-ID: <20140328092112.GA18946@redhat.com> On Fri, 28 Mar 2014, Martin Kosek wrote: >Fixes PKI installation errors on Fedora 19 and 20, respectively. > >466 is for master branch, 467 is for ipa-3-3 branch. ACK. I assume you'll be using master version for F20. -- / Alexander Bokovoy From mkosek at redhat.com Fri Mar 28 09:22:39 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 28 Mar 2014 10:22:39 +0100 Subject: [Freeipa-devel] [PATCH] 466-467 Add requires for new pki-core In-Reply-To: <20140328092112.GA18946@redhat.com> References: <53353C25.6080203@redhat.com> <20140328092112.GA18946@redhat.com> Message-ID: <53353F5F.9010101@redhat.com> On 03/28/2014 10:21 AM, Alexander Bokovoy wrote: > On Fri, 28 Mar 2014, Martin Kosek wrote: >> Fixes PKI installation errors on Fedora 19 and 20, respectively. >> >> 466 is for master branch, 467 is for ipa-3-3 branch. > ACK. > > I assume you'll be using master version for F20. That would be a wrong assumption - I will release 3.3.5 to F20 as well, FreeIPA 4.0 is planned to be released in Fedora 21. Martin From mkosek at redhat.com Fri Mar 28 09:33:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 28 Mar 2014 10:33:38 +0100 Subject: [Freeipa-devel] [PATCH] 466-467 Add requires for new pki-core In-Reply-To: <20140328092112.GA18946@redhat.com> References: <53353C25.6080203@redhat.com> <20140328092112.GA18946@redhat.com> Message-ID: <533541F2.5020708@redhat.com> On 03/28/2014 10:21 AM, Alexander Bokovoy wrote: > On Fri, 28 Mar 2014, Martin Kosek wrote: >> Fixes PKI installation errors on Fedora 19 and 20, respectively. >> >> 466 is for master branch, 467 is for ipa-3-3 branch. > ACK. Pushed 466 to master, 467 to ipa-3-3. Thanks, Martin From abokovoy at redhat.com Fri Mar 28 09:43:51 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 28 Mar 2014 11:43:51 +0200 Subject: [Freeipa-devel] [PATCH] 466-467 Add requires for new pki-core In-Reply-To: <53353F5F.9010101@redhat.com> References: <53353C25.6080203@redhat.com> <20140328092112.GA18946@redhat.com> <53353F5F.9010101@redhat.com> Message-ID: <20140328094351.GB18946@redhat.com> On Fri, 28 Mar 2014, Martin Kosek wrote: >On 03/28/2014 10:21 AM, Alexander Bokovoy wrote: >> On Fri, 28 Mar 2014, Martin Kosek wrote: >>> Fixes PKI installation errors on Fedora 19 and 20, respectively. >>> >>> 466 is for master branch, 467 is for ipa-3-3 branch. >> ACK. >> >> I assume you'll be using master version for F20. > >That would be a wrong assumption - I will release 3.3.5 to F20 as well, FreeIPA >4.0 is planned to be released in Fedora 21. Since Fedora 20 has 10.1.1, requiring 10.0.7 makes little sense, thus was my question. -- / Alexander Bokovoy From mkosek at redhat.com Fri Mar 28 09:50:42 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 28 Mar 2014 10:50:42 +0100 Subject: [Freeipa-devel] [PATCH] 466-467 Add requires for new pki-core In-Reply-To: <20140328094351.GB18946@redhat.com> References: <53353C25.6080203@redhat.com> <20140328092112.GA18946@redhat.com> <53353F5F.9010101@redhat.com> <20140328094351.GB18946@redhat.com> Message-ID: <533545F2.1030906@redhat.com> On 03/28/2014 10:43 AM, Alexander Bokovoy wrote: > On Fri, 28 Mar 2014, Martin Kosek wrote: >> On 03/28/2014 10:21 AM, Alexander Bokovoy wrote: >>> On Fri, 28 Mar 2014, Martin Kosek wrote: >>>> Fixes PKI installation errors on Fedora 19 and 20, respectively. >>>> >>>> 466 is for master branch, 467 is for ipa-3-3 branch. >>> ACK. >>> >>> I assume you'll be using master version for F20. >> >> That would be a wrong assumption - I will release 3.3.5 to F20 as well, FreeIPA >> 4.0 is planned to be released in Fedora 21. > Since Fedora 20 has 10.1.1, requiring 10.0.7 makes little sense, thus > was my question. > Ah, I get it. I thought you were asking about what git branch I would use for releasing. Yes, you are right, I will use the master version for F20 release. Martin From pvoborni at redhat.com Fri Mar 28 11:39:35 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 28 Mar 2014 12:39:35 +0100 Subject: [Freeipa-devel] [PATCH]Extending user plugin with employeenumber field In-Reply-To: <20140327165603.2e79792a@unused-4-246.brq.redhat.com> References: <1796318445.1683710.1392993953023.JavaMail.zimbra@redhat.com> <53076B73.9020008@redhat.com> <20140321101355.06e5efaa@unused-4-246.brq.redhat.com> <20140321110051.1a50f943@unused-4-246.brq.redhat.com> <53318523.7000601@redhat.com> <20140325182653.551fee3d@unused-4-246.brq.redhat.com> <20140326140750.126d6821@unused-4-246.brq.redhat.com> <20140327165603.2e79792a@unused-4-246.brq.redhat.com> Message-ID: <53355F77.6000803@redhat.com> snip >> >> The preferredLanguage regex pattern and error message has been >> modified to comply with RFC, according to conversation with Petr. >> Thanks >> Adam >> > > The regex pattern corrected, unit tests added for preferredlanguage. > Greets > Adam > ACK Pushed to master: 0f626a9cc870ba0bdcc1322d765687b0e597c26c -- Petr Vobornik From mkosek at redhat.com Fri Mar 28 12:14:31 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 28 Mar 2014 13:14:31 +0100 Subject: [Freeipa-devel] FreeIPA repository and it's committers Message-ID: <533567A7.2060405@redhat.com> This week there was a request to be added to the list of FreeIPA committers, which I denied as the person was not a member of the short list of selected trusted active core upstream developers doing the pushes. When thinking about the request I realized we do not have appropriate information and policy on our wiki, defining our repositories, who can read, who can write and what are the process requirements related to pushing a patch. Well, there it is: http://www.freeipa.org/page/Contribute/Repository I linked it from other Contribution articles. I also did a small pruning of the committers list to keep it consistent with the policy. If there are any objections, or comments for the new wiki page, please tell me. Thanks. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From pvoborni at redhat.com Fri Mar 28 13:04:13 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 28 Mar 2014 14:04:13 +0100 Subject: [Freeipa-devel] [PATCH] 569-583 New Login Screen Message-ID: <5335734D.9030300@redhat.com> Attached patches replace IPA.unauthorized dialog with new Login Screen. To make it happen, a support for standalone facets had to be developed because current framework was limited by facets dependent on entities and a container with menu. This new feature was already used for Load facet which is part of this patchset and also will be a basis for API browser and OTP sync page. Patches should fix these tickets: https://fedorahosted.org/freeipa/ticket/3903 https://fedorahosted.org/freeipa/ticket/4017 Depends on patches #565-#568. [PATCH] webui: facet container ------------------------------ A widget which servers as container for facets. FacetContainer is a base class. App is specialization. Doing this abstraction will allow us to implement various facet containers. [PATCH] webui: FormMixin ------------------------ a mixin used for fields validation. Basically implements a logic which is already in details facet and dialog. Now this logic can be used in any component. The long term goal is to replace the logic in details facet and dialog with this mixin. [PATCH] webui: ContainerMixin ----------------------------- A mixin which implements widget storing logic. Similar logic is already implemented in details facet and dialog. Long term goal is to replace that with this one. Separating the logic into mixin makes it usable in other components. [PATCH] webui: standalone facet ------------------------------- `facet.Facet` is a new base class for facets. It doesn't have any dependencies on entities so it's usable for general purpose facets, e.g., future API browser, load facet or login facet. [PATCH] webui: activity widget ------------------------------ A widget for showing ongoing activity. Displays a text with changing dots. It listens to `network-activity-start` and `network-activity-end` topics. [PATCH] webui: publish network activity topics ---------------------------------------------- Network activity is now published through global topics. It allows other components like activity_widget to listen to them. [PATCH] webui: load page ------------------------ Load page is a simple facet which is displayed up to 'runtime' phase. On application start it tells the user that there is ongoing activity. [PATCH] webui: validation summary widget ---------------------------------------- A widget which aggregates warnings and errors and shows them on one place. [PATCH] webui: login screen widget ---------------------------------- Reimplementation of unauthorized dialog into separate widget. It uses RCUE design. New features compared to unauthorized dialog: - reflects auth methods from `auth` module - validation summary - differentiates Kerberos auth failure with session expiration - Caps Lock warning - form based method doesn't allow password only submission https://fedorahosted.org/freeipa/ticket/4017 https://fedorahosted.org/freeipa/ticket/3903 [PATCH] webui: login page ------------------------- A facet with login sreen widget. [PATCH] webui: authentication module ------------------------------------ General purpose authentication interface and state. See doc of 'freeipa/auth' module. [PATCH] webui: use asynchronous call for authentication Change `IPA.login_password` and `IPA.get_credentials` to use async AJAX and to return promise instead of blocking the code. IPA.get_credentials is still partially blocking because of negotiate process. We can't do anything about that. It allows activity indicators to do their job. [PATCH] webui: fix combobox styles to work with selenium testing [PATCH] webui-ci: adapt to new login screen [PATCH] webui: remove IPA.unauthorized_dialog -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0583-webui-remove-IPA.unauthorized_dialog.patch Type: text/x-patch Size: 15307 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0582-webui-ci-adapt-to-new-login-screen.patch Type: text/x-patch Size: 3787 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0581-webui-fix-combobox-styles-to-work-with-selenium-test.patch Type: text/x-patch Size: 1863 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0580-webui-use-asynchronous-call-for-authentication.patch Type: text/x-patch Size: 8322 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0579-webui-authentication-module.patch Type: text/x-patch Size: 18863 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0578-webui-login-page.patch Type: text/x-patch Size: 5600 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0577-webui-login-screen-widget.patch Type: text/x-patch Size: 128903 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0576-webui-validation-summary-widget.patch Type: text/x-patch Size: 3840 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0575-webui-load-page.patch Type: text/x-patch Size: 7396 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0574-webui-publish-network-activity-topics.patch Type: text/x-patch Size: 1764 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0573-webui-activity-widget.patch Type: text/x-patch Size: 5211 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0572-webui-standalone-facet.patch Type: text/x-patch Size: 14000 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0571-webui-ContainerMixin.patch Type: text/x-patch Size: 5220 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0570-webui-FormMixin.patch Type: text/x-patch Size: 7808 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0569-webui-facet-container.patch Type: text/x-patch Size: 10315 bytes Desc: not available URL: From lslebodn at redhat.com Fri Mar 28 13:46:42 2014 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 28 Mar 2014 14:46:42 +0100 Subject: [Freeipa-devel] FreeIPA repository and it's committers In-Reply-To: <533567A7.2060405@redhat.com> References: <533567A7.2060405@redhat.com> Message-ID: <20140328134641.GB12869@mail.corp.redhat.com> On (28/03/14 13:14), Martin Kosek wrote: >This week there was a request to be added to the list of FreeIPA committers, >which I denied as the person was not a member of the short list of selected >trusted active core upstream developers doing the pushes. > >When thinking about the request I realized we do not have appropriate >information and policy on our wiki, defining our repositories, who can read, >who can write and what are the process requirements related to pushing a patch. > >Well, there it is: >http://www.freeipa.org/page/Contribute/Repository >I linked it from other Contribution articles. > >I also did a small pruning of the committers list to keep it consistent with >the policy. If there are any objections, or comments for the new wiki page, >please tell me. > >Thanks. > To make the committer's life a little be easier, we developed an ipatool to do at least some of the work required, that is to add the Required-by tag and ^^^^^^^^^^^ Required-by or Reviewed-By prepare text snippets for mail, Trac and Bugzilla. LS From mkosek at redhat.com Fri Mar 28 13:56:15 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 28 Mar 2014 14:56:15 +0100 Subject: [Freeipa-devel] FreeIPA repository and it's committers In-Reply-To: <20140328134641.GB12869@mail.corp.redhat.com> References: <533567A7.2060405@redhat.com> <20140328134641.GB12869@mail.corp.redhat.com> Message-ID: <53357F7F.6070301@redhat.com> On 03/28/2014 02:46 PM, Lukas Slebodnik wrote: > On (28/03/14 13:14), Martin Kosek wrote: >> This week there was a request to be added to the list of FreeIPA committers, >> which I denied as the person was not a member of the short list of selected >> trusted active core upstream developers doing the pushes. >> >> When thinking about the request I realized we do not have appropriate >> information and policy on our wiki, defining our repositories, who can read, >> who can write and what are the process requirements related to pushing a patch. >> >> Well, there it is: >> http://www.freeipa.org/page/Contribute/Repository >> I linked it from other Contribution articles. >> >> I also did a small pruning of the committers list to keep it consistent with >> the policy. If there are any objections, or comments for the new wiki page, >> please tell me. >> >> Thanks. >> > To make the committer's life a little be easier, we developed an ipatool to do > at least some of the work required, that is to add the Required-by tag and > ^^^^^^^^^^^ > Required-by or Reviewed-By > prepare text snippets for mail, Trac and Bugzilla. > > LS Thanks! Fixed. Martin From mkosek at redhat.com Fri Mar 28 14:06:45 2014 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 28 Mar 2014 15:06:45 +0100 Subject: [Freeipa-devel] Announcing FreeIPA 3.3.5 Message-ID: <533581F5.104@redhat.com> The FreeIPA team is proud to announce FreeIPA v3.3.5! It can be downloaded from http://www.freeipa.org/page/Downloads. Fedora 19 and Fedora 20 builds are already on their way to updates-testing repo. == Highlights in 3.3.5 == === Enhancements === * DNS classless support for reverse domains === Bug fixes === * Lockout plugin was not applied to users with default password policy * Migration plugin did not add users to default group (ipausers) * AD Trust subdomains were not automatically fetched by trust-add command * When installing Dogtag 10 replica with a CA from a Dogtag 9 based replica, the ipa-replica-conncheck did not check if Dogtag 9 DS port is open * When installing Dogtag 10 replica with a CA from a Dogtag 9 based replica, CA database was not updated resulting in limited functionality of the CA * Trust could not be added with --shared-secret option * Active AD Trust subdomain ID range could be deleted * FreeIPA client returned invalid group membership info when multiple AD Trusts were configured * /ca/ee/ca/profileSubmit proxy URI was added to allow cloning of PKI 10.1.1 and newer * ... and numerous other small fixes === Test improvements === * Many fixes related to Active Directory integration tests == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note that if you are doing the upgrade in special environment (e.g. FedUp) which does not allow running the LDAP server during upgrade process, upgrade scripts need to be run manually after the first boot: # ipa-upgradeconfig # ipa-ldap-updater --upgrade Also note that the performance improvements require an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of users may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks, not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Detailed Changelog since 3.3.4 == === Adam Misnyovszki (1) === * Too big font in input fields === Alexander Bokovoy (10) === * bindinstance: make sure zone manager is initialized in add_master_dns_records * ipa-kdb: in case of delegation use original client's database entry, not the proxy * ipa-kdb: make sure we don't produce MS-PAC in case of authdata flag cleared by admin * trustdomain_find: make sure we skip short entries when --pkey-only is specified * trust: make sure we always discover topology of the forest trust * ipaserver/dcerpc: catch the case of insuffient permissions when establishing trust * fix filtering of subdomain-based trust users * ipa-kdb: do not fetch client principal if it is the same as existing entry * ipaserver/dcerpc: make sure to always return unicode SID of the trust domain * trust: do not fetch subdomains in case shared secret was used to set up the trust === Jan Cholasta (2) === * Include LDFLAGS provided by rpmbuild in global LDFLAGS in the spec file. * Remove sourcehostcategory from the default HBAC rule. === Jason Woods (1) === * ipa-sam: cache gid to sid and uid to sid requests in idmap cache === Martin Basti (3) === * DNS classless support for reverse domains * DNS tests for classless reverse domains * Fix test_host_plugin for DNS Classless Reverse zones === Martin Kosek (10) === * Fallback to global policy in ipa-lockout plugin * ipa-lockout: do not fail when default realm cannot be read * Migration does not add users to default group * Avoid passing non-terminated string to is_master_host * ipa-replica-install never checks for 7389 port * Fix idrange unit test failure * Update Dogtag 9 database during replica installation * Proxy PKI clone /ca/ee/ca/profileSubmit URI * Add requires for pki-core-10.0.7-1.fc19 * Become IPA 3.3.5 === Misnyovszki Adam (1) === * Permission MOD command fix === Petr Viktorin (12) === * integration tests OpenSSHTransport: Expand tilde to home in root_ssh_key_filename * ipa tool: Print the name of the server we are connecting to with -v * test_integration.config: Fix crash in to_env when no replica is defined * test_integration.config: Do not save the input environment * test_integration.config: Use a more declarative approach to test-wide settings * test_integration.config: Do not store the index in Domain and Host objects * test_integration.config: Load/store from/to dicts * test_integration.config: Add environment variables for JSON/YAML * ipa-test-config: Add --json and --yaml output options * test_integration.config: Convert some text values to str * Add tests for integration test configuration * test_integration.tasks: Do not fail cleanup if backup directory does not exist === Sumit Bose (1) === * extdom: do not return results from the wrong domain === Tomas Babej (13) === * ipatests: test_legacy_clients: Change "test group" to "testgroup" * ipatests: Add records for all hosts in master's domain * ipatests: Run restoring backup files and restoring their context in one session * ipatests: legacy_clients: Test legacy clients with non-posix trust * ipatests: Perform a connection test before preparing the client * ipatests: Make sure we re-kinit as admin before adding the disabledipauser * ipatests: Stop sssd service before deleting the cache * ipatests: Add test cases for subdomain users on legacy clients * ipatests: Change expected home directories returned by getent * ipatests: Do not require group name resolution for the non-posix tests * ipatests: Fix incorrect order of operations when restoring backup * Prohibit deletion of active subdomain range * ipatests: test_trust: Change expected home directories for posix users From pviktori at redhat.com Fri Mar 28 15:11:25 2014 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 28 Mar 2014 16:11:25 +0100 Subject: [Freeipa-devel] Read access to container entries Message-ID: <5335911D.9070600@redhat.com> Hello, I'm trying to add ACIs to allow read access to containers, and I need some input. The DS's access control system is not designed to allow access to a single entry but not its descendants. The [ACI documentation] suggests some ways to work around it. This doesn't work that well for read access in IPA: $SUFFIX needs anonymous read access; ipa-client-install looks for "info=IPA V2.0" anonymously. cn=accounts,$SUFFIX needs read access if it or any of its children are to be listed in a GUI cn=users,cn=accounts,$SUFFIX needs read access if it or any users are to be listed in a GUI uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied It's safe to expose IPA's default containers anonymously; all they tell the user is that they're looking an IPA server. The container entries themselves just have cn and an objectClass of cnContainer, so it's impossible to construct a general targetfilter that targets them but not any possible descendants. I see 3 possible solutions: 1) File a DS RFE to implement [targetscope]. With that we could have ACIs that only target a single entry, so admins could manage read access to containers in the usual way (with permissions). 2) Add a (objectClass=nsContainer) filter. The problem here is that if this is on cn=accounts,$S, it would also affect e.g. cn=users,cn=accounts,$S, and other nsContainers under it. For example, cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer. 3) Add a special attribute to mark "public" containers, and add an ACI with a filter on that. Something like objectClass=ipaPublicContainer would do. I'm thinking about 3, but I'd like to ask an LDAP expert for opinions. Note that children can be accessible even if the parent isn't. This whole container business only affects exploring the DIT with a GUI-ish tool. -- Petr? Thanks to Ludwig for input on IRC. [ACI documentation]: https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Defining_Targets-Targeting_a_Single_Directory_Entry [targetscope]: http://docs.oracle.com/cd/E19424-01/820-4809/gdzgi/index.html From redhatrises at gmail.com Fri Mar 28 23:22:28 2014 From: redhatrises at gmail.com (Gabe Alford) Date: Fri, 28 Mar 2014 17:22:28 -0600 Subject: [Freeipa-devel] [PATCH] [DOC] Add note about additional nameservers in resolv.conf In-Reply-To: <533526DC.1080803@redhat.com> References: <1395912216.2269.5.camel@unused-4-145.brq.redhat.com> <5333F056.2030100@redhat.com> <1395915293.2269.7.camel@unused-4-145.brq.redhat.com> <533526DC.1080803@redhat.com> Message-ID: Changed 127.0.0.1 to 192.0.2.1 On Fri, Mar 28, 2014 at 1:38 AM, Petr Spacek wrote: > On 28.3.2014 02:09, Gabe Alford wrote: > >> I believe that Martin is right about the server installer no longer >> putting >> 127.0.0.1 in the resolv.conf. Here is a mod patch to address Martin's >> concern if the note needs to be changed to show a real IP address. >> > > Okay, that is new for me :-) > > Conditional ACK. Please change the IP address before push to something > from: > http://tools.ietf.org/html/rfc5737#section-3 > > 192.0.2.1 sounds like a good candidate. > > Thanks! > > Petr^2 Spacek > > > On Thu, Mar 27, 2014 at 4:14 AM, Martin Basti wrote: >> >> On Thu, 2014-03-27 at 10:33 +0100, Petr Spacek wrote: >>> >>>> On 27.3.2014 10:23, Martin Basti wrote: >>>> >>>>> On Wed, 2014-03-26 at 17:40 -0600, Gabe Alford wrote: >>>>> >>>>>> All, >>>>>> >>>>>> Please review patch for https://fedorahosted.org/freeipa/ticket/3085 >>>>>> >>>>>> Added note that 'nameserver 127.0.0.1' is added to resolv.conf, that >>>>>> it is recommended to add more replicas to resolv.conf, and the max >>>>>> nameservers allowed in resolv.conf. >>>>>> >>>>>> Actually, my ipa-server-install puts into /etc/resolv.conf its ip >>>>> address itself not localhost >>>>> >>>>> After fresh install: >>>>> #cat /etc/resolv.conf >>>>> search example.com >>>>> nameserver 10.*.*.* >>>>> >>>> >>>> IMHO /etc/resolv.conf was overwritten by DHCPd (when IPA installation >>>> was >>>> finished). >>>> >>>> >>> I inspect ipa-server-install source code and installation adds to >>> resolv.conf a real server address. >>> >>> DHCP leave note in resolv.conf when generate it. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rga-0012-2-DOC-Update-resolv.conf-nameserver-note-to-reflect-re.patch Type: text/x-patch Size: 1284 bytes Desc: not available URL: From tbabej at redhat.com Mon Mar 31 04:05:26 2014 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 31 Mar 2014 06:05:26 +0200 Subject: [Freeipa-devel] [PATCH 0113] ipa-client: Set NIS domain name in the installer In-Reply-To: <533527D3.5040302@redhat.com> References: <5243F02D.9020005@redhat.com> <5284B9E2.3000007@redhat.com> <5314D51E.9040402@redhat.com> <53331259.2090508@redhat.com> <533527D3.5040302@redhat.com> Message-ID: <5338E986.2040906@redhat.com> On 03/28/2014 08:42 AM, Martin Kosek wrote: > On 03/26/2014 06:46 PM, Martin Kosek wrote: >> On 03/03/2014 08:16 PM, Tomas Babej wrote: >>> The updated patch addresses all the mentioned issues. >>> >>> Also enables systemd's specific domainname service instead of relying >>> ypbind being present on the system. >>> >>> Please note that nisdomainname is not configured on boot time at the >>> moment. The following bug is the cause: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1071951 >> I spoke with initscripts maintainer, applied little pressure and fixed version >> is now on its way to updates-testing - initscripts-9.51-2.fc20. >> >> Martin > Tomas, did you test the referred build? If yes, it would be great to give it a > karma so that it gets soon to stable update repo: > > https://admin.fedoraproject.org/updates/FEDORA-2014-4376/initscripts-9.51-2.fc20 > > Thanks, > Martin Yes. I gave the karma, now it should be on its way to stable update repository. > -- Tomas Babej Associate Software Engineer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pspacek at redhat.com Mon Mar 31 06:50:00 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 31 Mar 2014 08:50:00 +0200 Subject: [Freeipa-devel] PKI expert needed: [dane] "DANE-TA(2) ? Full(0)" certificate chain matching? In-Reply-To: <20140326222511.GE13649@mournblade.imrryr.org> References: <20140326222511.GE13649@mournblade.imrryr.org> Message-ID: <53391018.2050302@redhat.com> Hello list, FYI dane at ietf.org list hosts a discussion about PKI certificate handling in DNSSEC world. PKIX experts are needed here, please comment (not only) on following draft. Glossary for the alphabet soup below: http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-04 http://tools.ietf.org/html/rfc6698 Mailing list: https://www.ietf.org/mailman/listinfo/dane Have a nice day! Petr^2 Spacek -------- Original Message -------- Subject: [dane] Repost: "DANE-TA(2) ? Full(0)" certificate chain matching? Date: Wed, 26 Mar 2014 22:25:11 +0000 From: Viktor Dukhovni Reply-To: dane at ietf.org To: dane at ietf.org [ Repost, no feedback received. Question summary: * Are clients supposed to check "signed-by" via bare TA keys (2 1 0) that have no matching certificate in the server's chain (say root TA left out of chain per normal PKIX practice)? * Are clients supposed to be able to augment the server chain with any (2 0 0) DANE-TA certificate obtained from DNS, if that certificate is missing from the server's chain? ] I believe we have reached consensus on DANE-EE(3) end-entity X.509 cert verification: - No name checks based on certificate content (TLSA base domain sufficient) - No expiration checks based on certificate content (DNSSEC sufficient) It is time to consider the issues for DANE-TA(2). The first issue is: With records of the form: _25.mx.example.com. TLSA DANE-TA(2) {blob} where the matching type is really a digest, not Full(0), we've observed that the server operator had better include the matching certificate in his TLS handshake certificate (chain) message, because the verifying client can't match a digest against a certificate it does not have. What do we want to say about: _25.mx.example.com. TLSA DANE-TA(2) SPKI(1) Full(0) {DER-encoded key} In this case the client still typically has no corresponding certificate in hand, and so, if the server does not provide a matching certificate in the TLS handshake, the client cannot "compare" the TLSA record with the server's chain. However, if the server's chain starts with a certificate signed with the trust anchor key in question (obtained from the TLSA record), the client can in principle verify the chain. The Postfix SMTP client in fact does exactly this, uses any "IN TLSA 2 1 0" trust anchor keys to verify "signed-by" even when the server does not present a corresponding TA issuing certificate in his chain. So the question is: - Are clients expected to do this? In other words can servers expect to be able to elide TA certs from their chains when the TA key is in a "2 1 0" TLSA record? - If clients are not expected to do this, there is little point in "IN TLSA 2 1 0", with the key also inside a certificate in the server's chain, it makes a lot more sense to publish "IN TLSA 2 1 X" for some suitable set of digests X. A related question is whether with "DANE-TA(2) Cert(0) Full(0)", there is again a practical need to duplicate the certificate in the server's chain "for matching", or whether this time the server really can avoid duplication, because the client has the cert in hand. Note: The OPS draft discourages "Full(0)" due to potential issues with DNS payload bloat, but these are nevertheless valid, and it would be good to settle on the semantics. -- Viktor. _______________________________________________ dane mailing list dane at ietf.org https://www.ietf.org/mailman/listinfo/dane From lkrispen at redhat.com Mon Mar 31 08:41:12 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 31 Mar 2014 10:41:12 +0200 Subject: [Freeipa-devel] Read access to container entries In-Reply-To: <5335911D.9070600@redhat.com> References: <5335911D.9070600@redhat.com> Message-ID: <53392A28.1090307@redhat.com> Hi Petr, we already discussed on IRC, but see some comments below On 03/28/2014 04:11 PM, Petr Viktorin wrote: > Hello, > I'm trying to add ACIs to allow read access to containers, and I need > some input. > > The DS's access control system is not designed to allow access to a > single entry but not its descendants. The [ACI documentation] suggests > some ways to work around it. > > This doesn't work that well for read access in IPA: > > $SUFFIX needs anonymous read access; ipa-client-install looks for > "info=IPA V2.0" anonymously. > cn=accounts,$SUFFIX needs read access if it or any of its children are > to be listed in a GUI > cn=users,cn=accounts,$SUFFIX needs read access if it or any users are > to be listed in a GUI > uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied > > It's safe to expose IPA's default containers anonymously; all they > tell the user is that they're looking an IPA server. > > The container entries themselves just have cn and an objectClass of > cnContainer, so it's impossible to construct a general targetfilter > that targets them but not any possible descendants. > > I see 3 possible solutions: > 1) File a DS RFE to implement [targetscope]. With that we could have > ACIs that only target a single entry, so admins could manage read > access to containers in the usual way (with permissions). > 2) Add a (objectClass=nsContainer) filter. The problem here is that if > this is on cn=accounts,$S, it would also affect e.g. > cn=users,cn=accounts,$S, and other nsContainers under it. For example, > cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer. > 3) Add a special attribute to mark "public" containers, and add an ACI > with a filter on that. Something like objectClass=ipaPublicContainer > would do. there is one more option 4) add an allow aci for cn=accounts,$S and a deny aci for cn=*,cn=accounts,$S or uid=*,cn=accounts,$S In general I think we should implement 1), there will be other scenarios where it could be useful. If something is needed imemdiately I would also prefer 3) > > > I'm thinking about 3, but I'd like to ask an LDAP expert for opinions. > > > Note that children can be accessible even if the parent isn't. This > whole container business only affects exploring the DIT with a GUI-ish > tool. > From mkosek at redhat.com Mon Mar 31 10:32:16 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 31 Mar 2014 12:32:16 +0200 Subject: [Freeipa-devel] Read access to container entries In-Reply-To: <53392A28.1090307@redhat.com> References: <5335911D.9070600@redhat.com> <53392A28.1090307@redhat.com> Message-ID: <53394430.50509@redhat.com> On 03/31/2014 10:41 AM, Ludwig Krispenz wrote: > Hi Petr, > > we already discussed on IRC, but see some comments below > On 03/28/2014 04:11 PM, Petr Viktorin wrote: >> Hello, >> I'm trying to add ACIs to allow read access to containers, and I need some >> input. >> >> The DS's access control system is not designed to allow access to a single >> entry but not its descendants. The [ACI documentation] suggests some ways to >> work around it. >> >> This doesn't work that well for read access in IPA: >> >> $SUFFIX needs anonymous read access; ipa-client-install looks for "info=IPA >> V2.0" anonymously. >> cn=accounts,$SUFFIX needs read access if it or any of its children are to be >> listed in a GUI >> cn=users,cn=accounts,$SUFFIX needs read access if it or any users are to be >> listed in a GUI >> uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied >> >> It's safe to expose IPA's default containers anonymously; all they tell the >> user is that they're looking an IPA server. >> >> The container entries themselves just have cn and an objectClass of >> cnContainer, so it's impossible to construct a general targetfilter that >> targets them but not any possible descendants. >> >> I see 3 possible solutions: >> 1) File a DS RFE to implement [targetscope]. With that we could have ACIs >> that only target a single entry, so admins could manage read access to >> containers in the usual way (with permissions). >> 2) Add a (objectClass=nsContainer) filter. The problem here is that if this >> is on cn=accounts,$S, it would also affect e.g. cn=users,cn=accounts,$S, and >> other nsContainers under it. For example, >> cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer. >> 3) Add a special attribute to mark "public" containers, and add an ACI with a >> filter on that. Something like objectClass=ipaPublicContainer would do. > there is one more option > 4) add an allow aci for cn=accounts,$S and a deny aci for cn=*,cn=accounts,$S > or uid=*,cn=accounts,$S In the past, we tried hard to avoid deny acis and I think we should keep it this way. deny ACI is just a hard stop that cannot be overriden by any other ACI. If possible, I would prefer to only add allow ACIs. > In general I think we should implement 1), there will be other scenarios where > it could be useful. If something is needed imemdiately I would also prefer 3) We need this feature for FreeIPA 4.0, so I am thinking waiting for 389 feature is not an option unless it'd be done really fast. Given Petr's findings, I am thinking that solution based on 3) seems like way to go. We would of course only allow objectclass + cn attributes. I am not convinced that objectclass like ipaPublicContainer is the right way to go, does not sound to me as a standard solution and not something that people would assume they need to do when they are adding a custom container. When I installed a fresh FreeIPA, I did a (cn=nsContainer) search (results attached) and there were 61 results. Do we really want to update 61 LDAP entries and add a custom ipaPublicContainer objectclass to all? Sounds a little bit hackish to me. Would adding following ACIs work? dn: SUFFIX aci: allow anonymous read for "(objectclass=nsContainer)" for cn, objectclass; except cn=etc,SUFFIX dn: cn=etc,SUFFIX aci: allow authenticated read for "(objectclass=nsContainer)" for cn, objectclass As I just checked, allowing whole cn=etc,SUFFIX for authenticated only is something we agreed on during DevConf. With this approach, the only question is what should we do with nsContainer based LDAP entries that contains sensitive information. I wonder - is this a real situation? Are there many nsContainer LDAP entries with sensitive information? Shouldn't we have a rule instead that would recommend using custom (not nsContainer) objectclasses to store sensitive information based on cn? Otherwise it seems to me a an abuse of nsContainer purpose. Martin -------------- next part -------------- dn: cn=accounts,dc=mkosek-fedora20,dc=test dn: cn=users,cn=accounts,dc=mkosek-fedora20,dc=test dn: cn=groups,cn=accounts,dc=mkosek-fedora20,dc=test dn: cn=services,cn=accounts,dc=mkosek-fedora20,dc=test dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test dn: cn=hostgroups,cn=accounts,dc=mkosek-fedora20,dc=test dn: cn=alt,dc=mkosek-fedora20,dc=test dn: cn=ng,cn=alt,dc=mkosek-fedora20,dc=test dn: cn=automount,dc=mkosek-fedora20,dc=test dn: cn=default,cn=automount,dc=mkosek-fedora20,dc=test dn: cn=hbac,dc=mkosek-fedora20,dc=test dn: cn=hbacservices,cn=hbac,dc=mkosek-fedora20,dc=test dn: cn=hbacservicegroups,cn=hbac,dc=mkosek-fedora20,dc=test dn: cn=sudo,dc=mkosek-fedora20,dc=test dn: cn=sudocmds,cn=sudo,dc=mkosek-fedora20,dc=test dn: cn=sudocmdgroups,cn=sudo,dc=mkosek-fedora20,dc=test dn: cn=sudorules,cn=sudo,dc=mkosek-fedora20,dc=test dn: cn=etc,dc=mkosek-fedora20,dc=test dn: cn=sysaccounts,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=replicas,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=dna,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=ca_renewal,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=s4u2proxy,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=ipaConfig,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=cosTemplates,cn=accounts,dc=mkosek-fedora20,dc=test dn: cn=selinux,dc=mkosek-fedora20,dc=test dn: cn=usermap,cn=selinux,dc=mkosek-fedora20,dc=test dn: cn=ranges,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=roles,cn=accounts,dc=mkosek-fedora20,dc=test dn: cn=pbac,dc=mkosek-fedora20,dc=test dn: cn=privileges,cn=pbac,dc=mkosek-fedora20,dc=test dn: cn=permissions,cn=pbac,dc=mkosek-fedora20,dc=test dn: cn=virtual operations,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=retrieve certificate,cn=virtual operations,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=request certificate,cn=virtual operations,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=request certificate different host,cn=virtual operations,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=certificate status,cn=virtual operations,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=revoke certificate,cn=virtual operations,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=certificate remove hold,cn=virtual operations,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=Managed Entries,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=Templates,cn=Managed Entries,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=Definitions,cn=Managed Entries,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=automember,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=ipa.mkosek-fedora20.test,cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=CA,cn=ipa.mkosek-fedora20.test,cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=CAcert,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=global_policy,cn=MKOSEK-FEDORA20.TEST,cn=kerberos,dc=mkosek-fedora20,dc=test dn: cn=KDC,cn=ipa.mkosek-fedora20.test,cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=KPASSWD,cn=ipa.mkosek-fedora20.test,cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=MEMCACHE,cn=ipa.mkosek-fedora20.test,cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=OTPD,cn=ipa.mkosek-fedora20.test,cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=HTTP,cn=ipa.mkosek-fedora20.test,cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=anonymous-limits,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=otp,dc=mkosek-fedora20,dc=test dn: cn=Realm Domains,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test dn: cn=trusts,dc=mkosek-fedora20,dc=test dn: cn=dns,dc=mkosek-fedora20,dc=test dn: cn=DNS,cn=ipa.mkosek-fedora20.test,cn=masters,cn=ipa,cn=etc,dc=mkosek-fedora20,dc=test From abokovoy at redhat.com Mon Mar 31 10:52:40 2014 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 31 Mar 2014 13:52:40 +0300 Subject: [Freeipa-devel] Read access to container entries In-Reply-To: <53394430.50509@redhat.com> References: <5335911D.9070600@redhat.com> <53392A28.1090307@redhat.com> <53394430.50509@redhat.com> Message-ID: <20140331105240.GN21211@redhat.com> On Mon, 31 Mar 2014, Martin Kosek wrote: >On 03/31/2014 10:41 AM, Ludwig Krispenz wrote: >> Hi Petr, >> >> we already discussed on IRC, but see some comments below >> On 03/28/2014 04:11 PM, Petr Viktorin wrote: >>> Hello, >>> I'm trying to add ACIs to allow read access to containers, and I need some >>> input. >>> >>> The DS's access control system is not designed to allow access to a single >>> entry but not its descendants. The [ACI documentation] suggests some ways to >>> work around it. >>> >>> This doesn't work that well for read access in IPA: >>> >>> $SUFFIX needs anonymous read access; ipa-client-install looks for "info=IPA >>> V2.0" anonymously. >>> cn=accounts,$SUFFIX needs read access if it or any of its children are to be >>> listed in a GUI >>> cn=users,cn=accounts,$SUFFIX needs read access if it or any users are to be >>> listed in a GUI >>> uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied >>> >>> It's safe to expose IPA's default containers anonymously; all they tell the >>> user is that they're looking an IPA server. >>> >>> The container entries themselves just have cn and an objectClass of >>> cnContainer, so it's impossible to construct a general targetfilter that >>> targets them but not any possible descendants. >>> >>> I see 3 possible solutions: >>> 1) File a DS RFE to implement [targetscope]. With that we could have ACIs >>> that only target a single entry, so admins could manage read access to >>> containers in the usual way (with permissions). >>> 2) Add a (objectClass=nsContainer) filter. The problem here is that if this >>> is on cn=accounts,$S, it would also affect e.g. cn=users,cn=accounts,$S, and >>> other nsContainers under it. For example, >>> cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer. >>> 3) Add a special attribute to mark "public" containers, and add an ACI with a >>> filter on that. Something like objectClass=ipaPublicContainer would do. >> there is one more option >> 4) add an allow aci for cn=accounts,$S and a deny aci for cn=*,cn=accounts,$S >> or uid=*,cn=accounts,$S > >In the past, we tried hard to avoid deny acis and I think we should keep it >this way. deny ACI is just a hard stop that cannot be overriden by any other >ACI. If possible, I would prefer to only add allow ACIs. > >> In general I think we should implement 1), there will be other scenarios where >> it could be useful. If something is needed imemdiately I would also prefer 3) > >We need this feature for FreeIPA 4.0, so I am thinking waiting for 389 feature >is not an option unless it'd be done really fast. > >Given Petr's findings, I am thinking that solution based on 3) seems like way >to go. We would of course only allow objectclass + cn attributes. I am not >convinced that objectclass like ipaPublicContainer is the right way to go, does >not sound to me as a standard solution and not something that people would >assume they need to do when they are adding a custom container. > >When I installed a fresh FreeIPA, I did a (cn=nsContainer) search (results >attached) and there were 61 results. Do we really want to update 61 LDAP >entries and add a custom ipaPublicContainer objectclass to all? Sounds a little >bit hackish to me. > >Would adding following ACIs work? > >dn: SUFFIX >aci: allow anonymous read for "(objectclass=nsContainer)" for cn, objectclass; >except cn=etc,SUFFIX > >dn: cn=etc,SUFFIX >aci: allow authenticated read for "(objectclass=nsContainer)" for cn, objectclass > >As I just checked, allowing whole cn=etc,SUFFIX for authenticated only is >something we agreed on during DevConf. > >With this approach, the only question is what should we do with nsContainer >based LDAP entries that contains sensitive information. I wonder - is this a >real situation? Are there many nsContainer LDAP entries with sensitive >information? Shouldn't we have a rule instead that would recommend using custom >(not nsContainer) objectclasses to store sensitive information based on cn? >Otherwise it seems to me a an abuse of nsContainer purpose. We have trust entries that need absolute protection for any authenticated read other than from 'trust agents' and 'trust admins' groups. There are also Kerberos entries that should not be accessible (master keys, etc). OTP tokens should only be visible to the user itself and admins. I'm sure there are others too. -- / Alexander Bokovoy From mkosek at redhat.com Mon Mar 31 11:18:18 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 31 Mar 2014 13:18:18 +0200 Subject: [Freeipa-devel] Read access to container entries In-Reply-To: <20140331105240.GN21211@redhat.com> References: <5335911D.9070600@redhat.com> <53392A28.1090307@redhat.com> <53394430.50509@redhat.com> <20140331105240.GN21211@redhat.com> Message-ID: <53394EFA.4020906@redhat.com> On 03/31/2014 12:52 PM, Alexander Bokovoy wrote: > On Mon, 31 Mar 2014, Martin Kosek wrote: >> On 03/31/2014 10:41 AM, Ludwig Krispenz wrote: >>> Hi Petr, >>> >>> we already discussed on IRC, but see some comments below >>> On 03/28/2014 04:11 PM, Petr Viktorin wrote: >>>> Hello, >>>> I'm trying to add ACIs to allow read access to containers, and I need some >>>> input. >>>> >>>> The DS's access control system is not designed to allow access to a single >>>> entry but not its descendants. The [ACI documentation] suggests some ways to >>>> work around it. >>>> >>>> This doesn't work that well for read access in IPA: >>>> >>>> $SUFFIX needs anonymous read access; ipa-client-install looks for "info=IPA >>>> V2.0" anonymously. >>>> cn=accounts,$SUFFIX needs read access if it or any of its children are to be >>>> listed in a GUI >>>> cn=users,cn=accounts,$SUFFIX needs read access if it or any users are to be >>>> listed in a GUI >>>> uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied >>>> >>>> It's safe to expose IPA's default containers anonymously; all they tell the >>>> user is that they're looking an IPA server. >>>> >>>> The container entries themselves just have cn and an objectClass of >>>> cnContainer, so it's impossible to construct a general targetfilter that >>>> targets them but not any possible descendants. >>>> >>>> I see 3 possible solutions: >>>> 1) File a DS RFE to implement [targetscope]. With that we could have ACIs >>>> that only target a single entry, so admins could manage read access to >>>> containers in the usual way (with permissions). >>>> 2) Add a (objectClass=nsContainer) filter. The problem here is that if this >>>> is on cn=accounts,$S, it would also affect e.g. cn=users,cn=accounts,$S, and >>>> other nsContainers under it. For example, >>>> cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer. >>>> 3) Add a special attribute to mark "public" containers, and add an ACI with a >>>> filter on that. Something like objectClass=ipaPublicContainer would do. >>> there is one more option >>> 4) add an allow aci for cn=accounts,$S and a deny aci for cn=*,cn=accounts,$S >>> or uid=*,cn=accounts,$S >> >> In the past, we tried hard to avoid deny acis and I think we should keep it >> this way. deny ACI is just a hard stop that cannot be overriden by any other >> ACI. If possible, I would prefer to only add allow ACIs. >> >>> In general I think we should implement 1), there will be other scenarios where >>> it could be useful. If something is needed imemdiately I would also prefer 3) >> >> We need this feature for FreeIPA 4.0, so I am thinking waiting for 389 feature >> is not an option unless it'd be done really fast. >> >> Given Petr's findings, I am thinking that solution based on 3) seems like way >> to go. We would of course only allow objectclass + cn attributes. I am not >> convinced that objectclass like ipaPublicContainer is the right way to go, does >> not sound to me as a standard solution and not something that people would >> assume they need to do when they are adding a custom container. >> >> When I installed a fresh FreeIPA, I did a (cn=nsContainer) search (results >> attached) and there were 61 results. Do we really want to update 61 LDAP >> entries and add a custom ipaPublicContainer objectclass to all? Sounds a little >> bit hackish to me. >> >> Would adding following ACIs work? >> >> dn: SUFFIX >> aci: allow anonymous read for "(objectclass=nsContainer)" for cn, objectclass; >> except cn=etc,SUFFIX >> >> dn: cn=etc,SUFFIX >> aci: allow authenticated read for "(objectclass=nsContainer)" for cn, >> objectclass >> >> As I just checked, allowing whole cn=etc,SUFFIX for authenticated only is >> something we agreed on during DevConf. >> >> With this approach, the only question is what should we do with nsContainer >> based LDAP entries that contains sensitive information. I wonder - is this a >> real situation? Are there many nsContainer LDAP entries with sensitive >> information? Shouldn't we have a rule instead that would recommend using custom >> (not nsContainer) objectclasses to store sensitive information based on cn? >> Otherwise it seems to me a an abuse of nsContainer purpose. > We have trust entries that need absolute protection for any > authenticated read other than from 'trust agents' and 'trust admins' groups. Note that this ACI would only allow access to nsContainer based entries + only to CN + ObjectClass attributes, i.e. not to any keys present in such entry for example. Speaking of Trusts, trust data are in cn=,cn=ad,cn=trusts,SUFFIX and none of the subentries has nsContainer object class. Authenticated user would only see that there is cn=ad,cn=trusts,SUFFIX container but nothing else (he does see that already). > There are also Kerberos entries that should not be accessible (master > keys, etc). Not nsContainer objetclass, not even a cn attribute - we are safe there. OTP tokens should only be visible to the user itself and > admins. I'm sure there are others too. OTP data are in cn=otp,SUFFIX. Only cn=otp is a nsContainer entry so anonymous users would only see that this container exists. Real token data are in ipatokenuniqueid=,cn=otp,SUFFIX which uses ipaToken* objectclasses, not nsContainer. Martin From lkrispen at redhat.com Mon Mar 31 11:52:27 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 31 Mar 2014 13:52:27 +0200 Subject: [Freeipa-devel] Read access to container entries In-Reply-To: <53394430.50509@redhat.com> References: <5335911D.9070600@redhat.com> <53392A28.1090307@redhat.com> <53394430.50509@redhat.com> Message-ID: <533956FB.2060104@redhat.com> On 03/31/2014 12:32 PM, Martin Kosek wrote: > On 03/31/2014 10:41 AM, Ludwig Krispenz wrote: >> Hi Petr, >> >> we already discussed on IRC, but see some comments below >> On 03/28/2014 04:11 PM, Petr Viktorin wrote: >>> Hello, >>> I'm trying to add ACIs to allow read access to containers, and I need some >>> input. >>> >>> The DS's access control system is not designed to allow access to a single >>> entry but not its descendants. The [ACI documentation] suggests some ways to >>> work around it. >>> >>> This doesn't work that well for read access in IPA: >>> >>> $SUFFIX needs anonymous read access; ipa-client-install looks for "info=IPA >>> V2.0" anonymously. >>> cn=accounts,$SUFFIX needs read access if it or any of its children are to be >>> listed in a GUI >>> cn=users,cn=accounts,$SUFFIX needs read access if it or any users are to be >>> listed in a GUI >>> uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied >>> >>> It's safe to expose IPA's default containers anonymously; all they tell the >>> user is that they're looking an IPA server. >>> >>> The container entries themselves just have cn and an objectClass of >>> cnContainer, so it's impossible to construct a general targetfilter that >>> targets them but not any possible descendants. >>> >>> I see 3 possible solutions: >>> 1) File a DS RFE to implement [targetscope]. With that we could have ACIs >>> that only target a single entry, so admins could manage read access to >>> containers in the usual way (with permissions). >>> 2) Add a (objectClass=nsContainer) filter. The problem here is that if this >>> is on cn=accounts,$S, it would also affect e.g. cn=users,cn=accounts,$S, and >>> other nsContainers under it. For example, >>> cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer. >>> 3) Add a special attribute to mark "public" containers, and add an ACI with a >>> filter on that. Something like objectClass=ipaPublicContainer would do. >> there is one more option >> 4) add an allow aci for cn=accounts,$S and a deny aci for cn=*,cn=accounts,$S >> or uid=*,cn=accounts,$S > In the past, we tried hard to avoid deny acis and I think we should keep it > this way. deny ACI is just a hard stop that cannot be overriden by any other > ACI. If possible, I would prefer to only add allow ACIs. I agree, in my opinion the access restriction is much clearer if only allow is used > >> In general I think we should implement 1), there will be other scenarios where >> it could be useful. If something is needed imemdiately I would also prefer 3) > We need this feature for FreeIPA 4.0, so I am thinking waiting for 389 feature > is not an option unless it'd be done really fast. how fast does it have to be ? If we just can use the same concept with targetscope=[base,one,sub] implementation should not take too much time, about a week or so, but we need to get it accepted by DS core. > > Given Petr's findings, I am thinking that solution based on 3) seems like way > to go. We would of course only allow objectclass + cn attributes. I am not > convinced that objectclass like ipaPublicContainer is the right way to go, does > not sound to me as a standard solution and not something that people would > assume they need to do when they are adding a custom container. > > When I installed a fresh FreeIPA, I did a (cn=nsContainer) search (results > attached) and there were 61 results. Do we really want to update 61 LDAP > entries and add a custom ipaPublicContainer objectclass to all? Sounds a little > bit hackish to me. > > Would adding following ACIs work? > > dn: SUFFIX > aci: allow anonymous read for "(objectclass=nsContainer)" for cn, objectclass; > except cn=etc,SUFFIX how do you want to specify the "except" ? > > dn: cn=etc,SUFFIX > aci: allow authenticated read for "(objectclass=nsContainer)" for cn, objectclass > > As I just checked, allowing whole cn=etc,SUFFIX for authenticated only is > something we agreed on during DevConf. > > With this approach, the only question is what should we do with nsContainer > based LDAP entries that contains sensitive information. I wonder - is this a > real situation? Are there many nsContainer LDAP entries with sensitive > information? Shouldn't we have a rule instead that would recommend using custom > (not nsContainer) objectclasses to store sensitive information based on cn? > Otherwise it seems to me a an abuse of nsContainer purpose. > > Martin From simo at redhat.com Mon Mar 31 12:53:55 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2014 08:53:55 -0400 Subject: [Freeipa-devel] Read access to container entries In-Reply-To: <53392A28.1090307@redhat.com> References: <5335911D.9070600@redhat.com> <53392A28.1090307@redhat.com> Message-ID: <1396270435.1844.98.camel@willson.li.ssimo.org> On Mon, 2014-03-31 at 10:41 +0200, Ludwig Krispenz wrote: > Hi Petr, > > we already discussed on IRC, but see some comments below > On 03/28/2014 04:11 PM, Petr Viktorin wrote: > > Hello, > > I'm trying to add ACIs to allow read access to containers, and I need > > some input. > > > > The DS's access control system is not designed to allow access to a > > single entry but not its descendants. The [ACI documentation] suggests > > some ways to work around it. > > > > This doesn't work that well for read access in IPA: > > > > $SUFFIX needs anonymous read access; ipa-client-install looks for > > "info=IPA V2.0" anonymously. > > cn=accounts,$SUFFIX needs read access if it or any of its children are > > to be listed in a GUI > > cn=users,cn=accounts,$SUFFIX needs read access if it or any users are > > to be listed in a GUI > > uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied > > > > It's safe to expose IPA's default containers anonymously; all they > > tell the user is that they're looking an IPA server. > > > > The container entries themselves just have cn and an objectClass of > > cnContainer, so it's impossible to construct a general targetfilter > > that targets them but not any possible descendants. > > > > I see 3 possible solutions: > > 1) File a DS RFE to implement [targetscope]. With that we could have > > ACIs that only target a single entry, so admins could manage read > > access to containers in the usual way (with permissions). > > 2) Add a (objectClass=nsContainer) filter. The problem here is that if > > this is on cn=accounts,$S, it would also affect e.g. > > cn=users,cn=accounts,$S, and other nsContainers under it. For example, > > cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer. Re-reading this I am not sure I understand the example, the filter wouldn't apply to masters as they are under cn=etc not cn=accounts I guess you meant that if we set the permission on the root in order to see accounts that we also show masters and other parts of the tree? (like hbac and sudo .. > > 3) Add a special attribute to mark "public" containers, and add an ACI > > with a filter on that. Something like objectClass=ipaPublicContainer > > would do. > there is one more option > 4) add an allow aci for cn=accounts,$S and a deny aci for > cn=*,cn=accounts,$S or uid=*,cn=accounts,$S We want to get rid of deny ACIs if at all possible. > In general I think we should implement 1), there will be other scenarios > where it could be useful. If something is needed imemdiately I would > also prefer 3) I wonder, can we have an objectclass that defines no attributes ? Or do we always need to have a MAY at least ? Anyway I agree that the simplest solution would be to have an objectclass to filter on. But I see 2 options. 1. objectClass=ipaPublicContainer 2. objectClass=ipaPrivateContainer The problem with the second is adding a (!(objectclass=ipaPrivateContainer)) everywhere ... > > > > > > I'm thinking about 3, but I'd like to ask an LDAP expert for opinions. > > > > > > Note that children can be accessible even if the parent isn't. This > > whole container business only affects exploring the DIT with a GUI-ish > > tool. > > > -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Mon Mar 31 12:59:34 2014 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 31 Mar 2014 14:59:34 +0200 Subject: [Freeipa-devel] LDAP ACI testing Message-ID: <533966B6.4020208@redhat.com> Hello list, thread "[Freeipa-devel] Read access to container entries" reminds me an idea I have in mind for a while: We could check effective ACIs [1] for interesting objects (Kerberos master key, trust objects etc.) and make sure that there is nothing like 'read by anonymous' etc. Method [1] has one important limitation: It checks ACI in given sub-tree against one specified DN. Realization of my idea would be better with a "reverse" approach: Specify DN of a single object as "target" and get list of all users with non-null access rights for the object in question. (This could be refined with filter for specific rights so we can get "list of DNs allowed to write to this object" etc.) Does it make sense? [1] https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html -- Petr^2 Spacek From lkrispen at redhat.com Mon Mar 31 13:18:47 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 31 Mar 2014 15:18:47 +0200 Subject: [Freeipa-devel] LDAP ACI testing In-Reply-To: <533966B6.4020208@redhat.com> References: <533966B6.4020208@redhat.com> Message-ID: <53396B37.10206@redhat.com> On 03/31/2014 02:59 PM, Petr Spacek wrote: > Hello list, > > thread "[Freeipa-devel] Read access to container entries" reminds me > an idea I have in mind for a while: > > We could check effective ACIs [1] for interesting objects (Kerberos > master key, trust objects etc.) and make sure that there is nothing > like 'read by anonymous' etc. > > Method [1] has one important limitation: It checks ACI in given > sub-tree against one specified DN. > > Realization of my idea would be better with a "reverse" approach: > Specify DN of a single object as "target" and get list of all users > with non-null access rights for the object in question. (This could be > refined with filter for specific rights so we can get "list of DNs > allowed to write to this object" etc.) > > > Does it make sense? yes, I think it would be a "nice to have" feature, but ... I think it will be quit ecomplex to implement and you could get very large result sets, eg all users. In geteffectiverigths you more or less do the normal aci evaluation for a given bind dn, but in your request you ask for all dns which could match teh bind rules and this could be complicated in case of bind rules depneding on attributes of the entry and the bind rule eg in a userattr rule, so you would have to look at every entyr and check if the userattr matches. In rules with groupdns we need to find all direct or indirect group members and for macro acis the expansion to all dns matchng the macro could also get complicated > > > > [1] > https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html > From mkosek at redhat.com Mon Mar 31 13:23:10 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 31 Mar 2014 15:23:10 +0200 Subject: [Freeipa-devel] Read access to container entries In-Reply-To: <533956FB.2060104@redhat.com> References: <5335911D.9070600@redhat.com> <53392A28.1090307@redhat.com> <53394430.50509@redhat.com> <533956FB.2060104@redhat.com> Message-ID: <53396C3E.6050509@redhat.com> On 03/31/2014 01:52 PM, Ludwig Krispenz wrote: > > On 03/31/2014 12:32 PM, Martin Kosek wrote: >> On 03/31/2014 10:41 AM, Ludwig Krispenz wrote: ... >>> In general I think we should implement 1), there will be other scenarios where >>> it could be useful. If something is needed imemdiately I would also prefer 3) >> We need this feature for FreeIPA 4.0, so I am thinking waiting for 389 feature >> is not an option unless it'd be done really fast. > how fast does it have to be ? If we just can use the same concept with > targetscope=[base,one,sub] > implementation should not take too much time, about a week or so, but we need > to get it accepted by > DS core. As fast as a light :-) A week should be sufficient, though I am not convinced that we are able to release that fast or that rushing ACI related implementation is a good thing to do. Question is if we want to go this way (adding ACI for all containers) or the second way having ACI(s) for all containers in the tree described below. > >> >> Given Petr's findings, I am thinking that solution based on 3) seems like way >> to go. We would of course only allow objectclass + cn attributes. I am not >> convinced that objectclass like ipaPublicContainer is the right way to go, does >> not sound to me as a standard solution and not something that people would >> assume they need to do when they are adding a custom container. >> >> When I installed a fresh FreeIPA, I did a (cn=nsContainer) search (results >> attached) and there were 61 results. Do we really want to update 61 LDAP >> entries and add a custom ipaPublicContainer objectclass to all? Sounds a little >> bit hackish to me. >> >> Would adding following ACIs work? >> >> dn: SUFFIX >> aci: allow anonymous read for "(objectclass=nsContainer)" for cn, objectclass; >> except cn=etc,SUFFIX > how do you want to specify the "except" ? (target != "ldap:///cn=etc,SUFFIX") >> dn: cn=etc,SUFFIX >> aci: allow authenticated read for "(objectclass=nsContainer)" for cn, >> objectclass >> >> As I just checked, allowing whole cn=etc,SUFFIX for authenticated only is >> something we agreed on during DevConf. >> >> With this approach, the only question is what should we do with nsContainer >> based LDAP entries that contains sensitive information. I wonder - is this a >> real situation? Are there many nsContainer LDAP entries with sensitive >> information? Shouldn't we have a rule instead that would recommend using custom >> (not nsContainer) objectclasses to store sensitive information based on cn? >> Otherwise it seems to me a an abuse of nsContainer purpose. >> >> Martin > From rcritten at redhat.com Mon Mar 31 13:23:20 2014 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 31 Mar 2014 09:23:20 -0400 Subject: [Freeipa-devel] LDAP ACI testing In-Reply-To: <533966B6.4020208@redhat.com> References: <533966B6.4020208@redhat.com> Message-ID: <53396C48.5080806@redhat.com> Petr Spacek wrote: > Hello list, > > thread "[Freeipa-devel] Read access to container entries" reminds me an > idea I have in mind for a while: > > We could check effective ACIs [1] for interesting objects (Kerberos > master key, trust objects etc.) and make sure that there is nothing like > 'read by anonymous' etc. > > Method [1] has one important limitation: It checks ACI in given sub-tree > against one specified DN. > > Realization of my idea would be better with a "reverse" approach: > Specify DN of a single object as "target" and get list of all users with > non-null access rights for the object in question. (This could be > refined with filter for specific rights so we can get "list of DNs > allowed to write to this object" etc.) > > > Does it make sense? > > > > [1] > https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html Maybe. We've had a long-term need to run the unit tests as various other users to avoid delegation regressions. We really should have some subset of tests to do positive and negative testing of each role. We'd probably want to do these tests directly with the framework. Ideally this could be extended to disabling anonymous access, setting minimum SSF, etc. This could probably be mostly done using GER. rob From lkrispen at redhat.com Mon Mar 31 13:33:03 2014 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Mon, 31 Mar 2014 15:33:03 +0200 Subject: [Freeipa-devel] Read access to container entries In-Reply-To: <53396C3E.6050509@redhat.com> References: <5335911D.9070600@redhat.com> <53392A28.1090307@redhat.com> <53394430.50509@redhat.com> <533956FB.2060104@redhat.com> <53396C3E.6050509@redhat.com> Message-ID: <53396E8F.2090202@redhat.com> On 03/31/2014 03:23 PM, Martin Kosek wrote: > On 03/31/2014 01:52 PM, Ludwig Krispenz wrote: >> On 03/31/2014 12:32 PM, Martin Kosek wrote: >>> On 03/31/2014 10:41 AM, Ludwig Krispenz wrote: > ... >>>> In general I think we should implement 1), there will be other scenarios where >>>> it could be useful. If something is needed imemdiately I would also prefer 3) >>> We need this feature for FreeIPA 4.0, so I am thinking waiting for 389 feature >>> is not an option unless it'd be done really fast. >> how fast does it have to be ? If we just can use the same concept with >> targetscope=[base,one,sub] >> implementation should not take too much time, about a week or so, but we need >> to get it accepted by >> DS core. > As fast as a light :-) A week should be sufficient, though I am not convinced > that we are able to release that fast or that rushing ACI related > implementation is a good thing to do. :-) and I am no longer sure if it would be the best way to go since there seem to be may containers you want to apply this and with targetscope=base you would hav eto add the aci to any container you want to control > > Question is if we want to go this way (adding ACI for all containers) or the > second way having ACI(s) for all containers in the tree described below. if you don't see any problems giving access to too many containers I think the combination of your suggestion (target != "ldap:///cn=etc,SUFFIX")(targetfilter= ...) is the best. The question is, do you want to use an existing attribute,value pair for the filter or add something unique to the entries you target. In that case you would have to edit the entries and the filter would be enough > >>> Given Petr's findings, I am thinking that solution based on 3) seems like way >>> to go. We would of course only allow objectclass + cn attributes. I am not >>> convinced that objectclass like ipaPublicContainer is the right way to go, does >>> not sound to me as a standard solution and not something that people would >>> assume they need to do when they are adding a custom container. >>> >>> When I installed a fresh FreeIPA, I did a (cn=nsContainer) search (results >>> attached) and there were 61 results. Do we really want to update 61 LDAP >>> entries and add a custom ipaPublicContainer objectclass to all? Sounds a little >>> bit hackish to me. >>> >>> Would adding following ACIs work? >>> >>> dn: SUFFIX >>> aci: allow anonymous read for "(objectclass=nsContainer)" for cn, objectclass; >>> except cn=etc,SUFFIX >> how do you want to specify the "except" ? > (target != "ldap:///cn=etc,SUFFIX") > >>> dn: cn=etc,SUFFIX >>> aci: allow authenticated read for "(objectclass=nsContainer)" for cn, >>> objectclass >>> >>> As I just checked, allowing whole cn=etc,SUFFIX for authenticated only is >>> something we agreed on during DevConf. >>> >>> With this approach, the only question is what should we do with nsContainer >>> based LDAP entries that contains sensitive information. I wonder - is this a >>> real situation? Are there many nsContainer LDAP entries with sensitive >>> information? Shouldn't we have a rule instead that would recommend using custom >>> (not nsContainer) objectclasses to store sensitive information based on cn? >>> Otherwise it seems to me a an abuse of nsContainer purpose. >>> >>> Martin From mkosek at redhat.com Mon Mar 31 13:32:28 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 31 Mar 2014 15:32:28 +0200 Subject: [Freeipa-devel] LDAP ACI testing In-Reply-To: <53396C48.5080806@redhat.com> References: <533966B6.4020208@redhat.com> <53396C48.5080806@redhat.com> Message-ID: <53396E6C.20903@redhat.com> On 03/31/2014 03:23 PM, Rob Crittenden wrote: > Petr Spacek wrote: >> Hello list, >> >> thread "[Freeipa-devel] Read access to container entries" reminds me an >> idea I have in mind for a while: >> >> We could check effective ACIs [1] for interesting objects (Kerberos >> master key, trust objects etc.) and make sure that there is nothing like >> 'read by anonymous' etc. >> >> Method [1] has one important limitation: It checks ACI in given sub-tree >> against one specified DN. >> >> Realization of my idea would be better with a "reverse" approach: >> Specify DN of a single object as "target" and get list of all users with >> non-null access rights for the object in question. (This could be >> refined with filter for specific rights so we can get "list of DNs >> allowed to write to this object" etc.) >> >> >> Does it make sense? >> >> >> >> [1] >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html >> > > Maybe. We've had a long-term need to run the unit tests as various other users > to avoid delegation regressions. We really should have some subset of tests to > do positive and negative testing of each role. We'd probably want to do these > tests directly with the framework. > > Ideally this could be extended to disabling anonymous access, setting minimum > SSF, etc. This could probably be mostly done using GER. > > rob FYI - we have a ticket already open to do something like what Petr says: https://fedorahosted.org/freeipa/ticket/4035 IMO it is a good thing to do. Martin From mkosek at redhat.com Mon Mar 31 13:39:39 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 31 Mar 2014 15:39:39 +0200 Subject: [Freeipa-devel] Read access to container entries In-Reply-To: <1396270435.1844.98.camel@willson.li.ssimo.org> References: <5335911D.9070600@redhat.com> <53392A28.1090307@redhat.com> <1396270435.1844.98.camel@willson.li.ssimo.org> Message-ID: <5339701B.9070901@redhat.com> On 03/31/2014 02:53 PM, Simo Sorce wrote: > On Mon, 2014-03-31 at 10:41 +0200, Ludwig Krispenz wrote: ... >>> 3) Add a special attribute to mark "public" containers, and add an ACI >>> with a filter on that. Something like objectClass=ipaPublicContainer >>> would do. >> there is one more option >> 4) add an allow aci for cn=accounts,$S and a deny aci for >> cn=*,cn=accounts,$S or uid=*,cn=accounts,$S > > We want to get rid of deny ACIs if at all possible. > >> In general I think we should implement 1), there will be other scenarios >> where it could be useful. If something is needed imemdiately I would >> also prefer 3) > > I wonder, can we have an objectclass that defines no attributes ? > Or do we always need to have a MAY at least ? This particular objectclass could have just one MUST attribute - cn. Similarly to what nsContainer has. > Anyway I agree that the simplest solution would be to have an > objectclass to filter on. > > But I see 2 options. > 1. objectClass=ipaPublicContainer > 2. objectClass=ipaPrivateContainer > > The problem with the second is adding a > (!(objectclass=ipaPrivateContainer)) everywhere ... > I already elaborated on that topic later in this thread, please check it. It also includes an attached list of container we already have. IMO most of containers we have will be public, rather than private as LDAP nsContainer's cn attribute is semantically not meant to contain secrets we want to hide. So instead of adding 61 ipaPublicContainer everywhere I would just allow reading nsContainers (cn+objectclass) anonymously + have ipaPrivateContainer available in case we need it (I am not aware of any such case though). Martin From mkosek at redhat.com Mon Mar 31 15:09:38 2014 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 31 Mar 2014 17:09:38 +0200 Subject: [Freeipa-devel] [PATCH] [DOC] Review section on NetworkManager In-Reply-To: <20140327102713.GG3872@redhat.com> References: <20140327102713.GG3872@redhat.com> Message-ID: <53398532.6080807@redhat.com> On 03/27/2014 11:27 AM, Jan Pazdziora wrote: > On Wed, Mar 26, 2014 at 05:30:13PM -0600, Gabe Alford wrote: >> All, >> >> Please review this patch for https://fedorahosted.org/freeipa/ticket/4156 >> Added links to documentation on configuring NetworkManager. > > Thank you for the patch. > > ACK. > Thanks to both! Pushed to master. Martin From simo at redhat.com Mon Mar 31 16:01:00 2014 From: simo at redhat.com (Simo Sorce) Date: Mon, 31 Mar 2014 12:01:00 -0400 Subject: [Freeipa-devel] Read access to container entries In-Reply-To: <5339701B.9070901@redhat.com> References: <5335911D.9070600@redhat.com> <53392A28.1090307@redhat.com> <1396270435.1844.98.camel@willson.li.ssimo.org> <5339701B.9070901@redhat.com> Message-ID: <1396281660.1844.100.camel@willson.li.ssimo.org> On Mon, 2014-03-31 at 15:39 +0200, Martin Kosek wrote: > On 03/31/2014 02:53 PM, Simo Sorce wrote: > > On Mon, 2014-03-31 at 10:41 +0200, Ludwig Krispenz wrote: > ... > >>> 3) Add a special attribute to mark "public" containers, and add an ACI > >>> with a filter on that. Something like objectClass=ipaPublicContainer > >>> would do. > >> there is one more option > >> 4) add an allow aci for cn=accounts,$S and a deny aci for > >> cn=*,cn=accounts,$S or uid=*,cn=accounts,$S > > > > We want to get rid of deny ACIs if at all possible. > > > >> In general I think we should implement 1), there will be other scenarios > >> where it could be useful. If something is needed imemdiately I would > >> also prefer 3) > > > > I wonder, can we have an objectclass that defines no attributes ? > > Or do we always need to have a MAY at least ? > > This particular objectclass could have just one MUST attribute - cn. Similarly > to what nsContainer has. > > > Anyway I agree that the simplest solution would be to have an > > objectclass to filter on. > > > > But I see 2 options. > > 1. objectClass=ipaPublicContainer > > 2. objectClass=ipaPrivateContainer > > > > The problem with the second is adding a > > (!(objectclass=ipaPrivateContainer)) everywhere ... > > > > I already elaborated on that topic later in this thread, please check it. It > also includes an attached list of container we already have. IMO most of > containers we have will be public, rather than private as LDAP nsContainer's cn > attribute is semantically not meant to contain secrets we want to hide. > > So instead of adding 61 ipaPublicContainer everywhere I would just allow > reading nsContainers (cn+objectclass) anonymously + have ipaPrivateContainer > available in case we need it (I am not aware of any such case though). Yeah sorry, I replied in order. I agree with your proposal of allowing (objectclass=nsContainer) and a targetfilter that simply excludes the cn=etc subtree. Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Mon Mar 31 16:20:09 2014 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 31 Mar 2014 18:20:09 +0200 Subject: [Freeipa-devel] [PATCH] 569-583 New Login Screen In-Reply-To: <5335734D.9030300@redhat.com> References: <5335734D.9030300@redhat.com> Message-ID: <533995B9.5040609@redhat.com> I forgot to add new images to makefile, attaching new version of patch #577. On 28.3.2014 14:04, Petr Vobornik wrote: > Attached patches replace IPA.unauthorized dialog with new Login Screen. > > To make it happen, a support for standalone facets had to be developed > because current framework was limited by facets dependent on entities > and a container with menu. This new feature was already used for Load > facet which is part of this patchset and also will be a basis for API > browser and OTP sync page. > > Patches should fix these tickets: > https://fedorahosted.org/freeipa/ticket/3903 > https://fedorahosted.org/freeipa/ticket/4017 > > Depends on patches #565-#568. > > > [PATCH] webui: facet container > ------------------------------ > A widget which servers as container for facets. FacetContainer is a base > class. App is specialization. > > Doing this abstraction will allow us to implement various facet containers. > > [PATCH] webui: FormMixin > ------------------------ > a mixin used for fields validation. Basically implements a logic which > is already in details facet and dialog. > > Now this logic can be used in any component. > > The long term goal is to replace the logic in details facet and dialog > with this mixin. > > [PATCH] webui: ContainerMixin > ----------------------------- > A mixin which implements widget storing logic. Similar logic is already > implemented > in details facet and dialog. > > Long term goal is to replace that with this one. > > Separating the logic into mixin makes it usable in other components. > > [PATCH] webui: standalone facet > ------------------------------- > `facet.Facet` is a new base class for facets. It doesn't have any > dependencies > on entities so it's usable for general purpose facets, e.g., future API > browser, > load facet or login facet. > > [PATCH] webui: activity widget > ------------------------------ > A widget for showing ongoing activity. > > Displays a text with changing dots. > > It listens to `network-activity-start` and `network-activity-end` topics. > > [PATCH] webui: publish network activity topics > ---------------------------------------------- > Network activity is now published through global topics. It allows other > components like activity_widget to listen to them. > > [PATCH] webui: load page > ------------------------ > Load page is a simple facet which is displayed up to 'runtime' phase. > > On application start it tells the user that there is ongoing activity. > > [PATCH] webui: validation summary widget > ---------------------------------------- > A widget which aggregates warnings and errors and shows them on one place. > > [PATCH] webui: login screen widget > ---------------------------------- > Reimplementation of unauthorized dialog into separate widget. It uses RCUE > design. > > New features compared to unauthorized dialog: > > - reflects auth methods from `auth` module > - validation summary > - differentiates Kerberos auth failure with session expiration > - Caps Lock warning > - form based method doesn't allow password only submission > > https://fedorahosted.org/freeipa/ticket/4017 > https://fedorahosted.org/freeipa/ticket/3903 > > > [PATCH] webui: login page > ------------------------- > A facet with login sreen widget. > > [PATCH] webui: authentication module > ------------------------------------ > General purpose authentication interface and state. See doc of > 'freeipa/auth' module. > > [PATCH] webui: use asynchronous call for authentication > > Change `IPA.login_password` and `IPA.get_credentials` to use async AJAX > and to return promise instead of blocking the code. > > IPA.get_credentials is still partially blocking because of negotiate > process. > We can't do anything about that. > > It allows activity indicators to do their job. > > [PATCH] webui: fix combobox styles to work with selenium testing > [PATCH] webui-ci: adapt to new login screen > [PATCH] webui: remove IPA.unauthorized_dialog > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0577-1-webui-login-screen-widget.patch Type: text/x-patch Size: 130136 bytes Desc: not available URL: