From gim.spb at gmail.com Tue Oct 1 08:38:36 2013 From: gim.spb at gmail.com (Gorbachev Ivan) Date: Tue, 1 Oct 2013 12:38:36 +0400 Subject: [Freeipa-devel] PostgreSQL + freeipa In-Reply-To: <20130930155852.GL4216@redhat.com> References: <20130930155852.GL4216@redhat.com> Message-ID: Thank you! And one more question, what does error mean - "GSSAPI continuation error: No credentials found with supported encryption types". This error appears when I try to log in from another computer within the domain IPA. On Mon, Sep 30, 2013 at 7:58 PM, Alexander Bokovoy wrote: > On Mon, 30 Sep 2013, Gorbachev Ivan wrote: > >> I should add the role every time then add ipa users ? For example, i have >> one role for PostgreSQL, and after add a new IPA user, i should add >> mapping >> for this new user ? Or it would be made automaticaly ? >> > This is PostgreSQL-specific question, nothing specific to IPA at all. > Answer to it depends on your model of a database access since PostgreSQL > users are not the same as system users -- you need to map the to each > other. By default mapping is 1:1, i.e. for each system user there should > exist the same user entry in PostgreSQL. > > In general, if you have a single database user (or role) and want to > allow multiple system level users to access it, you need to supply user > maps: http://www.postgresql.org/**docs/9.2/static/auth-username-** > maps.html > > In Adam's case I guess puppet's recipe automatically sets up PostgreSQL > user named 'keystone' and therefore connection to PostgreSQL with > principal 'keystone' matches it automatically. > > >> On Mon, Sep 30, 2013 at 7:03 PM, Alexander Bokovoy > >wrote: >> >> On Mon, 30 Sep 2013, Gorbachev Ivan wrote: >>> >>> Hi! >>>> >>>> Sorry for my English. Can you help me. I try to add PostgreSQL >>>> authentication to IPA. >>>> >>>> Server of IPA host name - server.my.domain.local >>>> database PostgreSQL host name - database.my.domain.local >>>> >>>> 1. pg_hba.conf ? add record >>>> >>>> host all all 192.168.0.0/24 gss >>>> >>>> 2. postgresql.conf add records: >>>> # Kerberos and GSSAPI >>>> krb_server_keyfile = '/var/lib/pgsql/9.2/data/pg.****keytab' >>>> >>>> krb_srvname = 'postgres' # (Kerberos only) >>>> >>>> 3. Add PostgreSQL service: >>>> ipa service-add postgres/server.my.domain.****local >>>> >>>> >>>> 4. Create keytab: >>>> ipa-getkeytab -s server.my.domain.local -p >>>> postgres/database.my.domain.****local at MY.DOMAIN.LOCAL -k >>>> /var/lib/pgsql/data/9.2/pg.****keytab >>>> >>>> 5. Change owner: >>>> chown postgres:postgres /var/lib/pgsql/9.2/data/pg.****keytab >>>> >>>> >>>> 6. restart PostgreSQL service >>>> >>>> 7. Try to connect from database host: >>>> psql -h database.my.domain.local >>>> >>>> If I try ? ?psql -h database.my.domain.local? command, I have an error ? >>>> ?psql: FATAL: role "rembo" does not exist? >>>> >>>> So authentication passes in this case but you don't have proper role >>> defined. Define a role called 'rembo'. >>> >>> See http://www.postgresql.org/****docs/9.2/static/database-**** >>> roles.html >>> >>> > >>> >>> >>> >>> >>> If I try ?? psql -h database.my.domain.local -U rembo at MY.DOMAIN.LOCAL? >>>> command, I have an error ?psql: FATAL: GSSAPI authentication failed >>>> for >>>> user rembo at MY.DOMAIN.LOCAL" >>>> >>>> database.my.domain.local host?s authentication method ? IPA. >>>> >>>> This is PostgreSQL log: >>>> DEBUG: InitPostgres >>>> DEBUG: my backend ID is 1 >>>> DEBUG: StartTransaction >>>> DEBUG: checkpointer updated shared memory configuration values >>>> DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, >>>> xid/subid/cid: 0/1/0, nestlvl: 1, children: >>>> DEBUG: CommitTransaction >>>> DEBUG: name: unnamed; blockState: STARTED; state: INPROGR, >>>> xid/subid/cid: 0/1/0, nestlvl: 1, children: >>>> DEBUG: forked new backend, pid=17203 socket=11 >>>> DEBUG: postmaster child[17203]: starting with ( >>>> DEBUG: postgres >>>> DEBUG: rembo at MY.DOMAIN.LOCAL >>>> DEBUG: ) >>>> DEBUG: InitPostgres >>>> DEBUG: my backend ID is 2 >>>> DEBUG: StartTransaction >>>> DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, >>>> xid/subid/cid: 0/1/0, nestlvl: 1, children: >>>> DEBUG: Processing received GSS token of length 654 >>>> DEBUG: gss_accept_sec_context major: 0, minor: 0, outlen: 156, >>>> outflags: >>>> 1b2 >>>> DEBUG: sending GSS response token of length 156 >>>> DEBUG: sending GSS token of length 156 >>>> LOG: provided user name (rembo at MY.DOMAIN.LOCAL) and authenticated user >>>> name (rembo) do not match >>>> >>>> You have this issue because your username and mapped name do not match. >>> >>> >>> -- >>> / Alexander Bokovoy >>> >>> >> >> >> -- >> With Best Regards >> Gorbachev Ivan >> > > > > -- > / Alexander Bokovoy > -- With Best Regards Gorbachev Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Tue Oct 1 08:56:57 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 01 Oct 2013 10:56:57 +0200 Subject: [Freeipa-devel] [PATCHES] 0289-0302 Managed Read permissions Message-ID: <524A8E59.8010605@redhat.com> Hello, These patches implement the framework for https://fedorahosted.org/freeipa/ticket/3566 Design is at http://www.freeipa.org/page/V3/Managed_Read_permissions. As you can see from the TODOs it's not yet complete; I'll need a few more discussions about some details and future work. The patches only add read permissions for User objects, and the global anonymous read ACI is not removed. I'll add the other objects after the overall structure is ACKed. To test, remove the ACI (cheatsheet: http://fpaste.org/43296/13806142/) and verify that anonymous read is disabled and normal users can't read anything but user info. These depend on some of my earlier patches: - 0258-0265, 0275 - LDIF-based schema updater - 0276-0277 - Split large doc strings for translation - 0288 - user template in tests I needed to test both server and client plugins. Since we only have one API object (#3090) and can't unload plugins, I needed to fix some issues when they are loaded at the same time. Terminology note: currently IPA calls the "read"/"search"/"write"/"delete" part of an ACI a "permission", which is confusing since our ACI wrapper objects are also "permissions". Wherever I can, I use the term "rights" for these. "Rights" is also used in ACI docs: https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#id3349243 /Enter patches. Act I. 0289: Might as well update to new API since I'll be making extensive changes here 0290: My linting tools were complaining heavily about the tabs, so I fixed the indentation here. 0291: Fix a crash when ldap2 and a client RPC backend are connected at the same time. (This happens in tests that I'll add later) Act II. 0292: See the "Permission flags" section of the design. 0293: Add schema. (The OIDs aren't registered yet.) 0294: This makes the test in the next patch possible. 0295: See the "MANAGED Permissions" section of the design. 0296: See the "Read rights" section of the design. Act III. 0297: See "Marking Attributes in Plugins" and "Adding permissions for default read permissions" in the design. 0298: Make the help plugin not fail when server plugins are loaded. This will happen in later tests. 0299: Tests for 0297 0300! Fix a TODO from 0295 0301: See "Adding privileges and role for default read permissions" in the design 0302: Tests for 0301 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0289-Update-Permission-plugin-to-decorator-registration-A.patch Type: text/x-patch Size: 3533 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0290-Fix-indentation-in-permission-plugin-tests.patch Type: text/x-patch Size: 8525 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0291-Fix-invalid-assumption-NSS-initialization-check-in-S.patch Type: text/x-patch Size: 1240 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0292-Treat-permissions-with-unknown-flags-as-immutable.patch Type: text/x-patch Size: 9601 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0293-Add-schema-for-managed-permissions.patch Type: text/x-patch Size: 3377 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0294-Make-it-possible-to-call-custom-functions-in-Declara.patch Type: text/x-patch Size: 1798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0295-Add-support-for-managed-permissions.patch Type: text/x-patch Size: 27821 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0296-Add-read-search-and-compare-to-the-list-of-permissio.patch Type: text/x-patch Size: 5182 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0297-Add-Object-metadata-and-update-plugin-for-managed-pe.patch Type: text/x-patch Size: 7504 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0298-Help-plugin-don-t-fail-if-a-topic-s-module-is-not-fo.patch Type: text/x-patch Size: 1651 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0299-Add-tests-for-managed-permission-updater.patch Type: text/x-patch Size: 8096 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0300-Make-managed-permission-tests-use-the-server-update-.patch Type: text/x-patch Size: 5638 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0301-Add-Reader-role-and-user-read-privilege.patch Type: text/x-patch Size: 2008 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0302-Add-tests-for-the-new-Reader-role.patch Type: text/x-patch Size: 7682 bytes Desc: not available URL: From pviktori at redhat.com Tue Oct 1 09:00:15 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 01 Oct 2013 11:00:15 +0200 Subject: [Freeipa-devel] [PATCHES] 0289-0302 Managed Read permissions In-Reply-To: <524A8E59.8010605@redhat.com> References: <524A8E59.8010605@redhat.com> Message-ID: <524A8F1F.1020407@redhat.com> On 10/01/2013 10:56 AM, Petr Viktorin wrote: > Hello, > > These patches implement the framework for > https://fedorahosted.org/freeipa/ticket/3566 > > Design is at http://www.freeipa.org/page/V3/Managed_Read_permissions. > As you can see from the TODOs it's not yet complete; I'll need a few > more discussions about some details and future work. Simo, I believe you're in charge of OIDs? Can you register the schema? attributeTypes: 2.16.840.1.113730.3.8.11.42 ipaPermissionDefaultAttribute 2.16.840.1.113730.3.8.11.43 ipaPermissionAllowedAttribute 2.16.840.1.113730.3.8.11.44 ipaPermissionExcludedAttribute objectClasses: 2.16.840.1.113730.3.8.12.20 ipaManagedPermission The schema is added in patch 0293. -- Petr? From jcholast at redhat.com Tue Oct 1 10:32:00 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 01 Oct 2013 12:32:00 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <5232D563.3050500@redhat.com> References: <52161568.7060702@redhat.com> <52245136.1090804@redhat.com> <52260B6B.7050906@redhat.com> <522840B4.30709@redhat.com> <5232D20C.9050204@redhat.com> <5232D290.40504@redhat.com> <5232D563.3050500@redhat.com> Message-ID: <524AA4A0.6040801@redhat.com> On 13.9.2013 11:05, Jan Cholasta wrote: > On 13.9.2013 10:53, Martin Kosek wrote: >> On 09/13/2013 10:51 AM, Jan Cholasta wrote: >>> On 5.9.2013 10:28, Jan Cholasta wrote: >>>> On 3.9.2013 18:16, Dmitri Pal wrote: >>>>> On 09/02/2013 04:49 AM, Petr Spacek wrote: >>>>>> It reminds me problems with key-rotation for DNSSEC. >>>>>> >>>>>> Could we find common problems and use the same/similar solution for >>>>>> both problems? >>>>>> >>>>>> An extension for certmonger? Oddjob? Or a completely new daemon? >>>>>> >>>>> Certmonger already has a way to: >>>>> 1) Check things periodically >>>>> 2) Hand certs in different places >>>>> 3) Run post op scripts >>>>> >>>>> IMO it is a good candidate but I would leave it to Nalin to chime in. >>>>> >>>> >>>> I would expect more things that require periodic checking on clients >>>> beyond certificates to come in the future, so I'm not sure if doing >>>> this >>>> in certmonger is the right thing to do. Also, SSSD already does a >>>> similar thing for realm domains, right? >> >> Are you suggesting extending SSSD to handle that? > > Yes. > >> >>>> >>>> Honza >>>> >>> >>> So, does anyone have any strong opinions on this? >> >> Not at this point. BTW, is there any reason why we cannot go the >> simple way and >> just utilize cron and a script? Previously we just dropped conf to >> /etc/cron.d >> for ipa-compliance script and it worked quite well. > > Hmm, that's so simple it might just work. At least until there is a > better way. I have been thinking about this for some time now and came up with this solution: Write a library implementing the PKCS#11 API (Cryptoki), which would provide the shared CA certificates and associated information (nicknames, trust flags). The library would get the certificates from SSSD, which in turn would get them from IPA (and do the usual stuff like caching). This library could then be used by IPA NSS databases as a source of trust information for IPA services (see modutil). It could also be used by p11-glue to provide the trust information to the rest of the system. Pros: * Automatic support for getting trust information stored in IPA in all the applications that understand PKCS#11. * Certificates are fetched from IPA on-demand, not periodically like in the previous solutions. Cons: * Complexity of implementation? (I don't know about this one, I briefly looked at the source code of the p11-kit PKCS#11 module and it looked manageable to me.) Does this sound reasonable? Honza -- Jan Cholasta From swalter at redhat.com Tue Oct 1 10:48:01 2013 From: swalter at redhat.com (Stef Walter) Date: Tue, 01 Oct 2013 12:48:01 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <524AA4A0.6040801@redhat.com> References: <52161568.7060702@redhat.com> <52245136.1090804@redhat.com> <52260B6B.7050906@redhat.com> <522840B4.30709@redhat.com> <5232D20C.9050204@redhat.com> <5232D290.40504@redhat.com> <5232D563.3050500@redhat.com> <524AA4A0.6040801@redhat.com> Message-ID: <524AA861.7060201@redhat.com> On 01.10.2013 12:32, Jan Cholasta wrote: > On 13.9.2013 11:05, Jan Cholasta wrote: >> On 13.9.2013 10:53, Martin Kosek wrote: >>> On 09/13/2013 10:51 AM, Jan Cholasta wrote: >>>> On 5.9.2013 10:28, Jan Cholasta wrote: >>>>> On 3.9.2013 18:16, Dmitri Pal wrote: >>>>>> On 09/02/2013 04:49 AM, Petr Spacek wrote: >>>>>>> It reminds me problems with key-rotation for DNSSEC. >>>>>>> >>>>>>> Could we find common problems and use the same/similar solution for >>>>>>> both problems? >>>>>>> >>>>>>> An extension for certmonger? Oddjob? Or a completely new daemon? >>>>>>> >>>>>> Certmonger already has a way to: >>>>>> 1) Check things periodically >>>>>> 2) Hand certs in different places >>>>>> 3) Run post op scripts >>>>>> >>>>>> IMO it is a good candidate but I would leave it to Nalin to chime in. >>>>>> >>>>> >>>>> I would expect more things that require periodic checking on clients >>>>> beyond certificates to come in the future, so I'm not sure if doing >>>>> this >>>>> in certmonger is the right thing to do. Also, SSSD already does a >>>>> similar thing for realm domains, right? >>> >>> Are you suggesting extending SSSD to handle that? >> >> Yes. >> >>> >>>>> >>>>> Honza >>>>> >>>> >>>> So, does anyone have any strong opinions on this? >>> >>> Not at this point. BTW, is there any reason why we cannot go the >>> simple way and >>> just utilize cron and a script? Previously we just dropped conf to >>> /etc/cron.d >>> for ipa-compliance script and it worked quite well. >> >> Hmm, that's so simple it might just work. At least until there is a >> better way. > > I have been thinking about this for some time now and came up with this > solution: > > Write a library implementing the PKCS#11 API (Cryptoki), which would > provide the shared CA certificates and associated information > (nicknames, trust flags). The library would get the certificates from > SSSD, which in turn would get them from IPA (and do the usual stuff like > caching). > > This library could then be used by IPA NSS databases as a source of > trust information for IPA services (see modutil). It could also be used > by p11-glue to provide the trust information to the rest of the system. > > Pros: > * Automatic support for getting trust information stored in IPA in all > the applications that understand PKCS#11. > * Certificates are fetched from IPA on-demand, not periodically like > in the previous solutions. > > Cons: > * Complexity of implementation? (I don't know about this one, I > briefly looked at the source code of the p11-kit PKCS#11 module and it > looked manageable to me.) > > Does this sound reasonable? This sounds like the right approach to me. I've written several PKCS#11 modules, and am willing to help with a starter implementation, if that's needed. Stef From thozza at redhat.com Tue Oct 1 12:28:04 2013 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 01 Oct 2013 14:28:04 +0200 Subject: [Freeipa-devel] [PATCH 0192] Prevent deadlock in PTR record synchronization (versions <= 2.x) In-Reply-To: <52443268.4060301@redhat.com> References: <52443268.4060301@redhat.com> Message-ID: <524ABFD4.2040204@redhat.com> On 09/26/2013 03:11 PM, Petr Spacek wrote: > Hello, > > attached patch prevents/hides deadlock in plugin versions versions <= 2.x. > > I plan to push it to v2 branch. Branches v3 and newer shouldn't be > affected. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/113 ACK. I tested the patch with: freeipa-server-3.1.5-1.fc18.x86_64 freeipa-client-3.1.5-1.fc18.x86_64 With the patch, records are added successfully for the client and no warnings/errors are printed in the server log. However the ipa-client-install command still prints "Failed to update DNS records." even though everything passed fine on the server. Maybe there is some issue with the ipa-client. Regards, Tomas From mbasti at redhat.com Tue Oct 1 13:49:03 2013 From: mbasti at redhat.com (Martin Basti) Date: Tue, 01 Oct 2013 15:49:03 +0200 Subject: [Freeipa-devel] [PATCH][DOC] 0007 Removed trailing whitespaces Message-ID: <1380635343.2140.14.camel@unused-4-145.brq.redhat.com> Patch removes trailing whitespaces in user guide from chapter 6 to end Whitespaces was removed by: sed 's/[ \t]\+$//' -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0007-Removed-trailing-whitespaces-from-ch6-to-end.patch Type: text/x-patch Size: 590649 bytes Desc: not available URL: From pvoborni at redhat.com Tue Oct 1 14:29:02 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 01 Oct 2013 16:29:02 +0200 Subject: [Freeipa-devel] [DOC] Chapter 4 text In-Reply-To: <1380297179.2116.20.camel@unused-4-145.brq.redhat.com> References: <1379517057.9269.7.camel@unused-4-145.brq.redhat.com> <1380297179.2116.20.camel@unused-4-145.brq.redhat.com> Message-ID: <524ADC2E.2040805@redhat.com> On 09/27/2013 05:52 PM, Martin Basti wrote: > On Wed, 2013-09-18 at 17:10 +0200, Martin Basti wrote: >> Patch fix examples in chapter 4, adds new examples, fix out of date >> information. >> >> NOTE: Patch doesn't cover part 4.3 Logging with web UI > Updated patch > NACK >> 1. Table 4.1. Configuration Areas Per Tab is missing Trusts in IPA tab. This menu item is visible only if ipa-adtrust-install was run. > + Trusts (shown if AD-trust exists) ipa-adtrust-install was run != AD-trust exists From ipa-adtrust-install man page: ipa-adtrust-install - Prepare an IPA server to be able to establish trust relationships with AD domains -- Petr Vobornik From pvoborni at redhat.com Tue Oct 1 14:29:13 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 01 Oct 2013 16:29:13 +0200 Subject: [Freeipa-devel] [DOC] 0005 Updated chapter 4 - login into web UI In-Reply-To: <1380559529.2128.4.camel@unused-4-145.brq.redhat.com> References: <1379685975.2094.5.camel@unused-4-145.brq.redhat.com> <523C6C47.400@redhat.com> <1380559529.2128.4.camel@unused-4-145.brq.redhat.com> Message-ID: <524ADC39.2040703@redhat.com> On 09/30/2013 06:45 PM, Martin Basti wrote: > On Fri, 2013-09-20 at 17:39 +0200, Petr Vobornik wrote: >> On 09/20/2013 04:06 PM, Martin Basti wrote: >>> Logging into web UI and configuring web browser sections were outdated >>> >> >> Thanks for the path. >> >> Here are my comments (some for existing issues): >> >> 1. There are whitespace warnings when applying this patch. > Fixed >> >> 2. PDF output is bad. Images are too big - right half is not displayed. >> Several times there is image A with list item for image B below (image B >> is on the next page with list item for image C). >> >> I saw some 'missing image constraints warnings' during build - maybe >> that's the cause. > More important is HTML, there is 440px width limit for images in PDF and > current images are not readable in PDF > >> 3. Section 4.3.5: Don't know why it's called 'Simple authentication'. >> Usually it's referred to as 'forms based authentication'. > Changed to form based auth > >> 3a. Following sentence is misleading: >> "the error first says to renew the Kerberos credentials or to >> configure the browser to support Kerberos authentication." >> IIRC the previous dialog had different wording. The new one gives user >> two options but it doesn't encourage user to 'renew Kerberos >> credentials'. Also, you have deleted the first instruction but left a >> second: "Then simply supply the UID and password for a configured >> FreeIPA user." without any context. IMO it should be reworded. > Reworded > >> 4. I think the entire section '4.3.6. Using the UI with Proxy Servers' >> is incorrect. Using Web UI with proxy is not an easy thing to do. >> > Removed section > >> 5. Old unused images should be deleted. >> > Deleted + deleted unused xml which requires unused images >> 6. Section 4.4.1 (not sure if it's related to this patch) says: >> "randomly selects up to 20 entries" that's not true. There is no >> randomness. It selects: First record: ($PAGE_NUM * 20 +1), up to Last: >> (($PAGE_NUM + 1) *20). When first index is 1. > Fixed > >> 6a. LDAP search limit: the option name is --pkey-only not --pkey. >> > Fixed > > updated patch attached > Note that 6 and 6a are implemented in mbasti 0004-2. ACK -- Petr Vobornik From abokovoy at redhat.com Tue Oct 1 15:15:09 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 1 Oct 2013 18:15:09 +0300 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <20130930123143.GJ4216@redhat.com> References: <523C388E.2050008@redhat.com> <523FF024.4010300@redhat.com> <20130923081509.GR4216@redhat.com> <20130923141841.GS4216@redhat.com> <20130923150422.GT4216@redhat.com> <20130927125308.GD4216@redhat.com> <20130927163121.GM10000@localhost.localdomain> <20130928200134.GF4216@redhat.com> <52495AEB.7000204@redhat.com> <20130930123143.GJ4216@redhat.com> Message-ID: <20131001151509.GP4216@redhat.com> On Mon, 30 Sep 2013, Alexander Bokovoy wrote: >On Mon, 30 Sep 2013, Tomas Babej wrote: >>On 09/28/2013 10:01 PM, Alexander Bokovoy wrote: >>>On Fri, 27 Sep 2013, Sumit Bose wrote: >>>>On Fri, Sep 27, 2013 at 03:53:08PM +0300, Alexander Bokovoy wrote: >>>>>On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >>>>>>On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >>>>>>>On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >>>>>>>>On Mon, 23 Sep 2013, Martin Kosek wrote: >>>>>>>>>>>However, we don't have trust type available so it >>>>>>>>>>>needs >>>>>to discovered >>>>>>>>>>>every time. This doesn't play well with the >>>>>>>>>>>framework, it >>>>>is simply not >>>>>>>>>>>expecting dynamic containers. >>>>>>>>>> >>>>>>>>>>This doesn't sound like a big obstacle to me. Right >>>>>>>>>>now >>>>>the trust_type lookup >>>>>>>>>>is done in trust_show.execute() for some reason, >>>>>>>>>>which is >>>>>not the best place to >>>>>>>>>>do it IMHO. Doing it in trust.get_dn() instead >>>>>>>>>>should >>>>>simplify things enough to >>>>>>>>>>make parent_object work. >>>>>>>>> >>>>>>>>>Yup, get_dn() is the method where object DN lookup >>>>>>>>>should >>>>>be done. See for >>>>>>>>>example host.py plugin get_dn method, we also do a >>>>>>>>>dynamic >>>>>lookup for correct >>>>>>>>>host name. >>>>>>>>I'll see if that would work. >>>>>>>> >>>>>>>>>the best way to implement dynamic DN gathering is the >>>>>get_dn() method. That >>>>>>>>>way, it could be implemented in one place and all >>>>>>>>>commands >>>>>could take advantage >>>>>>>>>of it instead of re-implementing it several times in >>>>>pre_callback - this is >>>>>>>>>just hackish. >>>>>>>>I'd suggest you look into the code. The commands use >>>>>pre_callback for a >>>>>>>>different purpose than implementing dynamic DN gathering. >>>>>>>> >>>>>>>>>I think it would have been very useful to have a >>>>>>>>>design >>>>>page before sending a >>>>>>>>>patch. It is then easier to make design decisions >>>>>>>>>without >>>>>having to dig into >>>>>>>>>the patch. >>>>>>>>The design page is there for long time: >>>>>>>>http://www.freeipa.org/page/V3/Transitive_Trusts >>>>>>>Ok, here is new version of the patch and updated version of my 0117 >>>>>>>patch as Sumit noticed I've sent wrong version. >>>>>>Ok, here is updated 0118 which fixes API.txt change for >>>>>trustdomain_add >>>>>>-- I renamed trustdomain_create to trustdomain_add but forgot to rerun >>>>>>makeapi. >>>>>New edition attached for all subdomain-related patches: >>>> >>>>I did some tests and all is working as expected. >>>> >>>>> >>>>>freeipa-abbra-0117-ipaserver-dcerpc.py-populate-forest-trust-informatio-3.patch >>>>> >>>>> Use realmdomains to report name suffix routes at the time we >>>>>establish trust >>>>> >>>>>freeipa-abbra-0118-trusts-support-subdomains-in-a-forest-3.patch >>>>> Introduce trustdomain-* commands to fetch list of domains associated >>>>> with a forest trust and allow filtering them off >>>> >>>>We talked on irc that ipaNTSupportedEncryptionTypes in the filter >>>>for the trusted domains should be replace by a different attribute. >>>>Because of an error in ipasam the ipaNTSupportedEncryptionTypes is only >>>>set in recent versions and might not be present in the >>>>directory trees of >>>>older versions. >>>Fixed in the attached patch 0118 version 4. >>> >>>Also attached first attempt to implement transiting through trusted >>>domains, as patch 0123. In this patch we grant transition only if all >>>three realms (client, transited realm, and server realm) match any of >>>our trusted domains and our domain. This is probably a bit wider but it >>>worked for me bidirectionally, from a child domain to a service in IPA, >>>and from IPA realm to a service in a child domain of a forest trust. >>> >>> >>> >>>_______________________________________________ >>>Freeipa-devel mailing list >>>Freeipa-devel at redhat.com >>>https://www.redhat.com/mailman/listinfo/freeipa-devel >> >>Hi, >> >>here are my comments: >> >>*PATCH 117* >> >>+ def get_realmdomains(self): >>+ """ >>+ Generate list of records for forest trust information about >>+ our realm domains. Note that the list generated currently >>+ includes only top level domains, no exclusion domains, and >>no TDO objects >>+ as we handle the latter in a separte way >>+ """ >> >>A nitpick typo: separte -> separate. >Fixed. > >> >>Also, there's trailing whitespace in the patch: >> >>Applying: ipaserver/dcerpc.py: populate forest trust information >>using realmdomains >>/home/tbabej/dev/freeipa/.git/rebase-apply/patch:62: trailing whitespace. >> Only top level name and top level name exclusions are handled here. >>/home/tbabej/dev/freeipa/.git/rebase-apply/patch:174: trailing whitespace. >> >>warning: 2 lines add whitespace errors. >Fixed. > >> >> >>*PATCH 119* >> >>We also need to change the frontend tests that cover this functionality: >> >>====================================================================== >>FAIL: Test the ``ipalib.frontend.Command.args`` instance attribute. >>---------------------------------------------------------------------- >>Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>runTest >> self.test(*self.arg) >> File >>"/home/tbabej/dev/freeipa/ipatests/test_ipalib/test_frontend.py", >>line 283, in test_args >> assert str(e) == 'arg2: required argument after optional' >>AssertionError >> >>See ipatests/test_ipalib/test_frontend.py, line 281: >> >> # Test ValueError, required after optional: >> e = raises(ValueError, self.get_instance, args=('arg1?', 'arg2')) >> assert str(e) == 'arg2: required argument after optional' >Ok, will fix. This patch is not essential, of course, so we can decide >what to do with it later. > >> >> >>*PATCH 120* >> >>When I try to add a trust, I get internal error: >> >>echo $AD_PASSWORD | ipa trust-add --type=ad $AD_DOMAIN --admin >>Administrator --password >> >>[Wed Sep 25 10:28:53.978664 2013] [:error] [pid 7905] ipa: ERROR: >>non-public: IndexError: tuple index out of range >>[Wed Sep 25 10:28:53.978702 2013] [:error] [pid 7905] Traceback >>(most recent call last): >>[Wed Sep 25 10:28:53.978708 2013] [:error] [pid 7905] File >>"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line >>333, in wsgi_execute >>[Wed Sep 25 10:28:53.978713 2013] [:error] [pid 7905] result = >>self.Command[name](*args, **options) >>[Wed Sep 25 10:28:53.978720 2013] [:error] [pid 7905] File >>"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in >>__call__ >>[Wed Sep 25 10:28:53.978725 2013] [:error] [pid 7905] ret = >>self.run(*args, **options) >>[Wed Sep 25 10:28:53.978730 2013] [:error] [pid 7905] File >>"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 755, in >>run >>[Wed Sep 25 10:28:53.978734 2013] [:error] [pid 7905] result = >>self.execute(*args, **options) >>[Wed Sep 25 10:28:53.978739 2013] [:error] [pid 7905] File >>"/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py", line >>338, in execute >>[Wed Sep 25 10:28:53.978744 2013] [:error] [pid 7905] >>self.add_range(range_name, dom_sid, *keys, **options) >>[Wed Sep 25 10:28:53.978748 2013] [:error] [pid 7905] File >>"/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py", line >>549, in add_range >>[Wed Sep 25 10:28:53.978755 2013] [:error] [pid 7905] quiet=True) >>[Wed Sep 25 10:28:53.978759 2013] [:error] [pid 7905] File >>"/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 507, >>in search_in_dc >>[Wed Sep 25 10:28:53.978764 2013] [:error] [pid 7905] info = >>self.__retrieve_trusted_domain_gc_list(domain) >>[Wed Sep 25 10:28:53.978769 2013] [:error] [pid 7905] File >>"/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 595, >>in __retrieve_trusted_domain_gc_list >>[Wed Sep 25 10:28:53.978774 2013] [:error] [pid 7905] info['auth'] >>= self._domains[domain][2] >>[Wed Sep 25 10:28:53.978778 2013] [:error] [pid 7905] IndexError: >>tuple index out of range >>[Wed Sep 25 10:28:53.979248 2013] [:error] [pid 7905] ipa: INFO: >>admin at DOM006.TBAD.IPA.COM: trust_add(u'tbad.ipa.com', >>trust_type=u'ad', realm_admin=u'Administrator', >>realm_passwd=u'********', all=False, raw=False, version=u'2.65'): >>IndexError >> >>I think we need to do the following changes here: >> >>diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py >>index fa5c449..4ac0a5f 100644 >>--- a/ipaserver/dcerpc.py >>+++ b/ipaserver/dcerpc.py >>@@ -565,7 +565,6 @@ class DomainValidator(object): >> Returns dictionary with following keys >> name -- NetBIOS name of the trusted domain >> dns_domain -- DNS name of the trusted domain >>- auth -- encrypted credentials for trusted domain account >> gc -- array of tuples (server, port) for >>Global Catalog >> """ >> if domain in self._info: >>@@ -592,7 +591,6 @@ class DomainValidator(object): >> self._domains = self.get_trusted_domains() >> >> info = dict() >>- info['auth'] = self._domains[domain][2] >> servers = [] >> >> if result: >> >>After applying this fix, I get: >> >>tbabej at vm-006 freeipa]$ echo $AD_PASSWORD | ipa trust-add --type=ad >>$AD_DOMAIN --admin Administrator --password >>ipa: ERROR: CIFS server communication error: code "-1073741811", >> message "Unexpected information received" (both >>may be "None") >> >>I was unable to track this one down in a reasonable timeframe, I >>suggest we continue on IRC. >I've fixed this. At the time we establish trust, there could be a race >condition when cross-realm TGT is not yet ready so we cannot rely on it >when fetching domains. As we have administrator's credentials here, I've >added use of them in addition to Kerberos. > > >I'll send new patchset shortly. New patchset is attached. 1. Added test update for ipalib/frontend.py changes 2. Used LDAPQuery as base for trustdomain_enable|disable commands as suggested by Honza. 3. Fixed issues with removal of trust account password authentication 4. Added support to use AD administrator credentials when fetching subdomains information when we establish trust as Kerberos will not be available for cross-realm operations yet. 5. Patch 0123 is not part of the patchset and should not be committed, we will discuss exact semantics of transition checks with MIT Kerberos upstream first. 6. Fixed few error paths and dead-end cases like attempt to disable root domain of the trust (renders trust dead) or enabling it (it is always enabled). 7. Made clear that deleting root domain of the trust is not possible, use trust-del instead. 8. Removed whitespaces where saw. -- / Alexander Bokovoy -------------- next part -------------- >From 690d7a71b053aef2eca5b7def0770f37a9659b4e Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 11 Sep 2013 21:34:55 +0300 Subject: [PATCH 1/7] ipaserver/dcerpc.py: populate forest trust information using realmdomains Use realmdomains information to prepopulate forest trust info. As result, all additional domains should now be enabled from the beginning, unless they really conflict with existing DNS domains on AD side. https://fedorahosted.org/freeipa/ticket/3919 --- ipaserver/dcerpc.py | 113 +++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 95 insertions(+), 18 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index bd8f5aa..cc9e7be 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -39,7 +39,7 @@ import uuid from samba import param from samba import credentials from samba.dcerpc import security, lsa, drsblobs, nbt, netlogon -from samba.ndr import ndr_pack +from samba.ndr import ndr_pack, ndr_print from samba import net import samba import random @@ -684,6 +684,12 @@ class DomainValidator(object): self._info[domain] = info return info +def string_to_array(what): + blob = [0] * len(what) + + for i in range(len(what)): + blob[i] = ord(what[i]) + return blob class TrustDomainInstance(object): @@ -698,6 +704,7 @@ class TrustDomainInstance(object): self._pipe = None self._policy_handle = None self.read_only = False + self.ftinfo_records = None def __gen_lsa_connection(self, binding): if self.creds is None: @@ -827,12 +834,6 @@ class TrustDomainInstance(object): def arcfour_encrypt(key, data): c = RC4.RC4(key) return c.update(data) - def string_to_array(what): - blob = [0] * len(what) - - for i in range(len(what)): - blob[i] = ord(what[i]) - return blob password_blob = string_to_array(trustdom_secret.encode('utf-16-le')) @@ -876,6 +877,53 @@ class TrustDomainInstance(object): self.auth_info = auth_info + def generate_ftinfo(self, another_domain): + """ + Generates TrustDomainInfoFullInfo2Internal structure + This structure allows to pass information about all domains associated + with the another domain's realm. + + Only top level name and top level name exclusions are handled here. + """ + if not another_domain.ftinfo_records: + return + + ftinfo_records = [] + info = lsa.ForestTrustInformation() + + for rec in another_domain.ftinfo_records: + record = lsa.ForestTrustRecord() + record.flags = 0 + record.time = rec['rec_time'] + record.type = rec['rec_type'] + record.forest_trust_data.string = rec['rec_name'] + ftinfo_records.append(record) + + info.count = len(ftinfo_records) + info.entries = ftinfo_records + return info + + def update_ftinfo(self, another_domain): + """ + Updates forest trust information in this forest corresponding + to the another domain's information. + """ + try: + if another_domain.ftinfo_records: + ftinfo = self.generate_ftinfo(another_domain) + # Set forest trust information -- we do it only against AD DC as + # smbd already has the information about itself + ldname = lsa.StringLarge() + ldname.string = another_domain.info['dns_domain'] + collision_info = self._pipe.lsaRSetForestTrustInformation(self._policy_handle, + ldname, + lsa.LSA_FOREST_TRUST_DOMAIN_INFO, + ftinfo, 0) + if collision_info: + root_logger.error("When setting forest trust information, got collision info back:\n%s" % (ndr_print(collision_info))) + except RuntimeError, e: + # We can ignore the error here -- setting up name suffix routes may fail + pass def establish_trust(self, another_domain, trustdom_secret): """ @@ -883,6 +931,12 @@ class TrustDomainInstance(object): Input: another_domain -- instance of TrustDomainInstance, initialized with #retrieve call trustdom_secret -- shared secred used for the trust """ + if self.info['name'] == another_domain.info['name']: + # Check that NetBIOS names do not clash + raise errors.ValidationError(name=u'AD Trust Setup', + error=_('the IPA server and the remote domain cannot share the same ' + 'NetBIOS name: %s') % self.info['name']) + self.generate_auth(trustdom_secret) info = lsa.TrustDomainInfoInfoEx() @@ -893,12 +947,6 @@ class TrustDomainInstance(object): info.trust_type = lsa.LSA_TRUST_TYPE_UPLEVEL info.trust_attributes = lsa.LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE - if self.info['name'] == info.netbios_name.string: - # Check that NetBIOS names do not clash - raise errors.ValidationError(name=u'AD Trust Setup', - error=_('the IPA server and the remote domain cannot share the same ' - 'NetBIOS name: %s') % self.info['name']) - try: dname = lsa.String() dname.string = another_domain.info['dns_domain'] @@ -911,12 +959,14 @@ class TrustDomainInstance(object): except RuntimeError, (num, message): raise assess_dcerpc_exception(num=num, message=message) + self.update_ftinfo(another_domain) + + # We should use proper trustdom handle in order to modify the + # trust settings. Samba insists this has to be done with LSA + # OpenTrustedDomain* calls, it is not enough to have a handle + # returned by the CreateTrustedDomainEx2 call. + trustdom_handle = self._pipe.OpenTrustedDomainByName(self._policy_handle, dname, security.SEC_FLAG_MAXIMUM_ALLOWED) try: - # We should use proper trustdom handle in order to modify the - # trust settings. Samba insists this has to be done with LSA - # OpenTrustedDomain* calls, it is not enough to have a handle - # returned by the CreateTrustedDomainEx2 call. - trustdom_handle = self._pipe.OpenTrustedDomainByName(self._policy_handle, dname, security.SEC_FLAG_MAXIMUM_ALLOWED) infoclass = lsa.TrustDomainInfoSupportedEncTypes() infoclass.enc_types = security.KERB_ENCTYPE_RC4_HMAC_MD5 infoclass.enc_types |= security.KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 @@ -1016,6 +1066,32 @@ class TrustDomainJoins(object): # Otherwise, use anonymously obtained data self.remote_domain = rd + def get_realmdomains(self): + """ + Generate list of records for forest trust information about + our realm domains. Note that the list generated currently + includes only top level domains, no exclusion domains, and no TDO objects + as we handle the latter in a separte way + """ + if self.local_domain.read_only: + return + + self.local_domain.ftinfo_records = [] + + realm_domains = self.api.Command.realmdomains_show()['result'] + trustconfig = self.api.Command.trustconfig_show()['result'] + # Use realmdomains' modification timestamp to judge records last update time + (dn, entry_attrs) = self.api.Backend.ldap2.get_entry(realm_domains['dn'], ['modifyTimestamp']) + # Convert the timestamp to Windows 64-bit timestamp format + trust_timestamp = long(time.mktime(time.strptime(entry_attrs['modifytimestamp'][0][:14], "%Y%m%d%H%M%S"))*1e7+116444736000000000) + + for dom in realm_domains['associateddomain']: + ftinfo = dict() + ftinfo['rec_name'] = dom + ftinfo['rec_time'] = trust_timestamp + ftinfo['rec_type'] = lsa.LSA_FOREST_TRUST_TOP_LEVEL_NAME + self.local_domain.ftinfo_records.append(ftinfo) + def join_ad_full_credentials(self, realm, realm_server, realm_admin, realm_passwd): if not self.configured: return None @@ -1030,6 +1106,7 @@ class TrustDomainJoins(object): if not self.remote_domain.read_only: trustdom_pass = samba.generate_random_password(128, 128) + self.get_realmdomains() self.remote_domain.establish_trust(self.local_domain, trustdom_pass) self.local_domain.establish_trust(self.remote_domain, trustdom_pass) result = self.remote_domain.verify_trust(self.local_domain) -- 1.8.3.1 -------------- next part -------------- >From a36e53eab287e5eda88cd28d10c681b93af9d68b Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 18 Sep 2013 17:04:19 +0200 Subject: [PATCH 2/7] trusts: support subdomains in a forest Add IPA CLI to manage trust domains. ipa trust-fetch-domains -- fetch list of subdomains from AD side and add new ones to IPA ipa trustdomain-find -- show all available domains ipa trustdomain-del -- remove domain from IPA view about ipa trustdomain-enable -- allow users from trusted domain to access resources in IPA ipa trustdomain-disable -- disable access to resources in IPA from trusted domain By default all discovered trust domains are allowed to access IPA resources IPA KDC needs also information for authentication paths to subdomains in case they are not hierarchical under AD forest trust root. This information is managed via capaths section in krb5.conf. SSSD should be able to generate it once ticket https://fedorahosted.org/sssd/ticket/2093 is resolved. part of https://fedorahosted.org/freeipa/ticket/3909 --- API.txt | 80 +++++++++++ ipalib/plugins/trust.py | 346 +++++++++++++++++++++++++++++++++++++++++------- ipaserver/dcerpc.py | 54 ++++++++ 3 files changed, 429 insertions(+), 51 deletions(-) diff --git a/API.txt b/API.txt index 761d1d1..d9242eb 100644 --- a/API.txt +++ b/API.txt @@ -3423,6 +3423,15 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: Output('value', , None) +command: trust_fetch_domains +args: 1,4,2 +arg: Str('cn', attribute=True, cli_name='realm', multivalue=False, primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) command: trust_find args: 1,11,4 arg: Str('criteria?', noextrawhitespace=False) @@ -3497,6 +3506,77 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: Output('value', , None) +command: trustdomain_add +args: 2,9,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('cn', cli_name='domain') +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('ipantflatname', attribute=True, cli_name='flat_name', multivalue=False, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, cli_name='sid', multivalue=False, required=False) +option: Str('ipanttrustpartner', attribute=True, cli_name='ipanttrustpartner', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', values=(u'ad',)) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trustdomain_del +args: 2,2,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('cn', cli_name='domain') +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trustdomain_disable +args: 2,1,1 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('cn', cli_name='domain') +option: Str('version?', exclude='webui') +output: Output('summary', (, ), None) +command: trustdomain_enable +args: 2,1,1 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('cn', cli_name='domain') +option: Str('version?', exclude='webui') +output: Output('summary', (, ), None) +command: trustdomain_find +args: 2,8,4 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('ipantflatname', attribute=True, autofill=False, cli_name='flat_name', multivalue=False, query=True, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='sid', multivalue=False, query=True, required=False) +option: Str('ipanttrustpartner', attribute=True, autofill=False, cli_name='ipanttrustpartner', multivalue=False, query=True, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: trustdomain_mod +args: 2,11,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('cn', cli_name='domain') +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('ipantflatname', attribute=True, autofill=False, cli_name='flat_name', multivalue=False, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='sid', multivalue=False, required=False) +option: Str('ipanttrustpartner', attribute=True, autofill=False, cli_name='ipanttrustpartner', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', values=(u'ad',)) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('value', , None) command: user_add args: 1,35,3 arg: Str('uid', attribute=True, cli_name='login', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 3c117b4..de98451 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -181,6 +181,13 @@ def trust_status_string(level): string = _trust_status_dict.get(level, _trust_type_dict_unknown) return unicode(string) +def make_trust_dn(env, trust_type, dn): + assert isinstance(dn, DN) + if trust_type: + container_dn = DN(('cn', trust_type), env.container_trusts, env.basedn) + return DN(dn, container_dn) + return dn + class trust(LDAPObject): """ Trust object. @@ -195,7 +202,8 @@ class trust(LDAPObject): 'ipantauthtrustoutgoing', 'ipanttrustauthincoming', 'ipanttrustforesttrustinfo', 'ipanttrustposixoffset', 'ipantsupportedencryptiontypes' ] search_display_attributes = ['cn', 'ipantflatname', - 'ipanttrusteddomainsid', 'ipanttrusttype' ] + 'ipanttrusteddomainsid', 'ipanttrusttype', + 'ipantsidblacklistincoming', 'ipantsidblacklistoutgoing' ] label = _('Trusts') label_singular = _('Trust') @@ -241,12 +249,26 @@ class trust(LDAPObject): raise errors.ValidationError(name=attr, error=_("invalid SID: %(value)s") % dict(value=value)) -def make_trust_dn(env, trust_type, dn): - assert isinstance(dn, DN) - if trust_type in trust.trust_types: - container_dn = DN(('cn', trust_type), env.container_trusts, env.basedn) - return DN(dn[0], container_dn) - return dn + def get_dn(self, *keys, **kwargs): + sdn = map(lambda x: ('cn', x), keys) + sdn.reverse() + trust_type = kwargs.get('trust_type') + if trust_type is None: + ldap = self.backend + filter = ldap.make_filter({'objectclass': ['ipaNTTrustedDomain'], 'cn': [keys[-1]]}) + filter = ldap.combine_filters((filter, "ipaNTSIDBlacklistIncoming=*"), rules=ldap.MATCH_ALL) + try: + result = ldap.get_entries(DN(self.container_dn, self.env.basedn), + ldap.SCOPE_SUBTREE, filter, ['']) + except errors.NotFound: + trust_type = u'ad' + else: + if len(result) > 1: + raise errors.OnlyOneValueAllowed(attr='trust domain') + return result[0].dn + + dn=make_trust_dn(self.env, trust_type, DN(*sdn)) + return dn class trust_add(LDAPCreate): __doc__ = _(''' @@ -576,10 +598,13 @@ sides. def execute_ad(self, full_join, *keys, **options): # Join domain using full credentials and with random trustdom # secret (will be generated by the join method) - try: - api.Command['trust_show'](keys[-1]) + + # First see if the trust is already in place + # Force retrieval of the trust object by not passing trust_type + dn = self.obj.get_dn(keys[-1]) + if dn: summary = _('Re-established trust to domain "%(value)s"') - except errors.NotFound: + else: summary = self.msg_summary # 1. Full access to the remote domain. Use admin credentials and @@ -652,14 +677,6 @@ class trust_del(LDAPDelete): msg_summary = _('Deleted trust "%(value)s"') - def pre_callback(self, ldap, dn, *keys, **options): - assert isinstance(dn, DN) - try: - result = self.api.Command.trust_show(keys[-1]) - except errors.NotFound, e: - self.obj.handle_not_found(*keys) - return result['result']['dn'] - class trust_mod(LDAPUpdate): __doc__ = _(""" Modify a trust (for future use). @@ -673,16 +690,10 @@ class trust_mod(LDAPUpdate): def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): assert isinstance(dn, DN) - result = None - try: - result = self.api.Command.trust_show(keys[-1]) - except errors.NotFound, e: - self.obj.handle_not_found(*keys) self.obj.validate_sid_blacklists(entry_attrs) - # TODO: we found the trust object, now modify it - return result['result']['dn'] + return dn class trust_find(LDAPSearch): __doc__ = _('Search for trusts.') @@ -696,8 +707,10 @@ class trust_find(LDAPSearch): # Since all trusts types are stored within separate containers under 'cn=trusts', # search needs to be done on a sub-tree scope def pre_callback(self, ldap, filters, attrs_list, base_dn, scope, *args, **options): - assert isinstance(base_dn, DN) - return (filters, base_dn, ldap.SCOPE_SUBTREE) + # list only trust, not trust domains + trust_filter = '(ipaNTSIDBlacklistIncoming=*)' + filter = ldap.combine_filters((filters, trust_filter), rules=ldap.MATCH_ALL) + return (filter, base_dn, ldap.SCOPE_SUBTREE) def post_callback(self, ldap, entries, truncated, *args, **options): if options.get('pkey_only', False): @@ -718,30 +731,6 @@ class trust_show(LDAPRetrieve): has_output_params = LDAPRetrieve.has_output_params + trust_output_params +\ (Str('ipanttrusttype'), Str('ipanttrustdirection')) - def execute(self, *keys, **options): - error = None - result = None - for trust_type in trust.trust_types: - options['trust_show_type'] = trust_type - try: - result = super(trust_show, self).execute(*keys, **options) - except errors.NotFound, e: - result = None - error = e - if result: - break - if error or not result: - self.obj.handle_not_found(*keys) - - return result - - def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): - assert isinstance(dn, DN) - if 'trust_show_type' in options: - return make_trust_dn(self.env, options['trust_show_type'], dn) - - return dn - def post_callback(self, ldap, dn, entry_attrs, *keys, **options): # Translate ipanttrusttype to trusttype @@ -1078,3 +1067,258 @@ class sidgen_was_run(Command): return dict(result=True) api.register(sidgen_was_run) + +class trustdomain(LDAPObject): + """ + Object representing a domain of the AD trust. + """ + parent_object = 'trust' + trust_type_idx = {'2':u'ad'} + object_name = _('trust domain') + object_name_plural = _('trust domains') + object_class = ['ipaNTTrustedDomain'] + default_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', 'ipanttrustpartner'] + search_display_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', ] + + label = _('Trusted domains') + label_singular = _('Trusted domain') + + # We do not add this argument implicitly via takes_args in the object. + # Rather, it is added explicitly in the commands that require second arg + # because first argument will be inherited from the 'trust' parent object + trustdomain_args = ( + Str('cn', + label=_('Domain name'), + cli_name='domain', + ), + ) + + takes_params = ( + Str('ipantflatname?', + cli_name='flat_name', + label=_('Domain NetBIOS name'), + ), + Str('ipanttrusteddomainsid?', + cli_name='sid', + label=_('Domain Security Identifier'), + ), + Str('ipanttrustpartner?', + label=_('Trusted domain partner'), + flags=['no_display', 'no_option'], + ), + ) + + # LDAPObject.get_dn() only passes all but last element of keys and no kwargs + # to the parent object's get_dn() no matter what you pass to it. Make own get_dn() + # as we really need all elements to construct proper dn. + def get_dn(self, *keys, **kwargs): + sdn = map(lambda x: ('cn', x), keys) + sdn.reverse() + trust_type = kwargs.get('trust_type') + if not trust_type: + trust_type=u'ad' + + dn=make_trust_dn(self.env, trust_type, DN(*sdn)) + return dn +api.register(trustdomain) + +class trustdomain_find(LDAPSearch): + __doc__ = _('Search domains of the trust') + + has_output_params = LDAPSearch.has_output_params + trustdomain.trustdomain_args + def pre_callback(self, ldap, filters, attrs_list, base_dn, scope, *args, **options): + return (filters, base_dn, ldap.SCOPE_SUBTREE) +api.register(trustdomain_find) + +class trustdomain_mod(LDAPUpdate): + __doc__ = _('Modify trustdomain of the trust') + + NO_CLI = True + takes_args = trustdomain.trustdomain_args + takes_options = LDAPUpdate.takes_options + (_trust_type_option,) +api.register(trustdomain_mod) + +class trustdomain_add(LDAPCreate): + __doc__ = _('Allow access from the trusted domain') + NO_CLI = True + + takes_args = trustdomain.trustdomain_args + takes_options = LDAPCreate.takes_options + (_trust_type_option,) + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + if 'ipanttrustpartner' in options: + entry_attrs['ipanttrustpartner'] = [options['ipanttrustpartner']] + return dn +api.register(trustdomain_add) + +class trustdomain_del(LDAPDelete): + __doc__ = _('Remove infromation about the domain associated with the trust.') + + msg_summary = _('Removed information about the trusted domain "%(value)s"') + + takes_args = trustdomain.trustdomain_args + + def execute(self, *keys, **options): + # Note that pre-/post- callback handling for LDAPDelete is causing pre_callback + # to always receive empty keys. We need to catch the case when root domain is being deleted + if keys[0].lower() == keys[1].lower(): + raise errors.ValidationError(name='trustdomain_del', + error=_("cannot delete root domain of the trust, use trust-del to delete the trust itself")) + result = super(trustdomain_del, self).execute(*keys, **options) + result['value'] = keys[1] + return result + + +api.register(trustdomain_del) + + +def fetch_domains_from_trust(self, trustinstance, trust_entry): + trust_name = trust_entry['cn'][0] + domains = ipaserver.dcerpc.fetch_domains(self.api, trustinstance.local_flatname, trust_name) + result = [] + if not domains: + return None + + for dom in domains: + dom['trust_type'] = u'ad' + try: + name = dom['cn'] + del dom['cn'] + res = self.api.Command.trustdomain_add(trust_name, name, **dom) + result.append(res['result']) + except errors.DuplicateEntry: + # Ignore updating duplicate entries + pass + return result + +class trust_fetch_domains(LDAPRetrieve): + __doc__ = _('Refresh list of the domains associated with the trust') + + has_output = ( + output.ListOfEntries('result'), + output.summary + ) + + def execute(self, *keys, **options): + if not _bindings_installed: + raise errors.NotFound( + name=_('AD Trust setup'), + reason=_( + 'Cannot perform join operation without Samba 4 support ' + 'installed. Make sure you have installed server-trust-ad ' + 'sub-package of IPA' + ) + ) + trust = self.api.Command.trust_show(keys[0], raw=True)['result'] + + trustinstance = ipaserver.dcerpc.TrustDomainJoins(self.api) + if not trustinstance.configured: + raise errors.NotFound( + name=_('AD Trust setup'), + reason=_( + 'Cannot perform join operation without own domain ' + 'configured. Make sure you have run ipa-adtrust-install ' + 'on the IPA server first' + ) + ) + domains = fetch_domains_from_trust(self, trustinstance, trust) + result = dict(result=[]) + if not domains: + result['summary'] = unicode(_('No trust domains were detected during refresh')) + return result + + if len(domains) > 0: + result['summary'] = unicode(_('List of trust domains successfully refreshed')) + else: + result['summary'] = unicode(_('No new trust domains were found')) + + result['result'] = domains + return result +api.register(trust_fetch_domains) + +class trustdomain_enable(LDAPQuery): + __doc__ = _('Allow use of IPA resources by the domain of the trust') + + has_output = ( + output.summary, + ) + + takes_args = trustdomain.trustdomain_args + + def execute(self, *keys, **options): + ldap = self.api.Backend.ldap2 + + if keys[0].lower() == keys[1].lower(): + raise errors.ValidationError(name='trustdomain_enable', + error=_("Root domain of the trust is always enabled for the existing trust")) + try: + trust_dn = self.obj.get_dn(keys[0], trust_type=u'ad') + trust_entry = ldap.get_entry(trust_dn) + except errors.NotFound: + raise errors.ValidationError(name=_('AD trust'), error=_('Valid trust name is required')) + + result = dict() + result['trust'] = unicode(keys[0]) + result['domain'] = unicode(keys[1]) + dn = self.obj.get_dn(keys[0], keys[1], trust_type=u'ad') + try: + entry = ldap.get_entry(dn) + sid = entry['ipanttrusteddomainsid'][0] + if sid in trust_entry['ipantsidblacklistincoming']: + trust_entry['ipantsidblacklistincoming'].remove(sid) + result['action'] = _('is allowed') + ldap.update_entry(trust_entry) + else: + result['action'] = _('is already allowed') + result['summary'] = _('Domain %(domain)s of trust %(trust)s %(action)s to access IPA resources') + except errors.NotFound: + raise errors.ValidationError(name=_('AD trust'), error=_('Valid trust domain name is required')) + except errors.EmptyModlist: + result['summary'] = _('No changes were done') + + return dict(summary=result['summary'] % result) + +api.register(trustdomain_enable) + +class trustdomain_disable(LDAPQuery): + __doc__ = _('Disable use of IPA resources by the domain of the trust') + + has_output = ( + output.summary, + ) + + takes_args = trustdomain.trustdomain_args + + def execute(self, *keys, **options): + ldap = self.api.Backend.ldap2 + + if keys[0].lower() == keys[1].lower(): + raise errors.ValidationError(name='trustdomain_disable', + error=_("cannot disable root domain of the trust, use trust-del to delete the trust itself")) + try: + trust_dn = self.obj.get_dn(keys[0], trust_type=u'ad') + trust_entry = ldap.get_entry(trust_dn) + except errors.NotFound: + raise errors.ValidationError(name=_('AD trust'), error=_('Valid trust name is required')) + + result = dict() + result['trust'] = unicode(keys[0]) + result['domain'] = unicode(keys[1]) + dn = self.obj.get_dn(keys[0], keys[1], trust_type=u'ad') + try: + entry = ldap.get_entry(dn) + sid = entry['ipanttrusteddomainsid'][0] + if not (sid in trust_entry['ipantsidblacklistincoming']): + trust_entry['ipantsidblacklistincoming'].append(sid) + result['action'] = _('is not allowed') + ldap.update_entry(trust_entry) + else: + result['action'] = _('is already not allowed') + result['summary'] = _('Domain %(domain)s of trust %(trust)s %(action)s to access IPA resources') + except errors.NotFound: + raise errors.ValidationError(name=_('AD trust'), error=_('Valid trust domain name is required')) + except errors.EmptyModlist: + result['summary'] = _('No changes were done') + + return dict(summary=result['summary'] % result) + +api.register(trustdomain_disable) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index cc9e7be..1c4f4a6 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -1002,6 +1002,60 @@ class TrustDomainInstance(object): return True return False +def fetch_domains(api, mydomain, trustdomain): + trust_flags = dict( + NETR_TRUST_FLAG_IN_FOREST = 0x00000001, + NETR_TRUST_FLAG_OUTBOUND = 0x00000002, + NETR_TRUST_FLAG_TREEROOT = 0x00000004, + NETR_TRUST_FLAG_PRIMARY = 0x00000008, + NETR_TRUST_FLAG_NATIVE = 0x00000010, + NETR_TRUST_FLAG_INBOUND = 0x00000020, + NETR_TRUST_FLAG_MIT_KRB5 = 0x00000080, + NETR_TRUST_FLAG_AES = 0x00000100) + + trust_attributes = dict( + NETR_TRUST_ATTRIBUTE_NON_TRANSITIVE = 0x00000001, + NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x00000002, + NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x00000004, + NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x00000008, + NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x00000010, + NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x00000020, + NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x00000040) + + domval = DomainValidator(api) + (ccache_name, principal) = domval.kinit_as_http(trustdomain) + if ccache_name: + with installutils.private_ccache(path=ccache_name): + td = TrustDomainInstance('') + td.parm.set('workgroup', mydomain) + td.creds = credentials.Credentials() + td.creds.set_kerberos_state(credentials.MUST_USE_KERBEROS) + td.creds.guess(td.parm) + netrc = net.Net(creds=td.creds, lp=td.parm) + try: + result = netrc.finddc(domain=trustdomain, flags=nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_DS) + except RuntimeError, e: + raise assess_dcerpc_exception(message=str(e)) + if not result: + return None + td.retrieve(unicode(result.pdc_dns_name)) + + netr_pipe = netlogon.netlogon(td.binding, td.parm, td.creds) + domains = netr_pipe.netr_DsrEnumerateDomainTrusts(td.binding, 1) + + result = [] + for t in domains.array: + if ((t.trust_attributes & trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and + (t.trust_flags & trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): + res = dict() + res['cn'] = unicode(t.dns_name) + res['ipantflatname'] = unicode(t.netbios_name) + res['ipanttrusteddomainsid'] = unicode(t.sid) + res['ipanttrustpartner'] = res['cn'] + result.append(res) + return result + + class TrustDomainJoins(object): def __init__(self, api): self.api = api -- 1.8.3.1 -------------- next part -------------- >From 78d1dfe476bc859d694f152b3cf36a071418d683 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 26 Sep 2013 16:44:37 +0200 Subject: [PATCH 3/7] frontend: report arguments errors with better detail When reporting argument errors, show also a context -- what is processed, what is the name of the command. --- ipalib/frontend.py | 3 ++- ipatests/test_ipalib/test_frontend.py | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/ipalib/frontend.py b/ipalib/frontend.py index cac3e3b..f478ef0 100644 --- a/ipalib/frontend.py +++ b/ipalib/frontend.py @@ -869,7 +869,8 @@ class Command(HasParam): for arg in args(): if optional and arg.required: raise ValueError( - '%s: required argument after optional' % arg.name + '%s: required argument after optional in %s arguments %s' % (arg.name, + self.name, map(lambda x: x.param_spec, args())) ) if multivalue: raise ValueError( diff --git a/ipatests/test_ipalib/test_frontend.py b/ipatests/test_ipalib/test_frontend.py index 310d7a5..ce943a7 100644 --- a/ipatests/test_ipalib/test_frontend.py +++ b/ipatests/test_ipalib/test_frontend.py @@ -280,7 +280,7 @@ class test_Command(ClassChecker): # Test ValueError, required after optional: e = raises(ValueError, self.get_instance, args=('arg1?', 'arg2')) - assert str(e) == 'arg2: required argument after optional' + assert str(e) == "arg2: required argument after optional in %s arguments ['arg1?', 'arg2']" % (self.get_instance().name) # Test ValueError, scalar after multivalue: e = raises(ValueError, self.get_instance, args=('arg1+', 'arg2')) -- 1.8.3.1 -------------- next part -------------- >From fd9ecb2d7a843cec122fb28c9deb1b5764271bde Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 27 Sep 2013 12:36:59 +0200 Subject: [PATCH 4/7] ipaserver/dcerpc: remove use of trust account authentication Since FreeIPA KDC supports adding MS-PAC to HTTP/ipa.server principal, it is possible to use it when talking to the trusted AD DC. Remove support for authenticating as trust account because it should not really be used other than within Samba. --- ipalib/plugins/trust.py | 1 - ipaserver/dcerpc.py | 76 ++++--------------------------------------------- 2 files changed, 6 insertions(+), 71 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index de98451..9c3ff62 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -538,7 +538,6 @@ sides. None, SCOPE_SUBTREE, basedn=info_dn, - use_http=True, quiet=True) if info_list: diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 1c4f4a6..2b0da45 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -165,8 +165,7 @@ class DomainValidator(object): base_dn=cn_trust, attrs_list=[self.ATTR_TRUSTED_SID, self.ATTR_FLATNAME, - self.ATTR_TRUST_PARTNER, - self.ATTR_TRUST_AUTHOUT] + self.ATTR_TRUST_PARTNER] ) # We need to use case-insensitive dictionary since we use @@ -185,18 +184,8 @@ class DomainValidator(object): "attribute: %s", dn, e) continue - trust_authout = entry.get(self.ATTR_TRUST_AUTHOUT, [None])[0] - - # We were able to read all Trusted domain attributes but the - # secret User is not member of trust admins group - if trust_authout is None: - raise errors.ACIError( - info=_('communication with trusted domains is allowed ' - 'for Trusts administrator group members only')) - result[trust_partner] = (flatname_normalized, - security.dom_sid(trusted_sid), - trust_authout) + security.dom_sid(trusted_sid)) return result except errors.NotFound, e: return [] @@ -462,43 +451,6 @@ class DomainValidator(object): ] return u'S-%d-%d-%s' % ( sid_rev_num, ia, '-'.join([str(s) for s in subs]),) - def __extract_trusted_auth(self, info): - """ - Returns in clear trusted domain account credentials - """ - clear = None - auth = drsblobs.trustAuthInOutBlob() - auth.__ndr_unpack__(info['auth']) - auth_array = auth.current.array[0] - if auth_array.AuthType == lsa.TRUST_AUTH_TYPE_CLEAR: - clear = ''.join(map(chr, auth_array.AuthInfo.password)).decode('utf-16-le') - return clear - - def __kinit_as_trusted_account(self, info, password): - """ - Initializes ccache with trusted domain account credentials. - - Applies session code defaults for ccache directory and naming prefix. - Session code uses krbccache_prefix+, we use - krbccache_prefix++ so there is no clash - - Returns tuple (ccache name, principal) where (None, None) signifes an error - on ccache initialization - """ - ccache_name = os.path.join(krbccache_dir, "%sTD%s" % (krbccache_prefix, info['name'][0])) - principal = '%s$@%s' % (self.flatname, info['dns_domain'].upper()) - (stdout, stderr, returncode) = ipautil.run(['/usr/bin/kinit', principal], - env={'KRB5CCNAME':ccache_name}, - stdin=password, raiseonerr=False) - if returncode == 0: - return (ccache_name, principal) - else: - if returncode == 1: - raise errors.ACIError( - info=_("KDC for %(domain)s denied trust account for IPA domain with a message '%(message)s'") % - dict(domain=info['dns_domain'],message=stderr.strip())) - return (None, None) - def kinit_as_http(self, domain): """ Initializes ccache with http service credentials. @@ -544,13 +496,10 @@ class DomainValidator(object): return (None, None) def search_in_dc(self, domain, filter, attrs, scope, basedn=None, - use_http=False, quiet=False): + quiet=False): """ Perform LDAP search in a trusted domain `domain' Domain Controller. Returns resulting entries or None. - - If use_http is set to True, the search is conducted using - HTTP service credentials. """ entries = None @@ -565,7 +514,6 @@ class DomainValidator(object): for (host, port) in info['gc']: entries = self.__search_in_dc(info, host, port, filter, attrs, scope, basedn=basedn, - use_http=use_http, quiet=quiet) if entries: break @@ -573,22 +521,13 @@ class DomainValidator(object): return entries def __search_in_dc(self, info, host, port, filter, attrs, scope, - basedn=None, use_http=False, quiet=False): + basedn=None, quiet=False): """ Actual search in AD LDAP server, using SASL GSSAPI authentication Returns LDAP result or None. """ - if use_http: - (ccache_name, principal) = self.kinit_as_http(info['dns_domain']) - else: - auth = self.__extract_trusted_auth(info) - - if not auth: - return None - - (ccache_name, principal) = self.__kinit_as_trusted_account(info, - auth) + (ccache_name, principal) = self.kinit_as_http(info['dns_domain']) if ccache_name: with installutils.private_ccache(path=ccache_name): @@ -626,7 +565,6 @@ class DomainValidator(object): Returns dictionary with following keys name -- NetBIOS name of the trusted domain dns_domain -- DNS name of the trusted domain - auth -- encrypted credentials for trusted domain account gc -- array of tuples (server, port) for Global Catalog """ if domain in self._info: @@ -653,7 +591,6 @@ class DomainValidator(object): self._domains = self.get_trusted_domains() info = dict() - info['auth'] = self._domains[domain][2] servers = [] if result: @@ -1125,7 +1062,7 @@ class TrustDomainJoins(object): Generate list of records for forest trust information about our realm domains. Note that the list generated currently includes only top level domains, no exclusion domains, and no TDO objects - as we handle the latter in a separte way + as we handle the latter in a separate way """ if self.local_domain.read_only: return @@ -1133,7 +1070,6 @@ class TrustDomainJoins(object): self.local_domain.ftinfo_records = [] realm_domains = self.api.Command.realmdomains_show()['result'] - trustconfig = self.api.Command.trustconfig_show()['result'] # Use realmdomains' modification timestamp to judge records last update time (dn, entry_attrs) = self.api.Backend.ldap2.get_entry(realm_domains['dn'], ['modifyTimestamp']) # Convert the timestamp to Windows 64-bit timestamp format -- 1.8.3.1 -------------- next part -------------- >From e9e5d68ab07886598a666d0c40b33709a4d2d7da Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 27 Sep 2013 12:39:57 +0200 Subject: [PATCH 5/7] trust: integrate subdomains support into trust-add --- ipalib/plugins/trust.py | 23 ++++++++++++-- ipaserver/dcerpc.py | 80 +++++++++++++++++++++++++++++-------------------- 2 files changed, 67 insertions(+), 36 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 9c3ff62..15d8fd3 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -345,7 +345,20 @@ sides. base_dn = DN(api.env.container_trusts, api.env.basedn), filter = trust_filter) + result['result'] = entry_to_dict(trusts[0][1], **options) + if options.get('trust_type') == u'ad': + domains = fetch_domains_from_trust(self, self.trustinstance, result['result'], **options) + if domains and len(domains) > 0: + for dom in domains: + range_name = dom['cn'][0].upper() + '_id_range' + range_type=options.get('range_type', u'ipa-ad-trust') + dom_sid = dom['ipanttrusteddomainsid'][0] + try: + self.add_range(range_name, dom_sid, range_type=range_type) + except errors.DuplicateEntry: + pass + result['result']['trusttype'] = [trust_type_string(result['result']['ipanttrusttype'][0])] result['result']['trustdirection'] = [trust_direction_string(result['result']['ipanttrustdirection'][0])] result['result']['truststatus'] = [trust_status_string(result['verified'])] @@ -433,7 +446,7 @@ sides. except errors.NotFound: old_range = None - if options.get('type') == u'ad': + if options.get('trust_type') == u'ad': if range_type and range_type not in (u'ipa-ad-trust', u'ipa-ad-trust-posix'): raise errors.ValidationError( @@ -1170,9 +1183,13 @@ class trustdomain_del(LDAPDelete): api.register(trustdomain_del) -def fetch_domains_from_trust(self, trustinstance, trust_entry): +def fetch_domains_from_trust(self, trustinstance, trust_entry, **options): trust_name = trust_entry['cn'][0] - domains = ipaserver.dcerpc.fetch_domains(self.api, trustinstance.local_flatname, trust_name) + creds = None + password = options.get('realm_password', None) + if password: + creds = u"%s%%%s" % (options.get('realm_admin'), password) + domains = ipaserver.dcerpc.fetch_domains(self.api, trustinstance.local_flatname, trust_name, creds=creds) result = [] if not domains: return None diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 2b0da45..86bb428 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -939,7 +939,8 @@ class TrustDomainInstance(object): return True return False -def fetch_domains(api, mydomain, trustdomain): + +def fetch_domains(api, mydomain, trustdomain, creds=None): trust_flags = dict( NETR_TRUST_FLAG_IN_FOREST = 0x00000001, NETR_TRUST_FLAG_OUTBOUND = 0x00000002, @@ -959,38 +960,51 @@ def fetch_domains(api, mydomain, trustdomain): NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x00000020, NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x00000040) - domval = DomainValidator(api) - (ccache_name, principal) = domval.kinit_as_http(trustdomain) - if ccache_name: - with installutils.private_ccache(path=ccache_name): - td = TrustDomainInstance('') - td.parm.set('workgroup', mydomain) - td.creds = credentials.Credentials() - td.creds.set_kerberos_state(credentials.MUST_USE_KERBEROS) - td.creds.guess(td.parm) - netrc = net.Net(creds=td.creds, lp=td.parm) - try: - result = netrc.finddc(domain=trustdomain, flags=nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_DS) - except RuntimeError, e: - raise assess_dcerpc_exception(message=str(e)) - if not result: - return None - td.retrieve(unicode(result.pdc_dns_name)) - - netr_pipe = netlogon.netlogon(td.binding, td.parm, td.creds) - domains = netr_pipe.netr_DsrEnumerateDomainTrusts(td.binding, 1) - - result = [] - for t in domains.array: - if ((t.trust_attributes & trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and - (t.trust_flags & trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): - res = dict() - res['cn'] = unicode(t.dns_name) - res['ipantflatname'] = unicode(t.netbios_name) - res['ipanttrusteddomainsid'] = unicode(t.sid) - res['ipanttrustpartner'] = res['cn'] - result.append(res) - return result + def communicate(td): + td.creds.guess(td.parm) + netrc = net.Net(creds=td.creds, lp=td.parm) + try: + result = netrc.finddc(domain=trustdomain, flags=nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_DS) + except RuntimeError, e: + raise assess_dcerpc_exception(message=str(e)) + if not result: + return None + td.retrieve(unicode(result.pdc_dns_name)) + + netr_pipe = netlogon.netlogon(td.binding, td.parm, td.creds) + domains = netr_pipe.netr_DsrEnumerateDomainTrusts(td.binding, 1) + return domains + + domains = None + td = TrustDomainInstance('') + td.parm.set('workgroup', mydomain) + td.creds = credentials.Credentials() + if creds is None: + domval = DomainValidator(api) + (ccache_name, principal) = domval.kinit_as_http(trustdomain) + td.creds.set_kerberos_state(credentials.MUST_USE_KERBEROS) + if ccache_name: + with installutils.private_ccache(path=ccache_name): + domains = communicate(td) + else: + td.creds.set_kerberos_state(credentials.DONT_USE_KERBEROS) + td.creds.parse_string(creds) + domains = communicate(td) + + if domains is None: + return None + + result = [] + for t in domains.array: + if ((t.trust_attributes & trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and + (t.trust_flags & trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): + res = dict() + res['cn'] = unicode(t.dns_name) + res['ipantflatname'] = unicode(t.netbios_name) + res['ipanttrusteddomainsid'] = unicode(t.sid) + res['ipanttrustpartner'] = res['cn'] + result.append(res) + return result class TrustDomainJoins(object): -- 1.8.3.1 -------------- next part -------------- >From 38f3dbe18e1a141b964737124d89204ddb86d51b Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 27 Sep 2013 14:00:22 +0200 Subject: [PATCH 6/7] ipasam: for subdomains pick up defaults for missing values We don't store trust type, attributes, and direction for subdomains of the existing trust. Since trust is always forest level, these parameters can be added as defaults when they are missing. --- daemons/ipa-sam/ipa_sam.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index a535c0f..59ddcef 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -2026,6 +2026,10 @@ static bool fill_pdb_trusted_domain(TALLOC_CTX *mem_ctx, if (!res) { return false; } + if (td->trust_direction == 0) { + /* attribute wasn't present, set default value */ + td->trust_direction = LSA_TRUST_DIRECTION_INBOUND | LSA_TRUST_DIRECTION_OUTBOUND; + } res = get_uint32_t_from_ldap_msg(ldap_state, entry, LDAP_ATTRIBUTE_TRUST_ATTRIBUTES, @@ -2033,6 +2037,10 @@ static bool fill_pdb_trusted_domain(TALLOC_CTX *mem_ctx, if (!res) { return false; } + if (td->trust_attributes == 0) { + /* attribute wasn't present, set default value */ + td->trust_attributes = LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE; + } res = get_uint32_t_from_ldap_msg(ldap_state, entry, LDAP_ATTRIBUTE_TRUST_TYPE, @@ -2040,6 +2048,10 @@ static bool fill_pdb_trusted_domain(TALLOC_CTX *mem_ctx, if (!res) { return false; } + if (td->trust_type == 0) { + /* attribute wasn't present, set default value */ + td->trust_type = LSA_TRUST_TYPE_UPLEVEL; + } td->trust_posix_offset = talloc_zero(td, uint32_t); if (td->trust_posix_offset == NULL) { -- 1.8.3.1 From abokovoy at redhat.com Tue Oct 1 15:16:49 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 1 Oct 2013 18:16:49 +0300 Subject: [Freeipa-devel] PostgreSQL + freeipa In-Reply-To: References: <20130930155852.GL4216@redhat.com> Message-ID: <20131001151649.GQ4216@redhat.com> On Tue, 01 Oct 2013, Gorbachev Ivan wrote: >Thank you! >And one more question, what does error mean - "GSSAPI continuation error: >No credentials found with supported encryption types". This error appears >when I try to log in from another computer within the domain IPA. You need to look into what encryption types are in use there. I suspect it might be DES which is disable. What is the client OS? What does /var/log/krb5kdc.log on IPA master says for this communication? -- / Alexander Bokovoy From ssorce at redhat.com Tue Oct 1 19:50:49 2013 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 1 Oct 2013 15:50:49 -0400 (EDT) Subject: [Freeipa-devel] [PATCHES] 0289-0302 Managed Read permissions In-Reply-To: <524A8F1F.1020407@redhat.com> References: <524A8E59.8010605@redhat.com> <524A8F1F.1020407@redhat.com> Message-ID: <1468563935.655967.1380657049317.JavaMail.root@redhat.com> ----- Original Message ----- > On 10/01/2013 10:56 AM, Petr Viktorin wrote: > > Hello, > > > > These patches implement the framework for > > https://fedorahosted.org/freeipa/ticket/3566 > > > > Design is at http://www.freeipa.org/page/V3/Managed_Read_permissions. > > As you can see from the TODOs it's not yet complete; I'll need a few > > more discussions about some details and future work. > > Simo, I believe you're in charge of OIDs? Can you register the schema? Done. > attributeTypes: > 2.16.840.1.113730.3.8.11.42 ipaPermissionDefaultAttribute > 2.16.840.1.113730.3.8.11.43 ipaPermissionAllowedAttribute > 2.16.840.1.113730.3.8.11.44 ipaPermissionExcludedAttribute Would it make sense to shorten these to something like ipaPermXXXAttr ? Long names are harder to read. > objectClasses: > 2.16.840.1.113730.3.8.12.20 ipaManagedPermission > > The schema is added in patch 0293. Ok, Simo. -- Simo Sorce * Red Hat, Inc. * New York From ssorce at redhat.com Tue Oct 1 19:57:13 2013 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 1 Oct 2013 15:57:13 -0400 (EDT) Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <524AA4A0.6040801@redhat.com> References: <52161568.7060702@redhat.com> <52245136.1090804@redhat.com> <52260B6B.7050906@redhat.com> <522840B4.30709@redhat.com> <5232D20C.9050204@redhat.com> <5232D290.40504@redhat.com> <5232D563.3050500@redhat.com> <524AA4A0.6040801@redhat.com> Message-ID: <851875259.658384.1380657433774.JavaMail.root@redhat.com> ----- Original Message ----- > On 13.9.2013 11:05, Jan Cholasta wrote: > > On 13.9.2013 10:53, Martin Kosek wrote: > >> On 09/13/2013 10:51 AM, Jan Cholasta wrote: > >>> On 5.9.2013 10:28, Jan Cholasta wrote: > >>>> On 3.9.2013 18:16, Dmitri Pal wrote: > >>>>> On 09/02/2013 04:49 AM, Petr Spacek wrote: > >>>>>> It reminds me problems with key-rotation for DNSSEC. > >>>>>> > >>>>>> Could we find common problems and use the same/similar solution for > >>>>>> both problems? > >>>>>> > >>>>>> An extension for certmonger? Oddjob? Or a completely new daemon? > >>>>>> > >>>>> Certmonger already has a way to: > >>>>> 1) Check things periodically > >>>>> 2) Hand certs in different places > >>>>> 3) Run post op scripts > >>>>> > >>>>> IMO it is a good candidate but I would leave it to Nalin to chime in. > >>>>> > >>>> > >>>> I would expect more things that require periodic checking on clients > >>>> beyond certificates to come in the future, so I'm not sure if doing > >>>> this > >>>> in certmonger is the right thing to do. Also, SSSD already does a > >>>> similar thing for realm domains, right? > >> > >> Are you suggesting extending SSSD to handle that? > > > > Yes. > > > >> > >>>> > >>>> Honza > >>>> > >>> > >>> So, does anyone have any strong opinions on this? > >> > >> Not at this point. BTW, is there any reason why we cannot go the > >> simple way and > >> just utilize cron and a script? Previously we just dropped conf to > >> /etc/cron.d > >> for ipa-compliance script and it worked quite well. > > > > Hmm, that's so simple it might just work. At least until there is a > > better way. > > I have been thinking about this for some time now and came up with this > solution: > > Write a library implementing the PKCS#11 API (Cryptoki), which would > provide the shared CA certificates and associated information > (nicknames, trust flags). The library would get the certificates from > SSSD, which in turn would get them from IPA (and do the usual stuff like > caching). > > This library could then be used by IPA NSS databases as a source of > trust information for IPA services (see modutil). It could also be used > by p11-glue to provide the trust information to the rest of the system. > > Pros: > * Automatic support for getting trust information stored in IPA in > all the applications that understand PKCS#11. > * Certificates are fetched from IPA on-demand, not periodically like > in the previous solutions. > > Cons: > * Complexity of implementation? (I don't know about this one, I > briefly looked at the source code of the p11-kit PKCS#11 module and it > looked manageable to me.) > > Does this sound reasonable? Sounds reasonable to me, however I assume you will do some caching, both to avoid lenghty waits and to handle offline cases, so I'd like to know more how/when you are going to use the caches vs fetching the cert chains from the server. Simo. -- Simo Sorce * Red Hat, Inc. * New York From rcritten at redhat.com Tue Oct 1 20:08:29 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Oct 2013 16:08:29 -0400 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <851875259.658384.1380657433774.JavaMail.root@redhat.com> References: <52161568.7060702@redhat.com> <52245136.1090804@redhat.com> <52260B6B.7050906@redhat.com> <522840B4.30709@redhat.com> <5232D20C.9050204@redhat.com> <5232D290.40504@redhat.com> <5232D563.3050500@redhat.com> <524AA4A0.6040801@redhat.com> <851875259.658384.1380657433774.JavaMail.root@redhat.com> Message-ID: <524B2BBD.20104@redhat.com> Simo Sorce wrote: > ----- Original Message ----- >> On 13.9.2013 11:05, Jan Cholasta wrote: >>> On 13.9.2013 10:53, Martin Kosek wrote: >>>> On 09/13/2013 10:51 AM, Jan Cholasta wrote: >>>>> On 5.9.2013 10:28, Jan Cholasta wrote: >>>>>> On 3.9.2013 18:16, Dmitri Pal wrote: >>>>>>> On 09/02/2013 04:49 AM, Petr Spacek wrote: >>>>>>>> It reminds me problems with key-rotation for DNSSEC. >>>>>>>> >>>>>>>> Could we find common problems and use the same/similar solution for >>>>>>>> both problems? >>>>>>>> >>>>>>>> An extension for certmonger? Oddjob? Or a completely new daemon? >>>>>>>> >>>>>>> Certmonger already has a way to: >>>>>>> 1) Check things periodically >>>>>>> 2) Hand certs in different places >>>>>>> 3) Run post op scripts >>>>>>> >>>>>>> IMO it is a good candidate but I would leave it to Nalin to chime in. >>>>>>> >>>>>> >>>>>> I would expect more things that require periodic checking on clients >>>>>> beyond certificates to come in the future, so I'm not sure if doing >>>>>> this >>>>>> in certmonger is the right thing to do. Also, SSSD already does a >>>>>> similar thing for realm domains, right? >>>> >>>> Are you suggesting extending SSSD to handle that? >>> >>> Yes. >>> >>>> >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> So, does anyone have any strong opinions on this? >>>> >>>> Not at this point. BTW, is there any reason why we cannot go the >>>> simple way and >>>> just utilize cron and a script? Previously we just dropped conf to >>>> /etc/cron.d >>>> for ipa-compliance script and it worked quite well. >>> >>> Hmm, that's so simple it might just work. At least until there is a >>> better way. >> >> I have been thinking about this for some time now and came up with this >> solution: >> >> Write a library implementing the PKCS#11 API (Cryptoki), which would >> provide the shared CA certificates and associated information >> (nicknames, trust flags). The library would get the certificates from >> SSSD, which in turn would get them from IPA (and do the usual stuff like >> caching). >> >> This library could then be used by IPA NSS databases as a source of >> trust information for IPA services (see modutil). It could also be used >> by p11-glue to provide the trust information to the rest of the system. >> >> Pros: >> * Automatic support for getting trust information stored in IPA in >> all the applications that understand PKCS#11. >> * Certificates are fetched from IPA on-demand, not periodically like >> in the previous solutions. >> >> Cons: >> * Complexity of implementation? (I don't know about this one, I >> briefly looked at the source code of the p11-kit PKCS#11 module and it >> looked manageable to me.) >> >> Does this sound reasonable? > > > Sounds reasonable to me, however I assume you will do some caching, both to avoid lenghty waits and to handle offline cases, so I'd like to know more how/when you are going to use the caches vs fetching the cert chains from the server. For on-demand, what are we talking about, fetching the cert when the module is loaded? Or whenever someone wants to use (e.g. validate) the cert? How often will this cert change, after all? What would the load be like? Is it fatal if the cert can't be obtained? rob From swalter at redhat.com Tue Oct 1 20:02:37 2013 From: swalter at redhat.com (Stef Walter) Date: Tue, 01 Oct 2013 22:02:37 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <851875259.658384.1380657433774.JavaMail.root@redhat.com> References: <52161568.7060702@redhat.com> <52245136.1090804@redhat.com> <52260B6B.7050906@redhat.com> <522840B4.30709@redhat.com> <5232D20C.9050204@redhat.com> <5232D290.40504@redhat.com> <5232D563.3050500@redhat.com> <524AA4A0.6040801@redhat.com> <851875259.658384.1380657433774.JavaMail.root@redhat.com> Message-ID: <524B2A5D.1020300@redhat.com> On 01.10.2013 21:57, Simo Sorce wrote: > ----- Original Message ----- >> On 13.9.2013 11:05, Jan Cholasta wrote: >>> On 13.9.2013 10:53, Martin Kosek wrote: >>>> On 09/13/2013 10:51 AM, Jan Cholasta wrote: >>>>> On 5.9.2013 10:28, Jan Cholasta wrote: >>>>>> On 3.9.2013 18:16, Dmitri Pal wrote: >>>>>>> On 09/02/2013 04:49 AM, Petr Spacek wrote: >>>>>>>> It reminds me problems with key-rotation for DNSSEC. >>>>>>>> >>>>>>>> Could we find common problems and use the same/similar >>>>>>>> solution for both problems? >>>>>>>> >>>>>>>> An extension for certmonger? Oddjob? Or a completely >>>>>>>> new daemon? >>>>>>>> >>>>>>> Certmonger already has a way to: 1) Check things >>>>>>> periodically 2) Hand certs in different places 3) Run >>>>>>> post op scripts >>>>>>> >>>>>>> IMO it is a good candidate but I would leave it to Nalin >>>>>>> to chime in. >>>>>>> >>>>>> >>>>>> I would expect more things that require periodic checking >>>>>> on clients beyond certificates to come in the future, so >>>>>> I'm not sure if doing this in certmonger is the right thing >>>>>> to do. Also, SSSD already does a similar thing for realm >>>>>> domains, right? >>>> >>>> Are you suggesting extending SSSD to handle that? >>> >>> Yes. >>> >>>> >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> So, does anyone have any strong opinions on this? >>>> >>>> Not at this point. BTW, is there any reason why we cannot go >>>> the simple way and just utilize cron and a script? Previously >>>> we just dropped conf to /etc/cron.d for ipa-compliance script >>>> and it worked quite well. >>> >>> Hmm, that's so simple it might just work. At least until there is >>> a better way. >> >> I have been thinking about this for some time now and came up with >> this solution: >> >> Write a library implementing the PKCS#11 API (Cryptoki), which >> would provide the shared CA certificates and associated >> information (nicknames, trust flags). The library would get the >> certificates from SSSD, which in turn would get them from IPA (and >> do the usual stuff like caching). >> >> This library could then be used by IPA NSS databases as a source >> of trust information for IPA services (see modutil). It could also >> be used by p11-glue to provide the trust information to the rest of >> the system. >> >> Pros: * Automatic support for getting trust information stored in >> IPA in all the applications that understand PKCS#11. * Certificates >> are fetched from IPA on-demand, not periodically like in the >> previous solutions. >> >> Cons: * Complexity of implementation? (I don't know about this one, >> I briefly looked at the source code of the p11-kit PKCS#11 module >> and it looked manageable to me.) >> >> Does this sound reasonable? > > > Sounds reasonable to me, however I assume you will do some caching, > both to avoid lenghty waits and to handle offline cases, so I'd like > to know more how/when you are going to use the caches vs fetching the > cert chains from the server. I sorta imagined it would use the sssd cache, and pull the data via sssd. Is that what you guys thought? Stef From npmccallum at redhat.com Tue Oct 1 21:00:15 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 01 Oct 2013 17:00:15 -0400 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <52285AA5.3010309@redhat.com> References: <1378355153.19352.29.camel@localhost> <1378355905.19352.35.camel@localhost> <52285AA5.3010309@redhat.com> Message-ID: <1380661215.25386.27.camel@localhost> On Thu, 2013-09-05 at 12:19 +0200, Petr Viktorin wrote: > On 09/05/2013 06:38 AM, Nathaniel McCallum wrote: > > 3. I had to make the 'id' option optional to make the uuid > > autogeneration work in otp-add. However, this has the side-effect that > > 'id' is now optional in all the other commands. This is particularly bad > > in the case of otp-del, where calling this command with no ID > > transparently removes all tokens. How can I make this optional for > > otp-add but required for all other commands? > > You'll need to add a new option flag. > > 1. Add a 'optional_create' flag to the comment in ipalib.parameters.Param. > 2. Handle the flag in ipalib.crud.Create.get_options (clone with > attribute=attribute, required=False) > > See the handling of 'ask_create' for exapmles. I spent part of yesterday and all day today working on this and I can't make the attached patch work... No matter what I do, the Param with the 'optional_create' flag is never actually optional. There is no failure, it just doesn't work. Any thoughts? As a hint, the code in cli.py and frontend.py seems to call cmd.args() rather than cmd.get_args(). Though, when I changed this it seemed to break stuff. There seems to be lots of Python magic going on here via the NameSpace class and I can't quite follow the logic. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-optional_create-flag.patch Type: text/x-patch Size: 2274 bytes Desc: not available URL: From pviktori at redhat.com Wed Oct 2 08:19:29 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Oct 2013 10:19:29 +0200 Subject: [Freeipa-devel] [PATCHES] 0289-0302 Managed Read permissions In-Reply-To: <1468563935.655967.1380657049317.JavaMail.root@redhat.com> References: <524A8E59.8010605@redhat.com> <524A8F1F.1020407@redhat.com> <1468563935.655967.1380657049317.JavaMail.root@redhat.com> Message-ID: <524BD711.4050900@redhat.com> On 10/01/2013 09:50 PM, Simo Sorce wrote: > > > ----- Original Message ----- >> On 10/01/2013 10:56 AM, Petr Viktorin wrote: >>> Hello, >>> >>> These patches implement the framework for >>> https://fedorahosted.org/freeipa/ticket/3566 >>> >>> Design is at http://www.freeipa.org/page/V3/Managed_Read_permissions. >>> As you can see from the TODOs it's not yet complete; I'll need a few >>> more discussions about some details and future work. >> >> Simo, I believe you're in charge of OIDs? Can you register the schema? > > Done. Thank you! >> attributeTypes: >> 2.16.840.1.113730.3.8.11.42 ipaPermissionDefaultAttribute >> 2.16.840.1.113730.3.8.11.43 ipaPermissionAllowedAttribute >> 2.16.840.1.113730.3.8.11.44 ipaPermissionExcludedAttribute > > Would it make sense to shorten these to something like ipaPermXXXAttr ? > Long names are harder to read. Sure. I'll make the change in the next iteration of the patches. >> objectClasses: >> 2.16.840.1.113730.3.8.12.20 ipaManagedPermission >> >> The schema is added in patch 0293. > > Ok, > > Simo. > -- Petr? From mkosek at redhat.com Wed Oct 2 08:39:22 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 02 Oct 2013 10:39:22 +0200 Subject: [Freeipa-devel] [PATCHES] 0289-0302 Managed Read permissions In-Reply-To: <524A8E59.8010605@redhat.com> References: <524A8E59.8010605@redhat.com> Message-ID: <524BDBBA.6060506@redhat.com> On 10/01/2013 10:56 AM, Petr Viktorin wrote: > Hello, > > These patches implement the framework for > https://fedorahosted.org/freeipa/ticket/3566 > > Design is at http://www.freeipa.org/page/V3/Managed_Read_permissions. > As you can see from the TODOs it's not yet complete; I'll need a few more > discussions about some details and future work. > > The patches only add read permissions for User objects, and the global > anonymous read ACI is not removed. I'll add the other objects after the overall > structure is ACKed. > To test, remove the ACI (cheatsheet: http://fpaste.org/43296/13806142/) and > verify that anonymous read is disabled and normal users can't read anything but > user info. > > > These depend on some of my earlier patches: > - 0258-0265, 0275 - LDIF-based schema updater > - 0276-0277 - Split large doc strings for translation > - 0288 - user template in tests > > > I needed to test both server and client plugins. Since we only have one API > object (#3090) and can't unload plugins, I needed to fix some issues when they > are loaded at the same time. > > Terminology note: currently IPA calls the "read"/"search"/"write"/"delete" part > of an ACI a "permission", which is confusing since our ACI wrapper objects are > also "permissions". > Wherever I can, I use the term "rights" for these. > "Rights" is also used in ACI docs: > https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#id3349243 > > > > /Enter patches. > > Act I. > > 0289: Might as well update to new API since I'll be making extensive changes here > > 0290: My linting tools were complaining heavily about the tabs, so I fixed the > indentation here. > > 0291: Fix a crash when ldap2 and a client RPC backend are connected at the same > time. (This happens in tests that I'll add later) > > > Act II. > > 0292: See the "Permission flags" section of the design. > > 0293: Add schema. (The OIDs aren't registered yet.) > > 0294: This makes the test in the next patch possible. > > 0295: See the "MANAGED Permissions" section of the design. > > 0296: See the "Read rights" section of the design. > > > Act III. > > 0297: See "Marking Attributes in Plugins" and "Adding permissions for default > read permissions" in the design. > > 0298: Make the help plugin not fail when server plugins are loaded. This will > happen in later tests. > > 0299: Tests for 0297 > > 0300! Fix a TODO from 0295 > > 0301: See "Adding privileges and role for default read permissions" in the design > > 0302: Tests for 0301 > Thanks for all the patches and carrying on with this major effort! I swiftly went through the patches and have few comments: 1) Patch 293 requires your schema updater patches, right? That means patches 258-265, 275 There may be more dependencies though: ... Applying: Add Reader role and user read privilege Applying: Add tests for the new Reader role error: patch failed: ipatests/test_xmlrpc/test_user_plugin.py:106 error: ipatests/test_xmlrpc/test_user_plugin.py: patch does not apply Patch failed at 0014 Add tests for the new Reader role 2) 297: in update_managed_permissions, handling of ipapermissionallowedattribute and ipapermissionexcludedattribute should be handled by + try: + api.Command.permission_mod(name) + except errors.EmptyModlist: + self.log.debug('Attributes unchanged') right? 3) 301: I did not like the Reader role & User Readers privilege very much. I see several issues related to that: a) performance reasons - read operation on LDAP must be as fast as possible. DS checking membership in ipausers where may be 100000 of users does not look right b) ipausers group may be changed to other group by setting ipaDefaultPrimaryGroup. I also think we are guaranteed that it really contains all users. There have been also thoughts about removing it. To sum it up, I would rather not build our permission system on this group. I think we need top base our ACIs on LDAP bind targets ldap:///all and ldap:///anyone to avoid performance issues and issues with ipausers not being complete: https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Access_Control-Bind_Rules.html I rather think we want to base the permissions on binddn. In the beginning, there would be 3 types of permissions based on binddn: * groupdn based: standard permissions that can be assigned privileges * ldap:///all permissions for all authenticated users. Cannot be assigned to privileges (would not make sense) * ldap:///anyone permissions for all, including anonymous users. Cannot be assigned to privileges (would not make sense) Just few examples: Read users - ldap:///anyone Read groups - ldap:///anyone Read sudo - ldap:///all Read hbac - ldap:///all ... Basing the permissions on these would allow us to get rid of all the awful deny permissions. To make the permission Bind part more user friendly, there should be an option in permission-find and a switch in Web UI to e.g. list permissions by bind type, i.e.: - anonymous permissions - authenticated users permissions - group based permissions If use would want to e.g restrict sudo only to specified group, I would see this workflow: 1) Change bind type from "authenticated users" to "group based" 2) Bind permission to chosen privilege 3) ... And the opposite, if he wants to make reading more open: 1) Unbind permission from privilege 2) Change bind type to "authenticated users" or "anonymous" Makes sense? Martin From pspacek at redhat.com Wed Oct 2 08:43:38 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 02 Oct 2013 10:43:38 +0200 Subject: [Freeipa-devel] [PATCH 0192] Prevent deadlock in PTR record synchronization (versions <= 2.x) In-Reply-To: <524ABFD4.2040204@redhat.com> References: <52443268.4060301@redhat.com> <524ABFD4.2040204@redhat.com> Message-ID: <524BDCBA.1060101@redhat.com> On 1.10.2013 14:28, Tomas Hozza wrote: > On 09/26/2013 03:11 PM, Petr Spacek wrote: >> Hello, >> >> attached patch prevents/hides deadlock in plugin versions versions <= 2.x. >> >> I plan to push it to v2 branch. Branches v3 and newer shouldn't be >> affected. >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/113 > > ACK. > > I tested the patch with: > freeipa-server-3.1.5-1.fc18.x86_64 > freeipa-client-3.1.5-1.fc18.x86_64 > > With the patch, records are added successfully for the client and no > warnings/errors are printed in the server log. However the > ipa-client-install command still prints "Failed to update DNS records." > even though > everything passed fine on the server. Maybe there is some issue with the > ipa-client. My tests with RHEL 6.5 are passing, so I assume that it is some glitch in F18. Pushed to v2 branch: 3ab4665b942ff2157314259260f3b58264874acb -- Petr^2 Spacek From pspacek at redhat.com Wed Oct 2 08:51:31 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 02 Oct 2013 10:51:31 +0200 Subject: [Freeipa-devel] [PATCH 0180] Remove support for zone_refresh mode and options cache_ttl and psearch In-Reply-To: <520CB9D0.5050607@redhat.com> References: <51ED1616.20501@redhat.com> <520CB9D0.5050607@redhat.com> Message-ID: <524BDE93.7050306@redhat.com> On 15.8.2013 13:21, Tomas Hozza wrote: > On 07/22/2013 01:23 PM, Petr Spacek wrote: >> Hello, >> >> Remove support for zone_refresh mode and options cache_ttl and psearch. >> >> All three options are ignored and persistent search is always enabled. > > ACK. > > Looks good and plugin works well with the change. > > Anyway I think it would be good to change the README > to reflect this change in configuration. Good point! I deleted relevant parts of README and pushed the new version of the patch to master branch: 18ff737c49f6e58f0adfcfe728ac1308630ba018 Thank you for your time. -- Petr^2 Spacek From pviktori at redhat.com Wed Oct 2 10:00:41 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Oct 2013 12:00:41 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <1380661215.25386.27.camel@localhost> References: <1378355153.19352.29.camel@localhost> <1378355905.19352.35.camel@localhost> <52285AA5.3010309@redhat.com> <1380661215.25386.27.camel@localhost> Message-ID: <524BEEC9.9090008@redhat.com> On 10/01/2013 11:00 PM, Nathaniel McCallum wrote: > On Thu, 2013-09-05 at 12:19 +0200, Petr Viktorin wrote: >> On 09/05/2013 06:38 AM, Nathaniel McCallum wrote: >>> 3. I had to make the 'id' option optional to make the uuid >>> autogeneration work in otp-add. However, this has the side-effect that >>> 'id' is now optional in all the other commands. This is particularly bad >>> in the case of otp-del, where calling this command with no ID >>> transparently removes all tokens. How can I make this optional for >>> otp-add but required for all other commands? >> >> You'll need to add a new option flag. >> >> 1. Add a 'optional_create' flag to the comment in ipalib.parameters.Param. >> 2. Handle the flag in ipalib.crud.Create.get_options (clone with >> attribute=attribute, required=False) >> >> See the handling of 'ask_create' for exapmles. > > I spent part of yesterday and all day today working on this and I can't > make the attached patch work... No matter what I do, the Param with the > 'optional_create' flag is never actually optional. There is no failure, > it just doesn't work. Any thoughts? get_args is overridden in plugins/baseldap.py, and that contains a bug. Thanks for bringing this up! Here's a patch, apply it on top of your "Add optional_create flag". > As a hint, the code in cli.py and frontend.py seems to call cmd.args() > rather than cmd.get_args(). Though, when I changed this it seemed to > break stuff. There seems to be lots of Python magic going on here via > the NameSpace class and I can't quite follow the logic. Yeah, the framework is a bit of a maze. Sorry for that. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0303-Fix-bug-in-LDAPCreate-and-crud.Create-get_args-metho.patch Type: text/x-patch Size: 1688 bytes Desc: not available URL: From jcholast at redhat.com Wed Oct 2 10:03:54 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 02 Oct 2013 12:03:54 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <524B2BBD.20104@redhat.com> References: <52161568.7060702@redhat.com> <52245136.1090804@redhat.com> <52260B6B.7050906@redhat.com> <522840B4.30709@redhat.com> <5232D20C.9050204@redhat.com> <5232D290.40504@redhat.com> <5232D563.3050500@redhat.com> <524AA4A0.6040801@redhat.com> <851875259.658384.1380657433774.JavaMail.root@redhat.com> <524B2BBD.20104@redhat.com> Message-ID: <524BEF8A.5000309@redhat.com> On 1.10.2013 22:08, Rob Crittenden wrote: > Simo Sorce wrote: >> ----- Original Message ----- >>> On 13.9.2013 11:05, Jan Cholasta wrote: >>>> On 13.9.2013 10:53, Martin Kosek wrote: >>>>> On 09/13/2013 10:51 AM, Jan Cholasta wrote: >>>>>> On 5.9.2013 10:28, Jan Cholasta wrote: >>>>>>> On 3.9.2013 18:16, Dmitri Pal wrote: >>>>>>>> On 09/02/2013 04:49 AM, Petr Spacek wrote: >>>>>>>>> It reminds me problems with key-rotation for DNSSEC. >>>>>>>>> >>>>>>>>> Could we find common problems and use the same/similar solution >>>>>>>>> for >>>>>>>>> both problems? >>>>>>>>> >>>>>>>>> An extension for certmonger? Oddjob? Or a completely new daemon? >>>>>>>>> >>>>>>>> Certmonger already has a way to: >>>>>>>> 1) Check things periodically >>>>>>>> 2) Hand certs in different places >>>>>>>> 3) Run post op scripts >>>>>>>> >>>>>>>> IMO it is a good candidate but I would leave it to Nalin to >>>>>>>> chime in. >>>>>>>> >>>>>>> >>>>>>> I would expect more things that require periodic checking on clients >>>>>>> beyond certificates to come in the future, so I'm not sure if doing >>>>>>> this >>>>>>> in certmonger is the right thing to do. Also, SSSD already does a >>>>>>> similar thing for realm domains, right? >>>>> >>>>> Are you suggesting extending SSSD to handle that? >>>> >>>> Yes. >>>> >>>>> >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> So, does anyone have any strong opinions on this? >>>>> >>>>> Not at this point. BTW, is there any reason why we cannot go the >>>>> simple way and >>>>> just utilize cron and a script? Previously we just dropped conf to >>>>> /etc/cron.d >>>>> for ipa-compliance script and it worked quite well. >>>> >>>> Hmm, that's so simple it might just work. At least until there is a >>>> better way. >>> >>> I have been thinking about this for some time now and came up with this >>> solution: >>> >>> Write a library implementing the PKCS#11 API (Cryptoki), which would >>> provide the shared CA certificates and associated information >>> (nicknames, trust flags). The library would get the certificates from >>> SSSD, which in turn would get them from IPA (and do the usual stuff like >>> caching). >>> >>> This library could then be used by IPA NSS databases as a source of >>> trust information for IPA services (see modutil). It could also be used >>> by p11-glue to provide the trust information to the rest of the system. >>> >>> Pros: >>> * Automatic support for getting trust information stored in IPA in >>> all the applications that understand PKCS#11. >>> * Certificates are fetched from IPA on-demand, not periodically like >>> in the previous solutions. >>> >>> Cons: >>> * Complexity of implementation? (I don't know about this one, I >>> briefly looked at the source code of the p11-kit PKCS#11 module and it >>> looked manageable to me.) >>> >>> Does this sound reasonable? >> >> >> Sounds reasonable to me, however I assume you will do some caching, >> both to avoid lenghty waits and to handle offline cases, so I'd like >> to know more how/when you are going to use the caches vs fetching the >> cert chains from the server. I was thinking about using algorithm like this when SSSD receives the request: if certs in cache: if cache last update time + delta < now: if certs were update on server: # lastUSN check remove certs from cache else: cache last update time = now if certs not in cache: get certs from server store certs in cache cache last update time = now return certs in cache The delta would be a configurable option, defaulting to some reasonable value (1 hour? more? less?) > > For on-demand, what are we talking about, fetching the cert when the > module is loaded? Or whenever someone wants to use (e.g. validate) the > cert? Something in between - the module would request the certificates from SSSD when a PKCS#11 session is opened and keep them in memory until the session is closed. The point is to always have the same data between PKCS#11 object management calls. > > How often will this cert change, after all? Not often. Why? > > What would the load be like? Is it fatal if the cert can't be obtained? The module could either return an error to the user when the certs can't be obtained, or return whatever is in the cache. I'm not sure which is better, but I'm leaning towards returning whatever is in the cache, since this must work even when the client system is offline. > > rob > Honza -- Jan Cholasta From pvoborni at redhat.com Wed Oct 2 10:45:49 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 02 Oct 2013 12:45:49 +0200 Subject: [Freeipa-devel] [PATCH] 448 Load updated Web UI files after server upgrade In-Reply-To: <524530C7.9020204@redhat.com> References: <5220B880.9040902@redhat.com> <524530C7.9020204@redhat.com> Message-ID: <524BF95D.2000006@redhat.com> On 09/27/2013 09:16 AM, Ana Krivokapic wrote: > On 08/30/2013 05:21 PM, Petr Vobornik wrote: snip >> >> https://fedorahosted.org/freeipa/ticket/3798 >> > > I tested the patch and it seems to work fine. Code-wise it looks good as well. > > Nitpick: There is an unused function 'updated()' in the new loader.js.in file. > Unused function removed. Updated patch attached. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0448-1-Load-updated-Web-UI-files-after-server-upgrade.patch Type: text/x-patch Size: 21949 bytes Desc: not available URL: From pspacek at redhat.com Wed Oct 2 10:57:01 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 02 Oct 2013 12:57:01 +0200 Subject: [Freeipa-devel] [PATCH 0186-0191] Replace LDAP cache with RBTDB In-Reply-To: <523313C3.8070306@redhat.com> References: <51FA694C.1000302@redhat.com> <520B9373.1070707@redhat.com> <520B9755.70503@redhat.com> <523313C3.8070306@redhat.com> Message-ID: <524BFBFD.1000901@redhat.com> On 13.9.2013 15:31, Petr Spacek wrote: > On 14.8.2013 16:42, Petr Spacek wrote: >> On 14.8.2013 16:25, Petr Spacek wrote: >>> On 1.8.2013 15:57, Petr Spacek wrote: >>>> Hello, >>>> >>>> attached monster patches replace our internal cache/database with RBTDB >>>> implementation. See commit messages and comments inside. >>>> >>>> This patch set provides very basic functionality (including DNS support for >>>> updates). Error handling definitely needs more love, but it should be enough >>>> for rapid DNSSEC prototyping. >>> >>> Patch 186 v2: The code now applies incremental changes in LDAP to the >>> in-memory database. Commit message was modified to mention that wildcards are >>> now supported. >>> >>> Patch 187 v2: The code was re-worked and now it respects serial_autoincrement >>> option. >>> >>> Patch 188 v2: Minor comment clean-up and rebase on top of patch 187 v2. >>> >>> Patch 189 v2: Call to deleterdataset() nested in substractrdataset() was >>> deleted. This code was meant only for testing purposes. >>> >>> These patch set is now ready for review. Please see commit messages! Some >>> functionality is missing intentionally, but it will be fixed by separate >>> patches. >> >> It would be too easy! >> >> Patch 186 v3: Commit message was extended with information that LDAP MODRDN >> operation is not supported at the moment. >> >> Patch 187 v3: Missing file ldap_driver.h was added. > > This extended patch set handles correctly object deletion from LDAP. > > Patches 186-189 contain very minor changes, only moving code from one place to > the other. > > See commit messages for patches 190 and 191. > > This should be testable. I would recommend to test the whole patch set at > once, most probably it doesn't make much sense to test patches separately. bind-dyndb-ldap-pspacek-0186-5-Use-RBTDB-instead-of-internal-LDAP-cache.patch adds missing missing include (db.h) to zone_register.c. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0186-5-Use-RBTDB-instead-of-internal-LDAP-cache.patch Type: text/x-patch Size: 88114 bytes Desc: not available URL: From ssorce at redhat.com Wed Oct 2 11:07:33 2013 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 2 Oct 2013 07:07:33 -0400 (EDT) Subject: [Freeipa-devel] [PATCHES] 0289-0302 Managed Read permissions In-Reply-To: <524BDBBA.6060506@redhat.com> References: <524A8E59.8010605@redhat.com> <524BDBBA.6060506@redhat.com> Message-ID: <1135777364.287904.1380712053236.JavaMail.root@redhat.com> ----- Original Message ----- > On 10/01/2013 10:56 AM, Petr Viktorin wrote: > > Hello, > > > > These patches implement the framework for > > https://fedorahosted.org/freeipa/ticket/3566 > > > > Design is at http://www.freeipa.org/page/V3/Managed_Read_permissions. > > As you can see from the TODOs it's not yet complete; I'll need a few more > > discussions about some details and future work. > > > > The patches only add read permissions for User objects, and the global > > anonymous read ACI is not removed. I'll add the other objects after the > > overall > > structure is ACKed. > > To test, remove the ACI (cheatsheet: http://fpaste.org/43296/13806142/) and > > verify that anonymous read is disabled and normal users can't read anything > > but > > user info. > > > > > > These depend on some of my earlier patches: > > - 0258-0265, 0275 - LDIF-based schema updater > > - 0276-0277 - Split large doc strings for translation > > - 0288 - user template in tests > > > > > > I needed to test both server and client plugins. Since we only have one API > > object (#3090) and can't unload plugins, I needed to fix some issues when > > they > > are loaded at the same time. > > > > Terminology note: currently IPA calls the "read"/"search"/"write"/"delete" > > part > > of an ACI a "permission", which is confusing since our ACI wrapper objects > > are > > also "permissions". > > Wherever I can, I use the term "rights" for these. > > "Rights" is also used in ACI docs: > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#id3349243 > > > > > > > > /Enter patches. > > > > Act I. > > > > 0289: Might as well update to new API since I'll be making extensive > > changes here > > > > 0290: My linting tools were complaining heavily about the tabs, so I fixed > > the > > indentation here. > > > > 0291: Fix a crash when ldap2 and a client RPC backend are connected at the > > same > > time. (This happens in tests that I'll add later) > > > > > > Act II. > > > > 0292: See the "Permission flags" section of the design. > > > > 0293: Add schema. (The OIDs aren't registered yet.) > > > > 0294: This makes the test in the next patch possible. > > > > 0295: See the "MANAGED Permissions" section of the design. > > > > 0296: See the "Read rights" section of the design. > > > > > > Act III. > > > > 0297: See "Marking Attributes in Plugins" and "Adding permissions for > > default > > read permissions" in the design. > > > > 0298: Make the help plugin not fail when server plugins are loaded. This > > will > > happen in later tests. > > > > 0299: Tests for 0297 > > > > 0300! Fix a TODO from 0295 > > > > 0301: See "Adding privileges and role for default read permissions" in the > > design > > > > 0302: Tests for 0301 > > > > Thanks for all the patches and carrying on with this major effort! I swiftly > went through the patches and have few comments: > > 1) Patch 293 requires your schema updater patches, right? That means patches > 258-265, 275 > > There may be more dependencies though: > > ... > Applying: Add Reader role and user read privilege > Applying: Add tests for the new Reader role > error: patch failed: ipatests/test_xmlrpc/test_user_plugin.py:106 > error: ipatests/test_xmlrpc/test_user_plugin.py: patch does not apply > Patch failed at 0014 Add tests for the new Reader role > > > 2) 297: in update_managed_permissions, handling of > ipapermissionallowedattribute and ipapermissionexcludedattribute should be > handled by > > + try: > + api.Command.permission_mod(name) > + except errors.EmptyModlist: > + self.log.debug('Attributes unchanged') > > right? > > 3) 301: I did not like the Reader role & User Readers privilege very much. I > see several issues related to that: > > a) performance reasons - read operation on LDAP must be as fast as possible. > DS > checking membership in ipausers where may be 100000 of users does not look > right > > b) ipausers group may be changed to other group by setting > ipaDefaultPrimaryGroup. I also think we are guaranteed that it really > contains > all users. There have been also thoughts about removing it. > > To sum it up, I would rather not build our permission system on this group. > > I think we need top base our ACIs on LDAP bind targets ldap:///all and > ldap:///anyone to avoid performance issues and issues with ipausers not being > complete: > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Access_Control-Bind_Rules.html > > I rather think we want to base the permissions on binddn. In the beginning, > there would be 3 types of permissions based on binddn: > > * groupdn based: standard permissions that can be assigned privileges > * ldap:///all permissions for all authenticated users. Cannot be assigned to > privileges (would not make sense) > * ldap:///anyone permissions for all, including anonymous users. Cannot be > assigned to privileges (would not make sense) > > Just few examples: > Read users - ldap:///anyone > Read groups - ldap:///anyone > Read sudo - ldap:///all > Read hbac - ldap:///all > ... > > Basing the permissions on these would allow us to get rid of all the awful > deny > permissions. > > To make the permission Bind part more user friendly, there should be an > option > in permission-find and a switch in Web UI to e.g. list permissions by bind > type, i.e.: > - anonymous permissions > - authenticated users permissions > - group based permissions > > If use would want to e.g restrict sudo only to specified group, I would see > this workflow: > 1) Change bind type from "authenticated users" to "group based" > 2) Bind permission to chosen privilege > 3) ... > > And the opposite, if he wants to make reading more open: > 1) Unbind permission from privilege > 2) Change bind type to "authenticated users" or "anonymous" > > Makes sense? I agree with Martin's comments too. Simo. -- Simo Sorce * Red Hat, Inc. * New York From ssorce at redhat.com Wed Oct 2 11:10:36 2013 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 2 Oct 2013 07:10:36 -0400 (EDT) Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <524BEF8A.5000309@redhat.com> References: <52161568.7060702@redhat.com> <5232D20C.9050204@redhat.com> <5232D290.40504@redhat.com> <5232D563.3050500@redhat.com> <524AA4A0.6040801@redhat.com> <851875259.658384.1380657433774.JavaMail.root@redhat.com> <524B2BBD.20104@redhat.com> <524BEF8A.5000309@redhat.com> Message-ID: <1052675559.288505.1380712236557.JavaMail.root@redhat.com> ----- Original Message ----- > On 1.10.2013 22:08, Rob Crittenden wrote: > > Simo Sorce wrote: > >> ----- Original Message ----- > >>> On 13.9.2013 11:05, Jan Cholasta wrote: > >>>> On 13.9.2013 10:53, Martin Kosek wrote: > >>>>> On 09/13/2013 10:51 AM, Jan Cholasta wrote: > >>>>>> On 5.9.2013 10:28, Jan Cholasta wrote: > >>>>>>> On 3.9.2013 18:16, Dmitri Pal wrote: > >>>>>>>> On 09/02/2013 04:49 AM, Petr Spacek wrote: > >>>>>>>>> It reminds me problems with key-rotation for DNSSEC. > >>>>>>>>> > >>>>>>>>> Could we find common problems and use the same/similar solution > >>>>>>>>> for > >>>>>>>>> both problems? > >>>>>>>>> > >>>>>>>>> An extension for certmonger? Oddjob? Or a completely new daemon? > >>>>>>>>> > >>>>>>>> Certmonger already has a way to: > >>>>>>>> 1) Check things periodically > >>>>>>>> 2) Hand certs in different places > >>>>>>>> 3) Run post op scripts > >>>>>>>> > >>>>>>>> IMO it is a good candidate but I would leave it to Nalin to > >>>>>>>> chime in. > >>>>>>>> > >>>>>>> > >>>>>>> I would expect more things that require periodic checking on clients > >>>>>>> beyond certificates to come in the future, so I'm not sure if doing > >>>>>>> this > >>>>>>> in certmonger is the right thing to do. Also, SSSD already does a > >>>>>>> similar thing for realm domains, right? > >>>>> > >>>>> Are you suggesting extending SSSD to handle that? > >>>> > >>>> Yes. > >>>> > >>>>> > >>>>>>> > >>>>>>> Honza > >>>>>>> > >>>>>> > >>>>>> So, does anyone have any strong opinions on this? > >>>>> > >>>>> Not at this point. BTW, is there any reason why we cannot go the > >>>>> simple way and > >>>>> just utilize cron and a script? Previously we just dropped conf to > >>>>> /etc/cron.d > >>>>> for ipa-compliance script and it worked quite well. > >>>> > >>>> Hmm, that's so simple it might just work. At least until there is a > >>>> better way. > >>> > >>> I have been thinking about this for some time now and came up with this > >>> solution: > >>> > >>> Write a library implementing the PKCS#11 API (Cryptoki), which would > >>> provide the shared CA certificates and associated information > >>> (nicknames, trust flags). The library would get the certificates from > >>> SSSD, which in turn would get them from IPA (and do the usual stuff like > >>> caching). > >>> > >>> This library could then be used by IPA NSS databases as a source of > >>> trust information for IPA services (see modutil). It could also be used > >>> by p11-glue to provide the trust information to the rest of the system. > >>> > >>> Pros: > >>> * Automatic support for getting trust information stored in IPA in > >>> all the applications that understand PKCS#11. > >>> * Certificates are fetched from IPA on-demand, not periodically like > >>> in the previous solutions. > >>> > >>> Cons: > >>> * Complexity of implementation? (I don't know about this one, I > >>> briefly looked at the source code of the p11-kit PKCS#11 module and it > >>> looked manageable to me.) > >>> > >>> Does this sound reasonable? > >> > >> > >> Sounds reasonable to me, however I assume you will do some caching, > >> both to avoid lenghty waits and to handle offline cases, so I'd like > >> to know more how/when you are going to use the caches vs fetching the > >> cert chains from the server. > > I was thinking about using algorithm like this when SSSD receives the > request: > > if certs in cache: > if cache last update time + delta < now: > if certs were update on server: # lastUSN check > remove certs from cache > else: > cache last update time = now > if certs not in cache: > get certs from server > store certs in cache > cache last update time = now > return certs in cache > > The delta would be a configurable option, defaulting to some reasonable > value (1 hour? more? less?) > > > > > For on-demand, what are we talking about, fetching the cert when the > > module is loaded? Or whenever someone wants to use (e.g. validate) the > > cert? > > Something in between - the module would request the certificates from > SSSD when a PKCS#11 session is opened and keep them in memory until the > session is closed. The point is to always have the same data between > PKCS#11 object management calls. > > > > > How often will this cert change, after all? > > Not often. Why? > > > > > What would the load be like? Is it fatal if the cert can't be obtained? > > The module could either return an error to the user when the certs can't > be obtained, or return whatever is in the cache. I'm not sure which is > better, but I'm leaning towards returning whatever is in the cache, > since this must work even when the client system is offline. I think the cache should just be ca.crt files though, in this case, not the ldb modules cache. As some people wipe it out for various reasons. The main issue here is a chicken-egg issue if you are using LDAP(S) to connect to the server and you ned the CA cert to validate the server cert. You do not want to lock yourself out by wiping valid ca certs. Simo. -- Simo Sorce * Red Hat, Inc. * New York From sbose at redhat.com Wed Oct 2 11:23:34 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 2 Oct 2013 13:23:34 +0200 Subject: [Freeipa-devel] [PoC/RfC] ipa-kdb: check for alternatives if cross realm TGT cannot be found Message-ID: <20131002112334.GZ10000@localhost.localdomain> Hi, the attached two patches are a proof-of-concept how we can eliminate the need to have [capaths] defined in krb5.conf for member domains in trusted forests together with Alexander's patch 0123. capaths are used in the core KDC code at two places. One is to validate transited field in the TGT, this is handled by Alexander's patch. The other is to find out where to redirect a client asking for a cross realm TGT for a realm we do not shared credential with but know and trust a realm which can handle this. This is typically the case for member domains(realms) in a trusted forest. We share credentials with the forest root but not with the members but we know that the forest root can handle requests for its member domains. The patches are just proof-of-concept because I'm currently not sure if this is kerberos-wise the right way to handle it. Additionally we might want to enhance the patches to handle to more broader use case of transitive-trusts. Please note that for the time being there is a workaround implemented in SSSD to add a suitable [capaths] section to the krb5.conf include file managed by SSSD. bye, Sumit -------------- next part -------------- From 73893a102c300627f7977afaf482ee83afc2a161 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 2 Oct 2013 11:44:32 +0200 Subject: [PATCH 1/2] ipa-kdb: add transit_realm member to trusted domains To be able to handle requests for member domains in a trusted forest we must know which forest the domain belongs to. Because we only share credentials with the forest root all request for member domains must go through (transit) the KDC of the forest root. This will also be true for other forests which are trusted by the forest we trust. But the patch does not handle this case because it is currently not clear how transitively trusted forests will be stored in the directory tree. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 86 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 86 insertions(+) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 27d50ac..ce9b06a 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -32,6 +32,7 @@ struct ipadb_adtrusts { char *domain_name; char *flat_name; char *domain_sid; + char *transit_realm; struct dom_sid domsid; struct dom_sid *sid_blacklist_incoming; int len_sid_blacklist_incoming; @@ -2119,6 +2120,7 @@ void ipadb_mspac_struct_free(struct ipadb_mspac **mspac) free((*mspac)->trusts[i].domain_name); free((*mspac)->trusts[i].flat_name); free((*mspac)->trusts[i].domain_sid); + free((*mspac)->trusts[i].transit_realm); free((*mspac)->trusts[i].sid_blacklist_incoming); free((*mspac)->trusts[i].sid_blacklist_outgoing); } @@ -2209,6 +2211,84 @@ done: return ret; } +static int get_transit_realm(LDAP *lc, LDAPMessage *le, char **transit_realm) +{ + char *dn_str = NULL; + char *val = NULL; + LDAPDN dn; + int ret; + size_t num_vals; + char *p; + + dn_str = ldap_get_dn(lc, le); + if (dn_str == NULL) { + ret = EINVAL; + goto done; + } + + ret = ldap_str2dn(dn_str, &dn, LDAP_DN_FORMAT_LDAPV3); + if (ret != LDAP_SUCCESS) { + ret = EINVAL; + goto done; + } + + for (num_vals = 0; dn != NULL && dn[num_vals] != NULL; num_vals++); + if (num_vals < 5) { + /* we are only interested in the children of a forest root object */ + ret = 0; + *transit_realm = NULL; + goto done; + } + + ret = ldap_rdn2str(dn[2], &val, LDAP_DN_FORMAT_UFN); + if (ret != LDAP_SUCCESS) { + ret = EINVAL; + goto done; + } + if (strcmp(val, "ad") != 0) { + ret = 0; + *transit_realm = NULL; + goto done; + } + + ldap_memfree(val); + ret = ldap_rdn2str(dn[3], &val, LDAP_DN_FORMAT_UFN); + if (ret != LDAP_SUCCESS) { + ret = EINVAL; + goto done; + } + if (strcmp(val, "trusts") != 0) { + ret = 0; + *transit_realm = NULL; + goto done; + } + + ldap_memfree(val); + ret = ldap_rdn2str(dn[1], &val, LDAP_DN_FORMAT_UFN); + if (ret != LDAP_SUCCESS) { + ret = EINVAL; + goto done; + } + *transit_realm = strdup(val); + if (*transit_realm == NULL) { + ret = ENOMEM; + goto done; + } + + for (p = *transit_realm; *p; p++) { + *p = toupper(*p); + } + + ret = 0; + +done: + ldap_memfree(val); + ldap_dnfree(dn); + ldap_memfree(dn_str); + + return ret; +} + krb5_error_code ipadb_mspac_get_trusted_domains(struct ipadb_context *ipactx) { struct ipadb_adtrusts *t; @@ -2280,6 +2360,12 @@ krb5_error_code ipadb_mspac_get_trusted_domains(struct ipadb_context *ipactx) goto done; } + ret = get_transit_realm(lc, le, &t[n].transit_realm); + if (ret) { + ret = EINVAL; + goto done; + } + ret = ipadb_ldap_attr_to_strlist(lc, le, "ipaNTSIDBlacklistIncoming", &sid_blacklist_incoming); -- 1.8.1.4 -------------- next part -------------- From 50c6e3b90981dfcb38c3b7f8889be6f050a599c7 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 2 Oct 2013 11:45:27 +0200 Subject: [PATCH 2/2] ipa-kdb: check for alternatives if cross realm TGT cannot be found If an IPA client wants to access a service from the member domain of a trusted forest it will first try to get a cross realm TGT for this domain, e.g. krbtgt/MEMBER.AD.DOM at IPA.DOM. But IPA will only share credentials with the forest root and hence only have krbtgt/AD.DOM at IPA.DOM. But the KDC of the forest root has credentials for it's member domains. With this patch for every cross realm ticket which cannot be found in the directory tree we check if there is a transit realm which might be able to handle this request further. If this is the case we send a cross realm TGT for the transit realm back to the client. Although this is the same behaviour as can be seen when using [capaths] in krb5.conf I'm currently not sure if this is really the right behaviour. It needs further discussion. --- daemons/ipa-kdb/ipa_kdb.h | 9 +++++ daemons/ipa-kdb/ipa_kdb_mspac.c | 66 ++++++++++++++++++++++++++++++++++++ daemons/ipa-kdb/ipa_kdb_principals.c | 13 ++++--- 3 files changed, 83 insertions(+), 5 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h index 1c2aefc..8eb9247 100644 --- a/daemons/ipa-kdb/ipa_kdb.h +++ b/daemons/ipa-kdb/ipa_kdb.h @@ -163,6 +163,11 @@ int ipadb_ldap_attr_has_value(LDAP *lcontext, LDAPMessage *le, int ipadb_ldap_deref_results(LDAP *lcontext, LDAPMessage *le, LDAPDerefRes **results); +krb5_error_code ipadb_check_for_alternative_tgs(struct ipadb_context *ipactx, + unsigned int flags, + char **principal, + LDAPMessage **result); + /* PRINCIPALS FUNCTIONS */ krb5_error_code ipadb_get_principal(krb5_context kcontext, krb5_const_principal search_for, @@ -178,6 +183,10 @@ krb5_error_code ipadb_iterate(krb5_context kcontext, char *match_entry, int (*func)(krb5_pointer, krb5_db_entry *), krb5_pointer func_arg); +krb5_error_code ipadb_fetch_principals(struct ipadb_context *ipactx, + unsigned int flags, + char *principal, + LDAPMessage **result); /* POLICY FUNCTIONS */ diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index ce9b06a..39259dd 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -2211,6 +2211,72 @@ done: return ret; } +krb5_error_code ipadb_check_for_alternative_tgs(struct ipadb_context *ipactx, + unsigned int flags, + char **principal, + LDAPMessage **result) +{ + krb5_error_code kerr; + krb5_principal princ; + char *new_principal = NULL; + int ret; + size_t c; + + if (!ipactx->kcontext) { + kerr = KRB5_KDB_SERVER_INTERNAL_ERR; + goto done; + } + + kerr = krb5_parse_name(ipactx->kcontext, *principal, &princ); + if (!is_cross_realm_krbtgt(princ)) { + kerr = KRB5_KDB_NOENTRY; + goto done; + } + + for (c = 0; c < ipactx->mspac->num_trusts; c++) { + if (strncasecmp(ipactx->mspac->trusts[c].domain_name, + princ->data[1].data, princ->data[1].length) == 0) { + if (ipactx->mspac->trusts[c].transit_realm == NULL) { + kerr = KRB5_KDB_NOENTRY; + goto done; + } + + ret = asprintf(&new_principal, "krbtgt/%s@%.*s", + ipactx->mspac->trusts[c].transit_realm, + princ->realm.length, princ->realm.data); + if (ret == -1) { + new_principal = NULL; + kerr = KRB5_KDB_INTERNAL_ERROR; + goto done; + } + + break; + } + } + + if (new_principal == NULL) { + kerr = KRB5_KDB_NOENTRY; + goto done; + } + + kerr = ipadb_fetch_principals(ipactx, flags, new_principal, result); + + if (kerr == 0) { + free(*principal); + *principal = strdup(new_principal); + if (*principal == NULL) { + kerr = KRB5_KDB_INTERNAL_ERROR; + goto done; + } + } + +done: + free(new_principal); + krb5_free_principal(ipactx->kcontext, princ); + + return kerr; +} + static int get_transit_realm(LDAP *lc, LDAPMessage *le, char **transit_realm) { char *dn_str = NULL; diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c index 38059d2..e56e29d 100644 --- a/daemons/ipa-kdb/ipa_kdb_principals.c +++ b/daemons/ipa-kdb/ipa_kdb_principals.c @@ -557,10 +557,10 @@ done: return kerr; } -static krb5_error_code ipadb_fetch_principals(struct ipadb_context *ipactx, - unsigned int flags, - char *principal, - LDAPMessage **result) +krb5_error_code ipadb_fetch_principals(struct ipadb_context *ipactx, + unsigned int flags, + char *principal, + LDAPMessage **result) { krb5_error_code kerr; char *src_filter = NULL; @@ -828,7 +828,10 @@ krb5_error_code ipadb_get_principal(krb5_context kcontext, } kerr = ipadb_fetch_principals(ipactx, flags, principal, &res); - if (kerr != 0) { + if (kerr == KRB5_KDB_NOENTRY + || ldap_count_entries(ipactx->lcontext, res) == 0) { + kerr = ipadb_check_for_alternative_tgs(ipactx, flags, &principal, &res); + } else if (kerr != 0) { goto done; } -- 1.8.1.4 From pviktori at redhat.com Wed Oct 2 11:26:00 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Oct 2013 13:26:00 +0200 Subject: [Freeipa-devel] [PATCHES] 0289-0302 Managed Read permissions In-Reply-To: <1135777364.287904.1380712053236.JavaMail.root@redhat.com> References: <524A8E59.8010605@redhat.com> <524BDBBA.6060506@redhat.com> <1135777364.287904.1380712053236.JavaMail.root@redhat.com> Message-ID: <524C02C8.9030300@redhat.com> On 10/02/2013 01:07 PM, Simo Sorce wrote: > > > ----- Original Message ----- >> On 10/01/2013 10:56 AM, Petr Viktorin wrote: >>> Hello, >>> >>> These patches implement the framework for >>> https://fedorahosted.org/freeipa/ticket/3566 >>> >>> Design is at http://www.freeipa.org/page/V3/Managed_Read_permissions. >>> As you can see from the TODOs it's not yet complete; I'll need a few more >>> discussions about some details and future work. >>> >>> The patches only add read permissions for User objects, and the global >>> anonymous read ACI is not removed. I'll add the other objects after the >>> overall >>> structure is ACKed. >>> To test, remove the ACI (cheatsheet: http://fpaste.org/43296/13806142/) and >>> verify that anonymous read is disabled and normal users can't read anything >>> but >>> user info. >>> >>> >>> These depend on some of my earlier patches: >>> - 0258-0265, 0275 - LDIF-based schema updater >>> - 0276-0277 - Split large doc strings for translation >>> - 0288 - user template in tests These are the dependencies ^ >>> I needed to test both server and client plugins. Since we only have one API >>> object (#3090) and can't unload plugins, I needed to fix some issues when >>> they >>> are loaded at the same time. >>> >>> Terminology note: currently IPA calls the "read"/"search"/"write"/"delete" >>> part >>> of an ACI a "permission", which is confusing since our ACI wrapper objects >>> are >>> also "permissions". >>> Wherever I can, I use the term "rights" for these. >>> "Rights" is also used in ACI docs: >>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#id3349243 >>> >>> >>> >>> /Enter patches. >>> >>> Act I. >>> >>> 0289: Might as well update to new API since I'll be making extensive >>> changes here >>> >>> 0290: My linting tools were complaining heavily about the tabs, so I fixed >>> the >>> indentation here. >>> >>> 0291: Fix a crash when ldap2 and a client RPC backend are connected at the >>> same >>> time. (This happens in tests that I'll add later) >>> >>> >>> Act II. >>> >>> 0292: See the "Permission flags" section of the design. >>> >>> 0293: Add schema. (The OIDs aren't registered yet.) >>> >>> 0294: This makes the test in the next patch possible. >>> >>> 0295: See the "MANAGED Permissions" section of the design. >>> >>> 0296: See the "Read rights" section of the design. >>> >>> >>> Act III. >>> >>> 0297: See "Marking Attributes in Plugins" and "Adding permissions for >>> default >>> read permissions" in the design. >>> >>> 0298: Make the help plugin not fail when server plugins are loaded. This >>> will >>> happen in later tests. >>> >>> 0299: Tests for 0297 >>> >>> 0300! Fix a TODO from 0295 >>> >>> 0301: See "Adding privileges and role for default read permissions" in the >>> design >>> >>> 0302: Tests for 0301 >>> >> >> Thanks for all the patches and carrying on with this major effort! I swiftly >> went through the patches and have few comments: >> >> 1) Patch 293 requires your schema updater patches, right? That means patches >> 258-265, 275 >> >> There may be more dependencies though: >> >> ... >> Applying: Add Reader role and user read privilege >> Applying: Add tests for the new Reader role >> error: patch failed: ipatests/test_xmlrpc/test_user_plugin.py:106 >> error: ipatests/test_xmlrpc/test_user_plugin.py: patch does not apply >> Patch failed at 0014 Add tests for the new Reader role >> See the list of deps earlier in the mail :) >> >> 2) 297: in update_managed_permissions, handling of >> ipapermissionallowedattribute and ipapermissionexcludedattribute should be >> handled by >> >> + try: >> + api.Command.permission_mod(name) >> + except errors.EmptyModlist: >> + self.log.debug('Attributes unchanged') >> >> right? Yes. ipapermdefaultattrs is added in ldap.update_entry(entry), and then from that and allowed+excluded, attributes is recomputed in permission_mod. This way the algorithm is kept in one place. >> 3) 301: I did not like the Reader role & User Readers privilege very much. I >> see several issues related to that: >> >> a) performance reasons - read operation on LDAP must be as fast as possible. >> DS >> checking membership in ipausers where may be 100000 of users does not look >> right >> >> b) ipausers group may be changed to other group by setting >> ipaDefaultPrimaryGroup. I also think we are guaranteed that it really >> contains >> all users. There have been also thoughts about removing it. Having ipausers in Readers is just a default, the admin can change it to match their setting. But your point is still valid. >> To sum it up, I would rather not build our permission system on this group. >> >> I think we need top base our ACIs on LDAP bind targets ldap:///all and >> ldap:///anyone to avoid performance issues and issues with ipausers not being >> complete: >> >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Access_Control-Bind_Rules.html >> >> I rather think we want to base the permissions on binddn. In the beginning, >> there would be 3 types of permissions based on binddn: >> >> * groupdn based: standard permissions that can be assigned privileges >> * ldap:///all permissions for all authenticated users. Cannot be assigned to >> privileges (would not make sense) >> * ldap:///anyone permissions for all, including anonymous users. Cannot be >> assigned to privileges (would not make sense) >> >> Just few examples: >> Read users - ldap:///anyone >> Read groups - ldap:///anyone >> Read sudo - ldap:///all >> Read hbac - ldap:///all >> ... >> >> Basing the permissions on these would allow us to get rid of all the awful >> deny permissions. >> >> To make the permission Bind part more user friendly, there should be an >> option >> in permission-find and a switch in Web UI to e.g. list permissions by bind >> type, i.e.: >> - anonymous permissions >> - authenticated users permissions >> - group based permissions >> >> If use would want to e.g restrict sudo only to specified group, I would see >> this workflow: >> 1) Change bind type from "authenticated users" to "group based" >> 2) Bind permission to chosen privilege >> 3) ... >> >> And the opposite, if he wants to make reading more open: >> 1) Unbind permission from privilege >> 2) Change bind type to "authenticated users" or "anonymous" >> >> Makes sense? Yes. > I agree with Martin's comments too. > > Simo. We use privileges to group related permissions. For example an "Automount Reader" privilege would contain "read automount keys" and "read automount maps" permissions. Wouldn't it make more sense (from the user's point of view at least) to have this setting at the privilege level? The selfservice plugin does pretty much the same thing. Should we (aim to) move selfservice functionality to this system? And, since these permissions are longer be compatible with old versions, I could move them out of $SUFFIX and onto the relevant containers. That should also help performance. -- Petr? From abokovoy at redhat.com Wed Oct 2 11:42:44 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 2 Oct 2013 14:42:44 +0300 Subject: [Freeipa-devel] [PoC/RfC] ipa-kdb: check for alternatives if cross realm TGT cannot be found In-Reply-To: <20131002112334.GZ10000@localhost.localdomain> References: <20131002112334.GZ10000@localhost.localdomain> Message-ID: <20131002114244.GR4216@redhat.com> On Wed, 02 Oct 2013, Sumit Bose wrote: >Hi, > >the attached two patches are a proof-of-concept how we can eliminate the >need to have [capaths] defined in krb5.conf for member domains in >trusted forests together with Alexander's patch 0123. > >capaths are used in the core KDC code at two places. One is to validate >transited field in the TGT, this is handled by Alexander's patch. > >The other is to find out where to redirect a client asking for a cross >realm TGT for a realm we do not shared credential with but know and >trust a realm which can handle this. This is typically the case for >member domains(realms) in a trusted forest. We share credentials with >the forest root but not with the members but we know that the forest >root can handle requests for its member domains. > >The patches are just proof-of-concept because I'm currently not sure if >this is kerberos-wise the right way to handle it. Additionally we might >want to enhance the patches to handle to more broader use case of >transitive-trusts. > >Please note that for the time being there is a workaround implemented in >SSSD to add a suitable [capaths] section to the krb5.conf include file >managed by SSSD. > >bye, >Sumit >From 73893a102c300627f7977afaf482ee83afc2a161 Mon Sep 17 00:00:00 2001 >From: Sumit Bose >Date: Wed, 2 Oct 2013 11:44:32 +0200 >Subject: [PATCH 1/2] ipa-kdb: add transit_realm member to trusted domains > >To be able to handle requests for member domains in a trusted forest we >must know which forest the domain belongs to. Because we only share >credentials with the forest root all request for member domains must go >through (transit) the KDC of the forest root. This will also be true for >other forests which are trusted by the forest we trust. But the patch >does not handle this case because it is currently not clear how >transitively trusted forests will be stored in the directory tree. >--- > daemons/ipa-kdb/ipa_kdb_mspac.c | 86 +++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 86 insertions(+) > >diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c >index 27d50ac..ce9b06a 100644 >--- a/daemons/ipa-kdb/ipa_kdb_mspac.c >+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c >@@ -32,6 +32,7 @@ struct ipadb_adtrusts { > char *domain_name; > char *flat_name; > char *domain_sid; >+ char *transit_realm; > struct dom_sid domsid; > struct dom_sid *sid_blacklist_incoming; > int len_sid_blacklist_incoming; >@@ -2119,6 +2120,7 @@ void ipadb_mspac_struct_free(struct ipadb_mspac **mspac) > free((*mspac)->trusts[i].domain_name); > free((*mspac)->trusts[i].flat_name); > free((*mspac)->trusts[i].domain_sid); >+ free((*mspac)->trusts[i].transit_realm); > free((*mspac)->trusts[i].sid_blacklist_incoming); > free((*mspac)->trusts[i].sid_blacklist_outgoing); > } >@@ -2209,6 +2211,84 @@ done: > return ret; > } > >+static int get_transit_realm(LDAP *lc, LDAPMessage *le, char **transit_realm) >+{ >+ char *dn_str = NULL; >+ char *val = NULL; >+ LDAPDN dn; >+ int ret; >+ size_t num_vals; >+ char *p; >+ >+ dn_str = ldap_get_dn(lc, le); >+ if (dn_str == NULL) { >+ ret = EINVAL; >+ goto done; >+ } >+ >+ ret = ldap_str2dn(dn_str, &dn, LDAP_DN_FORMAT_LDAPV3); >+ if (ret != LDAP_SUCCESS) { >+ ret = EINVAL; >+ goto done; >+ } >+ >+ for (num_vals = 0; dn != NULL && dn[num_vals] != NULL; num_vals++); >+ if (num_vals < 5) { We know base dn and trust container, so we can just use the part of the string before trust container and deal with that only -- if it matches. This way we would have two DN components available. The rest looks fine for PoC. We still need to identify what semantics should be followed by the KDB method to check transitions. It would be good to support blending of KDB driver decision and [capaths] tree if it is available to allow easier handling of MIT Kerberos trusts with IPA for migration/co-existance purposes: in case of existing MIT Kerberos realm, copying its [capaths] tree is easy -- add it to IPA KDC's krb5.conf, create cross-realm principals and everything should start working. Otherwise we would need to implement special trust type explicitly to re-write existing [capaths] parser and handler for no real benefit. -- / Alexander Bokovoy From pvoborni at redhat.com Wed Oct 2 12:20:00 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 02 Oct 2013 14:20:00 +0200 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <523722A3.7060700@redhat.com> References: <523049A5.10208@redhat.com> <523722A3.7060700@redhat.com> Message-ID: <524C0F70.809@redhat.com> On 09/16/2013 05:24 PM, Ana Krivokapic wrote: > On 09/11/2013 12:44 PM, Petr Vobornik wrote: >> Hello, >> snip >> > > I looked into the documentation effort and (ruby dependency discussion aside) I > don't have any major objections. I like how the generated pages look, and they > are intuitive and easy to navigate. > > A couple of nitpicks: > > 1) There are some spelling mistakes (e.g. Apllication_controller) Fixed > > 2) Bulleted lists are not rendered nicely in the html output (see for example > the doc string for _base.Builder property 'string_mode'. I think a list needs to > look like this in the source code: > > /** > * This is a list: > * > * - 'element1' > * - 'element2' > * > */ > > as opposed to this: > > /** > * This is a list: > * - 'element1' > * - 'element2' > */ > Fixed on many places. Also fixed the same issue in some code examples. - _base.Builder doc was heavily revised - added doc comments to ./plugin_loader All patches are rebased but just patches 452 and 453 are changed. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0458-1-Registries-and-Build-Guide.patch Type: text/x-patch Size: 12664 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0457-1-Navigation-Guide.patch Type: text/x-patch Size: 15630 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0456-1-Plugin-Infrastructure-Guide.patch Type: text/x-patch Size: 5022 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0455-1-Debugging-Web-UI-guide.patch Type: text/x-patch Size: 6324 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0454-1-Phases-Guide.patch Type: text/x-patch Size: 9671 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0453-1-Configuration-for-JSDuck-documentation-generator.patch Type: text/x-patch Size: 9540 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0452-1-Web-UI-source-code-annotation.patch Type: text/x-patch Size: 323184 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0451-1-Removal-of-unused-code.patch Type: text/x-patch Size: 1211 bytes Desc: not available URL: From pviktori at redhat.com Wed Oct 2 12:40:37 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Oct 2013 14:40:37 +0200 Subject: [Freeipa-devel] [PATCH 0018] Ensure credentials structure is initialized In-Reply-To: <52456903.4060907@redhat.com> References: <1380146822.2046.8.camel@localhost> <52440E1F.6040805@redhat.com> <1380206911.22351.3.camel@localhost> <524562CC.8030907@redhat.com> <52456903.4060907@redhat.com> Message-ID: <524C1445.2090506@redhat.com> On 09/27/2013 01:16 PM, Petr Vobornik wrote: > On 09/27/2013 12:49 PM, Petr Viktorin wrote: >> On 09/26/2013 04:48 PM, Nathaniel McCallum wrote: >>> On Thu, 2013-09-26 at 12:36 +0200, Petr Viktorin wrote: >>>> On 09/26/2013 12:07 AM, Nathaniel McCallum wrote: >>>>> Patch attached. >>>>> >>>> >>>> There's a ticket to make FreeIPA build with stricter warnings: >>>> https://fedorahosted.org/freeipa/ticket/3896 >>>> >>>> AFAIU this will trip -Wmissing-field-initializers. >>> >>> C89 (implicitly) and C99 (explicitly) define that unspecified fields in >>> initializers have the same initialization as static storage (aka zero). >>> This feature is both well defined and useful. We should disable that >>> warning. >> >> I added a note to that ticket, warnings can be discussed there. We'll >> probably want to coordinate with SSSD as their team has more C >> experience. >> >> Back to your patch: >> Does the issue have a ticket in Trac? Which branches does it apply to? >> > It has now: https://fedorahosted.org/freeipa/ticket/3953 Thanks! I've added that URL to the commit message and pushed to master: 1acd00487fad66983ec2716cb4ef888f8813d390 ipa-3-3: c6647a09ab6d37c2acf60cd95e365598d72c6fb9 -- Petr? From pviktori at redhat.com Wed Oct 2 13:49:28 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Oct 2013 15:49:28 +0200 Subject: [Freeipa-devel] [PATCH] 0303 Use correct super-calls in get_args() methods Message-ID: <524C2468.5070908@redhat.com> As Nathaniel found while implementing OTP, weird super() calls in get_args make it difficult to customize the get_args behavior in LDAP CRUD methods. This patch makes the super() calls properly follow the inheritance chain. I've sent a previous version of the patch, which only corrected one occurrence to the problem, to Nathaniel's thread: http://www.redhat.com/archives/freeipa-devel/2013-October/msg00020.html -- Petr? ~ "if you need to add a pylint exception for it, it might be a bad idea" -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0303.2-Use-correct-super-calls-in-get_args-methods.patch Type: text/x-patch Size: 4916 bytes Desc: not available URL: From npmccallum at redhat.com Wed Oct 2 14:00:33 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 02 Oct 2013 10:00:33 -0400 Subject: [Freeipa-devel] [PATCH] 0303 Use correct super-calls in get_args() methods In-Reply-To: <524C2468.5070908@redhat.com> References: <524C2468.5070908@redhat.com> Message-ID: <1380722433.27810.1.camel@localhost> On Wed, 2013-10-02 at 15:49 +0200, Petr Viktorin wrote: > As Nathaniel found while implementing OTP, weird super() calls in > get_args make it difficult to customize the get_args behavior in LDAP > CRUD methods. > > This patch makes the super() calls properly follow the inheritance chain. > > > I've sent a previous version of the patch, which only corrected one > occurrence to the problem, to Nathaniel's thread: > http://www.redhat.com/archives/freeipa-devel/2013-October/msg00020.html ACK From pviktori at redhat.com Wed Oct 2 14:11:33 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Oct 2013 16:11:33 +0200 Subject: [Freeipa-devel] [PATCH] 0303 Use correct super-calls in get_args() methods In-Reply-To: <1380722433.27810.1.camel@localhost> References: <524C2468.5070908@redhat.com> <1380722433.27810.1.camel@localhost> Message-ID: <524C2995.8090400@redhat.com> On 10/02/2013 04:00 PM, Nathaniel McCallum wrote: > On Wed, 2013-10-02 at 15:49 +0200, Petr Viktorin wrote: >> As Nathaniel found while implementing OTP, weird super() calls in >> get_args make it difficult to customize the get_args behavior in LDAP >> CRUD methods. >> >> This patch makes the super() calls properly follow the inheritance chain. >> >> >> I've sent a previous version of the patch, which only corrected one >> occurrence to the problem, to Nathaniel's thread: >> http://www.redhat.com/archives/freeipa-devel/2013-October/msg00020.html > > ACK > Thanks, pushed to master: 295ce7bf18510efbe7d170887eb4e6956d3db035 -- Petr? From pviktori at redhat.com Wed Oct 2 14:34:06 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 02 Oct 2013 16:34:06 +0200 Subject: [Freeipa-devel] [PATCH] 0304 ipapython.nsslib: Name arguments to NSPRError Message-ID: <524C2EDE.5000006@redhat.com> As I found out when installing on a misconfigured system, we use wrong argument order for NSPRError in nsslib. This patch corrects the problem. FWIW raising NSPRError might not be correct; the nss.error.NSPRError docstring states: > Raised internally, there should be no need to raise this exception > from with a Python program using python-nss. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0304-ipapython.nsslib-Name-arguments-to-NSPRError.patch Type: text/x-patch Size: 1857 bytes Desc: not available URL: From pvoborni at redhat.com Wed Oct 2 15:17:17 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 02 Oct 2013 17:17:17 +0200 Subject: [Freeipa-devel] [PATCH] 0067 Use fqdn when creating msdcs SRV records In-Reply-To: <5239D7E5.2090401@redhat.com> References: <5239D7E5.2090401@redhat.com> Message-ID: <524C38FD.1040506@redhat.com> On 09/18/2013 06:42 PM, Ana Krivokapic wrote: > Hello, > > This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3908. > > The patch does what it advertises - it uses fqdn every time for mcsdcs SRV records. It's not consistent with other DNS SRV records, where fqdn is used only when IPA server is not in the IPA DNS domain. bindinstance.py uses this code to address the same issue: host, zone = fqdn.split(".", 1) if normalize_zone(zone) == normalize_zone(self.domain): host_in_rr = host else: host_in_rr = normalize_zone(fqdn) Alexander suggests the same solution -- Petr Vobornik From mkosek at redhat.com Wed Oct 2 15:24:33 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 02 Oct 2013 17:24:33 +0200 Subject: [Freeipa-devel] [PATCH] 0067 Use fqdn when creating msdcs SRV records In-Reply-To: <524C38FD.1040506@redhat.com> References: <5239D7E5.2090401@redhat.com> <524C38FD.1040506@redhat.com> Message-ID: <524C3AB1.7060100@redhat.com> On 10/02/2013 05:17 PM, Petr Vobornik wrote: > On 09/18/2013 06:42 PM, Ana Krivokapic wrote: >> Hello, >> >> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3908. >> >> > > The patch does what it advertises - it uses fqdn every time for mcsdcs SRV > records. > > It's not consistent with other DNS SRV records, where fqdn is used only when > IPA server is not in the IPA DNS domain. > > bindinstance.py uses this code to address the same issue: > > host, zone = fqdn.split(".", 1) > > if normalize_zone(zone) == normalize_zone(self.domain): > host_in_rr = host > else: > host_in_rr = normalize_zone(fqdn) > > Alexander suggests the same solution > Yes, I think we should be fixed. When I was looking at the AD SRV records using this patch, it just look confusing - some records relative, some were absolute. This could bite us later when for example removing or changing these records. Martin From pvoborni at redhat.com Wed Oct 2 15:49:31 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 02 Oct 2013 17:49:31 +0200 Subject: [Freeipa-devel] [PATCH] 0304 ipapython.nsslib: Name arguments to NSPRError In-Reply-To: <524C2EDE.5000006@redhat.com> References: <524C2EDE.5000006@redhat.com> Message-ID: <524C408B.1010309@redhat.com> On 10/02/2013 04:34 PM, Petr Viktorin wrote: > As I found out when installing on a misconfigured system, we use wrong > argument order for NSPRError in nsslib. This patch corrects the problem. ACK A nitpick: $ git diff HEAD~1 | pep8 --diff ./ipapython/nsslib.py:145:14: E111 indentation is not a multiple of four ./ipapython/nsslib.py:148:21: E128 continuation line under-indented for visual indent You are a bigger fan of pep8, so it's up to you... > > > FWIW raising NSPRError might not be correct; the nss.error.NSPRError > docstring states: > > Raised internally, there should be no need to raise this exception > > from with a Python program using python-nss. > > -- Petr Vobornik From tbabej at redhat.com Wed Oct 2 20:31:21 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 02 Oct 2013 22:31:21 +0200 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <20131001151509.GP4216@redhat.com> References: <523C388E.2050008@redhat.com> <523FF024.4010300@redhat.com> <20130923081509.GR4216@redhat.com> <20130923141841.GS4216@redhat.com> <20130923150422.GT4216@redhat.com> <20130927125308.GD4216@redhat.com> <20130927163121.GM10000@localhost.localdomain> <20130928200134.GF4216@redhat.com> <52495AEB.7000204@redhat.com> <20130930123143.GJ4216@redhat.com> <20131001151509.GP4216@redhat.com> Message-ID: <524C8299.9040801@redhat.com> On 10/01/2013 05:15 PM, Alexander Bokovoy wrote: > On Mon, 30 Sep 2013, Alexander Bokovoy wrote: >> On Mon, 30 Sep 2013, Tomas Babej wrote: >>> On 09/28/2013 10:01 PM, Alexander Bokovoy wrote: >>>> On Fri, 27 Sep 2013, Sumit Bose wrote: >>>>> On Fri, Sep 27, 2013 at 03:53:08PM +0300, Alexander Bokovoy wrote: >>>>>> On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >>>>>>> On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >>>>>>>> On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >>>>>>>>> On Mon, 23 Sep 2013, Martin Kosek wrote: >>>>>>>>>>>> However, we don't have trust type available so it needs >>>>>> to discovered >>>>>>>>>>>> every time. This doesn't play well with the framework, it >>>>>> is simply not >>>>>>>>>>>> expecting dynamic containers. >>>>>>>>>>> >>>>>>>>>>> This doesn't sound like a big obstacle to me. Right now >>>>>> the trust_type lookup >>>>>>>>>>> is done in trust_show.execute() for some reason, which is >>>>>> not the best place to >>>>>>>>>>> do it IMHO. Doing it in trust.get_dn() instead should >>>>>> simplify things enough to >>>>>>>>>>> make parent_object work. >>>>>>>>>> >>>>>>>>>> Yup, get_dn() is the method where object DN lookup should >>>>>> be done. See for >>>>>>>>>> example host.py plugin get_dn method, we also do a dynamic >>>>>> lookup for correct >>>>>>>>>> host name. >>>>>>>>> I'll see if that would work. >>>>>>>>> >>>>>>>>>> the best way to implement dynamic DN gathering is the >>>>>> get_dn() method. That >>>>>>>>>> way, it could be implemented in one place and all commands >>>>>> could take advantage >>>>>>>>>> of it instead of re-implementing it several times in >>>>>> pre_callback - this is >>>>>>>>>> just hackish. >>>>>>>>> I'd suggest you look into the code. The commands use >>>>>> pre_callback for a >>>>>>>>> different purpose than implementing dynamic DN gathering. >>>>>>>>> >>>>>>>>>> I think it would have been very useful to have a design >>>>>> page before sending a >>>>>>>>>> patch. It is then easier to make design decisions without >>>>>> having to dig into >>>>>>>>>> the patch. >>>>>>>>> The design page is there for long time: >>>>>>>>> http://www.freeipa.org/page/V3/Transitive_Trusts >>>>>>>> Ok, here is new version of the patch and updated version of my >>>>>>>> 0117 >>>>>>>> patch as Sumit noticed I've sent wrong version. >>>>>>> Ok, here is updated 0118 which fixes API.txt change for >>>>>> trustdomain_add >>>>>>> -- I renamed trustdomain_create to trustdomain_add but forgot to >>>>>>> rerun >>>>>>> makeapi. >>>>>> New edition attached for all subdomain-related patches: >>>>> >>>>> I did some tests and all is working as expected. >>>>> >>>>>> >>>>>> freeipa-abbra-0117-ipaserver-dcerpc.py-populate-forest-trust-informatio-3.patch >>>>>> >>>>>> >>>>>> Use realmdomains to report name suffix routes at the time we >>>>>> establish trust >>>>>> >>>>>> freeipa-abbra-0118-trusts-support-subdomains-in-a-forest-3.patch >>>>>> Introduce trustdomain-* commands to fetch list of domains associated >>>>>> with a forest trust and allow filtering them off >>>>> >>>>> We talked on irc that ipaNTSupportedEncryptionTypes in the filter >>>>> for the trusted domains should be replace by a different attribute. >>>>> Because of an error in ipasam the ipaNTSupportedEncryptionTypes is >>>>> only >>>>> set in recent versions and might not be present in the directory >>>>> trees of >>>>> older versions. >>>> Fixed in the attached patch 0118 version 4. >>>> >>>> Also attached first attempt to implement transiting through trusted >>>> domains, as patch 0123. In this patch we grant transition only if all >>>> three realms (client, transited realm, and server realm) match any of >>>> our trusted domains and our domain. This is probably a bit wider >>>> but it >>>> worked for me bidirectionally, from a child domain to a service in >>>> IPA, >>>> and from IPA realm to a service in a child domain of a forest trust. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> Hi, >>> >>> here are my comments: >>> >>> *PATCH 117* >>> >>> + def get_realmdomains(self): >>> + """ >>> + Generate list of records for forest trust information about >>> + our realm domains. Note that the list generated currently >>> + includes only top level domains, no exclusion domains, and >>> no TDO objects >>> + as we handle the latter in a separte way >>> + """ >>> >>> A nitpick typo: separte -> separate. >> Fixed. >> >>> >>> Also, there's trailing whitespace in the patch: >>> >>> Applying: ipaserver/dcerpc.py: populate forest trust information >>> using realmdomains >>> /home/tbabej/dev/freeipa/.git/rebase-apply/patch:62: trailing >>> whitespace. >>> Only top level name and top level name exclusions are handled >>> here. >>> /home/tbabej/dev/freeipa/.git/rebase-apply/patch:174: trailing >>> whitespace. >>> >>> warning: 2 lines add whitespace errors. >> Fixed. >> >>> >>> >>> *PATCH 119* >>> >>> We also need to change the frontend tests that cover this >>> functionality: >>> >>> ====================================================================== >>> FAIL: Test the ``ipalib.frontend.Command.args`` instance attribute. >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >>> runTest >>> self.test(*self.arg) >>> File >>> "/home/tbabej/dev/freeipa/ipatests/test_ipalib/test_frontend.py", >>> line 283, in test_args >>> assert str(e) == 'arg2: required argument after optional' >>> AssertionError >>> >>> See ipatests/test_ipalib/test_frontend.py, line 281: >>> >>> # Test ValueError, required after optional: >>> e = raises(ValueError, self.get_instance, args=('arg1?', 'arg2')) >>> assert str(e) == 'arg2: required argument after optional' >> Ok, will fix. This patch is not essential, of course, so we can decide >> what to do with it later. >> >>> >>> >>> *PATCH 120* >>> >>> When I try to add a trust, I get internal error: >>> >>> echo $AD_PASSWORD | ipa trust-add --type=ad $AD_DOMAIN --admin >>> Administrator --password >>> >>> [Wed Sep 25 10:28:53.978664 2013] [:error] [pid 7905] ipa: ERROR: >>> non-public: IndexError: tuple index out of range >>> [Wed Sep 25 10:28:53.978702 2013] [:error] [pid 7905] Traceback >>> (most recent call last): >>> [Wed Sep 25 10:28:53.978708 2013] [:error] [pid 7905] File >>> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 333, >>> in wsgi_execute >>> [Wed Sep 25 10:28:53.978713 2013] [:error] [pid 7905] result = >>> self.Command[name](*args, **options) >>> [Wed Sep 25 10:28:53.978720 2013] [:error] [pid 7905] File >>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in >>> __call__ >>> [Wed Sep 25 10:28:53.978725 2013] [:error] [pid 7905] ret = >>> self.run(*args, **options) >>> [Wed Sep 25 10:28:53.978730 2013] [:error] [pid 7905] File >>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 755, in run >>> [Wed Sep 25 10:28:53.978734 2013] [:error] [pid 7905] result = >>> self.execute(*args, **options) >>> [Wed Sep 25 10:28:53.978739 2013] [:error] [pid 7905] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py", line >>> 338, in execute >>> [Wed Sep 25 10:28:53.978744 2013] [:error] [pid 7905] >>> self.add_range(range_name, dom_sid, *keys, **options) >>> [Wed Sep 25 10:28:53.978748 2013] [:error] [pid 7905] File >>> "/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py", line >>> 549, in add_range >>> [Wed Sep 25 10:28:53.978755 2013] [:error] [pid 7905] quiet=True) >>> [Wed Sep 25 10:28:53.978759 2013] [:error] [pid 7905] File >>> "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 507, in >>> search_in_dc >>> [Wed Sep 25 10:28:53.978764 2013] [:error] [pid 7905] info = >>> self.__retrieve_trusted_domain_gc_list(domain) >>> [Wed Sep 25 10:28:53.978769 2013] [:error] [pid 7905] File >>> "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 595, in >>> __retrieve_trusted_domain_gc_list >>> [Wed Sep 25 10:28:53.978774 2013] [:error] [pid 7905] info['auth'] = >>> self._domains[domain][2] >>> [Wed Sep 25 10:28:53.978778 2013] [:error] [pid 7905] IndexError: >>> tuple index out of range >>> [Wed Sep 25 10:28:53.979248 2013] [:error] [pid 7905] ipa: INFO: >>> admin at DOM006.TBAD.IPA.COM: trust_add(u'tbad.ipa.com', >>> trust_type=u'ad', realm_admin=u'Administrator', >>> realm_passwd=u'********', all=False, raw=False, version=u'2.65'): >>> IndexError >>> >>> I think we need to do the following changes here: >>> >>> diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py >>> index fa5c449..4ac0a5f 100644 >>> --- a/ipaserver/dcerpc.py >>> +++ b/ipaserver/dcerpc.py >>> @@ -565,7 +565,6 @@ class DomainValidator(object): >>> Returns dictionary with following keys >>> name -- NetBIOS name of the trusted domain >>> dns_domain -- DNS name of the trusted domain >>> - auth -- encrypted credentials for trusted domain >>> account >>> gc -- array of tuples (server, port) for Global >>> Catalog >>> """ >>> if domain in self._info: >>> @@ -592,7 +591,6 @@ class DomainValidator(object): >>> self._domains = self.get_trusted_domains() >>> >>> info = dict() >>> - info['auth'] = self._domains[domain][2] >>> servers = [] >>> >>> if result: >>> >>> After applying this fix, I get: >>> >>> tbabej at vm-006 freeipa]$ echo $AD_PASSWORD | ipa trust-add --type=ad >>> $AD_DOMAIN --admin Administrator --password >>> ipa: ERROR: CIFS server communication error: code "-1073741811", >>> message "Unexpected information received" (both may >>> be "None") >>> >>> I was unable to track this one down in a reasonable timeframe, I >>> suggest we continue on IRC. >> I've fixed this. At the time we establish trust, there could be a race >> condition when cross-realm TGT is not yet ready so we cannot rely on it >> when fetching domains. As we have administrator's credentials here, I've >> added use of them in addition to Kerberos. >> >> >> I'll send new patchset shortly. > New patchset is attached. > > 1. Added test update for ipalib/frontend.py changes > 2. Used LDAPQuery as base for trustdomain_enable|disable commands as > suggested by Honza. > 3. Fixed issues with removal of trust account password authentication > 4. Added support to use AD administrator credentials when fetching > subdomains information when we establish trust as Kerberos will not > be available for cross-realm operations yet. > 5. Patch 0123 is not part of the patchset and should not be committed, > we will discuss exact semantics of transition checks with MIT > Kerberos upstream first. > 6. Fixed few error paths and dead-end cases like attempt to disable root > domain of the trust (renders trust dead) or enabling it (it is always > enabled). > 7. Made clear that deleting root domain of the trust is not possible, > use trust-del instead. > 8. Removed whitespaces where saw. > > > Thanks! This fixes most of the issues I had. To summarize, two issues from the today's functional testing we already discussed on IRC: 1.) The blacklisting for the child domain does not work (it works fine for the root domain). Thus, ipa trustdomain-disable for the child domain does not reject access to the IPA's resources: [tbabej at vm-147 labtool]$ ipa trustdomain-disable tbad.idm.lab.eng.brq.redhat.com child.tbad.idm.lab.eng.brq.redhat.com ------------------------------------------------------------------------------------------------------------------------------------ Domain child.tbad.idm.lab.eng.brq.redhat.com of trust tbad.idm.lab.eng.brq.redhat.com is already not allowed to access IPA resources ------------------------------------------------------------------------------------------------------------------------------------ [tbabej at vm-147 labtool]$ kdestroy [tbabej at vm-147 labtool]$ kvno -S ldap `hostname` kvno: Credentials cache file '/run/user/536/krb5cc/tkt1sLaOS' not found while getting client principal name [tbabej at vm-147 labtool]$ kinit Administrator at CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM Password for Administrator at CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM: [tbabej at vm-147 labtool]$ klist Ticket cache: DIR::/run/user/536/krb5cc/tktS7Bkhj Default principal: Administrator at CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM Valid starting Expires Service principal 10/02/2013 21:28:52 10/03/2013 07:28:52 krbtgt/CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM at CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM renew until 10/03/2013 21:28:46 [tbabej at vm-147 labtool]$ kvno -S ldap `hostname` ldap/vm-147.dom147.tbad.idm.lab.eng.brq.redhat.com at DOM147.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM: kvno = 2 We should have been denied access here. 2.) The trust-fetch-domains has somewhat confusing options: [tbabej at vm-147 labtool]$ ipa trust-fetch-domains tbad.idm.lab.eng.brq.redhat.com --help Usage: ipa [global-options] trust-fetch-domains REALM [options] Refresh list of the domains associated with the trust Options: -h, --help show this help message and exit --rights Display the access rights of this entry (requires --all). See ipa man page for details. --all Retrieve and print all attributes from the server. Affects command output. --raw Print entries as stored on the server. Only affects output format. Please note that I did not test with more than 1 subdomain, since I do not have more ADs available. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From abokovoy at redhat.com Wed Oct 2 21:01:35 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 3 Oct 2013 00:01:35 +0300 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <524C8299.9040801@redhat.com> References: <20130923081509.GR4216@redhat.com> <20130923141841.GS4216@redhat.com> <20130923150422.GT4216@redhat.com> <20130927125308.GD4216@redhat.com> <20130927163121.GM10000@localhost.localdomain> <20130928200134.GF4216@redhat.com> <52495AEB.7000204@redhat.com> <20130930123143.GJ4216@redhat.com> <20131001151509.GP4216@redhat.com> <524C8299.9040801@redhat.com> Message-ID: <20131002210135.GU4216@redhat.com> On Wed, 02 Oct 2013, Tomas Babej wrote: >>>I'll send new patchset shortly. >>New patchset is attached. >> >>1. Added test update for ipalib/frontend.py changes >>2. Used LDAPQuery as base for trustdomain_enable|disable commands as >> suggested by Honza. >>3. Fixed issues with removal of trust account password authentication >>4. Added support to use AD administrator credentials when fetching >> subdomains information when we establish trust as Kerberos will not >> be available for cross-realm operations yet. >>5. Patch 0123 is not part of the patchset and should not be committed, >> we will discuss exact semantics of transition checks with MIT >> Kerberos upstream first. >>6. Fixed few error paths and dead-end cases like attempt to disable root >> domain of the trust (renders trust dead) or enabling it (it is always >> enabled). >>7. Made clear that deleting root domain of the trust is not possible, >> use trust-del instead. >>8. Removed whitespaces where saw. >> >> >> > >Thanks! > >This fixes most of the issues I had. > >To summarize, two issues from the today's functional testing we >already discussed on IRC: > >1.) The blacklisting for the child domain does not work (it works >fine for the root domain). >Thus, ipa trustdomain-disable for the child domain does not reject >access to the IPA's resources: > >[tbabej at vm-147 labtool]$ ipa trustdomain-disable >tbad.idm.lab.eng.brq.redhat.com child.tbad.idm.lab.eng.brq.redhat.com >------------------------------------------------------------------------------------------------------------------------------------ >Domain child.tbad.idm.lab.eng.brq.redhat.com of trust >tbad.idm.lab.eng.brq.redhat.com is already not allowed to access IPA >resources >------------------------------------------------------------------------------------------------------------------------------------ >[tbabej at vm-147 labtool]$ kdestroy >[tbabej at vm-147 labtool]$ kvno -S ldap `hostname` >kvno: Credentials cache file '/run/user/536/krb5cc/tkt1sLaOS' not >found while getting client principal name >[tbabej at vm-147 labtool]$ kinit >Administrator at CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM >Password for Administrator at CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM: >[tbabej at vm-147 labtool]$ klist >Ticket cache: DIR::/run/user/536/krb5cc/tktS7Bkhj >Default principal: Administrator at CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM > >Valid starting Expires Service principal >10/02/2013 21:28:52 10/03/2013 07:28:52 krbtgt/CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM at CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM > renew until 10/03/2013 21:28:46 >[tbabej at vm-147 labtool]$ kvno -S ldap `hostname` >ldap/vm-147.dom147.tbad.idm.lab.eng.brq.redhat.com at DOM147.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM: >kvno = 2 > >We should have been denied access here. Right. This is *very good* finding. Since we put information about black list only to the root level domain of the trust, we need to reference the root level domain when checking a subdomain. We don't do that right now and it is needed also in Sumit's patches so I'll work on merging them. Here is my plan: make a helper that identifies root domain for the trusted domain (Sumit's code already has this), fetch root domain of the trust and validate this domain's SID against black list associated with the root domain in filter_logon_info(). Here is MS-PAC dump I've got for the user from a subdomain. Note that its info.info.info3.sids array contains a SID of root domain's object. Successfully validated Kerberos PAC pac_data: struct PAC_DATA num_buffers : 0x00000005 (5) version : 0x00000000 (0) buffers: ARRAY(5) buffers: struct PAC_BUFFER type : PAC_TYPE_LOGON_INFO (1) _ndr_size : 0x000001e8 (488) info : * info : union PAC_INFO(case 1) logon_info: struct PAC_LOGON_INFO_CTR info : * info: struct PAC_LOGON_INFO info3: struct netr_SamInfo3 base: struct netr_SamBaseInfo logon_time : Wed Oct 2 10:00:50 PM 2013 CEST logoff_time : Thu Sep 14 04:48:05 AM 30828 CEST kickoff_time : Thu Sep 14 04:48:05 AM 30828 CEST last_password_change : Wed Mar 13 05:15:57 PM 2013 CET allow_password_change : Thu Mar 14 05:15:57 PM 2013 CET force_password_change : Thu Sep 14 04:48:05 AM 30828 CEST account_name: struct lsa_String length : 0x001a (26) size : 0x001a (26) string : * string : 'Administrator' full_name: struct lsa_String length : 0x0000 (0) size : 0x0000 (0) string : * string : '' logon_script: struct lsa_String length : 0x0000 (0) size : 0x0000 (0) string : * string : '' profile_path: struct lsa_String length : 0x0000 (0) size : 0x0000 (0) string : * string : '' home_directory: struct lsa_String length : 0x0000 (0) size : 0x0000 (0) string : * string : '' home_drive: struct lsa_String length : 0x0000 (0) size : 0x0000 (0) string : * string : '' logon_count : 0x0053 (83) bad_password_count : 0x0002 (2) rid : 0x000001f4 (500) primary_gid : 0x00000201 (513) groups: struct samr_RidWithAttributeArray count : 0x00000003 (3) rids : * rids: ARRAY(3) rids: struct samr_RidWithAttribute rid : 0x00000201 (513) attributes : 0x00000007 (7) 1: SE_GROUP_MANDATORY 1: SE_GROUP_ENABLED_BY_DEFAULT 1: SE_GROUP_ENABLED 0: SE_GROUP_OWNER 0: SE_GROUP_USE_FOR_DENY_ONLY 0: SE_GROUP_RESOURCE 0x00: SE_GROUP_LOGON_ID (0) rids: struct samr_RidWithAttribute rid : 0x00000200 (512) attributes : 0x00000007 (7) 1: SE_GROUP_MANDATORY 1: SE_GROUP_ENABLED_BY_DEFAULT 1: SE_GROUP_ENABLED 0: SE_GROUP_OWNER 0: SE_GROUP_USE_FOR_DENY_ONLY 0: SE_GROUP_RESOURCE 0x00: SE_GROUP_LOGON_ID (0) rids: struct samr_RidWithAttribute rid : 0x00000208 (520) attributes : 0x00000007 (7) 1: SE_GROUP_MANDATORY 1: SE_GROUP_ENABLED_BY_DEFAULT 1: SE_GROUP_ENABLED 0: SE_GROUP_OWNER 0: SE_GROUP_USE_FOR_DENY_ONLY 0: SE_GROUP_RESOURCE 0x00: SE_GROUP_LOGON_ID (0) user_flags : 0x00000020 (32) 0: NETLOGON_GUEST 0: NETLOGON_NOENCRYPTION 0: NETLOGON_CACHED_ACCOUNT 0: NETLOGON_USED_LM_PASSWORD 1: NETLOGON_EXTRA_SIDS 0: NETLOGON_SUBAUTH_SESSION_KEY 0: NETLOGON_SERVER_TRUST_ACCOUNT 0: NETLOGON_NTLMV2_ENABLED 0: NETLOGON_RESOURCE_GROUPS 0: NETLOGON_PROFILE_PATH_RETURNED 0: NETLOGON_GRACE_LOGON key: struct netr_UserSessionKey key : 00000000000000000000000000000000 logon_server: struct lsa_StringLarge length : 0x000c (12) size : 0x000e (14) string : * string : 'ADSUB2' logon_domain: struct lsa_StringLarge length : 0x000c (12) size : 0x000e (14) string : * string : 'SUBDOM' domain_sid : * domain_sid : S-1-5-21-1497370719-3066148852-2058531780 LMSessKey: struct netr_LMSessionKey key : 0000000000000000 acct_flags : 0x00000210 (528) 0: ACB_DISABLED 0: ACB_HOMDIRREQ 0: ACB_PWNOTREQ 0: ACB_TEMPDUP 1: ACB_NORMAL 0: ACB_MNS 0: ACB_DOMTRUST 0: ACB_WSTRUST 0: ACB_SVRTRUST 1: ACB_PWNOEXP 0: ACB_AUTOLOCK 0: ACB_ENC_TXT_PWD_ALLOWED 0: ACB_SMARTCARD_REQUIRED 0: ACB_TRUSTED_FOR_DELEGATION 0: ACB_NOT_DELEGATED 0: ACB_USE_DES_KEY_ONLY 0: ACB_DONT_REQUIRE_PREAUTH 0: ACB_PW_EXPIRED 0: ACB_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION 0: ACB_NO_AUTH_DATA_REQD 0: ACB_PARTIAL_SECRETS_ACCOUNT 0: ACB_USE_AES_KEYS sub_auth_status : 0x00000000 (0) last_successful_logon : NTTIME(0) last_failed_logon : NTTIME(0) failed_logon_count : 0x00000000 (0) reserved : 0x00000000 (0) sidcount : 0x00000001 (1) sids : * sids: ARRAY(1) sids: struct netr_SidAttr sid : * sid : S-1-5-21-2662603575-1345047739-3284616891-1114 attributes : 0x00000007 (7) 1: SE_GROUP_MANDATORY 1: SE_GROUP_ENABLED_BY_DEFAULT 1: SE_GROUP_ENABLED 0: SE_GROUP_OWNER 0: SE_GROUP_USE_FOR_DENY_ONLY 0: SE_GROUP_RESOURCE 0x00: SE_GROUP_LOGON_ID (0) res_group_dom_sid : NULL res_groups: struct samr_RidWithAttributeArray count : 0x00000000 (0) rids : NULL _pad : 0x00000000 (0) buffers: struct PAC_BUFFER type : PAC_TYPE_LOGON_NAME (10) _ndr_size : 0x00000024 (36) info : * info : union PAC_INFO(case 10) logon_name: struct PAC_LOGON_NAME logon_time : Wed Oct 2 10:17:42 PM 2013 CEST size : 0x001a (26) account_name : 'Administrator' _pad : 0x00000000 (0) buffers: struct PAC_BUFFER type : PAC_TYPE_UNKNOWN_12 (12) _ndr_size : 0x00000058 (88) info : * info : union PAC_INFO(case 12) unknown: struct DATA_BLOB_REM remaining : DATA_BLOB length=88 [0000] 30 00 10 00 14 00 40 00 01 00 00 00 00 00 00 00 0..... at . ........ [0010] 41 00 64 00 6D 00 69 00 6E 00 69 00 73 00 74 00 A.d.m.i. n.i.s.t. [0020] 72 00 61 00 74 00 6F 00 72 00 40 00 73 00 75 00 r.a.t.o. r. at .s.u. [0030] 62 00 64 00 6F 00 6D 00 2E 00 73 00 75 00 62 00 b.d.o.m. ..s.u.b. [0040] 53 00 55 00 42 00 44 00 4F 00 4D 00 2E 00 53 00 S.U.B.D. O.M...S. [0050] 55 00 42 00 00 00 00 00 U.B..... _pad : 0x00000000 (0) buffers: struct PAC_BUFFER type : PAC_TYPE_SRV_CHECKSUM (6) _ndr_size : 0x00000010 (16) info : * info : union PAC_INFO(case 6) srv_cksum: struct PAC_SIGNATURE_DATA type : 0x00000010 (16) signature : DATA_BLOB length=12 [0000] 99 ED 78 89 9B D2 42 7B 8B 14 1C B3 .x..B{ ... _pad : 0x00000000 (0) buffers: struct PAC_BUFFER type : PAC_TYPE_KDC_CHECKSUM (7) _ndr_size : 0x00000010 (16) info : * info : union PAC_INFO(case 7) kdc_cksum: struct PAC_SIGNATURE_DATA type : 0x00000010 (16) signature : DATA_BLOB length=12 [0000] E7 CE 8A 2E 26 38 1F 54 13 7B 5E AE ..&8.T .{^ _pad : 0x00000000 (0) > >2.) The trust-fetch-domains has somewhat confusing options: > >[tbabej at vm-147 labtool]$ ipa trust-fetch-domains >tbad.idm.lab.eng.brq.redhat.com --help >Usage: ipa [global-options] trust-fetch-domains REALM [options] > >Refresh list of the domains associated with the trust >Options: > -h, --help show this help message and exit > --rights Display the access rights of this entry (requires --all). See > ipa man page for details. > --all Retrieve and print all attributes from the server. Affects > command output. > --raw Print entries as stored on the server. Only affects output > format. Yep, I'll switch it to use the same LDAPQuery class as trustdomain-enable/disable use now. -- / Alexander Bokovoy From sbose at redhat.com Wed Oct 2 21:04:53 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 2 Oct 2013 23:04:53 +0200 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <524C8299.9040801@redhat.com> References: <20130923081509.GR4216@redhat.com> <20130923141841.GS4216@redhat.com> <20130923150422.GT4216@redhat.com> <20130927125308.GD4216@redhat.com> <20130927163121.GM10000@localhost.localdomain> <20130928200134.GF4216@redhat.com> <52495AEB.7000204@redhat.com> <20130930123143.GJ4216@redhat.com> <20131001151509.GP4216@redhat.com> <524C8299.9040801@redhat.com> Message-ID: <20131002210453.GF10000@localhost.localdomain> On Wed, Oct 02, 2013 at 10:31:21PM +0200, Tomas Babej wrote: > On 10/01/2013 05:15 PM, Alexander Bokovoy wrote: > >On Mon, 30 Sep 2013, Alexander Bokovoy wrote: > >>On Mon, 30 Sep 2013, Tomas Babej wrote: > >>>On 09/28/2013 10:01 PM, Alexander Bokovoy wrote: > >>>>On Fri, 27 Sep 2013, Sumit Bose wrote: > >>>>>On Fri, Sep 27, 2013 at 03:53:08PM +0300, Alexander Bokovoy wrote: > >>>>>>On Mon, 23 Sep 2013, Alexander Bokovoy wrote: > >>>>>>>On Mon, 23 Sep 2013, Alexander Bokovoy wrote: > >>>>>>>>On Mon, 23 Sep 2013, Alexander Bokovoy wrote: > >>>>>>>>>On Mon, 23 Sep 2013, Martin Kosek wrote: > >>>>>>>>>>>>However, we don't have trust type available so it needs > >>>>>>to discovered > >>>>>>>>>>>>every time. This doesn't play well with the framework, it > >>>>>>is simply not > >>>>>>>>>>>>expecting dynamic containers. > >>>>>>>>>>> > >>>>>>>>>>>This doesn't sound like a big obstacle to me. Right now > >>>>>>the trust_type lookup > >>>>>>>>>>>is done in trust_show.execute() for some reason, which is > >>>>>>not the best place to > >>>>>>>>>>>do it IMHO. Doing it in trust.get_dn() instead should > >>>>>>simplify things enough to > >>>>>>>>>>>make parent_object work. > >>>>>>>>>> > >>>>>>>>>>Yup, get_dn() is the method where object DN lookup should > >>>>>>be done. See for > >>>>>>>>>>example host.py plugin get_dn method, we also do a dynamic > >>>>>>lookup for correct > >>>>>>>>>>host name. > >>>>>>>>>I'll see if that would work. > >>>>>>>>> > >>>>>>>>>>the best way to implement dynamic DN gathering is the > >>>>>>get_dn() method. That > >>>>>>>>>>way, it could be implemented in one place and all commands > >>>>>>could take advantage > >>>>>>>>>>of it instead of re-implementing it several times in > >>>>>>pre_callback - this is > >>>>>>>>>>just hackish. > >>>>>>>>>I'd suggest you look into the code. The commands use > >>>>>>pre_callback for a > >>>>>>>>>different purpose than implementing dynamic DN gathering. > >>>>>>>>> > >>>>>>>>>>I think it would have been very useful to have a design > >>>>>>page before sending a > >>>>>>>>>>patch. It is then easier to make design decisions without > >>>>>>having to dig into > >>>>>>>>>>the patch. > >>>>>>>>>The design page is there for long time: > >>>>>>>>>http://www.freeipa.org/page/V3/Transitive_Trusts > >>>>>>>>Ok, here is new version of the patch and updated > >>>>>>>>version of my 0117 > >>>>>>>>patch as Sumit noticed I've sent wrong version. > >>>>>>>Ok, here is updated 0118 which fixes API.txt change for > >>>>>>trustdomain_add > >>>>>>>-- I renamed trustdomain_create to trustdomain_add but > >>>>>>>forgot to rerun > >>>>>>>makeapi. > >>>>>>New edition attached for all subdomain-related patches: > >>>>> > >>>>>I did some tests and all is working as expected. > >>>>> > >>>>>> > >>>>>>freeipa-abbra-0117-ipaserver-dcerpc.py-populate-forest-trust-informatio-3.patch > >>>>>> > >>>>>> > >>>>>>Use realmdomains to report name suffix routes at the > >>>>>>time we establish trust > >>>>>> > >>>>>>freeipa-abbra-0118-trusts-support-subdomains-in-a-forest-3.patch > >>>>>>Introduce trustdomain-* commands to fetch list of domains associated > >>>>>>with a forest trust and allow filtering them off > >>>>> > >>>>>We talked on irc that ipaNTSupportedEncryptionTypes in the filter > >>>>>for the trusted domains should be replace by a different attribute. > >>>>>Because of an error in ipasam the > >>>>>ipaNTSupportedEncryptionTypes is only > >>>>>set in recent versions and might not be present in the > >>>>>directory trees of > >>>>>older versions. > >>>>Fixed in the attached patch 0118 version 4. > >>>> > >>>>Also attached first attempt to implement transiting through trusted > >>>>domains, as patch 0123. In this patch we grant transition only if all > >>>>three realms (client, transited realm, and server realm) match any of > >>>>our trusted domains and our domain. This is probably a bit > >>>>wider but it > >>>>worked for me bidirectionally, from a child domain to a > >>>>service in IPA, > >>>>and from IPA realm to a service in a child domain of a forest trust. > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>Freeipa-devel mailing list > >>>>Freeipa-devel at redhat.com > >>>>https://www.redhat.com/mailman/listinfo/freeipa-devel > >>> > >>>Hi, > >>> > >>>here are my comments: > >>> > >>>*PATCH 117* > >>> > >>>+ def get_realmdomains(self): > >>>+ """ > >>>+ Generate list of records for forest trust information about > >>>+ our realm domains. Note that the list generated currently > >>>+ includes only top level domains, no exclusion > >>>domains, and no TDO objects > >>>+ as we handle the latter in a separte way > >>>+ """ > >>> > >>>A nitpick typo: separte -> separate. > >>Fixed. > >> > >>> > >>>Also, there's trailing whitespace in the patch: > >>> > >>>Applying: ipaserver/dcerpc.py: populate forest trust > >>>information using realmdomains > >>>/home/tbabej/dev/freeipa/.git/rebase-apply/patch:62: trailing > >>>whitespace. > >>> Only top level name and top level name exclusions are > >>>handled here. > >>>/home/tbabej/dev/freeipa/.git/rebase-apply/patch:174: trailing > >>>whitespace. > >>> > >>>warning: 2 lines add whitespace errors. > >>Fixed. > >> > >>> > >>> > >>>*PATCH 119* > >>> > >>>We also need to change the frontend tests that cover this > >>>functionality: > >>> > >>>====================================================================== > >>>FAIL: Test the ``ipalib.frontend.Command.args`` instance attribute. > >>>---------------------------------------------------------------------- > >>>Traceback (most recent call last): > >>>File "/usr/lib/python2.7/site-packages/nose/case.py", line > >>>197, in runTest > >>> self.test(*self.arg) > >>>File > >>>"/home/tbabej/dev/freeipa/ipatests/test_ipalib/test_frontend.py", > >>>line 283, in test_args > >>> assert str(e) == 'arg2: required argument after optional' > >>>AssertionError > >>> > >>>See ipatests/test_ipalib/test_frontend.py, line 281: > >>> > >>> # Test ValueError, required after optional: > >>> e = raises(ValueError, self.get_instance, args=('arg1?', 'arg2')) > >>> assert str(e) == 'arg2: required argument after optional' > >>Ok, will fix. This patch is not essential, of course, so we can decide > >>what to do with it later. > >> > >>> > >>> > >>>*PATCH 120* > >>> > >>>When I try to add a trust, I get internal error: > >>> > >>>echo $AD_PASSWORD | ipa trust-add --type=ad $AD_DOMAIN --admin > >>>Administrator --password > >>> > >>>[Wed Sep 25 10:28:53.978664 2013] [:error] [pid 7905] ipa: > >>>ERROR: non-public: IndexError: tuple index out of range > >>>[Wed Sep 25 10:28:53.978702 2013] [:error] [pid 7905] > >>>Traceback (most recent call last): > >>>[Wed Sep 25 10:28:53.978708 2013] [:error] [pid 7905] File > >>>"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", > >>>line 333, in wsgi_execute > >>>[Wed Sep 25 10:28:53.978713 2013] [:error] [pid 7905] result = > >>>self.Command[name](*args, **options) > >>>[Wed Sep 25 10:28:53.978720 2013] [:error] [pid 7905] File > >>>"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line > >>>436, in __call__ > >>>[Wed Sep 25 10:28:53.978725 2013] [:error] [pid 7905] ret > >>>= self.run(*args, **options) > >>>[Wed Sep 25 10:28:53.978730 2013] [:error] [pid 7905] File > >>>"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line > >>>755, in run > >>>[Wed Sep 25 10:28:53.978734 2013] [:error] [pid 7905] result = > >>>self.execute(*args, **options) > >>>[Wed Sep 25 10:28:53.978739 2013] [:error] [pid 7905] File > >>>"/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py", > >>>line 338, in execute > >>>[Wed Sep 25 10:28:53.978744 2013] [:error] [pid 7905] > >>>self.add_range(range_name, dom_sid, *keys, **options) > >>>[Wed Sep 25 10:28:53.978748 2013] [:error] [pid 7905] File > >>>"/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py", > >>>line 549, in add_range > >>>[Wed Sep 25 10:28:53.978755 2013] [:error] [pid 7905] quiet=True) > >>>[Wed Sep 25 10:28:53.978759 2013] [:error] [pid 7905] File > >>>"/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line > >>>507, in search_in_dc > >>>[Wed Sep 25 10:28:53.978764 2013] [:error] [pid 7905] info > >>>= self.__retrieve_trusted_domain_gc_list(domain) > >>>[Wed Sep 25 10:28:53.978769 2013] [:error] [pid 7905] File > >>>"/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line > >>>595, in __retrieve_trusted_domain_gc_list > >>>[Wed Sep 25 10:28:53.978774 2013] [:error] [pid 7905] > >>>info['auth'] = self._domains[domain][2] > >>>[Wed Sep 25 10:28:53.978778 2013] [:error] [pid 7905] > >>>IndexError: tuple index out of range > >>>[Wed Sep 25 10:28:53.979248 2013] [:error] [pid 7905] ipa: > >>>INFO: admin at DOM006.TBAD.IPA.COM: trust_add(u'tbad.ipa.com', > >>>trust_type=u'ad', realm_admin=u'Administrator', > >>>realm_passwd=u'********', all=False, raw=False, > >>>version=u'2.65'): IndexError > >>> > >>>I think we need to do the following changes here: > >>> > >>>diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py > >>>index fa5c449..4ac0a5f 100644 > >>>--- a/ipaserver/dcerpc.py > >>>+++ b/ipaserver/dcerpc.py > >>>@@ -565,7 +565,6 @@ class DomainValidator(object): > >>> Returns dictionary with following keys > >>> name -- NetBIOS name of the trusted domain > >>> dns_domain -- DNS name of the trusted domain > >>>- auth -- encrypted credentials for trusted > >>>domain account > >>> gc -- array of tuples (server, port) for > >>>Global Catalog > >>> """ > >>> if domain in self._info: > >>>@@ -592,7 +591,6 @@ class DomainValidator(object): > >>> self._domains = self.get_trusted_domains() > >>> > >>> info = dict() > >>>- info['auth'] = self._domains[domain][2] > >>> servers = [] > >>> > >>> if result: > >>> > >>>After applying this fix, I get: > >>> > >>>tbabej at vm-006 freeipa]$ echo $AD_PASSWORD | ipa trust-add > >>>--type=ad $AD_DOMAIN --admin Administrator --password > >>>ipa: ERROR: CIFS server communication error: code "-1073741811", > >>> message "Unexpected information received" > >>>(both may be "None") > >>> > >>>I was unable to track this one down in a reasonable timeframe, > >>>I suggest we continue on IRC. > >>I've fixed this. At the time we establish trust, there could be a race > >>condition when cross-realm TGT is not yet ready so we cannot rely on it > >>when fetching domains. As we have administrator's credentials here, I've > >>added use of them in addition to Kerberos. > >> > >> > >>I'll send new patchset shortly. > >New patchset is attached. > > > >1. Added test update for ipalib/frontend.py changes > >2. Used LDAPQuery as base for trustdomain_enable|disable commands as > > suggested by Honza. > >3. Fixed issues with removal of trust account password authentication > >4. Added support to use AD administrator credentials when fetching > > subdomains information when we establish trust as Kerberos will not > > be available for cross-realm operations yet. > >5. Patch 0123 is not part of the patchset and should not be committed, > > we will discuss exact semantics of transition checks with MIT > > Kerberos upstream first. > >6. Fixed few error paths and dead-end cases like attempt to disable root > > domain of the trust (renders trust dead) or enabling it (it is always > > enabled). > >7. Made clear that deleting root domain of the trust is not possible, > > use trust-del instead. > >8. Removed whitespaces where saw. > > > > > > > > Thanks! > > This fixes most of the issues I had. > > To summarize, two issues from the today's functional testing we > already discussed on IRC: > > 1.) The blacklisting for the child domain does not work (it works > fine for the root domain). > Thus, ipa trustdomain-disable for the child domain does not reject > access to the IPA's resources: > > [tbabej at vm-147 labtool]$ ipa trustdomain-disable > tbad.idm.lab.eng.brq.redhat.com > child.tbad.idm.lab.eng.brq.redhat.com > ------------------------------------------------------------------------------------------------------------------------------------ > Domain child.tbad.idm.lab.eng.brq.redhat.com of trust > tbad.idm.lab.eng.brq.redhat.com is already not allowed to access IPA > resources > ------------------------------------------------------------------------------------------------------------------------------------ > [tbabej at vm-147 labtool]$ kdestroy > [tbabej at vm-147 labtool]$ kvno -S ldap `hostname` > kvno: Credentials cache file '/run/user/536/krb5cc/tkt1sLaOS' not > found while getting client principal name > [tbabej at vm-147 labtool]$ kinit > Administrator at CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM > Password for Administrator at CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM: > [tbabej at vm-147 labtool]$ klist > Ticket cache: DIR::/run/user/536/krb5cc/tktS7Bkhj > Default principal: Administrator at CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM > > Valid starting Expires Service principal > 10/02/2013 21:28:52 10/03/2013 07:28:52 krbtgt/CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM at CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM > renew until 10/03/2013 21:28:46 > [tbabej at vm-147 labtool]$ kvno -S ldap `hostname` > ldap/vm-147.dom147.tbad.idm.lab.eng.brq.redhat.com at DOM147.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM: > kvno = 2 > > We should have been denied access here. > > 2.) The trust-fetch-domains has somewhat confusing options: > > [tbabej at vm-147 labtool]$ ipa trust-fetch-domains > tbad.idm.lab.eng.brq.redhat.com --help > Usage: ipa [global-options] trust-fetch-domains REALM [options] > > Refresh list of the domains associated with the trust > Options: > -h, --help show this help message and exit > --rights Display the access rights of this entry (requires --all). See > ipa man page for details. > --all Retrieve and print all attributes from the server. Affects > command output. > --raw Print entries as stored on the server. Only affects output > format. > > > Please note that I did not test with more than 1 subdomain, since I > do not have more ADs available. > I have done some testing as well and the patches are working as expected except the trustdomain-disable issue Tomas mentioned. But I think it would be sufficient to add a comment to the release notes and fix this with the next release to not delay this release anymore. The patches are also working for trusts which were added with older releases. So ACK from my side for the functional part. bye, Sumit > -- > Tomas Babej > Associate Software Engeneer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Thu Oct 3 07:14:49 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 03 Oct 2013 09:14:49 +0200 Subject: [Freeipa-devel] [PATCH] 460 Fix enablement of automount map type selector In-Reply-To: <52496FB6.5080704@redhat.com> References: <52496FB6.5080704@redhat.com> Message-ID: <524D1969.2040601@redhat.com> On 09/30/2013 02:33 PM, Petr Vobornik wrote: > Map type radio used old way of defining that its value should not be used in > add command. Recent patch related to 'enable' attribute hardened/fixed the > behavior of radio widgets so they are disabled in UI as well when > enabled==false. Automount did not reflect this change. > > https://fedorahosted.org/freeipa/ticket/3954 > ACK! Works for me. Pushed to master, ipa-3-3. Martin From stefw at redhat.com Thu Oct 3 07:41:47 2013 From: stefw at redhat.com (Stef Walter) Date: Thu, 03 Oct 2013 09:41:47 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <1052675559.288505.1380712236557.JavaMail.root@redhat.com> References: <52161568.7060702@redhat.com> <5232D20C.9050204@redhat.com> <5232D290.40504@redhat.com> <5232D563.3050500@redhat.com> <524AA4A0.6040801@redhat.com> <851875259.658384.1380657433774.JavaMail.root@redhat.com> <524B2BBD.20104@redhat.com> <524BEF8A.5000309@redhat.com> <1052675559.288505.1380712236557.JavaMail.root@redhat.com> Message-ID: <524D1FBB.90008@redhat.com> On 02.10.2013 13:10, Simo Sorce wrote: > > > ----- Original Message ----- >> On 1.10.2013 22:08, Rob Crittenden wrote: >>> Simo Sorce wrote: >>>> ----- Original Message ----- >>>>> On 13.9.2013 11:05, Jan Cholasta wrote: >>>>>> On 13.9.2013 10:53, Martin Kosek wrote: >>>>>>> On 09/13/2013 10:51 AM, Jan Cholasta wrote: >>>>>>>> On 5.9.2013 10:28, Jan Cholasta wrote: >>>>>>>>> On 3.9.2013 18:16, Dmitri Pal wrote: >>>>>>>>>> On 09/02/2013 04:49 AM, Petr Spacek wrote: >>>>>>>>>>> It reminds me problems with key-rotation for DNSSEC. >>>>>>>>>>> >>>>>>>>>>> Could we find common problems and use the same/similar solution >>>>>>>>>>> for >>>>>>>>>>> both problems? >>>>>>>>>>> >>>>>>>>>>> An extension for certmonger? Oddjob? Or a completely new daemon? >>>>>>>>>>> >>>>>>>>>> Certmonger already has a way to: >>>>>>>>>> 1) Check things periodically >>>>>>>>>> 2) Hand certs in different places >>>>>>>>>> 3) Run post op scripts >>>>>>>>>> >>>>>>>>>> IMO it is a good candidate but I would leave it to Nalin to >>>>>>>>>> chime in. >>>>>>>>>> >>>>>>>>> >>>>>>>>> I would expect more things that require periodic checking on clients >>>>>>>>> beyond certificates to come in the future, so I'm not sure if doing >>>>>>>>> this >>>>>>>>> in certmonger is the right thing to do. Also, SSSD already does a >>>>>>>>> similar thing for realm domains, right? >>>>>>> >>>>>>> Are you suggesting extending SSSD to handle that? >>>>>> >>>>>> Yes. >>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>> >>>>>>>> So, does anyone have any strong opinions on this? >>>>>>> >>>>>>> Not at this point. BTW, is there any reason why we cannot go the >>>>>>> simple way and >>>>>>> just utilize cron and a script? Previously we just dropped conf to >>>>>>> /etc/cron.d >>>>>>> for ipa-compliance script and it worked quite well. >>>>>> >>>>>> Hmm, that's so simple it might just work. At least until there is a >>>>>> better way. >>>>> >>>>> I have been thinking about this for some time now and came up with this >>>>> solution: >>>>> >>>>> Write a library implementing the PKCS#11 API (Cryptoki), which would >>>>> provide the shared CA certificates and associated information >>>>> (nicknames, trust flags). The library would get the certificates from >>>>> SSSD, which in turn would get them from IPA (and do the usual stuff like >>>>> caching). >>>>> >>>>> This library could then be used by IPA NSS databases as a source of >>>>> trust information for IPA services (see modutil). It could also be used >>>>> by p11-glue to provide the trust information to the rest of the system. >>>>> >>>>> Pros: >>>>> * Automatic support for getting trust information stored in IPA in >>>>> all the applications that understand PKCS#11. >>>>> * Certificates are fetched from IPA on-demand, not periodically like >>>>> in the previous solutions. >>>>> >>>>> Cons: >>>>> * Complexity of implementation? (I don't know about this one, I >>>>> briefly looked at the source code of the p11-kit PKCS#11 module and it >>>>> looked manageable to me.) >>>>> >>>>> Does this sound reasonable? >>>> >>>> >>>> Sounds reasonable to me, however I assume you will do some caching, >>>> both to avoid lenghty waits and to handle offline cases, so I'd like >>>> to know more how/when you are going to use the caches vs fetching the >>>> cert chains from the server. >> >> I was thinking about using algorithm like this when SSSD receives the >> request: >> >> if certs in cache: >> if cache last update time + delta < now: >> if certs were update on server: # lastUSN check >> remove certs from cache >> else: >> cache last update time = now >> if certs not in cache: >> get certs from server >> store certs in cache >> cache last update time = now >> return certs in cache >> >> The delta would be a configurable option, defaulting to some reasonable >> value (1 hour? more? less?) >> >>> >>> For on-demand, what are we talking about, fetching the cert when the >>> module is loaded? Or whenever someone wants to use (e.g. validate) the >>> cert? >> >> Something in between - the module would request the certificates from >> SSSD when a PKCS#11 session is opened and keep them in memory until the >> session is closed. The point is to always have the same data between >> PKCS#11 object management calls. >> >>> >>> How often will this cert change, after all? >> >> Not often. Why? >> >>> >>> What would the load be like? Is it fatal if the cert can't be obtained? >> >> The module could either return an error to the user when the certs can't >> be obtained, or return whatever is in the cache. I'm not sure which is >> better, but I'm leaning towards returning whatever is in the cache, >> since this must work even when the client system is offline. > > I think the cache should just be ca.crt files though, in this case, not the > ldb modules cache. As some people wipe it out for various reasons. > The main issue here is a chicken-egg issue if you are using LDAP(S) to > connect to the server and you ned the CA cert to validate the server cert. > You do not want to lock yourself out by wiping valid ca certs. Then you can just add them to the p11-kit-trust module using the trust tool (or I could build an API for that): # trust anchor --store /path/to/ca.crt By the way, even with PKCS#11, just having the certificates in place, it's also necessary to add the appropriate trust flags and so on so that these are trusted as anchors. The above also handles callers that don't yet support PKCS#11 for accessing trusted anchors. Cheers, Stef From sbose at redhat.com Thu Oct 3 08:22:31 2013 From: sbose at redhat.com (Sumit Bose) Date: Thu, 3 Oct 2013 10:22:31 +0200 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <20131002210135.GU4216@redhat.com> References: <20130923141841.GS4216@redhat.com> <20130923150422.GT4216@redhat.com> <20130927125308.GD4216@redhat.com> <20130927163121.GM10000@localhost.localdomain> <20130928200134.GF4216@redhat.com> <52495AEB.7000204@redhat.com> <20130930123143.GJ4216@redhat.com> <20131001151509.GP4216@redhat.com> <524C8299.9040801@redhat.com> <20131002210135.GU4216@redhat.com> Message-ID: <20131003082231.GG10000@localhost.localdomain> On Thu, Oct 03, 2013 at 12:01:35AM +0300, Alexander Bokovoy wrote: > On Wed, 02 Oct 2013, Tomas Babej wrote: > >>>I'll send new patchset shortly. > >>New patchset is attached. > >> > >>1. Added test update for ipalib/frontend.py changes > >>2. Used LDAPQuery as base for trustdomain_enable|disable commands as > >> suggested by Honza. > >>3. Fixed issues with removal of trust account password authentication > >>4. Added support to use AD administrator credentials when fetching > >> subdomains information when we establish trust as Kerberos will not > >> be available for cross-realm operations yet. > >>5. Patch 0123 is not part of the patchset and should not be committed, > >> we will discuss exact semantics of transition checks with MIT > >> Kerberos upstream first. > >>6. Fixed few error paths and dead-end cases like attempt to disable root > >> domain of the trust (renders trust dead) or enabling it (it is always > >> enabled). > >>7. Made clear that deleting root domain of the trust is not possible, > >> use trust-del instead. > >>8. Removed whitespaces where saw. > >> > >> > >> > > > >Thanks! > > > >This fixes most of the issues I had. > > > >To summarize, two issues from the today's functional testing we > >already discussed on IRC: > > > >1.) The blacklisting for the child domain does not work (it works > >fine for the root domain). > >Thus, ipa trustdomain-disable for the child domain does not reject > >access to the IPA's resources: > > > >[tbabej at vm-147 labtool]$ ipa trustdomain-disable > >tbad.idm.lab.eng.brq.redhat.com > >child.tbad.idm.lab.eng.brq.redhat.com > >------------------------------------------------------------------------------------------------------------------------------------ > >Domain child.tbad.idm.lab.eng.brq.redhat.com of trust > >tbad.idm.lab.eng.brq.redhat.com is already not allowed to access > >IPA resources > >------------------------------------------------------------------------------------------------------------------------------------ > >[tbabej at vm-147 labtool]$ kdestroy > >[tbabej at vm-147 labtool]$ kvno -S ldap `hostname` > >kvno: Credentials cache file '/run/user/536/krb5cc/tkt1sLaOS' not > >found while getting client principal name > >[tbabej at vm-147 labtool]$ kinit > >Administrator at CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM > >Password for Administrator at CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM: > >[tbabej at vm-147 labtool]$ klist > >Ticket cache: DIR::/run/user/536/krb5cc/tktS7Bkhj > >Default principal: Administrator at CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM > > > >Valid starting Expires Service principal > >10/02/2013 21:28:52 10/03/2013 07:28:52 krbtgt/CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM at CHILD.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM > > renew until 10/03/2013 21:28:46 > >[tbabej at vm-147 labtool]$ kvno -S ldap `hostname` > >ldap/vm-147.dom147.tbad.idm.lab.eng.brq.redhat.com at DOM147.TBAD.IDM.LAB.ENG.BRQ.REDHAT.COM: > >kvno = 2 > > > >We should have been denied access here. > Right. This is *very good* finding. Since we put information about black > list only to the root level domain of the trust, we need to reference > the root level domain when checking a subdomain. We don't do that right > now and it is needed also in Sumit's patches so I'll work on merging > them. > > Here is my plan: make a helper that identifies root domain for the > trusted domain (Sumit's code already has this), fetch root domain of > the trust > and validate this domain's SID against black list associated with the > root domain in filter_logon_info(). Since it looks like the forest root<->member domain relationship is needed in various places I wonder if it would be easier in the long run to add this explicitly to the member domain objects e.g. with the help of a new objectclass ipaNTForestMember with a mandatory attribute ipaNTForest or ipaNTMemberOfForest? I think this would also help to make the handling of member domains in transitively trusted forests easier. bye, Sumit From mkosek at redhat.com Thu Oct 3 08:48:24 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 03 Oct 2013 10:48:24 +0200 Subject: [Freeipa-devel] [PATCH] 0067 Use fqdn when creating msdcs SRV records In-Reply-To: <524C3AB1.7060100@redhat.com> References: <5239D7E5.2090401@redhat.com> <524C38FD.1040506@redhat.com> <524C3AB1.7060100@redhat.com> Message-ID: <524D2F58.7030107@redhat.com> On 10/02/2013 05:24 PM, Martin Kosek wrote: > On 10/02/2013 05:17 PM, Petr Vobornik wrote: >> On 09/18/2013 06:42 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3908. >>> >>> >> >> The patch does what it advertises - it uses fqdn every time for mcsdcs SRV >> records. >> >> It's not consistent with other DNS SRV records, where fqdn is used only when >> IPA server is not in the IPA DNS domain. >> >> bindinstance.py uses this code to address the same issue: >> >> host, zone = fqdn.split(".", 1) >> >> if normalize_zone(zone) == normalize_zone(self.domain): >> host_in_rr = host >> else: >> host_in_rr = normalize_zone(fqdn) >> >> Alexander suggests the same solution >> > > Yes, I think we should be fixed. > > When I was looking at the AD SRV records using this patch, it just look > confusing - some records relative, some were absolute. This could bite us later > when for example removing or changing these records. > > Martin > Given we need to fix that soon and Ana is away ATM, I am sending my candidate patch - worked for me. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-422-use-fqdn-when-creating-msdcs-srv-records.patch Type: text/x-patch Size: 2088 bytes Desc: not available URL: From jcholast at redhat.com Thu Oct 3 09:37:36 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 03 Oct 2013 11:37:36 +0200 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <20131002210135.GU4216@redhat.com> References: <20130923081509.GR4216@redhat.com> <20130923141841.GS4216@redhat.com> <20130923150422.GT4216@redhat.com> <20130927125308.GD4216@redhat.com> <20130927163121.GM10000@localhost.localdomain> <20130928200134.GF4216@redhat.com> <52495AEB.7000204@redhat.com> <20130930123143.GJ4216@redhat.com> <20131001151509.GP4216@redhat.com> <524C8299.9040801@redhat.com> <20131002210135.GU4216@redhat.com> Message-ID: <524D3AE0.6070702@redhat.com> On 2.10.2013 23:01, Alexander Bokovoy wrote: > On Wed, 02 Oct 2013, Tomas Babej wrote: >> 2.) The trust-fetch-domains has somewhat confusing options: >> >> [tbabej at vm-147 labtool]$ ipa trust-fetch-domains >> tbad.idm.lab.eng.brq.redhat.com --help >> Usage: ipa [global-options] trust-fetch-domains REALM [options] >> >> Refresh list of the domains associated with the trust >> Options: >> -h, --help show this help message and exit >> --rights Display the access rights of this entry (requires --all). >> See >> ipa man page for details. >> --all Retrieve and print all attributes from the server. Affects >> command output. >> --raw Print entries as stored on the server. Only affects output >> format. > Yep, I'll switch it to use the same LDAPQuery class as > trustdomain-enable/disable use now. > Since trust-fetch-domains returns a list of entries, I think --all and --raw should stay, to be consistent with other commands which return entries. Just make sure they work by passing them through to trustdomain_add. Honza -- Jan Cholasta From mkosek at redhat.com Thu Oct 3 10:03:01 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 03 Oct 2013 12:03:01 +0200 Subject: [Freeipa-devel] [PATCH 107] Do not add trust to AD in case of IPA realm-domain mismatch In-Reply-To: <523ACA85.5050808@redhat.com> References: <523ACA85.5050808@redhat.com> Message-ID: <524D40D5.5060604@redhat.com> On 09/19/2013 11:57 AM, Tomas Babej wrote: > Hi, > > Make sure that trust-add command fails when admin attempts > to add an Active Directory trust when the realm name and > the domain name of the IPA server do not match. > > https://fedorahosted.org/freeipa/ticket/3923 ACK. Works for me. I just removed the trailing dot in the error message. Pushed to master, ipa-3-3. Martin From mkosek at redhat.com Thu Oct 3 10:03:52 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 03 Oct 2013 12:03:52 +0200 Subject: [Freeipa-devel] [PATCH 108] Warn user about realm-domain mismatch in install scripts In-Reply-To: <523ACAC8.2030707@redhat.com> References: <523ACAC8.2030707@redhat.com> Message-ID: <524D4108.9000406@redhat.com> On 09/19/2013 11:58 AM, Tomas Babej wrote: > Hi, > > If the IPA server is setup with non-matching domain and realm > names, it will not be able to estabilish trust with the Active > Directory. > > Adds warnings to the ipa-server-install and warning to the > ipa-adtrust-install (which has to be confirmed). > > Man pages for the ipa-server-install and ipa-adtrust-install were > updated with the relevant notes. > > https://fedorahosted.org/freeipa/ticket/3924 ACK, works for me. I just wrapped the long warning message so that it fits the 80 char limit. Pushed to master, ipa-3-3. Martin From mbasti at redhat.com Thu Oct 3 10:12:13 2013 From: mbasti at redhat.com (Martin Basti) Date: Thu, 03 Oct 2013 12:12:13 +0200 Subject: [Freeipa-devel] [DOC] Chapter 4 text In-Reply-To: <524ADC2E.2040805@redhat.com> References: <1379517057.9269.7.camel@unused-4-145.brq.redhat.com> <1380297179.2116.20.camel@unused-4-145.brq.redhat.com> <524ADC2E.2040805@redhat.com> Message-ID: <1380795133.2201.0.camel@unused-4-145.brq.redhat.com> On Tue, 2013-10-01 at 16:29 +0200, Petr Vobornik wrote: > On 09/27/2013 05:52 PM, Martin Basti wrote: > > On Wed, 2013-09-18 at 17:10 +0200, Martin Basti wrote: > >> Patch fix examples in chapter 4, adds new examples, fix out of date > >> information. > >> > >> NOTE: Patch doesn't cover part 4.3 Logging with web UI > > > Updated patch > > > > NACK > > >> 1. Table 4.1. Configuration Areas Per Tab is missing Trusts in IPA tab. This menu item is visible only if ipa-adtrust-install was run. > > > + Trusts (shown if AD-trust exists) > > ipa-adtrust-install was run != AD-trust exists > > From ipa-adtrust-install man page: > ipa-adtrust-install - Prepare an IPA server to be able to establish > trust relationships with AD domains Fixed Updated patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0004-3-chapter_4_text.patch Type: text/x-patch Size: 19682 bytes Desc: not available URL: From pvoborni at redhat.com Thu Oct 3 10:21:31 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 03 Oct 2013 12:21:31 +0200 Subject: [Freeipa-devel] [PATCH] 0067 Use fqdn when creating msdcs SRV records In-Reply-To: <524D2F58.7030107@redhat.com> References: <5239D7E5.2090401@redhat.com> <524C38FD.1040506@redhat.com> <524C3AB1.7060100@redhat.com> <524D2F58.7030107@redhat.com> Message-ID: <524D452B.4040208@redhat.com> On 10/03/2013 10:48 AM, Martin Kosek wrote: > On 10/02/2013 05:24 PM, Martin Kosek wrote: >> On 10/02/2013 05:17 PM, Petr Vobornik wrote: >>> On 09/18/2013 06:42 PM, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3908. >>>> >>>> >>> >>> The patch does what it advertises - it uses fqdn every time for mcsdcs SRV >>> records. >>> >>> It's not consistent with other DNS SRV records, where fqdn is used only when >>> IPA server is not in the IPA DNS domain. >>> >>> bindinstance.py uses this code to address the same issue: >>> >>> host, zone = fqdn.split(".", 1) >>> >>> if normalize_zone(zone) == normalize_zone(self.domain): >>> host_in_rr = host >>> else: >>> host_in_rr = normalize_zone(fqdn) >>> >>> Alexander suggests the same solution >>> >> >> Yes, I think we should be fixed. >> >> When I was looking at the AD SRV records using this patch, it just look >> confusing - some records relative, some were absolute. This could bite us later >> when for example removing or changing these records. >> >> Martin >> > > Given we need to fix that soon and Ana is away ATM, I am sending my candidate > patch - worked for me. > > Martin > ACK with a little change: - host_in_rr = self.fqdn.split(".")[0] + host_in_rr = host -- Petr Vobornik From mkosek at redhat.com Thu Oct 3 10:42:03 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 03 Oct 2013 12:42:03 +0200 Subject: [Freeipa-devel] [PATCHES] 0289-0302 Managed Read permissions In-Reply-To: <524C02C8.9030300@redhat.com> References: <524A8E59.8010605@redhat.com> <524BDBBA.6060506@redhat.com> <1135777364.287904.1380712053236.JavaMail.root@redhat.com> <524C02C8.9030300@redhat.com> Message-ID: <524D49FB.1040801@redhat.com> On 10/02/2013 01:26 PM, Petr Viktorin wrote: > On 10/02/2013 01:07 PM, Simo Sorce wrote: ... >>> To sum it up, I would rather not build our permission system on this group. >>> >>> I think we need top base our ACIs on LDAP bind targets ldap:///all and >>> ldap:///anyone to avoid performance issues and issues with ipausers not being >>> complete: >>> >>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Access_Control-Bind_Rules.html >>> >>> >>> I rather think we want to base the permissions on binddn. In the beginning, >>> there would be 3 types of permissions based on binddn: >>> >>> * groupdn based: standard permissions that can be assigned privileges >>> * ldap:///all permissions for all authenticated users. Cannot be assigned to >>> privileges (would not make sense) >>> * ldap:///anyone permissions for all, including anonymous users. Cannot be >>> assigned to privileges (would not make sense) >>> >>> Just few examples: >>> Read users - ldap:///anyone >>> Read groups - ldap:///anyone >>> Read sudo - ldap:///all >>> Read hbac - ldap:///all >>> ... >>> >>> Basing the permissions on these would allow us to get rid of all the awful >>> deny permissions. >>> >>> To make the permission Bind part more user friendly, there should be an >>> option >>> in permission-find and a switch in Web UI to e.g. list permissions by bind >>> type, i.e.: >>> - anonymous permissions >>> - authenticated users permissions >>> - group based permissions >>> >>> If use would want to e.g restrict sudo only to specified group, I would see >>> this workflow: >>> 1) Change bind type from "authenticated users" to "group based" >>> 2) Bind permission to chosen privilege >>> 3) ... >>> >>> And the opposite, if he wants to make reading more open: >>> 1) Unbind permission from privilege >>> 2) Change bind type to "authenticated users" or "anonymous" >>> >>> Makes sense? > > Yes. > >> I agree with Martin's comments too. >> >> Simo. > > We use privileges to group related permissions. For example an "Automount > Reader" privilege would contain "read automount keys" and "read automount maps" > permissions. > Wouldn't it make more sense (from the user's point of view at least) to have > this setting at the privilege level? > > The selfservice plugin does pretty much the same thing. Should we (aim to) move > selfservice functionality to this system? selfservice is not involved in privileges, neither is delegation, they are just handling raw ACIs in a custom manner. With ldap:///all and ldap:///anyone we could theoretically add new permission types and commands, like anonymousrbac-add or authenticatedrbac-add, but I think it would be best to keep them with standard permissions for several reasons: 1) Can use the new cool features you are adding to permission entries 2) With these ACIs, it makes sense to convert them to group-based permission and assign to a privilege (does not make that much sense with selfservice ACIs). AFAIU, we all agree on that and the only part is how the anonymous/authenticated-user permissions should be grouped. I still think that grouping them in privileges or roles does not make much sense - anonymous/authenticated-user ACIs do not need to be grouped anywhere, setting binddn is enough. It would be just our custom wiring in framework without much benefit to real functionality in LDAP. If you have a privilege "Automount Reader" with setting "Access: Anonymous: or similar, what if you add more non-anonymous permission to the privilege? What would happen then? Or what if you remove permission from the privilege, should it automagically become group-based ACI? Going with the workflow I described above seems to me as the most direct approach with keeping the anonymous/authenticated users/group based information in the single authoritative source - ACI/permission. > > And, since these permissions are longer be compatible with old versions, I > could move them out of $SUFFIX and onto the relevant containers. That should > also help performance. +1 Martin From pviktori at redhat.com Thu Oct 3 11:15:14 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 03 Oct 2013 13:15:14 +0200 Subject: [Freeipa-devel] [PATCHES] 170-171 Allow PKCS#12 files with empty password in install tools In-Reply-To: <5242A2D9.10304@redhat.com> References: <5242A2D9.10304@redhat.com> Message-ID: <524D51C2.6090006@redhat.com> On 09/25/2013 10:46 AM, Jan Cholasta wrote: > Hi, > > the attached patches fix . > > Honza > I'm still testing; it looks good except for unattended installs. With the attached fixup squashed in it works so far. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: fixup-Allow-PKCS-12-files-with-empty-password-in-ins.patch Type: text/x-patch Size: 1399 bytes Desc: not available URL: From mkosek at redhat.com Thu Oct 3 12:15:27 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 03 Oct 2013 14:15:27 +0200 Subject: [Freeipa-devel] [PATCH] 0067 Use fqdn when creating msdcs SRV records In-Reply-To: <524D452B.4040208@redhat.com> References: <5239D7E5.2090401@redhat.com> <524C38FD.1040506@redhat.com> <524C3AB1.7060100@redhat.com> <524D2F58.7030107@redhat.com> <524D452B.4040208@redhat.com> Message-ID: <524D5FDF.9060009@redhat.com> On 10/03/2013 12:21 PM, Petr Vobornik wrote: > On 10/03/2013 10:48 AM, Martin Kosek wrote: >> On 10/02/2013 05:24 PM, Martin Kosek wrote: >>> On 10/02/2013 05:17 PM, Petr Vobornik wrote: >>>> On 09/18/2013 06:42 PM, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3908. >>>>> >>>>> >>>> >>>> The patch does what it advertises - it uses fqdn every time for mcsdcs SRV >>>> records. >>>> >>>> It's not consistent with other DNS SRV records, where fqdn is used only when >>>> IPA server is not in the IPA DNS domain. >>>> >>>> bindinstance.py uses this code to address the same issue: >>>> >>>> host, zone = fqdn.split(".", 1) >>>> >>>> if normalize_zone(zone) == normalize_zone(self.domain): >>>> host_in_rr = host >>>> else: >>>> host_in_rr = normalize_zone(fqdn) >>>> >>>> Alexander suggests the same solution >>>> >>> >>> Yes, I think we should be fixed. >>> >>> When I was looking at the AD SRV records using this patch, it just look >>> confusing - some records relative, some were absolute. This could bite us later >>> when for example removing or changing these records. >>> >>> Martin >>> >> >> Given we need to fix that soon and Ana is away ATM, I am sending my candidate >> patch - worked for me. >> >> Martin >> > > ACK with a little change: > > - host_in_rr = self.fqdn.split(".")[0] > + host_in_rr = host > > Thanks. Fixed and pushed to master, ipa-3-3. Martin From abokovoy at redhat.com Thu Oct 3 13:10:52 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 3 Oct 2013 16:10:52 +0300 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <20131002210453.GF10000@localhost.localdomain> References: <20130923141841.GS4216@redhat.com> <20130923150422.GT4216@redhat.com> <20130927125308.GD4216@redhat.com> <20130927163121.GM10000@localhost.localdomain> <20130928200134.GF4216@redhat.com> <52495AEB.7000204@redhat.com> <20130930123143.GJ4216@redhat.com> <20131001151509.GP4216@redhat.com> <524C8299.9040801@redhat.com> <20131002210453.GF10000@localhost.localdomain> Message-ID: <20131003131052.GV4216@redhat.com> On Wed, 02 Oct 2013, Sumit Bose wrote: >> Please note that I did not test with more than 1 subdomain, since I >> do not have more ADs available. >> > >I have done some testing as well and the patches are working as expected >except the trustdomain-disable issue Tomas mentioned. But I think it >would be sufficient to add a comment to the release notes and fix this >with the next release to not delay this release anymore. > >The patches are also working for trusts which were added with older >releases. So ACK from my side for the functional part. New patchset is attached. I've fixed all outstanding issues and implemented proper SID filtering for subdomains. In addition, I've added MS-PAC cache eviction when we change blacklists from IPA side and forced removal of the domain from SID blacklist if the domain is being removed by trustdomain-del. -- / Alexander Bokovoy -------------- next part -------------- >From 96c77d1d0269a89ad91dfd73a13830366f5039a1 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 11 Sep 2013 21:34:55 +0300 Subject: [PATCH 1/8] ipaserver/dcerpc.py: populate forest trust information using realmdomains Use realmdomains information to prepopulate forest trust info. As result, all additional domains should now be enabled from the beginning, unless they really conflict with existing DNS domains on AD side. https://fedorahosted.org/freeipa/ticket/3919 --- ipaserver/dcerpc.py | 113 +++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 95 insertions(+), 18 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index bd8f5aa..cc9e7be 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -39,7 +39,7 @@ import uuid from samba import param from samba import credentials from samba.dcerpc import security, lsa, drsblobs, nbt, netlogon -from samba.ndr import ndr_pack +from samba.ndr import ndr_pack, ndr_print from samba import net import samba import random @@ -684,6 +684,12 @@ class DomainValidator(object): self._info[domain] = info return info +def string_to_array(what): + blob = [0] * len(what) + + for i in range(len(what)): + blob[i] = ord(what[i]) + return blob class TrustDomainInstance(object): @@ -698,6 +704,7 @@ class TrustDomainInstance(object): self._pipe = None self._policy_handle = None self.read_only = False + self.ftinfo_records = None def __gen_lsa_connection(self, binding): if self.creds is None: @@ -827,12 +834,6 @@ class TrustDomainInstance(object): def arcfour_encrypt(key, data): c = RC4.RC4(key) return c.update(data) - def string_to_array(what): - blob = [0] * len(what) - - for i in range(len(what)): - blob[i] = ord(what[i]) - return blob password_blob = string_to_array(trustdom_secret.encode('utf-16-le')) @@ -876,6 +877,53 @@ class TrustDomainInstance(object): self.auth_info = auth_info + def generate_ftinfo(self, another_domain): + """ + Generates TrustDomainInfoFullInfo2Internal structure + This structure allows to pass information about all domains associated + with the another domain's realm. + + Only top level name and top level name exclusions are handled here. + """ + if not another_domain.ftinfo_records: + return + + ftinfo_records = [] + info = lsa.ForestTrustInformation() + + for rec in another_domain.ftinfo_records: + record = lsa.ForestTrustRecord() + record.flags = 0 + record.time = rec['rec_time'] + record.type = rec['rec_type'] + record.forest_trust_data.string = rec['rec_name'] + ftinfo_records.append(record) + + info.count = len(ftinfo_records) + info.entries = ftinfo_records + return info + + def update_ftinfo(self, another_domain): + """ + Updates forest trust information in this forest corresponding + to the another domain's information. + """ + try: + if another_domain.ftinfo_records: + ftinfo = self.generate_ftinfo(another_domain) + # Set forest trust information -- we do it only against AD DC as + # smbd already has the information about itself + ldname = lsa.StringLarge() + ldname.string = another_domain.info['dns_domain'] + collision_info = self._pipe.lsaRSetForestTrustInformation(self._policy_handle, + ldname, + lsa.LSA_FOREST_TRUST_DOMAIN_INFO, + ftinfo, 0) + if collision_info: + root_logger.error("When setting forest trust information, got collision info back:\n%s" % (ndr_print(collision_info))) + except RuntimeError, e: + # We can ignore the error here -- setting up name suffix routes may fail + pass def establish_trust(self, another_domain, trustdom_secret): """ @@ -883,6 +931,12 @@ class TrustDomainInstance(object): Input: another_domain -- instance of TrustDomainInstance, initialized with #retrieve call trustdom_secret -- shared secred used for the trust """ + if self.info['name'] == another_domain.info['name']: + # Check that NetBIOS names do not clash + raise errors.ValidationError(name=u'AD Trust Setup', + error=_('the IPA server and the remote domain cannot share the same ' + 'NetBIOS name: %s') % self.info['name']) + self.generate_auth(trustdom_secret) info = lsa.TrustDomainInfoInfoEx() @@ -893,12 +947,6 @@ class TrustDomainInstance(object): info.trust_type = lsa.LSA_TRUST_TYPE_UPLEVEL info.trust_attributes = lsa.LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE - if self.info['name'] == info.netbios_name.string: - # Check that NetBIOS names do not clash - raise errors.ValidationError(name=u'AD Trust Setup', - error=_('the IPA server and the remote domain cannot share the same ' - 'NetBIOS name: %s') % self.info['name']) - try: dname = lsa.String() dname.string = another_domain.info['dns_domain'] @@ -911,12 +959,14 @@ class TrustDomainInstance(object): except RuntimeError, (num, message): raise assess_dcerpc_exception(num=num, message=message) + self.update_ftinfo(another_domain) + + # We should use proper trustdom handle in order to modify the + # trust settings. Samba insists this has to be done with LSA + # OpenTrustedDomain* calls, it is not enough to have a handle + # returned by the CreateTrustedDomainEx2 call. + trustdom_handle = self._pipe.OpenTrustedDomainByName(self._policy_handle, dname, security.SEC_FLAG_MAXIMUM_ALLOWED) try: - # We should use proper trustdom handle in order to modify the - # trust settings. Samba insists this has to be done with LSA - # OpenTrustedDomain* calls, it is not enough to have a handle - # returned by the CreateTrustedDomainEx2 call. - trustdom_handle = self._pipe.OpenTrustedDomainByName(self._policy_handle, dname, security.SEC_FLAG_MAXIMUM_ALLOWED) infoclass = lsa.TrustDomainInfoSupportedEncTypes() infoclass.enc_types = security.KERB_ENCTYPE_RC4_HMAC_MD5 infoclass.enc_types |= security.KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 @@ -1016,6 +1066,32 @@ class TrustDomainJoins(object): # Otherwise, use anonymously obtained data self.remote_domain = rd + def get_realmdomains(self): + """ + Generate list of records for forest trust information about + our realm domains. Note that the list generated currently + includes only top level domains, no exclusion domains, and no TDO objects + as we handle the latter in a separte way + """ + if self.local_domain.read_only: + return + + self.local_domain.ftinfo_records = [] + + realm_domains = self.api.Command.realmdomains_show()['result'] + trustconfig = self.api.Command.trustconfig_show()['result'] + # Use realmdomains' modification timestamp to judge records last update time + (dn, entry_attrs) = self.api.Backend.ldap2.get_entry(realm_domains['dn'], ['modifyTimestamp']) + # Convert the timestamp to Windows 64-bit timestamp format + trust_timestamp = long(time.mktime(time.strptime(entry_attrs['modifytimestamp'][0][:14], "%Y%m%d%H%M%S"))*1e7+116444736000000000) + + for dom in realm_domains['associateddomain']: + ftinfo = dict() + ftinfo['rec_name'] = dom + ftinfo['rec_time'] = trust_timestamp + ftinfo['rec_type'] = lsa.LSA_FOREST_TRUST_TOP_LEVEL_NAME + self.local_domain.ftinfo_records.append(ftinfo) + def join_ad_full_credentials(self, realm, realm_server, realm_admin, realm_passwd): if not self.configured: return None @@ -1030,6 +1106,7 @@ class TrustDomainJoins(object): if not self.remote_domain.read_only: trustdom_pass = samba.generate_random_password(128, 128) + self.get_realmdomains() self.remote_domain.establish_trust(self.local_domain, trustdom_pass) self.local_domain.establish_trust(self.remote_domain, trustdom_pass) result = self.remote_domain.verify_trust(self.local_domain) -- 1.8.3.1 -------------- next part -------------- >From b1fbca3585aa8191a81012c97d5320e281a1546b Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 18 Sep 2013 17:04:19 +0200 Subject: [PATCH 2/8] trusts: support subdomains in a forest Add IPA CLI to manage trust domains. ipa trust-fetch-domains -- fetch list of subdomains from AD side and add new ones to IPA ipa trustdomain-find -- show all available domains ipa trustdomain-del -- remove domain from IPA view about ipa trustdomain-enable -- allow users from trusted domain to access resources in IPA ipa trustdomain-disable -- disable access to resources in IPA from trusted domain By default all discovered trust domains are allowed to access IPA resources IPA KDC needs also information for authentication paths to subdomains in case they are not hierarchical under AD forest trust root. This information is managed via capaths section in krb5.conf. SSSD should be able to generate it once ticket https://fedorahosted.org/sssd/ticket/2093 is resolved. part of https://fedorahosted.org/freeipa/ticket/3909 --- API.txt | 80 +++++++++++ ipalib/plugins/trust.py | 351 +++++++++++++++++++++++++++++++++++++++++------- ipaserver/dcerpc.py | 54 ++++++++ 3 files changed, 434 insertions(+), 51 deletions(-) diff --git a/API.txt b/API.txt index 761d1d1..d9242eb 100644 --- a/API.txt +++ b/API.txt @@ -3423,6 +3423,15 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: Output('value', , None) +command: trust_fetch_domains +args: 1,4,2 +arg: Str('cn', attribute=True, cli_name='realm', multivalue=False, primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) command: trust_find args: 1,11,4 arg: Str('criteria?', noextrawhitespace=False) @@ -3497,6 +3506,77 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: Output('value', , None) +command: trustdomain_add +args: 2,9,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('cn', cli_name='domain') +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('ipantflatname', attribute=True, cli_name='flat_name', multivalue=False, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, cli_name='sid', multivalue=False, required=False) +option: Str('ipanttrustpartner', attribute=True, cli_name='ipanttrustpartner', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', values=(u'ad',)) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trustdomain_del +args: 2,2,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('cn', cli_name='domain') +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trustdomain_disable +args: 2,1,1 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('cn', cli_name='domain') +option: Str('version?', exclude='webui') +output: Output('summary', (, ), None) +command: trustdomain_enable +args: 2,1,1 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('cn', cli_name='domain') +option: Str('version?', exclude='webui') +output: Output('summary', (, ), None) +command: trustdomain_find +args: 2,8,4 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('ipantflatname', attribute=True, autofill=False, cli_name='flat_name', multivalue=False, query=True, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='sid', multivalue=False, query=True, required=False) +option: Str('ipanttrustpartner', attribute=True, autofill=False, cli_name='ipanttrustpartner', multivalue=False, query=True, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: trustdomain_mod +args: 2,11,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('cn', cli_name='domain') +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('ipantflatname', attribute=True, autofill=False, cli_name='flat_name', multivalue=False, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='sid', multivalue=False, required=False) +option: Str('ipanttrustpartner', attribute=True, autofill=False, cli_name='ipanttrustpartner', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', values=(u'ad',)) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('value', , None) command: user_add args: 1,35,3 arg: Str('uid', attribute=True, cli_name='login', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 3d05029..157bedc 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -181,6 +181,13 @@ def trust_status_string(level): string = _trust_status_dict.get(level, _trust_type_dict_unknown) return unicode(string) +def make_trust_dn(env, trust_type, dn): + assert isinstance(dn, DN) + if trust_type: + container_dn = DN(('cn', trust_type), env.container_trusts, env.basedn) + return DN(dn, container_dn) + return dn + class trust(LDAPObject): """ Trust object. @@ -195,7 +202,8 @@ class trust(LDAPObject): 'ipantauthtrustoutgoing', 'ipanttrustauthincoming', 'ipanttrustforesttrustinfo', 'ipanttrustposixoffset', 'ipantsupportedencryptiontypes' ] search_display_attributes = ['cn', 'ipantflatname', - 'ipanttrusteddomainsid', 'ipanttrusttype' ] + 'ipanttrusteddomainsid', 'ipanttrusttype', + 'ipantsidblacklistincoming', 'ipantsidblacklistoutgoing' ] label = _('Trusts') label_singular = _('Trust') @@ -241,12 +249,26 @@ class trust(LDAPObject): raise errors.ValidationError(name=attr, error=_("invalid SID: %(value)s") % dict(value=value)) -def make_trust_dn(env, trust_type, dn): - assert isinstance(dn, DN) - if trust_type in trust.trust_types: - container_dn = DN(('cn', trust_type), env.container_trusts, env.basedn) - return DN(dn[0], container_dn) - return dn + def get_dn(self, *keys, **kwargs): + sdn = map(lambda x: ('cn', x), keys) + sdn.reverse() + trust_type = kwargs.get('trust_type') + if trust_type is None: + ldap = self.backend + filter = ldap.make_filter({'objectclass': ['ipaNTTrustedDomain'], 'cn': [keys[-1]]}) + filter = ldap.combine_filters((filter, "ipaNTSIDBlacklistIncoming=*"), rules=ldap.MATCH_ALL) + try: + result = ldap.get_entries(DN(self.container_dn, self.env.basedn), + ldap.SCOPE_SUBTREE, filter, ['']) + except errors.NotFound: + trust_type = u'ad' + else: + if len(result) > 1: + raise errors.OnlyOneValueAllowed(attr='trust domain') + return result[0].dn + + dn=make_trust_dn(self.env, trust_type, DN(*sdn)) + return dn class trust_add(LDAPCreate): __doc__ = _(''' @@ -589,10 +611,13 @@ sides. def execute_ad(self, full_join, *keys, **options): # Join domain using full credentials and with random trustdom # secret (will be generated by the join method) - try: - api.Command['trust_show'](keys[-1]) + + # First see if the trust is already in place + # Force retrieval of the trust object by not passing trust_type + dn = self.obj.get_dn(keys[-1]) + if dn: summary = _('Re-established trust to domain "%(value)s"') - except errors.NotFound: + else: summary = self.msg_summary # 1. Full access to the remote domain. Use admin credentials and @@ -665,14 +690,6 @@ class trust_del(LDAPDelete): msg_summary = _('Deleted trust "%(value)s"') - def pre_callback(self, ldap, dn, *keys, **options): - assert isinstance(dn, DN) - try: - result = self.api.Command.trust_show(keys[-1]) - except errors.NotFound, e: - self.obj.handle_not_found(*keys) - return result['result']['dn'] - class trust_mod(LDAPUpdate): __doc__ = _(""" Modify a trust (for future use). @@ -686,16 +703,10 @@ class trust_mod(LDAPUpdate): def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): assert isinstance(dn, DN) - result = None - try: - result = self.api.Command.trust_show(keys[-1]) - except errors.NotFound, e: - self.obj.handle_not_found(*keys) self.obj.validate_sid_blacklists(entry_attrs) - # TODO: we found the trust object, now modify it - return result['result']['dn'] + return dn class trust_find(LDAPSearch): __doc__ = _('Search for trusts.') @@ -709,8 +720,10 @@ class trust_find(LDAPSearch): # Since all trusts types are stored within separate containers under 'cn=trusts', # search needs to be done on a sub-tree scope def pre_callback(self, ldap, filters, attrs_list, base_dn, scope, *args, **options): - assert isinstance(base_dn, DN) - return (filters, base_dn, ldap.SCOPE_SUBTREE) + # list only trust, not trust domains + trust_filter = '(ipaNTSIDBlacklistIncoming=*)' + filter = ldap.combine_filters((filters, trust_filter), rules=ldap.MATCH_ALL) + return (filter, base_dn, ldap.SCOPE_SUBTREE) def post_callback(self, ldap, entries, truncated, *args, **options): if options.get('pkey_only', False): @@ -731,30 +744,6 @@ class trust_show(LDAPRetrieve): has_output_params = LDAPRetrieve.has_output_params + trust_output_params +\ (Str('ipanttrusttype'), Str('ipanttrustdirection')) - def execute(self, *keys, **options): - error = None - result = None - for trust_type in trust.trust_types: - options['trust_show_type'] = trust_type - try: - result = super(trust_show, self).execute(*keys, **options) - except errors.NotFound, e: - result = None - error = e - if result: - break - if error or not result: - self.obj.handle_not_found(*keys) - - return result - - def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): - assert isinstance(dn, DN) - if 'trust_show_type' in options: - return make_trust_dn(self.env, options['trust_show_type'], dn) - - return dn - def post_callback(self, ldap, dn, entry_attrs, *keys, **options): # Translate ipanttrusttype to trusttype @@ -1091,3 +1080,263 @@ class sidgen_was_run(Command): return dict(result=True) api.register(sidgen_was_run) + +class trustdomain(LDAPObject): + """ + Object representing a domain of the AD trust. + """ + parent_object = 'trust' + trust_type_idx = {'2':u'ad'} + object_name = _('trust domain') + object_name_plural = _('trust domains') + object_class = ['ipaNTTrustedDomain'] + default_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', 'ipanttrustpartner'] + search_display_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', ] + + label = _('Trusted domains') + label_singular = _('Trusted domain') + + # We do not add this argument implicitly via takes_args in the object. + # Rather, it is added explicitly in the commands that require second arg + # because first argument will be inherited from the 'trust' parent object + trustdomain_args = ( + Str('cn', + label=_('Domain name'), + cli_name='domain', + ), + ) + + takes_params = ( + Str('ipantflatname?', + cli_name='flat_name', + label=_('Domain NetBIOS name'), + ), + Str('ipanttrusteddomainsid?', + cli_name='sid', + label=_('Domain Security Identifier'), + ), + Str('ipanttrustpartner?', + label=_('Trusted domain partner'), + flags=['no_display', 'no_option'], + ), + ) + + # LDAPObject.get_dn() only passes all but last element of keys and no kwargs + # to the parent object's get_dn() no matter what you pass to it. Make own get_dn() + # as we really need all elements to construct proper dn. + def get_dn(self, *keys, **kwargs): + sdn = map(lambda x: ('cn', x), keys) + sdn.reverse() + trust_type = kwargs.get('trust_type') + if not trust_type: + trust_type=u'ad' + + dn=make_trust_dn(self.env, trust_type, DN(*sdn)) + return dn +api.register(trustdomain) + +class trustdomain_find(LDAPSearch): + __doc__ = _('Search domains of the trust') + + has_output_params = LDAPSearch.has_output_params + trustdomain.trustdomain_args + def pre_callback(self, ldap, filters, attrs_list, base_dn, scope, *args, **options): + return (filters, base_dn, ldap.SCOPE_SUBTREE) +api.register(trustdomain_find) + +class trustdomain_mod(LDAPUpdate): + __doc__ = _('Modify trustdomain of the trust') + + NO_CLI = True + takes_args = trustdomain.trustdomain_args + takes_options = LDAPUpdate.takes_options + (_trust_type_option,) +api.register(trustdomain_mod) + +class trustdomain_add(LDAPCreate): + __doc__ = _('Allow access from the trusted domain') + NO_CLI = True + + takes_args = trustdomain.trustdomain_args + takes_options = LDAPCreate.takes_options + (_trust_type_option,) + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + if 'ipanttrustpartner' in options: + entry_attrs['ipanttrustpartner'] = [options['ipanttrustpartner']] + return dn +api.register(trustdomain_add) + +class trustdomain_del(LDAPDelete): + __doc__ = _('Remove infromation about the domain associated with the trust.') + + msg_summary = _('Removed information about the trusted domain "%(value)s"') + + takes_args = trustdomain.trustdomain_args + + def execute(self, *keys, **options): + # Note that pre-/post- callback handling for LDAPDelete is causing pre_callback + # to always receive empty keys. We need to catch the case when root domain is being deleted + if keys[0].lower() == keys[1].lower(): + raise errors.ValidationError(name='trustdomain_del', + error=_("cannot delete root domain of the trust, use trust-del to delete the trust itself")) + res = api.Command.trustdomain_enable(*keys) + result = super(trustdomain_del, self).execute(*keys, **options) + result['value'] = keys[1] + return result + + +api.register(trustdomain_del) + + +def fetch_domains_from_trust(self, trustinstance, trust_entry): + trust_name = trust_entry['cn'][0] + domains = ipaserver.dcerpc.fetch_domains(self.api, trustinstance.local_flatname, trust_name) + result = [] + if not domains: + return None + + for dom in domains: + dom['trust_type'] = u'ad' + try: + name = dom['cn'] + del dom['cn'] + if 'all' in options: + dom['all'] = options['all'] + if 'raw' in options: + dom['raw'] = options['raw'] + res = self.api.Command.trustdomain_add(trust_name, name, **dom) + result.append(res['result']) + except errors.DuplicateEntry: + # Ignore updating duplicate entries + pass + return result + +class trust_fetch_domains(LDAPRetrieve): + __doc__ = _('Refresh list of the domains associated with the trust') + + has_output = ( + output.ListOfEntries('result'), + output.summary + ) + + def execute(self, *keys, **options): + if not _bindings_installed: + raise errors.NotFound( + name=_('AD Trust setup'), + reason=_( + 'Cannot perform join operation without Samba 4 support ' + 'installed. Make sure you have installed server-trust-ad ' + 'sub-package of IPA' + ) + ) + trust = self.api.Command.trust_show(keys[0], raw=True)['result'] + + trustinstance = ipaserver.dcerpc.TrustDomainJoins(self.api) + if not trustinstance.configured: + raise errors.NotFound( + name=_('AD Trust setup'), + reason=_( + 'Cannot perform join operation without own domain ' + 'configured. Make sure you have run ipa-adtrust-install ' + 'on the IPA server first' + ) + ) + domains = fetch_domains_from_trust(self, trustinstance, trust) + result = dict(result=[]) + if not domains: + result['summary'] = unicode(_('No trust domains were detected during refresh')) + return result + + if len(domains) > 0: + result['summary'] = unicode(_('List of trust domains successfully refreshed')) + else: + result['summary'] = unicode(_('No new trust domains were found')) + + result['result'] = domains + return result +api.register(trust_fetch_domains) + +class trustdomain_enable(LDAPQuery): + __doc__ = _('Allow use of IPA resources by the domain of the trust') + + has_output = ( + output.summary, + ) + + takes_args = trustdomain.trustdomain_args + + def execute(self, *keys, **options): + ldap = self.api.Backend.ldap2 + + if keys[0].lower() == keys[1].lower(): + raise errors.ValidationError(name='trustdomain_enable', + error=_("Root domain of the trust is always enabled for the existing trust")) + try: + trust_dn = self.obj.get_dn(keys[0], trust_type=u'ad') + trust_entry = ldap.get_entry(trust_dn) + except errors.NotFound: + raise errors.ValidationError(name=_('AD trust'), error=_('Valid trust name is required')) + + result = dict() + result['trust'] = unicode(keys[0]) + result['domain'] = unicode(keys[1]) + dn = self.obj.get_dn(keys[0], keys[1], trust_type=u'ad') + try: + entry = ldap.get_entry(dn) + sid = entry['ipanttrusteddomainsid'][0] + if sid in trust_entry['ipantsidblacklistincoming']: + trust_entry['ipantsidblacklistincoming'].remove(sid) + result['action'] = _('is allowed') + ldap.update_entry(trust_entry) + else: + result['action'] = _('is already allowed') + result['summary'] = _('Domain %(domain)s of trust %(trust)s %(action)s to access IPA resources') + except errors.NotFound: + raise errors.ValidationError(name=_('AD trust'), error=_('Valid trust domain name is required')) + except errors.EmptyModlist: + result['summary'] = _('No changes were done') + + return dict(summary=result['summary'] % result) + +api.register(trustdomain_enable) + +class trustdomain_disable(LDAPQuery): + __doc__ = _('Disable use of IPA resources by the domain of the trust') + + has_output = ( + output.summary, + ) + + takes_args = trustdomain.trustdomain_args + + def execute(self, *keys, **options): + ldap = self.api.Backend.ldap2 + + if keys[0].lower() == keys[1].lower(): + raise errors.ValidationError(name='trustdomain_disable', + error=_("cannot disable root domain of the trust, use trust-del to delete the trust itself")) + try: + trust_dn = self.obj.get_dn(keys[0], trust_type=u'ad') + trust_entry = ldap.get_entry(trust_dn) + except errors.NotFound: + raise errors.ValidationError(name=_('AD trust'), error=_('Valid trust name is required')) + + result = dict() + result['trust'] = unicode(keys[0]) + result['domain'] = unicode(keys[1]) + dn = self.obj.get_dn(keys[0], keys[1], trust_type=u'ad') + try: + entry = ldap.get_entry(dn) + sid = entry['ipanttrusteddomainsid'][0] + if not (sid in trust_entry['ipantsidblacklistincoming']): + trust_entry['ipantsidblacklistincoming'].append(sid) + result['action'] = _('is not allowed') + ldap.update_entry(trust_entry) + else: + result['action'] = _('is already not allowed') + result['summary'] = _('Domain %(domain)s of trust %(trust)s %(action)s to access IPA resources') + except errors.NotFound: + raise errors.ValidationError(name=_('AD trust'), error=_('Valid trust domain name is required')) + except errors.EmptyModlist: + result['summary'] = _('No changes were done') + + return dict(summary=result['summary'] % result) + +api.register(trustdomain_disable) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index cc9e7be..1c4f4a6 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -1002,6 +1002,60 @@ class TrustDomainInstance(object): return True return False +def fetch_domains(api, mydomain, trustdomain): + trust_flags = dict( + NETR_TRUST_FLAG_IN_FOREST = 0x00000001, + NETR_TRUST_FLAG_OUTBOUND = 0x00000002, + NETR_TRUST_FLAG_TREEROOT = 0x00000004, + NETR_TRUST_FLAG_PRIMARY = 0x00000008, + NETR_TRUST_FLAG_NATIVE = 0x00000010, + NETR_TRUST_FLAG_INBOUND = 0x00000020, + NETR_TRUST_FLAG_MIT_KRB5 = 0x00000080, + NETR_TRUST_FLAG_AES = 0x00000100) + + trust_attributes = dict( + NETR_TRUST_ATTRIBUTE_NON_TRANSITIVE = 0x00000001, + NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x00000002, + NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x00000004, + NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x00000008, + NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x00000010, + NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x00000020, + NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x00000040) + + domval = DomainValidator(api) + (ccache_name, principal) = domval.kinit_as_http(trustdomain) + if ccache_name: + with installutils.private_ccache(path=ccache_name): + td = TrustDomainInstance('') + td.parm.set('workgroup', mydomain) + td.creds = credentials.Credentials() + td.creds.set_kerberos_state(credentials.MUST_USE_KERBEROS) + td.creds.guess(td.parm) + netrc = net.Net(creds=td.creds, lp=td.parm) + try: + result = netrc.finddc(domain=trustdomain, flags=nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_DS) + except RuntimeError, e: + raise assess_dcerpc_exception(message=str(e)) + if not result: + return None + td.retrieve(unicode(result.pdc_dns_name)) + + netr_pipe = netlogon.netlogon(td.binding, td.parm, td.creds) + domains = netr_pipe.netr_DsrEnumerateDomainTrusts(td.binding, 1) + + result = [] + for t in domains.array: + if ((t.trust_attributes & trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and + (t.trust_flags & trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): + res = dict() + res['cn'] = unicode(t.dns_name) + res['ipantflatname'] = unicode(t.netbios_name) + res['ipanttrusteddomainsid'] = unicode(t.sid) + res['ipanttrustpartner'] = res['cn'] + result.append(res) + return result + + class TrustDomainJoins(object): def __init__(self, api): self.api = api -- 1.8.3.1 -------------- next part -------------- >From 1c5728d51ee3d9c744004f8a7d7e97d17623ebe2 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 26 Sep 2013 16:44:37 +0200 Subject: [PATCH 3/8] frontend: report arguments errors with better detail When reporting argument errors, show also a context -- what is processed, what is the name of the command. --- ipalib/frontend.py | 3 ++- ipatests/test_ipalib/test_frontend.py | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/ipalib/frontend.py b/ipalib/frontend.py index cac3e3b..f478ef0 100644 --- a/ipalib/frontend.py +++ b/ipalib/frontend.py @@ -869,7 +869,8 @@ class Command(HasParam): for arg in args(): if optional and arg.required: raise ValueError( - '%s: required argument after optional' % arg.name + '%s: required argument after optional in %s arguments %s' % (arg.name, + self.name, map(lambda x: x.param_spec, args())) ) if multivalue: raise ValueError( diff --git a/ipatests/test_ipalib/test_frontend.py b/ipatests/test_ipalib/test_frontend.py index 310d7a5..ce943a7 100644 --- a/ipatests/test_ipalib/test_frontend.py +++ b/ipatests/test_ipalib/test_frontend.py @@ -280,7 +280,7 @@ class test_Command(ClassChecker): # Test ValueError, required after optional: e = raises(ValueError, self.get_instance, args=('arg1?', 'arg2')) - assert str(e) == 'arg2: required argument after optional' + assert str(e) == "arg2: required argument after optional in %s arguments ['arg1?', 'arg2']" % (self.get_instance().name) # Test ValueError, scalar after multivalue: e = raises(ValueError, self.get_instance, args=('arg1+', 'arg2')) -- 1.8.3.1 -------------- next part -------------- >From 3997d9c286a073f1e5c78189dfb4f91bb1bf3b65 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 27 Sep 2013 12:36:59 +0200 Subject: [PATCH 4/8] ipaserver/dcerpc: remove use of trust account authentication Since FreeIPA KDC supports adding MS-PAC to HTTP/ipa.server principal, it is possible to use it when talking to the trusted AD DC. Remove support for authenticating as trust account because it should not really be used other than within Samba. --- ipalib/plugins/trust.py | 1 - ipaserver/dcerpc.py | 76 ++++--------------------------------------------- 2 files changed, 6 insertions(+), 71 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 4765ac7..216451c 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -551,7 +551,6 @@ sides. None, SCOPE_SUBTREE, basedn=info_dn, - use_http=True, quiet=True) if info_list: diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 1c4f4a6..2b0da45 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -165,8 +165,7 @@ class DomainValidator(object): base_dn=cn_trust, attrs_list=[self.ATTR_TRUSTED_SID, self.ATTR_FLATNAME, - self.ATTR_TRUST_PARTNER, - self.ATTR_TRUST_AUTHOUT] + self.ATTR_TRUST_PARTNER] ) # We need to use case-insensitive dictionary since we use @@ -185,18 +184,8 @@ class DomainValidator(object): "attribute: %s", dn, e) continue - trust_authout = entry.get(self.ATTR_TRUST_AUTHOUT, [None])[0] - - # We were able to read all Trusted domain attributes but the - # secret User is not member of trust admins group - if trust_authout is None: - raise errors.ACIError( - info=_('communication with trusted domains is allowed ' - 'for Trusts administrator group members only')) - result[trust_partner] = (flatname_normalized, - security.dom_sid(trusted_sid), - trust_authout) + security.dom_sid(trusted_sid)) return result except errors.NotFound, e: return [] @@ -462,43 +451,6 @@ class DomainValidator(object): ] return u'S-%d-%d-%s' % ( sid_rev_num, ia, '-'.join([str(s) for s in subs]),) - def __extract_trusted_auth(self, info): - """ - Returns in clear trusted domain account credentials - """ - clear = None - auth = drsblobs.trustAuthInOutBlob() - auth.__ndr_unpack__(info['auth']) - auth_array = auth.current.array[0] - if auth_array.AuthType == lsa.TRUST_AUTH_TYPE_CLEAR: - clear = ''.join(map(chr, auth_array.AuthInfo.password)).decode('utf-16-le') - return clear - - def __kinit_as_trusted_account(self, info, password): - """ - Initializes ccache with trusted domain account credentials. - - Applies session code defaults for ccache directory and naming prefix. - Session code uses krbccache_prefix+, we use - krbccache_prefix++ so there is no clash - - Returns tuple (ccache name, principal) where (None, None) signifes an error - on ccache initialization - """ - ccache_name = os.path.join(krbccache_dir, "%sTD%s" % (krbccache_prefix, info['name'][0])) - principal = '%s$@%s' % (self.flatname, info['dns_domain'].upper()) - (stdout, stderr, returncode) = ipautil.run(['/usr/bin/kinit', principal], - env={'KRB5CCNAME':ccache_name}, - stdin=password, raiseonerr=False) - if returncode == 0: - return (ccache_name, principal) - else: - if returncode == 1: - raise errors.ACIError( - info=_("KDC for %(domain)s denied trust account for IPA domain with a message '%(message)s'") % - dict(domain=info['dns_domain'],message=stderr.strip())) - return (None, None) - def kinit_as_http(self, domain): """ Initializes ccache with http service credentials. @@ -544,13 +496,10 @@ class DomainValidator(object): return (None, None) def search_in_dc(self, domain, filter, attrs, scope, basedn=None, - use_http=False, quiet=False): + quiet=False): """ Perform LDAP search in a trusted domain `domain' Domain Controller. Returns resulting entries or None. - - If use_http is set to True, the search is conducted using - HTTP service credentials. """ entries = None @@ -565,7 +514,6 @@ class DomainValidator(object): for (host, port) in info['gc']: entries = self.__search_in_dc(info, host, port, filter, attrs, scope, basedn=basedn, - use_http=use_http, quiet=quiet) if entries: break @@ -573,22 +521,13 @@ class DomainValidator(object): return entries def __search_in_dc(self, info, host, port, filter, attrs, scope, - basedn=None, use_http=False, quiet=False): + basedn=None, quiet=False): """ Actual search in AD LDAP server, using SASL GSSAPI authentication Returns LDAP result or None. """ - if use_http: - (ccache_name, principal) = self.kinit_as_http(info['dns_domain']) - else: - auth = self.__extract_trusted_auth(info) - - if not auth: - return None - - (ccache_name, principal) = self.__kinit_as_trusted_account(info, - auth) + (ccache_name, principal) = self.kinit_as_http(info['dns_domain']) if ccache_name: with installutils.private_ccache(path=ccache_name): @@ -626,7 +565,6 @@ class DomainValidator(object): Returns dictionary with following keys name -- NetBIOS name of the trusted domain dns_domain -- DNS name of the trusted domain - auth -- encrypted credentials for trusted domain account gc -- array of tuples (server, port) for Global Catalog """ if domain in self._info: @@ -653,7 +591,6 @@ class DomainValidator(object): self._domains = self.get_trusted_domains() info = dict() - info['auth'] = self._domains[domain][2] servers = [] if result: @@ -1125,7 +1062,7 @@ class TrustDomainJoins(object): Generate list of records for forest trust information about our realm domains. Note that the list generated currently includes only top level domains, no exclusion domains, and no TDO objects - as we handle the latter in a separte way + as we handle the latter in a separate way """ if self.local_domain.read_only: return @@ -1133,7 +1070,6 @@ class TrustDomainJoins(object): self.local_domain.ftinfo_records = [] realm_domains = self.api.Command.realmdomains_show()['result'] - trustconfig = self.api.Command.trustconfig_show()['result'] # Use realmdomains' modification timestamp to judge records last update time (dn, entry_attrs) = self.api.Backend.ldap2.get_entry(realm_domains['dn'], ['modifyTimestamp']) # Convert the timestamp to Windows 64-bit timestamp format -- 1.8.3.1 -------------- next part -------------- >From a17e60eedb436a576031f586459b6410ca21b221 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 27 Sep 2013 12:39:57 +0200 Subject: [PATCH 5/8] trust: integrate subdomains support into trust-add --- ipalib/plugins/trust.py | 23 ++++++++++++-- ipaserver/dcerpc.py | 80 +++++++++++++++++++++++++++++-------------------- 2 files changed, 67 insertions(+), 36 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 216451c..88d67eb 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -345,7 +345,20 @@ sides. base_dn = DN(api.env.container_trusts, api.env.basedn), filter = trust_filter) + result['result'] = entry_to_dict(trusts[0][1], **options) + if options.get('trust_type') == u'ad': + domains = fetch_domains_from_trust(self, self.trustinstance, result['result'], **options) + if domains and len(domains) > 0: + for dom in domains: + range_name = dom['cn'][0].upper() + '_id_range' + range_type=options.get('range_type', u'ipa-ad-trust') + dom_sid = dom['ipanttrusteddomainsid'][0] + try: + self.add_range(range_name, dom_sid, range_type=range_type) + except errors.DuplicateEntry: + pass + result['result']['trusttype'] = [trust_type_string(result['result']['ipanttrusttype'][0])] result['result']['trustdirection'] = [trust_direction_string(result['result']['ipanttrustdirection'][0])] result['result']['truststatus'] = [trust_status_string(result['verified'])] @@ -446,7 +459,7 @@ sides. except errors.NotFound: old_range = None - if options.get('type') == u'ad': + if options.get('trust_type') == u'ad': if range_type and range_type not in (u'ipa-ad-trust', u'ipa-ad-trust-posix'): raise errors.ValidationError( @@ -1184,9 +1197,13 @@ class trustdomain_del(LDAPDelete): api.register(trustdomain_del) -def fetch_domains_from_trust(self, trustinstance, trust_entry): +def fetch_domains_from_trust(self, trustinstance, trust_entry, **options): trust_name = trust_entry['cn'][0] - domains = ipaserver.dcerpc.fetch_domains(self.api, trustinstance.local_flatname, trust_name) + creds = None + password = options.get('realm_password', None) + if password: + creds = u"%s%%%s" % (options.get('realm_admin'), password) + domains = ipaserver.dcerpc.fetch_domains(self.api, trustinstance.local_flatname, trust_name, creds=creds) result = [] if not domains: return None diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 2b0da45..86bb428 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -939,7 +939,8 @@ class TrustDomainInstance(object): return True return False -def fetch_domains(api, mydomain, trustdomain): + +def fetch_domains(api, mydomain, trustdomain, creds=None): trust_flags = dict( NETR_TRUST_FLAG_IN_FOREST = 0x00000001, NETR_TRUST_FLAG_OUTBOUND = 0x00000002, @@ -959,38 +960,51 @@ def fetch_domains(api, mydomain, trustdomain): NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x00000020, NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x00000040) - domval = DomainValidator(api) - (ccache_name, principal) = domval.kinit_as_http(trustdomain) - if ccache_name: - with installutils.private_ccache(path=ccache_name): - td = TrustDomainInstance('') - td.parm.set('workgroup', mydomain) - td.creds = credentials.Credentials() - td.creds.set_kerberos_state(credentials.MUST_USE_KERBEROS) - td.creds.guess(td.parm) - netrc = net.Net(creds=td.creds, lp=td.parm) - try: - result = netrc.finddc(domain=trustdomain, flags=nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_DS) - except RuntimeError, e: - raise assess_dcerpc_exception(message=str(e)) - if not result: - return None - td.retrieve(unicode(result.pdc_dns_name)) - - netr_pipe = netlogon.netlogon(td.binding, td.parm, td.creds) - domains = netr_pipe.netr_DsrEnumerateDomainTrusts(td.binding, 1) - - result = [] - for t in domains.array: - if ((t.trust_attributes & trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and - (t.trust_flags & trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): - res = dict() - res['cn'] = unicode(t.dns_name) - res['ipantflatname'] = unicode(t.netbios_name) - res['ipanttrusteddomainsid'] = unicode(t.sid) - res['ipanttrustpartner'] = res['cn'] - result.append(res) - return result + def communicate(td): + td.creds.guess(td.parm) + netrc = net.Net(creds=td.creds, lp=td.parm) + try: + result = netrc.finddc(domain=trustdomain, flags=nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_DS) + except RuntimeError, e: + raise assess_dcerpc_exception(message=str(e)) + if not result: + return None + td.retrieve(unicode(result.pdc_dns_name)) + + netr_pipe = netlogon.netlogon(td.binding, td.parm, td.creds) + domains = netr_pipe.netr_DsrEnumerateDomainTrusts(td.binding, 1) + return domains + + domains = None + td = TrustDomainInstance('') + td.parm.set('workgroup', mydomain) + td.creds = credentials.Credentials() + if creds is None: + domval = DomainValidator(api) + (ccache_name, principal) = domval.kinit_as_http(trustdomain) + td.creds.set_kerberos_state(credentials.MUST_USE_KERBEROS) + if ccache_name: + with installutils.private_ccache(path=ccache_name): + domains = communicate(td) + else: + td.creds.set_kerberos_state(credentials.DONT_USE_KERBEROS) + td.creds.parse_string(creds) + domains = communicate(td) + + if domains is None: + return None + + result = [] + for t in domains.array: + if ((t.trust_attributes & trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and + (t.trust_flags & trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): + res = dict() + res['cn'] = unicode(t.dns_name) + res['ipantflatname'] = unicode(t.netbios_name) + res['ipanttrusteddomainsid'] = unicode(t.sid) + res['ipanttrustpartner'] = res['cn'] + result.append(res) + return result class TrustDomainJoins(object): -- 1.8.3.1 -------------- next part -------------- >From 7edbd5a6b27c2372d4478195801125a63baaab03 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Fri, 27 Sep 2013 14:00:22 +0200 Subject: [PATCH 6/8] ipasam: for subdomains pick up defaults for missing values We don't store trust type, attributes, and direction for subdomains of the existing trust. Since trust is always forest level, these parameters can be added as defaults when they are missing. --- daemons/ipa-sam/ipa_sam.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index a535c0f..59ddcef 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -2026,6 +2026,10 @@ static bool fill_pdb_trusted_domain(TALLOC_CTX *mem_ctx, if (!res) { return false; } + if (td->trust_direction == 0) { + /* attribute wasn't present, set default value */ + td->trust_direction = LSA_TRUST_DIRECTION_INBOUND | LSA_TRUST_DIRECTION_OUTBOUND; + } res = get_uint32_t_from_ldap_msg(ldap_state, entry, LDAP_ATTRIBUTE_TRUST_ATTRIBUTES, @@ -2033,6 +2037,10 @@ static bool fill_pdb_trusted_domain(TALLOC_CTX *mem_ctx, if (!res) { return false; } + if (td->trust_attributes == 0) { + /* attribute wasn't present, set default value */ + td->trust_attributes = LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE; + } res = get_uint32_t_from_ldap_msg(ldap_state, entry, LDAP_ATTRIBUTE_TRUST_TYPE, @@ -2040,6 +2048,10 @@ static bool fill_pdb_trusted_domain(TALLOC_CTX *mem_ctx, if (!res) { return false; } + if (td->trust_type == 0) { + /* attribute wasn't present, set default value */ + td->trust_type = LSA_TRUST_TYPE_UPLEVEL; + } td->trust_posix_offset = talloc_zero(td, uint32_t); if (td->trust_posix_offset == NULL) { -- 1.8.3.1 -------------- next part -------------- >From bf411c69b3851e823c0d5ab7461647dfbdded8cd Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Sat, 28 Sep 2013 21:49:57 +0200 Subject: [PATCH 7/8] KDC: implement transition check for trusted domains When client principal requests for a ticket for a server principal and we have to perform transition, check that all three belong to either our domain or the domains we trust through forest trusts. In case all three realms (client, transition, and server) match trusted domains and our domain, issue permission to transition from client realm to server realm. Part of https://fedorahosted.org/freeipa/ticket/3909 --- daemons/ipa-kdb/ipa_kdb.c | 2 +- daemons/ipa-kdb/ipa_kdb.h | 5 +++- daemons/ipa-kdb/ipa_kdb_mspac.c | 62 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 67 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb.c b/daemons/ipa-kdb/ipa_kdb.c index 5e4d047..c807bbc 100644 --- a/daemons/ipa-kdb/ipa_kdb.c +++ b/daemons/ipa-kdb/ipa_kdb.c @@ -602,7 +602,7 @@ kdb_vftabl kdb_function_table = { NULL, /* decrypt_key_data */ NULL, /* encrypt_key_data */ ipadb_sign_authdata, /* sign_authdata */ - NULL, /* check_transited_realms */ + ipadb_check_transited_realms, /* check_transited_realms */ ipadb_check_policy_as, /* check_policy_as */ NULL, /* check_policy_tgs */ ipadb_audit_as_req, /* audit_as_req */ diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h index f4d3555..1c2aefc 100644 --- a/daemons/ipa-kdb/ipa_kdb.h +++ b/daemons/ipa-kdb/ipa_kdb.h @@ -253,7 +253,10 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx, bool force_reinit); void ipadb_mspac_struct_free(struct ipadb_mspac **mspac); - +krb5_error_code ipadb_check_transited_realms(krb5_context kcontext, + const krb5_data *tr_contents, + const krb5_data *client_realm, + const krb5_data *server_realm); /* DELEGATION CHECKS */ krb5_error_code ipadb_check_allowed_to_delegate(krb5_context kcontext, diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 08b55af..589d5d0 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -2490,3 +2490,65 @@ done: ldap_msgfree(result); return kerr; } + +krb5_error_code ipadb_check_transited_realms(krb5_context kcontext, + const krb5_data *tr_contents, + const krb5_data *client_realm, + const krb5_data *server_realm) +{ + struct ipadb_context *ipactx; + bool has_transited_contents, has_client_realm, has_server_realm; + int i; + krb5_error_code ret; + + ipactx = ipadb_get_context(kcontext); + if (!ipactx || !ipactx->mspac) { + return KRB5_KDB_DBNOTINITED; + } + + has_transited_contents = false; + has_client_realm = false; + has_server_realm = false; + + /* First, compare client or server realm with ours */ + if (strncasecmp(client_realm->data, ipactx->realm, client_realm->length) == 0) { + has_client_realm = true; + } + if (strncasecmp(server_realm->data, ipactx->realm, server_realm->length) == 0) { + has_server_realm = true; + } + + if ((tr_contents->length == 0) || (tr_contents->data[0] == '\0')) { + /* For in-realm case allow transition */ + if (has_client_realm && has_server_realm) { + return 0; + } + return KRB5_PLUGIN_NO_HANDLE; + } + + if (!ipactx->mspac || !ipactx->mspac->trusts) { + return KRB5_PLUGIN_NO_HANDLE; + } + + /* Iterate through list of trusts and check if any of input belongs to any of the trust */ + for(i=0; i < ipactx->mspac->num_trusts ; i++) { + if (!has_transited_contents && + (strncasecmp(tr_contents->data, ipactx->mspac->trusts[i].domain_name, tr_contents->length) == 0)) { + has_transited_contents = true; + } + if (!has_client_realm && + (strncasecmp(client_realm->data, ipactx->mspac->trusts[i].domain_name, client_realm->length) == 0)) { + has_client_realm = true; + } + if (!has_server_realm && + (strncasecmp(server_realm->data, ipactx->mspac->trusts[i].domain_name, server_realm->length) == 0)) { + has_server_realm = true; + } + } + + ret = KRB5KRB_AP_ERR_ILL_CR_TKT; + if (has_client_realm && has_transited_contents && has_server_realm) { + ret = 0; + } + return ret; +} -- 1.8.3.1 -------------- next part -------------- >From 7911e753244699b49cb7b8808f5e4bf9f819afda Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 3 Oct 2013 12:30:44 +0200 Subject: [PATCH 8/8] ipa-kdb: Handle parent-child relationship for subdomains When MS-PAC information is re-initialized, record also parent-child relationship between trust root level domain and its subdomains. Use parent incoming SID black list to check if child domain is not allowed to access IPA realm. We also should really use 'cn' of the entry as domain name. ipaNTTrustPartner has different meaning on wire, it is an index pointing to the parent domain of the domain and will be 0 for top level domains or disjoint subdomains of the trust. Finally, trustdomain-enable and trustdomain-disable commands should force MS-PAC cache re-initalization in case of black list change. Trigger that by asking for cross-realm TGT for HTTP service. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 109 ++++++++++++++++++++++++++++++++++++---- ipalib/plugins/trust.py | 6 +++ 2 files changed, 105 insertions(+), 10 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 589d5d0..af20966 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -37,6 +37,8 @@ struct ipadb_adtrusts { int len_sid_blacklist_incoming; struct dom_sid *sid_blacklist_outgoing; int len_sid_blacklist_outgoing; + struct ipadb_adtrusts *parent; + char *parent_name; }; struct ipadb_mspac { @@ -1359,6 +1361,18 @@ static krb5_error_code filter_logon_info(krb5_context context, return EINVAL; } + /* Check if this domain has been filtered out by the trust itself*/ + if (domain->parent != NULL) { + for(k = 0; k < domain->parent->len_sid_blacklist_incoming; k++) { + result = dom_sid_check(info->info->info3.base.domain_sid, + &domain->parent->sid_blacklist_incoming[k], true); + if (result) { + filter_logon_info_log_message(info->info->info3.base.domain_sid); + return EINVAL; + } + } + } + /* According to MS-KILE 25.0, info->info->info3.sids may be non zero, so check * should include different possibilities into account * */ @@ -2121,6 +2135,8 @@ void ipadb_mspac_struct_free(struct ipadb_mspac **mspac) free((*mspac)->trusts[i].domain_sid); free((*mspac)->trusts[i].sid_blacklist_incoming); free((*mspac)->trusts[i].sid_blacklist_outgoing); + free((*mspac)->trusts[i].parent_name); + (*mspac)->trusts[i].parent = NULL; } free((*mspac)->trusts); } @@ -2209,18 +2225,42 @@ done: return ret; } +static void ipadb_free_sid_blacklists(char ***sid_blacklist_incoming, char ***sid_blacklist_outgoing) +{ + int i; + + if (sid_blacklist_incoming && *sid_blacklist_incoming) { + for (i = 0; *sid_blacklist_incoming && (*sid_blacklist_incoming)[i]; i++) { + free((*sid_blacklist_incoming)[i]); + } + free(*sid_blacklist_incoming); + *sid_blacklist_incoming = NULL; + } + + if (sid_blacklist_outgoing && *sid_blacklist_outgoing) { + for (i = 0; *sid_blacklist_outgoing && (*sid_blacklist_outgoing)[i]; i++) { + free((*sid_blacklist_outgoing)[i]); + } + free(*sid_blacklist_outgoing); + *sid_blacklist_outgoing = NULL; + } +} + krb5_error_code ipadb_mspac_get_trusted_domains(struct ipadb_context *ipactx) { struct ipadb_adtrusts *t; LDAP *lc = ipactx->lcontext; - char *attrs[] = { "ipaNTTrustPartner", "ipaNTFlatName", + char *attrs[] = { "cn", "ipaNTTrustPartner", "ipaNTFlatName", "ipaNTTrustedDomainSID", "ipaNTSIDBlacklistIncoming", "ipaNTSIDBlacklistOutgoing", NULL }; char *filter = "(objectclass=ipaNTTrustedDomain)"; krb5_error_code kerr; LDAPMessage *res = NULL; LDAPMessage *le; + LDAPRDN rdn; char *base = NULL; + char *dnstr = NULL; + char *dnl = NULL; char **sid_blacklist_incoming = NULL; char **sid_blacklist_outgoing = NULL; int ret, n, i; @@ -2243,6 +2283,13 @@ krb5_error_code ipadb_mspac_get_trusted_domains(struct ipadb_context *ipactx) } for (le = ldap_first_entry(lc, res); le; le = ldap_next_entry(lc, le)) { + dnstr = ldap_get_dn(lc, le); + + if (dnstr == NULL) { + ret = ENOMEM; + goto done; + } + n = ipactx->mspac->num_trusts; ipactx->mspac->num_trusts++; t = realloc(ipactx->mspac->trusts, @@ -2253,7 +2300,9 @@ krb5_error_code ipadb_mspac_get_trusted_domains(struct ipadb_context *ipactx) } ipactx->mspac->trusts = t; - ret = ipadb_ldap_attr_to_str(lc, le, "ipaNTTrustPartner", + memset(&t[n], 0, sizeof(t[n])); + + ret = ipadb_ldap_attr_to_str(lc, le, "cn", &t[n].domain_name); if (ret) { ret = EINVAL; @@ -2287,6 +2336,7 @@ krb5_error_code ipadb_mspac_get_trusted_domains(struct ipadb_context *ipactx) if (ret == ENOENT) { /* This attribute is optional */ ret = 0; + sid_blacklist_incoming = NULL; } else { ret = EINVAL; goto done; @@ -2300,6 +2350,7 @@ krb5_error_code ipadb_mspac_get_trusted_domains(struct ipadb_context *ipactx) if (ret == ENOENT) { /* This attribute is optional */ ret = 0; + sid_blacklist_outgoing = NULL; } else { ret = EINVAL; goto done; @@ -2312,6 +2363,49 @@ krb5_error_code ipadb_mspac_get_trusted_domains(struct ipadb_context *ipactx) if (ret) { goto done; } + ipadb_free_sid_blacklists(&sid_blacklist_incoming, + &sid_blacklist_outgoing); + + /* Parse first two RDNs of the entry to find its parent */ + dnl = strcasestr(dnstr, base); + if (dnl == NULL) { + goto done; + } + + /* Note that after ldap_str2rdn() call dnl will point to end of one RDN + * which would be '\0' for trust root domain and ',' for subdomain */ + dnl--; dnl[0] = '\0'; + ret = ldap_str2rdn(dnstr, &rdn, &dnl, LDAP_DN_FORMAT_LDAPV3); + if (ret) { + goto done; + } + + ldap_rdnfree(rdn); + + if (dnl[0] != '\0') { + dnl++; + ret = ldap_str2rdn(dnl, &rdn, &dnl, LDAP_DN_FORMAT_LDAPV3); + if (ret) { + goto done; + } + t[n].parent_name = strndup(rdn[0]->la_value.bv_val, rdn[0]->la_value.bv_len); + ldap_rdnfree(rdn); + } + + free(dnstr); + dnstr = NULL; + } + + /* Traverse through all trusts and resolve parents */ + t = ipactx->mspac->trusts; + for (i = 0; i < ipactx->mspac->num_trusts; i++) { + if (t[i].parent_name != NULL) { + for (n = 0; n < ipactx->mspac->num_trusts; n++) { + if (strcasecmp(t[i].parent_name, t[n].domain_name) == 0) { + t[i].parent = &t[n]; + } + } + } } ret = 0; @@ -2320,15 +2414,10 @@ done: if (ret != 0) { krb5_klog_syslog(LOG_ERR, "Failed to read list of trusted domains"); } + free(dnstr); free(base); - for (i = 0; sid_blacklist_incoming && sid_blacklist_incoming[i]; i++) { - free(sid_blacklist_incoming[i]); - } - free(sid_blacklist_incoming); - for (i = 0; sid_blacklist_outgoing && sid_blacklist_outgoing[i]; i++) { - free(sid_blacklist_outgoing[i]); - } - free(sid_blacklist_outgoing); + ipadb_free_sid_blacklists(&sid_blacklist_incoming, + &sid_blacklist_outgoing); ldap_msgfree(res); return ret; } diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 88d67eb..151aa42 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -1301,6 +1301,9 @@ class trustdomain_enable(LDAPQuery): trust_entry['ipantsidblacklistincoming'].remove(sid) result['action'] = _('is allowed') ldap.update_entry(trust_entry) + # Force MS-PAC cache re-initialization on KDC side + domval = ipaserver.dcerpc.DomainValidator(api) + (ccache_name, principal) = domval.kinit_as_http(keys[0]) else: result['action'] = _('is already allowed') result['summary'] = _('Domain %(domain)s of trust %(trust)s %(action)s to access IPA resources') @@ -1345,6 +1348,9 @@ class trustdomain_disable(LDAPQuery): trust_entry['ipantsidblacklistincoming'].append(sid) result['action'] = _('is not allowed') ldap.update_entry(trust_entry) + # Force MS-PAC cache re-initialization on KDC side + domval = ipaserver.dcerpc.DomainValidator(api) + (ccache_name, principal) = domval.kinit_as_http(keys[0]) else: result['action'] = _('is already not allowed') result['summary'] = _('Domain %(domain)s of trust %(trust)s %(action)s to access IPA resources') -- 1.8.3.1 From mkosek at redhat.com Thu Oct 3 13:22:16 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 03 Oct 2013 15:22:16 +0200 Subject: [Freeipa-devel] [PATCH] 423 Do not set DNS discovery domain in server mode Message-ID: <524D6F88.6030604@redhat.com> In server mode, the discovery domain should be left unset in all cases as the DNS discovery is only driven by the AD domains. https://fedorahosted.org/freeipa/ticket/3947 --- Pushed as a (tested) one-liner to master, ipa-3-3. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-423-do-not-set-dns-discovery-domain-in-server-mode.patch Type: text/x-patch Size: 1256 bytes Desc: not available URL: From pviktori at redhat.com Thu Oct 3 15:44:16 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 03 Oct 2013 17:44:16 +0200 Subject: [Freeipa-devel] [PATCHES] 170-171 Allow PKCS#12 files with empty password in install tools In-Reply-To: <524D51C2.6090006@redhat.com> References: <5242A2D9.10304@redhat.com> <524D51C2.6090006@redhat.com> Message-ID: <524D90D0.1060309@redhat.com> On 10/03/2013 01:15 PM, Petr Viktorin wrote: > On 09/25/2013 10:46 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patches fix . >> >> Honza >> > > I'm still testing; it looks good except for unattended installs. With > the attached fixup squashed in it works so far. Another problem is that the change pkcs12_info (password instead of filename) was not done in ipa-replica-install. Here is another fixup to correct this. Also, I'm attaching tests I used for this. If these changes look OK to you, then it's an ACK. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: fixup-Allow-PKCS-12-files-with-empty-password-in-ins.patch Type: text/x-patch Size: 1399 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fixup-Read-passwords-from-stdin-when-importing-PKCS-.patch Type: text/x-patch Size: 3128 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0305-Add-tests-for-installing-with-empty-PKCS-12-password.patch Type: text/x-patch Size: 8782 bytes Desc: not available URL: From pvoborni at redhat.com Thu Oct 3 15:51:12 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 03 Oct 2013 17:51:12 +0200 Subject: [Freeipa-devel] [DOC] Chapter 4 text In-Reply-To: <1380795133.2201.0.camel@unused-4-145.brq.redhat.com> References: <1379517057.9269.7.camel@unused-4-145.brq.redhat.com> <1380297179.2116.20.camel@unused-4-145.brq.redhat.com> <524ADC2E.2040805@redhat.com> <1380795133.2201.0.camel@unused-4-145.brq.redhat.com> Message-ID: <524D9270.1000906@redhat.com> On 10/03/2013 12:12 PM, Martin Basti wrote: > On Tue, 2013-10-01 at 16:29 +0200, Petr Vobornik wrote: >> On 09/27/2013 05:52 PM, Martin Basti wrote: >>> On Wed, 2013-09-18 at 17:10 +0200, Martin Basti wrote: >>>> Patch fix examples in chapter 4, adds new examples, fix out of date >>>> information. >>>> >>>> NOTE: Patch doesn't cover part 4.3 Logging with web UI >> >>> Updated patch >>> >> >> NACK >> >>>> 1. Table 4.1. Configuration Areas Per Tab is missing Trusts in IPA tab. This menu item is visible only if ipa-adtrust-install was run. >> >>> + Trusts (shown if AD-trust exists) >> >> ipa-adtrust-install was run != AD-trust exists >> >> From ipa-adtrust-install man page: >> ipa-adtrust-install - Prepare an IPA server to be able to establish >> trust relationships with AD domains > Fixed > > Updated patch attached > ACK -- Petr Vobornik From jcholast at redhat.com Thu Oct 3 15:57:46 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 03 Oct 2013 17:57:46 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <524D1FBB.90008@redhat.com> References: <52161568.7060702@redhat.com> <5232D20C.9050204@redhat.com> <5232D290.40504@redhat.com> <5232D563.3050500@redhat.com> <524AA4A0.6040801@redhat.com> <851875259.658384.1380657433774.JavaMail.root@redhat.com> <524B2BBD.20104@redhat.com> <524BEF8A.5000309@redhat.com> <1052675559.288505.1380712236557.JavaMail.root@redhat.com> <524D1FBB.90008@redhat.com> Message-ID: <524D93FA.3020407@redhat.com> On 3.10.2013 09:41, Stef Walter wrote: > On 02.10.2013 13:10, Simo Sorce wrote: >> >> >> ----- Original Message ----- >>> On 1.10.2013 22:08, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> ----- Original Message ----- >>>>>> On 13.9.2013 11:05, Jan Cholasta wrote: >>>>>>> On 13.9.2013 10:53, Martin Kosek wrote: >>>>>>>> On 09/13/2013 10:51 AM, Jan Cholasta wrote: >>>>>>>>> On 5.9.2013 10:28, Jan Cholasta wrote: >>>>>>>>>> On 3.9.2013 18:16, Dmitri Pal wrote: >>>>>>>>>>> On 09/02/2013 04:49 AM, Petr Spacek wrote: >>>>>>>>>>>> It reminds me problems with key-rotation for DNSSEC. >>>>>>>>>>>> >>>>>>>>>>>> Could we find common problems and use the same/similar solution >>>>>>>>>>>> for >>>>>>>>>>>> both problems? >>>>>>>>>>>> >>>>>>>>>>>> An extension for certmonger? Oddjob? Or a completely new daemon? >>>>>>>>>>>> >>>>>>>>>>> Certmonger already has a way to: >>>>>>>>>>> 1) Check things periodically >>>>>>>>>>> 2) Hand certs in different places >>>>>>>>>>> 3) Run post op scripts >>>>>>>>>>> >>>>>>>>>>> IMO it is a good candidate but I would leave it to Nalin to >>>>>>>>>>> chime in. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I would expect more things that require periodic checking on clients >>>>>>>>>> beyond certificates to come in the future, so I'm not sure if doing >>>>>>>>>> this >>>>>>>>>> in certmonger is the right thing to do. Also, SSSD already does a >>>>>>>>>> similar thing for realm domains, right? >>>>>>>> >>>>>>>> Are you suggesting extending SSSD to handle that? >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>> Honza >>>>>>>>>> >>>>>>>>> >>>>>>>>> So, does anyone have any strong opinions on this? >>>>>>>> >>>>>>>> Not at this point. BTW, is there any reason why we cannot go the >>>>>>>> simple way and >>>>>>>> just utilize cron and a script? Previously we just dropped conf to >>>>>>>> /etc/cron.d >>>>>>>> for ipa-compliance script and it worked quite well. >>>>>>> >>>>>>> Hmm, that's so simple it might just work. At least until there is a >>>>>>> better way. >>>>>> >>>>>> I have been thinking about this for some time now and came up with this >>>>>> solution: >>>>>> >>>>>> Write a library implementing the PKCS#11 API (Cryptoki), which would >>>>>> provide the shared CA certificates and associated information >>>>>> (nicknames, trust flags). The library would get the certificates from >>>>>> SSSD, which in turn would get them from IPA (and do the usual stuff like >>>>>> caching). >>>>>> >>>>>> This library could then be used by IPA NSS databases as a source of >>>>>> trust information for IPA services (see modutil). It could also be used >>>>>> by p11-glue to provide the trust information to the rest of the system. >>>>>> >>>>>> Pros: >>>>>> * Automatic support for getting trust information stored in IPA in >>>>>> all the applications that understand PKCS#11. >>>>>> * Certificates are fetched from IPA on-demand, not periodically like >>>>>> in the previous solutions. >>>>>> >>>>>> Cons: >>>>>> * Complexity of implementation? (I don't know about this one, I >>>>>> briefly looked at the source code of the p11-kit PKCS#11 module and it >>>>>> looked manageable to me.) >>>>>> >>>>>> Does this sound reasonable? >>>>> >>>>> >>>>> Sounds reasonable to me, however I assume you will do some caching, >>>>> both to avoid lenghty waits and to handle offline cases, so I'd like >>>>> to know more how/when you are going to use the caches vs fetching the >>>>> cert chains from the server. >>> >>> I was thinking about using algorithm like this when SSSD receives the >>> request: >>> >>> if certs in cache: >>> if cache last update time + delta < now: >>> if certs were update on server: # lastUSN check >>> remove certs from cache >>> else: >>> cache last update time = now >>> if certs not in cache: >>> get certs from server >>> store certs in cache >>> cache last update time = now >>> return certs in cache >>> >>> The delta would be a configurable option, defaulting to some reasonable >>> value (1 hour? more? less?) >>> >>>> >>>> For on-demand, what are we talking about, fetching the cert when the >>>> module is loaded? Or whenever someone wants to use (e.g. validate) the >>>> cert? >>> >>> Something in between - the module would request the certificates from >>> SSSD when a PKCS#11 session is opened and keep them in memory until the >>> session is closed. The point is to always have the same data between >>> PKCS#11 object management calls. >>> >>>> >>>> How often will this cert change, after all? >>> >>> Not often. Why? >>> >>>> >>>> What would the load be like? Is it fatal if the cert can't be obtained? >>> >>> The module could either return an error to the user when the certs can't >>> be obtained, or return whatever is in the cache. I'm not sure which is >>> better, but I'm leaning towards returning whatever is in the cache, >>> since this must work even when the client system is offline. >> >> I think the cache should just be ca.crt files though, in this case, not the >> ldb modules cache. As some people wipe it out for various reasons. >> The main issue here is a chicken-egg issue if you are using LDAP(S) to >> connect to the server and you ned the CA cert to validate the server cert. >> You do not want to lock yourself out by wiping valid ca certs. My plan was to synchronize the certificates from SSSD to IPA files (/etc/ipa/ca.crt, /etc/pki/nssdb, /etc/httpd/alias, /etc/dirsrv/slapd-REALM) periodically and do it only if the SSSD cache is valid, i.e. when it is not empty and a successful attempt to retrieve the certificates from server was made. This means that if the user deleted the cache, the certificates would still be there in the files. > > Then you can just add them to the p11-kit-trust module using the trust > tool (or I could build an API for that): > > # trust anchor --store /path/to/ca.crt > > By the way, even with PKCS#11, just having the certificates in place, > it's also necessary to add the appropriate trust flags and so on so that > these are trusted as anchors. > > The above also handles callers that don't yet support PKCS#11 for > accessing trusted anchors. > > Cheers, > > Stef > If I can somehow use p11-kit to help me, cool! Is there any support for separate trust databases? I would like client systems to trust the CA certificates from IPA, but I would like IPA services to trust *only* the CA certificates from IPA. Honza -- Jan Cholasta From mkosek at redhat.com Thu Oct 3 16:04:24 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 03 Oct 2013 18:04:24 +0200 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <20131003131052.GV4216@redhat.com> References: <20130923141841.GS4216@redhat.com> <20130923150422.GT4216@redhat.com> <20130927125308.GD4216@redhat.com> <20130927163121.GM10000@localhost.localdomain> <20130928200134.GF4216@redhat.com> <52495AEB.7000204@redhat.com> <20130930123143.GJ4216@redhat.com> <20131001151509.GP4216@redhat.com> <524C8299.9040801@redhat.com> <20131002210453.GF10000@localhost.localdomain> <20131003131052.GV4216@redhat.com> Message-ID: <524D9588.9050006@redhat.com> On 10/03/2013 03:10 PM, Alexander Bokovoy wrote: > On Wed, 02 Oct 2013, Sumit Bose wrote: >>> Please note that I did not test with more than 1 subdomain, since I >>> do not have more ADs available. >>> >> >> I have done some testing as well and the patches are working as expected >> except the trustdomain-disable issue Tomas mentioned. But I think it >> would be sufficient to add a comment to the release notes and fix this >> with the next release to not delay this release anymore. >> >> The patches are also working for trusts which were added with older >> releases. So ACK from my side for the functional part. > New patchset is attached. I've fixed all outstanding issues and > implemented proper SID filtering for subdomains. In addition, I've > added MS-PAC cache eviction when we change blacklists from IPA side > and forced removal of the domain from SID blacklist if the domain is > being removed by trustdomain-del. > 1) Minor issue in 0118: + if keys[0].lower() == keys[1].lower(): + raise errors.ValidationError(name='trustdomain_enable', + error=_("Root domain of the trust is always enabled for the existing trust")) The error message looks weird (double trustdomain_enable) # ipa trustdomain-enable realm domain ipa: ERROR: invalid 'trustdomain_enable': Root domain of the trust is always enabled for the existing trust I would rather do something like + raise errors.ValidationError(name='domain', 2) trustconfig-enable and trustconfig-disable should use standard output like other enable/disable methods. See user-enable/user-disable for example. Current situation puts all the authoritative information to summary which: a) Does not look nice in terminal # ipa trustdomain-disable very.long.long.long.realm very.long.long.long.domain ---------------------------------------------------------------------------------------------------------------------------- Domain very.long.long.long.domain of trust very.long.long.long.realm is not allowed to access IPA resources ---------------------------------------------------------------------------------------------------------------------------- b) How am I supposed to parse an information about the result if all I get is a text in summary? Using standard errors and output values will allow easier consumption of the API later (like in Web UI). I am attaching a patch (0001) how to make it consistent with other enable/disable commands. Example: # ipa trustdomain-disable realm domain ipa: ERROR: This entry is already disabled # ipa trustdomain-enable realm domain ----------------------------- Enabled trust domain "domain" ----------------------------- 3) Let's use standard primary key for the trustdomain object. This will let us overcome some hacks and also let us use handle_not_found method - patch attached (0002). 0002 also changes some ValidationError errors to standard errors, just for being consistent with the rest of the API. Note that in order to make primary_key=True, I had to enhance trustdomain_del command to manage multiple domains. I think these API fixes are a must, it would be very hard to amend the API later. If these patches are squashed to your 0118, it would be ACK from me to the Python side. I will let C parts and a functional test to Sumit's mighty hands. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-trustdomain-enable-and-trustdomain-disable-outp.patch Type: text/x-patch Size: 5356 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Use-primary_key-instead-of-custom-args.patch Type: text/x-patch Size: 7242 bytes Desc: not available URL: From pvoborni at redhat.com Thu Oct 3 16:49:46 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 03 Oct 2013 18:49:46 +0200 Subject: [Freeipa-devel] [PATCHES] 0278-0279 Make it possible to run integration tests without Paramiko In-Reply-To: <523980B5.8030300@redhat.com> References: <523980B5.8030300@redhat.com> Message-ID: <524DA02A.1090108@redhat.com> On 09/18/2013 12:30 PM, Petr Viktorin wrote: > Hello, > These patches take the SSH2 bits out of the integration tests' Host > class into a Transport class, and add a new Transport that uses > /usr/bin/ssh to talk with remote hosts. > The Host class is broken up to help adding AD trust tests (see Tom??'s > patches 100-106, the WinHost addition can be simplified now; in the > future adding e.g. a telnet transport should be easier). > > The spec file is not changed, I believe Paramiko is a better default for > Fedora. > The OpenSSH transport can be selected by setting > IPA_TEST_SSH_TRANSPORT=openssh. > > https://fedorahosted.org/freeipa/ticket/3890 > > ACK -- Petr Vobornik From pvoborni at redhat.com Thu Oct 3 16:50:38 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 03 Oct 2013 18:50:38 +0200 Subject: [Freeipa-devel] [PATCHES] 0282-0286 Test improvements In-Reply-To: <5241B2EA.30907@redhat.com> References: <5241B2EA.30907@redhat.com> Message-ID: <524DA05E.4000204@redhat.com> On 09/24/2013 05:42 PM, Petr Viktorin wrote: > Hello, > These patches fix issues in the test suite, mainly those in BeakerLib > integration. > > > Patch 0282: > When requested logs don't exist, tests shouldn't fail. The BeakerLib > plugin was too strict here. > > Patch 0283: > The Ordered plugin does not play well with generators: the generated > tests are run, but they're not reported plugins' hooks (startTest etc.). > I spent some time looking for ways to correct this, but was unsuccessful. > The patch disables ordering for test generators (relative to the methods > of a class -- the tests from one generator still run in the generated > order). > With this the BeakerLib plugin will report generated tests. > > Patch 0284: > This adds arguments to "test names" that the BeakerLib plugin gives to > generated tests. > The patch only adds the names to the integration tests. As it becomes > possible to run the rest of the suite out-of-tree, I can add them to the > other test generators as well. > > Patch 0285: > This just adds logging to Host.ldap_connect. > > Patch 0285: > Correct the CLITestContext context manager used in help tests to > re-raise unexpected exceptions. > > > Except 0283/0284, these can be reviewed/applied individually. > ACK for 0282, 0283, 0284, 0286 NACK for 0285 - this patch has two issues: - doesn't apply on top of paramiko patches (pvi-0278) - has incorrect log usage: self.log("something") instead of self.log.debug("something") or self.log.info("something"), ... Attaching patch which replaces 0285 and applies on top of pviktorin-0278. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0461-ipatests.test_integration.host-Add-logging-to-ldap_c.patch Type: text/x-patch Size: 1191 bytes Desc: not available URL: From pviktori at redhat.com Thu Oct 3 17:56:06 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 03 Oct 2013 19:56:06 +0200 Subject: [Freeipa-devel] [PATCHES] 0282-0286 Test improvements In-Reply-To: <524DA05E.4000204@redhat.com> References: <5241B2EA.30907@redhat.com> <524DA05E.4000204@redhat.com> Message-ID: <524DAFB6.1060800@redhat.com> On 10/03/2013 06:50 PM, Petr Vobornik wrote: > On 09/24/2013 05:42 PM, Petr Viktorin wrote: >> Hello, >> These patches fix issues in the test suite, mainly those in BeakerLib >> integration. >> >> >> Patch 0282: >> When requested logs don't exist, tests shouldn't fail. The BeakerLib >> plugin was too strict here. >> >> Patch 0283: >> The Ordered plugin does not play well with generators: the generated >> tests are run, but they're not reported plugins' hooks (startTest etc.). >> I spent some time looking for ways to correct this, but was unsuccessful. >> The patch disables ordering for test generators (relative to the methods >> of a class -- the tests from one generator still run in the generated >> order). >> With this the BeakerLib plugin will report generated tests. >> >> Patch 0284: >> This adds arguments to "test names" that the BeakerLib plugin gives to >> generated tests. >> The patch only adds the names to the integration tests. As it becomes >> possible to run the rest of the suite out-of-tree, I can add them to the >> other test generators as well. >> >> Patch 0285: >> This just adds logging to Host.ldap_connect. >> >> Patch 0285: >> Correct the CLITestContext context manager used in help tests to >> re-raise unexpected exceptions. >> >> >> Except 0283/0284, these can be reviewed/applied individually. >> > > ACK for 0282, 0283, 0284, 0286 > > NACK for 0285 - this patch has two issues: > - doesn't apply on top of paramiko patches (pvi-0278) > - has incorrect log usage: self.log("something") instead of > self.log.debug("something") or self.log.info("something"), ... > > Attaching patch which replaces 0285 and applies on top of pviktorin-0278. > Thanks, ACK to that. I found one more bug, pushing as one-liner. Pushed to: master: ef2d61faa2d76924fb20b0883da03b4e9f7087a4 ipa-3-3: f4c022a9cad559167d15625430f37897d601ea85 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0306-ipatests.test_integration.test_caless-Fix-mkdir_recu.patch Type: text/x-patch Size: 1065 bytes Desc: not available URL: From npmccallum at redhat.com Thu Oct 3 21:43:20 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 3 Oct 2013 17:43:20 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <1552467225.1129348.1380836560481.JavaMail.root@redhat.com> Message-ID: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0019-Prefer-TCP-connections-to-UDP-in-krb5-clients.patch Type: text/x-patch Size: 3312 bytes Desc: not available URL: From sbose at redhat.com Thu Oct 3 21:54:08 2013 From: sbose at redhat.com (Sumit Bose) Date: Thu, 3 Oct 2013 23:54:08 +0200 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <524D9588.9050006@redhat.com> References: <20130927125308.GD4216@redhat.com> <20130927163121.GM10000@localhost.localdomain> <20130928200134.GF4216@redhat.com> <52495AEB.7000204@redhat.com> <20130930123143.GJ4216@redhat.com> <20131001151509.GP4216@redhat.com> <524C8299.9040801@redhat.com> <20131002210453.GF10000@localhost.localdomain> <20131003131052.GV4216@redhat.com> <524D9588.9050006@redhat.com> Message-ID: <20131003215407.GI10000@localhost.localdomain> On Thu, Oct 03, 2013 at 06:04:24PM +0200, Martin Kosek wrote: > On 10/03/2013 03:10 PM, Alexander Bokovoy wrote: > > On Wed, 02 Oct 2013, Sumit Bose wrote: > >>> Please note that I did not test with more than 1 subdomain, since I > >>> do not have more ADs available. > >>> > >> > >> I have done some testing as well and the patches are working as expected > >> except the trustdomain-disable issue Tomas mentioned. But I think it > >> would be sufficient to add a comment to the release notes and fix this > >> with the next release to not delay this release anymore. > >> > >> The patches are also working for trusts which were added with older > >> releases. So ACK from my side for the functional part. > > New patchset is attached. I've fixed all outstanding issues and > > implemented proper SID filtering for subdomains. In addition, I've > > added MS-PAC cache eviction when we change blacklists from IPA side > > and forced removal of the domain from SID blacklist if the domain is > > being removed by trustdomain-del. > > > > 1) Minor issue in 0118: > > + if keys[0].lower() == keys[1].lower(): > + raise errors.ValidationError(name='trustdomain_enable', > + error=_("Root domain of the trust is always enabled for the > existing trust")) > > The error message looks weird (double trustdomain_enable) > > # ipa trustdomain-enable realm domain > ipa: ERROR: invalid 'trustdomain_enable': Root domain of the trust is always > enabled for the existing trust > > I would rather do something like > > + raise errors.ValidationError(name='domain', > > > 2) trustconfig-enable and trustconfig-disable should use standard output like > other enable/disable methods. See user-enable/user-disable for example. Current > situation puts all the authoritative information to summary which: > a) Does not look nice in terminal > # ipa trustdomain-disable very.long.long.long.realm very.long.long.long.domain > ---------------------------------------------------------------------------------------------------------------------------- > Domain very.long.long.long.domain of trust very.long.long.long.realm is not > allowed to access IPA resources > ---------------------------------------------------------------------------------------------------------------------------- > b) How am I supposed to parse an information about the result if all I get is a > text in summary? Using standard errors and output values will allow easier > consumption of the API later (like in Web UI). > > I am attaching a patch (0001) how to make it consistent with other > enable/disable commands. Example: > > # ipa trustdomain-disable realm domain > ipa: ERROR: This entry is already disabled > > # ipa trustdomain-enable realm domain > ----------------------------- > Enabled trust domain "domain" > ----------------------------- > > 3) Let's use standard primary key for the trustdomain object. This will let us > overcome some hacks and also let us use handle_not_found method - patch > attached (0002). > > 0002 also changes some ValidationError errors to standard errors, just for > being consistent with the rest of the API. > > Note that in order to make primary_key=True, I had to enhance trustdomain_del > command to manage multiple domains. > > > I think these API fixes are a must, it would be very hard to amend the API > later. If these patches are squashed to your 0118, it would be ACK from me to > the Python side. I will let C parts and a functional test to Sumit's mighty hands. Functional it is an ACK to all patches except 0123. The trustdomain-disabled issue found by Tomas is fixed with 0124. Patch 0123 is not needed and breaks setups with unpatched MIT Kerberos, which currently are more or less all. It does not allow users from the trusted forest root to get tickets for the IPA domain. In this case the TGT does not have any transited data, because it is a direct trust, but the client realm is not ours. So the plugin returns KRB5_PLUGIN_NO_HANDLE which is interpreted as an error in current MIT Kerberos versions. I would recommend to just drop the patch for this release and include an improved version in the next. Patch 0124 look good although the new parent_name member looks a bit useless to me. I also find the name ipadb_free_sid_blacklists() a bit irritating because it is not clear (from the name) if it should be used to free the lists of SID strings or of struct dom_sid. But both can be fixed (if needed) later when we touch this part of the code again to include support for transitively trusted forests. bye, Sumit > > Martin From abokovoy at redhat.com Fri Oct 4 05:40:00 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 4 Oct 2013 08:40:00 +0300 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <524D9588.9050006@redhat.com> References: <20130927125308.GD4216@redhat.com> <20130927163121.GM10000@localhost.localdomain> <20130928200134.GF4216@redhat.com> <52495AEB.7000204@redhat.com> <20130930123143.GJ4216@redhat.com> <20131001151509.GP4216@redhat.com> <524C8299.9040801@redhat.com> <20131002210453.GF10000@localhost.localdomain> <20131003131052.GV4216@redhat.com> <524D9588.9050006@redhat.com> Message-ID: <20131004054000.GW4216@redhat.com> On Thu, 03 Oct 2013, Martin Kosek wrote: >On 10/03/2013 03:10 PM, Alexander Bokovoy wrote: >> On Wed, 02 Oct 2013, Sumit Bose wrote: >>>> Please note that I did not test with more than 1 subdomain, since I >>>> do not have more ADs available. >>>> >>> >>> I have done some testing as well and the patches are working as expected >>> except the trustdomain-disable issue Tomas mentioned. But I think it >>> would be sufficient to add a comment to the release notes and fix this >>> with the next release to not delay this release anymore. >>> >>> The patches are also working for trusts which were added with older >>> releases. So ACK from my side for the functional part. >> New patchset is attached. I've fixed all outstanding issues and >> implemented proper SID filtering for subdomains. In addition, I've >> added MS-PAC cache eviction when we change blacklists from IPA side >> and forced removal of the domain from SID blacklist if the domain is >> being removed by trustdomain-del. >> > >1) Minor issue in 0118: > >+ if keys[0].lower() == keys[1].lower(): >+ raise errors.ValidationError(name='trustdomain_enable', >+ error=_("Root domain of the trust is always enabled for the >existing trust")) > >The error message looks weird (double trustdomain_enable) > ># ipa trustdomain-enable realm domain >ipa: ERROR: invalid 'trustdomain_enable': Root domain of the trust is always >enabled for the existing trust > >I would rather do something like > >+ raise errors.ValidationError(name='domain', > > >2) trustconfig-enable and trustconfig-disable should use standard output like >other enable/disable methods. See user-enable/user-disable for example. Current >situation puts all the authoritative information to summary which: >a) Does not look nice in terminal ># ipa trustdomain-disable very.long.long.long.realm very.long.long.long.domain >---------------------------------------------------------------------------------------------------------------------------- >Domain very.long.long.long.domain of trust very.long.long.long.realm is not >allowed to access IPA resources >---------------------------------------------------------------------------------------------------------------------------- >b) How am I supposed to parse an information about the result if all I get is a >text in summary? Using standard errors and output values will allow easier >consumption of the API later (like in Web UI). > >I am attaching a patch (0001) how to make it consistent with other >enable/disable commands. Example: > ># ipa trustdomain-disable realm domain >ipa: ERROR: This entry is already disabled > ># ipa trustdomain-enable realm domain >----------------------------- >Enabled trust domain "domain" >----------------------------- > >3) Let's use standard primary key for the trustdomain object. This will let us >overcome some hacks and also let us use handle_not_found method - patch >attached (0002). > >0002 also changes some ValidationError errors to standard errors, just for >being consistent with the rest of the API. > >Note that in order to make primary_key=True, I had to enhance trustdomain_del >command to manage multiple domains. > > >I think these API fixes are a must, it would be very hard to amend the API >later. If these patches are squashed to your 0118, it would be ACK from me to >the Python side. I will let C parts and a functional test to Sumit's mighty hands. Thanks. I've merged these changes, along with a API.txt correction. In my tests these worked fine. I'll resend 0118 shortly. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Oct 4 05:59:08 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 4 Oct 2013 08:59:08 +0300 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <20131003215407.GI10000@localhost.localdomain> References: <20130927163121.GM10000@localhost.localdomain> <20130928200134.GF4216@redhat.com> <52495AEB.7000204@redhat.com> <20130930123143.GJ4216@redhat.com> <20131001151509.GP4216@redhat.com> <524C8299.9040801@redhat.com> <20131002210453.GF10000@localhost.localdomain> <20131003131052.GV4216@redhat.com> <524D9588.9050006@redhat.com> <20131003215407.GI10000@localhost.localdomain> Message-ID: <20131004055908.GX4216@redhat.com> On Thu, 03 Oct 2013, Sumit Bose wrote: >On Thu, Oct 03, 2013 at 06:04:24PM +0200, Martin Kosek wrote: >> On 10/03/2013 03:10 PM, Alexander Bokovoy wrote: >> > On Wed, 02 Oct 2013, Sumit Bose wrote: >> >>> Please note that I did not test with more than 1 subdomain, since I >> >>> do not have more ADs available. >> >>> >> >> >> >> I have done some testing as well and the patches are working as expected >> >> except the trustdomain-disable issue Tomas mentioned. But I think it >> >> would be sufficient to add a comment to the release notes and fix this >> >> with the next release to not delay this release anymore. >> >> >> >> The patches are also working for trusts which were added with older >> >> releases. So ACK from my side for the functional part. >> > New patchset is attached. I've fixed all outstanding issues and >> > implemented proper SID filtering for subdomains. In addition, I've >> > added MS-PAC cache eviction when we change blacklists from IPA side >> > and forced removal of the domain from SID blacklist if the domain is >> > being removed by trustdomain-del. >> > >> >> 1) Minor issue in 0118: >> >> + if keys[0].lower() == keys[1].lower(): >> + raise errors.ValidationError(name='trustdomain_enable', >> + error=_("Root domain of the trust is always enabled for the >> existing trust")) >> >> The error message looks weird (double trustdomain_enable) >> >> # ipa trustdomain-enable realm domain >> ipa: ERROR: invalid 'trustdomain_enable': Root domain of the trust is always >> enabled for the existing trust >> >> I would rather do something like >> >> + raise errors.ValidationError(name='domain', >> >> >> 2) trustconfig-enable and trustconfig-disable should use standard output like >> other enable/disable methods. See user-enable/user-disable for example. Current >> situation puts all the authoritative information to summary which: >> a) Does not look nice in terminal >> # ipa trustdomain-disable very.long.long.long.realm very.long.long.long.domain >> ---------------------------------------------------------------------------------------------------------------------------- >> Domain very.long.long.long.domain of trust very.long.long.long.realm is not >> allowed to access IPA resources >> ---------------------------------------------------------------------------------------------------------------------------- >> b) How am I supposed to parse an information about the result if all I get is a >> text in summary? Using standard errors and output values will allow easier >> consumption of the API later (like in Web UI). >> >> I am attaching a patch (0001) how to make it consistent with other >> enable/disable commands. Example: >> >> # ipa trustdomain-disable realm domain >> ipa: ERROR: This entry is already disabled >> >> # ipa trustdomain-enable realm domain >> ----------------------------- >> Enabled trust domain "domain" >> ----------------------------- >> >> 3) Let's use standard primary key for the trustdomain object. This will let us >> overcome some hacks and also let us use handle_not_found method - patch >> attached (0002). >> >> 0002 also changes some ValidationError errors to standard errors, just for >> being consistent with the rest of the API. >> >> Note that in order to make primary_key=True, I had to enhance trustdomain_del >> command to manage multiple domains. >> >> >> I think these API fixes are a must, it would be very hard to amend the API >> later. If these patches are squashed to your 0118, it would be ACK from me to >> the Python side. I will let C parts and a functional test to Sumit's mighty hands. > >Functional it is an ACK to all patches except 0123. The >trustdomain-disabled issue found by Tomas is fixed with 0124. > >Patch 0123 is not needed and breaks setups with unpatched MIT Kerberos, >which currently are more or less all. It does not allow users from the >trusted forest root to get tickets for the IPA domain. In this case the >TGT does not have any transited data, because it is a direct trust, but >the client realm is not ours. So the plugin returns >KRB5_PLUGIN_NO_HANDLE which is interpreted as an error in current MIT >Kerberos versions. I would recommend to just drop the patch for this >release and include an improved version in the next. I've fixed 0123 by allowing to proceed with the trust checks in case of empty transited realm and both client and server realms are not ours. The result will be success in case both client and server realms are either our realm or belong to any of the trusted domains. For this case empty transited realm considered a match. For me following cases work now: - principal from our realm asking for ticket of a service in our realm - principal from root level trusted domain asking for a ticket of a service in our realm - principal from a trusted domain asking for a ticket of a service in our realm - principal from our realm asking for a ticket of a service in a root level trusted domain - principal from our realm asking for a ticket of a service in a trusted domain These are supported use cases without your PoC patches, the last one works due to manual configuration file written by SSSD 1.11.3. >Patch 0124 look good although the new parent_name member looks a bit >useless to me. I also find the name ipadb_free_sid_blacklists() a bit >irritating because it is not clear (from the name) if it should be used >to free the lists of SID strings or of struct dom_sid. But both can be >fixed (if needed) later when we touch this part of the code again to >include support for transitively trusted forests. We reallocate trusts array as we parse entries returned by the LDAP query. It means we don't really know complete size of the trusts array in advance. I would need to keep a book aside to record trust name and its parent name to perform resolution later. It would be additional hassle, so I simply added a parent name to the trust struct. I don't think this needs refactoring as it would bring more complexity than warranted. ipadb_free_sid_blacklists() can be renamed to ipadb_free_sid_string_lists() if needed. -- / Alexander Bokovoy -------------- next part -------------- >From 3927619695773abb9882e93584353270aed29699 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Sat, 28 Sep 2013 21:49:57 +0200 Subject: [PATCH 7/8] KDC: implement transition check for trusted domains When client principal requests for a ticket for a server principal and we have to perform transition, check that all three belong to either our domain or the domains we trust through forest trusts. In case all three realms (client, transition, and server) match trusted domains and our domain, issue permission to transition from client realm to server realm. Part of https://fedorahosted.org/freeipa/ticket/3909 --- daemons/ipa-kdb/ipa_kdb.c | 2 +- daemons/ipa-kdb/ipa_kdb.h | 5 +++- daemons/ipa-kdb/ipa_kdb_mspac.c | 63 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 68 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb.c b/daemons/ipa-kdb/ipa_kdb.c index 5e4d047..c807bbc 100644 --- a/daemons/ipa-kdb/ipa_kdb.c +++ b/daemons/ipa-kdb/ipa_kdb.c @@ -602,7 +602,7 @@ kdb_vftabl kdb_function_table = { NULL, /* decrypt_key_data */ NULL, /* encrypt_key_data */ ipadb_sign_authdata, /* sign_authdata */ - NULL, /* check_transited_realms */ + ipadb_check_transited_realms, /* check_transited_realms */ ipadb_check_policy_as, /* check_policy_as */ NULL, /* check_policy_tgs */ ipadb_audit_as_req, /* audit_as_req */ diff --git a/daemons/ipa-kdb/ipa_kdb.h b/daemons/ipa-kdb/ipa_kdb.h index f4d3555..1c2aefc 100644 --- a/daemons/ipa-kdb/ipa_kdb.h +++ b/daemons/ipa-kdb/ipa_kdb.h @@ -253,7 +253,10 @@ krb5_error_code ipadb_sign_authdata(krb5_context context, krb5_error_code ipadb_reinit_mspac(struct ipadb_context *ipactx, bool force_reinit); void ipadb_mspac_struct_free(struct ipadb_mspac **mspac); - +krb5_error_code ipadb_check_transited_realms(krb5_context kcontext, + const krb5_data *tr_contents, + const krb5_data *client_realm, + const krb5_data *server_realm); /* DELEGATION CHECKS */ krb5_error_code ipadb_check_allowed_to_delegate(krb5_context kcontext, diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 08b55af..e20de36 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -2490,3 +2490,66 @@ done: ldap_msgfree(result); return kerr; } + +krb5_error_code ipadb_check_transited_realms(krb5_context kcontext, + const krb5_data *tr_contents, + const krb5_data *client_realm, + const krb5_data *server_realm) +{ + struct ipadb_context *ipactx; + bool has_transited_contents, has_client_realm, has_server_realm; + int i; + krb5_error_code ret; + + ipactx = ipadb_get_context(kcontext); + if (!ipactx || !ipactx->mspac) { + return KRB5_KDB_DBNOTINITED; + } + + has_transited_contents = false; + has_client_realm = false; + has_server_realm = false; + + /* First, compare client or server realm with ours */ + if (strncasecmp(client_realm->data, ipactx->realm, client_realm->length) == 0) { + has_client_realm = true; + } + if (strncasecmp(server_realm->data, ipactx->realm, server_realm->length) == 0) { + has_server_realm = true; + } + + if ((tr_contents->length == 0) || (tr_contents->data[0] == '\0')) { + /* For in-realm case allow transition */ + if (has_client_realm && has_server_realm) { + return 0; + } + /* Since transited realm is empty, we don't need to check for it, it is a direct trust case */ + has_transited_contents = true; + } + + if (!ipactx->mspac || !ipactx->mspac->trusts) { + return KRB5_PLUGIN_NO_HANDLE; + } + + /* Iterate through list of trusts and check if any of input belongs to any of the trust */ + for(i=0; i < ipactx->mspac->num_trusts ; i++) { + if (!has_transited_contents && + (strncasecmp(tr_contents->data, ipactx->mspac->trusts[i].domain_name, tr_contents->length) == 0)) { + has_transited_contents = true; + } + if (!has_client_realm && + (strncasecmp(client_realm->data, ipactx->mspac->trusts[i].domain_name, client_realm->length) == 0)) { + has_client_realm = true; + } + if (!has_server_realm && + (strncasecmp(server_realm->data, ipactx->mspac->trusts[i].domain_name, server_realm->length) == 0)) { + has_server_realm = true; + } + } + + ret = KRB5KRB_AP_ERR_ILL_CR_TKT; + if (has_client_realm && has_transited_contents && has_server_realm) { + ret = 0; + } + return ret; +} -- 1.8.3.1 From abokovoy at redhat.com Fri Oct 4 05:59:45 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 4 Oct 2013 08:59:45 +0300 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <20131004054000.GW4216@redhat.com> References: <20130927163121.GM10000@localhost.localdomain> <20130928200134.GF4216@redhat.com> <52495AEB.7000204@redhat.com> <20130930123143.GJ4216@redhat.com> <20131001151509.GP4216@redhat.com> <524C8299.9040801@redhat.com> <20131002210453.GF10000@localhost.localdomain> <20131003131052.GV4216@redhat.com> <524D9588.9050006@redhat.com> <20131004054000.GW4216@redhat.com> Message-ID: <20131004055945.GY4216@redhat.com> On Fri, 04 Oct 2013, Alexander Bokovoy wrote: >On Thu, 03 Oct 2013, Martin Kosek wrote: >>On 10/03/2013 03:10 PM, Alexander Bokovoy wrote: >>>On Wed, 02 Oct 2013, Sumit Bose wrote: >>>>>Please note that I did not test with more than 1 subdomain, since I >>>>>do not have more ADs available. >>>>> >>>> >>>>I have done some testing as well and the patches are working as expected >>>>except the trustdomain-disable issue Tomas mentioned. But I think it >>>>would be sufficient to add a comment to the release notes and fix this >>>>with the next release to not delay this release anymore. >>>> >>>>The patches are also working for trusts which were added with older >>>>releases. So ACK from my side for the functional part. >>>New patchset is attached. I've fixed all outstanding issues and >>>implemented proper SID filtering for subdomains. In addition, I've >>>added MS-PAC cache eviction when we change blacklists from IPA side >>>and forced removal of the domain from SID blacklist if the domain is >>>being removed by trustdomain-del. >>> >> >>1) Minor issue in 0118: >> >>+ if keys[0].lower() == keys[1].lower(): >>+ raise errors.ValidationError(name='trustdomain_enable', >>+ error=_("Root domain of the trust is always enabled for the >>existing trust")) >> >>The error message looks weird (double trustdomain_enable) >> >># ipa trustdomain-enable realm domain >>ipa: ERROR: invalid 'trustdomain_enable': Root domain of the trust is always >>enabled for the existing trust >> >>I would rather do something like >> >>+ raise errors.ValidationError(name='domain', >> >> >>2) trustconfig-enable and trustconfig-disable should use standard output like >>other enable/disable methods. See user-enable/user-disable for example. Current >>situation puts all the authoritative information to summary which: >>a) Does not look nice in terminal >># ipa trustdomain-disable very.long.long.long.realm very.long.long.long.domain >>---------------------------------------------------------------------------------------------------------------------------- >>Domain very.long.long.long.domain of trust very.long.long.long.realm is not >>allowed to access IPA resources >>---------------------------------------------------------------------------------------------------------------------------- >>b) How am I supposed to parse an information about the result if all I get is a >>text in summary? Using standard errors and output values will allow easier >>consumption of the API later (like in Web UI). >> >>I am attaching a patch (0001) how to make it consistent with other >>enable/disable commands. Example: >> >># ipa trustdomain-disable realm domain >>ipa: ERROR: This entry is already disabled >> >># ipa trustdomain-enable realm domain >>----------------------------- >>Enabled trust domain "domain" >>----------------------------- >> >>3) Let's use standard primary key for the trustdomain object. This will let us >>overcome some hacks and also let us use handle_not_found method - patch >>attached (0002). >> >>0002 also changes some ValidationError errors to standard errors, just for >>being consistent with the rest of the API. >> >>Note that in order to make primary_key=True, I had to enhance trustdomain_del >>command to manage multiple domains. >> >> >>I think these API fixes are a must, it would be very hard to amend the API >>later. If these patches are squashed to your 0118, it would be ACK from me to >>the Python side. I will let C parts and a functional test to Sumit's mighty hands. >Thanks. I've merged these changes, along with a API.txt correction. In >my tests these worked fine. > >I'll resend 0118 shortly. New edition of 0118 attached. -- / Alexander Bokovoy -------------- next part -------------- >From 1e5d4090d53ce0e889f05359685efd8819771826 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 18 Sep 2013 17:04:19 +0200 Subject: [PATCH 2/8] trusts: support subdomains in a forest Add IPA CLI to manage trust domains. ipa trust-fetch-domains -- fetch list of subdomains from AD side and add new ones to IPA ipa trustdomain-find -- show all available domains ipa trustdomain-del -- remove domain from IPA view about ipa trustdomain-enable -- allow users from trusted domain to access resources in IPA ipa trustdomain-disable -- disable access to resources in IPA from trusted domain By default all discovered trust domains are allowed to access IPA resources IPA KDC needs also information for authentication paths to subdomains in case they are not hierarchical under AD forest trust root. This information is managed via capaths section in krb5.conf. SSSD should be able to generate it once ticket https://fedorahosted.org/sssd/ticket/2093 is resolved. part of https://fedorahosted.org/freeipa/ticket/3909 --- API.txt | 88 +++++++++++++ ipalib/plugins/trust.py | 329 ++++++++++++++++++++++++++++++++++++++++-------- ipaserver/dcerpc.py | 54 ++++++++ 3 files changed, 420 insertions(+), 51 deletions(-) diff --git a/API.txt b/API.txt index 761d1d1..40871f6 100644 --- a/API.txt +++ b/API.txt @@ -3423,6 +3423,17 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: Output('value', , None) +command: trust_fetch_domains +args: 1,4,4 +arg: Str('cn', attribute=True, cli_name='realm', multivalue=False, primary_key=True, query=True, required=True) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) command: trust_find args: 1,11,4 arg: Str('criteria?', noextrawhitespace=False) @@ -3497,6 +3508,83 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: Output('value', , None) +command: trustdomain_add +args: 2,9,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('cn', attribute=True, cli_name='domain', multivalue=False, primary_key=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('ipantflatname', attribute=True, cli_name='flat_name', multivalue=False, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, cli_name='sid', multivalue=False, required=False) +option: Str('ipanttrustpartner', attribute=True, cli_name='ipanttrustpartner', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', values=(u'ad',)) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trustdomain_del +args: 2,2,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('cn', attribute=True, cli_name='domain', multivalue=True, primary_key=True, query=True, required=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trustdomain_disable +args: 2,1,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('cn', attribute=True, cli_name='domain', multivalue=False, primary_key=True, query=True, required=True) +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trustdomain_enable +args: 2,1,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('cn', attribute=True, cli_name='domain', multivalue=False, primary_key=True, query=True, required=True) +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trustdomain_find +args: 2,10,4 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('criteria?', noextrawhitespace=False) +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn', attribute=True, autofill=False, cli_name='domain', multivalue=False, primary_key=True, query=True, required=False) +option: Str('ipantflatname', attribute=True, autofill=False, cli_name='flat_name', multivalue=False, query=True, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='sid', multivalue=False, query=True, required=False) +option: Str('ipanttrustpartner', attribute=True, autofill=False, cli_name='ipanttrustpartner', multivalue=False, query=True, required=False) +option: Flag('pkey_only?', autofill=True, default=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: trustdomain_mod +args: 2,11,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('cn', attribute=True, cli_name='domain', multivalue=False, primary_key=True, query=True, required=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('ipantflatname', attribute=True, autofill=False, cli_name='flat_name', multivalue=False, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='sid', multivalue=False, required=False) +option: Str('ipanttrustpartner', attribute=True, autofill=False, cli_name='ipanttrustpartner', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', values=(u'ad',)) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('value', , None) command: user_add args: 1,35,3 arg: Str('uid', attribute=True, cli_name='login', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 3d05029..82b2c96 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -181,6 +181,13 @@ def trust_status_string(level): string = _trust_status_dict.get(level, _trust_type_dict_unknown) return unicode(string) +def make_trust_dn(env, trust_type, dn): + assert isinstance(dn, DN) + if trust_type: + container_dn = DN(('cn', trust_type), env.container_trusts, env.basedn) + return DN(dn, container_dn) + return dn + class trust(LDAPObject): """ Trust object. @@ -195,7 +202,8 @@ class trust(LDAPObject): 'ipantauthtrustoutgoing', 'ipanttrustauthincoming', 'ipanttrustforesttrustinfo', 'ipanttrustposixoffset', 'ipantsupportedencryptiontypes' ] search_display_attributes = ['cn', 'ipantflatname', - 'ipanttrusteddomainsid', 'ipanttrusttype' ] + 'ipanttrusteddomainsid', 'ipanttrusttype', + 'ipantsidblacklistincoming', 'ipantsidblacklistoutgoing' ] label = _('Trusts') label_singular = _('Trust') @@ -241,12 +249,26 @@ class trust(LDAPObject): raise errors.ValidationError(name=attr, error=_("invalid SID: %(value)s") % dict(value=value)) -def make_trust_dn(env, trust_type, dn): - assert isinstance(dn, DN) - if trust_type in trust.trust_types: - container_dn = DN(('cn', trust_type), env.container_trusts, env.basedn) - return DN(dn[0], container_dn) - return dn + def get_dn(self, *keys, **kwargs): + sdn = map(lambda x: ('cn', x), keys) + sdn.reverse() + trust_type = kwargs.get('trust_type') + if trust_type is None: + ldap = self.backend + filter = ldap.make_filter({'objectclass': ['ipaNTTrustedDomain'], 'cn': [keys[-1]]}) + filter = ldap.combine_filters((filter, "ipaNTSIDBlacklistIncoming=*"), rules=ldap.MATCH_ALL) + try: + result = ldap.get_entries(DN(self.container_dn, self.env.basedn), + ldap.SCOPE_SUBTREE, filter, ['']) + except errors.NotFound: + trust_type = u'ad' + else: + if len(result) > 1: + raise errors.OnlyOneValueAllowed(attr='trust domain') + return result[0].dn + + dn=make_trust_dn(self.env, trust_type, DN(*sdn)) + return dn class trust_add(LDAPCreate): __doc__ = _(''' @@ -589,10 +611,13 @@ sides. def execute_ad(self, full_join, *keys, **options): # Join domain using full credentials and with random trustdom # secret (will be generated by the join method) - try: - api.Command['trust_show'](keys[-1]) + + # First see if the trust is already in place + # Force retrieval of the trust object by not passing trust_type + dn = self.obj.get_dn(keys[-1]) + if dn: summary = _('Re-established trust to domain "%(value)s"') - except errors.NotFound: + else: summary = self.msg_summary # 1. Full access to the remote domain. Use admin credentials and @@ -665,14 +690,6 @@ class trust_del(LDAPDelete): msg_summary = _('Deleted trust "%(value)s"') - def pre_callback(self, ldap, dn, *keys, **options): - assert isinstance(dn, DN) - try: - result = self.api.Command.trust_show(keys[-1]) - except errors.NotFound, e: - self.obj.handle_not_found(*keys) - return result['result']['dn'] - class trust_mod(LDAPUpdate): __doc__ = _(""" Modify a trust (for future use). @@ -686,16 +703,10 @@ class trust_mod(LDAPUpdate): def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): assert isinstance(dn, DN) - result = None - try: - result = self.api.Command.trust_show(keys[-1]) - except errors.NotFound, e: - self.obj.handle_not_found(*keys) self.obj.validate_sid_blacklists(entry_attrs) - # TODO: we found the trust object, now modify it - return result['result']['dn'] + return dn class trust_find(LDAPSearch): __doc__ = _('Search for trusts.') @@ -709,8 +720,10 @@ class trust_find(LDAPSearch): # Since all trusts types are stored within separate containers under 'cn=trusts', # search needs to be done on a sub-tree scope def pre_callback(self, ldap, filters, attrs_list, base_dn, scope, *args, **options): - assert isinstance(base_dn, DN) - return (filters, base_dn, ldap.SCOPE_SUBTREE) + # list only trust, not trust domains + trust_filter = '(ipaNTSIDBlacklistIncoming=*)' + filter = ldap.combine_filters((filters, trust_filter), rules=ldap.MATCH_ALL) + return (filter, base_dn, ldap.SCOPE_SUBTREE) def post_callback(self, ldap, entries, truncated, *args, **options): if options.get('pkey_only', False): @@ -731,30 +744,6 @@ class trust_show(LDAPRetrieve): has_output_params = LDAPRetrieve.has_output_params + trust_output_params +\ (Str('ipanttrusttype'), Str('ipanttrustdirection')) - def execute(self, *keys, **options): - error = None - result = None - for trust_type in trust.trust_types: - options['trust_show_type'] = trust_type - try: - result = super(trust_show, self).execute(*keys, **options) - except errors.NotFound, e: - result = None - error = e - if result: - break - if error or not result: - self.obj.handle_not_found(*keys) - - return result - - def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): - assert isinstance(dn, DN) - if 'trust_show_type' in options: - return make_trust_dn(self.env, options['trust_show_type'], dn) - - return dn - def post_callback(self, ldap, dn, entry_attrs, *keys, **options): # Translate ipanttrusttype to trusttype @@ -1091,3 +1080,241 @@ class sidgen_was_run(Command): return dict(result=True) api.register(sidgen_was_run) + +class trustdomain(LDAPObject): + """ + Object representing a domain of the AD trust. + """ + parent_object = 'trust' + trust_type_idx = {'2':u'ad'} + object_name = _('trust domain') + object_name_plural = _('trust domains') + object_class = ['ipaNTTrustedDomain'] + default_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', 'ipanttrustpartner'] + search_display_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', ] + + label = _('Trusted domains') + label_singular = _('Trusted domain') + + takes_params = ( + Str('cn', + label=_('Domain name'), + cli_name='domain', + primary_key=True + ), + Str('ipantflatname?', + cli_name='flat_name', + label=_('Domain NetBIOS name'), + ), + Str('ipanttrusteddomainsid?', + cli_name='sid', + label=_('Domain Security Identifier'), + ), + Str('ipanttrustpartner?', + label=_('Trusted domain partner'), + flags=['no_display', 'no_option'], + ), + ) + + # LDAPObject.get_dn() only passes all but last element of keys and no kwargs + # to the parent object's get_dn() no matter what you pass to it. Make own get_dn() + # as we really need all elements to construct proper dn. + def get_dn(self, *keys, **kwargs): + sdn = map(lambda x: ('cn', x), keys) + sdn.reverse() + trust_type = kwargs.get('trust_type') + if not trust_type: + trust_type=u'ad' + + dn=make_trust_dn(self.env, trust_type, DN(*sdn)) + return dn +api.register(trustdomain) + +class trustdomain_find(LDAPSearch): + __doc__ = _('Search domains of the trust') + + def pre_callback(self, ldap, filters, attrs_list, base_dn, scope, *args, **options): + return (filters, base_dn, ldap.SCOPE_SUBTREE) +api.register(trustdomain_find) + +class trustdomain_mod(LDAPUpdate): + __doc__ = _('Modify trustdomain of the trust') + + NO_CLI = True + takes_options = LDAPUpdate.takes_options + (_trust_type_option,) +api.register(trustdomain_mod) + +class trustdomain_add(LDAPCreate): + __doc__ = _('Allow access from the trusted domain') + NO_CLI = True + + takes_options = LDAPCreate.takes_options + (_trust_type_option,) + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + if 'ipanttrustpartner' in options: + entry_attrs['ipanttrustpartner'] = [options['ipanttrustpartner']] + return dn +api.register(trustdomain_add) + +class trustdomain_del(LDAPDelete): + __doc__ = _('Remove infromation about the domain associated with the trust.') + + msg_summary = _('Removed information about the trusted domain "%(value)s"') + + def execute(self, *keys, **options): + # Note that pre-/post- callback handling for LDAPDelete is causing pre_callback + # to always receive empty keys. We need to catch the case when root domain is being deleted + + for domain in keys[1]: + if keys[0].lower() == domain: + raise errors.ValidationError(name='domain', + error=_("cannot delete root domain of the trust, use trust-del to delete the trust itself")) + try: + res = api.Command.trustdomain_enable(keys[0], domain) + except errors.AlreadyActive: + pass + result = super(trustdomain_del, self).execute(*keys, **options) + result['value'] = u','.join(keys[1]) + return result + + +api.register(trustdomain_del) + + +def fetch_domains_from_trust(self, trustinstance, trust_entry): + trust_name = trust_entry['cn'][0] + domains = ipaserver.dcerpc.fetch_domains(self.api, trustinstance.local_flatname, trust_name) + result = [] + if not domains: + return None + + for dom in domains: + dom['trust_type'] = u'ad' + try: + name = dom['cn'] + del dom['cn'] + if 'all' in options: + dom['all'] = options['all'] + if 'raw' in options: + dom['raw'] = options['raw'] + res = self.api.Command.trustdomain_add(trust_name, name, **dom) + result.append(res['result']) + except errors.DuplicateEntry: + # Ignore updating duplicate entries + pass + return result + +class trust_fetch_domains(LDAPRetrieve): + __doc__ = _('Refresh list of the domains associated with the trust') + + has_output = output.standard_list_of_entries + + def execute(self, *keys, **options): + if not _bindings_installed: + raise errors.NotFound( + name=_('AD Trust setup'), + reason=_( + 'Cannot perform join operation without Samba 4 support ' + 'installed. Make sure you have installed server-trust-ad ' + 'sub-package of IPA' + ) + ) + trust = self.api.Command.trust_show(keys[0], raw=True)['result'] + + trustinstance = ipaserver.dcerpc.TrustDomainJoins(self.api) + if not trustinstance.configured: + raise errors.NotFound( + name=_('AD Trust setup'), + reason=_( + 'Cannot perform join operation without own domain ' + 'configured. Make sure you have run ipa-adtrust-install ' + 'on the IPA server first' + ) + ) + domains = fetch_domains_from_trust(self, trustinstance, trust) + result = dict() + + if len(domains) > 0: + result['summary'] = unicode(_('List of trust domains successfully refreshed')) + else: + result['summary'] = unicode(_('No new trust domains were found')) + + result['result'] = domains + result['count'] = len(domains) + result['truncated'] = False + return result + +api.register(trust_fetch_domains) + +class trustdomain_enable(LDAPQuery): + __doc__ = _('Allow use of IPA resources by the domain of the trust') + + has_output = output.standard_value + msg_summary = _('Enabled trust domain "%(value)s"') + + def execute(self, *keys, **options): + ldap = self.api.Backend.ldap2 + + if keys[0].lower() == keys[1].lower(): + raise errors.ValidationError(name='domain', + error=_("Root domain of the trust is always enabled for the existing trust")) + try: + trust_dn = self.obj.get_dn(keys[0], trust_type=u'ad') + trust_entry = ldap.get_entry(trust_dn) + except errors.NotFound: + raise self.api.Object[self.obj.parent_object].handle_not_found(keys[0]) + + dn = self.obj.get_dn(keys[0], keys[1], trust_type=u'ad') + try: + entry = ldap.get_entry(dn) + sid = entry['ipanttrusteddomainsid'][0] + if sid in trust_entry['ipantsidblacklistincoming']: + trust_entry['ipantsidblacklistincoming'].remove(sid) + ldap.update_entry(trust_entry) + else: + raise errors.AlreadyActive() + except errors.NotFound: + self.obj.handle_not_found(*keys) + + return dict( + result=True, + value=keys[1], + ) + +api.register(trustdomain_enable) + +class trustdomain_disable(LDAPQuery): + __doc__ = _('Disable use of IPA resources by the domain of the trust') + + has_output = output.standard_value + msg_summary = _('Disabled trust domain "%(value)s"') + + def execute(self, *keys, **options): + ldap = self.api.Backend.ldap2 + + if keys[0].lower() == keys[1].lower(): + raise errors.ValidationError(name='domain', + error=_("cannot disable root domain of the trust, use trust-del to delete the trust itself")) + try: + trust_dn = self.obj.get_dn(keys[0], trust_type=u'ad') + trust_entry = ldap.get_entry(trust_dn) + except errors.NotFound: + self.api.Object[self.obj.parent_object].handle_not_found(keys[0]) + + dn = self.obj.get_dn(keys[0], keys[1], trust_type=u'ad') + try: + entry = ldap.get_entry(dn) + sid = entry['ipanttrusteddomainsid'][0] + if not (sid in trust_entry['ipantsidblacklistincoming']): + trust_entry['ipantsidblacklistincoming'].append(sid) + ldap.update_entry(trust_entry) + else: + raise errors.AlreadyInactive() + except errors.NotFound: + self.obj.handle_not_found(*keys) + + return dict( + result=True, + value=keys[1], + ) + +api.register(trustdomain_disable) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index cc9e7be..1c4f4a6 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -1002,6 +1002,60 @@ class TrustDomainInstance(object): return True return False +def fetch_domains(api, mydomain, trustdomain): + trust_flags = dict( + NETR_TRUST_FLAG_IN_FOREST = 0x00000001, + NETR_TRUST_FLAG_OUTBOUND = 0x00000002, + NETR_TRUST_FLAG_TREEROOT = 0x00000004, + NETR_TRUST_FLAG_PRIMARY = 0x00000008, + NETR_TRUST_FLAG_NATIVE = 0x00000010, + NETR_TRUST_FLAG_INBOUND = 0x00000020, + NETR_TRUST_FLAG_MIT_KRB5 = 0x00000080, + NETR_TRUST_FLAG_AES = 0x00000100) + + trust_attributes = dict( + NETR_TRUST_ATTRIBUTE_NON_TRANSITIVE = 0x00000001, + NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x00000002, + NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x00000004, + NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x00000008, + NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x00000010, + NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x00000020, + NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x00000040) + + domval = DomainValidator(api) + (ccache_name, principal) = domval.kinit_as_http(trustdomain) + if ccache_name: + with installutils.private_ccache(path=ccache_name): + td = TrustDomainInstance('') + td.parm.set('workgroup', mydomain) + td.creds = credentials.Credentials() + td.creds.set_kerberos_state(credentials.MUST_USE_KERBEROS) + td.creds.guess(td.parm) + netrc = net.Net(creds=td.creds, lp=td.parm) + try: + result = netrc.finddc(domain=trustdomain, flags=nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_DS) + except RuntimeError, e: + raise assess_dcerpc_exception(message=str(e)) + if not result: + return None + td.retrieve(unicode(result.pdc_dns_name)) + + netr_pipe = netlogon.netlogon(td.binding, td.parm, td.creds) + domains = netr_pipe.netr_DsrEnumerateDomainTrusts(td.binding, 1) + + result = [] + for t in domains.array: + if ((t.trust_attributes & trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and + (t.trust_flags & trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): + res = dict() + res['cn'] = unicode(t.dns_name) + res['ipantflatname'] = unicode(t.netbios_name) + res['ipanttrusteddomainsid'] = unicode(t.sid) + res['ipanttrustpartner'] = res['cn'] + result.append(res) + return result + + class TrustDomainJoins(object): def __init__(self, api): self.api = api -- 1.8.3.1 From mkosek at redhat.com Fri Oct 4 06:55:55 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Oct 2013 08:55:55 +0200 Subject: [Freeipa-devel] [PATCHES] 0278-0279 Make it possible to run integration tests without Paramiko In-Reply-To: <524DA02A.1090108@redhat.com> References: <523980B5.8030300@redhat.com> <524DA02A.1090108@redhat.com> Message-ID: <524E667B.2040205@redhat.com> On 10/03/2013 06:49 PM, Petr Vobornik wrote: > On 09/18/2013 12:30 PM, Petr Viktorin wrote: >> Hello, >> These patches take the SSH2 bits out of the integration tests' Host >> class into a Transport class, and add a new Transport that uses >> /usr/bin/ssh to talk with remote hosts. >> The Host class is broken up to help adding AD trust tests (see Tom??'s >> patches 100-106, the WinHost addition can be simplified now; in the >> future adding e.g. a telnet transport should be easier). >> >> The spec file is not changed, I believe Paramiko is a better default for >> Fedora. >> The OpenSSH transport can be selected by setting >> IPA_TEST_SSH_TRANSPORT=openssh. >> >> https://fedorahosted.org/freeipa/ticket/3890 >> >> > > ACK This was pushed to master, ipa-3-3 by Petr Viktorin. Martin From pspacek at redhat.com Fri Oct 4 06:57:50 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 04 Oct 2013 08:57:50 +0200 Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> Message-ID: <524E66EE.1000905@redhat.com> On 3.10.2013 23:43, Nathaniel McCallum wrote: > Patch attached. I'm curious - what is the purpose of this patch? To prevent 1 second timeouts and re-transmits when OTP is in place? What is the expected performance impact? Could it be configured for OTP separately - somehow? (I guess that it is not possible now ...) -- Petr^2 Spacek From abokovoy at redhat.com Fri Oct 4 07:40:30 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 4 Oct 2013 10:40:30 +0300 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <20131004055945.GY4216@redhat.com> References: <20130928200134.GF4216@redhat.com> <52495AEB.7000204@redhat.com> <20130930123143.GJ4216@redhat.com> <20131001151509.GP4216@redhat.com> <524C8299.9040801@redhat.com> <20131002210453.GF10000@localhost.localdomain> <20131003131052.GV4216@redhat.com> <524D9588.9050006@redhat.com> <20131004054000.GW4216@redhat.com> <20131004055945.GY4216@redhat.com> Message-ID: <20131004074030.GZ4216@redhat.com> On Fri, 04 Oct 2013, Alexander Bokovoy wrote: > On Fri, 04 Oct 2013, Alexander Bokovoy wrote: >> On Thu, 03 Oct 2013, Martin Kosek wrote: >>> On 10/03/2013 03:10 PM, Alexander Bokovoy wrote: >>>> On Wed, 02 Oct 2013, Sumit Bose wrote: >>>>>> Please note that I did not test with more than 1 subdomain, since I >>>>>> do not have more ADs available. >>>>>> >>>>> >>>>> I have done some testing as well and the patches are working as expected >>>>> except the trustdomain-disable issue Tomas mentioned. But I think it >>>>> would be sufficient to add a comment to the release notes and fix this >>>>> with the next release to not delay this release anymore. >>>>> >>>>> The patches are also working for trusts which were added with older >>>>> releases. So ACK from my side for the functional part. >>>> New patchset is attached. I've fixed all outstanding issues and >>>> implemented proper SID filtering for subdomains. In addition, I've >>>> added MS-PAC cache eviction when we change blacklists from IPA side >>>> and forced removal of the domain from SID blacklist if the domain is >>>> being removed by trustdomain-del. >>>> >>> >>> 1) Minor issue in 0118: >>> >>> + if keys[0].lower() == keys[1].lower(): >>> + raise errors.ValidationError(name='trustdomain_enable', >>> + error=_("Root domain of the trust is always enabled for the >>> existing trust")) >>> >>> The error message looks weird (double trustdomain_enable) >>> >>> # ipa trustdomain-enable realm domain >>> ipa: ERROR: invalid 'trustdomain_enable': Root domain of the trust is always >>> enabled for the existing trust >>> >>> I would rather do something like >>> >>> + raise errors.ValidationError(name='domain', >>> >>> >>> 2) trustconfig-enable and trustconfig-disable should use standard output like >>> other enable/disable methods. See user-enable/user-disable for example. Current >>> situation puts all the authoritative information to summary which: >>> a) Does not look nice in terminal >>> # ipa trustdomain-disable very.long.long.long.realm very.long.long.long.domain >>> ---------------------------------------------------------------------------------------------------------------------------- >>> Domain very.long.long.long.domain of trust very.long.long.long.realm is not >>> allowed to access IPA resources >>> ---------------------------------------------------------------------------------------------------------------------------- >>> b) How am I supposed to parse an information about the result if all I get is a >>> text in summary? Using standard errors and output values will allow easier >>> consumption of the API later (like in Web UI). >>> >>> I am attaching a patch (0001) how to make it consistent with other >>> enable/disable commands. Example: >>> >>> # ipa trustdomain-disable realm domain >>> ipa: ERROR: This entry is already disabled >>> >>> # ipa trustdomain-enable realm domain >>> ----------------------------- >>> Enabled trust domain "domain" >>> ----------------------------- >>> >>> 3) Let's use standard primary key for the trustdomain object. This will let us >>> overcome some hacks and also let us use handle_not_found method - patch >>> attached (0002). >>> >>> 0002 also changes some ValidationError errors to standard errors, just for >>> being consistent with the rest of the API. >>> >>> Note that in order to make primary_key=True, I had to enhance trustdomain_del >>> command to manage multiple domains. >>> >>> >>> I think these API fixes are a must, it would be very hard to amend the API >>> later. If these patches are squashed to your 0118, it would be ACK from me to >>> the Python side. I will let C parts and a functional test to Sumit's mighty hands. >> Thanks. I've merged these changes, along with a API.txt correction. In >> my tests these worked fine. >> >> I'll resend 0118 shortly. > New edition of 0118 attached. ... and updated 0124 to match the 0118. -- / Alexander Bokovoy -------------- next part -------------- >From 34dc771417b247de180fe490da9fe9cb09644fee Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 3 Oct 2013 12:30:44 +0200 Subject: [PATCH 8/8] ipa-kdb: Handle parent-child relationship for subdomains When MS-PAC information is re-initialized, record also parent-child relationship between trust root level domain and its subdomains. Use parent incoming SID black list to check if child domain is not allowed to access IPA realm. We also should really use 'cn' of the entry as domain name. ipaNTTrustPartner has different meaning on wire, it is an index pointing to the parent domain of the domain and will be 0 for top level domains or disjoint subdomains of the trust. Finally, trustdomain-enable and trustdomain-disable commands should force MS-PAC cache re-initalization in case of black list change. Trigger that by asking for cross-realm TGT for HTTP service. --- daemons/ipa-kdb/ipa_kdb_mspac.c | 109 ++++++++++++++++++++++++++++++++++++---- ipalib/plugins/trust.py | 6 +++ 2 files changed, 105 insertions(+), 10 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index e20de36..ff67391 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -37,6 +37,8 @@ struct ipadb_adtrusts { int len_sid_blacklist_incoming; struct dom_sid *sid_blacklist_outgoing; int len_sid_blacklist_outgoing; + struct ipadb_adtrusts *parent; + char *parent_name; }; struct ipadb_mspac { @@ -1359,6 +1361,18 @@ static krb5_error_code filter_logon_info(krb5_context context, return EINVAL; } + /* Check if this domain has been filtered out by the trust itself*/ + if (domain->parent != NULL) { + for(k = 0; k < domain->parent->len_sid_blacklist_incoming; k++) { + result = dom_sid_check(info->info->info3.base.domain_sid, + &domain->parent->sid_blacklist_incoming[k], true); + if (result) { + filter_logon_info_log_message(info->info->info3.base.domain_sid); + return EINVAL; + } + } + } + /* According to MS-KILE 25.0, info->info->info3.sids may be non zero, so check * should include different possibilities into account * */ @@ -2121,6 +2135,8 @@ void ipadb_mspac_struct_free(struct ipadb_mspac **mspac) free((*mspac)->trusts[i].domain_sid); free((*mspac)->trusts[i].sid_blacklist_incoming); free((*mspac)->trusts[i].sid_blacklist_outgoing); + free((*mspac)->trusts[i].parent_name); + (*mspac)->trusts[i].parent = NULL; } free((*mspac)->trusts); } @@ -2209,18 +2225,42 @@ done: return ret; } +static void ipadb_free_sid_blacklists(char ***sid_blacklist_incoming, char ***sid_blacklist_outgoing) +{ + int i; + + if (sid_blacklist_incoming && *sid_blacklist_incoming) { + for (i = 0; *sid_blacklist_incoming && (*sid_blacklist_incoming)[i]; i++) { + free((*sid_blacklist_incoming)[i]); + } + free(*sid_blacklist_incoming); + *sid_blacklist_incoming = NULL; + } + + if (sid_blacklist_outgoing && *sid_blacklist_outgoing) { + for (i = 0; *sid_blacklist_outgoing && (*sid_blacklist_outgoing)[i]; i++) { + free((*sid_blacklist_outgoing)[i]); + } + free(*sid_blacklist_outgoing); + *sid_blacklist_outgoing = NULL; + } +} + krb5_error_code ipadb_mspac_get_trusted_domains(struct ipadb_context *ipactx) { struct ipadb_adtrusts *t; LDAP *lc = ipactx->lcontext; - char *attrs[] = { "ipaNTTrustPartner", "ipaNTFlatName", + char *attrs[] = { "cn", "ipaNTTrustPartner", "ipaNTFlatName", "ipaNTTrustedDomainSID", "ipaNTSIDBlacklistIncoming", "ipaNTSIDBlacklistOutgoing", NULL }; char *filter = "(objectclass=ipaNTTrustedDomain)"; krb5_error_code kerr; LDAPMessage *res = NULL; LDAPMessage *le; + LDAPRDN rdn; char *base = NULL; + char *dnstr = NULL; + char *dnl = NULL; char **sid_blacklist_incoming = NULL; char **sid_blacklist_outgoing = NULL; int ret, n, i; @@ -2243,6 +2283,13 @@ krb5_error_code ipadb_mspac_get_trusted_domains(struct ipadb_context *ipactx) } for (le = ldap_first_entry(lc, res); le; le = ldap_next_entry(lc, le)) { + dnstr = ldap_get_dn(lc, le); + + if (dnstr == NULL) { + ret = ENOMEM; + goto done; + } + n = ipactx->mspac->num_trusts; ipactx->mspac->num_trusts++; t = realloc(ipactx->mspac->trusts, @@ -2253,7 +2300,9 @@ krb5_error_code ipadb_mspac_get_trusted_domains(struct ipadb_context *ipactx) } ipactx->mspac->trusts = t; - ret = ipadb_ldap_attr_to_str(lc, le, "ipaNTTrustPartner", + memset(&t[n], 0, sizeof(t[n])); + + ret = ipadb_ldap_attr_to_str(lc, le, "cn", &t[n].domain_name); if (ret) { ret = EINVAL; @@ -2287,6 +2336,7 @@ krb5_error_code ipadb_mspac_get_trusted_domains(struct ipadb_context *ipactx) if (ret == ENOENT) { /* This attribute is optional */ ret = 0; + sid_blacklist_incoming = NULL; } else { ret = EINVAL; goto done; @@ -2300,6 +2350,7 @@ krb5_error_code ipadb_mspac_get_trusted_domains(struct ipadb_context *ipactx) if (ret == ENOENT) { /* This attribute is optional */ ret = 0; + sid_blacklist_outgoing = NULL; } else { ret = EINVAL; goto done; @@ -2312,6 +2363,49 @@ krb5_error_code ipadb_mspac_get_trusted_domains(struct ipadb_context *ipactx) if (ret) { goto done; } + ipadb_free_sid_blacklists(&sid_blacklist_incoming, + &sid_blacklist_outgoing); + + /* Parse first two RDNs of the entry to find its parent */ + dnl = strcasestr(dnstr, base); + if (dnl == NULL) { + goto done; + } + + /* Note that after ldap_str2rdn() call dnl will point to end of one RDN + * which would be '\0' for trust root domain and ',' for subdomain */ + dnl--; dnl[0] = '\0'; + ret = ldap_str2rdn(dnstr, &rdn, &dnl, LDAP_DN_FORMAT_LDAPV3); + if (ret) { + goto done; + } + + ldap_rdnfree(rdn); + + if (dnl[0] != '\0') { + dnl++; + ret = ldap_str2rdn(dnl, &rdn, &dnl, LDAP_DN_FORMAT_LDAPV3); + if (ret) { + goto done; + } + t[n].parent_name = strndup(rdn[0]->la_value.bv_val, rdn[0]->la_value.bv_len); + ldap_rdnfree(rdn); + } + + free(dnstr); + dnstr = NULL; + } + + /* Traverse through all trusts and resolve parents */ + t = ipactx->mspac->trusts; + for (i = 0; i < ipactx->mspac->num_trusts; i++) { + if (t[i].parent_name != NULL) { + for (n = 0; n < ipactx->mspac->num_trusts; n++) { + if (strcasecmp(t[i].parent_name, t[n].domain_name) == 0) { + t[i].parent = &t[n]; + } + } + } } ret = 0; @@ -2320,15 +2414,10 @@ done: if (ret != 0) { krb5_klog_syslog(LOG_ERR, "Failed to read list of trusted domains"); } + free(dnstr); free(base); - for (i = 0; sid_blacklist_incoming && sid_blacklist_incoming[i]; i++) { - free(sid_blacklist_incoming[i]); - } - free(sid_blacklist_incoming); - for (i = 0; sid_blacklist_outgoing && sid_blacklist_outgoing[i]; i++) { - free(sid_blacklist_outgoing[i]); - } - free(sid_blacklist_outgoing); + ipadb_free_sid_blacklists(&sid_blacklist_incoming, + &sid_blacklist_outgoing); ldap_msgfree(res); return ret; } diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 5a1ec17..8aa6ed5 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -1286,6 +1286,9 @@ class trustdomain_enable(LDAPQuery): if sid in trust_entry['ipantsidblacklistincoming']: trust_entry['ipantsidblacklistincoming'].remove(sid) ldap.update_entry(trust_entry) + # Force MS-PAC cache re-initialization on KDC side + domval = ipaserver.dcerpc.DomainValidator(api) + (ccache_name, principal) = domval.kinit_as_http(keys[0]) else: raise errors.AlreadyActive() except errors.NotFound: @@ -1323,6 +1326,9 @@ class trustdomain_disable(LDAPQuery): if not (sid in trust_entry['ipantsidblacklistincoming']): trust_entry['ipantsidblacklistincoming'].append(sid) ldap.update_entry(trust_entry) + # Force MS-PAC cache re-initialization on KDC side + domval = ipaserver.dcerpc.DomainValidator(api) + (ccache_name, principal) = domval.kinit_as_http(keys[0]) else: raise errors.AlreadyInactive() except errors.NotFound: -- 1.8.3.1 From jcholast at redhat.com Fri Oct 4 07:55:28 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 04 Oct 2013 09:55:28 +0200 Subject: [Freeipa-devel] [PATCHES] 170-171 Allow PKCS#12 files with empty password in install tools In-Reply-To: <524D90D0.1060309@redhat.com> References: <5242A2D9.10304@redhat.com> <524D51C2.6090006@redhat.com> <524D90D0.1060309@redhat.com> Message-ID: <524E7470.6060108@redhat.com> On 3.10.2013 17:44, Petr Viktorin wrote: > On 10/03/2013 01:15 PM, Petr Viktorin wrote: >> On 09/25/2013 10:46 AM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patches fix . >>> >>> Honza >>> >> >> I'm still testing; it looks good except for unattended installs. With >> the attached fixup squashed in it works so far. > > Another problem is that the change pkcs12_info (password instead of > filename) was not done in ipa-replica-install. Here is another fixup to > correct this. > > Also, I'm attaching tests I used for this. > > If these changes look OK to you, then it's an ACK. > Thanks! ACK to your changes (I don't know how I missed all of this, shame on me!) Honza -- Jan Cholasta From mkosek at redhat.com Fri Oct 4 08:32:55 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Oct 2013 10:32:55 +0200 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <20131004074030.GZ4216@redhat.com> References: <20130928200134.GF4216@redhat.com> <52495AEB.7000204@redhat.com> <20130930123143.GJ4216@redhat.com> <20131001151509.GP4216@redhat.com> <524C8299.9040801@redhat.com> <20131002210453.GF10000@localhost.localdomain> <20131003131052.GV4216@redhat.com> <524D9588.9050006@redhat.com> <20131004054000.GW4216@redhat.com> <20131004055945.GY4216@redhat.com> <20131004074030.GZ4216@redhat.com> Message-ID: <524E7D37.20206@redhat.com> On 10/04/2013 09:40 AM, Alexander Bokovoy wrote: > On Fri, 04 Oct 2013, Alexander Bokovoy wrote: >> On Fri, 04 Oct 2013, Alexander Bokovoy wrote: >>> On Thu, 03 Oct 2013, Martin Kosek wrote: >>>> On 10/03/2013 03:10 PM, Alexander Bokovoy wrote: >>>>> On Wed, 02 Oct 2013, Sumit Bose wrote: >>>>>>> Please note that I did not test with more than 1 subdomain, since I >>>>>>> do not have more ADs available. >>>>>>> >>>>>> >>>>>> I have done some testing as well and the patches are working as expected >>>>>> except the trustdomain-disable issue Tomas mentioned. But I think it >>>>>> would be sufficient to add a comment to the release notes and fix this >>>>>> with the next release to not delay this release anymore. >>>>>> >>>>>> The patches are also working for trusts which were added with older >>>>>> releases. So ACK from my side for the functional part. >>>>> New patchset is attached. I've fixed all outstanding issues and >>>>> implemented proper SID filtering for subdomains. In addition, I've >>>>> added MS-PAC cache eviction when we change blacklists from IPA side >>>>> and forced removal of the domain from SID blacklist if the domain is >>>>> being removed by trustdomain-del. >>>>> >>>> >>>> 1) Minor issue in 0118: >>>> >>>> + if keys[0].lower() == keys[1].lower(): >>>> + raise errors.ValidationError(name='trustdomain_enable', >>>> + error=_("Root domain of the trust is always enabled for the >>>> existing trust")) >>>> >>>> The error message looks weird (double trustdomain_enable) >>>> >>>> # ipa trustdomain-enable realm domain >>>> ipa: ERROR: invalid 'trustdomain_enable': Root domain of the trust is always >>>> enabled for the existing trust >>>> >>>> I would rather do something like >>>> >>>> + raise errors.ValidationError(name='domain', >>>> >>>> >>>> 2) trustconfig-enable and trustconfig-disable should use standard output like >>>> other enable/disable methods. See user-enable/user-disable for example. >>>> Current >>>> situation puts all the authoritative information to summary which: >>>> a) Does not look nice in terminal >>>> # ipa trustdomain-disable very.long.long.long.realm very.long.long.long.domain >>>> ---------------------------------------------------------------------------------------------------------------------------- >>>> >>>> Domain very.long.long.long.domain of trust very.long.long.long.realm is not >>>> allowed to access IPA resources >>>> ---------------------------------------------------------------------------------------------------------------------------- >>>> >>>> b) How am I supposed to parse an information about the result if all I get >>>> is a >>>> text in summary? Using standard errors and output values will allow easier >>>> consumption of the API later (like in Web UI). >>>> >>>> I am attaching a patch (0001) how to make it consistent with other >>>> enable/disable commands. Example: >>>> >>>> # ipa trustdomain-disable realm domain >>>> ipa: ERROR: This entry is already disabled >>>> >>>> # ipa trustdomain-enable realm domain >>>> ----------------------------- >>>> Enabled trust domain "domain" >>>> ----------------------------- >>>> >>>> 3) Let's use standard primary key for the trustdomain object. This will let us >>>> overcome some hacks and also let us use handle_not_found method - patch >>>> attached (0002). >>>> >>>> 0002 also changes some ValidationError errors to standard errors, just for >>>> being consistent with the rest of the API. >>>> >>>> Note that in order to make primary_key=True, I had to enhance trustdomain_del >>>> command to manage multiple domains. >>>> >>>> >>>> I think these API fixes are a must, it would be very hard to amend the API >>>> later. If these patches are squashed to your 0118, it would be ACK from me to >>>> the Python side. I will let C parts and a functional test to Sumit's mighty >>>> hands. >>> Thanks. I've merged these changes, along with a API.txt correction. In >>> my tests these worked fine. >>> >>> I'll resend 0118 shortly. >> New edition of 0118 attached. > ... and updated 0124 to match the 0118. > Thanks Alexander and Sumit! The patches seem to work now - ACK. Pushed all to master, ipa-3-3. I just also updated our spec to require new SSSD. Martin From pviktori at redhat.com Fri Oct 4 08:34:09 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Oct 2013 10:34:09 +0200 Subject: [Freeipa-devel] [PATCHES] 170-171 Allow PKCS#12 files with empty password in install tools In-Reply-To: <524E7470.6060108@redhat.com> References: <5242A2D9.10304@redhat.com> <524D51C2.6090006@redhat.com> <524D90D0.1060309@redhat.com> <524E7470.6060108@redhat.com> Message-ID: <524E7D81.4090307@redhat.com> On 10/04/2013 09:55 AM, Jan Cholasta wrote: > On 3.10.2013 17:44, Petr Viktorin wrote: >> On 10/03/2013 01:15 PM, Petr Viktorin wrote: >>> On 09/25/2013 10:46 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patches fix >>>> . >>>> >>>> Honza >>>> >>> >>> I'm still testing; it looks good except for unattended installs. With >>> the attached fixup squashed in it works so far. >> >> Another problem is that the change pkcs12_info (password instead of >> filename) was not done in ipa-replica-install. Here is another fixup to >> correct this. >> >> Also, I'm attaching tests I used for this. >> >> If these changes look OK to you, then it's an ACK. >> > > Thanks! > > ACK to your changes (I don't know how I missed all of this, shame on me!) > > Honza > Pushed to master: 3a4a7458c72bb70673520a546ba463ec7fc94bcf ipa-3-3: c6113ab89b010bd60eff4084b8d244dde2563dcf -- Petr? From jcholast at redhat.com Fri Oct 4 10:01:04 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 04 Oct 2013 12:01:04 +0200 Subject: [Freeipa-devel] [RFE] CA certificate renewal Message-ID: <524E91E0.1020603@redhat.com> Hi, you can find a draft of the design document for this feature at . Comments are welcome. Honza -- Jan Cholasta From ssorce at redhat.com Fri Oct 4 10:12:04 2013 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 4 Oct 2013 06:12:04 -0400 (EDT) Subject: [Freeipa-devel] [PATCH 0019] Prefer TCP connections to UDP in krb5 clients In-Reply-To: <524E66EE.1000905@redhat.com> References: <582599009.1129536.1380836600087.JavaMail.root@redhat.com> <524E66EE.1000905@redhat.com> Message-ID: <1126554510.1522210.1380881524784.JavaMail.root@redhat.com> ----- Original Message ----- > On 3.10.2013 23:43, Nathaniel McCallum wrote: > > Patch attached. > > I'm curious - what is the purpose of this patch? To prevent 1 second timeouts > and re-transmits when OTP is in place? > > What is the expected performance impact? Could it be configured for OTP > separately - somehow? (I guess that it is not possible now ...) It benefits also communication of large packets (when large MS-PAC or CAMMAC AD Data are attached), so it is a better choice for IPA in general. Especially given we have multiple KDC processes configured we do not want clients wasting KDC resources by making multiple processes do the same operation. Simo. -- Simo Sorce * Red Hat, Inc. * New York From mbasti at redhat.com Fri Oct 4 10:52:52 2013 From: mbasti at redhat.com (Martin Basti) Date: Fri, 04 Oct 2013 12:52:52 +0200 Subject: [Freeipa-devel] [DOC] Chapter 2 Installation In-Reply-To: <52499D31.3050908@redhat.com> References: <1377530209.2139.6.camel@unused-4-145.brq.redhat.com> <1380271858.2116.7.camel@unused-4-145.brq.redhat.com> <1380274641.2116.9.camel@unused-4-145.brq.redhat.com> <52499D31.3050908@redhat.com> Message-ID: <1380883972.2378.2.camel@unused-4-145.brq.redhat.com> On Mon, 2013-09-30 at 17:48 +0200, Petr Vobornik wrote: > On 09/27/2013 11:37 AM, Martin Basti wrote: > > On Fri, 2013-09-27 at 10:50 +0200, Martin Basti wrote: > >> On Mon, 2013-08-26 at 17:16 +0200, Martin Basti wrote: > >>> Hello, > >>> > >>> this patch fix some setup outputs and remove outdated section about > >>> updating freeIPA version 2 > >>> > >>> -- > >>> Martin Basti > >> > >> Updated patch is attached > > 1. The new paragraph about different replica version does not sound good. > > Instead of: > There is exception for using older version of replica by upgrading > process, but there should not be long-running &IPA; servers with > different versions. > > Use: > There is an exception to the rule ? newer version of replica can > be installed as a part of upgrade process. All other replicas have > to be upgraded to the same version in a matter of days or weeks. > There should not be long-running &IPA; servers with different > versions. Reworded, I hope, it sounds better now. Updated patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0001-4-Chapter-2-Installing.patch Type: text/x-patch Size: 22035 bytes Desc: not available URL: From pviktori at redhat.com Fri Oct 4 11:26:21 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Oct 2013 13:26:21 +0200 Subject: [Freeipa-devel] [PATCHES] 0307-0308 Use direct RPC with specified version in client-install Message-ID: <524EA5DD.9050805@redhat.com> These patches allow a client to enroll with old servers. The bug was reported in uploading SSH keys: https://fedorahosted.org/freeipa/ticket/3931 but while testing against v2.1 I found and fixed another bug that prevented the install. See the commit messages. With these patches I've successfully enrolled on: - Fedora 19, master - Fedora 19, 3.3.1-1 - Fedora 19, 3.3.1-1, CA-less - RHEL 6.2, 2.1.3-9 (SSH keys not supported, --force for cert over HTTP) -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0307-ipa-client-install-Use-direct-RPC-instead-of-api.Com.patch Type: text/x-patch Size: 2140 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0308-ipa-client-install-Verify-RPC-connection-with-a-ping.patch Type: text/x-patch Size: 1785 bytes Desc: not available URL: From pvoborni at redhat.com Fri Oct 4 11:41:02 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 04 Oct 2013 13:41:02 +0200 Subject: [Freeipa-devel] [DOC] Chapter 4 screenshots In-Reply-To: <5242C7E6.1060907@redhat.com> References: <1379516848.9269.3.camel@unused-4-145.brq.redhat.com> <5242C7E6.1060907@redhat.com> Message-ID: <524EA94E.7090405@redhat.com> On 09/25/2013 01:24 PM, Petr Vobornik wrote: > On 09/18/2013 05:07 PM, Martin Basti wrote: >> Patch adds new screen-shots for chapter 4 Basic Usage >> >> NOTE: Patch doesn't cover part 4.3 Logging with web UI >> > > ACK, but I would wait for mbasti 0004 and 0005. Pushed to master -- Petr Vobornik From pvoborni at redhat.com Fri Oct 4 11:41:39 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 04 Oct 2013 13:41:39 +0200 Subject: [Freeipa-devel] [DOC] Chapter 2 Installation In-Reply-To: <1380883972.2378.2.camel@unused-4-145.brq.redhat.com> References: <1377530209.2139.6.camel@unused-4-145.brq.redhat.com> <1380271858.2116.7.camel@unused-4-145.brq.redhat.com> <1380274641.2116.9.camel@unused-4-145.brq.redhat.com> <52499D31.3050908@redhat.com> <1380883972.2378.2.camel@unused-4-145.brq.redhat.com> Message-ID: <524EA973.9070401@redhat.com> On 10/04/2013 12:52 PM, Martin Basti wrote: > On Mon, 2013-09-30 at 17:48 +0200, Petr Vobornik wrote: >> On 09/27/2013 11:37 AM, Martin Basti wrote: >>> On Fri, 2013-09-27 at 10:50 +0200, Martin Basti wrote: >>>> On Mon, 2013-08-26 at 17:16 +0200, Martin Basti wrote: >>>>> Hello, >>>>> >>>>> this patch fix some setup outputs and remove outdated section about >>>>> updating freeIPA version 2 >>>>> >>>>> -- >>>>> Martin Basti >>>> >>>> Updated patch is attached >> >> 1. The new paragraph about different replica version does not sound good. >> >> Instead of: >> There is exception for using older version of replica by upgrading >> process, but there should not be long-running &IPA; servers with >> different versions. >> >> Use: >> There is an exception to the rule ? newer version of replica can >> be installed as a part of upgrade process. All other replicas have >> to be upgraded to the same version in a matter of days or weeks. >> There should not be long-running &IPA; servers with different >> versions. > > Reworded, I hope, it sounds better now. > > Updated patch attached. > ACK, pushed to master. -- Petr Vobornik From pvoborni at redhat.com Fri Oct 4 11:42:10 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 04 Oct 2013 13:42:10 +0200 Subject: [Freeipa-devel] [DOC] 0002 Chapter 3 Installing clients In-Reply-To: <5249A6D3.5040607@redhat.com> References: <1377530741.2139.11.camel@unused-4-145.brq.redhat.com> <1380297127.2116.19.camel@unused-4-145.brq.redhat.com> <5249A6D3.5040607@redhat.com> Message-ID: <524EA992.7010600@redhat.com> On 09/30/2013 06:29 PM, Petr Vobornik wrote: > On 09/27/2013 05:52 PM, Martin Basti wrote: >> On Mon, 2013-08-26 at 17:25 +0200, Martin Basti wrote: >>> Hello, >>> >>> this patch fix some setup outputs, add tips and order of command in >>> examples >>> >>> >>> -- >>> Martin Basti >> >> Updated patch >> > > You did some additional changes( --> etc.) > which were not previously discussed in a review. Please mention it also > in a mail next time. > > This is weird, but it's commented out, so it doesn't matter: > - admin_server = ipaserver.example.com:749 > - default_domain = example.com > - kdc = ipaserver.example.com:88 > - } > + admin_server = ipaserver.example.com:749 > + default_domain = example.com > + kdc = ipaserver.example.com:88 > + } > > ACK Pushed to master. -- Petr Vobornik From pvoborni at redhat.com Fri Oct 4 11:42:29 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 04 Oct 2013 13:42:29 +0200 Subject: [Freeipa-devel] [DOC] 0005 Updated chapter 4 - login into web UI In-Reply-To: <524ADC39.2040703@redhat.com> References: <1379685975.2094.5.camel@unused-4-145.brq.redhat.com> <523C6C47.400@redhat.com> <1380559529.2128.4.camel@unused-4-145.brq.redhat.com> <524ADC39.2040703@redhat.com> Message-ID: <524EA9A5.7040306@redhat.com> On 10/01/2013 04:29 PM, Petr Vobornik wrote: > On 09/30/2013 06:45 PM, Martin Basti wrote: >> On Fri, 2013-09-20 at 17:39 +0200, Petr Vobornik wrote: >>> On 09/20/2013 04:06 PM, Martin Basti wrote: >>>> Logging into web UI and configuring web browser sections were outdated >>>> >>> >>> Thanks for the path. >>> >>> Here are my comments (some for existing issues): >>> >>> 1. There are whitespace warnings when applying this patch. >> Fixed >>> >>> 2. PDF output is bad. Images are too big - right half is not displayed. >>> Several times there is image A with list item for image B below (image B >>> is on the next page with list item for image C). >>> >>> I saw some 'missing image constraints warnings' during build - maybe >>> that's the cause. >> More important is HTML, there is 440px width limit for images in PDF and >> current images are not readable in PDF >> >>> 3. Section 4.3.5: Don't know why it's called 'Simple authentication'. >>> Usually it's referred to as 'forms based authentication'. >> Changed to form based auth >> >>> 3a. Following sentence is misleading: >>> "the error first says to renew the Kerberos credentials or to >>> configure the browser to support Kerberos authentication." >>> IIRC the previous dialog had different wording. The new one gives user >>> two options but it doesn't encourage user to 'renew Kerberos >>> credentials'. Also, you have deleted the first instruction but left a >>> second: "Then simply supply the UID and password for a configured >>> FreeIPA user." without any context. IMO it should be reworded. >> Reworded >> >>> 4. I think the entire section '4.3.6. Using the UI with Proxy Servers' >>> is incorrect. Using Web UI with proxy is not an easy thing to do. >>> >> Removed section >> >>> 5. Old unused images should be deleted. >>> >> Deleted + deleted unused xml which requires unused images >>> 6. Section 4.4.1 (not sure if it's related to this patch) says: >>> "randomly selects up to 20 entries" that's not true. There is no >>> randomness. It selects: First record: ($PAGE_NUM * 20 +1), up to Last: >>> (($PAGE_NUM + 1) *20). When first index is 1. >> Fixed >> >>> 6a. LDAP search limit: the option name is --pkey-only not --pkey. >>> >> Fixed >> >> updated patch attached >> > > Note that 6 and 6a are implemented in mbasti 0004-2. > > ACK > Pushed to master. -- Petr Vobornik From pvoborni at redhat.com Fri Oct 4 11:43:15 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 04 Oct 2013 13:43:15 +0200 Subject: [Freeipa-devel] [DOC] Chapter 4 text In-Reply-To: <524D9270.1000906@redhat.com> References: <1379517057.9269.7.camel@unused-4-145.brq.redhat.com> <1380297179.2116.20.camel@unused-4-145.brq.redhat.com> <524ADC2E.2040805@redhat.com> <1380795133.2201.0.camel@unused-4-145.brq.redhat.com> <524D9270.1000906@redhat.com> Message-ID: <524EA9D3.2010200@redhat.com> On 10/03/2013 05:51 PM, Petr Vobornik wrote: > On 10/03/2013 12:12 PM, Martin Basti wrote: >> On Tue, 2013-10-01 at 16:29 +0200, Petr Vobornik wrote: >>> On 09/27/2013 05:52 PM, Martin Basti wrote: >>>> On Wed, 2013-09-18 at 17:10 +0200, Martin Basti wrote: >>>>> Patch fix examples in chapter 4, adds new examples, fix out of date >>>>> information. >>>>> >>>>> NOTE: Patch doesn't cover part 4.3 Logging with web UI >>> >>>> Updated patch >>>> >>> >>> NACK >>> >>>>> 1. Table 4.1. Configuration Areas Per Tab is missing Trusts in IPA >>>>> tab. This menu item is visible only if ipa-adtrust-install was run. >>> >>>> + Trusts (shown if AD-trust exists) >>> >>> ipa-adtrust-install was run != AD-trust exists >>> >>> From ipa-adtrust-install man page: >>> ipa-adtrust-install - Prepare an IPA server to be able to establish >>> trust relationships with AD domains >> Fixed >> >> Updated patch attached >> > > ACK Pushed to master -- Petr Vobornik From pviktori at redhat.com Fri Oct 4 11:49:07 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Oct 2013 13:49:07 +0200 Subject: [Freeipa-devel] [PATCH] 0309 Do no fail upgrade if the global anonymous read ACI is not, found Message-ID: <524EAB33.5020400@redhat.com> https://fedorahosted.org/freeipa/ticket/3956 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0309-Do-no-fail-upgrade-if-the-global-anonymous-read-ACI-.patch Type: text/x-patch Size: 1718 bytes Desc: not available URL: From pviktori at redhat.com Fri Oct 4 11:50:42 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Oct 2013 13:50:42 +0200 Subject: [Freeipa-devel] [PATCH] 0309 Do not fail upgrade if the global anonymous read ACI is not found In-Reply-To: <524EAB33.5020400@redhat.com> References: <524EAB33.5020400@redhat.com> Message-ID: <524EAB92.8020208@redhat.com> On 10/04/2013 01:49 PM, Petr Viktorin wrote: > https://fedorahosted.org/freeipa/ticket/3956 ... Once more, without the typo in the subject. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0309.2-Do-not-fail-upgrade-if-the-global-anonymous-read-ACI-.patch Type: text/x-patch Size: 1719 bytes Desc: not available URL: From mkosek at redhat.com Fri Oct 4 11:52:50 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Oct 2013 13:52:50 +0200 Subject: [Freeipa-devel] [PATCH] 424 Remove faulty DNS memberOf Task Message-ID: <524EAC12.1000507@redhat.com> This task was added with a DN colliding with privilege update memberOf task being run later and caused this task to be ineffective and thus miss some privilege membership, like "SELinux User Map Administrators" DNS update plugin do not need to run any task at all as privileges will be updated later in scope of 55-pbacmemberof.update https://fedorahosted.org/freeipa/ticket/3877 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-424-remove-faulty-dns-memberof-task.patch Type: text/x-patch Size: 1797 bytes Desc: not available URL: From pviktori at redhat.com Fri Oct 4 12:32:45 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Oct 2013 14:32:45 +0200 Subject: [Freeipa-devel] [PATCH] 424 Remove faulty DNS memberOf Task In-Reply-To: <524EAC12.1000507@redhat.com> References: <524EAC12.1000507@redhat.com> Message-ID: <524EB56D.60301@redhat.com> On 10/04/2013 01:52 PM, Martin Kosek wrote: > This task was added with a DN colliding with privilege update memberOf > task being run later and caused this task to be ineffective and thus > miss some privilege membership, like "SELinux User Map Administrators" > > DNS update plugin do not need to run any task at all as privileges > will be updated later in scope of 55-pbacmemberof.update > > https://fedorahosted.org/freeipa/ticket/3877 I could never reproduce the issue, but the fix seems plausible and doesn't break anything. So ACK, pushed to: master: b1451373c4f918621ce06d8144aaa63e1417777c ipa-3-3: b32ed6d8ba85ec4baa1ebd69c564f2c8fcf7a3a6 -- Petr? From pviktori at redhat.com Fri Oct 4 12:52:51 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Oct 2013 14:52:51 +0200 Subject: [Freeipa-devel] [PATCH] 287 Update translations from Transifex In-Reply-To: <52441629.5040402@redhat.com> References: <52441629.5040402@redhat.com> Message-ID: <524EBA23.5030905@redhat.com> On 09/26/2013 01:10 PM, Petr Viktorin wrote: > Hello, > There'll be a Fedora 20 L10n test on Thursday, and maintainers are asked > to push packages with updated translations by Friday. > > We're planning another minor release after that deadline; in the mean > time I will put this patch into Fedora 20 & Rawhide only. > > The patch goes on top of the ipa-3-3 branch. > > Welcome to new translators: Ubuntu's Adolfo Jayme Barrientos provided > lots of new Spanish words, and Dralyab and G? Baylardfor helped to keep > French up to date. There has been no translation activity since I made the patch, and we're getting close to release, so I've pushed it to upstream as well. master: 321e8635ae74b9e494047ac22d384dfd92a9a28e ipa-3-3: 0a9304c5b91b09aac123591531b42c3610b8b987 Martin, you can remove the Fedora patch when you release. -- Petr? From pspacek at redhat.com Fri Oct 4 13:03:11 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 04 Oct 2013 15:03:11 +0200 Subject: [Freeipa-devel] [PATCHES] 0307-0308 Use direct RPC with specified version in client-install In-Reply-To: <524EA5DD.9050805@redhat.com> References: <524EA5DD.9050805@redhat.com> Message-ID: <524EBC8F.5090108@redhat.com> On 4.10.2013 13:26, Petr Viktorin wrote: > These patches allow a client to enroll with old servers. > > The bug was reported in uploading SSH keys: > https://fedorahosted.org/freeipa/ticket/3931 > but while testing against v2.1 I found and fixed another bug that prevented > the install. > > See the commit messages. > > > With these patches I've successfully enrolled on: > - Fedora 19, master > - Fedora 19, 3.3.1-1 > - Fedora 19, 3.3.1-1, CA-less > - RHEL 6.2, 2.1.3-9 (SSH keys not supported, --force for cert over HTTP) Could you put the information to the freeipa.org web site? E.g. "How-to join RHEL <= 6.2 client to FreeIPA" ? BTW, should we have some 'Compatibility' section in docs? Martin? I'm sorry for nitpicking :-) -- Petr^2 Spacek From pviktori at redhat.com Fri Oct 4 13:10:15 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Oct 2013 15:10:15 +0200 Subject: [Freeipa-devel] [PATCHES] 0307-0308 Use direct RPC with specified version in client-install In-Reply-To: <524EBC8F.5090108@redhat.com> References: <524EA5DD.9050805@redhat.com> <524EBC8F.5090108@redhat.com> Message-ID: <524EBE37.1050004@redhat.com> On 10/04/2013 03:03 PM, Petr Spacek wrote: > On 4.10.2013 13:26, Petr Viktorin wrote: >> These patches allow a client to enroll with old servers. >> >> The bug was reported in uploading SSH keys: >> https://fedorahosted.org/freeipa/ticket/3931 >> but while testing against v2.1 I found and fixed another bug that >> prevented >> the install. >> >> See the commit messages. >> >> >> With these patches I've successfully enrolled on: >> - Fedora 19, master >> - Fedora 19, 3.3.1-1 >> - Fedora 19, 3.3.1-1, CA-less >> - RHEL 6.2, 2.1.3-9 (SSH keys not supported, --force for cert over HTTP) > Could you put the information to the freeipa.org web site? E.g. "How-to > join RHEL <= 6.2 client to FreeIPA" ? The client tells you what to do, and warns that it's insecure. From the code it looks like in normal (not unattended) mode it'll even ask directly. I don't think we need an extra guide on the wiki. > BTW, should we have some 'Compatibility' section in docs? Martin? > > I'm sorry for nitpicking :-) -- Petr? From mbasti at redhat.com Fri Oct 4 13:14:33 2013 From: mbasti at redhat.com (Martin Basti) Date: Fri, 04 Oct 2013 15:14:33 +0200 Subject: [Freeipa-devel] [PATCHES] 0307-0308 Use direct RPC with specified version in client-install In-Reply-To: <524EBC8F.5090108@redhat.com> References: <524EA5DD.9050805@redhat.com> <524EBC8F.5090108@redhat.com> Message-ID: <1380892473.2378.6.camel@unused-4-145.brq.redhat.com> On Fri, 2013-10-04 at 15:03 +0200, Petr Spacek wrote: > On 4.10.2013 13:26, Petr Viktorin wrote: > > These patches allow a client to enroll with old servers. > > > > The bug was reported in uploading SSH keys: > > https://fedorahosted.org/freeipa/ticket/3931 > > but while testing against v2.1 I found and fixed another bug that prevented > > the install. > > > > See the commit messages. > > > > > > With these patches I've successfully enrolled on: > > - Fedora 19, master > > - Fedora 19, 3.3.1-1 > > - Fedora 19, 3.3.1-1, CA-less > > - RHEL 6.2, 2.1.3-9 (SSH keys not supported, --force for cert over HTTP) > Could you put the information to the freeipa.org web site? E.g. "How-to join > RHEL <= 6.2 client to FreeIPA" ? > > BTW, should we have some 'Compatibility' section in docs? Martin? It is only for RHEL, it should be in IdM Guide, maintained by Deon. > > I'm sorry for nitpicking :-) > -- Martin Basti From jcholast at redhat.com Fri Oct 4 13:34:13 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 04 Oct 2013 15:34:13 +0200 Subject: [Freeipa-devel] [PATCHES] 0307-0308 Use direct RPC with specified version in client-install In-Reply-To: <524EA5DD.9050805@redhat.com> References: <524EA5DD.9050805@redhat.com> Message-ID: <524EC3D5.4070003@redhat.com> Hi, On 4.10.2013 13:26, Petr Viktorin wrote: > These patches allow a client to enroll with old servers. > > The bug was reported in uploading SSH keys: > https://fedorahosted.org/freeipa/ticket/3931 > but while testing against v2.1 I found and fixed another bug that > prevented the install. > > See the commit messages. > > > With these patches I've successfully enrolled on: > - Fedora 19, master > - Fedora 19, 3.3.1-1 > - Fedora 19, 3.3.1-1, CA-less > - RHEL 6.2, 2.1.3-9 (SSH keys not supported, --force for cert over HTTP) > ACK. Honza -- Jan Cholasta From pviktori at redhat.com Fri Oct 4 13:40:28 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Oct 2013 15:40:28 +0200 Subject: [Freeipa-devel] [PATCHES] 0307-0308 Use direct RPC with specified version in client-install In-Reply-To: <524EC3D5.4070003@redhat.com> References: <524EA5DD.9050805@redhat.com> <524EC3D5.4070003@redhat.com> Message-ID: <524EC54C.200@redhat.com> On 10/04/2013 03:34 PM, Jan Cholasta wrote: > Hi, > > On 4.10.2013 13:26, Petr Viktorin wrote: >> These patches allow a client to enroll with old servers. >> >> The bug was reported in uploading SSH keys: >> https://fedorahosted.org/freeipa/ticket/3931 >> but while testing against v2.1 I found and fixed another bug that >> prevented the install. >> >> See the commit messages. >> >> >> With these patches I've successfully enrolled on: >> - Fedora 19, master >> - Fedora 19, 3.3.1-1 >> - Fedora 19, 3.3.1-1, CA-less >> - RHEL 6.2, 2.1.3-9 (SSH keys not supported, --force for cert over HTTP) >> > > ACK. > > Honza > Thanks, pushed to: master: 5824a0e14e73f8d13a93ccccf1b5213488ff9eaa ipa-3-3: 96ab7002ac2acfc129dd73f1fc9b023a6fbf3723 -- Petr? From mkosek at redhat.com Fri Oct 4 13:42:48 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Oct 2013 15:42:48 +0200 Subject: [Freeipa-devel] [PATCH] 0309 Do not fail upgrade if the global anonymous read ACI is not found In-Reply-To: <524EAB92.8020208@redhat.com> References: <524EAB33.5020400@redhat.com> <524EAB92.8020208@redhat.com> Message-ID: <524EC5D8.6010503@redhat.com> On 10/04/2013 01:50 PM, Petr Viktorin wrote: > On 10/04/2013 01:49 PM, Petr Viktorin wrote: >> https://fedorahosted.org/freeipa/ticket/3956 > > ... Once more, without the typo in the subject. > ACK! Works fine. Pushed to master, ipa-3-3. Martin From pviktori at redhat.com Fri Oct 4 13:50:15 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 04 Oct 2013 15:50:15 +0200 Subject: [Freeipa-devel] [PATCH] 0304 ipapython.nsslib: Name arguments to NSPRError In-Reply-To: <524C408B.1010309@redhat.com> References: <524C2EDE.5000006@redhat.com> <524C408B.1010309@redhat.com> Message-ID: <524EC797.7080102@redhat.com> On 10/02/2013 05:49 PM, Petr Vobornik wrote: > On 10/02/2013 04:34 PM, Petr Viktorin wrote: >> As I found out when installing on a misconfigured system, we use wrong >> argument order for NSPRError in nsslib. This patch corrects the problem. > > ACK > > A nitpick: > $ git diff HEAD~1 | pep8 --diff > ./ipapython/nsslib.py:145:14: E111 indentation is not a multiple of four > ./ipapython/nsslib.py:148:21: E128 continuation line under-indented for > visual indent > > You are a bigger fan of pep8, so it's up to you... Thanks, fixed E111 and pushed to master: 80886a50e6157e6a0b8f3f09523ba7d2c2b8001c ipa-3-3: 54a7c84d02c92133b1d1283f01b7a46cbaa50229 -- Petr? From mkosek at redhat.com Fri Oct 4 15:20:30 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Oct 2013 17:20:30 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 3.3.2 Message-ID: <524EDCBE.6060107@redhat.com> The FreeIPA team is proud to announce FreeIPA v3.3.2! It can be downloaded from http://www.freeipa.org/page/Downloads. Fedora 19 builds are already on their way to updates-testing repo. == Highlights in 3.3.2 == === Enhancements === * Multiple domains from a trusted Active Directory forest supported now * Issue warnings when installed FreeIPA realm differs from the main domain as this setup prevents configuring AD trusts * Allow PKCS#12 files with empty password in install tools === Bug fixes === * ipa-replica-manage no longer returns RUV error when removing a replica * ipa-replica-install no longer crashes when being run against a master with older Directory Server * When creating AD trust, report supported enctypes based on Kerberos realm configuration * ... and numerous other small fixes === Test improvements === * New tests for forced client re-enrollment feature * Integration tests no longer require python-paramiko and can run on top of bare SSH connection * Numerous small fixes in beakerlib integration == Supporting Multiple Domains from Trusted Active Directory Forest == Previously only a root level domain of a trusted AD forest was supported. Now all domains of the trusted AD forest can access resources in a FreeIPA domain. Free IPA admins are now able to refresh list of domains from a trusted AD forest and selectively enable and disable specific domains from accessing resources in FreeIPA domain. Following commands were added to FreeIPA CLI: * ipa trust-fetch-domains ** Refresh list of domains from a trusted AD forest. By default all found domains belonging to the forest will be allowed to access IPA resources. * ipa trustdomain-find [domain] ** List domains of the trusted AD forest, displaying their attributes. When ''domain'' is specified in addition to the trust name, only information about ''domain'' is shown. * ipa trustdomain-disable ** Disable access from of the to IPA resources. * ipa trustdomain-enable ** Enable access from of the to IPA resources. * ipa trustdomain-del ** Remove information about of the from IPA view about the trusted AD forest. Users from will not be able to access IPA resources. Following IPA commands were extended: * ipa trust-add ** When trust to an AD forest is established, list of domains of the forest will be fetched and identity ranges for them will be created automatically. In case of POSIX attributes being managed by the AD forest, a single identity range for the trusted forest's root level domain will be re-used. ** When trust to an AD forest is established, list of domains associated with IPA is provided to the DC of the forest root level domain. This information is used to enable name suffix routing for systems belonging to IPA domain. As result, if IPA master servers don't belong to IPA DNS domain namespace, they will be able to access resources in the trusted AD forest. FreeIPA 3.3.2 requires use of SSSD 1.11.1 due to integration of non-root level forest domains support. == Upgrading == === FreeIPA servers with CA installed prior to version 3.1 === Manual upgrade procedure is required for FreeIPA servers installed with version prior to 3.1. Please see http://www.freeipa.org/page/Howto/Dogtag9ToDogtag10Migration for details. === Other FreeIPA servers and clients === 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.1 == === Alexander Bokovoy (11): === * ipa-sam: do not modify objectclass when trust object already created * ipa-sam: do not leak LDAPMessage on ipa-sam initialization * ipa-sam: report supported enctypes based on Kerberos realm configuration * ipaserver/dcerpc.py: populate forest trust information using realmdomains * trusts: support subdomains in a forest * frontend: report arguments errors with better detail * ipaserver/dcerpc: remove use of trust account authentication * trust: integrate subdomains support into trust-add * ipasam: for subdomains pick up defaults for missing values * KDC: implement transition check for trusted domains * ipa-kdb: Handle parent-child relationship for subdomains === Ana Krivokapic (5): === * Add integration tests for forced client re-enrollment * Create DS user and group during ipa-restore * Add warning when uninstalling active replica * Do not crash if DS is down during server uninstall * Follow tmpfiles.d packaging guidelines === Jan Cholasta (3): === * Fix nsslapdPlugin object class after initial replication. * Read passwords from stdin when importing PKCS#12 files with pk12util. * Allow PKCS#12 files with empty password in install tools. === Martin Kosek (5): === * Use FQDN when creating MSDCS SRV records * Do not set DNS discovery domain in server mode * Require new SSSD to pull required AD subdomain fixes * Remove faulty DNS memberOf Task * Become IPA 3.3.2 === Nathaniel McCallum (1): === * Ensure credentials structure is initialized === Petr Spacek (1): === * Add timestamps to named debug logs in /var/named/data/named.run === Petr Viktorin (15): === * Remove __all__ specifications in ipaclient and ipaserver.install * Make make-lint compatible with Pylint 1.0 * test_integration.host: Move transport-related functionality to a new module * test_integration: Add OpenSSHTransport, used if paramiko is not available * ipatests.test_integration.test_caless: Fix mkdir_recursive call * ipatests.beakerlib_plugin: Warn instead of failing when some logs are missing * ipatests.order_plugin: Exclude test generators from the order * ipatests.beakerlib_plugin: Add argument of generated tests to test captions * ipatests.test_cmdline.test_help: Re-raise unexpected exceptions on failure * Add tests for installing with empty PKCS#12 password * Update translations from Transifex * ipa-client-install: Use direct RPC instead of api.Command * ipa-client-install: Verify RPC connection with a ping * Do not fail upgrade if the global anonymous read ACI is not found * ipapython.nsslib: Name arguments to NSPRError === Petr Vobornik (5): === * Fix RUV search scope in ipa-replica-manage * Fix redirection on deletion of last dns record entry * Allow edit of ipakrbokasdelegate in Web UI when attrlevelrights are unknown * Fix enablement of automount map type selector * ipatests.test_integration.host: Add logging to ldap_connect() === Simo Sorce (1): === * Add Delegation Info to MS-PAC === Sumit Bose (1): === * CLDAP: do not read IPA domain from hostname === Tomas Babej (3): === * Use getent admin at domain for nss check in ipa-client-install * Do not add trust to AD in case of IPA realm-domain mismatch * Warn user about realm-domain mismatch in install scripts From mkosek at redhat.com Fri Oct 4 15:44:09 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 04 Oct 2013 17:44:09 +0200 Subject: [Freeipa-devel] [PATCH] 425 Do not allow '%' in DM password Message-ID: <524EE249.3080004@redhat.com> Having '%' in DM password causes pkispawn to crash. Do not allow users to enter it until pkispawn is fixed. https://bugzilla.redhat.com/show_bug.cgi?id=953488 --- Pushed as a one-liner to master, ipa-3-3. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-425-do-not-allow-in-dm-password.patch Type: text/x-patch Size: 1167 bytes Desc: not available URL: From npmccallum at redhat.com Fri Oct 4 17:33:04 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 04 Oct 2013 13:33:04 -0400 Subject: [Freeipa-devel] [PATCH 0020] Add IntEnum parameter to ipalib Message-ID: <1380907984.1760.1.camel@localhost> This patch is preparatory for the OTP CLI patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0020-Add-IntEnum-parameter-to-ipalib.patch Type: text/x-patch Size: 1818 bytes Desc: not available URL: From npmccallum at redhat.com Fri Oct 4 17:34:54 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 04 Oct 2013 13:34:54 -0400 Subject: [Freeipa-devel] [PATCH 0021] Don't special case the Password class in Param.__init__() Message-ID: <1380908094.1760.3.camel@localhost> This patch is preparatory for the OTP CLI patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0021-Don-t-special-case-the-Password-class-in-Param.__ini.patch Type: text/x-patch Size: 2207 bytes Desc: not available URL: From npmccallum at redhat.com Fri Oct 4 17:36:12 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 04 Oct 2013 13:36:12 -0400 Subject: [Freeipa-devel] [PATCH 0022] Document no_search in Param flags Message-ID: <1380908172.1760.5.camel@localhost> This patch is preparatory for the OTP CLI patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0022-Document-no_search-in-Param-flags.patch Type: text/x-patch Size: 1170 bytes Desc: not available URL: From npmccallum at redhat.com Fri Oct 4 17:37:51 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 04 Oct 2013 13:37:51 -0400 Subject: [Freeipa-devel] [PATCH 0023] Add optional_create flag Message-ID: <1380908271.1760.7.camel@localhost> This patch is preparatory for the OTP CLI patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0023-Add-optional_create-flag.patch Type: text/x-patch Size: 2713 bytes Desc: not available URL: From npmccallum at redhat.com Fri Oct 4 20:01:42 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 04 Oct 2013 16:01:42 -0400 Subject: [Freeipa-devel] [PATCH 0023] Add optional_create flag In-Reply-To: <1380908271.1760.7.camel@localhost> References: <1380908271.1760.7.camel@localhost> Message-ID: <1380916902.1760.9.camel@localhost> On Fri, 2013-10-04 at 13:37 -0400, Nathaniel McCallum wrote: > This patch is preparatory for the OTP CLI patch. I'm not quite sure why, but this patch apparently changes the output of ./makeapi. This change is now included in the attached patch. Is this a mistake of some sort? Or is this just correct? Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0023-2-Add-optional_create-flag.patch Type: text/x-patch Size: 70238 bytes Desc: not available URL: From npmccallum at redhat.com Fri Oct 4 20:16:50 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 04 Oct 2013 16:16:50 -0400 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI Message-ID: <1380917810.1760.23.camel@localhost> This patch supersedes my patch 0017 and requires patches 0020-0023. I believe I have solved all of the outstanding issues from the review of patch 0017, unless otherwise noted: 1. I'm not actually sure what the format of the date parameters is. Could someone clarify this for me? Should I do something differently here? 2. In this new version of the patch, we are writing default values for many of the token attributes. It would be nice to have some global defaults for these default values, but this is not currently implemented. I think this would make a clean secondary patch on top of this current patch. 3. Dmitri brought up the idea of having tokens automatically expire by default. Is this a good idea? I think this dovetails nicely with #2 above. 4. This patch does not currently protect the deletion of the last token as previously discussed. Here is why I think this is still needed, but in the form of a DS plugin: We need to account for a state when the user is enabled for OTP but has not yet configured any tokens. I believe this state should be when the "otp" user auth type is set, but the user has no assigned tokens. In this state, the user should be able to log in with single factor authentication. Once the user has added tokens, however, should we allow the user to remove all his own tokens and return to single factor authentication? If yes, nothing further is needed. If no, then protection in the FreeIPA framework is not sufficient and this needs to be checked at the DS plugin level. I suspect Dmitri might answer that this needs to be a matter of policy. 5. There appears to be some sort of permissions issue with users and adding their own tokens. I have not looked into this yet, but I will review this early next week. Since this is a small bug fix to an existing feature, I figured it was out of scope for this patch. 6. When a user is deleted, all his tokens are deleted as well. This is sensible default behavior. However, in the case of hardware tokens, it may be more desirable to orphan these objects for future assignment to new users. Does anyone have any opinions on this topic? Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0024-Add-OTP-support-to-ipalib-CLI.patch Type: text/x-patch Size: 29657 bytes Desc: not available URL: From ayoung at redhat.com Fri Oct 4 20:31:36 2013 From: ayoung at redhat.com (Adam Young) Date: Fri, 04 Oct 2013 16:31:36 -0400 Subject: [Freeipa-devel] DNS views in FreeIPA again In-Reply-To: <524A8B93.40800@redhat.com> References: <523C85E5.7070207@redhat.com> <52404F6B.3050107@redhat.com> <52407519.8070502@redhat.com> <524A8B93.40800@redhat.com> Message-ID: <524F25A8.2020109@redhat.com> On 10/01/2013 04:45 AM, Petr Spacek wrote: > On 23.9.2013 19:06, Dmitri Pal wrote: >> On 09/23/2013 10:25 AM, Petr Spacek wrote: >>> On 20.9.2013 19:29, Dmitri Pal wrote: >>>> 5) Met with James (the blogger) and the community guy who created >>>> puppet >>>> scripts for IPA. He was trying to convince me that we need to support >>>> the use case when IPA is the DNS that provides two different sets >>>> of the >>>> IPA addresses for the IPA clients running inside the subnet and >>>> outside >>>> the subnet. I see a clear use case and value. So that get back to the >>>> views. Why do we thing views will be a problem in IPA? >>> >>> In principle - it is technically possible. Just pretty hard. >>> >>> - It requires re-designing of LDAP schema for DNS. >>> - It implies that we will have to adapt all parts of FreeIPA and >>> bind-dyndb-ldap which touches the LDAP. >>> - And also re-design CLI and WebUI, because views adds one level of >>> indirection: Your will need some tool to see what is in the particular >>> view, move records from one view to another, share records between >>> views, do exceptions etc. >>> >>> We tried to design schema for views approximately year ago, but there >>> wasn't a clear agreement on that. >>> >> Hm. OK. That means that we are probably over complicating things. Do you >> have a pointer to design? > > It has been more 'discussion' without clear outcome then real design: > https://www.redhat.com/archives/freeipa-users/2012-April/msg00070.html > https://www.redhat.com/archives/freeipa-devel/2012-May/msg00208.html > >> Let us table the actual design conversation for now but when we start >> 3.5 planning I want to take a closer look. > > We should move the discussion to freeipa-devel at thins point ... > > > I have spent some time thinking about DNS views and I think that we > should design support for DNS views as soon as possible. Opening up the discussion. This is FreeIPA general stuff: I think that the idea of different internal and external views is not specific to DNS. Other things that might be different between internal and external: Kerberos might only want to let a subset of users get tickets from outside the VPN, and only provide service tickets for services in the DMZ You might want to run an Kerberos KDC proxy outside of the IPA instance LDAP might be limited to read only when accessed from outside, and only a subset of users, or a subset of the data from other entities would be exposed Dogtag might want to only publish CRL and expose OCSP to the outside world IPA ui might be limited to self service Perhaps a better abstraction is an IPA proxy, a server that is an incomplete replica of an IPA server. As such it would get: 1. A subset of the data from the canonical LDAP server 2. Some of that data would be modified, such as the A records marked for external use 3. It will not push updates to the centralized server. It will be configured to not accept updates from the outside world. > > Resulting design will significantly influence bind-dyndb-ldap > internals & also DNSSEC support. At the moment, the code relies on > assumption that one LDAP object = one DNS name. > > We have to find out if DNS views will break this assumption as soon as > possible. IMHO views will change things significantly, including this > 1:1 mapping - which will require major code re-design. > > I would like to avoid re-designing for DNSSEC and then immediate > re-design for DNS views. > From dpal at redhat.com Fri Oct 4 21:41:59 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 04 Oct 2013 17:41:59 -0400 Subject: [Freeipa-devel] DNS views in FreeIPA again In-Reply-To: <524F25A8.2020109@redhat.com> References: <523C85E5.7070207@redhat.com> <52404F6B.3050107@redhat.com> <52407519.8070502@redhat.com> <524A8B93.40800@redhat.com> <524F25A8.2020109@redhat.com> Message-ID: <524F3627.6030003@redhat.com> On 10/04/2013 04:31 PM, Adam Young wrote: > On 10/01/2013 04:45 AM, Petr Spacek wrote: >> On 23.9.2013 19:06, Dmitri Pal wrote: >>> On 09/23/2013 10:25 AM, Petr Spacek wrote: >>>> On 20.9.2013 19:29, Dmitri Pal wrote: >>>>> 5) Met with James (the blogger) and the community guy who created >>>>> puppet >>>>> scripts for IPA. He was trying to convince me that we need to support >>>>> the use case when IPA is the DNS that provides two different sets >>>>> of the >>>>> IPA addresses for the IPA clients running inside the subnet and >>>>> outside >>>>> the subnet. I see a clear use case and value. So that get back to the >>>>> views. Why do we thing views will be a problem in IPA? >>>> >>>> In principle - it is technically possible. Just pretty hard. >>>> >>>> - It requires re-designing of LDAP schema for DNS. >>>> - It implies that we will have to adapt all parts of FreeIPA and >>>> bind-dyndb-ldap which touches the LDAP. >>>> - And also re-design CLI and WebUI, because views adds one level of >>>> indirection: Your will need some tool to see what is in the particular >>>> view, move records from one view to another, share records between >>>> views, do exceptions etc. >>>> >>>> We tried to design schema for views approximately year ago, but there >>>> wasn't a clear agreement on that. >>>> >>> Hm. OK. That means that we are probably over complicating things. Do >>> you >>> have a pointer to design? >> >> It has been more 'discussion' without clear outcome then real design: >> https://www.redhat.com/archives/freeipa-users/2012-April/msg00070.html >> https://www.redhat.com/archives/freeipa-devel/2012-May/msg00208.html >> >>> Let us table the actual design conversation for now but when we start >>> 3.5 planning I want to take a closer look. >> >> We should move the discussion to freeipa-devel at thins point ... >> >> >> I have spent some time thinking about DNS views and I think that we >> should design support for DNS views as soon as possible. > > Opening up the discussion. This is FreeIPA general stuff: > > I think that the idea of different internal and external views is not > specific to DNS. Other things that might be different between > internal and external: > > Kerberos might only want to let a subset of users get tickets from > outside the VPN, and only provide service tickets for services in the DMZ > You might want to run an Kerberos KDC proxy outside of the IPA instance > LDAP might be limited to read only when accessed from outside, and > only a subset of users, or a subset of the data from other entities > would be exposed > Dogtag might want to only publish CRL and expose OCSP to the outside > world > IPA ui might be limited to self service > > Perhaps a better abstraction is an IPA proxy, a server that is an > incomplete replica of an IPA server. As such it would get: > > 1. A subset of the data from the canonical LDAP server > 2. Some of that data would be modified, such as the A records marked > for external use > 3. It will not push updates to the centralized server. It will be > configured to not accept updates from the outside world. > > > >> >> Resulting design will significantly influence bind-dyndb-ldap >> internals & also DNSSEC support. At the moment, the code relies on >> assumption that one LDAP object = one DNS name. >> >> We have to find out if DNS views will break this assumption as soon >> as possible. IMHO views will change things significantly, including >> this 1:1 mapping - which will require major code re-design. >> >> I would like to avoid re-designing for DNSSEC and then immediate >> re-design for DNS views. >> > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel This brings us to the read only replicas. May be it is time to think about those more seriously? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jfenal at gmail.com Sat Oct 5 11:00:02 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Sat, 5 Oct 2013 13:00:02 +0200 Subject: [Freeipa-devel] [DOC] Use entities when citing product name Message-ID: Trivial patch attached. -- J?r?me Fenal -------------- next part -------------- A non-text attachment was scrubbed... Name: Installing-use-productname-entities.diff Type: application/octet-stream Size: 747 bytes Desc: not available URL: From jfenal at gmail.com Sat Oct 5 12:22:22 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Sat, 5 Oct 2013 14:22:22 +0200 Subject: [Freeipa-devel] Changed trac wiki page for freeipa-guide Message-ID: Hi there, just a quick head-up to tell I've just changed the wiki page at https://fedorahosted.org/freeipa-guide/wiki/WikiStart to reflect the new documentation process (and refer to the right git repo and freeipa.org page). Regards, J. -- J?r?me Fenal From mkosek at redhat.com Mon Oct 7 07:34:27 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 07 Oct 2013 09:34:27 +0200 Subject: [Freeipa-devel] Changed trac wiki page for freeipa-guide In-Reply-To: References: Message-ID: <52526403.9060501@redhat.com> On 10/05/2013 02:22 PM, J?r?me Fenal wrote: > Hi there, > > just a quick head-up to tell I've just changed the wiki page at > https://fedorahosted.org/freeipa-guide/wiki/WikiStart to reflect the > new documentation process (and refer to the right git repo and > freeipa.org page). > > Regards, > > J. > Thanks, J?r?me. This will help drive people to the new doc repo. I also added a link to FreeIPA guidelines with information about git repo, patch creation and submission, etc. Martin From mbasti at redhat.com Mon Oct 7 10:06:28 2013 From: mbasti at redhat.com (Martin Basti) Date: Mon, 07 Oct 2013 12:06:28 +0200 Subject: [Freeipa-devel] [PATCH][DOC] 0008 Chapter 6 update Message-ID: <1381140388.2228.1.camel@unused-4-145.brq.redhat.com> Requires to apply patch 0007 before -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0008-Chapter-6-update.patch Type: text/x-patch Size: 1177323 bytes Desc: not available URL: From pviktori at redhat.com Mon Oct 7 10:56:59 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Oct 2013 12:56:59 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <1378355153.19352.29.camel@localhost> References: <1378355153.19352.29.camel@localhost> Message-ID: <5252937B.9030108@redhat.com> On 09/05/2013 06:25 AM, Nathaniel McCallum wrote: > This patch has a few problems that I'd like some help with. There are a > few notes here as well. > > 1. The handling of the 'key' option is insecure. It should probably be > treated like a password (hidden from logs, etc). However, in this case, > it is binary, so I'm not quite sure how to do that. Passing it as a > command line option may be nice for scripting, but is potentially a > security problem if it ends up in bash.history. It would also be nice if > the encoding were base32 instead of base64, since nearly all the OTP > tools use this encoding. > > 2. The 'key' option also appears in otp-find. I'd like to suppress this. > How? > > 3. I had to make the 'id' option optional to make the uuid > autogeneration work in otp-add. However, this has the side-effect that > 'id' is now optional in all the other commands. This is particularly bad > in the case of otp-del, where calling this command with no ID > transparently removes all tokens. How can I make this optional for > otp-add but required for all other commands? > > 4. otp-import is not implemented. I spent a few hours looking and I > didn't find any otp tool that actually uses this xml format for > exporting. Should we implement this now or wait until someone can > actually export data to us? > > 5. otp-del happily deletes the last token for a user. How can I find out > the dn of the user executing the command? Also, what is the right > exception to throw in pre_callback()? > > 6. user-show does not list the associated tokens for this user. Do we > care? It is a single search: otp-find --owner npmccallum. > > 7. otp-add only prints the qr code if the --qrcode option is specified. > This is for two reasons. First, and most importantly, the qr code > doesn't fit on a standard 24x80 terminal. I wanted to avoid dumping > garbage on people's screens by default. Second, you may not always want > the qr code output (like for a hard token or manual code entry). > > Nathaniel For the record: This patch was superseded by Nathaniel's patch 0024. -- Petr? From pviktori at redhat.com Mon Oct 7 11:22:58 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Oct 2013 13:22:58 +0200 Subject: [Freeipa-devel] [PATCH 0020] Add IntEnum parameter to ipalib In-Reply-To: <1380907984.1760.1.camel@localhost> References: <1380907984.1760.1.camel@localhost> Message-ID: <52529992.6050805@redhat.com> On 10/04/2013 07:33 PM, Nathaniel McCallum wrote: > This patch is preparatory for the OTP CLI patch. > + def _convert_scalar(self, value, index=None): > + return Int._convert_scalar(self, value, index=index) That won't work. In Python 2 unbound methods (such as Int._validate_scalar) must be passed the correct type as self; passing an IntEnum instance like this will raise a TypeError. You'll need to either use multiple inheritance (if you feel the framework isn't complex enough), or make a convert_int function, and then in both Int and IntEnum just call it and handle ValueError. For validate_scalar it would probably be best to extend Param._validate_scalar to allow the class to define extra allowed types, and get rid of the reimplementation in Int. -- Petr? From pviktori at redhat.com Mon Oct 7 11:47:08 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Oct 2013 13:47:08 +0200 Subject: [Freeipa-devel] [PATCH 0021] Don't special case the Password class in Param.__init__() In-Reply-To: <1380908094.1760.3.camel@localhost> References: <1380908094.1760.3.camel@localhost> Message-ID: <52529F3C.8060309@redhat.com> On 10/04/2013 07:34 PM, Nathaniel McCallum wrote: > This patch is preparatory for the OTP CLI patch. Thanks for the patch; it needs some work. >>From 2678ff4e2f22e7e81bf40b30ffcd0efe0ecf08c2 Mon Sep 17 00:00:00 2001 > From: Nathaniel McCallum > Date: Mon, 30 Sep 2013 13:06:37 -0400 > Subject: [PATCH] Don't special case the Password class in Param.__init__() > > --- > ipalib/parameters.py | 20 ++++++++++---------- > 1 file changed, 10 insertions(+), 10 deletions(-) > > diff --git a/ipalib/parameters.py b/ipalib/parameters.py > index fbcb87537ba662763a00e12178d424a8718baa8a..925f442968ab93b2b6df4e386d03558300bf5990 100644 > --- a/ipalib/parameters.py > +++ b/ipalib/parameters.py > @@ -398,11 +398,11 @@ class Param(ReadOnly): > # We keep these values to use in __repr__(): > self.param_spec = name > self.__kw = dict(kw) > - > - if isinstance(self, Password): > - self.password = True > - else: > + > + try: > self.password = False > + except AttributeError: > + pass Setting the attribute here will always pass, and always re-set `password` to False, even for Password instances. A class-level attribute (both in Param and Password) would work better here: class Param(ReadOnly): ... password = False ... class Password(Str): ... password = True ... You can run a part of the test suite to verify changes in ipalib (test_ipalib happens to not need an installed server): ./make-test ipatests/test_ipalib or just for parameters: ./make-test ipatests/test_ipalib/test_parameters.py BTW, Git complains trailing whitespace. I found the following Git setting useful to spot this before `git am`: $ git config color.diff.whitespace 'red reverse' -- Petr? From pviktori at redhat.com Mon Oct 7 12:01:19 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Oct 2013 14:01:19 +0200 Subject: [Freeipa-devel] [PATCH 0022] Document no_search in Param flags In-Reply-To: <1380908172.1760.5.camel@localhost> References: <1380908172.1760.5.camel@localhost> Message-ID: <5252A28F.40402@redhat.com> On 10/04/2013 07:36 PM, Nathaniel McCallum wrote: > This patch is preparatory for the OTP CLI patch. Thank you! ACK, pushed to master: 12ae6a054a20134fe51f195933ced7b52b2bd2ed -- Petr? From pviktori at redhat.com Mon Oct 7 12:26:06 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Oct 2013 14:26:06 +0200 Subject: [Freeipa-devel] [PATCH 0023] Add optional_create flag In-Reply-To: <1380916902.1760.9.camel@localhost> References: <1380908271.1760.7.camel@localhost> <1380916902.1760.9.camel@localhost> Message-ID: <5252A85E.5060906@redhat.com> On 10/04/2013 10:01 PM, Nathaniel McCallum wrote: > On Fri, 2013-10-04 at 13:37 -0400, Nathaniel McCallum wrote: >> This patch is preparatory for the OTP CLI patch. > > I'm not quite sure why, but this patch apparently changes the output > of ./makeapi. This change is now included in the attached patch. Is this > a mistake of some sort? Or is this just correct? > > Nathaniel Apparently, Param.clone() uses all options, even those that are left out of what API.txt reports (see __kw and __clonekw in Param.__init__). IMO it's not ideal behavior, makeapi should have used __clonekw directly. Anyway, to keep API.txt as before, only clone if necessary: def __clone(self, param, **kw): if 'optional_create' in param.flags: kw['required'] = False - return param.clone(**kw) + if kw: + return param.clone(**kw) + else: + return param -- Petr? From thozza at redhat.com Mon Oct 7 13:19:08 2013 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 07 Oct 2013 15:19:08 +0200 Subject: [Freeipa-devel] [PATCH 0181] Replace LDAP persistent search with syncrepl (RFC 4533) In-Reply-To: <51ED3091.8050003@redhat.com> References: <51ED1647.5020805@redhat.com> <51ED3091.8050003@redhat.com> Message-ID: <5252B4CC.3000407@redhat.com> On 07/22/2013 03:16 PM, Petr Spacek wrote: > On 22.7.2013 13:23, Petr Spacek wrote: >> Hello, >> >> Replace LDAP persistent search with syncrepl (RFC 4533). >> >> All direct operations with LDAP Persistent Search control are replaced >> by ldap_sync_* calls. >> >> Syncrepl code works in exactly same way as old psearch code: >> Only the DN of the modified object is re-used from the message, >> data from the object are fetched via separate LDAP search. >> >> Current code is not able to detect object renaming because we don't have >> UUID->DN mapping yet. >> >> Another limitation is that current code can't detect unchanged entries, >> so serial is incremented after each parsed LDAP object. > > Clang noticed potential NULL dereference in cleanup section of > ldap_syncrepl_watcher(). Fixed patch is attached. > ACK. Tested Patch bundle 181 - 185. Common tasks like adding/deleting/updating records work fine. Also PTR sync, zone serial number incrementation is OK. Regards, Tomas From thozza at redhat.com Mon Oct 7 13:20:17 2013 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 07 Oct 2013 15:20:17 +0200 Subject: [Freeipa-devel] [PATCH 0182] Fix false error messages when nonexistent object/attribute is deleted In-Reply-To: <51FA674A.5020708@redhat.com> References: <51FA674A.5020708@redhat.com> Message-ID: <5252B511.9010207@redhat.com> On 08/01/2013 03:48 PM, Petr Spacek wrote: > Hello, > > Fix false error messages when nonexistent object/attribute is deleted. > > > This patch should go to branches v3 and master. > ACK. Tested Patch bundle 181 - 185. Common tasks like adding/deleting/updating records work fine. Also PTR sync, zone serial number incrementation is OK. No unexpected errors are printed. The described scenario was fixed by this patch. Regards, Tomas From thozza at redhat.com Mon Oct 7 13:20:51 2013 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 07 Oct 2013 15:20:51 +0200 Subject: [Freeipa-devel] [PATCH 0183] Move data structures for parser from ldap_qresult_t to ldap_entry_t In-Reply-To: <51FA6782.6060601@redhat.com> References: <51FA6782.6060601@redhat.com> Message-ID: <5252B533.1090100@redhat.com> On 08/01/2013 03:49 PM, Petr Spacek wrote: > Hello, > > Move data structures for parser from ldap_qresult_t to ldap_entry_t. > > > The target branch is master. > ACK. Tested Patch bundle 181 - 185. Common tasks like adding/deleting/updating records work fine. Also PTR sync, zone serial number incrementation is OK. Regards, Tomas From thozza at redhat.com Mon Oct 7 13:21:23 2013 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 07 Oct 2013 15:21:23 +0200 Subject: [Freeipa-devel] [PATCH 0184] Use DNS_RDATA_MAXLENGTH from rdata.h instead of own definition In-Reply-To: <51FA67D0.4040103@redhat.com> References: <51FA67D0.4040103@redhat.com> Message-ID: <5252B553.8080500@redhat.com> On 08/01/2013 03:51 PM, Petr Spacek wrote: > Hello, > > Use DNS_RDATA_MAXLENGTH from rdata.h instead of own definition. > > > This minor fix could go to v3 and master. > ACK. Tested Patch bundle 181 - 185. Common tasks like adding/deleting/updating records work fine. Also PTR sync, zone serial number incrementation is OK. Regards, Tomas From thozza at redhat.com Mon Oct 7 13:27:00 2013 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 07 Oct 2013 15:27:00 +0200 Subject: [Freeipa-devel] [PATCH 0185] Do not execute new LDAP search for each updated object In-Reply-To: <51FA6837.60103@redhat.com> References: <51FA6837.60103@redhat.com> Message-ID: <5252B6A4.5080909@redhat.com> On 08/01/2013 03:52 PM, Petr Spacek wrote: > Hello, > > Do not execute new LDAP search for each updated object. > > Syncrepl delivers notification about change in particular object > along with all data from the object. Resource Records are parsed out > from this data instead of data obtained via separate LDAP search. > > Current code doesn't have any rate limitation. As a result, > ldap_sync_init/poll() can enqueue update events faster than rest of BIND > is able to dequeue and process them. Unprocessed events can consume > significant amount of memory. This area definitely needs improvement. > > > This is next in complete transition to RBTDB. It should go to master. > ACK. Tested Patch bundle 181 - 185. Common tasks like adding/deleting/updating records work fine. Also PTR sync, zone serial number incrementation is OK. Regards, Tomas From pviktori at redhat.com Mon Oct 7 14:22:28 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Oct 2013 16:22:28 +0200 Subject: [Freeipa-devel] [PATCH 0015] Add support for managing user auth types In-Reply-To: <1380142275.2046.2.camel@localhost> References: <1378353865.19352.9.camel@localhost> <522DCE8B.9040009@redhat.com> <1379533870.1629.5.camel@localhost> <52403FC4.6070807@redhat.com> <1380142275.2046.2.camel@localhost> Message-ID: <5252C3A4.3070408@redhat.com> Sorry for the delay. On 09/25/2013 10:51 PM, Nathaniel McCallum wrote: > On Mon, 2013-09-23 at 15:19 +0200, Petr Viktorin wrote: >> Great, we're getting close! >> [...] >> There's another test failure when trying to rename a manager user. I >> didn't investigate in detail why that happens. > > Does the failure happen without the patch? No. It seems the added objectclasses attribute conflicts with renaming a user who's a manager. > Is this just a standard make check? It's the standard make test; specifically: ./make-test ipatests/test_xmlrpc/test_user_plugin.py It should pass on a newly installed server, with `make` being run in advance. Make sure to have ~/.ipa/default.conf set up. -- Petr? From sbose at redhat.com Mon Oct 7 15:11:50 2013 From: sbose at redhat.com (Sumit Bose) Date: Mon, 7 Oct 2013 17:11:50 +0200 Subject: [Freeipa-devel] [PATCH] Use the right attribute with ipapwd_entry_checks for MaigcRegen Message-ID: <20131007151150.GQ10000@localhost.localdomain> Hi, this issue was found by Steeve, he tried to validate a trust manually from AD and was repeatedly ask for the admin password without any progress. It turned out that the ipaNTHash was not set through the MagicRegen mechanism and samba always returned NT_STATUS_WRONG_PASSWORD. This patch should fix it. I attached a patch for 3.0 as well because the touched file was renamed. bye, Sumit -------------- next part -------------- From 8bae65bc0afef181562b238d3a61d4d1dc7b3bde Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 7 Oct 2013 16:49:33 +0200 Subject: [PATCH] Use the right attribute with ipapwd_entry_checks for MagicRegen There is a special mode to set the ipaNTHash attribute if a RC4 Kerberos key is available for the corresponding user. This is typically triggered by samba via the ipa_sam passdb plugin. The principal used by samba to connect to the IPA directory server has the right to modify ipaNTHash but no other password attribute. This means that the current check on the userPassword attribute is too strict for this case and leads to a failure of the whole operation. With this patch the access right on ipaNTHash are checked if no other password operations are requested. --- daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 3 ++- 1 file changed, 2 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 8a222650cbd7348f419c8b697fa9b9784a66eb22..64a9d314015b47f0e224410f8f3f2460dbce57bc 100644 --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c @@ -554,7 +554,8 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb) rc = ipapwd_entry_checks(pb, e, &is_root, &is_krb, &is_smb, &is_ipant, - SLAPI_USERPWD_ATTR, SLAPI_ACL_WRITE); + is_pwd_op ? SLAPI_USERPWD_ATTR : "ipaNTHash", + SLAPI_ACL_WRITE); if (rc) { goto done; } -- 1.8.1.4 -------------- next part -------------- From 2e724b9dcdb9b98ea6d8b232074f2a5d5d34a939 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 7 Oct 2013 16:49:33 +0200 Subject: [PATCH] Use the right attribute with ipapwd_entry_checks for MagicRegen There is a special mode to set the ipaNTHash attribute if a RC4 Kerberos key is available for the corresponding user. This is typically triggered by samba via the ipa_sam passdb plugin. The principal used by samba to connect to the IPA directory server has the right to modify ipaNTHash but no other password attribute. This means that the current check on the userPassword attribute is too strict for this case and leads to a failure of the whole operation. With this patch the access right on ipaNTHash are checked if no other password operations are requested. --- daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c index e4909c94585b6fac6b7f8347b806a8841107f3d0..f5cda73ca5a433a0432538169bfbd8d75182f280 100644 --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd_prepost.c @@ -547,7 +547,8 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb) rc = ipapwd_entry_checks(pb, e, &is_root, &is_krb, &is_smb, &is_ipant, - SLAPI_USERPWD_ATTR, SLAPI_ACL_WRITE); + is_pwd_op ? SLAPI_USERPWD_ATTR : "ipaNTHash", + SLAPI_ACL_WRITE); if (rc) { goto done; } -- 1.8.1.4 From mkosek at redhat.com Mon Oct 7 15:30:43 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 07 Oct 2013 17:30:43 +0200 Subject: [Freeipa-devel] [RFE] CA certificate renewal In-Reply-To: <524E91E0.1020603@redhat.com> References: <524E91E0.1020603@redhat.com> Message-ID: <5252D3A3.7020000@redhat.com> On 10/04/2013 12:01 PM, Jan Cholasta wrote: > Hi, > > you can find a draft of the design document for this feature at > . > > Comments are welcome. > > Honza > 1) Shared certificate store Shouldn't we name the container as cn=cacerts,cn=ipa,cn=etc,suffix? It seems that current design would allow storing certificates not only for IPA CA, but also custom servers managed by IPA. 2) Distributing CA certificates to clients So /etc/ipa/ca.crt would contain multiple certificates, even the whole certificate chains? Will that fly for example when doing ldapsearch -ZZZ + have TLS_CACERT pointing to /etc/ipa/ca.crt? 3) Implementation I am not confident about the cron part. If you have 1000 client machines, asking every hour for an update, that could create a lot of traffic. Maybe some certmonger-like heuristics would be in place? Like test each week under normal circumstances, test each day when a cert in /etc/ipa/ca.crt is about to expire. I am also thinking how to randomize the cron schedule so that every client does not run the check in the same moment - to split the load. Martin From pviktori at redhat.com Mon Oct 7 16:16:41 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 07 Oct 2013 18:16:41 +0200 Subject: [Freeipa-devel] [PATCH] 0119 Switch client to JSON-RPC In-Reply-To: <520899FD.9060202@redhat.com> References: <50F53F2B.4020406@redhat.com> <511CF3D3.80107@redhat.com> <5159FE2B.306@redhat.com> <518D0A2F.6040401@redhat.com> <51FB781D.4060201@redhat.com> <520899FD.9060202@redhat.com> Message-ID: <5252DE69.9050004@redhat.com> On 08/12/2013 10:17 AM, Petr Viktorin wrote: > On 08/02/2013 11:13 AM, Petr Viktorin wrote: >> On 05/10/2013 04:54 PM, Petr Viktorin wrote: >>> On 04/01/2013 11:37 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 01/15/2013 12:36 PM, Petr Viktorin wrote: >>>>>> I meant to hold this patch a while longer to let it mature, but from >>>>>> what Brian Smith asked on the user list it seems it could help him. >>>>>> >>>>>> Design: http://freeipa.org/page/V3/JSON-RPC >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3299 >>>>>> >>>>>> See the design page for what the patch does. >>>>>> >>>>>> >>>>>> As much as I've tried to avoid them, the code includes some >>>>>> workarounds: >>>>>> It extends xmlrpclib to also support JSON. This is rather intrusive, >>>>>> but >>>>>> to not do that I'd need to write a parallel stack for JSON, without >>>>>> the >>>>>> help of a standard library. >>>>>> The registration of either jsonclient or xmlclient as "rpcclient" in >>>>>> the >>>>>> API also needs a bit of magic, since the framework requires the class >>>>>> name to match the attribute. >>>>>> >>>>>> >>>>>> To prevent backwards compatibility problems, we need to ensure that >>>>>> all >>>>>> official JSON clients send the API version, so this patch should be >>>>>> applied after my patches 0104-0106. >>>>>> >>>>> >>>>> Updating to current master. >>>> >>>> Please reverse this change in ipalib/rpc.py: >>>> >>>> @@ -665,8 +788,6 @@ class xmlclient(Connectible): >>>> except Exception, e: >>>> if not fallback: >>>> raise >>>> - else: >>>> - self.log.info('Connection to %s failed with %s', >>>> url, e) >>>> serverproxy = None >>>> >>>> This logs connection errors when the client fails over to another >>>> server. >>> >>> Thanks. Done, and rebased to master. >>> >>>> The changes look really good. The show stopper is that using jsonrpc >>>> doesn't create a session key. I noticed that xmlrpc_uri is hardcoded >>>> into ipalib/session.py but it appears the issue is deeper than that. >>> >>> That uses only the hostname from xmlrpc_uri. When using different >>> hostnames in xmlrpc_uri and jsonrpc_uri *on the server*, it'll put the >>> wrong domain in the cookie. In this case I think it's the configuration >>> that's wrong. >>> >>> The real problem is that KerberossSession code which creates the cookie, >>> was not called by the JSON server. >>> Patch 0223 adds it. >>> >>> Patch 0224 adds the server class name (e.g. [jsonserver_kerb]) to the >>> server logs. It should help debug problems specific to a >>> backend/protocol. >> >> Rebased onto current master. >> > > Another minor rebase Rebased again. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0119.6-Switch-client-to-JSON-RPC.patch Type: text/x-patch Size: 41579 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0223.6-Make-jsonserver_kerb-start-a-cookie-based-session.patch Type: text/x-patch Size: 1580 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0224.6-Add-server-protocol-type-to-rpcserver-logs.patch Type: text/x-patch Size: 2805 bytes Desc: not available URL: From jcholast at redhat.com Mon Oct 7 16:28:12 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 07 Oct 2013 18:28:12 +0200 Subject: [Freeipa-devel] [RFE] CA certificate renewal In-Reply-To: <5252D3A3.7020000@redhat.com> References: <524E91E0.1020603@redhat.com> <5252D3A3.7020000@redhat.com> Message-ID: <5252E11C.8000608@redhat.com> On 7.10.2013 17:30, Martin Kosek wrote: > On 10/04/2013 12:01 PM, Jan Cholasta wrote: >> Hi, >> >> you can find a draft of the design document for this feature at >> . >> >> Comments are welcome. >> >> Honza >> > > 1) Shared certificate store > > Shouldn't we name the container as cn=cacerts,cn=ipa,cn=etc,suffix? It seems > that current design would allow storing certificates not only for IPA CA, but > also custom servers managed by IPA. The store is basically a NSS database in LDAP, so theoretically you could store any cert in there, but IPA will understand only CA certificates (at least for now). > > > 2) Distributing CA certificates to clients > > So /etc/ipa/ca.crt would contain multiple certificates, even the whole > certificate chains? Will that fly for example when doing ldapsearch -ZZZ + have > TLS_CACERT pointing to /etc/ipa/ca.crt? libldap understands CA PEM bundles, so this will fly. > > > 3) Implementation > > I am not confident about the cron part. If you have 1000 client machines, > asking every hour for an update, that could create a lot of traffic. Maybe some > certmonger-like heuristics would be in place? Like test each week under normal > circumstances, test each day when a cert in /etc/ipa/ca.crt is about to expire. > > I am also thinking how to randomize the cron schedule so that every client does > not run the check in the same moment - to split the load. The script is run hourly for sufficiently small time granularity, but that doesn't mean it will contact the server every time it is run. Some heuristics and randomization will definitely be in place. > > Martin > Honza -- Jan Cholasta From abokovoy at redhat.com Mon Oct 7 16:29:35 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 7 Oct 2013 19:29:35 +0300 Subject: [Freeipa-devel] [PATCH] Use the right attribute with ipapwd_entry_checks for MaigcRegen In-Reply-To: <20131007151150.GQ10000@localhost.localdomain> References: <20131007151150.GQ10000@localhost.localdomain> Message-ID: <20131007162935.GB4216@redhat.com> On Mon, 07 Oct 2013, Sumit Bose wrote: >Hi, > >this issue was found by Steeve, he tried to validate a trust manually >from AD and was repeatedly ask for the admin password without any >progress. It turned out that the ipaNTHash was not set through the >MagicRegen mechanism and samba always returned NT_STATUS_WRONG_PASSWORD. > >This patch should fix it. I attached a patch for 3.0 as well because the >touched file was renamed. I remember sending fix for similar bug last winter albeit the fix was different. Your fix is correct, ACK, but I wonder what happened to my patch because I can't seem to find it... -- / Alexander Bokovoy From rcritten at redhat.com Mon Oct 7 17:16:28 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Oct 2013 13:16:28 -0400 Subject: [Freeipa-devel] [RFE] CA certificate renewal In-Reply-To: <524E91E0.1020603@redhat.com> References: <524E91E0.1020603@redhat.com> Message-ID: <5252EC6C.9030502@redhat.com> Jan Cholasta wrote: > Hi, > > you can find a draft of the design document for this feature at > . > > Comments are welcome. > > Honza > Shared certificate store. DM should not be required. It may be required initially, but we have a long-term goal of removing the need to be DM to perform operations. Note that this would only probably be practical in a single-389-ds install. Does readable by everyone include anonymous? I think it does but probably best to spell it out. Automatic renewal of IPA CA certificate. certmonger currently has no notification capabilities. How will anyone know that the renewal has failed unless they happen to run getcert list? Unfortunately I don't really have an answer. An MTA is looking more and more necessary. What certmonger CA backend will be used for renewing an external CA? Perhaps that can be used as some sort of notification via syslog? Are you sure you can change the signing chain, essentially on-the-fly? I imagine that the math will work ok but I don't know if changing the issuer is valid. I think the trust flag should include code signing by default since we sign an object cert for Firefox. It would also probably be forward-looking to go ahead and include clients as well. Distributing CA certificates to clients I think a certmonger CA-refresher backend should be done first. I echo Martin's concerns about hourly polling and the load that entails. It also doesn't cover all cases, like if you set up a web server using an IPA cert there is no way to pick up the new CA. Also, we issue a 20-year CA which means in the case where someone lets it just run through there would be 175k polls to do nothing, then one to get the new CA. That's a lot of cache misses. Implementation For the external case are you storing the original CSR anywhere? Do you know how to generate a new CSR re-using the same key (I don't)? rob From jcholast at redhat.com Mon Oct 7 18:20:26 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 07 Oct 2013 20:20:26 +0200 Subject: [Freeipa-devel] [RFE] CA certificate renewal In-Reply-To: <5252EC6C.9030502@redhat.com> References: <524E91E0.1020603@redhat.com> <5252EC6C.9030502@redhat.com> Message-ID: <5252FB6A.3090705@redhat.com> On 7.10.2013 19:16, Rob Crittenden wrote: > Jan Cholasta wrote: >> Hi, >> >> you can find a draft of the design document for this feature at >> . >> >> Comments are welcome. >> >> Honza >> > > Shared certificate store. > > DM should not be required. It may be required initially, but we have a > long-term goal of removing the need to be DM to perform operations. Note > that this would only probably be practical in a single-389-ds install. OK. Who should be allowed to update CA certificates? Should I add a new privilege for that? > > Does readable by everyone include anonymous? I think it does but > probably best to spell it out. Yes, it does. > > Automatic renewal of IPA CA certificate. > > certmonger currently has no notification capabilities. How will anyone > know that the renewal has failed unless they happen to run getcert list? > Unfortunately I don't really have an answer. An MTA is looking more and > more necessary. I agree. > > What certmonger CA backend will be used for renewing an external CA? > Perhaps that can be used as some sort of notification via syslog? New one I created for this purpose. It already syslogs the message with LOG_ERR level - a higher level would be better for this, right? > > Are you sure you can change the signing chain, essentially on-the-fly? I > imagine that the math will work ok but I don't know if changing the > issuer is valid. It seems to work, as long as CS.cfg is update accordingly (hierarchy.select and subsystem.count are different for self-signed and signed by external CA). > > I think the trust flag should include code signing by default since we > sign an object cert for Firefox. It would also probably be > forward-looking to go ahead and include clients as well. The trust flags are CT,C,C by default for the CA certificate issued by Dogtag. In CA-less installs, the object signing cert for Firefox is not created. > > Distributing CA certificates to clients > > I think a certmonger CA-refresher backend should be done first. I echo > Martin's concerns about hourly polling and the load that entails. It > also doesn't cover all cases, like if you set up a web server using an > IPA cert there is no way to pick up the new CA. Yes, it should, but I can't imagine how I could make it in time for 3.4. There's just not enough time, hence the cron-based solution. > > Also, we issue a 20-year CA which means in the case where someone lets > it just run through there would be 175k polls to do nothing, then one to > get the new CA. That's a lot of cache misses. The script is run hourly, but it will not poll the server every time. > > Implementation > > For the external case are you storing the original CSR anywhere? Do you > know how to generate a new CSR re-using the same key (I don't)? Certmonger supplies the CSR to the CA helper in an environment variable, I export it from there. > > rob Thanks for the review! Honza -- Jan Cholasta From nalin at redhat.com Mon Oct 7 19:53:48 2013 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 7 Oct 2013 15:53:48 -0400 Subject: [Freeipa-devel] Handling of multiple krbPrincipalNames and of krbCanonicalNames Message-ID: <20131007195348.GA20708@redhat.com> Comparing master's ipa-kdb's handling of krbPrincipalName and krbCanonicalName attributes with that of the upstream kldap driver, there are a few differences which I'm thinking are bugs. * If an entry has multiple krbPrincipalName values, the name which was used to look it up is required to match only the last value of the attribute that we read, not any of them. * If an entry has a krbCanonicalName value, and the name which we used to look it up doesn't match it, if database aliases are allowed, we return an error instead of using it to populate the returned entry. I'm attaching patches for both of these, though the second still doesn't quite match the behavior of kldap.so, in that we don't preserve the requested name if it differs from the canonical name only in case. I don't know that it matters, but I'm mentioning here just in case. Cheers, Nalin -------------- next part -------------- >From d4330cd204757bdbbcb50164d03fedf864d6b736 Mon Sep 17 00:00:00 2001 From: Nalin Dahyabhai Date: Mon, 7 Oct 2013 15:24:29 -0400 Subject: [PATCH 1/4] Accept any alias, not just the last value If the entry's krbPrincipalName attribute is multi-valued, accept any of the values, not just the last one we happen to examine. --- daemons/ipa-kdb/ipa_kdb_principals.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c index 38059d2..d3b2820 100644 --- a/daemons/ipa-kdb/ipa_kdb_principals.c +++ b/daemons/ipa-kdb/ipa_kdb_principals.c @@ -653,6 +653,9 @@ static krb5_error_code ipadb_find_principal(krb5_context kcontext, } else { found = (strcmp(vals[i]->bv_val, (*principal)) == 0); } + if (found) { + break; + } } ldap_value_free_len(vals); -- 1.8.3.1 -------------- next part -------------- >From 59c38ecfe3786c72b7fea9aeba2118f1d07f3235 Mon Sep 17 00:00:00 2001 From: Nalin Dahyabhai Date: Mon, 7 Oct 2013 15:26:21 -0400 Subject: [PATCH 2/4] Restore krbCanonicalName handling When an entry has a krbCanonicalName, if KRB5_KDB_FLAG_ALIAS_OK is set, rewrite the principal name to the canonical value, else error out, instead of always returning an error if the requested name doesn't look like the canonical one. --- daemons/ipa-kdb/ipa_kdb_principals.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_principals.c b/daemons/ipa-kdb/ipa_kdb_principals.c index d3b2820..766aa92 100644 --- a/daemons/ipa-kdb/ipa_kdb_principals.c +++ b/daemons/ipa-kdb/ipa_kdb_principals.c @@ -672,11 +672,7 @@ static krb5_error_code ipadb_find_principal(krb5_context kcontext, /* Again, if aliases are accepted by KDC, use case-insensitive comparison */ if ((flags & KRB5_KDB_FLAG_ALIAS_OK) != 0) { - if (ulc_casecmp(vals[0]->bv_val, vals[0]->bv_len, - (*principal), strlen(*principal), - NULL, NULL, &result) != 0) - return KRB5_KDB_INTERNAL_ERROR; - found = (result == 0); + found = true; } else { found = (strcmp(vals[0]->bv_val, (*principal)) == 0); } -- 1.8.3.1 From jfenal at gmail.com Mon Oct 7 20:43:05 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Mon, 7 Oct 2013 22:43:05 +0200 Subject: [Freeipa-devel] [DOC] what was the meaning? Message-ID: Hi all, Found in SelinuxMap.xml: As with adding a user to a ion> value identifies the host-based access control rule to use for mapping. The access control rule must specify both users and hosts appropriately so that the SELinux map can construct the SELinux user, &IPA; user, and host triple. What was "ion>" supposed to be? Regards, J. -- J?r?me Fenal From npmccallum at redhat.com Mon Oct 7 21:28:08 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 07 Oct 2013 17:28:08 -0400 Subject: [Freeipa-devel] [PATCH 0020] Add IntEnum parameter to ipalib In-Reply-To: <52529992.6050805@redhat.com> References: <1380907984.1760.1.camel@localhost> <52529992.6050805@redhat.com> Message-ID: <1381181288.1760.30.camel@localhost> On Mon, 2013-10-07 at 13:22 +0200, Petr Viktorin wrote: > On 10/04/2013 07:33 PM, Nathaniel McCallum wrote: > > This patch is preparatory for the OTP CLI patch. > > > > + def _convert_scalar(self, value, index=None): > > + return Int._convert_scalar(self, value, index=index) > > That won't work. In Python 2 unbound methods (such as > Int._validate_scalar) must be passed the correct type as self; passing > an IntEnum instance like this will raise a TypeError. > > You'll need to either use multiple inheritance (if you feel the > framework isn't complex enough), or make a convert_int function, and > then in both Int and IntEnum just call it and handle ValueError. > > For validate_scalar it would probably be best to extend > Param._validate_scalar to allow the class to define extra allowed types, > and get rid of the reimplementation in Int. Fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0020-2-Add-IntEnum-parameter-to-ipalib.patch Type: text/x-patch Size: 10717 bytes Desc: not available URL: From npmccallum at redhat.com Mon Oct 7 21:28:45 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 07 Oct 2013 17:28:45 -0400 Subject: [Freeipa-devel] [PATCH 0021] Don't special case the Password class in Param.__init__() In-Reply-To: <52529F3C.8060309@redhat.com> References: <1380908094.1760.3.camel@localhost> <52529F3C.8060309@redhat.com> Message-ID: <1381181325.1760.31.camel@localhost> On Mon, 2013-10-07 at 13:47 +0200, Petr Viktorin wrote: > On 10/04/2013 07:34 PM, Nathaniel McCallum wrote: > > This patch is preparatory for the OTP CLI patch. > > Thanks for the patch; it needs some work. > > >>From 2678ff4e2f22e7e81bf40b30ffcd0efe0ecf08c2 Mon Sep 17 00:00:00 2001 > > From: Nathaniel McCallum > > Date: Mon, 30 Sep 2013 13:06:37 -0400 > > Subject: [PATCH] Don't special case the Password class in Param.__init__() > > > > --- > > ipalib/parameters.py | 20 ++++++++++---------- > > 1 file changed, 10 insertions(+), 10 deletions(-) > > > > diff --git a/ipalib/parameters.py b/ipalib/parameters.py > > index fbcb87537ba662763a00e12178d424a8718baa8a..925f442968ab93b2b6df4e386d03558300bf5990 100644 > > --- a/ipalib/parameters.py > > +++ b/ipalib/parameters.py > > @@ -398,11 +398,11 @@ class Param(ReadOnly): > > # We keep these values to use in __repr__(): > > self.param_spec = name > > self.__kw = dict(kw) > > - > > - if isinstance(self, Password): > > - self.password = True > > - else: > > + > > + try: > > self.password = False > > + except AttributeError: > > + pass > > > Setting the attribute here will always pass, and always re-set > `password` to False, even for Password instances. > > A class-level attribute (both in Param and Password) would work better here: > > class Param(ReadOnly): > ... > password = False > ... > > class Password(Str): > ... > password = True > ... > > > You can run a part of the test suite to verify changes in ipalib > (test_ipalib happens to not need an installed server): > ./make-test ipatests/test_ipalib > or just for parameters: > ./make-test ipatests/test_ipalib/test_parameters.py > > > BTW, Git complains trailing whitespace. I found the following Git > setting useful to spot this before `git am`: > $ git config color.diff.whitespace 'red reverse' Fixed. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0021-2-Don-t-special-case-the-Password-class-in-Param.__ini.patch Type: text/x-patch Size: 2210 bytes Desc: not available URL: From npmccallum at redhat.com Mon Oct 7 21:30:57 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 07 Oct 2013 17:30:57 -0400 Subject: [Freeipa-devel] [PATCH 0023] Add optional_create flag In-Reply-To: <5252A85E.5060906@redhat.com> References: <1380908271.1760.7.camel@localhost> <1380916902.1760.9.camel@localhost> <5252A85E.5060906@redhat.com> Message-ID: <1381181457.1760.33.camel@localhost> On Mon, 2013-10-07 at 14:26 +0200, Petr Viktorin wrote: > On 10/04/2013 10:01 PM, Nathaniel McCallum wrote: > > On Fri, 2013-10-04 at 13:37 -0400, Nathaniel McCallum wrote: > >> This patch is preparatory for the OTP CLI patch. > > > > I'm not quite sure why, but this patch apparently changes the output > > of ./makeapi. This change is now included in the attached patch. Is this > > a mistake of some sort? Or is this just correct? > > > > Nathaniel > > Apparently, Param.clone() uses all options, even those that are left out > of what API.txt reports (see __kw and __clonekw in Param.__init__). IMO > it's not ideal behavior, makeapi should have used __clonekw directly. > > > Anyway, to keep API.txt as before, only clone if necessary: > > def __clone(self, param, **kw): > if 'optional_create' in param.flags: > kw['required'] = False > - return param.clone(**kw) > + if kw: > + return param.clone(**kw) > + else: > + return param Fixed. This patch does still cause an error in the tests because param is a string. Is this a bug in the test? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0023-2-Add-optional_create-flag.patch Type: text/x-patch Size: 2665 bytes Desc: not available URL: From npmccallum at redhat.com Mon Oct 7 21:34:48 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Mon, 07 Oct 2013 17:34:48 -0400 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <1380917810.1760.23.camel@localhost> References: <1380917810.1760.23.camel@localhost> Message-ID: <1381181688.1760.36.camel@localhost> On Fri, 2013-10-04 at 16:16 -0400, Nathaniel McCallum wrote: > This patch supersedes my patch 0017 and requires patches 0020-0023. I > believe I have solved all of the outstanding issues from the review of > patch 0017, unless otherwise noted: > > 1. I'm not actually sure what the format of the date parameters is. > Could someone clarify this for me? Should I do something differently > here? > > 2. In this new version of the patch, we are writing default values for > many of the token attributes. It would be nice to have some global > defaults for these default values, but this is not currently > implemented. I think this would make a clean secondary patch on top of > this current patch. > > 3. Dmitri brought up the idea of having tokens automatically expire by > default. Is this a good idea? I think this dovetails nicely with #2 > above. > > 4. This patch does not currently protect the deletion of the last token > as previously discussed. Here is why I think this is still needed, but > in the form of a DS plugin: > > We need to account for a state when the user is enabled for OTP but has > not yet configured any tokens. I believe this state should be when the > "otp" user auth type is set, but the user has no assigned tokens. In > this state, the user should be able to log in with single factor > authentication. > > Once the user has added tokens, however, should we allow the user to > remove all his own tokens and return to single factor authentication? If > yes, nothing further is needed. If no, then protection in the FreeIPA > framework is not sufficient and this needs to be checked at the DS > plugin level. I suspect Dmitri might answer that this needs to be a > matter of policy. > > 5. There appears to be some sort of permissions issue with users and > adding their own tokens. I have not looked into this yet, but I will > review this early next week. Since this is a small bug fix to an > existing feature, I figured it was out of scope for this patch. > > 6. When a user is deleted, all his tokens are deleted as well. This is > sensible default behavior. However, in the case of hardware tokens, it > may be more desirable to orphan these objects for future assignment to > new users. Does anyone have any opinions on this topic? > > Nathaniel v2. Fixes API.txt and OTPTokenKey issues caused by bugs in previous patches. Whitespace cleanup. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0024-2-Add-OTP-support-to-ipalib-CLI.patch Type: text/x-patch Size: 29364 bytes Desc: not available URL: From pspacek at redhat.com Tue Oct 8 06:37:28 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 08 Oct 2013 08:37:28 +0200 Subject: [Freeipa-devel] [RFE] CA certificate renewal In-Reply-To: <5252FB6A.3090705@redhat.com> References: <524E91E0.1020603@redhat.com> <5252EC6C.9030502@redhat.com> <5252FB6A.3090705@redhat.com> Message-ID: <5253A828.2050005@redhat.com> On 7.10.2013 20:20, Jan Cholasta wrote: >> Automatic renewal of IPA CA certificate. >> >> certmonger currently has no notification capabilities. How will anyone >> know that the renewal has failed unless they happen to run getcert list? >> Unfortunately I don't really have an answer. An MTA is looking more and >> more necessary. > > I agree. Please, don't invent yet another notification system. Don't try to re-invent wheel :-) There are plenty systems for that, we should just provide hooks for them (i.e. ability to run custom script on particular event and provide machine-readable output from our tools). I don't want to repeat all the arguments again, so there is a link: https://www.redhat.com/archives/freeipa-devel/2013-September/msg00071.html (See the end of the page - the part below all quotations.) -- Petr^2 Spacek From jcholast at redhat.com Tue Oct 8 07:16:35 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 08 Oct 2013 09:16:35 +0200 Subject: [Freeipa-devel] [RFE] CA certificate renewal In-Reply-To: <5253A828.2050005@redhat.com> References: <524E91E0.1020603@redhat.com> <5252EC6C.9030502@redhat.com> <5252FB6A.3090705@redhat.com> <5253A828.2050005@redhat.com> Message-ID: <5253B153.7080601@redhat.com> On 8.10.2013 08:37, Petr Spacek wrote: > On 7.10.2013 20:20, Jan Cholasta wrote: >>> Automatic renewal of IPA CA certificate. >>> >>> certmonger currently has no notification capabilities. How will anyone >>> know that the renewal has failed unless they happen to run getcert list? >>> Unfortunately I don't really have an answer. An MTA is looking more and >>> more necessary. >> >> I agree. > > Please, don't invent yet another notification system. Don't try to > re-invent wheel :-) > > There are plenty systems for that, we should just provide hooks for them > (i.e. ability to run custom script on particular event and provide > machine-readable output from our tools). > > I don't want to repeat all the arguments again, so there is a link: > https://www.redhat.com/archives/freeipa-devel/2013-September/msg00071.html > (See the end of the page - the part below all quotations.) > OK, I don't care how this is done. Is syslogging with crit or alert severity good enough? Honza -- Jan Cholasta From jcholast at redhat.com Tue Oct 8 07:19:46 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 08 Oct 2013 09:19:46 +0200 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <1381181688.1760.36.camel@localhost> References: <1380917810.1760.23.camel@localhost> <1381181688.1760.36.camel@localhost> Message-ID: <5253B212.6000403@redhat.com> On 7.10.2013 23:34, Nathaniel McCallum wrote: > On Fri, 2013-10-04 at 16:16 -0400, Nathaniel McCallum wrote: >> This patch supersedes my patch 0017 and requires patches 0020-0023. I >> believe I have solved all of the outstanding issues from the review of >> patch 0017, unless otherwise noted: >> >> 1. I'm not actually sure what the format of the date parameters is. >> Could someone clarify this for me? Should I do something differently >> here? >> >> 2. In this new version of the patch, we are writing default values for >> many of the token attributes. It would be nice to have some global >> defaults for these default values, but this is not currently >> implemented. I think this would make a clean secondary patch on top of >> this current patch. >> >> 3. Dmitri brought up the idea of having tokens automatically expire by >> default. Is this a good idea? I think this dovetails nicely with #2 >> above. >> >> 4. This patch does not currently protect the deletion of the last token >> as previously discussed. Here is why I think this is still needed, but >> in the form of a DS plugin: >> >> We need to account for a state when the user is enabled for OTP but has >> not yet configured any tokens. I believe this state should be when the >> "otp" user auth type is set, but the user has no assigned tokens. In >> this state, the user should be able to log in with single factor >> authentication. >> >> Once the user has added tokens, however, should we allow the user to >> remove all his own tokens and return to single factor authentication? If >> yes, nothing further is needed. If no, then protection in the FreeIPA >> framework is not sufficient and this needs to be checked at the DS >> plugin level. I suspect Dmitri might answer that this needs to be a >> matter of policy. >> >> 5. There appears to be some sort of permissions issue with users and >> adding their own tokens. I have not looked into this yet, but I will >> review this early next week. Since this is a small bug fix to an >> existing feature, I figured it was out of scope for this patch. >> >> 6. When a user is deleted, all his tokens are deleted as well. This is >> sensible default behavior. However, in the case of hardware tokens, it >> may be more desirable to orphan these objects for future assignment to >> new users. Does anyone have any opinions on this topic? >> >> Nathaniel > > v2. Fixes API.txt and OTPTokenKey issues caused by bugs in previous > patches. Whitespace cleanup. > +class Base32DecodeError(ExecutionError): Is this really necessary? Are we going to add DecodeError for every kind of new encoding in IPA? Can't we just have generic DecodeError? (This is not an issue in your patch per se, I'm just wondering if we can do it better in the framework.) Honza -- Jan Cholasta From mkosek at redhat.com Tue Oct 8 07:20:08 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 08 Oct 2013 09:20:08 +0200 Subject: [Freeipa-devel] [PATCH] Use the right attribute with ipapwd_entry_checks for MaigcRegen In-Reply-To: <20131007162935.GB4216@redhat.com> References: <20131007151150.GQ10000@localhost.localdomain> <20131007162935.GB4216@redhat.com> Message-ID: <5253B228.9060306@redhat.com> On 10/07/2013 06:29 PM, Alexander Bokovoy wrote: > On Mon, 07 Oct 2013, Sumit Bose wrote: >> Hi, >> >> this issue was found by Steeve, he tried to validate a trust manually >> from AD and was repeatedly ask for the admin password without any >> progress. It turned out that the ipaNTHash was not set through the >> MagicRegen mechanism and samba always returned NT_STATUS_WRONG_PASSWORD. >> >> This patch should fix it. I attached a patch for 3.0 as well because the >> touched file was renamed. > I remember sending fix for similar bug last winter albeit the fix was > different. Your fix is correct, ACK, but I wonder what happened to my > patch because I can't seem to find it... Pushed to master, ipa-3-3. There was no request to have this patch in 3.0/3.1/3.2 branches, but it is good to have it in the archive in case such request emerges. Martin From pspacek at redhat.com Tue Oct 8 07:21:10 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 08 Oct 2013 09:21:10 +0200 Subject: [Freeipa-devel] [RFE] CA certificate renewal In-Reply-To: <5253B153.7080601@redhat.com> References: <524E91E0.1020603@redhat.com> <5252EC6C.9030502@redhat.com> <5252FB6A.3090705@redhat.com> <5253A828.2050005@redhat.com> <5253B153.7080601@redhat.com> Message-ID: <5253B266.8000609@redhat.com> On 8.10.2013 09:16, Jan Cholasta wrote: > On 8.10.2013 08:37, Petr Spacek wrote: >> On 7.10.2013 20:20, Jan Cholasta wrote: >>>> Automatic renewal of IPA CA certificate. >>>> >>>> certmonger currently has no notification capabilities. How will anyone >>>> know that the renewal has failed unless they happen to run getcert list? >>>> Unfortunately I don't really have an answer. An MTA is looking more and >>>> more necessary. >>> >>> I agree. >> >> Please, don't invent yet another notification system. Don't try to >> re-invent wheel :-) >> >> There are plenty systems for that, we should just provide hooks for them >> (i.e. ability to run custom script on particular event and provide >> machine-readable output from our tools). >> >> I don't want to repeat all the arguments again, so there is a link: >> https://www.redhat.com/archives/freeipa-devel/2013-September/msg00071.html >> (See the end of the page - the part below all quotations.) >> > > OK, I don't care how this is done. Is syslogging with crit or alert severity > good enough? For me - yes, it is. However, it would be great if there will be a 'status check tool' (or parameter) with machine readable output. -- Petr^2 Spacek From mkosek at redhat.com Tue Oct 8 07:31:59 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 08 Oct 2013 09:31:59 +0200 Subject: [Freeipa-devel] [DOC] what was the meaning? In-Reply-To: References: Message-ID: <5253B4EF.3020805@redhat.com> On 10/07/2013 10:43 PM, J?r?me Fenal wrote: > Hi all, > > Found in SelinuxMap.xml: > > As with adding a user to a ion> value identifies > the host-based access control rule to use for mapping. The access > control rule must specify both users and hosts appropriately so that > the SELinux map can construct the SELinux user, &IPA; user, and host > triple. > > What was "ion>" supposed to be? > > Regards, > > J. > I see this was wrong even in the original version of the paragraph. The first sentence is actually pretty cryptic. I would rather replace the whole paragraph with """ A specific user or host can be removed from an SELinux map by using either the selinuxusermap-remove-host or selinuxusermap-remove-user command. """ which is now above it. Ccing Petr and Martin to check that. Martin From jhrozek at redhat.com Tue Oct 8 07:56:24 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 8 Oct 2013 09:56:24 +0200 Subject: [Freeipa-devel] [RFE] CA certificate renewal In-Reply-To: <5253B266.8000609@redhat.com> References: <524E91E0.1020603@redhat.com> <5252EC6C.9030502@redhat.com> <5252FB6A.3090705@redhat.com> <5253A828.2050005@redhat.com> <5253B153.7080601@redhat.com> <5253B266.8000609@redhat.com> Message-ID: <20131008075624.GA29221@hendrix.redhat.com> On Tue, Oct 08, 2013 at 09:21:10AM +0200, Petr Spacek wrote: > On 8.10.2013 09:16, Jan Cholasta wrote: > >On 8.10.2013 08:37, Petr Spacek wrote: > >>On 7.10.2013 20:20, Jan Cholasta wrote: > >>>>Automatic renewal of IPA CA certificate. > >>>> > >>>>certmonger currently has no notification capabilities. How will anyone > >>>>know that the renewal has failed unless they happen to run getcert list? > >>>>Unfortunately I don't really have an answer. An MTA is looking more and > >>>>more necessary. > >>> > >>>I agree. > >> > >>Please, don't invent yet another notification system. Don't try to > >>re-invent wheel :-) > >> > >>There are plenty systems for that, we should just provide hooks for them > >>(i.e. ability to run custom script on particular event and provide > >>machine-readable output from our tools). > >> > >>I don't want to repeat all the arguments again, so there is a link: > >>https://www.redhat.com/archives/freeipa-devel/2013-September/msg00071.html > >>(See the end of the page - the part below all quotations.) > >> > > > >OK, I don't care how this is done. Is syslogging with crit or alert severity > >good enough? > > For me - yes, it is. However, it would be great if there will be a > 'status check tool' (or parameter) with machine readable output. I haven't read the whole discussion deeply so I might not have context, but when thinking about logging, I think you should consider journald. Journald is great at providing machine readable output (journalctl -b -o json for instance) as well as having the ability to provide custom fields to be queried later. From thozza at redhat.com Tue Oct 8 10:00:00 2013 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 08 Oct 2013 12:00:00 +0200 Subject: [Freeipa-devel] [PATCH 0186-0191] Replace LDAP cache with RBTDB In-Reply-To: <524BFBFD.1000901@redhat.com> References: <51FA694C.1000302@redhat.com> <520B9373.1070707@redhat.com> <520B9755.70503@redhat.com> <523313C3.8070306@redhat.com> <524BFBFD.1000901@redhat.com> Message-ID: <5253D7A0.2020108@redhat.com> On 10/02/2013 12:57 PM, Petr Spacek wrote: > On 13.9.2013 15:31, Petr Spacek wrote: >> On 14.8.2013 16:42, Petr Spacek wrote: >>> On 14.8.2013 16:25, Petr Spacek wrote: >>>> On 1.8.2013 15:57, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> attached monster patches replace our internal cache/database with >>>>> RBTDB >>>>> implementation. See commit messages and comments inside. >>>>> >>>>> This patch set provides very basic functionality (including DNS >>>>> support for >>>>> updates). Error handling definitely needs more love, but it should >>>>> be enough >>>>> for rapid DNSSEC prototyping. >>>> >>>> Patch 186 v2: The code now applies incremental changes in LDAP to the >>>> in-memory database. Commit message was modified to mention that >>>> wildcards are >>>> now supported. >>>> >>>> Patch 187 v2: The code was re-worked and now it respects >>>> serial_autoincrement >>>> option. >>>> >>>> Patch 188 v2: Minor comment clean-up and rebase on top of patch 187 v2. >>>> >>>> Patch 189 v2: Call to deleterdataset() nested in substractrdataset() >>>> was >>>> deleted. This code was meant only for testing purposes. >>>> >>>> These patch set is now ready for review. Please see commit messages! >>>> Some >>>> functionality is missing intentionally, but it will be fixed by >>>> separate >>>> patches. >>> >>> It would be too easy! >>> >>> Patch 186 v3: Commit message was extended with information that LDAP >>> MODRDN >>> operation is not supported at the moment. >>> >>> Patch 187 v3: Missing file ldap_driver.h was added. >> >> This extended patch set handles correctly object deletion from LDAP. >> >> Patches 186-189 contain very minor changes, only moving code from one >> place to >> the other. >> >> See commit messages for patches 190 and 191. >> >> This should be testable. I would recommend to test the whole patch set at >> once, most probably it doesn't make much sense to test patches >> separately. > > bind-dyndb-ldap-pspacek-0186-5-Use-RBTDB-instead-of-internal-LDAP-cache.patch > adds missing missing include (db.h) to zone_register.c. > ACK. Patches 186-191 tested. Adding/removing/modifying records works fine. Also PTR synchronization works. Zone transfer to slave and NOTIFY tested when changes occurred on master. Regards, Tomas From mbasti at redhat.com Tue Oct 8 14:13:28 2013 From: mbasti at redhat.com (Martin Basti) Date: Tue, 08 Oct 2013 16:13:28 +0200 Subject: [Freeipa-devel] [PATCH][DOC] 0009 Chapter 7 update Message-ID: <1381241608.2310.1.camel@unused-4-145.brq.redhat.com> Patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0009-Chapter-7-update.patch Type: text/x-patch Size: 390993 bytes Desc: not available URL: From pviktori at redhat.com Tue Oct 8 14:15:16 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Oct 2013 16:15:16 +0200 Subject: [Freeipa-devel] [PATCH 0021] Don't special case the Password class in Param.__init__() In-Reply-To: <1381181325.1760.31.camel@localhost> References: <1380908094.1760.3.camel@localhost> <52529F3C.8060309@redhat.com> <1381181325.1760.31.camel@localhost> Message-ID: <52541374.2070301@redhat.com> On 10/07/2013 11:28 PM, Nathaniel McCallum wrote: > On Mon, 2013-10-07 at 13:47 +0200, Petr Viktorin wrote: >> On 10/04/2013 07:34 PM, Nathaniel McCallum wrote: >>> This patch is preparatory for the OTP CLI patch. >> >> Thanks for the patch; it needs some work. >> >>> >From 2678ff4e2f22e7e81bf40b30ffcd0efe0ecf08c2 Mon Sep 17 00:00:00 2001 >>> From: Nathaniel McCallum >>> Date: Mon, 30 Sep 2013 13:06:37 -0400 >>> Subject: [PATCH] Don't special case the Password class in Param.__init__() >>> >>> --- >>> ipalib/parameters.py | 20 ++++++++++---------- >>> 1 file changed, 10 insertions(+), 10 deletions(-) >>> >>> diff --git a/ipalib/parameters.py b/ipalib/parameters.py >>> index fbcb87537ba662763a00e12178d424a8718baa8a..925f442968ab93b2b6df4e386d03558300bf5990 100644 >>> --- a/ipalib/parameters.py >>> +++ b/ipalib/parameters.py >>> @@ -398,11 +398,11 @@ class Param(ReadOnly): >>> # We keep these values to use in __repr__(): >>> self.param_spec = name >>> self.__kw = dict(kw) >>> - >>> - if isinstance(self, Password): >>> - self.password = True >>> - else: >>> + >>> + try: >>> self.password = False >>> + except AttributeError: >>> + pass >> >> >> Setting the attribute here will always pass, and always re-set >> `password` to False, even for Password instances. >> >> A class-level attribute (both in Param and Password) would work better here: >> >> class Param(ReadOnly): >> ... >> password = False >> ... >> >> class Password(Str): >> ... >> password = True >> ... >> >> >> You can run a part of the test suite to verify changes in ipalib >> (test_ipalib happens to not need an installed server): >> ./make-test ipatests/test_ipalib >> or just for parameters: >> ./make-test ipatests/test_ipalib/test_parameters.py >> >> >> BTW, Git complains trailing whitespace. I found the following Git >> setting useful to spot this before `git am`: >> $ git config color.diff.whitespace 'red reverse' > > Fixed. > Thanks, ACK, pushed to master: fd63505f6d02e5ef4630df49054d3b11fffcf54f -- Petr? From mkosek at redhat.com Tue Oct 8 14:24:10 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 08 Oct 2013 16:24:10 +0200 Subject: [Freeipa-devel] Handling of multiple krbPrincipalNames and of krbCanonicalNames In-Reply-To: <20131007195348.GA20708@redhat.com> References: <20131007195348.GA20708@redhat.com> Message-ID: <5254158A.7040405@redhat.com> On 10/07/2013 09:53 PM, Nalin Dahyabhai wrote: > Comparing master's ipa-kdb's handling of krbPrincipalName and > krbCanonicalName attributes with that of the upstream kldap driver, > there are a few differences which I'm thinking are bugs. > > * If an entry has multiple krbPrincipalName values, the name which > was used to look it up is required to match only the last value of the > attribute that we read, not any of them. > > * If an entry has a krbCanonicalName value, and the name which we used > to look it up doesn't match it, if database aliases are allowed, we > return an error instead of using it to populate the returned entry. > > I'm attaching patches for both of these, though the second still doesn't > quite match the behavior of kldap.so, in that we don't preserve the > requested name if it differs from the canonical name only in case. I > don't know that it matters, but I'm mentioning here just in case. > > Cheers, > > Nalin FYI, I filed upstream ticket to track this effort: https://fedorahosted.org/freeipa/ticket/3966 Martin From npmccallum at redhat.com Tue Oct 8 14:35:23 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 08 Oct 2013 10:35:23 -0400 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <5253B212.6000403@redhat.com> References: <1380917810.1760.23.camel@localhost> <1381181688.1760.36.camel@localhost> <5253B212.6000403@redhat.com> Message-ID: <1381242923.1760.38.camel@localhost> On Tue, 2013-10-08 at 09:19 +0200, Jan Cholasta wrote: > On 7.10.2013 23:34, Nathaniel McCallum wrote: > > On Fri, 2013-10-04 at 16:16 -0400, Nathaniel McCallum wrote: > >> This patch supersedes my patch 0017 and requires patches 0020-0023. I > >> believe I have solved all of the outstanding issues from the review of > >> patch 0017, unless otherwise noted: > >> > >> 1. I'm not actually sure what the format of the date parameters is. > >> Could someone clarify this for me? Should I do something differently > >> here? > >> > >> 2. In this new version of the patch, we are writing default values for > >> many of the token attributes. It would be nice to have some global > >> defaults for these default values, but this is not currently > >> implemented. I think this would make a clean secondary patch on top of > >> this current patch. > >> > >> 3. Dmitri brought up the idea of having tokens automatically expire by > >> default. Is this a good idea? I think this dovetails nicely with #2 > >> above. > >> > >> 4. This patch does not currently protect the deletion of the last token > >> as previously discussed. Here is why I think this is still needed, but > >> in the form of a DS plugin: > >> > >> We need to account for a state when the user is enabled for OTP but has > >> not yet configured any tokens. I believe this state should be when the > >> "otp" user auth type is set, but the user has no assigned tokens. In > >> this state, the user should be able to log in with single factor > >> authentication. > >> > >> Once the user has added tokens, however, should we allow the user to > >> remove all his own tokens and return to single factor authentication? If > >> yes, nothing further is needed. If no, then protection in the FreeIPA > >> framework is not sufficient and this needs to be checked at the DS > >> plugin level. I suspect Dmitri might answer that this needs to be a > >> matter of policy. > >> > >> 5. There appears to be some sort of permissions issue with users and > >> adding their own tokens. I have not looked into this yet, but I will > >> review this early next week. Since this is a small bug fix to an > >> existing feature, I figured it was out of scope for this patch. > >> > >> 6. When a user is deleted, all his tokens are deleted as well. This is > >> sensible default behavior. However, in the case of hardware tokens, it > >> may be more desirable to orphan these objects for future assignment to > >> new users. Does anyone have any opinions on this topic? > >> > >> Nathaniel > > > > v2. Fixes API.txt and OTPTokenKey issues caused by bugs in previous > > patches. Whitespace cleanup. > > > > +class Base32DecodeError(ExecutionError): > > Is this really necessary? Are we going to add DecodeError for > every kind of new encoding in IPA? Can't we just have generic > DecodeError? (This is not an issue in your patch per se, I'm just > wondering if we can do it better in the framework.) I added the new error due to the existence of a Base64DecodeError. I figured changing the existing error to be more generic would break api. Nathaniel From pviktori at redhat.com Tue Oct 8 14:49:17 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Oct 2013 16:49:17 +0200 Subject: [Freeipa-devel] [PATCH 0023] Add optional_create flag In-Reply-To: <1381181457.1760.33.camel@localhost> References: <1380908271.1760.7.camel@localhost> <1380916902.1760.9.camel@localhost> <5252A85E.5060906@redhat.com> <1381181457.1760.33.camel@localhost> Message-ID: <52541B6D.6060903@redhat.com> On 10/07/2013 11:30 PM, Nathaniel McCallum wrote: > On Mon, 2013-10-07 at 14:26 +0200, Petr Viktorin wrote: >> On 10/04/2013 10:01 PM, Nathaniel McCallum wrote: >>> On Fri, 2013-10-04 at 13:37 -0400, Nathaniel McCallum wrote: >>>> This patch is preparatory for the OTP CLI patch. >>> >>> I'm not quite sure why, but this patch apparently changes the output >>> of ./makeapi. This change is now included in the attached patch. Is this >>> a mistake of some sort? Or is this just correct? >>> >>> Nathaniel >> >> Apparently, Param.clone() uses all options, even those that are left out >> of what API.txt reports (see __kw and __clonekw in Param.__init__). IMO >> it's not ideal behavior, makeapi should have used __clonekw directly. >> >> >> Anyway, to keep API.txt as before, only clone if necessary: >> >> def __clone(self, param, **kw): >> if 'optional_create' in param.flags: >> kw['required'] = False >> - return param.clone(**kw) >> + if kw: >> + return param.clone(**kw) >> + else: >> + return param > > Fixed. > > This patch does still cause an error in the tests because param is a > string. Is this a bug in the test? Yes; I've fixed the test with the attached one-liner. ACK, pushed to master: e05dfbd8b4b4e040266ecfba579bcd64e22b342b -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0310-test_ipalib.test_crud-Don-t-use-a-string-in-takes_op.patch Type: text/x-patch Size: 1124 bytes Desc: not available URL: From pviktori at redhat.com Tue Oct 8 16:29:46 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 08 Oct 2013 18:29:46 +0200 Subject: [Freeipa-devel] [PATCH 0020] Add IntEnum parameter to ipalib In-Reply-To: <1381181288.1760.30.camel@localhost> References: <1380907984.1760.1.camel@localhost> <52529992.6050805@redhat.com> <1381181288.1760.30.camel@localhost> Message-ID: <525432FA.9040906@redhat.com> On 10/07/2013 11:28 PM, Nathaniel McCallum wrote: > On Mon, 2013-10-07 at 13:22 +0200, Petr Viktorin wrote: >> On 10/04/2013 07:33 PM, Nathaniel McCallum wrote: >>> This patch is preparatory for the OTP CLI patch. >> >> >> > + def _convert_scalar(self, value, index=None): >> > + return Int._convert_scalar(self, value, index=index) >> >> That won't work. In Python 2 unbound methods (such as >> Int._validate_scalar) must be passed the correct type as self; passing >> an IntEnum instance like this will raise a TypeError. >> >> You'll need to either use multiple inheritance (if you feel the >> framework isn't complex enough), or make a convert_int function, and >> then in both Int and IntEnum just call it and handle ValueError. >> >> For validate_scalar it would probably be best to extend >> Param._validate_scalar to allow the class to define extra allowed types, >> and get rid of the reimplementation in Int. > > Fixed. This works, but I do have some comments. I'd prefer if the framework changes and IntEnum addition were in separate patches. I find the usage of _get_types() a bit convoluted, especially when you need to get the "canonical" type. I've taken the liberty to do this with an `allowed_types` attribute, which I think is easier to use, and also doesn't break the API. Would you agree with these changes? I've added tests for IntEnum, as a combination of StrEnum and Int tests. Do they look OK? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-multiple-types-in-Param-type-validation.patch Type: text/x-patch Size: 8763 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-IntEnum-parameter-to-ipalib.patch Type: text/x-patch Size: 2004 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-tests-for-the-IntEnum-class.patch Type: text/x-patch Size: 8738 bytes Desc: not available URL: From npmccallum at redhat.com Tue Oct 8 18:37:24 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 08 Oct 2013 14:37:24 -0400 Subject: [Freeipa-devel] [PATCH 0020] Add IntEnum parameter to ipalib In-Reply-To: <525432FA.9040906@redhat.com> References: <1380907984.1760.1.camel@localhost> <52529992.6050805@redhat.com> <1381181288.1760.30.camel@localhost> <525432FA.9040906@redhat.com> Message-ID: <1381257444.1760.52.camel@localhost> On Tue, 2013-10-08 at 18:29 +0200, Petr Viktorin wrote: > On 10/07/2013 11:28 PM, Nathaniel McCallum wrote: > > On Mon, 2013-10-07 at 13:22 +0200, Petr Viktorin wrote: > >> On 10/04/2013 07:33 PM, Nathaniel McCallum wrote: > >>> This patch is preparatory for the OTP CLI patch. > >> > >> > >> > + def _convert_scalar(self, value, index=None): > >> > + return Int._convert_scalar(self, value, index=index) > >> > >> That won't work. In Python 2 unbound methods (such as > >> Int._validate_scalar) must be passed the correct type as self; passing > >> an IntEnum instance like this will raise a TypeError. > >> > >> You'll need to either use multiple inheritance (if you feel the > >> framework isn't complex enough), or make a convert_int function, and > >> then in both Int and IntEnum just call it and handle ValueError. > >> > >> For validate_scalar it would probably be best to extend > >> Param._validate_scalar to allow the class to define extra allowed types, > >> and get rid of the reimplementation in Int. > > > > Fixed. > > This works, but I do have some comments. > > I'd prefer if the framework changes and IntEnum addition were in > separate patches. > I find the usage of _get_types() a bit convoluted, especially when you > need to get the "canonical" type. I've taken the liberty to do this with > an `allowed_types` attribute, which I think is easier to use, and also > doesn't break the API. > Would you agree with these changes? > > I've added tests for IntEnum, as a combination of StrEnum and Int tests. > Do they look OK? Everything looks great except I suspect the reworking of convert_int() belongs in the second patch. Nathaniel From pviktori at redhat.com Wed Oct 9 08:23:34 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Oct 2013 10:23:34 +0200 Subject: [Freeipa-devel] [PATCH 0020] Add IntEnum parameter to ipalib In-Reply-To: <1381257444.1760.52.camel@localhost> References: <1380907984.1760.1.camel@localhost> <52529992.6050805@redhat.com> <1381181288.1760.30.camel@localhost> <525432FA.9040906@redhat.com> <1381257444.1760.52.camel@localhost> Message-ID: <52551286.6010805@redhat.com> On 10/08/2013 08:37 PM, Nathaniel McCallum wrote: > On Tue, 2013-10-08 at 18:29 +0200, Petr Viktorin wrote: >> On 10/07/2013 11:28 PM, Nathaniel McCallum wrote: >>> On Mon, 2013-10-07 at 13:22 +0200, Petr Viktorin wrote: >>>> On 10/04/2013 07:33 PM, Nathaniel McCallum wrote: >>>>> This patch is preparatory for the OTP CLI patch. >>>> >>>> >>>> > + def _convert_scalar(self, value, index=None): >>>> > + return Int._convert_scalar(self, value, index=index) >>>> >>>> That won't work. In Python 2 unbound methods (such as >>>> Int._validate_scalar) must be passed the correct type as self; passing >>>> an IntEnum instance like this will raise a TypeError. >>>> >>>> You'll need to either use multiple inheritance (if you feel the >>>> framework isn't complex enough), or make a convert_int function, and >>>> then in both Int and IntEnum just call it and handle ValueError. >>>> >>>> For validate_scalar it would probably be best to extend >>>> Param._validate_scalar to allow the class to define extra allowed types, >>>> and get rid of the reimplementation in Int. >>> >>> Fixed. >> >> This works, but I do have some comments. >> >> I'd prefer if the framework changes and IntEnum addition were in >> separate patches. >> I find the usage of _get_types() a bit convoluted, especially when you >> need to get the "canonical" type. I've taken the liberty to do this with >> an `allowed_types` attribute, which I think is easier to use, and also >> doesn't break the API. >> Would you agree with these changes? >> >> I've added tests for IntEnum, as a combination of StrEnum and Int tests. >> Do they look OK? > > Everything looks great except I suspect the reworking of convert_int() > belongs in the second patch. Makes sense, fixed. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001.2-Allow-multiple-types-in-Param-type-validation.patch Type: text/x-patch Size: 6830 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002.2-Add-IntEnum-parameter-to-ipalib.patch Type: text/x-patch Size: 3960 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003.2-Add-tests-for-the-IntEnum-class.patch Type: text/x-patch Size: 8738 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 9 11:31:11 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Oct 2013 13:31:11 +0200 Subject: [Freeipa-devel] [PATCH] 426 Winsync re-initialize should not run memberOf fixup task Message-ID: <52553E7F.5070204@redhat.com> Change re-initialize command to consider memberOf fixup task only for non-winsync replication agreements. This patch also includes few fixes for DsInstance to properly set realm and fqdn properties needed when connecting to LDAP. https://fedorahosted.org/freeipa/ticket/3854 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-426-winsync-re-initialize-should-not-run-memberof-fixup-.patch Type: text/x-patch Size: 2659 bytes Desc: not available URL: From pvoborni at redhat.com Wed Oct 9 11:36:36 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 09 Oct 2013 13:36:36 +0200 Subject: [Freeipa-devel] Less.js for RCUE adoption Message-ID: <52553FC4.3070501@redhat.com> Hi list, I've started to work on RCUE adoption [1][2][3][4][5]. RCUE uses Less CSS [6] so that means that technology for #3875 ([Web UI] Use CSS preprocessor (LESS/SASS/Stylus))[6] is pretty much chosen. Topic of this mail is to choose Less CSS implementation we will use during build. First some info. The main implementation of Less CSS is written in JavaScript as a Node.js module. There are also official builds for Rhino. Rhino versions are working up to version 1.3.3, they are broken since version 1.4. There is some upstream effort to make it work again. Implementations in different languages exist as well, but they may not implement every feature. Fedora has a Node.js package (nodejs-less[8]) and Python implementation (python-lesscpy[9]). Debian should contain these two as well. Problems might come with other targeted distributions. I tried to run less-rhino-1.3.3.js[10] in Rhino and python-lesscpy, both on RCUE reference implementation. Both tools seems to produce functionally equivalent CSS (checked by visual inspection of diff). For Fedora: - if we want to use the latest and greatest we should use Node.js package. Since Node.js reputation is not good I expect that this won't be the chosen solution. - if we want to avoid Node.js we can bundle less-rhino-1.3.3.js[10] or we can use python-lesscpy. python-lesscpy works better with Fedora packaging philosophy. For others: - bundle less-rhino if official package is not present Therefore: - bundling of less-rhino is universal solution - python-lesscpy might be better solution for Fedora Switching between implementations is easy so it's more political decision. I don't have strong option on any. Creating custom patch for each platform is a possibility as well. Last thing: we could also build and push final CSS during development. I expect we don't want to that (will be against Fedora packaging policy). [1] https://uxd-rcue.rhcloud.com/ [2] https://github.com/rhamilto/rcue [3] https://fedorahosted.org/freeipa/ticket/3902 [4] https://fedorahosted.org/freeipa/ticket/3903 [5] https://fedorahosted.org/freeipa/ticket/3904 [6] http://lesscss.org/ [7] https://fedorahosted.org/freeipa/ticket/3875 [8] http://koji.fedoraproject.org/koji/packageinfo?packageID=15909 [9] http://koji.fedoraproject.org/koji/packageinfo?packageID=16857 [10] https://github.com/less/less.js/blob/master/dist/less-rhino-1.3.3.js -- Petr Vobornik From pviktori at redhat.com Wed Oct 9 11:57:23 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Oct 2013 13:57:23 +0200 Subject: [Freeipa-devel] [PATCHES] 106-113 Access raw LDAP values directly from LDAPEntry In-Reply-To: <524426F5.6010006@redhat.com> References: <512E26E1.5010302@redhat.com> <52419527.70200@redhat.com> <524426F5.6010006@redhat.com> Message-ID: <525544A3.6080807@redhat.com> On 09/26/2013 02:22 PM, Jan Cholasta wrote: > On 24.9.2013 15:35, Jan Cholasta wrote: >> On 27.2.2013 16:31, Jan Cholasta wrote: >>> Hi, >>> >>> these patches add the ability to access and manipulate raw attribute >>> values as they are returned from python-ldap to the LDAPEntry class. >>> This is useful for comparing entries, computing modlists for the modify >>> operation, deleting values that don't match the syntax of an attribute, >>> etc., because we don't need to care what syntax does a particular >>> attribute use, or what Python type is used for it in the framework (raw >>> values are always list of str). It should also make interaction with >>> non-389 DS LDAP servers easier in the framework. >>> >>> (It might be too late for this kind of changes to get into 3.2 now, I'm >>> posting these patches mainly so that you are aware that they exist.) >>> >>> Honza >>> >> >> This is now planned for 3.4: >> >> >> I fixed some issues in these patches and refined the API. Updated >> patches attached. >> >> Also added a patch to use raw values when adding new entries and a patch >> which refines LDAPEntry.single_value, so that it is consistent with the >> rest of the changes introduced in the patches. >> >> Patch 110 will probably be dropped in favor of Petr Viktorin's schema >> update patches, but I included it anyway. >> >> Incidentally, this also fixes >> and possibly also >> . >> >> Honza >> > > Noticed a couple more issues and fixed them. Updated patches attached. > > Honza Thanks for the patches! 106. Make LDAPEntry a wrapper around dict rather than a dict subclass. ipapython/ipaldap.py:847: warning: 1 line adds whitespace errors. if isinstance(_obj, LDAPEntry): + data = dict(_obj._data) orig = _obj._orig Is this necessary? `self.update(_obj)` is done later. def __contains__(self, name): - return self._names.has_key(self._attr_name(name)) + return self._names.has_key(name) has_key() is deprecated for dict, it would make sense to prefer `name in self._names` for CIDict too. + def __eq__(self, other): + if not isinstance(other, LDAPEntry): + return NotImplemented + if self._dn != other._dn: + return False + return super(LDAPEntry, self).__eq__(other) I don't think equality checking makes sense on a LDAPEntry, where you might have different capitalizations/variants of attribute names, different _orig, or a different set of attributes loaded on the same entry. It's not obvious which of those differences should make the entries inequal. I'd just base it on identity (`self is other`). def __iter__(self): yield self._dn yield self This makes the whole thing sort of hackish -- we need to reimplement everything in MutableMapping that uses iter() internally :( Hopefully we can get rid of it soon. I'd welcome FIXME comments on whatever is reimplemented for this reason. 107. Introduce IPASimpleLDAPObject.decode method for decoding LDAP values. Can you put in a docstring? 108. Always use lists for values in LDAPEntry internally. @@ -698,6 +701,7 @@ class LDAPEntry(collections.MutableMapping): result._names = deepcopy(self._names) result._data = deepcopy(self._data) + result._not_list = deepcopy(self._not_list) if self._orig is not self: result._orig = self._orig.clone() It's better to use set() than deepcopy() for a set of strings. 109. Decode and encode attribute values in LDAPEntry on demand. The syncing looks rather over-engineered to me. Did you consider a custom MutableSequence for the values? I think it would be much cleaner in the end than merging two sets of changes together. I think it would also help (in the future?) to make the value lists more set-like, since the order doesn't matter. -- Petr? From dpal at redhat.com Wed Oct 9 13:43:58 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 09 Oct 2013 09:43:58 -0400 Subject: [Freeipa-devel] [RFE] CA certificate renewal In-Reply-To: <20131008075624.GA29221@hendrix.redhat.com> References: <524E91E0.1020603@redhat.com> <5252EC6C.9030502@redhat.com> <5252FB6A.3090705@redhat.com> <5253A828.2050005@redhat.com> <5253B153.7080601@redhat.com> <5253B266.8000609@redhat.com> <20131008075624.GA29221@hendrix.redhat.com> Message-ID: <52555D9E.2010203@redhat.com> On 10/08/2013 03:56 AM, Jakub Hrozek wrote: > On Tue, Oct 08, 2013 at 09:21:10AM +0200, Petr Spacek wrote: >> On 8.10.2013 09:16, Jan Cholasta wrote: >>> On 8.10.2013 08:37, Petr Spacek wrote: >>>> On 7.10.2013 20:20, Jan Cholasta wrote: >>>>>> Automatic renewal of IPA CA certificate. >>>>>> >>>>>> certmonger currently has no notification capabilities. How will anyone >>>>>> know that the renewal has failed unless they happen to run getcert list? >>>>>> Unfortunately I don't really have an answer. An MTA is looking more and >>>>>> more necessary. >>>>> I agree. >>>> Please, don't invent yet another notification system. Don't try to >>>> re-invent wheel :-) >>>> >>>> There are plenty systems for that, we should just provide hooks for them >>>> (i.e. ability to run custom script on particular event and provide >>>> machine-readable output from our tools). >>>> >>>> I don't want to repeat all the arguments again, so there is a link: >>>> https://www.redhat.com/archives/freeipa-devel/2013-September/msg00071.html >>>> (See the end of the page - the part below all quotations.) >>>> >>> OK, I don't care how this is done. Is syslogging with crit or alert severity >>> good enough? >> For me - yes, it is. However, it would be great if there will be a >> 'status check tool' (or parameter) with machine readable output. > I haven't read the whole discussion deeply so I might not have context, > but when thinking about logging, I think you should consider journald. > > Journald is great at providing machine readable output (journalctl -b -o > json for instance) as well as having the ability to provide custom > fields to be queried later. I would second that. > > _______________________________________________ > 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 dpal at redhat.com Wed Oct 9 13:55:52 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 09 Oct 2013 09:55:52 -0400 Subject: [Freeipa-devel] Less.js for RCUE adoption In-Reply-To: <52553FC4.3070501@redhat.com> References: <52553FC4.3070501@redhat.com> Message-ID: <52556068.2080807@redhat.com> On 10/09/2013 07:36 AM, Petr Vobornik wrote: > Hi list, > > I've started to work on RCUE adoption [1][2][3][4][5]. > > RCUE uses Less CSS [6] so that means that technology for #3875 ([Web > UI] Use CSS preprocessor (LESS/SASS/Stylus))[6] is pretty much chosen. > > Topic of this mail is to choose Less CSS implementation we will use > during build. > > First some info. The main implementation of Less CSS is written in > JavaScript as a Node.js module. There are also official builds for > Rhino. Rhino versions are working up to version 1.3.3, they are broken > since version 1.4. There is some upstream effort to make it work > again. Implementations in different languages exist as well, but they > may not implement every feature. > > Fedora has a Node.js package (nodejs-less[8]) and Python > implementation (python-lesscpy[9]). Debian should contain these two as > well. Problems might come with other targeted distributions. > > I tried to run less-rhino-1.3.3.js[10] in Rhino and python-lesscpy, > both on RCUE reference implementation. Both tools seems to produce > functionally equivalent CSS (checked by visual inspection of diff). > > For Fedora: > - if we want to use the latest and greatest we should use Node.js > package. Since Node.js reputation is not good I expect that this won't > be the chosen solution. > - if we want to avoid Node.js we can bundle less-rhino-1.3.3.js[10] or > we can use python-lesscpy. python-lesscpy works better with Fedora > packaging philosophy. > > For others: > - bundle less-rhino if official package is not present > > Therefore: > - bundling of less-rhino is universal solution > - python-lesscpy might be better solution for Fedora Why it is better? Because we do not bundle code but rather rely on the external package? This always makes sense especially for the security project like us. So if Debian has python-lesscpy package I would use it. Otherwise we would have to use less-rhino. > > Switching between implementations is easy so it's more political > decision. I don't have strong option on any. Creating custom patch for > each platform is a possibility as well. > > Last thing: we could also build and push final CSS during development. > I expect we don't want to that (will be against Fedora packaging policy). > > [1] https://uxd-rcue.rhcloud.com/ > [2] https://github.com/rhamilto/rcue > [3] https://fedorahosted.org/freeipa/ticket/3902 > [4] https://fedorahosted.org/freeipa/ticket/3903 > [5] https://fedorahosted.org/freeipa/ticket/3904 > [6] http://lesscss.org/ > [7] https://fedorahosted.org/freeipa/ticket/3875 > [8] http://koji.fedoraproject.org/koji/packageinfo?packageID=15909 > [9] http://koji.fedoraproject.org/koji/packageinfo?packageID=16857 > [10] https://github.com/less/less.js/blob/master/dist/less-rhino-1.3.3.js -- 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 Wed Oct 9 14:04:13 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Oct 2013 16:04:13 +0200 Subject: [Freeipa-devel] Less.js for RCUE adoption In-Reply-To: <52553FC4.3070501@redhat.com> References: <52553FC4.3070501@redhat.com> Message-ID: <5255625D.8010406@redhat.com> On 10/09/2013 01:36 PM, Petr Vobornik wrote: > Hi list, > > I've started to work on RCUE adoption [1][2][3][4][5]. > > RCUE uses Less CSS [6] so that means that technology for #3875 ([Web UI] > Use CSS preprocessor (LESS/SASS/Stylus))[6] is pretty much chosen. > > Topic of this mail is to choose Less CSS implementation we will use > during build. > > First some info. The main implementation of Less CSS is written in > JavaScript as a Node.js module. There are also official builds for > Rhino. Rhino versions are working up to version 1.3.3, they are broken > since version 1.4. There is some upstream effort to make it work again. > Implementations in different languages exist as well, but they may not > implement every feature. > > Fedora has a Node.js package (nodejs-less[8]) and Python implementation > (python-lesscpy[9]). Debian should contain these two as well. Problems > might come with other targeted distributions. > > I tried to run less-rhino-1.3.3.js[10] in Rhino and python-lesscpy, both > on RCUE reference implementation. Both tools seems to produce > functionally equivalent CSS (checked by visual inspection of diff). > > For Fedora: > - if we want to use the latest and greatest we should use Node.js > package. Since Node.js reputation is not good I expect that this won't > be the chosen solution. > - if we want to avoid Node.js we can bundle less-rhino-1.3.3.js[10] or > we can use python-lesscpy. python-lesscpy works better with Fedora > packaging philosophy. +1 for python-lesscpy, for this reason. > For others: > - bundle less-rhino if official package is not present This is really up to the other distros, but I don't see why another Python dependency should be a problem. I'm CCing Timo Aaltonen; we'll need some non-Fedora people to answer these questions. > Therefore: > - bundling of less-rhino is universal solution > - python-lesscpy might be better solution for Fedora I'd say bundling is a universally bad solution :) > Switching between implementations is easy so it's more political > decision. I don't have strong option on any. Creating custom patch for > each platform is a possibility as well. > > Last thing: we could also build and push final CSS during development. I > expect we don't want to that (will be against Fedora packaging policy). We can include them in tarballs but make sure they're re-built for Fedora. I don't think that would be against policy. > [1] https://uxd-rcue.rhcloud.com/ > [2] https://github.com/rhamilto/rcue > [3] https://fedorahosted.org/freeipa/ticket/3902 > [4] https://fedorahosted.org/freeipa/ticket/3903 > [5] https://fedorahosted.org/freeipa/ticket/3904 > [6] http://lesscss.org/ > [7] https://fedorahosted.org/freeipa/ticket/3875 > [8] http://koji.fedoraproject.org/koji/packageinfo?packageID=15909 > [9] http://koji.fedoraproject.org/koji/packageinfo?packageID=16857 > [10] https://github.com/less/less.js/blob/master/dist/less-rhino-1.3.3.js -- Petr? From pviktori at redhat.com Wed Oct 9 14:11:17 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Oct 2013 16:11:17 +0200 Subject: [Freeipa-devel] [PATCHES] 0276-0277 Break long doc strings for translations In-Reply-To: <52372000.3080804@redhat.com> References: <52372000.3080804@redhat.com> Message-ID: <52556405.2010508@redhat.com> On 09/16/2013 05:13 PM, Petr Viktorin wrote: > Hello, > The first patch allow concatenating LazyText objects using `+`. This > means we can break up long docstrings into multiple parts. Translators > can then work on each part separately, and the whole translation is not > lost when a small part is changed or added. > > The second patch splits up the docstring for Host*. I chose Host because > it was updated since last release, so translators would have > to-retranslate the text. In the future, whenever a long docstring is > changed it should be broken up like this. > The patch also updates translations, and adds the broken-up texts for > French and Ukraininan. You can test by viewing Host help in one of these > languages -- only the new section should be untranslated. Rebased to current master. I've added a patch to update translations, please apply it before the other two. It makes the functional changes a bit clearer. Test with: $ LANG=fr_FR ipa help host -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0276-0277.tar.xz Type: application/x-xz Size: 24216 bytes Desc: not available URL: From npmccallum at redhat.com Wed Oct 9 14:17:59 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 09 Oct 2013 10:17:59 -0400 Subject: [Freeipa-devel] [PATCH 0020] Add IntEnum parameter to ipalib In-Reply-To: <52551286.6010805@redhat.com> References: <1380907984.1760.1.camel@localhost> <52529992.6050805@redhat.com> <1381181288.1760.30.camel@localhost> <525432FA.9040906@redhat.com> <1381257444.1760.52.camel@localhost> <52551286.6010805@redhat.com> Message-ID: <1381328279.1760.55.camel@localhost> On Wed, 2013-10-09 at 10:23 +0200, Petr Viktorin wrote: > On 10/08/2013 08:37 PM, Nathaniel McCallum wrote: > > On Tue, 2013-10-08 at 18:29 +0200, Petr Viktorin wrote: > >> On 10/07/2013 11:28 PM, Nathaniel McCallum wrote: > >>> On Mon, 2013-10-07 at 13:22 +0200, Petr Viktorin wrote: > >>>> On 10/04/2013 07:33 PM, Nathaniel McCallum wrote: > >>>>> This patch is preparatory for the OTP CLI patch. > >>>> > >>>> > >>>> > + def _convert_scalar(self, value, index=None): > >>>> > + return Int._convert_scalar(self, value, index=index) > >>>> > >>>> That won't work. In Python 2 unbound methods (such as > >>>> Int._validate_scalar) must be passed the correct type as self; passing > >>>> an IntEnum instance like this will raise a TypeError. > >>>> > >>>> You'll need to either use multiple inheritance (if you feel the > >>>> framework isn't complex enough), or make a convert_int function, and > >>>> then in both Int and IntEnum just call it and handle ValueError. > >>>> > >>>> For validate_scalar it would probably be best to extend > >>>> Param._validate_scalar to allow the class to define extra allowed types, > >>>> and get rid of the reimplementation in Int. > >>> > >>> Fixed. > >> > >> This works, but I do have some comments. > >> > >> I'd prefer if the framework changes and IntEnum addition were in > >> separate patches. > >> I find the usage of _get_types() a bit convoluted, especially when you > >> need to get the "canonical" type. I've taken the liberty to do this with > >> an `allowed_types` attribute, which I think is easier to use, and also > >> doesn't break the API. > >> Would you agree with these changes? > >> > >> I've added tests for IntEnum, as a combination of StrEnum and Int tests. > >> Do they look OK? > > > > Everything looks great except I suspect the reworking of convert_int() > > belongs in the second patch. > > Makes sense, fixed. Two smaller issues. You define allowed_types as a @property in Param and then as a tuple in Int. This seems stylistically inconsistent, though I understand why you've done this, it breaks a certain understanding about the behavior of subclasses of Int. Also, in IntEnum, you've set IntEnum.types rather than IntEnum.allowed_types. Nathaniel From tjaalton at ubuntu.com Wed Oct 9 14:19:59 2013 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Wed, 09 Oct 2013 17:19:59 +0300 Subject: [Freeipa-devel] Less.js for RCUE adoption In-Reply-To: <5255625D.8010406@redhat.com> References: <52553FC4.3070501@redhat.com> <5255625D.8010406@redhat.com> Message-ID: <5255660F.6060003@ubuntu.com> On 09.10.2013 17:04, Petr Viktorin wrote: > On 10/09/2013 01:36 PM, Petr Vobornik wrote: >> Hi list, >> >> I've started to work on RCUE adoption [1][2][3][4][5]. >> >> RCUE uses Less CSS [6] so that means that technology for #3875 ([Web UI] >> Use CSS preprocessor (LESS/SASS/Stylus))[6] is pretty much chosen. >> >> Topic of this mail is to choose Less CSS implementation we will use >> during build. >> >> First some info. The main implementation of Less CSS is written in >> JavaScript as a Node.js module. There are also official builds for >> Rhino. Rhino versions are working up to version 1.3.3, they are broken >> since version 1.4. There is some upstream effort to make it work again. >> Implementations in different languages exist as well, but they may not >> implement every feature. >> >> Fedora has a Node.js package (nodejs-less[8]) and Python implementation >> (python-lesscpy[9]). Debian should contain these two as well. Problems >> might come with other targeted distributions. >> >> I tried to run less-rhino-1.3.3.js[10] in Rhino and python-lesscpy, both >> on RCUE reference implementation. Both tools seems to produce >> functionally equivalent CSS (checked by visual inspection of diff). >> >> For Fedora: >> - if we want to use the latest and greatest we should use Node.js >> package. Since Node.js reputation is not good I expect that this won't >> be the chosen solution. >> - if we want to avoid Node.js we can bundle less-rhino-1.3.3.js[10] or >> we can use python-lesscpy. python-lesscpy works better with Fedora >> packaging philosophy. > > +1 for python-lesscpy, for this reason. > >> For others: >> - bundle less-rhino if official package is not present > > This is really up to the other distros, but I don't see why another > Python dependency should be a problem. > > I'm CCing Timo Aaltonen; we'll need some non-Fedora people to answer > these questions. as mentioned, python-lesscpy is in Debian/Ubuntu now, so as long as any bundled solution can be disabled that's enough for me. -- t From mkosek at redhat.com Wed Oct 9 14:21:09 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Oct 2013 16:21:09 +0200 Subject: [Freeipa-devel] [PATCH] 427 Remove --no-serial-autoincrement Message-ID: <52556655.4090908@redhat.com> Deprecate this option and do not offer it in installation tools. Without this option enabled, advanced DNS features like DNSSEC would not work. https://fedorahosted.org/freeipa/ticket/3962 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-427-remove-no-serial-autoincrement.patch Type: text/x-patch Size: 6159 bytes Desc: not available URL: From pviktori at redhat.com Wed Oct 9 14:36:12 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Oct 2013 16:36:12 +0200 Subject: [Freeipa-devel] [PATCH 0020] Add IntEnum parameter to ipalib In-Reply-To: <1381328279.1760.55.camel@localhost> References: <1380907984.1760.1.camel@localhost> <52529992.6050805@redhat.com> <1381181288.1760.30.camel@localhost> <525432FA.9040906@redhat.com> <1381257444.1760.52.camel@localhost> <52551286.6010805@redhat.com> <1381328279.1760.55.camel@localhost> Message-ID: <525569DC.8010100@redhat.com> On 10/09/2013 04:17 PM, Nathaniel McCallum wrote: > On Wed, 2013-10-09 at 10:23 +0200, Petr Viktorin wrote: >> On 10/08/2013 08:37 PM, Nathaniel McCallum wrote: >>> On Tue, 2013-10-08 at 18:29 +0200, Petr Viktorin wrote: >>>> On 10/07/2013 11:28 PM, Nathaniel McCallum wrote: >>>>> On Mon, 2013-10-07 at 13:22 +0200, Petr Viktorin wrote: >>>>>> On 10/04/2013 07:33 PM, Nathaniel McCallum wrote: >>>>>>> This patch is preparatory for the OTP CLI patch. >>>>>> >>>>>> >>>>>> > + def _convert_scalar(self, value, index=None): >>>>>> > + return Int._convert_scalar(self, value, index=index) >>>>>> >>>>>> That won't work. In Python 2 unbound methods (such as >>>>>> Int._validate_scalar) must be passed the correct type as self; passing >>>>>> an IntEnum instance like this will raise a TypeError. >>>>>> >>>>>> You'll need to either use multiple inheritance (if you feel the >>>>>> framework isn't complex enough), or make a convert_int function, and >>>>>> then in both Int and IntEnum just call it and handle ValueError. >>>>>> >>>>>> For validate_scalar it would probably be best to extend >>>>>> Param._validate_scalar to allow the class to define extra allowed types, >>>>>> and get rid of the reimplementation in Int. >>>>> >>>>> Fixed. >>>> >>>> This works, but I do have some comments. >>>> >>>> I'd prefer if the framework changes and IntEnum addition were in >>>> separate patches. >>>> I find the usage of _get_types() a bit convoluted, especially when you >>>> need to get the "canonical" type. I've taken the liberty to do this with >>>> an `allowed_types` attribute, which I think is easier to use, and also >>>> doesn't break the API. >>>> Would you agree with these changes? >>>> >>>> I've added tests for IntEnum, as a combination of StrEnum and Int tests. >>>> Do they look OK? >>> >>> Everything looks great except I suspect the reworking of convert_int() >>> belongs in the second patch. >> >> Makes sense, fixed. > > Two smaller issues. > > You define allowed_types as a @property in Param and then as a tuple in > Int. This seems stylistically inconsistent, though I understand why > you've done this, it breaks a certain understanding about the behavior > of subclasses of Int. I don't think that's much of an issue. Using a @property that would always return the same value seems redundant. What understanding did you have in mind? > Also, in IntEnum, you've set IntEnum.types rather than > IntEnum.allowed_types. Fixed, thanks. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0001.3-Allow-multiple-types-in-Param-type-validation.patch Type: text/x-patch Size: 6830 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0002.3-Add-IntEnum-parameter-to-ipalib.patch Type: text/x-patch Size: 3968 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0003.3-Add-tests-for-the-IntEnum-class.patch Type: text/x-patch Size: 8738 bytes Desc: not available URL: From npmccallum at redhat.com Wed Oct 9 15:44:02 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 09 Oct 2013 11:44:02 -0400 Subject: [Freeipa-devel] [PATCH 0020] Add IntEnum parameter to ipalib In-Reply-To: <525569DC.8010100@redhat.com> References: <1380907984.1760.1.camel@localhost> <52529992.6050805@redhat.com> <1381181288.1760.30.camel@localhost> <525432FA.9040906@redhat.com> <1381257444.1760.52.camel@localhost> <52551286.6010805@redhat.com> <1381328279.1760.55.camel@localhost> <525569DC.8010100@redhat.com> Message-ID: <1381333442.1760.56.camel@localhost> On Wed, 2013-10-09 at 16:36 +0200, Petr Viktorin wrote: > On 10/09/2013 04:17 PM, Nathaniel McCallum wrote: > > On Wed, 2013-10-09 at 10:23 +0200, Petr Viktorin wrote: > >> On 10/08/2013 08:37 PM, Nathaniel McCallum wrote: > >>> On Tue, 2013-10-08 at 18:29 +0200, Petr Viktorin wrote: > >>>> On 10/07/2013 11:28 PM, Nathaniel McCallum wrote: > >>>>> On Mon, 2013-10-07 at 13:22 +0200, Petr Viktorin wrote: > >>>>>> On 10/04/2013 07:33 PM, Nathaniel McCallum wrote: > >>>>>>> This patch is preparatory for the OTP CLI patch. > >>>>>> > >>>>>> > >>>>>> > + def _convert_scalar(self, value, index=None): > >>>>>> > + return Int._convert_scalar(self, value, index=index) > >>>>>> > >>>>>> That won't work. In Python 2 unbound methods (such as > >>>>>> Int._validate_scalar) must be passed the correct type as self; passing > >>>>>> an IntEnum instance like this will raise a TypeError. > >>>>>> > >>>>>> You'll need to either use multiple inheritance (if you feel the > >>>>>> framework isn't complex enough), or make a convert_int function, and > >>>>>> then in both Int and IntEnum just call it and handle ValueError. > >>>>>> > >>>>>> For validate_scalar it would probably be best to extend > >>>>>> Param._validate_scalar to allow the class to define extra allowed types, > >>>>>> and get rid of the reimplementation in Int. > >>>>> > >>>>> Fixed. > >>>> > >>>> This works, but I do have some comments. > >>>> > >>>> I'd prefer if the framework changes and IntEnum addition were in > >>>> separate patches. > >>>> I find the usage of _get_types() a bit convoluted, especially when you > >>>> need to get the "canonical" type. I've taken the liberty to do this with > >>>> an `allowed_types` attribute, which I think is easier to use, and also > >>>> doesn't break the API. > >>>> Would you agree with these changes? > >>>> > >>>> I've added tests for IntEnum, as a combination of StrEnum and Int tests. > >>>> Do they look OK? > >>> > >>> Everything looks great except I suspect the reworking of convert_int() > >>> belongs in the second patch. > >> > >> Makes sense, fixed. > > > > Two smaller issues. > > > > You define allowed_types as a @property in Param and then as a tuple in > > Int. This seems stylistically inconsistent, though I understand why > > you've done this, it breaks a certain understanding about the behavior > > of subclasses of Int. > > I don't think that's much of an issue. Using a @property that would > always return the same value seems redundant. > What understanding did you have in mind? I don't have a better option. It just stood out to me. > > Also, in IntEnum, you've set IntEnum.types rather than > > IntEnum.allowed_types. > > Fixed, thanks. I think this is ready to merge. Do you? Nathaniel From tbabej at redhat.com Wed Oct 9 16:10:25 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 09 Oct 2013 18:10:25 +0200 Subject: [Freeipa-devel] [PATCHES 114-117] Do proper cleanup after ipa-adtrust-install Message-ID: <52557FF1.8020801@redhat.com> Hi, the following patchset contains fixes for https://fedorahosted.org/freeipa/ticket/3479 . With it applied, you should be able to establish a trust on a reinstalled IPA master that had a trust established. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0114-ipa-upgradeconfig-Remove-backed-up-smb.conf.patch Type: text/x-patch Size: 3426 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0115-ipa-adtrust-install-Add-warning-that-we-will-break-e.patch Type: text/x-patch Size: 2331 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0116-adtrustinstance-Properly-handle-uninstall-of-AD-trus.patch Type: text/x-patch Size: 7383 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0117-adtrustinstance-Move-attribute-definitions-from-setu.patch Type: text/x-patch Size: 5570 bytes Desc: not available URL: From pviktori at redhat.com Wed Oct 9 16:25:54 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Oct 2013 18:25:54 +0200 Subject: [Freeipa-devel] [PATCH 0020] Add IntEnum parameter to ipalib In-Reply-To: <1381333442.1760.56.camel@localhost> References: <1380907984.1760.1.camel@localhost> <52529992.6050805@redhat.com> <1381181288.1760.30.camel@localhost> <525432FA.9040906@redhat.com> <1381257444.1760.52.camel@localhost> <52551286.6010805@redhat.com> <1381328279.1760.55.camel@localhost> <525569DC.8010100@redhat.com> <1381333442.1760.56.camel@localhost> Message-ID: <52558392.4010803@redhat.com> On 10/09/2013 05:44 PM, Nathaniel McCallum wrote: > On Wed, 2013-10-09 at 16:36 +0200, Petr Viktorin wrote: >> On 10/09/2013 04:17 PM, Nathaniel McCallum wrote: >>> On Wed, 2013-10-09 at 10:23 +0200, Petr Viktorin wrote: >>>> On 10/08/2013 08:37 PM, Nathaniel McCallum wrote: >>>>> On Tue, 2013-10-08 at 18:29 +0200, Petr Viktorin wrote: >>>>>> On 10/07/2013 11:28 PM, Nathaniel McCallum wrote: >>>>>>> On Mon, 2013-10-07 at 13:22 +0200, Petr Viktorin wrote: >>>>>>>> On 10/04/2013 07:33 PM, Nathaniel McCallum wrote: >>>>>>>>> This patch is preparatory for the OTP CLI patch. >>>>>>>> >>>>>>>> >>>>>>>> > + def _convert_scalar(self, value, index=None): >>>>>>>> > + return Int._convert_scalar(self, value, index=index) >>>>>>>> >>>>>>>> That won't work. In Python 2 unbound methods (such as >>>>>>>> Int._validate_scalar) must be passed the correct type as self; passing >>>>>>>> an IntEnum instance like this will raise a TypeError. >>>>>>>> >>>>>>>> You'll need to either use multiple inheritance (if you feel the >>>>>>>> framework isn't complex enough), or make a convert_int function, and >>>>>>>> then in both Int and IntEnum just call it and handle ValueError. >>>>>>>> >>>>>>>> For validate_scalar it would probably be best to extend >>>>>>>> Param._validate_scalar to allow the class to define extra allowed types, >>>>>>>> and get rid of the reimplementation in Int. >>>>>>> >>>>>>> Fixed. >>>>>> >>>>>> This works, but I do have some comments. >>>>>> >>>>>> I'd prefer if the framework changes and IntEnum addition were in >>>>>> separate patches. >>>>>> I find the usage of _get_types() a bit convoluted, especially when you >>>>>> need to get the "canonical" type. I've taken the liberty to do this with >>>>>> an `allowed_types` attribute, which I think is easier to use, and also >>>>>> doesn't break the API. >>>>>> Would you agree with these changes? >>>>>> >>>>>> I've added tests for IntEnum, as a combination of StrEnum and Int tests. >>>>>> Do they look OK? >>>>> >>>>> Everything looks great except I suspect the reworking of convert_int() >>>>> belongs in the second patch. >>>> >>>> Makes sense, fixed. >>> >>> Two smaller issues. >>> >>> You define allowed_types as a @property in Param and then as a tuple in >>> Int. This seems stylistically inconsistent, though I understand why >>> you've done this, it breaks a certain understanding about the behavior >>> of subclasses of Int. >> >> I don't think that's much of an issue. Using a @property that would >> always return the same value seems redundant. >> What understanding did you have in mind? > > I don't have a better option. It just stood out to me. > >>> Also, in IntEnum, you've set IntEnum.types rather than >>> IntEnum.allowed_types. >> >> Fixed, thanks. > > I think this is ready to merge. Do you? Thanks! Let's get it in. Pushed to master: 5e8aab8558874a9a826a1c470e806c75fb84eef2 -- Petr? From pviktori at redhat.com Wed Oct 9 16:31:58 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 09 Oct 2013 18:31:58 +0200 Subject: [Freeipa-devel] [PATCHES] 0311-0312 Use new CLI options in certinstall tests Message-ID: <525584FE.9050002@redhat.com> Patch 0311: one-liner (or one-byter) to fix the last certinstall test Patch 0312 adds tests for http://www.freeipa.org/page/V3/ipa-server-certinstall_CLI_cleanup -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0311-test_caless.TestCertInstall-Fix-test_no_ds_password-.patch Type: text/x-patch Size: 1034 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0312-Use-new-CLI-options-in-certinstall-tests.patch Type: text/x-patch Size: 3532 bytes Desc: not available URL: From npmccallum at redhat.com Wed Oct 9 18:57:21 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 09 Oct 2013 14:57:21 -0400 Subject: [Freeipa-devel] Reviews still needed Message-ID: <1381345041.1760.60.camel@localhost> I still need reviews on the following patches. The first two (0015 and 0016) should be close if not ready to merge. They have undergone four revisions. The third is probably in the middle of reviews. Please help me push this over the goal line. :) Nathaniel freeipa-npmccallum-0015-4-Add-support-for-managing-user-auth-types.patch API.txt | 12 ++++++++---- VERSION | 2 +- install/updates/50-ipaconfig.update | 1 + ipalib/plugins/config.py | 8 ++++++++ ipalib/plugins/user.py | 35 ++++++++++++++++++++++------ 5 files changed, 43 insertions(+), 15 deletions(-) freeipa-npmccallum-0016-4-Add-RADIUS-proxy-support-to-ipalib-CLI.patch API.txt | 95 +++++++++++++++++++++++-- VERSION | 2 install/share/70ipaotp.ldif | 2 install/share/indices.ldif | 10 ++ install/share/referint-conf.ldif | 3 install/updates/10-70ipaotp.update | 2 install/updates/20-indices.update | 7 + install/updates/25-referint.update | 1 install/updates/40-otp.update | 5 + ipalib/constants.py | 1 ipalib/plugins/config.py | 2 ipalib/plugins/radiusproxy.py | 138 +++++++++++++++++++++++++++++ ipalib/plugins/user.py | 44 ++++++++++- 13 files changed, 298 insertions(+), 14 deletions(-) freeipa-npmccallum-0024-2-Add-OTP-support-to-ipalib-CLI.patch API.txt | 101 +++++++++++++ VERSION | 2 freeipa.spec.in | 2 ipalib/errors.py | 16 ++ ipalib/plugins/config.py | 2 ipalib/plugins/otptoken.py | 330 +++++++++++++++++++++++++++++++++++++ ipalib/plugins/user.py | 10 + 7 files changed, 456 insertions(+), 7 deletions(-) From mkosek at redhat.com Wed Oct 9 20:38:29 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 09 Oct 2013 22:38:29 +0200 Subject: [Freeipa-devel] [PATCH] 428 PKI installation on replica failing due to missing proxy conf Message-ID: <5255BEC5.2010807@redhat.com> Proxy configuration was not detected correctly. Both ipa-pki-proxy.conf and ipa.conf need to be in place and httpd restarted to be able to check it's status. https://fedorahosted.org/freeipa/ticket/3964 ---- I had to install and reinstall PKI a lot before I found the real root cause. Both ipa-replica-install --setup-ca and ipa-ca-install should be working now. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-428-pki-installation-on-replica-failing-due-to-missing-p.patch Type: text/x-patch Size: 2226 bytes Desc: not available URL: From jcholast at redhat.com Thu Oct 10 07:45:13 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 10 Oct 2013 09:45:13 +0200 Subject: [Freeipa-devel] [PATCHES] 106-113 Access raw LDAP values directly from LDAPEntry In-Reply-To: <525544A3.6080807@redhat.com> References: <512E26E1.5010302@redhat.com> <52419527.70200@redhat.com> <524426F5.6010006@redhat.com> <525544A3.6080807@redhat.com> Message-ID: <52565B09.2090909@redhat.com> On 9.10.2013 13:57, Petr Viktorin wrote: > On 09/26/2013 02:22 PM, Jan Cholasta wrote: >> On 24.9.2013 15:35, Jan Cholasta wrote: >>> On 27.2.2013 16:31, Jan Cholasta wrote: >>>> Hi, >>>> >>>> these patches add the ability to access and manipulate raw attribute >>>> values as they are returned from python-ldap to the LDAPEntry class. >>>> This is useful for comparing entries, computing modlists for the modify >>>> operation, deleting values that don't match the syntax of an attribute, >>>> etc., because we don't need to care what syntax does a particular >>>> attribute use, or what Python type is used for it in the framework (raw >>>> values are always list of str). It should also make interaction with >>>> non-389 DS LDAP servers easier in the framework. >>>> >>>> (It might be too late for this kind of changes to get into 3.2 now, I'm >>>> posting these patches mainly so that you are aware that they exist.) >>>> >>>> Honza >>>> >>> >>> This is now planned for 3.4: >>> >>> >>> I fixed some issues in these patches and refined the API. Updated >>> patches attached. >>> >>> Also added a patch to use raw values when adding new entries and a patch >>> which refines LDAPEntry.single_value, so that it is consistent with the >>> rest of the changes introduced in the patches. >>> >>> Patch 110 will probably be dropped in favor of Petr Viktorin's schema >>> update patches, but I included it anyway. >>> >>> Incidentally, this also fixes >>> and possibly also >>> . >>> >>> Honza >>> >> >> Noticed a couple more issues and fixed them. Updated patches attached. >> >> Honza > > Thanks for the patches! > > > 106. Make LDAPEntry a wrapper around dict rather than a dict subclass. > > ipapython/ipaldap.py:847: > warning: 1 line adds whitespace errors. > > if isinstance(_obj, LDAPEntry): > + data = dict(_obj._data) > orig = _obj._orig > > Is this necessary? `self.update(_obj)` is done later. Probably not. But it's removed in patch 109. > > > def __contains__(self, name): > - return self._names.has_key(self._attr_name(name)) > + return self._names.has_key(name) > > has_key() is deprecated for dict, it would make sense to prefer `name in > self._names` for CIDict too. Sure, this line is from before CIDict got __contains__. > > + def __eq__(self, other): > + if not isinstance(other, LDAPEntry): > + return NotImplemented > + if self._dn != other._dn: > + return False > + return super(LDAPEntry, self).__eq__(other) > > I don't think equality checking makes sense on a LDAPEntry, where you > might have different capitalizations/variants of attribute names, > different _orig, or a different set of attributes loaded on the same > entry. It's not obvious which of those differences should make the > entries inequal. > I'd just base it on identity (`self is other`). Right, I'm not sure why I even did it this way. But I remember seeing some code that did comparison of entries with ==... > > def __iter__(self): > yield self._dn > yield self > > This makes the whole thing sort of hackish -- we need to reimplement > everything in MutableMapping that uses iter() internally :( > Hopefully we can get rid of it soon. Yes, it's a shame MutableMapping uses iter() instead of iterkeys(). > I'd welcome FIXME comments on whatever is reimplemented for this reason. I thought the comment above __iter__ would be enough. Apparently I was wrong. > > > 107. Introduce IPASimpleLDAPObject.decode method for decoding LDAP values. > > Can you put in a docstring? OK. > > > > 108. Always use lists for values in LDAPEntry internally. > > @@ -698,6 +701,7 @@ class LDAPEntry(collections.MutableMapping): > > result._names = deepcopy(self._names) > result._data = deepcopy(self._data) > + result._not_list = deepcopy(self._not_list) > if self._orig is not self: > result._orig = self._orig.clone() > > It's better to use set() than deepcopy() for a set of strings. Right. > > > 109. Decode and encode attribute values in LDAPEntry on demand. > > The syncing looks rather over-engineered to me. > Did you consider a custom MutableSequence for the values? > I think it would be much cleaner in the end than merging two sets of > changes together. I'm not entirely happy about it either, but it works. I did consider a custom sequence type, but I didn't feel like it was the right time to this kind of change in this patchset. Unlike the (DN, dict) -> LDAPEntry transition, this change won't be backward compatible and there is a lot of isinstance(value, list) and entry[attr] = list() kind of things in the framework code. > > I think it would also help (in the future?) to make the value lists more > set-like, since the order doesn't matter. +1 Honza -- Jan Cholasta From jcholast at redhat.com Thu Oct 10 08:04:21 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 10 Oct 2013 10:04:21 +0200 Subject: [Freeipa-devel] [PATCH 0015] Add support for managing user auth types In-Reply-To: <1379018855.2210.0.camel@localhost> References: <1378353865.19352.9.camel@localhost> <1379018855.2210.0.camel@localhost> Message-ID: <52565F85.10209@redhat.com> On 12.9.2013 22:47, Nathaniel McCallum wrote: > On Thu, 2013-09-05 at 00:04 -0400, Nathaniel McCallum wrote: >> patch attached > > Update for ./makeapi attached. > Is ipaUserAuthType relevant only to Kerberos or to user authentication in general? For example, if "password" is removed from ipaUserAuthType of an user, will I be able to authenticate as that user with LDAP simple authentication? Honza -- Jan Cholasta From jcholast at redhat.com Thu Oct 10 11:47:38 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 10 Oct 2013 13:47:38 +0200 Subject: [Freeipa-devel] [PATCH] 427 Remove --no-serial-autoincrement In-Reply-To: <52556655.4090908@redhat.com> References: <52556655.4090908@redhat.com> Message-ID: <525693DA.70605@redhat.com> Hi, On 9.10.2013 16:21, Martin Kosek wrote: > Deprecate this option and do not offer it in installation tools. > Without this option enabled, advanced DNS features like DNSSEC > would not work. > > https://fedorahosted.org/freeipa/ticket/3962 > Is there a reason not to remove serial_autoincrement from bindinstance? It is used only to set serial_autoincrement value in named.conf template, which can be hard-coded to "yes" in the template file. Honza -- Jan Cholasta From mkosek at redhat.com Thu Oct 10 12:02:28 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 10 Oct 2013 14:02:28 +0200 Subject: [Freeipa-devel] [PATCH] 427 Remove --no-serial-autoincrement In-Reply-To: <525693DA.70605@redhat.com> References: <52556655.4090908@redhat.com> <525693DA.70605@redhat.com> Message-ID: <52569754.6040908@redhat.com> On 10/10/2013 01:47 PM, Jan Cholasta wrote: > Hi, > > On 9.10.2013 16:21, Martin Kosek wrote: >> Deprecate this option and do not offer it in installation tools. >> Without this option enabled, advanced DNS features like DNSSEC >> would not work. >> >> https://fedorahosted.org/freeipa/ticket/3962 >> > > Is there a reason not to remove serial_autoincrement from bindinstance? It is > used only to set serial_autoincrement value in named.conf template, which can > be hard-coded to "yes" in the template file. > > Honza > Probably not, attaching updated patch. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-427-2-remove-no-serial-autoincrement.patch Type: text/x-patch Size: 7144 bytes Desc: not available URL: From jcholast at redhat.com Thu Oct 10 12:18:16 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 10 Oct 2013 14:18:16 +0200 Subject: [Freeipa-devel] [PATCH] 427 Remove --no-serial-autoincrement In-Reply-To: <52569754.6040908@redhat.com> References: <52556655.4090908@redhat.com> <525693DA.70605@redhat.com> <52569754.6040908@redhat.com> Message-ID: <52569B08.7090008@redhat.com> On 10.10.2013 14:02, Martin Kosek wrote: > On 10/10/2013 01:47 PM, Jan Cholasta wrote: >> Hi, >> >> On 9.10.2013 16:21, Martin Kosek wrote: >>> Deprecate this option and do not offer it in installation tools. >>> Without this option enabled, advanced DNS features like DNSSEC >>> would not work. >>> >>> https://fedorahosted.org/freeipa/ticket/3962 >>> >> >> Is there a reason not to remove serial_autoincrement from bindinstance? It is >> used only to set serial_autoincrement value in named.conf template, which can >> be hard-coded to "yes" in the template file. >> >> Honza >> > > Probably not, attaching updated patch. > > Martin > ACK. -- Jan Cholasta From jcholast at redhat.com Thu Oct 10 13:24:38 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 10 Oct 2013 15:24:38 +0200 Subject: [Freeipa-devel] [PATCH] 428 PKI installation on replica failing due to missing proxy conf In-Reply-To: <5255BEC5.2010807@redhat.com> References: <5255BEC5.2010807@redhat.com> Message-ID: <5256AA96.1050601@redhat.com> Hi, On 9.10.2013 22:38, Martin Kosek wrote: > Proxy configuration was not detected correctly. Both > ipa-pki-proxy.conf and ipa.conf need to be in place and httpd > restarted to be able to check it's status. > > https://fedorahosted.org/freeipa/ticket/3964 > > ---- > > I had to install and reinstall PKI a lot before I found the real root > cause. Both > ipa-replica-install --setup-ca > and > ipa-ca-install > should be working now. > ACK. -- Jan Cholasta From npmccallum at redhat.com Thu Oct 10 14:51:17 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 10 Oct 2013 10:51:17 -0400 Subject: [Freeipa-devel] [PATCH 0015] Add support for managing user auth types In-Reply-To: <52565F85.10209@redhat.com> References: <1378353865.19352.9.camel@localhost> <1379018855.2210.0.camel@localhost> <52565F85.10209@redhat.com> Message-ID: <1381416677.1760.63.camel@localhost> On Thu, 2013-10-10 at 10:04 +0200, Jan Cholasta wrote: > On 12.9.2013 22:47, Nathaniel McCallum wrote: > > On Thu, 2013-09-05 at 00:04 -0400, Nathaniel McCallum wrote: > >> patch attached > > > > Update for ./makeapi attached. > > > > Is ipaUserAuthType relevant only to Kerberos or to user authentication > in general? For example, if "password" is removed from ipaUserAuthType > of an user, will I be able to authenticate as that user with LDAP simple > authentication? If only "otp" is set, yes via password+otp. If only "radius" is set, this behavior is currently undefined. We should probably define it. Nathaniel From tbabej at redhat.com Thu Oct 10 14:52:15 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 10 Oct 2013 16:52:15 +0200 Subject: [Freeipa-devel] [PATCH 0118] Do not create separate ranges for subdomains in case of POSIX trust Message-ID: <5256BF1F.3050608@redhat.com> Hi, This is a fix for a bug I found related to the subdomains code while working on the AD Continuous Integration testing. -- 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-0118-trusts-Do-not-create-ranges-for-subdomains-in-case-o.patch Type: text/x-patch Size: 4702 bytes Desc: not available URL: From jcholast at redhat.com Thu Oct 10 15:30:04 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 10 Oct 2013 17:30:04 +0200 Subject: [Freeipa-devel] [PATCH 0015] Add support for managing user auth types In-Reply-To: <1381416677.1760.63.camel@localhost> References: <1378353865.19352.9.camel@localhost> <1379018855.2210.0.camel@localhost> <52565F85.10209@redhat.com> <1381416677.1760.63.camel@localhost> Message-ID: <5256C7FC.9000304@redhat.com> On 10.10.2013 16:51, Nathaniel McCallum wrote: > On Thu, 2013-10-10 at 10:04 +0200, Jan Cholasta wrote: >> On 12.9.2013 22:47, Nathaniel McCallum wrote: >>> On Thu, 2013-09-05 at 00:04 -0400, Nathaniel McCallum wrote: >>>> patch attached >>> >>> Update for ./makeapi attached. >>> >> >> Is ipaUserAuthType relevant only to Kerberos or to user authentication >> in general? For example, if "password" is removed from ipaUserAuthType >> of an user, will I be able to authenticate as that user with LDAP simple >> authentication? > > If only "otp" is set, yes via password+otp. > > If only "radius" is set, this behavior is currently undefined. We should > probably define it. > > Nathaniel > OK, thanks. I'm wondering if SSH public key authentication should be included in the list, it is one of the currently supported authentication methods after all. I'm also wondering if HBAC could be extended to allow/deny access based on which authentication type was used. It might be useful for OTP token synchronization when password authentication is disabled (it could be used to allow password authentication *only* to the token synchronization service, if there's such a thing). Honza -- Jan Cholasta From jcholast at redhat.com Thu Oct 10 15:45:37 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 10 Oct 2013 17:45:37 +0200 Subject: [Freeipa-devel] [PATCH] 426 Winsync re-initialize should not run memberOf fixup task In-Reply-To: <52553E7F.5070204@redhat.com> References: <52553E7F.5070204@redhat.com> Message-ID: <5256CBA1.9050209@redhat.com> Hi, On 9.10.2013 13:31, Martin Kosek wrote: > Change re-initialize command to consider memberOf fixup task only > for non-winsync replication agreements. This patch also includes > few fixes for DsInstance to properly set realm and fqdn properties > needed when connecting to LDAP. > > https://fedorahosted.org/freeipa/ticket/3854 > - self.realm_name = realm_name + self.realm_name = self.realm = realm_name I think one realm property is enough. Can you please change dsinstance to use .realm instead of .realm_name? Honza -- Jan Cholasta From mkosek at redhat.com Thu Oct 10 16:07:15 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 10 Oct 2013 18:07:15 +0200 Subject: [Freeipa-devel] [PATCH] 429 Administrative password change does not respect password policy Message-ID: <5256D0B3.40403@redhat.com> When Directory Manager or a PassSync agent is changing a password, it is not being expired, but standard expiration time should apply. However, default expiration time was always applied (90 days) even though administrator may have a custom policy for the user. https://fedorahosted.org/freeipa/ticket/3968 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-429-administrative-password-change-does-not-respect-pass.patch Type: text/x-patch Size: 3595 bytes Desc: not available URL: From jfenal at gmail.com Thu Oct 10 16:37:17 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Thu, 10 Oct 2013 18:37:17 +0200 Subject: [Freeipa-devel] [PATCH] [DOC] Remove SELinux user paragraph replacement Message-ID: Attached. Replaced the dodgy sentence with Martin's one. Regards, J. -- J?r?me Fenal -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jfenal-0002-Remove-SELinux-user.patch Type: application/octet-stream Size: 919 bytes Desc: not available URL: From dpal at redhat.com Thu Oct 10 16:44:33 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 10 Oct 2013 12:44:33 -0400 Subject: [Freeipa-devel] [PATCH 0015] Add support for managing user auth types In-Reply-To: <1381416677.1760.63.camel@localhost> References: <1378353865.19352.9.camel@localhost> <1379018855.2210.0.camel@localhost> <52565F85.10209@redhat.com> <1381416677.1760.63.camel@localhost> Message-ID: <5256D971.4070303@redhat.com> On 10/10/2013 10:51 AM, Nathaniel McCallum wrote: > On Thu, 2013-10-10 at 10:04 +0200, Jan Cholasta wrote: >> On 12.9.2013 22:47, Nathaniel McCallum wrote: >>> On Thu, 2013-09-05 at 00:04 -0400, Nathaniel McCallum wrote: >>>> patch attached >>> Update for ./makeapi attached. >>> >> Is ipaUserAuthType relevant only to Kerberos or to user authentication >> in general? For example, if "password" is removed from ipaUserAuthType >> of an user, will I be able to authenticate as that user with LDAP simple >> authentication? > If only "otp" is set, yes via password+otp. > > If only "radius" is set, this behavior is currently undefined. We should > probably define it. If RADIUS is used you always rely on the external system to provide authentication for this user. Is this the definition you are looking for? > > 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 dpal at redhat.com Thu Oct 10 16:48:29 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 10 Oct 2013 12:48:29 -0400 Subject: [Freeipa-devel] [PATCH 0015] Add support for managing user auth types In-Reply-To: <5256C7FC.9000304@redhat.com> References: <1378353865.19352.9.camel@localhost> <1379018855.2210.0.camel@localhost> <52565F85.10209@redhat.com> <1381416677.1760.63.camel@localhost> <5256C7FC.9000304@redhat.com> Message-ID: <5256DA5D.6090407@redhat.com> On 10/10/2013 11:30 AM, Jan Cholasta wrote: > On 10.10.2013 16:51, Nathaniel McCallum wrote: >> On Thu, 2013-10-10 at 10:04 +0200, Jan Cholasta wrote: >>> On 12.9.2013 22:47, Nathaniel McCallum wrote: >>>> On Thu, 2013-09-05 at 00:04 -0400, Nathaniel McCallum wrote: >>>>> patch attached >>>> >>>> Update for ./makeapi attached. >>>> >>> >>> Is ipaUserAuthType relevant only to Kerberos or to user authentication >>> in general? For example, if "password" is removed from ipaUserAuthType >>> of an user, will I be able to authenticate as that user with LDAP >>> simple >>> authentication? >> >> If only "otp" is set, yes via password+otp. >> >> If only "radius" is set, this behavior is currently undefined. We should >> probably define it. >> >> Nathaniel >> > > OK, thanks. I'm wondering if SSH public key authentication should be > included in the list, it is one of the currently supported > authentication methods after all. You can't bind to LDAP or kinit with SSH keys so i do not think it is in the same boat. These methods are methods that IPA as a server would accept. I doubt Kerberos will be extended to support authentication with SSH keys. I do not think there is a use case for it. > > I'm also wondering if HBAC could be extended to allow/deny access > based on which authentication type was used. It might be useful for > OTP token synchronization when password authentication is disabled (it > could be used to allow password authentication *only* to the token > synchronization service, if there's such a thing). The plan here is to really rely on the Kerberos ticket and data in it to make the access control decisions. This is the spec that Anupam is working on so that part is covered. > > Honza > -- 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 Thu Oct 10 16:58:36 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 10 Oct 2013 18:58:36 +0200 Subject: [Freeipa-devel] [PATCH 0186-0191] Replace LDAP cache with RBTDB In-Reply-To: <5253D7A0.2020108@redhat.com> References: <51FA694C.1000302@redhat.com> <520B9373.1070707@redhat.com> <520B9755.70503@redhat.com> <523313C3.8070306@redhat.com> <524BFBFD.1000901@redhat.com> <5253D7A0.2020108@redhat.com> Message-ID: <5256DCBC.3070901@redhat.com> On 8.10.2013 12:00, Tomas Hozza wrote: > On 10/02/2013 12:57 PM, Petr Spacek wrote: >> On 13.9.2013 15:31, Petr Spacek wrote: >>> On 14.8.2013 16:42, Petr Spacek wrote: >>>> On 14.8.2013 16:25, Petr Spacek wrote: >>>>> On 1.8.2013 15:57, Petr Spacek wrote: >>>>>> Hello, >>>>>> >>>>>> attached monster patches replace our internal cache/database with >>>>>> RBTDB >>>>>> implementation. See commit messages and comments inside. >>>>>> >>>>>> This patch set provides very basic functionality (including DNS >>>>>> support for >>>>>> updates). Error handling definitely needs more love, but it should >>>>>> be enough >>>>>> for rapid DNSSEC prototyping. >>>>> >>>>> Patch 186 v2: The code now applies incremental changes in LDAP to the >>>>> in-memory database. Commit message was modified to mention that >>>>> wildcards are >>>>> now supported. >>>>> >>>>> Patch 187 v2: The code was re-worked and now it respects >>>>> serial_autoincrement >>>>> option. >>>>> >>>>> Patch 188 v2: Minor comment clean-up and rebase on top of patch 187 v2. >>>>> >>>>> Patch 189 v2: Call to deleterdataset() nested in substractrdataset() >>>>> was >>>>> deleted. This code was meant only for testing purposes. >>>>> >>>>> These patch set is now ready for review. Please see commit messages! >>>>> Some >>>>> functionality is missing intentionally, but it will be fixed by >>>>> separate >>>>> patches. >>>> >>>> It would be too easy! >>>> >>>> Patch 186 v3: Commit message was extended with information that LDAP >>>> MODRDN >>>> operation is not supported at the moment. >>>> >>>> Patch 187 v3: Missing file ldap_driver.h was added. >>> >>> This extended patch set handles correctly object deletion from LDAP. >>> >>> Patches 186-189 contain very minor changes, only moving code from one >>> place to >>> the other. >>> >>> See commit messages for patches 190 and 191. >>> >>> This should be testable. I would recommend to test the whole patch set at >>> once, most probably it doesn't make much sense to test patches >>> separately. >> >> bind-dyndb-ldap-pspacek-0186-5-Use-RBTDB-instead-of-internal-LDAP-cache.patch >> adds missing missing include (db.h) to zone_register.c. >> > > ACK. > > Patches 186-191 tested. Adding/removing/modifying records works fine. > Also PTR synchronization works. Zone transfer to slave and NOTIFY > tested when changes occurred on master. Patch 191-2 fixed problem with zone removal and race condition during zone load. I would recommend you to test it with other patch I plan to send today :-) -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0191-2-Handle-object-deletion.patch Type: text/x-patch Size: 10781 bytes Desc: not available URL: From pspacek at redhat.com Thu Oct 10 17:05:04 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 10 Oct 2013 19:05:04 +0200 Subject: [Freeipa-devel] [PATCH 0192-0196] Write all changes to journal Message-ID: <5256DE40.4060000@redhat.com> Hello, this patch set adds journaling to bind-dyndb-ldap. Journaling requires proper SOA serial maintenance, so from now SOA serial auto-incrementation is mandatory. Journal file is deleted on each start, so IXFR is limited to time frame from last BIND start. https://fedorahosted.org/bind-dyndb-ldap/ticket/64 You can use my personal branch for testing: https://github.com/spacekpe/bind-dyndb-ldap/tree/rbtdb.v7 It contains all unpushed patches. Basically, next master should be identical to this branch. Thank you for your time! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0192-Disallow-empty-LDAP-instance-names.patch Type: text/x-patch Size: 1030 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0193-Rework-SOA-serial-auto-incrementation-and-make-it-ma.patch Type: text/x-patch Size: 20975 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0194-Create-working-directory-for-each-LDAP-instance.patch Type: text/x-patch Size: 6313 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0195-Create-working-directory-for-each-DNS-zone.patch Type: text/x-patch Size: 4158 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0196-Record-all-changes-in-DNS-zone-to-journal.patch Type: text/x-patch Size: 9691 bytes Desc: not available URL: From npmccallum at redhat.com Thu Oct 10 19:13:02 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 10 Oct 2013 15:13:02 -0400 Subject: [Freeipa-devel] [PATCH 0015] Add support for managing user auth types In-Reply-To: <5256D971.4070303@redhat.com> References: <1378353865.19352.9.camel@localhost> <1379018855.2210.0.camel@localhost> <52565F85.10209@redhat.com> <1381416677.1760.63.camel@localhost> <5256D971.4070303@redhat.com> Message-ID: <1381432382.1760.65.camel@localhost> On Thu, 2013-10-10 at 12:44 -0400, Dmitri Pal wrote: > On 10/10/2013 10:51 AM, Nathaniel McCallum wrote: > > On Thu, 2013-10-10 at 10:04 +0200, Jan Cholasta wrote: > >> On 12.9.2013 22:47, Nathaniel McCallum wrote: > >>> On Thu, 2013-09-05 at 00:04 -0400, Nathaniel McCallum wrote: > >>>> patch attached > >>> Update for ./makeapi attached. > >>> > >> Is ipaUserAuthType relevant only to Kerberos or to user authentication > >> in general? For example, if "password" is removed from ipaUserAuthType > >> of an user, will I be able to authenticate as that user with LDAP simple > >> authentication? > > If only "otp" is set, yes via password+otp. > > > > If only "radius" is set, this behavior is currently undefined. We should > > probably define it. > > If RADIUS is used you always rely on the external system to provide > authentication for this user. > Is this the definition you are looking for? For Kerberos, yes. For LDAP, no. For LDAP, if "radius" is present, single factor authentication should probably be permitted. Nathaniel From dpal at redhat.com Thu Oct 10 19:53:05 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 10 Oct 2013 15:53:05 -0400 Subject: [Freeipa-devel] [PATCH 0015] Add support for managing user auth types In-Reply-To: <1381432382.1760.65.camel@localhost> References: <1378353865.19352.9.camel@localhost> <1379018855.2210.0.camel@localhost> <52565F85.10209@redhat.com> <1381416677.1760.63.camel@localhost> <5256D971.4070303@redhat.com> <1381432382.1760.65.camel@localhost> Message-ID: <525705A1.9030601@redhat.com> On 10/10/2013 03:13 PM, Nathaniel McCallum wrote: > On Thu, 2013-10-10 at 12:44 -0400, Dmitri Pal wrote: >> On 10/10/2013 10:51 AM, Nathaniel McCallum wrote: >>> On Thu, 2013-10-10 at 10:04 +0200, Jan Cholasta wrote: >>>> On 12.9.2013 22:47, Nathaniel McCallum wrote: >>>>> On Thu, 2013-09-05 at 00:04 -0400, Nathaniel McCallum wrote: >>>>>> patch attached >>>>> Update for ./makeapi attached. >>>>> >>>> Is ipaUserAuthType relevant only to Kerberos or to user authentication >>>> in general? For example, if "password" is removed from ipaUserAuthType >>>> of an user, will I be able to authenticate as that user with LDAP simple >>>> authentication? >>> If only "otp" is set, yes via password+otp. >>> >>> If only "radius" is set, this behavior is currently undefined. We should >>> probably define it. >> If RADIUS is used you always rely on the external system to provide >> authentication for this user. >> Is this the definition you are looking for? > For Kerberos, yes. For LDAP, no. For LDAP, if "radius" is present, > single factor authentication should probably be permitted. > > Nathaniel > Why you think they should be inconsistent? If you want to have this case covered I think we need a separate type something like "kerberos_radius" which will work only in kerberos but not in LDAP. But IMO such mode will create a lot of confusion. We can also do "kerberos_radius_ldap_pwd_and_radius" that would allow radius for kerberos and allow local LDAP password or RADIUS for bind but I do not see a reason for this case. Can you explain? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From npmccallum at redhat.com Fri Oct 11 00:33:45 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 10 Oct 2013 20:33:45 -0400 Subject: [Freeipa-devel] [PATCH 0015] Add support for managing user auth types In-Reply-To: <525705A1.9030601@redhat.com> References: <1378353865.19352.9.camel@localhost> <1379018855.2210.0.camel@localhost> <52565F85.10209@redhat.com> <1381416677.1760.63.camel@localhost> <5256D971.4070303@redhat.com> <1381432382.1760.65.camel@localhost> <525705A1.9030601@redhat.com> Message-ID: <1381451625.1760.68.camel@localhost> On Thu, 2013-10-10 at 15:53 -0400, Dmitri Pal wrote: > On 10/10/2013 03:13 PM, Nathaniel McCallum wrote: > > On Thu, 2013-10-10 at 12:44 -0400, Dmitri Pal wrote: > >> On 10/10/2013 10:51 AM, Nathaniel McCallum wrote: > >>> On Thu, 2013-10-10 at 10:04 +0200, Jan Cholasta wrote: > >>>> On 12.9.2013 22:47, Nathaniel McCallum wrote: > >>>>> On Thu, 2013-09-05 at 00:04 -0400, Nathaniel McCallum wrote: > >>>>>> patch attached > >>>>> Update for ./makeapi attached. > >>>>> > >>>> Is ipaUserAuthType relevant only to Kerberos or to user authentication > >>>> in general? For example, if "password" is removed from ipaUserAuthType > >>>> of an user, will I be able to authenticate as that user with LDAP simple > >>>> authentication? > >>> If only "otp" is set, yes via password+otp. > >>> > >>> If only "radius" is set, this behavior is currently undefined. We should > >>> probably define it. > >> If RADIUS is used you always rely on the external system to provide > >> authentication for this user. > >> Is this the definition you are looking for? > > For Kerberos, yes. For LDAP, no. For LDAP, if "radius" is present, > > single factor authentication should probably be permitted. > > > > Nathaniel > > > Why you think they should be inconsistent? > If you want to have this case covered I think we need a separate type > something like "kerberos_radius" which will work only in kerberos but > not in LDAP. > But IMO such mode will create a lot of confusion. > We can also do "kerberos_radius_ldap_pwd_and_radius" that would allow > radius for kerberos and allow local LDAP password or RADIUS for bind but > I do not see a reason for this case. > Can you explain? We implemented RADIUS forwarding in the companion daemon. So the implementation of the ipaUserAuthType for "radius" is occurring outside 389ds. Hence, when ipaUserAuthType says "radius" the companion daemon will forward Kerberos OTP requests to RADIUS. 389ds binds, however, will use standard password authentication in this case. There is no way around this without merging RADIUS proxying into 389ds directly. Nathaniel From dpal at redhat.com Fri Oct 11 03:07:27 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 10 Oct 2013 23:07:27 -0400 Subject: [Freeipa-devel] [PATCH 0015] Add support for managing user auth types In-Reply-To: <1381451625.1760.68.camel@localhost> References: <1378353865.19352.9.camel@localhost> <1379018855.2210.0.camel@localhost> <52565F85.10209@redhat.com> <1381416677.1760.63.camel@localhost> <5256D971.4070303@redhat.com> <1381432382.1760.65.camel@localhost> <525705A1.9030601@redhat.com> <1381451625.1760.68.camel@localhost> Message-ID: <52576B6F.2090401@redhat.com> On 10/10/2013 08:33 PM, Nathaniel McCallum wrote: > On Thu, 2013-10-10 at 15:53 -0400, Dmitri Pal wrote: >> On 10/10/2013 03:13 PM, Nathaniel McCallum wrote: >>> On Thu, 2013-10-10 at 12:44 -0400, Dmitri Pal wrote: >>>> On 10/10/2013 10:51 AM, Nathaniel McCallum wrote: >>>>> On Thu, 2013-10-10 at 10:04 +0200, Jan Cholasta wrote: >>>>>> On 12.9.2013 22:47, Nathaniel McCallum wrote: >>>>>>> On Thu, 2013-09-05 at 00:04 -0400, Nathaniel McCallum wrote: >>>>>>>> patch attached >>>>>>> Update for ./makeapi attached. >>>>>>> >>>>>> Is ipaUserAuthType relevant only to Kerberos or to user authentication >>>>>> in general? For example, if "password" is removed from ipaUserAuthType >>>>>> of an user, will I be able to authenticate as that user with LDAP simple >>>>>> authentication? >>>>> If only "otp" is set, yes via password+otp. >>>>> >>>>> If only "radius" is set, this behavior is currently undefined. We should >>>>> probably define it. >>>> If RADIUS is used you always rely on the external system to provide >>>> authentication for this user. >>>> Is this the definition you are looking for? >>> For Kerberos, yes. For LDAP, no. For LDAP, if "radius" is present, >>> single factor authentication should probably be permitted. >>> >>> Nathaniel >>> >> Why you think they should be inconsistent? >> If you want to have this case covered I think we need a separate type >> something like "kerberos_radius" which will work only in kerberos but >> not in LDAP. >> But IMO such mode will create a lot of confusion. >> We can also do "kerberos_radius_ldap_pwd_and_radius" that would allow >> radius for kerberos and allow local LDAP password or RADIUS for bind but >> I do not see a reason for this case. >> Can you explain? > We implemented RADIUS forwarding in the companion daemon. So the > implementation of the ipaUserAuthType for "radius" is occurring outside > 389ds. Hence, when ipaUserAuthType says "radius" the companion daemon > will forward Kerberos OTP requests to RADIUS. 389ds binds, however, will > use standard password authentication in this case. There is no way > around this without merging RADIUS proxying into 389ds directly. Ah right, I forget that only OTP is implemented in DS so it can be used by bind and Kerberos. Then we need to document expectation about "radius". > Nathaniel > > -- 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 Fri Oct 11 07:09:22 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 11 Oct 2013 09:09:22 +0200 Subject: [Freeipa-devel] [PATCH] [DOC] Remove SELinux user paragraph replacement In-Reply-To: References: Message-ID: <5257A422.4050603@redhat.com> On 10/10/2013 06:37 PM, J?r?me Fenal wrote: > Attached. > Replaced the dodgy sentence with Martin's one. > > Regards, > > J. Thanks J?r?me for the patch, I have few comments though: 1) One more note for patch format, please use the following command to extract your patch from git: $ git format-patch -M -C --patience --full-index -1 Source: http://www.freeipa.org/page/Contribute/Patch_Format It will maker then easier for us to merge the patch to main git tree. 2) I think we should not mix indentation with spaces and tabs 3) Shouldn't we also remove the now redundant previous paragraph? A change like that: - - A specific user or host can be removed from an SELinux map by using either the selinuxusermap-remove-host or selinuxusermap-remove-user comma... - Martin From mkosek at redhat.com Fri Oct 11 07:47:09 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 11 Oct 2013 09:47:09 +0200 Subject: [Freeipa-devel] [PATCH] 426, 430 Winsync re-initialize should not run memberOf fixup task In-Reply-To: <5256CBA1.9050209@redhat.com> References: <52553E7F.5070204@redhat.com> <5256CBA1.9050209@redhat.com> Message-ID: <5257ACFD.6030306@redhat.com> On 10/10/2013 05:45 PM, Jan Cholasta wrote: > Hi, > > On 9.10.2013 13:31, Martin Kosek wrote: >> Change re-initialize command to consider memberOf fixup task only >> for non-winsync replication agreements. This patch also includes >> few fixes for DsInstance to properly set realm and fqdn properties >> needed when connecting to LDAP. >> >> https://fedorahosted.org/freeipa/ticket/3854 >> > > - self.realm_name = realm_name > + self.realm_name = self.realm = realm_name > > I think one realm property is enough. Can you please change dsinstance to use > .realm instead of .realm_name? > > Honza > I did not get too much into refactoring, but this one is simple. Attaching updating patches. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-426-2-winsync-re-initialize-should-not-run-memberof-fixup-.patch Type: text/x-patch Size: 1752 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-430-use-consistent-realm-name-in-cainstance-and-dsinstan.patch Type: text/x-patch Size: 7723 bytes Desc: not available URL: From mkosek at redhat.com Fri Oct 11 07:50:29 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 11 Oct 2013 09:50:29 +0200 Subject: [Freeipa-devel] [PATCH] 427 Remove --no-serial-autoincrement In-Reply-To: <52569B08.7090008@redhat.com> References: <52556655.4090908@redhat.com> <525693DA.70605@redhat.com> <52569754.6040908@redhat.com> <52569B08.7090008@redhat.com> Message-ID: <5257ADC5.5000500@redhat.com> On 10/10/2013 02:18 PM, Jan Cholasta wrote: > On 10.10.2013 14:02, Martin Kosek wrote: >> On 10/10/2013 01:47 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 9.10.2013 16:21, Martin Kosek wrote: >>>> Deprecate this option and do not offer it in installation tools. >>>> Without this option enabled, advanced DNS features like DNSSEC >>>> would not work. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3962 >>>> >>> >>> Is there a reason not to remove serial_autoincrement from bindinstance? It is >>> used only to set serial_autoincrement value in named.conf template, which can >>> be hard-coded to "yes" in the template file. >>> >>> Honza >>> >> >> Probably not, attaching updated patch. >> >> Martin >> > > ACK. > Pushed to master, ipa-3-3. Martin From mkosek at redhat.com Fri Oct 11 07:52:33 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 11 Oct 2013 09:52:33 +0200 Subject: [Freeipa-devel] [PATCH] 428 PKI installation on replica failing due to missing proxy conf In-Reply-To: <5256AA96.1050601@redhat.com> References: <5255BEC5.2010807@redhat.com> <5256AA96.1050601@redhat.com> Message-ID: <5257AE41.9010402@redhat.com> On 10/10/2013 03:24 PM, Jan Cholasta wrote: > Hi, > > On 9.10.2013 22:38, Martin Kosek wrote: >> Proxy configuration was not detected correctly. Both >> ipa-pki-proxy.conf and ipa.conf need to be in place and httpd >> restarted to be able to check it's status. >> >> https://fedorahosted.org/freeipa/ticket/3964 >> >> ---- >> >> I had to install and reinstall PKI a lot before I found the real root >> cause. Both >> ipa-replica-install --setup-ca >> and >> ipa-ca-install >> should be working now. >> > > ACK. > Pushed to master, ipa-3-3. Martin From jcholast at redhat.com Fri Oct 11 08:00:51 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 11 Oct 2013 10:00:51 +0200 Subject: [Freeipa-devel] [PATCH] 426, 430 Winsync re-initialize should not run memberOf fixup task In-Reply-To: <5257ACFD.6030306@redhat.com> References: <52553E7F.5070204@redhat.com> <5256CBA1.9050209@redhat.com> <5257ACFD.6030306@redhat.com> Message-ID: <5257B033.8050600@redhat.com> On 11.10.2013 09:47, Martin Kosek wrote: > On 10/10/2013 05:45 PM, Jan Cholasta wrote: >> Hi, >> >> On 9.10.2013 13:31, Martin Kosek wrote: >>> Change re-initialize command to consider memberOf fixup task only >>> for non-winsync replication agreements. This patch also includes >>> few fixes for DsInstance to properly set realm and fqdn properties >>> needed when connecting to LDAP. >>> >>> https://fedorahosted.org/freeipa/ticket/3854 >>> >> >> - self.realm_name = realm_name >> + self.realm_name = self.realm = realm_name >> >> I think one realm property is enough. Can you please change dsinstance to use >> .realm instead of .realm_name? >> >> Honza >> > > I did not get too much into refactoring, but this one is simple. Attaching > updating patches. > > Martin > Thanks, ACK. -- Jan Cholasta From mkosek at redhat.com Fri Oct 11 08:12:18 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 11 Oct 2013 10:12:18 +0200 Subject: [Freeipa-devel] [PATCH] 426, 430 Winsync re-initialize should not run memberOf fixup task In-Reply-To: <5257B033.8050600@redhat.com> References: <52553E7F.5070204@redhat.com> <5256CBA1.9050209@redhat.com> <5257ACFD.6030306@redhat.com> <5257B033.8050600@redhat.com> Message-ID: <5257B2E2.9040807@redhat.com> On 10/11/2013 10:00 AM, Jan Cholasta wrote: > On 11.10.2013 09:47, Martin Kosek wrote: >> On 10/10/2013 05:45 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 9.10.2013 13:31, Martin Kosek wrote: >>>> Change re-initialize command to consider memberOf fixup task only >>>> for non-winsync replication agreements. This patch also includes >>>> few fixes for DsInstance to properly set realm and fqdn properties >>>> needed when connecting to LDAP. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3854 >>>> >>> >>> - self.realm_name = realm_name >>> + self.realm_name = self.realm = realm_name >>> >>> I think one realm property is enough. Can you please change dsinstance to use >>> .realm instead of .realm_name? >>> >>> Honza >>> >> >> I did not get too much into refactoring, but this one is simple. Attaching >> updating patches. >> >> Martin >> > > Thanks, ACK. > Pushed to master, ipa-3-3. Martin From pvoborni at redhat.com Fri Oct 11 10:55:28 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 11 Oct 2013 12:55:28 +0200 Subject: [Freeipa-devel] [PATCH][DOC] 0007 Removed trailing whitespaces In-Reply-To: <1380635343.2140.14.camel@unused-4-145.brq.redhat.com> References: <1380635343.2140.14.camel@unused-4-145.brq.redhat.com> Message-ID: <5257D920.8050900@redhat.com> On 10/01/2013 03:49 PM, Martin Basti wrote: > Patch removes trailing whitespaces in user guide from chapter 6 to end > > Whitespaces was removed by: > sed 's/[ \t]\+$//' > > ACK and pushed to master -- Petr Vobornik From abokovoy at redhat.com Fri Oct 11 11:20:56 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 11 Oct 2013 14:20:56 +0300 Subject: [Freeipa-devel] [PATCH 0118] Do not create separate ranges for subdomains in case of POSIX trust In-Reply-To: <5256BF1F.3050608@redhat.com> References: <5256BF1F.3050608@redhat.com> Message-ID: <20131011112056.GE30236@redhat.com> On Thu, 10 Oct 2013, Tomas Babej wrote: >Hi, > >This is a fix for a bug I found related to the subdomains code while >working on the AD Continuous Integration testing. Thanks. ACK, now I can see no ranges created for the subdomains if there is POSIX range in use for the forest root. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Oct 11 11:22:48 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 11 Oct 2013 14:22:48 +0300 Subject: [Freeipa-devel] [PATCHES 114-117] Do proper cleanup after ipa-adtrust-install In-Reply-To: <52557FF1.8020801@redhat.com> References: <52557FF1.8020801@redhat.com> Message-ID: <20131011112248.GF30236@redhat.com> On Wed, 09 Oct 2013, Tomas Babej wrote: > Hi, > > the following patchset contains fixes for > https://fedorahosted.org/freeipa/ticket/3479 . > > With it applied, you should be able to establish a trust on a > reinstalled IPA master that had a trust established. ACK. Small comment -- not "that had a trust established" but rather "where ipa-adtrust-install has been ran". You don't need to establish trust, only configure the system to handle trusts. -- / Alexander Bokovoy From jfenal at gmail.com Fri Oct 11 12:57:03 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Fri, 11 Oct 2013 14:57:03 +0200 Subject: [Freeipa-devel] [PATCH] [DOC] Remove SELinux user paragraph replacement In-Reply-To: <5257A422.4050603@redhat.com> References: <5257A422.4050603@redhat.com> Message-ID: 2013/10/11 Martin Kosek : > On 10/10/2013 06:37 PM, J?r?me Fenal wrote: >> Attached. >> Replaced the dodgy sentence with Martin's one. >> >> Regards, >> >> J. > > Thanks J?r?me for the patch, I have few comments though: > > 1) One more note for patch format, please use the following command to extract > your patch from git: > > $ git format-patch -M -C --patience --full-index -1 > > Source: http://www.freeipa.org/page/Contribute/Patch_Format > > It will maker then easier for us to merge the patch to main git tree. Done. > 2) I think we should not mix indentation with spaces and tabs Switched back to noet in vim, and fixed. > 3) Shouldn't we also remove the now redundant previous paragraph? A change like > that: > > - > - A specific user or host can be removed from an > SELinux map by using either the selinuxusermap-remove-host > or selinuxusermap-remove-user comma... > - Done as well, working while tired on doc cannot be spotted by a compiler... :) Let me know. -- J?r?me Fenal -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jfenal-0002-Fix-broken-sentence-for-selinuxusermap-remove.patch Type: application/octet-stream Size: 1503 bytes Desc: not available URL: From pspacek at redhat.com Fri Oct 11 13:35:12 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 11 Oct 2013 15:35:12 +0200 Subject: [Freeipa-devel] [PATCH 0197-0200] Message-ID: <5257FE90.2080905@redhat.com> Hello, update documentation and schema files for upcoming version 4.0. This fixes typo in schema file: https://fedorahosted.org/bind-dyndb-ldap/ticket/121 Have a nice weekend! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0197-Remove-persistent-search-and-zone_refresh-attributes.patch Type: text/x-patch Size: 2487 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0198-Fix-typo-in-LDAP-schema.patch Type: text/x-patch Size: 832 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0199-Update-NEWS-for-upcoming-4.0-release.patch Type: text/x-patch Size: 2066 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0200-Bump-NVR-to-4.0.patch Type: text/x-patch Size: 1196 bytes Desc: not available URL: From pspacek at redhat.com Fri Oct 11 13:35:45 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 11 Oct 2013 15:35:45 +0200 Subject: [Freeipa-devel] [PATCH 0197-0200] Preparation for bind-dyndb-ldap release 4.0 Message-ID: <5257FEB1.6020306@redhat.com> Hello, update documentation and schema files for upcoming version 4.0. This fixes typo in schema file: https://fedorahosted.org/bind-dyndb-ldap/ticket/121 Have a nice weekend! -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0197-Remove-persistent-search-and-zone_refresh-attributes.patch Type: text/x-patch Size: 2487 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0198-Fix-typo-in-LDAP-schema.patch Type: text/x-patch Size: 832 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0199-Update-NEWS-for-upcoming-4.0-release.patch Type: text/x-patch Size: 2066 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0200-Bump-NVR-to-4.0.patch Type: text/x-patch Size: 1196 bytes Desc: not available URL: From simo at redhat.com Fri Oct 11 15:14:06 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 11 Oct 2013 11:14:06 -0400 Subject: [Freeipa-devel] [PATCH] Split out function Message-ID: <1381504446.2684.86.camel@willson.li.ssimo.org> During the Kerberos interop we found out we are still missing to generate a Ms-PAc field the MS testsuite wants to see. I did some work in the past to create the UPN_DNS_INFO buffer in the samba IDL files but it has been recently reverted upstream due to some issues it created for Samba4 and is being reworked by G?nther and Metze. However I still went ahead and created a prototype patch that would use the new union buffer once it is released. In doing that I realize recent changes made it difficult to add the buffer so I created a patch that splits out some checks. I would like to push patch 0001, so that in the future we will also be able to push patch 0002, however 0002 cannot be pushed now as we miss the necessary code in the samba packages. So 0002 is added here only for reference to understand why I coded 0001 the way I did. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-mspac-Split-retrieval-of-basic-account-data.patch Type: text/x-patch Size: 9651 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-mspac-Add-support-for-UPN_DNS_INFO-buffer.patch Type: text/x-patch Size: 2590 bytes Desc: not available URL: From jfenal at gmail.com Sat Oct 12 17:28:07 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Sat, 12 Oct 2013 19:28:07 +0200 Subject: [Freeipa-devel] [DOC] [PATCH] 0003 Remove bogus paragraph Message-ID: In reformatting the last patch (which included revert my own repo), the removal of the paragraph was lost. Now removing it. Really ;) -- J?r?me Fenal -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jfenal-0003-Remove-bogus-paragraph.patch Type: application/octet-stream Size: 1249 bytes Desc: not available URL: From mkosek at redhat.com Mon Oct 14 08:10:15 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 14 Oct 2013 10:10:15 +0200 Subject: [Freeipa-devel] [PATCH 0118] Do not create separate ranges for subdomains in case of POSIX trust In-Reply-To: <20131011112056.GE30236@redhat.com> References: <5256BF1F.3050608@redhat.com> <20131011112056.GE30236@redhat.com> Message-ID: <525BA6E7.1060603@redhat.com> On 10/11/2013 01:20 PM, Alexander Bokovoy wrote: > On Thu, 10 Oct 2013, Tomas Babej wrote: > >> Hi, >> >> This is a fix for a bug I found related to the subdomains code while working >> on the AD Continuous Integration testing. > Thanks. ACK, now I can see no ranges created for the subdomains if there > is POSIX range in use for the forest root. > Pushed to master, ipa-3-3. Martin From mkosek at redhat.com Mon Oct 14 08:18:23 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 14 Oct 2013 10:18:23 +0200 Subject: [Freeipa-devel] [PATCH] [DOC] Remove SELinux user paragraph replacement In-Reply-To: References: <5257A422.4050603@redhat.com> Message-ID: <525BA8CF.1040702@redhat.com> On 10/11/2013 02:57 PM, J?r?me Fenal wrote: > 2013/10/11 Martin Kosek : >> On 10/10/2013 06:37 PM, J?r?me Fenal wrote: >>> Attached. >>> Replaced the dodgy sentence with Martin's one. >>> >>> Regards, >>> >>> J. >> >> Thanks J?r?me for the patch, I have few comments though: >> >> 1) One more note for patch format, please use the following command to extract >> your patch from git: >> >> $ git format-patch -M -C --patience --full-index -1 >> >> Source: http://www.freeipa.org/page/Contribute/Patch_Format >> >> It will maker then easier for us to merge the patch to main git tree. > > Done. > >> 2) I think we should not mix indentation with spaces and tabs > > Switched back to noet in vim, and fixed. > >> 3) Shouldn't we also remove the now redundant previous paragraph? A change like >> that: >> >> - >> - A specific user or host can be removed from an >> SELinux map by using either the selinuxusermap-remove-host >> or selinuxusermap-remove-user comma... >> - > > Done as well, working while tired on doc cannot be spotted by a compiler... :) > > Let me know. > Thanks J?r?me, the patch is perfect now. Unfortunately I see that I cannot push it as Martin Basti's commit 0d48ee15 already fixes this spot. But please don't be afraid, there will be many other opportunities to use the newly gained FreeIPA-doc-contribution skill :) Thanks for help, Martin From mkosek at redhat.com Mon Oct 14 08:23:02 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 14 Oct 2013 10:23:02 +0200 Subject: [Freeipa-devel] [DOC] [PATCH] 0003 Remove bogus paragraph In-Reply-To: References: Message-ID: <525BA9E6.4010204@redhat.com> On 10/12/2013 07:28 PM, J?r?me Fenal wrote: > In reformatting the last patch (which included revert my own repo), > the removal of the paragraph was lost. > > Now removing it. Really ;) Ah, this is the patch I was looking for :) ACK! Pushed to master. Martin From jcholast at redhat.com Mon Oct 14 08:59:40 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 14 Oct 2013 10:59:40 +0200 Subject: [Freeipa-devel] [PATCHES] 106-113 Access raw LDAP values directly from LDAPEntry In-Reply-To: <52565B09.2090909@redhat.com> References: <512E26E1.5010302@redhat.com> <52419527.70200@redhat.com> <524426F5.6010006@redhat.com> <525544A3.6080807@redhat.com> <52565B09.2090909@redhat.com> Message-ID: <525BB27C.1000507@redhat.com> On 10.10.2013 09:45, Jan Cholasta wrote: > On 9.10.2013 13:57, Petr Viktorin wrote: >> On 09/26/2013 02:22 PM, Jan Cholasta wrote: >>> On 24.9.2013 15:35, Jan Cholasta wrote: >>>> On 27.2.2013 16:31, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> these patches add the ability to access and manipulate raw attribute >>>>> values as they are returned from python-ldap to the LDAPEntry class. >>>>> This is useful for comparing entries, computing modlists for the >>>>> modify >>>>> operation, deleting values that don't match the syntax of an >>>>> attribute, >>>>> etc., because we don't need to care what syntax does a particular >>>>> attribute use, or what Python type is used for it in the framework >>>>> (raw >>>>> values are always list of str). It should also make interaction with >>>>> non-389 DS LDAP servers easier in the framework. >>>>> >>>>> (It might be too late for this kind of changes to get into 3.2 now, >>>>> I'm >>>>> posting these patches mainly so that you are aware that they exist.) >>>>> >>>>> Honza >>>>> >>>> >>>> This is now planned for 3.4: >>>> >>>> >>>> I fixed some issues in these patches and refined the API. Updated >>>> patches attached. >>>> >>>> Also added a patch to use raw values when adding new entries and a >>>> patch >>>> which refines LDAPEntry.single_value, so that it is consistent with the >>>> rest of the changes introduced in the patches. >>>> >>>> Patch 110 will probably be dropped in favor of Petr Viktorin's schema >>>> update patches, but I included it anyway. >>>> >>>> Incidentally, this also fixes >>>> and possibly also >>>> . >>>> >>>> Honza >>>> >>> >>> Noticed a couple more issues and fixed them. Updated patches attached. >>> >>> Honza >> >> Thanks for the patches! >> >> >> 106. Make LDAPEntry a wrapper around dict rather than a dict subclass. >> >> ipapython/ipaldap.py:847: >> warning: 1 line adds whitespace errors. >> >> if isinstance(_obj, LDAPEntry): >> + data = dict(_obj._data) >> orig = _obj._orig >> >> Is this necessary? `self.update(_obj)` is done later. > > Probably not. But it's removed in patch 109. > >> >> >> def __contains__(self, name): >> - return self._names.has_key(self._attr_name(name)) >> + return self._names.has_key(name) >> >> has_key() is deprecated for dict, it would make sense to prefer `name in >> self._names` for CIDict too. > > Sure, this line is from before CIDict got __contains__. > >> >> + def __eq__(self, other): >> + if not isinstance(other, LDAPEntry): >> + return NotImplemented >> + if self._dn != other._dn: >> + return False >> + return super(LDAPEntry, self).__eq__(other) >> >> I don't think equality checking makes sense on a LDAPEntry, where you >> might have different capitalizations/variants of attribute names, >> different _orig, or a different set of attributes loaded on the same >> entry. It's not obvious which of those differences should make the >> entries inequal. >> I'd just base it on identity (`self is other`). > > Right, I'm not sure why I even did it this way. But I remember seeing > some code that did comparison of entries with ==... > >> >> def __iter__(self): >> yield self._dn >> yield self >> >> This makes the whole thing sort of hackish -- we need to reimplement >> everything in MutableMapping that uses iter() internally :( >> Hopefully we can get rid of it soon. > > Yes, it's a shame MutableMapping uses iter() instead of iterkeys(). > >> I'd welcome FIXME comments on whatever is reimplemented for this reason. > > I thought the comment above __iter__ would be enough. Apparently I was > wrong. > >> >> >> 107. Introduce IPASimpleLDAPObject.decode method for decoding LDAP >> values. >> >> Can you put in a docstring? > > OK. > >> >> >> >> 108. Always use lists for values in LDAPEntry internally. >> >> @@ -698,6 +701,7 @@ class LDAPEntry(collections.MutableMapping): >> >> result._names = deepcopy(self._names) >> result._data = deepcopy(self._data) >> + result._not_list = deepcopy(self._not_list) >> if self._orig is not self: >> result._orig = self._orig.clone() >> >> It's better to use set() than deepcopy() for a set of strings. > > Right. > >> >> >> 109. Decode and encode attribute values in LDAPEntry on demand. >> >> The syncing looks rather over-engineered to me. >> Did you consider a custom MutableSequence for the values? >> I think it would be much cleaner in the end than merging two sets of >> changes together. > > I'm not entirely happy about it either, but it works. I did consider a > custom sequence type, but I didn't feel like it was the right time to > this kind of change in this patchset. Unlike the (DN, dict) -> LDAPEntry > transition, this change won't be backward compatible and there is a lot > of isinstance(value, list) and entry[attr] = list() kind of things in > the framework code. > >> >> I think it would also help (in the future?) to make the value lists more >> set-like, since the order doesn't matter. > > +1 > > Honza > Updated patches attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-106.4-Make-LDAPEntry-a-wrapper-around-dict-rather-than-a-d.patch Type: text/x-patch Size: 8565 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-107.4-Introduce-IPASimpleLDAPObject.decode-method-for-deco.patch Type: text/x-patch Size: 3810 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-108.4-Always-use-lists-for-values-in-LDAPEntry-internally.patch Type: text/x-patch Size: 3810 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-109.4-Decode-and-encode-attribute-values-in-LDAPEntry-on-d.patch Type: text/x-patch Size: 16766 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-110.4-Make-sure-attributeTypes-updates-are-done-before-obj.patch Type: text/x-patch Size: 1088 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-111.4-Remove-legacy-toDict-and-origDataDict-methods-of-LDA.patch Type: text/x-patch Size: 4878 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-112.4-Store-encoded-attribute-values-from-search-results-d.patch Type: text/x-patch Size: 886 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-113.4-Use-encoded-values-from-entry-objects-directly-when-.patch Type: text/x-patch Size: 3253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-121.4-Use-encoded-values-from-entry-objects-directly-when-.patch Type: text/x-patch Size: 1478 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-169.4-Turn-LDAPEntry.single_value-into-a-dictionary-like-p.patch Type: text/x-patch Size: 49606 bytes Desc: not available URL: From jfenal at gmail.com Mon Oct 14 09:06:25 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Mon, 14 Oct 2013 11:06:25 +0200 Subject: [Freeipa-devel] [PATCH] [DOC] Remove SELinux user paragraph replacement In-Reply-To: <525BA8CF.1040702@redhat.com> References: <5257A422.4050603@redhat.com> <525BA8CF.1040702@redhat.com> Message-ID: 2013/10/14 Martin Kosek : > Thanks J?r?me, the patch is perfect now. Unfortunately I see that I cannot push > it as Martin Basti's commit 0d48ee15 already fixes this spot. > > But please don't be afraid, there will be many other opportunities to use the > newly gained FreeIPA-doc-contribution skill :) Great, thank you. And don't worry, I've got a few fixes I have to send on other files as well. Just need to find some time to prepare those using my new superpowers ;) Regards, J. -- J?r?me Fenal From mkosek at redhat.com Mon Oct 14 09:16:27 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 14 Oct 2013 11:16:27 +0200 Subject: [Freeipa-devel] [PATCHES 114-117] Do proper cleanup after ipa-adtrust-install In-Reply-To: <20131011112248.GF30236@redhat.com> References: <52557FF1.8020801@redhat.com> <20131011112248.GF30236@redhat.com> Message-ID: <525BB66B.3010007@redhat.com> On 10/11/2013 01:22 PM, Alexander Bokovoy wrote: > On Wed, 09 Oct 2013, Tomas Babej wrote: > >> Hi, >> >> the following patchset contains fixes for >> https://fedorahosted.org/freeipa/ticket/3479 . >> >> With it applied, you should be able to establish a trust on a reinstalled IPA >> master that had a trust established. > ACK. > > Small comment -- not "that had a trust established" but rather "where > ipa-adtrust-install has been ran". You don't need to establish > trust, only configure the system to handle trusts. Pushed to master, ipa-3-3. I just fix a typo in 116 before pushing: s/ipa-adtrust-instal/ipa-adtrust-install/ Martin From tbabej at redhat.com Mon Oct 14 14:28:49 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 14 Oct 2013 16:28:49 +0200 Subject: [Freeipa-devel] [PATCH 0119] ipatests: Extend the order plugin to properly handle inheritance Message-ID: <525BFFA1.60207@redhat.com> Hi, When trying to create a new ordered test case by inheriting from already defined test case, by overriding few of its methods, the execution order of the tests is as follows: - first all non-overriden test methods from the parent test class - then all overriden tests methods This patch makes sure that methods are executed in the logical order, that is, the order defined in the parent class. -- 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-0119-ipatests-Extend-the-order-plugin-to-properly-handle-.patch Type: text/x-patch Size: 2234 bytes Desc: not available URL: From tbabej at redhat.com Mon Oct 14 15:47:42 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 14 Oct 2013 17:47:42 +0200 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests In-Reply-To: <523B1F0F.3010101@redhat.com> References: <52370B90.2030009@redhat.com> <52381625.3010607@redhat.com> <52386896.3000909@redhat.com> <523B1F0F.3010101@redhat.com> Message-ID: <525C121E.3080406@redhat.com> Hi, Sending the updated version of the patchset. It includes many fixes, plus incorporations of the comments by the QE. Tests are now broken down into multiple test cases. This requires my patch 119. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0106-6-ipatests-Add-AD-integration-test-case.patch Type: text/x-patch Size: 7728 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0105-6-ipatests-Add-AD-integration-related-tasks.patch Type: text/x-patch Size: 9584 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0104-6-ipatests-Add-WinHost-class.patch Type: text/x-patch Size: 1675 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0103-6-ipatests-Create-util-module-for-ipatests.patch Type: text/x-patch Size: 2506 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0102-6-ipatests-Extend-IntegrationTest-with-multiple-AD-dom.patch Type: text/x-patch Size: 2786 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0101-6-ipatests-Extend-domain-object-with-ad-role-support-a.patch Type: text/x-patch Size: 3151 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0100-6-ipatests-Add-Active-Directory-support-to-configurati.patch Type: text/x-patch Size: 5280 bytes Desc: not available URL: From mbasti at redhat.com Tue Oct 15 09:37:52 2013 From: mbasti at redhat.com (Martin Basti) Date: Tue, 15 Oct 2013 11:37:52 +0200 Subject: [Freeipa-devel] [PATCH] 0010 ipa-client-install does not clean up /etc/ipa/ca.crt after a failed attempt Message-ID: <1381829872.2237.1.camel@unused-4-145.brq.redhat.com> Added warning if cert. exists (client) https://fedorahosted.org/freeipa/ticket/3944 -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0010-Added-warning-if-cert-etc-ipa-ca.cert-exists.patch Type: text/x-patch Size: 1313 bytes Desc: not available URL: From akrivoka at redhat.com Tue Oct 15 11:51:24 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 15 Oct 2013 13:51:24 +0200 Subject: [Freeipa-devel] [PATCH] 448 Load updated Web UI files after server upgrade In-Reply-To: <524BF95D.2000006@redhat.com> References: <5220B880.9040902@redhat.com> <524530C7.9020204@redhat.com> <524BF95D.2000006@redhat.com> Message-ID: <525D2C3C.9040606@redhat.com> On 10/02/2013 12:45 PM, Petr Vobornik wrote: > On 09/27/2013 09:16 AM, Ana Krivokapic wrote: >> On 08/30/2013 05:21 PM, Petr Vobornik wrote: > > snip > >>> >>> https://fedorahosted.org/freeipa/ticket/3798 >>> >> >> I tested the patch and it seems to work fine. Code-wise it looks good as well. >> >> Nitpick: There is an unused function 'updated()' in the new loader.js.in file. >> > > Unused function removed. Updated patch attached. ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From mbasti at redhat.com Tue Oct 15 13:16:33 2013 From: mbasti at redhat.com (Martin Basti) Date: Tue, 15 Oct 2013 15:16:33 +0200 Subject: [Freeipa-devel] [PATCH][DOC] 0011 Chapter 10 DNS Message-ID: <1381842993.6890.1.camel@unused-4-145.brq.redhat.com> Patch attached -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0011-Chapter-10-DNS-update.patch Type: text/x-patch Size: 868361 bytes Desc: not available URL: From akrivoka at redhat.com Tue Oct 15 13:30:09 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 15 Oct 2013 15:30:09 +0200 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <524C0F70.809@redhat.com> References: <523049A5.10208@redhat.com> <523722A3.7060700@redhat.com> <524C0F70.809@redhat.com> Message-ID: <525D4361.7000000@redhat.com> On 10/02/2013 02:20 PM, Petr Vobornik wrote: > On 09/16/2013 05:24 PM, Ana Krivokapic wrote: >> On 09/11/2013 12:44 PM, Petr Vobornik wrote: >>> Hello, >>> > > snip > >>> >> >> I looked into the documentation effort and (ruby dependency discussion aside) I >> don't have any major objections. I like how the generated pages look, and they >> are intuitive and easy to navigate. >> >> A couple of nitpicks: >> >> 1) There are some spelling mistakes (e.g. Apllication_controller) > Fixed >> >> 2) Bulleted lists are not rendered nicely in the html output (see for example >> the doc string for _base.Builder property 'string_mode'. I think a list needs to >> look like this in the source code: >> >> /** >> * This is a list: >> * >> * - 'element1' >> * - 'element2' >> * >> */ >> >> as opposed to this: >> >> /** >> * This is a list: >> * - 'element1' >> * - 'element2' >> */ >> > > Fixed on many places. Also fixed the same issue in some code examples. > > - _base.Builder doc was heavily revised > - added doc comments to ./plugin_loader > > All patches are rebased but just patches 452 and 453 are changed. Looks good, ACK. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From jfenal at gmail.com Tue Oct 15 14:59:07 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Tue, 15 Oct 2013 16:59:07 +0200 Subject: [Freeipa-devel] [PATCH] [DOC] 0003 Split text commands & descriptions into XML tables. Message-ID: -- J?r?me Fenal -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jfenal-0003-Split-commands-in-proper-tables.patch Type: application/octet-stream Size: 53004 bytes Desc: not available URL: From mkosek at redhat.com Tue Oct 15 15:22:00 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 15 Oct 2013 17:22:00 +0200 Subject: [Freeipa-devel] [PATCH] [DOC] 0003 Split text commands & descriptions into XML tables. In-Reply-To: References: Message-ID: <525D5D98.7050005@redhat.com> Thanks. It would be ideal, if this table is (in future) generated somehow semi-automatically as practically all this info can be gathered from FreeIPA code. But for now, this is great. I see some issues with the patch though: 1) Whitespaces before tabs I fixed some of them with sed -i "s/\+\t$/+/g" /tmp/freeipa-jfenal-0003-Split-commands-in-proper-tables.patch Bug there is the second issue: 2) Test&build fails: $ git am /tmp/freeipa-jfenal-0003-Split-commands-in-proper-tables-1.patch Applying: Split commands in proper tables /home/mkosek/freeipa-docs/.git/rebase-apply/patch:211: space before tab in indent. /home/mkosek/freeipa-docs/.git/rebase-apply/patch:212: space before tab in indent. /home/mkosek/freeipa-docs/.git/rebase-apply/patch:213: space before tab in indent. automountkey-add /home/mkosek/freeipa-docs/.git/rebase-apply/patch:214: space before tab in indent. /home/mkosek/freeipa-docs/.git/rebase-apply/patch:215: space before tab in indent. warning: squelched 1849 whitespace errors warning: 1854 lines add whitespace errors. $ make test publican build --config publican.cfg --langs en-US --formats test ... Processing file tmp/en-US/xml_tmp/Sudo.xml -> tmp/en-US/xml/Sudo.xml Processing file tmp/en-US/xml_tmp/Tools.xml -> tmp/en-US/xml/Tools.xml *ERROR: Fatal Table Error* Table (Can't identify table) contains invalid data Attribute cols (2) does not match number of entry elements (XML::Element=HASH(0x3889db0)) at /usr/share/perl5/vendor_perl/Publican/Builder.pm line 801. make: *** [test] Error 255 Martin From akrivoka at redhat.com Tue Oct 15 16:09:35 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 15 Oct 2013 18:09:35 +0200 Subject: [Freeipa-devel] [PATCHES] 0068-0070 Automember rebuild membership In-Reply-To: <52493029.7060501@redhat.com> References: <523AFC1E.4080005@redhat.com> <52407D33.6000009@redhat.com> <52458177.30301@redhat.com> <52458455.6040403@redhat.com> <52493029.7060501@redhat.com> Message-ID: <525D68BF.9050901@redhat.com> On 09/30/2013 10:02 AM, Petr Viktorin wrote: > On 09/27/2013 03:12 PM, Martin Kosek wrote: >> On 09/27/2013 03:00 PM, Jan Cholasta wrote: >>> On 23.9.2013 19:41, Ana Krivokapic wrote: >>>> On 09/19/2013 03:29 PM, Ana Krivokapic wrote: >> ... >>> Patch 69: >>> >>> I think the changes in the update file should be also done in the >>> right LDIF >>> files in install/share, though I don't know what is the recent >>> consensus on this. >>> >>> >>> Honza >>> >> >> Last time I checked, we used to do the change both in LDIF and update >> file. Just to avoid the LDIF become obsolete. >> >> Martin > > Rob recently said his preference is to move everything from LDIF to updates, > and out of the the LDIF files: > http://www.redhat.com/archives/freeipa-devel/2013-September/msg00106.html > > I would agree, having two places with the same information is redundant and > error-prone. > Thanks Honza for the review. I incorporated your suggestions in this updated patchset. I attached all the patches for more convenient reviewing, but only patches 68 and 70 have changed. I haven't done any changes in the LDIF files since the consensus seems to be not to do that. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0068-03-Add-automember-rebuild-command.patch Type: text/x-patch Size: 7090 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0069-02-Add-permissions-for-automember-rebuild-command.patch Type: text/x-patch Size: 2389 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0070-03-Add-unit-tests-for-automember-rebuild-command.patch Type: text/x-patch Size: 23920 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0071-Fix-error-message-when-adding-duplicate-automember-r.patch Type: text/x-patch Size: 3819 bytes Desc: not available URL: From jfenal at gmail.com Tue Oct 15 16:19:06 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Tue, 15 Oct 2013 18:19:06 +0200 Subject: [Freeipa-devel] [PATCH] [DOC] 0003 Split text commands & descriptions into XML tables. In-Reply-To: <525D5D98.7050005@redhat.com> References: <525D5D98.7050005@redhat.com> Message-ID: kk2013/10/15 Martin Kosek : > Thanks. It would be ideal, if this table is (in future) generated somehow > semi-automatically as practically all this info can be gathered from FreeIPA > code. But for now, this is great. > > I see some issues with the patch though: > > 1) Whitespaces before tabs OK, I fixed my attached script my removing leading spaces in the second part of s///. > I fixed some of them with > sed -i "s/\+\t$/+/g" /tmp/freeipa-jfenal-0003-Split-commands-in-proper-tables.patch > > Bug there is the second issue: > > 2) Test&build fails: > > $ git am /tmp/freeipa-jfenal-0003-Split-commands-in-proper-tables-1.patch > Applying: Split commands in proper tables > /home/mkosek/freeipa-docs/.git/rebase-apply/patch:211: space before tab in indent. > > /home/mkosek/freeipa-docs/.git/rebase-apply/patch:212: space before tab in indent. > > /home/mkosek/freeipa-docs/.git/rebase-apply/patch:213: space before tab in indent. > automountkey-add > /home/mkosek/freeipa-docs/.git/rebase-apply/patch:214: space before tab in indent. > > /home/mkosek/freeipa-docs/.git/rebase-apply/patch:215: space before tab in indent. > > warning: squelched 1849 whitespace errors > warning: 1854 lines add whitespace errors. Will look into that. Side question, how did you get the initial text command list? Regards, J. -- J?r?me Fenal -------------- next part -------------- A non-text attachment was scrubbed... Name: t.pl Type: application/octet-stream Size: 323 bytes Desc: not available URL: From abokovoy at redhat.com Tue Oct 15 19:30:23 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 15 Oct 2013 22:30:23 +0300 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests In-Reply-To: <525C121E.3080406@redhat.com> References: <52370B90.2030009@redhat.com> <52381625.3010607@redhat.com> <52386896.3000909@redhat.com> <523B1F0F.3010101@redhat.com> <525C121E.3080406@redhat.com> Message-ID: <20131015192925.GA23601@redhat.com> On Mon, 14 Oct 2013, Tomas Babej wrote: >+def estabilish_trust_with_ad(master, ad, extra_args=[]): >+ """ >+ Estabilishes trust with Active Directory. Trust type is detected depending >+ on the presence of SfU (Services for Unix) support on the AD. >+ >+ Use extra arguments to pass extra arguments to the trust-add command, such >+ as --range-type="ipa-ad-trust" to enfroce a particular range type. >+ """ >+ >+ # Force KDC to reload MS-PAC info by trying to get TGT for HTTP >+ master.run_command(['kinit', '-kt', '/etc/httpd/conf/ipa.keytab', >+ 'HTTP/%s' % master.hostname]) It would be good to actually run 'kdestroy -A' before 'kinit' so that we don't have any left overs. >+ master.run_command(['systemctl', 'restart', 'krb5kdc.service']) >+ >+ kinit_admin(master) Same here. >+ master.run_command(['klist']) >+ master.run_command(['smbcontrol', 'all', 'debug', '100']) >+ assert util.run_repeatedly(master, >+ ['ipa', 'trust-add', >+ '--type', 'ad', ad.domain.name, >+ '--admin', 'Administrator', >+ '--password'] + extra_args, >+ stdin_text=master.config.ad_admin_password) >+ master.run_command(['smbcontrol', 'all', 'debug', '1']) >+ clear_sssd_cache(master) >+ The rest looks fine although it could be nice to have generic description of what is expected from AD setup -- there is assumption of POSIX attributes being enabled in one of tests which is definitely not a default configuration. I'm here after reproducible configurations using different test lab (like running an Azure or EC2 cloud). I'm still not able to reproduce the issue with missing MS-PAC in admin's ticket when running 'ipa trust-add' in the test, though... -- / Alexander Bokovoy From mkosek at redhat.com Wed Oct 16 06:49:44 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Oct 2013 08:49:44 +0200 Subject: [Freeipa-devel] [PATCH] [DOC] 0003 Split text commands & descriptions into XML tables. In-Reply-To: References: <525D5D98.7050005@redhat.com> Message-ID: <525E3708.7050902@redhat.com> On 10/15/2013 06:19 PM, J?r?me Fenal wrote: > kk2013/10/15 Martin Kosek : >> Thanks. It would be ideal, if this table is (in future) generated somehow >> semi-automatically as practically all this info can be gathered from FreeIPA >> code. But for now, this is great. >> >> I see some issues with the patch though: >> >> 1) Whitespaces before tabs > > OK, I fixed my attached script my removing leading spaces in the > second part of s///. > >> I fixed some of them with >> sed -i "s/\+\t$/+/g" /tmp/freeipa-jfenal-0003-Split-commands-in-proper-tables.patch >> >> Bug there is the second issue: >> >> 2) Test&build fails: >> >> $ git am /tmp/freeipa-jfenal-0003-Split-commands-in-proper-tables-1.patch >> Applying: Split commands in proper tables >> /home/mkosek/freeipa-docs/.git/rebase-apply/patch:211: space before tab in indent. >> >> /home/mkosek/freeipa-docs/.git/rebase-apply/patch:212: space before tab in indent. >> >> /home/mkosek/freeipa-docs/.git/rebase-apply/patch:213: space before tab in indent. >> automountkey-add >> /home/mkosek/freeipa-docs/.git/rebase-apply/patch:214: space before tab in indent. >> >> /home/mkosek/freeipa-docs/.git/rebase-apply/patch:215: space before tab in indent. >> >> warning: squelched 1849 whitespace errors >> warning: 1854 lines add whitespace errors. > > Will look into that. > > Side question, how did you get the initial text command list? This is a work that Deon did, not sure if she used some automated way though... Martin From mbasti at redhat.com Wed Oct 16 08:10:59 2013 From: mbasti at redhat.com (Martin Basti) Date: Wed, 16 Oct 2013 10:10:59 +0200 Subject: [Freeipa-devel] [PATCH] 0010 ipa-client-install does not clean up /etc/ipa/ca.crt after a failed attempt In-Reply-To: <1381829872.2237.1.camel@unused-4-145.brq.redhat.com> References: <1381829872.2237.1.camel@unused-4-145.brq.redhat.com> Message-ID: <1381911059.2224.2.camel@unused-4-145.brq.redhat.com> On Tue, 2013-10-15 at 11:37 +0200, Martin Basti wrote: > Added warning if cert. exists (client) > > https://fedorahosted.org/freeipa/ticket/3944 > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Supress warning if user select /etc/ipa/ca.crt manually with --ca-cert-file option -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0010-2-Added-warning-if-cert-etc-ipa-ca.cert-exists.patch Type: text/x-patch Size: 1342 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 16 08:12:31 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Oct 2013 10:12:31 +0200 Subject: [Freeipa-devel] [PATCH] 431 Installer should always wait until CA starts up Message-ID: <525E4A6F.3000001@redhat.com> Patch for ticket 3964 changed the installer so that it does not always wait for CA if the proxy is not configured. However, it was found out that it may freeze an installation when a step subsequent after CA restart call the CA and receives no reply. Change the wait so that it always waits for CA to start up. If HTTP proxy is already configured, it should wait on port 443. If not, it should wait on local PKI port 8443. https://fedorahosted.org/freeipa/ticket/3973 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-431-installer-should-always-wait-until-ca-starts-up.patch Type: text/x-patch Size: 3278 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 16 08:36:40 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Oct 2013 10:36:40 +0200 Subject: [Freeipa-devel] [PATCH] 0010 ipa-client-install does not clean up /etc/ipa/ca.crt after a failed attempt In-Reply-To: <1381911059.2224.2.camel@unused-4-145.brq.redhat.com> References: <1381829872.2237.1.camel@unused-4-145.brq.redhat.com> <1381911059.2224.2.camel@unused-4-145.brq.redhat.com> Message-ID: <525E5018.9090900@redhat.com> On 10/16/2013 10:10 AM, Martin Basti wrote: > On Tue, 2013-10-15 at 11:37 +0200, Martin Basti wrote: >> Added warning if cert. exists (client) >> >> https://fedorahosted.org/freeipa/ticket/3944 1) Patch subject uses wrong path to cert 2) The warning seems to chatty to me: # ipa-client-install -p admin -w kokos123 Certificate '/etc/ipa/ca.crt' exists and will be used. Make sure that certificate is valid (or remove it), otherwise client will not be able to join. Discovery was successful! ... We just want to notify user that we are using the cert and what is the path (as this is something new to FreeIPA newbies), this seems easier to read to me: # ipa-client-install -p admin -w kokos123 Using existing certificate /etc/ipa/ca.crt Discovery was successful! ... Martin From mbasti at redhat.com Wed Oct 16 08:52:39 2013 From: mbasti at redhat.com (Martin Basti) Date: Wed, 16 Oct 2013 10:52:39 +0200 Subject: [Freeipa-devel] [PATCH] 0010 ipa-client-install does not clean up /etc/ipa/ca.crt after a failed attempt In-Reply-To: <525E5018.9090900@redhat.com> References: <1381829872.2237.1.camel@unused-4-145.brq.redhat.com> <1381911059.2224.2.camel@unused-4-145.brq.redhat.com> <525E5018.9090900@redhat.com> Message-ID: <1381913559.2224.3.camel@unused-4-145.brq.redhat.com> On Wed, 2013-10-16 at 10:36 +0200, Martin Kosek wrote: > On 10/16/2013 10:10 AM, Martin Basti wrote: > > On Tue, 2013-10-15 at 11:37 +0200, Martin Basti wrote: > >> Added warning if cert. exists (client) > >> > >> https://fedorahosted.org/freeipa/ticket/3944 > > 1) Patch subject uses wrong path to cert > Fixed > 2) The warning seems to chatty to me: > > # ipa-client-install -p admin -w kokos123 > Certificate '/etc/ipa/ca.crt' exists and will be used. Make sure that > certificate is valid (or remove it), otherwise client will not be able to join. > Discovery was successful! > ... > > We just want to notify user that we are using the cert and what is the path (as > this is something new to FreeIPA newbies), this seems easier to read to me: > > # ipa-client-install -p admin -w kokos123 > Using existing certificate /etc/ipa/ca.crt > Discovery was successful! > ... > Fixed > Martin -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0010-3-Added-warning-if-cert-etc-ipa-ca.crt-exists.patch Type: text/x-patch Size: 1171 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 16 08:56:32 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Oct 2013 10:56:32 +0200 Subject: [Freeipa-devel] [PATCH] 0010 ipa-client-install does not clean up /etc/ipa/ca.crt after a failed attempt In-Reply-To: <1381913559.2224.3.camel@unused-4-145.brq.redhat.com> References: <1381829872.2237.1.camel@unused-4-145.brq.redhat.com> <1381911059.2224.2.camel@unused-4-145.brq.redhat.com> <525E5018.9090900@redhat.com> <1381913559.2224.3.camel@unused-4-145.brq.redhat.com> Message-ID: <525E54C0.6080209@redhat.com> On 10/16/2013 10:52 AM, Martin Basti wrote: > On Wed, 2013-10-16 at 10:36 +0200, Martin Kosek wrote: >> On 10/16/2013 10:10 AM, Martin Basti wrote: >>> On Tue, 2013-10-15 at 11:37 +0200, Martin Basti wrote: >>>> Added warning if cert. exists (client) >>>> >>>> https://fedorahosted.org/freeipa/ticket/3944 >> >> 1) Patch subject uses wrong path to cert >> > Fixed >> 2) The warning seems to chatty to me: >> >> # ipa-client-install -p admin -w kokos123 >> Certificate '/etc/ipa/ca.crt' exists and will be used. Make sure that >> certificate is valid (or remove it), otherwise client will not be able to join. >> Discovery was successful! >> ... >> >> We just want to notify user that we are using the cert and what is the path (as >> this is something new to FreeIPA newbies), this seems easier to read to me: >> >> # ipa-client-install -p admin -w kokos123 >> Using existing certificate /etc/ipa/ca.crt >> Discovery was successful! >> ... >> > Fixed > ACK! Pushed to master. Thanks, Martin From pviktori at redhat.com Wed Oct 16 11:57:42 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 16 Oct 2013 13:57:42 +0200 Subject: [Freeipa-devel] [PATCH 0119] ipatests: Extend the order plugin to properly handle inheritance In-Reply-To: <525BFFA1.60207@redhat.com> References: <525BFFA1.60207@redhat.com> Message-ID: <525E7F36.4000507@redhat.com> On 10/14/2013 04:28 PM, Tomas Babej wrote: > Hi, > > When trying to create a new ordered test case by inheriting > from already defined test case, by overriding few of its methods, > the execution order of the tests is as follows: > - first all non-overriden test methods from the parent test class > - then all overriden tests methods That is not strictly true: if the base class is defined in a different file, with larger line numbers, with this patch its tests would run last. > This patch makes sure that methods are executed in the logical order, > that is, the order defined in the parent class. We'll also need to support longer inheritance chains than just one parent. The sort should look at the first @ordered superclass where the method was defined, and run the methods defined at the beginning of the inheritance chain first. I've modified your patch to accomplish this, does it look OK? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0119-ipatests-Extend-the-order-plugin-to-properly-handle-.patch Type: text/x-patch Size: 2317 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 16 13:31:51 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 16 Oct 2013 15:31:51 +0200 Subject: [Freeipa-devel] [PATCH][DOC] 432 Add direct bug reporting links to Feedback section Message-ID: <525E9547.3030905@redhat.com> This change should enable faster and easier filing of new bugs. Patch also simplifies the section for both redhat and fedora variants. https://fedorahosted.org/freeipa/ticket/3754 -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-432-add-direct-bug-reporting-links-to-feedback-section.patch Type: text/x-patch Size: 5534 bytes Desc: not available URL: From pviktori at redhat.com Wed Oct 16 13:44:05 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 16 Oct 2013 15:44:05 +0200 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests In-Reply-To: <525C121E.3080406@redhat.com> References: <52370B90.2030009@redhat.com> <52381625.3010607@redhat.com> <52386896.3000909@redhat.com> <523B1F0F.3010101@redhat.com> <525C121E.3080406@redhat.com> Message-ID: <525E9825.2070008@redhat.com> On 10/14/2013 05:47 PM, Tomas Babej wrote: > Hi, > > Sending the updated version of the patchset. It includes many fixes, > plus incorporations of the comments by the QE. Tests are now broken down > into multiple test cases. > > This requires my patch 119. > > Tomas Patches 0100 & 0101: I still think it would be simpler if IPA and AD domains shared the numbering namespace (users would need to define $AD_env2; if they had $MASTER_env1 and $AD_env1 they would be in the same Domain). But if we use _env1 for both the AD and the IPA domain, they need to be separated in Domain.from_env. With patch 0101 both MASTER_env1 and AD_env1 will be in both domains[0] and ad_domains[0]. Also ipa-test-config should have an --ad-domain option to get info about the AD domain. Patch 0102: Looks good Patch 0103: Looks like run_repeatedly should always be called with an assert in front. We may want it to raise an exception directly if it times out, so forgetting the assert won't hide errors. Patch 0104: Looks good Patch 0105: In /ipatests/man/ipa-test-task.1: - Typo in - s/generatee/generate/ - Subcommand names have unescaped hyphens (e.g. configure\-dns-for-trust should be configure\-dns\-for\-trust) - The last subcommand should be sync-time Wrappers for the tasks need to be added to ipatests/ipa-test-task. Nitpicks: - In configure_dns_for_trust:is_subdomain, lockstep iteration over two lists at once is better done with zip() than `for i in range(len(...))`. - In estabilish_trust_with_ad, don't use mutable values for argument defaults; do `extra_args=()` and `+ list(extra_args)` - I can't say I'm a fan of configure_auth_to_local_rule, but I guess it's OK for tests. Patch 0106: Looks OK; unfortunately I don't have an AD machine to test functionality -- Petr? From tbabej at redhat.com Wed Oct 16 14:35:03 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 16 Oct 2013 16:35:03 +0200 Subject: [Freeipa-devel] [PATCH 0119] ipatests: Extend the order plugin to properly handle inheritance In-Reply-To: <525E7F36.4000507@redhat.com> References: <525BFFA1.60207@redhat.com> <525E7F36.4000507@redhat.com> Message-ID: <525EA417.1090905@redhat.com> On 10/16/2013 01:57 PM, Petr Viktorin wrote: > On 10/14/2013 04:28 PM, Tomas Babej wrote: >> Hi, >> >> When trying to create a new ordered test case by inheriting >> from already defined test case, by overriding few of its methods, >> the execution order of the tests is as follows: >> - first all non-overriden test methods from the parent test class >> - then all overriden tests methods > > That is not strictly true: if the base class is defined in a different > file, with larger line numbers, with this patch its tests would run last. > >> This patch makes sure that methods are executed in the logical order, >> that is, the order defined in the parent class. > > We'll also need to support longer inheritance chains than just one > parent. > The sort should look at the first @ordered superclass where the method > was defined, and run the methods defined at the beginning of the > inheritance chain first. > > I've modified your patch to accomplish this, does it look OK? > Thanks! This will even work with cross-module imports. I added a section to the Integration testing design page: http://www.freeipa.org/page/V3/Integration_testing#Ordering_of_the_tests Also, I changed the commit message and comments to reflect the new behaviour. Updated patch attached. Tomas -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0119-2-ipatests-Extend-the-order-plugin-to-properly-handle-.patch Type: text/x-patch Size: 2519 bytes Desc: not available URL: From abokovoy at redhat.com Wed Oct 16 15:31:32 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 16 Oct 2013 18:31:32 +0300 Subject: [Freeipa-devel] [PATCH] 0125 Trusts documentation update Message-ID: <20131016153132.GB25335@redhat.com> Hi! Attached is first update to AD trusts documentation for FreeIPA user guide. I've fixed number of outdated statements and added some more material. More patches will follow to cover functionality up to FreeIPA 3.3.2. -- / Alexander Bokovoy -------------- next part -------------- >From cb5af31974186d7f3c2acc67bdb2448deecbe02c Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 16 Oct 2013 18:25:55 +0300 Subject: [PATCH] Update Trust.xml to be on par with FreeIPA 3.3 --- src/user_guide/en-US/Trust.xml | 240 ++++++++++++++++++++++++++++------------- 1 file changed, 165 insertions(+), 75 deletions(-) diff --git a/src/user_guide/en-US/Trust.xml b/src/user_guide/en-US/Trust.xml index 0f89c79..0d8cba7 100644 --- a/src/user_guide/en-US/Trust.xml +++ b/src/user_guide/en-US/Trust.xml @@ -2,12 +2,19 @@ - Identity: Integrating with Active Directory Through Cross-Realm Kerberos Trusts &TITLE_TPREVIEW; - - Kerberos allows the configuration of trusted realms. Each realm has its own - resources and users, yet the trust relationship allows users of any trusted realm to obtain tickets - and connect to machines or services in a peer realm as if they were members of that peer realm. - + Identity: Integrating with Active Directory Through Cross-Realm Kerberos Trusts &TITLE_TPREVIEW; + + Active Directory is a Microsoft's implementation of LDAP, Kerberos, + SMB, and few other protocol families. While there are many differences + in the way these protocol families are implemented, in its core + trusting one &AD; domain to another means establishing relationships + between the two domains on the Kerberos protocol level. Kerberos + allows the configuration of trusted realms. Each + realm has its own resources and users, yet the trust relationship + allows users of any trusted realm to obtain tickets and connect to + machines or services in a peer realm as if they were members of that + peer realm. + Because of differences in the way that Windows and Linux domains implement LDAP services, DNS management, and even Kerberos realms, it is difficult to establish a direct trust between &AD; @@ -15,6 +22,18 @@ the Kerberos trust and DNS mappings so that &AD; users can access Linux hosts and services completely transparently, using one set of credentials. + + &AD; was implemented on top of existing domain membership as provided by SMB + protocol. In order to give short transition path for existing + deployments, many of the concepts from SMB protocol are used + internally by &AD;. Trust relationship is one of these; establishing + trust between two domains, in fact, requires execution of an SMB + command sequence that leads to creation of specialized accounts in LDAP + storage of domain controllers in both domains. When this step is + performed, resulting accounts can be used to perform Kerberos + authentication against the other domain and represent shared ticket and + key for Kerberos cross-realm trust. +
The Meaning of "Trust" @@ -45,13 +64,19 @@ - Samba, to perform identity lookups on &AD; and retrieve user and group security identifiers (SIDs) for authorization information - + Samba, to perform SMB protocol operations against + domain controllers in &AD; and represent points of + communication that &AD; domain controllers expect to + exist in another &AD; domain + - SSSD, to cache user, group, and ticket information for users and to map Kerberos and DNS domains - + SSSD, to query and cache user, group, and Kerberos + ticket information for users from &AD;. SSSD also maps + Security Identifiers of user and group objects on &AD; + side to user and group identifiers on &IPA; side + @@ -86,17 +111,36 @@ - Trusts, then, are essentially unidirectional. &AD; users can access &IPA; resources and services, but &IPA; users - cannot access &AD; resources. Trust allows Windows administrators and users to be able to access and manage Linux resourcesTrusted users, however, + Trust relationship is unidirectional. &AD; users can access + &IPA; resources and services, but &IPA; users cannot access + &AD; resources. Trust allows Windows administrators and users + to be able to access and manage Linux + resourcesTrusted users, however, cannot manage &PROD; itself.. - - - A trust relationship is established between a single &AD; domain and a single &IPA; domain. - + + + + It is worth to note that while a single trust relationship is + unidirectional, &IPA; technically establishes bidirectional + trust relationships with &AD; and internally uses &IPA; to &AD; + trust path to query &AD; users membership information from &AD; + domain controllers. However, to allow full access for &IPA; + users to &AD; resources, &IPA; needs to advance its + implementation of Global Catalog service as required by + &AD;-compliant domains. + + + + &AD; may contain a number of subordinated domains. In this case + one &AD; domain is called forest root + domain. A trust + relationship is established between a single &AD; forest + root domain and a single &IPA; domain. + NOTE No Windows machine can be a client of the &IPA; domain in a trust environment. - All Windows machines must be in the &AD; domain. + All Windows machines must be in an &AD; domain. @@ -163,39 +207,74 @@
Kerberos Realms, Authentication, and Authorization - Group information in &AD; is stored in a list of identifiers in each Kerberos ticket for - &AD; users in a special dataset called privileged access certificates - or MS-PAC. The group information in the PAC has to be mapped to the &AD; groups and then - to the corresponding &IPA; groups to help determine access. A PAC is essentially an account usability - extension. - - - Understanding the group mapping for trusts can help clarify how groups should be structured - in trust environments. - + Each object in &AD; can be addressed using its + Security Identifier (SID). Users, groups, + machine accounts, and other objects all have associated SIDs. + In some cases there could be more than one SID associated with + an object. For performance purposes information about SIDs of + related objects, including group membership, is stored in each + Kerberos ticket for &AD; users in a special dataset called + privileged access certificates or MS-PAC. + MS-PAC is issued as part of the Kerberos ticket and digitally + signed by the &AD; domain controller that issued the ticket. + Digital signature allows to verify authenticity of the + information and avoid requesting it over and over again from + &AD; domain controllers, making more efficient use of network + and computing resources. + - - Microsoft uses a special authorization structure called privileged access certificates - or MS-PAC. A PAC is embedded in a Kerberos ticket as a way of identifying the entity to other Windows clients and servers in the Windows domain. - - - On &IPA; resources, if an &AD; user requests a ticket for a service, then &IPA; - forwards the request - to &AD; to retrieve the user information. The PAC information sent back by &AD; - is embedded in the Kerberos ticket. + + Understanding the group mapping for trusts can help clarify how + groups should be structured in trust environments. + + + + When an &AD; user requests a ticket for a service in &IPA; + domain, it presents a cross-realm ticket granting ticket (TGT) + issued to an &AD; user by an &AD; domain controller. This + ticket contains MS-PAC information, signed by the &AD; domain controller. + + + &IPA; KDC, upon request to issue a ticket for a service in &IPA; domain, + verifies MS-PAC information in an &AD; user ticket. If it + contains any security identifier that + should be filtered out and not allowed to access &IPA; domain, + the request to obtain a service ticket is rejected. + + + + If &IPA; KDC issues the ticket to the service in &IPA; domain, + &AD; security identifiers from MS-PAC are used to map an &AD; + user membership to &IPA; groups. If an &AD; SID is an + external member of &IPA; group, &IPA; KDC + will track down any POSIX group this group is included into and + will add its SID to MS-PAC structure. + + + + Resulting ticket to the &IPA; service is digitally signed by + &IPA; KDC. Its MS-PAC information will contain SIDs of original + &AD; objects and &IPA; POSIX groups of which these objects are + external members. This ticket is then used by a software that + requested the ticket to connect to the actual &IPA; service. + + + + When the connection request comes to &IPAA; client, &IPA; + (through SSSD, as &IPAA; client), extracts the &AD; + security identifiers from the PAC and maps + them to POSIX group and user identifiers. The user is granted + access to the &IPA;-hosted services. according to their access + rules. Additionally, the &IPA; group information in the SSSD + user cache is updated to include the mapped &IPA; groups for + the &AD; user. + NOTE All Kerberos communication for both &AD; and &IPA; for trusts uses GSS-API. - - &IPA; (through SSSD, as &IPAA; client), extracts the &AD; group security - identifiers (SIDs) from the PAC. &IPA; then compares the &AD; SIDs in the PAC - to the group SIDs configured as members in &IPA; groups. If the &AD; group is - a member of &IPAA; group, then the &IPA; group SID is added to the PAC, and the - Kerberos ticket is updated with the new PAC. -
&IPA;, SSSD, and &AD; @@ -205,15 +284,6 @@
- That new ticket is then used to generate a service ticket for the user, and - the user is granted access to the &IPA;-hosted services. - according to their access rules. Additionally, the &IPA; group information in the - SSSD user cache is updated to include the mapped &IPA; groups for the &AD; user. - - - SSSD stores multiple TGTs and tickets for each user, as new services are accessed. - - A simpler way of saying this is that &AD; supplies a list of groups for each user, based on an identifier for the group. &IPA; compares that list of &AD; groups to memberships in &IPA; groups (where each group member is identified @@ -224,36 +294,56 @@ The crucial factor to realize in this is that &AD; users are recognized to the &IPA; domain not by their &AD; user entry, but - by their &AD; group memberships. + by their &IPA; group memberships. In a sense, &AD; users are not trusted by the &IPA; domain - — &AD; groups are. - - - But this method of mapping &AD; group SIDs to &IPA; group members means that - group structure in &IPA; is important. &AD; groups have different attributes - than Linux groups and, therefore, different attributes than &IPA; groups. Most - critically, &AD; groups are not POSIX groups, while &IPA; groups are. - - - &IPA; has introduced an intermediary, non-POSIX group type, external groups, which - allow entities outside &IPA; or a Linux system to be added as member. That external group can then be - added to a standard &IPA; (POSIX) group as a member. - + — &IPA; groups are. + + + + Since in POSIX environment every running process should be + running under some user and have some group membership to + access files, it is important that every &IPA; user has + corresponding POSIX identifier and user belongs to some groups + which have POSIX identifiers. Each &AD; user, therefore, should + have membership in some POSIX group to be able to access files + and run processes in &IPA; domain. + + + + Additionally, &AD; user entries are never stored in &IPA; LDAP + and cannot be addressed by a DN. Group members in &IPA; LDAP + always addressed by their DNs. This means &AD; users cannot be + directly added to &IPA; POSIX groups. + + + + &IPA; LDAP schema supports nested group membership. Each &IPA; + group may include another &IPA; group as its member. When + membership information is processed by &IPA; KDC or SSSD, + nested groups are unrolled and whole set of members is + flattened. + + + + &IPA; has introduced an intermediary, non-POSIX group type, + external groups, which allow entities + outside &IPA; or a Linux system to be added as a member. That + external group can then be added to a standard &IPA; (POSIX) + group as a member. + + - When &AD; groups are added to &IPAA; group, they can be idenfitied by + When &AD; objects are added to &IPAA; group, they can be idenfitied by their SID or by name, in the formats DOMAIN\group_name or - group_name at domain. &IPA; then resolves the group name to + group_name at domain. &IPA; then resolves the object name to the SID and stores the SID as the group member entry, to be compared to any offered user PAC. - + + Actually configuring groups for &AD; users is described in . - - IMPORTANT - - Both &AD; and &PROD; must be configured with integrated certificate services. - - + + All sessions in a trust environment are ultimately secured with Kerberos tickets, but users have different login options: -- 1.8.3.1 From pvoborni at redhat.com Wed Oct 16 16:11:23 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 16 Oct 2013 18:11:23 +0200 Subject: [Freeipa-devel] [PATCH] 448 Load updated Web UI files after server upgrade In-Reply-To: <525D2C3C.9040606@redhat.com> References: <5220B880.9040902@redhat.com> <524530C7.9020204@redhat.com> <524BF95D.2000006@redhat.com> <525D2C3C.9040606@redhat.com> Message-ID: <525EBAAB.3020602@redhat.com> On 10/15/2013 01:51 PM, Ana Krivokapic wrote: > On 10/02/2013 12:45 PM, Petr Vobornik wrote: >> On 09/27/2013 09:16 AM, Ana Krivokapic wrote: >>> On 08/30/2013 05:21 PM, Petr Vobornik wrote: >> >> snip >> >>>> >>>> https://fedorahosted.org/freeipa/ticket/3798 >>>> >>> >>> I tested the patch and it seems to work fine. Code-wise it looks good as well. >>> >>> Nitpick: There is an unused function 'updated()' in the new loader.js.in file. >>> >> >> Unused function removed. Updated patch attached. > > ACK > Pushed to master -- Petr Vobornik From pvoborni at redhat.com Wed Oct 16 16:11:45 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 16 Oct 2013 18:11:45 +0200 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <525D4361.7000000@redhat.com> References: <523049A5.10208@redhat.com> <523722A3.7060700@redhat.com> <524C0F70.809@redhat.com> <525D4361.7000000@redhat.com> Message-ID: <525EBAC1.3000608@redhat.com> On 10/15/2013 03:30 PM, Ana Krivokapic wrote: > On 10/02/2013 02:20 PM, Petr Vobornik wrote: >> On 09/16/2013 05:24 PM, Ana Krivokapic wrote: >>> On 09/11/2013 12:44 PM, Petr Vobornik wrote: >>>> Hello, >>>> >> >> snip >> >>>> >>> >>> I looked into the documentation effort and (ruby dependency discussion aside) I >>> don't have any major objections. I like how the generated pages look, and they >>> are intuitive and easy to navigate. >>> >>> A couple of nitpicks: >>> >>> 1) There are some spelling mistakes (e.g. Apllication_controller) >> Fixed >>> >>> 2) Bulleted lists are not rendered nicely in the html output (see for example >>> the doc string for _base.Builder property 'string_mode'. I think a list needs to >>> look like this in the source code: >>> >>> /** >>> * This is a list: >>> * >>> * - 'element1' >>> * - 'element2' >>> * >>> */ >>> >>> as opposed to this: >>> >>> /** >>> * This is a list: >>> * - 'element1' >>> * - 'element2' >>> */ >>> >> >> Fixed on many places. Also fixed the same issue in some code examples. >> >> - _base.Builder doc was heavily revised >> - added doc comments to ./plugin_loader >> >> All patches are rebased but just patches 452 and 453 are changed. > > Looks good, ACK. > Pushed to master -- Petr Vobornik From pviktori at redhat.com Wed Oct 16 16:13:01 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 16 Oct 2013 18:13:01 +0200 Subject: [Freeipa-devel] [PATCHES] 106-113 Access raw LDAP values directly from LDAPEntry In-Reply-To: <525BB27C.1000507@redhat.com> References: <512E26E1.5010302@redhat.com> <52419527.70200@redhat.com> <524426F5.6010006@redhat.com> <525544A3.6080807@redhat.com> <52565B09.2090909@redhat.com> <525BB27C.1000507@redhat.com> Message-ID: <525EBB0D.9040003@redhat.com> On 10/14/2013 10:59 AM, Jan Cholasta wrote: > On 10.10.2013 09:45, Jan Cholasta wrote: >> On 9.10.2013 13:57, Petr Viktorin wrote: >>> On 09/26/2013 02:22 PM, Jan Cholasta wrote: >>>> On 24.9.2013 15:35, Jan Cholasta wrote: >>>>> On 27.2.2013 16:31, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> these patches add the ability to access and manipulate raw attribute >>>>>> values as they are returned from python-ldap to the LDAPEntry class. >>>>>> This is useful for comparing entries, computing modlists for the >>>>>> modify >>>>>> operation, deleting values that don't match the syntax of an >>>>>> attribute, >>>>>> etc., because we don't need to care what syntax does a particular >>>>>> attribute use, or what Python type is used for it in the framework >>>>>> (raw >>>>>> values are always list of str). It should also make interaction with >>>>>> non-389 DS LDAP servers easier in the framework. >>>>>> >>>>>> (It might be too late for this kind of changes to get into 3.2 now, >>>>>> I'm >>>>>> posting these patches mainly so that you are aware that they exist.) >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> This is now planned for 3.4: >>>>> >>>>> >>>>> I fixed some issues in these patches and refined the API. Updated >>>>> patches attached. >>>>> >>>>> Also added a patch to use raw values when adding new entries and a >>>>> patch >>>>> which refines LDAPEntry.single_value, so that it is consistent with >>>>> the >>>>> rest of the changes introduced in the patches. >>>>> >>>>> Patch 110 will probably be dropped in favor of Petr Viktorin's schema >>>>> update patches, but I included it anyway. >>>>> >>>>> Incidentally, this also fixes >>>>> and possibly also >>>>> . >>>>> >>>>> Honza >>>>> >>>> >>>> Noticed a couple more issues and fixed them. Updated patches attached. >>>> >>>> Honza >>> >>> Thanks for the patches! >>> >>> >>> 106. Make LDAPEntry a wrapper around dict rather than a dict subclass. Git rants about one more whitespace error. [...] >>> + def __eq__(self, other): >>> + if not isinstance(other, LDAPEntry): >>> + return NotImplemented >>> + if self._dn != other._dn: >>> + return False >>> + return super(LDAPEntry, self).__eq__(other) >>> >>> I don't think equality checking makes sense on a LDAPEntry, where you >>> might have different capitalizations/variants of attribute names, >>> different _orig, or a different set of attributes loaded on the same >>> entry. It's not obvious which of those differences should make the >>> entries inequal. >>> I'd just base it on identity (`self is other`). >> >> Right, I'm not sure why I even did it this way. But I remember seeing >> some code that did comparison of entries with ==... Thanks. Please also implement __ne__() when reimplementing __eq__(). >> >>> >>> def __iter__(self): >>> yield self._dn >>> yield self >>> >>> This makes the whole thing sort of hackish -- we need to reimplement >>> everything in MutableMapping that uses iter() internally :( >>> Hopefully we can get rid of it soon. >> >> Yes, it's a shame MutableMapping uses iter() instead of iterkeys(). >> >>> I'd welcome FIXME comments on whatever is reimplemented for this reason. >> >> I thought the comment above __iter__ would be enough. Apparently I was >> wrong. Right, IMO it's not immediately obvious that these are reimplemented because they depend on __iter__. [...] >>> 109. Decode and encode attribute values in LDAPEntry on demand. >>> >>> The syncing looks rather over-engineered to me. >>> Did you consider a custom MutableSequence for the values? >>> I think it would be much cleaner in the end than merging two sets of >>> changes together. >> >> I'm not entirely happy about it either, but it works. I did consider a >> custom sequence type, but I didn't feel like it was the right time to >> this kind of change in this patchset. >> >> Unlike the (DN, dict) -> LDAPEntry >> transition, this change won't be backward compatible and there is a lot >> of isinstance(value, list) and entry[attr] = list() kind of things in >> the framework code. That's what I was afraid of. We could live with `isinstance(value, list)`; hopefully we could get rid of `type(value) == list` that is the real problem. With `entry[attr] = list()` we could convert automatically. But OK, let's settle for a worse solution in the meantime. To be frank I don't particularly like the LDAPEntryView. While the dict-like interface is great, there isn't a case for storing a Raw view long-term, i.e. you'd always want to do something like values = entry.raw[x] ... entry.raw[x] = new_values rather than raw = entry.raw values = raw[x] ... raw[x] = new_values The latter is confusing because LDAPEntryView and RawLDAPEntryView are two classes that have exactly the same interface, but do something different. In a duck-typed world that's a recipe for disaster. I think it would be better if the view implemented just the dict protocol, and not `conn`, `dn`, `nice`, `raw`, etc. The code would also be much simpler without the elaborate view class hierarchy. If you don't agree then at least don't make `raw` available on raw views and `nice` on nice views; the programmer *always* needs to know which version they're working with so these aren't necessary. >>> I think it would also help (in the future?) to make the value lists more >>> set-like, since the order doesn't matter. >> >> +1 >> >> Honza >> > > Updated patches attached. > 110. It can't hurt to have this in for now. 111 - 121 look great! 169. For reasons I said before I'd prefer if single_value stayed a simple function. -- Petr? From pspacek at redhat.com Wed Oct 16 19:59:37 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 16 Oct 2013 21:59:37 +0200 Subject: [Freeipa-devel] [PATCH][DOC] 432 Add direct bug reporting links to Feedback section In-Reply-To: <525E9547.3030905@redhat.com> References: <525E9547.3030905@redhat.com> Message-ID: <525EF029.9090802@redhat.com> On 16.10.2013 15:31, Martin Kosek wrote: > This change should enable faster and easier filing of new bugs. Patch > also simplifies the section for both redhat and fedora variants. > > https://fedorahosted.org/freeipa/ticket/3754 Hmm, is there a way to add the "Report a bug" link to each page footer (in HTML output)? I think that people should see this option all the time. This recalls me another thing: Could we add TICKET_CREATE privilege to anonymous 'subject' in the Trac? This should allow anyone to create ticket even without registration/logging in, which lowers the barrier. TICKET_CREATE is not enough for any modification to existing tickets/wiki, so we should be safe. The worst case is that we will have to remove few tickets with gibberish and revoke the permission. I did that for https://fedorahosted.org/bind-dyndb-ldap/ , feel free to create testing tickets there (don't forget to log-out :-). -- Petr^2 Spacek From akrivoka at redhat.com Wed Oct 16 21:37:58 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 16 Oct 2013 23:37:58 +0200 Subject: [Freeipa-devel] [PATCHES] 0072-0074 Add automember rebuild membership to the web UI In-Reply-To: <52459883.2070702@redhat.com> References: <5242B235.6020608@redhat.com> <52459883.2070702@redhat.com> Message-ID: <525F0736.7080605@redhat.com> On 09/27/2013 04:38 PM, Petr Vobornik wrote: > On 09/25/2013 11:51 AM, Ana Krivokapic wrote: >> Hello, >> >> This patch set addresses ticket >> https://fedorahosted.org/freeipa/ticket/3928. >> >> Patch 0072 hooks the new automember-rebuild command to the web UI >> (user and host >> pages). >> Patch 0073 adds some fixes to the web UI test driver, which are >> necessary for >> patch 0074. >> Patch 0074 adds web UI integration tests for the new feature. >> >> The patch set applies on top of my patches 0068-0071 >> > > patch 72: Me, Ana and Kyle discussed position of the actions and the > decision was to move them to action list. > > `ipa automember-rebuild --type=hostgroup` can't be run from UI > (already discussed with Ana as well) > > I'm thinking about adding/creating refresh facet policies for this > action so that appropriate facet would be marked as dirty and > therefore refreshed so user would not have click association facet > refresh button. > > patch 73: Looks OK but some changes might not be needed. > > patch 74: I would use different methods for certain actions to be > consistent with other tests and to make the test more robust against > Web UI refactoring: > > 1. >> self.click_on_link('Refresh') > > For buttons in .facet-controls use rather > `self.facet_button_click('refresh')` where 'refresh' is the button > name, not text. > > 2. >> self.add_record( >> 'automember', >> {'pkey': 'webservers', 'add': [ >> ('selectbox', 'key', 'fqdn'), >> ('textbox', 'automemberinclusiveregex', '^web[1-9]+') >> ]}, >> facet='hostgrouprule', >> facet_btn_css_class='widget', >> navigate=False >> ) > > use `add_table_record('automemberinclusiveregex', data, parent)`. > Example in test_dns.py:94. > > 3. A nitpick(or not even that): When working on one entity, I would > rather use `navigate_by_breadcrumb('link text') instead of direct > `navigate_to_record` call which changes url. It resembles user's > behavior more. But it depends on situation. Ie. when I'm on hostgroup > page and want to go to host search page, but the last host page was > some details or association I may just use `navigate_to_entity('host', > 'search'). Anyway, the important thing is to avoid navigating to the > same url twice in a row - IE10 does not like that. > > 4. Do not use `wait(1)` for AJAX calls. The test will fail if there is > bigger delay. User rather `wait_for_request(n=X)` where X is number of > AJAX calls you want to wait for. > > 5. Instead of `click_on_link('Rebuild auto membership')` you should > use `action_panel_action(panel_name, action)` There is also similar > call for > executing action list action: `action_list_action(action_name)`. > > 6. Nitpick: you can reduce the cleanup code: >> self.navigate_by_menu('identity/host') >> self.delete('host', [{'pkey': host1}]) >> self.delete('host', [{'pkey': host2}]) > > Can be written as: > > self.delete('host', [{'pkey': host1}, {'pkey': host2}]) > > or > self.navigate_by_menu('identity/host') > self.delete_record('host', [host1, host2]) > > `delete` is basically a shortcut for `navigate_to_entity` and > `delete_record` with CRUD data format. All fixed, new patches attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0072-02-Add-automember-rebuild-command-to-the-web-UI.patch Type: text/x-patch Size: 8466 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0073-02-Web-UI-integration-test-driver-enhancements.patch Type: text/x-patch Size: 1822 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0074-02-Add-web-UI-integration-tests-for-automember-rebuild.patch Type: text/x-patch Size: 7747 bytes Desc: not available URL: From simo at redhat.com Thu Oct 17 01:06:07 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 16 Oct 2013 21:06:07 -0400 Subject: [Freeipa-devel] [PATCH][DOC] 432 Add direct bug reporting links to Feedback section In-Reply-To: <525EF029.9090802@redhat.com> References: <525E9547.3030905@redhat.com> <525EF029.9090802@redhat.com> Message-ID: <1381971967.31620.1.camel@willson.li.ssimo.org> On Wed, 2013-10-16 at 21:59 +0200, Petr Spacek wrote: > On 16.10.2013 15:31, Martin Kosek wrote: > > This change should enable faster and easier filing of new bugs. Patch > > also simplifies the section for both redhat and fedora variants. > > > > https://fedorahosted.org/freeipa/ticket/3754 > > Hmm, is there a way to add the "Report a bug" link to each page footer (in > HTML output)? I think that people should see this option all the time. > > > This recalls me another thing: > Could we add TICKET_CREATE privilege to anonymous 'subject' in the Trac? This > should allow anyone to create ticket even without registration/logging in, > which lowers the barrier. Bad idea, you'll soon be submerge by the worst looking spam, seriously, don't do it. Besides you wouldn't be able to notify the reporter that you need more info and so on, its not worth to have fire-and-forget reports. > TICKET_CREATE is not enough for any modification to existing tickets/wiki, so > we should be safe. The worst case is that we will have to remove few tickets > with gibberish and revoke the permission. > > I did that for https://fedorahosted.org/bind-dyndb-ldap/ , feel free to create > testing tickets there (don't forget to log-out :-). -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Thu Oct 17 05:25:46 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 17 Oct 2013 07:25:46 +0200 Subject: [Freeipa-devel] [PATCH][DOC] 432 Add direct bug reporting links to Feedback section In-Reply-To: <1381971967.31620.1.camel@willson.li.ssimo.org> References: <525E9547.3030905@redhat.com> <525EF029.9090802@redhat.com> <1381971967.31620.1.camel@willson.li.ssimo.org> Message-ID: <525F74DA.1020804@redhat.com> On 17.10.2013 03:06, Simo Sorce wrote: > On Wed, 2013-10-16 at 21:59 +0200, Petr Spacek wrote: >> On 16.10.2013 15:31, Martin Kosek wrote: >>> This change should enable faster and easier filing of new bugs. Patch >>> also simplifies the section for both redhat and fedora variants. >>> >>> https://fedorahosted.org/freeipa/ticket/3754 >> >> Hmm, is there a way to add the "Report a bug" link to each page footer (in >> HTML output)? I think that people should see this option all the time. >> >> >> This recalls me another thing: >> Could we add TICKET_CREATE privilege to anonymous 'subject' in the Trac? This >> should allow anyone to create ticket even without registration/logging in, >> which lowers the barrier. > > Bad idea, you'll soon be submerge by the worst looking spam, seriously, > don't do it. > > Besides you wouldn't be able to notify the reporter that you need more > info and so on, its not worth to have fire-and-forget reports. There is an input box for reporter's e-mail... >> TICKET_CREATE is not enough for any modification to existing tickets/wiki, so >> we should be safe. The worst case is that we will have to remove few tickets >> with gibberish and revoke the permission. >> >> I did that for https://fedorahosted.org/bind-dyndb-ldap/ , feel free to create >> testing tickets there (don't forget to log-out :-). -- Petr^2 Spacek From pviktori at redhat.com Thu Oct 17 08:48:56 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 17 Oct 2013 10:48:56 +0200 Subject: [Freeipa-devel] [PATCH 0119] ipatests: Extend the order plugin to properly handle inheritance In-Reply-To: <525EA417.1090905@redhat.com> References: <525BFFA1.60207@redhat.com> <525E7F36.4000507@redhat.com> <525EA417.1090905@redhat.com> Message-ID: <525FA478.8070009@redhat.com> On 10/16/2013 04:35 PM, Tomas Babej wrote: > On 10/16/2013 01:57 PM, Petr Viktorin wrote: >> On 10/14/2013 04:28 PM, Tomas Babej wrote: >>> Hi, >>> >>> When trying to create a new ordered test case by inheriting >>> from already defined test case, by overriding few of its methods, >>> the execution order of the tests is as follows: >>> - first all non-overriden test methods from the parent test class >>> - then all overriden tests methods >> >> That is not strictly true: if the base class is defined in a different >> file, with larger line numbers, with this patch its tests would run last. >> >>> This patch makes sure that methods are executed in the logical order, >>> that is, the order defined in the parent class. >> >> We'll also need to support longer inheritance chains than just one >> parent. >> The sort should look at the first @ordered superclass where the method >> was defined, and run the methods defined at the beginning of the >> inheritance chain first. >> >> I've modified your patch to accomplish this, does it look OK? >> > > Thanks! This will even work with cross-module imports. > > I added a section to the Integration testing design page: > http://www.freeipa.org/page/V3/Integration_testing#Ordering_of_the_tests > > Also, I changed the commit message and comments to reflect the new > behaviour. > Great! ACK, pushed to master: 096a49766d6706a05231621b0993acd2e734b0f1 ipa-3-3: 76694f161089a538b37191280c82454d34bebcb9 -- Petr? From mbasti at redhat.com Thu Oct 17 08:55:36 2013 From: mbasti at redhat.com (Martin Basti) Date: Thu, 17 Oct 2013 10:55:36 +0200 Subject: [Freeipa-devel] [PATCH][DOC] 0012 Chapter 12 Defining password policies update Message-ID: <1382000136.2224.1.camel@unused-4-145.brq.redhat.com> Only minor fixes. Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0012-Chapter-12-Defining-password-policies-update.patch Type: text/x-patch Size: 479048 bytes Desc: not available URL: From pviktori at redhat.com Thu Oct 17 09:53:31 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 17 Oct 2013 11:53:31 +0200 Subject: [Freeipa-devel] [PATCH] 431 Installer should always wait until CA starts up In-Reply-To: <525E4A6F.3000001@redhat.com> References: <525E4A6F.3000001@redhat.com> Message-ID: <525FB39B.7010007@redhat.com> On 10/16/2013 10:12 AM, Martin Kosek wrote: > Patch for ticket 3964 changed the installer so that it does not > always wait for CA if the proxy is not configured. However, > it was found out that it may freeze an installation when > a step subsequent after CA restart call the CA and receives no > reply. > > Change the wait so that it always waits for CA to start up. If > HTTP proxy is already configured, it should wait on port 443. > If not, it should wait on local PKI port 8443. > > https://fedorahosted.org/freeipa/ticket/3973 Works for me, ACK. I'll wait with pushing until the ticket is triaged. -- Petr? From mkosek at redhat.com Thu Oct 17 10:04:25 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Oct 2013 12:04:25 +0200 Subject: [Freeipa-devel] [PATCH][DOC] 432 Add direct bug reporting links to Feedback section In-Reply-To: <525F74DA.1020804@redhat.com> References: <525E9547.3030905@redhat.com> <525EF029.9090802@redhat.com> <1381971967.31620.1.camel@willson.li.ssimo.org> <525F74DA.1020804@redhat.com> Message-ID: <525FB629.1090403@redhat.com> On 10/17/2013 07:25 AM, Petr Spacek wrote: > On 17.10.2013 03:06, Simo Sorce wrote: >> On Wed, 2013-10-16 at 21:59 +0200, Petr Spacek wrote: >>> On 16.10.2013 15:31, Martin Kosek wrote: >>>> This change should enable faster and easier filing of new bugs. Patch >>>> also simplifies the section for both redhat and fedora variants. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3754 >>> >>> Hmm, is there a way to add the "Report a bug" link to each page footer (in >>> HTML output)? I think that people should see this option all the time. >>> >>> >>> This recalls me another thing: >>> Could we add TICKET_CREATE privilege to anonymous 'subject' in the Trac? This >>> should allow anyone to create ticket even without registration/logging in, >>> which lowers the barrier. >> >> Bad idea, you'll soon be submerge by the worst looking spam, seriously, >> don't do it. >> >> Besides you wouldn't be able to notify the reporter that you need more >> info and so on, its not worth to have fire-and-forget reports. > > There is an input box for reporter's e-mail... Yeah, I wonder who would fill it. I would personally leave it as is, when someone really does not not want to register to Fedora, he can send a mail to freeipa-users (and thus also give as a way to ask back). Martin From mkosek at redhat.com Thu Oct 17 10:08:45 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Oct 2013 12:08:45 +0200 Subject: [Freeipa-devel] [PATCH] 431 Installer should always wait until CA starts up In-Reply-To: <525FB39B.7010007@redhat.com> References: <525E4A6F.3000001@redhat.com> <525FB39B.7010007@redhat.com> Message-ID: <525FB72D.8090900@redhat.com> On 10/17/2013 11:53 AM, Petr Viktorin wrote: > On 10/16/2013 10:12 AM, Martin Kosek wrote: >> Patch for ticket 3964 changed the installer so that it does not >> always wait for CA if the proxy is not configured. However, >> it was found out that it may freeze an installation when >> a step subsequent after CA restart call the CA and receives no >> reply. >> >> Change the wait so that it always waits for CA to start up. If >> HTTP proxy is already configured, it should wait on port 443. >> If not, it should wait on local PKI port 8443. >> >> https://fedorahosted.org/freeipa/ticket/3973 > > Works for me, ACK. I'll wait with pushing until the ticket is triaged. Triaged. Pushed to master, ipa-3-3. Martin From sbose at redhat.com Thu Oct 17 10:31:51 2013 From: sbose at redhat.com (Sumit Bose) Date: Thu, 17 Oct 2013 12:31:51 +0200 Subject: [Freeipa-devel] [PATCH] 0125 Trusts documentation update In-Reply-To: <20131016153132.GB25335@redhat.com> References: <20131016153132.GB25335@redhat.com> Message-ID: <20131017103151.GA3517@localhost.localdomain> On Wed, Oct 16, 2013 at 06:31:32PM +0300, Alexander Bokovoy wrote: > Hi! > > Attached is first update to AD trusts documentation for FreeIPA user > guide. I've fixed number of outdated statements and added some more > material. > > More patches will follow to cover functionality up to FreeIPA 3.3.2. The new content looks good, I only found a few minor issues, see below. bye, Sumit > > -- > / Alexander Bokovoy ... > + them to POSIX group and user identifiers. The user is granted > + access to the &IPA;-hosted services. according to their access ^ ? I think the dot should be removed. > + rules. Additionally, the &IPA; group information in the SSSD > + user cache is updated to include the mapped &IPA; groups for > + the &AD; user. ... > + > + > + Since in POSIX environment every running process should be > + running under some user and have some group membership to > + access files, it is important that every &IPA; user has I think you mean "every user of &IPA; services", because "every &IPA; user" has a POSIX ID by default. > + corresponding POSIX identifier and user belongs to some groups > + which have POSIX identifiers. Each &AD; user, therefore, should > + have membership in some POSIX group to be able to access files > + and run processes in &IPA; domain. > + > + > + > > - When &AD; groups are added to &IPAA; group, they can be idenfitied by > + When &AD; objects are added to &IPAA; group, they can be idenfitied by "identified" (error was there before) > their SID or by name, in the formats DOMAIN\group_name or > - group_name at domain. &IPA; then resolves the group name to > + group_name at domain. &IPA; then resolves the object name to > the SID and stores the SID as the group member entry, to be compared to any > offered user PAC. > - > + > + From pspacek at redhat.com Thu Oct 17 10:45:49 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 17 Oct 2013 12:45:49 +0200 Subject: [Freeipa-devel] [DOC] Image missing: sync-adpwdpolicy Message-ID: <525FBFDD.7010504@redhat.com> Hello, today I noticed that publican cries about missing image: Image missing: tmp/en-US/xml/images/sync-adpwdpolicy.png I tried to compile documentation from our git repo: commit f2e089aac386855e302d2d4b1a36f7e6b43c0e50 Martin, could you find where the image got lost and add it back to the repo? Thank you! -- Petr^2 Spacek From abokovoy at redhat.com Thu Oct 17 10:45:44 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Oct 2013 13:45:44 +0300 Subject: [Freeipa-devel] [PATCH] 0125 Trusts documentation update In-Reply-To: <20131017103151.GA3517@localhost.localdomain> References: <20131016153132.GB25335@redhat.com> <20131017103151.GA3517@localhost.localdomain> Message-ID: <20131017104544.GF25335@redhat.com> On Thu, 17 Oct 2013, Sumit Bose wrote: >On Wed, Oct 16, 2013 at 06:31:32PM +0300, Alexander Bokovoy wrote: >> Hi! >> >> Attached is first update to AD trusts documentation for FreeIPA user >> guide. I've fixed number of outdated statements and added some more >> material. >> >> More patches will follow to cover functionality up to FreeIPA 3.3.2. > >The new content looks good, I only found a few minor issues, see below. Thanks! I've fixed mentioned issues. New patch is attached. -- / Alexander Bokovoy -------------- next part -------------- >From a6564ef1424ed86325e7e439c83578f0d7611261 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 16 Oct 2013 18:25:55 +0300 Subject: [PATCH] Update Trust.xml to be on par with FreeIPA 3.3 --- src/user_guide/en-US/Trust.xml | 240 ++++++++++++++++++++++++++++------------- 1 file changed, 165 insertions(+), 75 deletions(-) diff --git a/src/user_guide/en-US/Trust.xml b/src/user_guide/en-US/Trust.xml index 0f89c79..fa63952 100644 --- a/src/user_guide/en-US/Trust.xml +++ b/src/user_guide/en-US/Trust.xml @@ -2,12 +2,19 @@ - Identity: Integrating with Active Directory Through Cross-Realm Kerberos Trusts &TITLE_TPREVIEW; - - Kerberos allows the configuration of trusted realms. Each realm has its own - resources and users, yet the trust relationship allows users of any trusted realm to obtain tickets - and connect to machines or services in a peer realm as if they were members of that peer realm. - + Identity: Integrating with Active Directory Through Cross-Realm Kerberos Trusts &TITLE_TPREVIEW; + + Active Directory is a Microsoft's implementation of LDAP, Kerberos, + SMB, and few other protocol families. While there are many differences + in the way these protocol families are implemented, in its core + trusting one &AD; domain to another means establishing relationships + between the two domains on the Kerberos protocol level. Kerberos + allows the configuration of trusted realms. Each + realm has its own resources and users, yet the trust relationship + allows users of any trusted realm to obtain tickets and connect to + machines or services in a peer realm as if they were members of that + peer realm. + Because of differences in the way that Windows and Linux domains implement LDAP services, DNS management, and even Kerberos realms, it is difficult to establish a direct trust between &AD; @@ -15,6 +22,18 @@ the Kerberos trust and DNS mappings so that &AD; users can access Linux hosts and services completely transparently, using one set of credentials. + + &AD; was implemented on top of existing domain membership as provided by SMB + protocol. In order to give short transition path for existing + deployments, many of the concepts from SMB protocol are used + internally by &AD;. Trust relationship is one of these; establishing + trust between two domains, in fact, requires execution of an SMB + command sequence that leads to creation of specialized accounts in LDAP + storage of domain controllers in both domains. When this step is + performed, resulting accounts can be used to perform Kerberos + authentication against the other domain and represent shared ticket and + key for Kerberos cross-realm trust. +
The Meaning of "Trust" @@ -45,13 +64,19 @@ - Samba, to perform identity lookups on &AD; and retrieve user and group security identifiers (SIDs) for authorization information - + Samba, to perform SMB protocol operations against + domain controllers in &AD; and represent points of + communication that &AD; domain controllers expect to + exist in another &AD; domain + - SSSD, to cache user, group, and ticket information for users and to map Kerberos and DNS domains - + SSSD, to query and cache user, group, and Kerberos + ticket information for users from &AD;. SSSD also maps + Security Identifiers of user and group objects on &AD; + side to user and group identifiers on &IPA; side + @@ -86,17 +111,36 @@ - Trusts, then, are essentially unidirectional. &AD; users can access &IPA; resources and services, but &IPA; users - cannot access &AD; resources. Trust allows Windows administrators and users to be able to access and manage Linux resourcesTrusted users, however, + Trust relationship is unidirectional. &AD; users can access + &IPA; resources and services, but &IPA; users cannot access + &AD; resources. Trust allows Windows administrators and users + to be able to access and manage Linux + resourcesTrusted users, however, cannot manage &PROD; itself.. - - - A trust relationship is established between a single &AD; domain and a single &IPA; domain. - + + + + It is worth to note that while a single trust relationship is + unidirectional, &IPA; technically establishes bidirectional + trust relationships with &AD; and internally uses &IPA; to &AD; + trust path to query &AD; users membership information from &AD; + domain controllers. However, to allow full access for &IPA; + users to &AD; resources, &IPA; needs to advance its + implementation of Global Catalog service as required by + &AD;-compliant domains. + + + + &AD; may contain a number of subordinated domains. In this case + one &AD; domain is called forest root + domain. A trust + relationship is established between a single &AD; forest + root domain and a single &IPA; domain. + NOTE No Windows machine can be a client of the &IPA; domain in a trust environment. - All Windows machines must be in the &AD; domain. + All Windows machines must be in an &AD; domain. @@ -163,39 +207,74 @@
Kerberos Realms, Authentication, and Authorization - Group information in &AD; is stored in a list of identifiers in each Kerberos ticket for - &AD; users in a special dataset called privileged access certificates - or MS-PAC. The group information in the PAC has to be mapped to the &AD; groups and then - to the corresponding &IPA; groups to help determine access. A PAC is essentially an account usability - extension. - - - Understanding the group mapping for trusts can help clarify how groups should be structured - in trust environments. - + Each object in &AD; can be addressed using its + Security Identifier (SID). Users, groups, + machine accounts, and other objects all have associated SIDs. + In some cases there could be more than one SID associated with + an object. For performance purposes information about SIDs of + related objects, including group membership, is stored in each + Kerberos ticket for &AD; users in a special dataset called + privileged access certificates or MS-PAC. + MS-PAC is issued as part of the Kerberos ticket and digitally + signed by the &AD; domain controller that issued the ticket. + Digital signature allows to verify authenticity of the + information and avoid requesting it over and over again from + &AD; domain controllers, making more efficient use of network + and computing resources. + - - Microsoft uses a special authorization structure called privileged access certificates - or MS-PAC. A PAC is embedded in a Kerberos ticket as a way of identifying the entity to other Windows clients and servers in the Windows domain. - - - On &IPA; resources, if an &AD; user requests a ticket for a service, then &IPA; - forwards the request - to &AD; to retrieve the user information. The PAC information sent back by &AD; - is embedded in the Kerberos ticket. + + Understanding the group mapping for trusts can help clarify how + groups should be structured in trust environments. + + + + When an &AD; user requests a ticket for a service in &IPA; + domain, it presents a cross-realm ticket granting ticket (TGT) + issued to an &AD; user by an &AD; domain controller. This + ticket contains MS-PAC information, signed by the &AD; domain controller. + + + &IPA; KDC, upon request to issue a ticket for a service in &IPA; domain, + verifies MS-PAC information in an &AD; user ticket. If it + contains any security identifier that + should be filtered out and not allowed to access &IPA; domain, + the request to obtain a service ticket is rejected. + + + + If &IPA; KDC issues the ticket to the service in &IPA; domain, + &AD; security identifiers from MS-PAC are used to map an &AD; + user membership to &IPA; groups. If an &AD; SID is an + external member of &IPA; group, &IPA; KDC + will track down any POSIX group this group is included into and + will add its SID to MS-PAC structure. + + + + Resulting ticket to the &IPA; service is digitally signed by + &IPA; KDC. Its MS-PAC information will contain SIDs of original + &AD; objects and &IPA; POSIX groups of which these objects are + external members. This ticket is then used by a software that + requested the ticket to connect to the actual &IPA; service. + + + + When the connection request comes to &IPAA; client, &IPA; + (through SSSD, as &IPAA; client), extracts the &AD; + security identifiers from the PAC and maps + them to POSIX group and user identifiers. The user is granted + access to the &IPA;-hosted services according to their access + rules. Additionally, the &IPA; group information in the SSSD + user cache is updated to include the mapped &IPA; groups for + the &AD; user. + NOTE All Kerberos communication for both &AD; and &IPA; for trusts uses GSS-API. - - &IPA; (through SSSD, as &IPAA; client), extracts the &AD; group security - identifiers (SIDs) from the PAC. &IPA; then compares the &AD; SIDs in the PAC - to the group SIDs configured as members in &IPA; groups. If the &AD; group is - a member of &IPAA; group, then the &IPA; group SID is added to the PAC, and the - Kerberos ticket is updated with the new PAC. -
&IPA;, SSSD, and &AD; @@ -205,15 +284,6 @@
- That new ticket is then used to generate a service ticket for the user, and - the user is granted access to the &IPA;-hosted services. - according to their access rules. Additionally, the &IPA; group information in the - SSSD user cache is updated to include the mapped &IPA; groups for the &AD; user. - - - SSSD stores multiple TGTs and tickets for each user, as new services are accessed. - - A simpler way of saying this is that &AD; supplies a list of groups for each user, based on an identifier for the group. &IPA; compares that list of &AD; groups to memberships in &IPA; groups (where each group member is identified @@ -224,36 +294,56 @@ The crucial factor to realize in this is that &AD; users are recognized to the &IPA; domain not by their &AD; user entry, but - by their &AD; group memberships. + by their &IPA; group memberships. In a sense, &AD; users are not trusted by the &IPA; domain - — &AD; groups are. - - - But this method of mapping &AD; group SIDs to &IPA; group members means that - group structure in &IPA; is important. &AD; groups have different attributes - than Linux groups and, therefore, different attributes than &IPA; groups. Most - critically, &AD; groups are not POSIX groups, while &IPA; groups are. - - - &IPA; has introduced an intermediary, non-POSIX group type, external groups, which - allow entities outside &IPA; or a Linux system to be added as member. That external group can then be - added to a standard &IPA; (POSIX) group as a member. - + — &IPA; groups are. + + + + Since in POSIX environment every running process should be + running under some user and have some group membership to + access files, it is important that every user of &IPA; services has + corresponding POSIX identifier and user belongs to some groups + which have POSIX identifiers. Each &AD; user, therefore, should + have membership in some POSIX group to be able to access files + and run processes in &IPA; domain. + + + + Additionally, &AD; user entries are never stored in &IPA; LDAP + and cannot be addressed by a DN. Group members in &IPA; LDAP + always addressed by their DNs. This means &AD; users cannot be + directly added to &IPA; POSIX groups. + + + + &IPA; LDAP schema supports nested group membership. Each &IPA; + group may include another &IPA; group as its member. When + membership information is processed by &IPA; KDC or SSSD, + nested groups are unrolled and whole set of members is + flattened. + + + + &IPA; has introduced an intermediary, non-POSIX group type, + external groups, which allow entities + outside &IPA; or a Linux system to be added as a member. That + external group can then be added to a standard &IPA; (POSIX) + group as a member. + + - When &AD; groups are added to &IPAA; group, they can be idenfitied by + When &AD; objects are added to &IPAA; group, they can be identified by their SID or by name, in the formats DOMAIN\group_name or - group_name at domain. &IPA; then resolves the group name to + group_name at domain. &IPA; then resolves the object name to the SID and stores the SID as the group member entry, to be compared to any offered user PAC. - + + Actually configuring groups for &AD; users is described in . - - IMPORTANT - - Both &AD; and &PROD; must be configured with integrated certificate services. - - + + All sessions in a trust environment are ultimately secured with Kerberos tickets, but users have different login options: -- 1.8.3.1 From mkosek at redhat.com Thu Oct 17 10:58:51 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 17 Oct 2013 12:58:51 +0200 Subject: [Freeipa-devel] [DOC] Image missing: sync-adpwdpolicy In-Reply-To: <525FBFDD.7010504@redhat.com> References: <525FBFDD.7010504@redhat.com> Message-ID: <525FC2EB.2080806@redhat.com> On 10/17/2013 12:45 PM, Petr Spacek wrote: > Hello, > > today I noticed that publican cries about missing image: > Image missing: tmp/en-US/xml/images/sync-adpwdpolicy.png > > I tried to compile documentation from our git repo: > commit f2e089aac386855e302d2d4b1a36f7e6b43c0e50 > > Martin, could you find where the image got lost and add it back to the repo? > > Thank you! > This file is missing even in the forked repo. Deon, could you please help us solve this mystery? :) Thank you, Martin From mbasti at redhat.com Thu Oct 17 11:00:45 2013 From: mbasti at redhat.com (Martin Basti) Date: Thu, 17 Oct 2013 13:00:45 +0200 Subject: [Freeipa-devel] [DOC] Image missing: sync-adpwdpolicy In-Reply-To: <525FBFDD.7010504@redhat.com> References: <525FBFDD.7010504@redhat.com> Message-ID: <1382007645.11804.0.camel@unused-4-145.brq.redhat.com> On Thu, 2013-10-17 at 12:45 +0200, Petr Spacek wrote: > Hello, > > today I noticed that publican cries about missing image: > Image missing: tmp/en-US/xml/images/sync-adpwdpolicy.png > > I tried to compile documentation from our git repo: > commit f2e089aac386855e302d2d4b1a36f7e6b43c0e50 > > Martin, could you find where the image got lost and add it back to the repo? > > Thank you! > It missing from initial commit, I will try to find it in old docs. -- Martin Basti From mbasti at redhat.com Thu Oct 17 11:03:00 2013 From: mbasti at redhat.com (Martin Basti) Date: Thu, 17 Oct 2013 13:03:00 +0200 Subject: [Freeipa-devel] [PATCH][DOC] 0013 Chapter 13 Managing the Kerberos domain update Message-ID: <1382007780.11804.2.camel@unused-4-145.brq.redhat.com> Contains minor fixes in examples only. Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0013-Chapter-13-Managing-the-Kerberos-Domain-update.patch Type: text/x-patch Size: 104355 bytes Desc: not available URL: From mbasti at redhat.com Thu Oct 17 11:04:52 2013 From: mbasti at redhat.com (Martin Basti) Date: Thu, 17 Oct 2013 13:04:52 +0200 Subject: [Freeipa-devel] [DOC] Image missing: sync-adpwdpolicy In-Reply-To: <525FC2EB.2080806@redhat.com> References: <525FBFDD.7010504@redhat.com> <525FC2EB.2080806@redhat.com> Message-ID: <1382007892.11804.3.camel@unused-4-145.brq.redhat.com> On Thu, 2013-10-17 at 12:58 +0200, Martin Kosek wrote: > On 10/17/2013 12:45 PM, Petr Spacek wrote: > > Hello, > > > > today I noticed that publican cries about missing image: > > Image missing: tmp/en-US/xml/images/sync-adpwdpolicy.png > > > > I tried to compile documentation from our git repo: > > commit f2e089aac386855e302d2d4b1a36f7e6b43c0e50 > > > > Martin, could you find where the image got lost and add it back to the repo? > > > > Thank you! > > > > This file is missing even in the forked repo. Deon, could you please help us > solve this mystery? :) > > Thank you, > Martin I won't find it then. :) -- Martin Basti From pviktori at redhat.com Thu Oct 17 12:07:11 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 17 Oct 2013 14:07:11 +0200 Subject: [Freeipa-devel] [PATCH] 429 Administrative password change does not respect password policy In-Reply-To: <5256D0B3.40403@redhat.com> References: <5256D0B3.40403@redhat.com> Message-ID: <525FD2EF.8070606@redhat.com> On 10/10/2013 06:07 PM, Martin Kosek wrote: > When Directory Manager or a PassSync agent is changing a password, > it is not being expired, but standard expiration time should apply. > However, default expiration time was always applied (90 days) > even though administrator may have a custom policy for the user. > > https://fedorahosted.org/freeipa/ticket/3968 > I had to work around https://fedorahosted.org/389/ticket/47329 when testing this, but I was able to verify that it fixes the issue. ACK, pushed to master: 5d8c02cfb8ce92fa7d92f3e34bfd7501672cc208 ipa-3-3: 9bb9354a40175fd6664bdde66bd605ffb6bf1389 -- Petr? From jcholast at redhat.com Thu Oct 17 12:21:21 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 17 Oct 2013 14:21:21 +0200 Subject: [Freeipa-devel] [PATCHES] 172-196 Refactor certificate renewal code Message-ID: <525FD641.20202@redhat.com> 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. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-172-Move-CACERT-definition-to-a-single-place.patch Type: text/x-patch Size: 12152 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-173-Do-not-create-CA-certificate-files-in-CA-less-server.patch Type: text/x-patch Size: 2029 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-174-Use-LDAP-API-to-upload-CA-certificate-instead-of-lda.patch Type: text/x-patch Size: 2812 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-175-Upload-CA-certificate-from-DS-NSS-database-in-CA-les.patch Type: text/x-patch Size: 3106 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-176-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-Show-progress-when-enabling-SSL-in-DS-in-ipa-server-.patch Type: text/x-patch Size: 3253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-178-Add-Dogtag-service-name-to-Dogtag-constants.patch Type: text/x-patch Size: 7410 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-179-Do-not-start-the-service-in-stopped_service-if-it-wa.patch Type: text/x-patch Size: 1115 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-180-Use-certmonger-D-Bus-API-to-configure-certmonger-in-.patch Type: text/x-patch Size: 5235 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-181-Add-new-certmonger-CA-helper-dogtag-ipa-ca-renew-age.patch Type: text/x-patch Size: 4388 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-182-Update-pkcs10-module-functions-to-always-load-CSRs-a.patch Type: text/x-patch Size: 5459 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-183-Remove-unused-function-get_subjectaltname-from-the-c.patch Type: text/x-patch Size: 1300 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-184-Add-function-for-parsing-friendly-name-from-certific.patch Type: text/x-patch Size: 2835 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-185-Support-retrieving-renewed-certificates-from-LDAP-in.patch Type: text/x-patch Size: 3740 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-186-Use-dogtag-ipa-ca-renew-agent-to-retrieve-renewed-ce.patch Type: text/x-patch Size: 4871 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-187-Remove-dogtag-ipa-retrieve-agent-submit.patch Type: text/x-patch Size: 4780 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-188-Support-storing-renewed-certificates-to-LDAP-in-dogt.patch Type: text/x-patch Size: 5246 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-189-Use-dogtag-ipa-ca-renew-agent-to-track-certificates-.patch Type: text/x-patch Size: 12333 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-190-Move-is_master-from-cainstance.CAInstance-to-cainsta.patch Type: text/x-patch Size: 2959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-191-Make-the-default-dogtag-ipa-ca-renew-agent-behavior-.patch Type: text/x-patch Size: 3043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-192-Merge-restart_pkicad-functionality-to-renew_ca_cert-.patch Type: text/x-patch Size: 7274 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-193-Merge-restart_httpd-functionality-to-renew_ra_cert.patch Type: text/x-patch Size: 2132 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-194-Use-the-same-certmonger-configuration-for-both-CA-ma.patch Type: text/x-patch Size: 8746 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-195-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-Support-exporting-CSRs-in-dogtag-ipa-ca-renew-agent.patch Type: text/x-patch Size: 1755 bytes Desc: not available URL: From jcholast at redhat.com Thu Oct 17 13:27:20 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 17 Oct 2013 15:27:20 +0200 Subject: [Freeipa-devel] [PATCH] 197 Track DS certificate with certmonger on replicas Message-ID: <525FE5B8.8090702@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-197-Track-DS-certificate-with-certmonger-on-replicas.patch Type: text/x-patch Size: 3052 bytes Desc: not available URL: From rcritten at redhat.com Thu Oct 17 13:40:48 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 17 Oct 2013 09:40:48 -0400 Subject: [Freeipa-devel] [PATCH] 197 Track DS certificate with certmonger on replicas In-Reply-To: <525FE5B8.8090702@redhat.com> References: <525FE5B8.8090702@redhat.com> Message-ID: <525FE8E0.3010301@redhat.com> Jan Cholasta wrote: > Hi, > > the attached patch fixes . Just thinking out loud here, haven't tried it... What about creating a replica on a non-CA host, I think it wouldn't be tracked. Can you use the value or existence of api.env.ra_plugin instead? rob From jcholast at redhat.com Thu Oct 17 14:45:30 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 17 Oct 2013 16:45:30 +0200 Subject: [Freeipa-devel] [PATCH] 197 Track DS certificate with certmonger on replicas In-Reply-To: <525FE8E0.3010301@redhat.com> References: <525FE5B8.8090702@redhat.com> <525FE8E0.3010301@redhat.com> Message-ID: <525FF80A.9040607@redhat.com> On 17.10.2013 15:40, Rob Crittenden wrote: > Jan Cholasta wrote: >> Hi, >> >> the attached patch fixes . > > Just thinking out loud here, haven't tried it... > > What about creating a replica on a non-CA host, I think it wouldn't be > tracked. AFAIU cacert.p12 is always put in the replica info file, it does not matter whether ipa-replica-prepare is run on a CA host or not (see ReplicaPrepare.copy_ds_certificate: ). > > Can you use the value or existence of api.env.ra_plugin instead? > > rob -- Jan Cholasta From pspacek at redhat.com Thu Oct 17 15:06:37 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 17 Oct 2013 17:06:37 +0200 Subject: [Freeipa-devel] [DOC][PATCH 0004] Remove obsolete options related to DNS Message-ID: <525FFCFD.4070808@redhat.com> Hello, this patch removes obsolete options related to DNS. It applies on top of Martin^2's patch no. 11. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0004-Remove-obsolete-options-related-to-DNS.patch Type: text/x-patch Size: 15091 bytes Desc: not available URL: From pviktori at redhat.com Thu Oct 17 16:01:27 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 17 Oct 2013 18:01:27 +0200 Subject: [Freeipa-devel] [PATCHES] 172-196 Refactor certificate renewal code In-Reply-To: <525FD641.20202@redhat.com> References: <525FD641.20202@redhat.com> Message-ID: <526009D7.2040702@redhat.com> 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() 174. Looks good 175. This line in upload_ca_cert() seems redundant: name = certdb.cacert_name 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) 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. Nitpick - PEP8 explicitly says to avoid aligning with extra spaces: http://www.python.org/dev/peps/pep-0008/#pet-peeves Please use a docstring for documenting what request_cert() does, and describe the return value. 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? Did you consider using `traceback.format_exc` for logging errors? Full tracebacks tend to be more useful than just type & message. 182. I don't understand why you reordered get_subjectaltname & get_subject, that makes it hard to see what changed. 183. Looks good 184. Looks OK 185. ldap_connect: conn.disconnect() should be in a finally clause 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(). main: Shouldn't we rather raise an error if CERTMONGER_CA_PROFILE has some unknown value? 186. I'm getting lost in all the arguments to dogtag_start_tracking(). Could you name them when calling it? 187. I think one changelog entry for all these patches is enough. 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". When store_cert() runs out of attempts, it should not return ISSUED. The exception should be re-raised so it's logged. 189. Again, naming arguments in dogtag_start_tracking calls would make them clearer 190. Instead of dogtag.install_constants, this should use configured_constants(). 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. 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. 195. Looks OK 196. Again, please use docstrings for documenting functions. -- Petr? From jcholast at redhat.com Thu Oct 17 16:08:08 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 17 Oct 2013 18:08:08 +0200 Subject: [Freeipa-devel] [PATCH] 0119 Switch client to JSON-RPC In-Reply-To: <5252DE69.9050004@redhat.com> References: <50F53F2B.4020406@redhat.com> <511CF3D3.80107@redhat.com> <5159FE2B.306@redhat.com> <518D0A2F.6040401@redhat.com> <51FB781D.4060201@redhat.com> <520899FD.9060202@redhat.com> <5252DE69.9050004@redhat.com> Message-ID: <52600B68.3060902@redhat.com> Hi, On 7.10.2013 18:16, Petr Viktorin wrote: > On 08/12/2013 10:17 AM, Petr Viktorin wrote: >> On 08/02/2013 11:13 AM, Petr Viktorin wrote: >>> On 05/10/2013 04:54 PM, Petr Viktorin wrote: >>>> On 04/01/2013 11:37 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 01/15/2013 12:36 PM, Petr Viktorin wrote: >>>>>>> I meant to hold this patch a while longer to let it mature, but from >>>>>>> what Brian Smith asked on the user list it seems it could help him. >>>>>>> >>>>>>> Design: http://freeipa.org/page/V3/JSON-RPC >>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3299 >>>>>>> >>>>>>> See the design page for what the patch does. >>>>>>> >>>>>>> >>>>>>> As much as I've tried to avoid them, the code includes some >>>>>>> workarounds: >>>>>>> It extends xmlrpclib to also support JSON. This is rather intrusive, >>>>>>> but >>>>>>> to not do that I'd need to write a parallel stack for JSON, without >>>>>>> the >>>>>>> help of a standard library. It would be nice to write the JSON stack in the future anyway, this indeed seems intrusive to me. >>>>>>> The registration of either jsonclient or xmlclient as "rpcclient" in >>>>>>> the >>>>>>> API also needs a bit of magic, since the framework requires the >>>>>>> class >>>>>>> name to match the attribute. You could also put the name of the plugin in a configuration option and address the plugin like "api.Backend[api.env.rpcclient_plugin]", but I guess your solution is no worse. >>>>>>> >>>>>>> >>>>>>> To prevent backwards compatibility problems, we need to ensure that >>>>>>> all >>>>>>> official JSON clients send the API version, so this patch should be >>>>>>> applied after my patches 0104-0106. >>>>>>> >>>>>> >>>>>> Updating to current master. >>>>> >>>>> Please reverse this change in ipalib/rpc.py: >>>>> >>>>> @@ -665,8 +788,6 @@ class xmlclient(Connectible): >>>>> except Exception, e: >>>>> if not fallback: >>>>> raise >>>>> - else: >>>>> - self.log.info('Connection to %s failed with %s', >>>>> url, e) >>>>> serverproxy = None >>>>> >>>>> This logs connection errors when the client fails over to another >>>>> server. >>>> >>>> Thanks. Done, and rebased to master. Thanks for the patch, it works for me. I have just a few nitpicks: def forward(self, *args, **kw): """ - Forward call over XML-RPC to this same command on server. + Forward call over JSON-RPC to this same command on server. The new docstring is not entirely true. + def send_content(self, connection, request_body): + if self.protocol == 'json': + connection.putheader("Content-Type", "application/json") + else: + connection.putheader("Content-Type", "text/xml") + + connection.putheader("Content-Length", str(len(request_body))) + connection.endheaders(request_body) The original implementation of send_content in the Transport class sets up gzip compression. I think it may be useful to do it here as well. + def rpc_uri_from_env(self, env): + raise NotImplementedError('RPCClient.rpc_uri_from_env') ... - xmlrpc_uri = self.env.xmlrpc_uri + rpc_uri = self.rpc_uri_from_env(self.env) I don't think this is necessary, since Env is also a mapping, you can do this instead: + env_rpc_uri_var = None ... - xmlrpc_uri = self.env.xmlrpc_uri + rpc_uri = self.env[env_rpc_uri_var] +class xmlclient(RPCClient): + session_path = '/ipa/session/xml' + server_proxy_class = ServerProxy + protocol = 'xml' + wrap_functions = xml_wrap, xml_unwrap ... +class jsonclient(RPCClient): + session_path = '/ipa/session/json' + server_proxy_class = JSONServerProxy + protocol = 'json' + wrap_functions = identity, identity It seems to me that json_encode_binary and json_decode_binary are equivallent to xml_wrap and xml_unwrap, is there a reason you used the identity function in jsonclient.wrap_functions? >>>> >>>>> The changes look really good. The show stopper is that using jsonrpc >>>>> doesn't create a session key. I noticed that xmlrpc_uri is hardcoded >>>>> into ipalib/session.py but it appears the issue is deeper than that. >>>> >>>> That uses only the hostname from xmlrpc_uri. When using different >>>> hostnames in xmlrpc_uri and jsonrpc_uri *on the server*, it'll put the >>>> wrong domain in the cookie. In this case I think it's the configuration >>>> that's wrong. >>>> >>>> The real problem is that KerberossSession code which creates the >>>> cookie, >>>> was not called by the JSON server. >>>> Patch 0223 adds it. ACK. >>>> >>>> Patch 0224 adds the server class name (e.g. [jsonserver_kerb]) to the >>>> server logs. It should help debug problems specific to a >>>> backend/protocol. ACK. >>> >>> Rebased onto current master. >>> >> >> Another minor rebase > > > Rebased again. > Honza -- Jan Cholasta From jcholast at redhat.com Thu Oct 17 16:59:10 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 17 Oct 2013 18:59:10 +0200 Subject: [Freeipa-devel] [PATCHES] 172-196 Refactor certificate renewal code In-Reply-To: <526009D7.2040702@redhat.com> References: <525FD641.20202@redhat.com> <526009D7.2040702@redhat.com> Message-ID: <5260175E.50809@redhat.com> 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. > > -- Jan Cholasta From akrivoka at redhat.com Thu Oct 17 20:12:32 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 17 Oct 2013 22:12:32 +0200 Subject: [Freeipa-devel] [PATCH] 0075 Add ipa-advise plugins for nss-pam-ldapd legacy clients Message-ID: <526044B0.3020403@redhat.com> Hello, This patch adds ipa-advise plugins for configuring legacy clients using nss-pam-ldapd. https://fedorahosted.org/freeipa/ticket/3672 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0075-Add-ipa-advise-plugins-for-nss-pam-ldapd-legacy-clie.patch Type: text/x-patch Size: 16365 bytes Desc: not available URL: From abokovoy at redhat.com Thu Oct 17 20:29:38 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 17 Oct 2013 23:29:38 +0300 Subject: [Freeipa-devel] [PATCH] 0075 Add ipa-advise plugins for nss-pam-ldapd legacy clients In-Reply-To: <526044B0.3020403@redhat.com> References: <526044B0.3020403@redhat.com> Message-ID: <20131017202938.GI25335@redhat.com> On Thu, 17 Oct 2013, Ana Krivokapic wrote: >Hello, > >This patch adds ipa-advise plugins for configuring legacy clients using >nss-pam-ldapd. > >https://fedorahosted.org/freeipa/ticket/3672 Thanks. Looks good. I have one comment below >+class config_freebsd_nss_pam_ldapd(config_base_legacy_client): >+ """ >+ Legacy client configuration for FreeBSD, using nss-pam-ldapd. >+ """ >+ description = ('Instructions for configuring a FreeBSD system with ' >+ 'nss-pam-ldapd. ') >+ >+ def get_info(self): >+ uri, base = self.get_uri_and_base() >+ cacrt = '/usr/local/etc/ipatest.crt' Is the cert file name is correct? 'ipatest.crt'? Perhaps 'ipaca.crt' would be a better name? >+ >+ self.check_compat_plugin() >+ >+ with open(os.path.join( >+ SHARE_DIR, >+ 'advise', >+ 'legacy', >+ 'pam_conf_sshd.template')) as fd: >+ pam_conf = fd.read() >+ >+ self.log.comment('Install required packages') >+ self.log.command('pkg_add -r nss-pam-ldapd curl\n') >+ >+ self.configure_ca_cert(cacrt) >+ >+ self.log.comment('Configure nsswitch.conf') >+ self.log.command('sed -i \'\' -e \'s/^passwd:/passwd: files ldap/\' ' >+ '/etc/nsswitch.conf') >+ self.log.command('sed -i \'\' -e \'s/^group:/group: files ldap/\' ' >+ '/etc/nsswitch.conf\n') >+ >+ self.log.comment('Configure PAM stack for the sshd service') >+ self.log.command('cat > /etc/pam.d/sshd << EOF \n' >+ '%s\nEOF\n' % pam_conf) >+ >+ self.log.comment('Add automated start of nslcd to /etc/rc.conf') >+ self.log.command('echo \'nslcd_enable="YES"\nnslcd_debug="NO"\' >> ' >+ '/etc/rc.conf') >+ >+ self.log.comment('Configure nslcd.conf:') >+ self.log.command('echo "uid nslcd\n' >+ 'gid nslcd\n' >+ 'uri %s\n' >+ 'base %s\n' >+ 'scope sub\n' >+ 'base group cn=groups,%s\n' >+ 'base passwd cn=users,%s\n' >+ 'base shadow cn=users,%s\n' >+ 'ssl start_tls\n' >+ 'tls_cacertfile %s\n" > /usr/local/etc/nslcd.conf' >+ % ((uri,) + (base,)*4 + (cacrt,))) >+ >+ self.log.comment('Configure ldap.conf:') >+ self.log.command('echo "uri %s\nbase %s\nssl start_tls\ntls_cacert %s"' >+ '> /usr/local/etc/ldap.conf' % (uri, base, cacrt)) >+ >+ self.log.comment('Restart nslcd') >+ self.log.command('/usr/local/etc/rc.d/nslcd restart') >+ >+ def configure_ca_cert(self, cacrt): >+ self.log.comment('Download the CA certificate of the IPA server') >+ self.log.command('curl -k https://%s/ipa/config/ca.crt > ' >+ '%s' % (api.env.host, cacrt)) >+ >+ >+api.register(config_freebsd_nss_pam_ldapd) -- / Alexander Bokovoy From mkosek at redhat.com Fri Oct 18 07:48:50 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 18 Oct 2013 09:48:50 +0200 Subject: [Freeipa-devel] [PATCH] 0075 Add ipa-advise plugins for nss-pam-ldapd legacy clients In-Reply-To: <20131017202938.GI25335@redhat.com> References: <526044B0.3020403@redhat.com> <20131017202938.GI25335@redhat.com> Message-ID: <5260E7E2.60601@redhat.com> On 10/17/2013 10:29 PM, Alexander Bokovoy wrote: > On Thu, 17 Oct 2013, Ana Krivokapic wrote: > >> Hello, >> >> This patch adds ipa-advise plugins for configuring legacy clients using >> nss-pam-ldapd. >> >> https://fedorahosted.org/freeipa/ticket/3672 > Thanks. Looks good. I have one comment below > >> +class config_freebsd_nss_pam_ldapd(config_base_legacy_client): >> + """ >> + Legacy client configuration for FreeBSD, using nss-pam-ldapd. >> + """ >> + description = ('Instructions for configuring a FreeBSD system with ' >> + 'nss-pam-ldapd. ') >> + >> + def get_info(self): >> + uri, base = self.get_uri_and_base() >> + cacrt = '/usr/local/etc/ipatest.crt' > Is the cert file name is correct? 'ipatest.crt'? Perhaps 'ipaca.crt' > would be a better name? Or simply ipa.crt since it is the filename used everywhere else... Martin From pvoborni at redhat.com Fri Oct 18 10:24:38 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 18 Oct 2013 12:24:38 +0200 Subject: [Freeipa-devel] [PATCHES] 0311-0312 Use new CLI options in certinstall tests In-Reply-To: <525584FE.9050002@redhat.com> References: <525584FE.9050002@redhat.com> Message-ID: <52610C66.5070703@redhat.com> On 10/09/2013 06:31 PM, Petr Viktorin wrote: > Patch 0311: one-liner (or one-byter) to fix the last certinstall test > > Patch 0312 adds tests for > http://www.freeipa.org/page/V3/ipa-server-certinstall_CLI_cleanup > > ACK -- Petr Vobornik From pviktori at redhat.com Fri Oct 18 10:26:33 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Oct 2013 12:26:33 +0200 Subject: [Freeipa-devel] [PATCH] 0119 Switch client to JSON-RPC In-Reply-To: <52600B68.3060902@redhat.com> References: <50F53F2B.4020406@redhat.com> <511CF3D3.80107@redhat.com> <5159FE2B.306@redhat.com> <518D0A2F.6040401@redhat.com> <51FB781D.4060201@redhat.com> <520899FD.9060202@redhat.com> <5252DE69.9050004@redhat.com> <52600B68.3060902@redhat.com> Message-ID: <52610CD9.8070506@redhat.com> On 10/17/2013 06:08 PM, Jan Cholasta wrote: > Hi, > > On 7.10.2013 18:16, Petr Viktorin wrote: >> On 08/12/2013 10:17 AM, Petr Viktorin wrote: >>> On 08/02/2013 11:13 AM, Petr Viktorin wrote: >>>> On 05/10/2013 04:54 PM, Petr Viktorin wrote: >>>>> On 04/01/2013 11:37 PM, Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>>>> On 01/15/2013 12:36 PM, Petr Viktorin wrote: >>>>>>>> I meant to hold this patch a while longer to let it mature, but >>>>>>>> from >>>>>>>> what Brian Smith asked on the user list it seems it could help him. >>>>>>>> >>>>>>>> Design: http://freeipa.org/page/V3/JSON-RPC >>>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3299 >>>>>>>> >>>>>>>> See the design page for what the patch does. >>>>>>>> >>>>>>>> >>>>>>>> As much as I've tried to avoid them, the code includes some >>>>>>>> workarounds: >>>>>>>> It extends xmlrpclib to also support JSON. This is rather >>>>>>>> intrusive, >>>>>>>> but >>>>>>>> to not do that I'd need to write a parallel stack for JSON, without >>>>>>>> the >>>>>>>> help of a standard library. > > It would be nice to write the JSON stack in the future anyway, this > indeed seems intrusive to me. Yes, it would. >>>>>>>> The registration of either jsonclient or xmlclient as >>>>>>>> "rpcclient" in >>>>>>>> the >>>>>>>> API also needs a bit of magic, since the framework requires the >>>>>>>> class >>>>>>>> name to match the attribute. > > You could also put the name of the plugin in a configuration option and > address the plugin like "api.Backend[api.env.rpcclient_plugin]", but I > guess your solution is no worse. > >>>>>>>> >>>>>>>> >>>>>>>> To prevent backwards compatibility problems, we need to ensure that >>>>>>>> all >>>>>>>> official JSON clients send the API version, so this patch should be >>>>>>>> applied after my patches 0104-0106. >>>>>>>> >>>>>>> >>>>>>> Updating to current master. >>>>>> >>>>>> Please reverse this change in ipalib/rpc.py: >>>>>> >>>>>> @@ -665,8 +788,6 @@ class xmlclient(Connectible): >>>>>> except Exception, e: >>>>>> if not fallback: >>>>>> raise >>>>>> - else: >>>>>> - self.log.info('Connection to %s failed with %s', >>>>>> url, e) >>>>>> serverproxy = None >>>>>> >>>>>> This logs connection errors when the client fails over to another >>>>>> server. >>>>> >>>>> Thanks. Done, and rebased to master. > > Thanks for the patch, it works for me. > > I have just a few nitpicks: > > def forward(self, *args, **kw): > """ > - Forward call over XML-RPC to this same command on server. > + Forward call over JSON-RPC to this same command on server. > > The new docstring is not entirely true. Fixed, thanks > + def send_content(self, connection, request_body): > + if self.protocol == 'json': > + connection.putheader("Content-Type", "application/json") > + else: > + connection.putheader("Content-Type", "text/xml") > + > + connection.putheader("Content-Length", str(len(request_body))) > + connection.endheaders(request_body) > > The original implementation of send_content in the Transport class sets > up gzip compression. I think it may be useful to do it here as well. We don't opt in for gzip compression, so that's unnecessary. I've added a comment. > + def rpc_uri_from_env(self, env): > + raise NotImplementedError('RPCClient.rpc_uri_from_env') > ... > - xmlrpc_uri = self.env.xmlrpc_uri > + rpc_uri = self.rpc_uri_from_env(self.env) > > I don't think this is necessary, since Env is also a mapping, you can do > this instead: > > + env_rpc_uri_var = None > ... > - xmlrpc_uri = self.env.xmlrpc_uri > + rpc_uri = self.env[env_rpc_uri_var] You're right, changed > +class xmlclient(RPCClient): > + session_path = '/ipa/session/xml' > + server_proxy_class = ServerProxy > + protocol = 'xml' > + wrap_functions = xml_wrap, xml_unwrap > ... > +class jsonclient(RPCClient): > + session_path = '/ipa/session/json' > + server_proxy_class = JSONServerProxy > + protocol = 'json' > + wrap_functions = identity, identity > > It seems to me that json_encode_binary and json_decode_binary are > equivallent to xml_wrap and xml_unwrap, is there a reason you used the > identity function in jsonclient.wrap_functions? Yes, it's for unwrapping error results. For JSON, we want the decoding done before the error is raised, but for XML no decoding is done (error results can't contain binary data). I've moved this into a single method, hopefully it's clearer this way. [...] >>>>> KerberossSession code which creates the >>>>> cookie, was not called by the JSON server. >>>>> Patch 0223 adds it. > > ACK. > >>>>> >>>>> Patch 0224 adds the server class name (e.g. [jsonserver_kerb]) to the >>>>> server logs. It should help debug problems specific to a >>>>> backend/protocol. > > ACK. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0222.7-Switch-client-to-JSON-RPC.patch Type: text/x-patch Size: 42470 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0223.7-Make-jsonserver_kerb-start-a-cookie-based-session.patch Type: text/x-patch Size: 1580 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0224.7-Add-server-protocol-type-to-rpcserver-logs.patch Type: text/x-patch Size: 2805 bytes Desc: not available URL: From pviktori at redhat.com Fri Oct 18 10:48:11 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Oct 2013 12:48:11 +0200 Subject: [Freeipa-devel] [PATCHES] 0311-0312 Use new CLI options in certinstall tests In-Reply-To: <52610C66.5070703@redhat.com> References: <525584FE.9050002@redhat.com> <52610C66.5070703@redhat.com> Message-ID: <526111EB.1020806@redhat.com> On 10/18/2013 12:24 PM, Petr Vobornik wrote: > On 10/09/2013 06:31 PM, Petr Viktorin wrote: >> Patch 0311: one-liner (or one-byter) to fix the last certinstall test >> >> Patch 0312 adds tests for >> http://www.freeipa.org/page/V3/ipa-server-certinstall_CLI_cleanup >> >> > ACK Thanks, pushed to: master: c97f4e8a66ce55df3c32d4a198043ad2e7e8e9cd ipa-3-3: bdf9668ed19d9473f25cf196e8bf8c841c48fe24 -- Petr? From pviktori at redhat.com Fri Oct 18 10:55:11 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Oct 2013 12:55:11 +0200 Subject: [Freeipa-devel] [PATCH] [DOC] 0003 Split text commands & descriptions into XML tables. In-Reply-To: References: <525D5D98.7050005@redhat.com> Message-ID: <5261138F.1070609@redhat.com> On 10/15/2013 06:19 PM, J?r?me Fenal wrote: > kk2013/10/15 Martin Kosek : >> Thanks. It would be ideal, if this table is (in future) generated somehow >> semi-automatically as practically all this info can be gathered from FreeIPA >> code. But for now, this is great. >> >> I see some issues with the patch though: >> >> 1) Whitespaces before tabs > > OK, I fixed my attached script my removing leading spaces in the > second part of s///. > >> I fixed some of them with >> sed -i "s/\+\t$/+/g" /tmp/freeipa-jfenal-0003-Split-commands-in-proper-tables.patch >> >> Bug there is the second issue: >> >> 2) Test&build fails: >> >> $ git am /tmp/freeipa-jfenal-0003-Split-commands-in-proper-tables-1.patch >> Applying: Split commands in proper tables >> /home/mkosek/freeipa-docs/.git/rebase-apply/patch:211: space before tab in indent. >> >> /home/mkosek/freeipa-docs/.git/rebase-apply/patch:212: space before tab in indent. >> >> /home/mkosek/freeipa-docs/.git/rebase-apply/patch:213: space before tab in indent. >> automountkey-add >> /home/mkosek/freeipa-docs/.git/rebase-apply/patch:214: space before tab in indent. >> >> /home/mkosek/freeipa-docs/.git/rebase-apply/patch:215: space before tab in indent. >> >> warning: squelched 1849 whitespace errors >> warning: 1854 lines add whitespace errors. > > Will look into that. > > Side question, how did you get the initial text command list? It looks like `ipa help commands` output. -- Petr? From akrivoka at redhat.com Fri Oct 18 11:31:15 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 18 Oct 2013 13:31:15 +0200 Subject: [Freeipa-devel] [PATCH] 0075 Add ipa-advise plugins for nss-pam-ldapd legacy clients In-Reply-To: <5260E7E2.60601@redhat.com> References: <526044B0.3020403@redhat.com> <20131017202938.GI25335@redhat.com> <5260E7E2.60601@redhat.com> Message-ID: <52611C03.8030702@redhat.com> On 10/18/2013 09:48 AM, Martin Kosek wrote: > On 10/17/2013 10:29 PM, Alexander Bokovoy wrote: >> On Thu, 17 Oct 2013, Ana Krivokapic wrote: >> >>> Hello, >>> >>> This patch adds ipa-advise plugins for configuring legacy clients using >>> nss-pam-ldapd. >>> >>> https://fedorahosted.org/freeipa/ticket/3672 >> Thanks. Looks good. I have one comment below >> >>> +class config_freebsd_nss_pam_ldapd(config_base_legacy_client): >>> + """ >>> + Legacy client configuration for FreeBSD, using nss-pam-ldapd. >>> + """ >>> + description = ('Instructions for configuring a FreeBSD system with ' >>> + 'nss-pam-ldapd. ') >>> + >>> + def get_info(self): >>> + uri, base = self.get_uri_and_base() >>> + cacrt = '/usr/local/etc/ipatest.crt' >> Is the cert file name is correct? 'ipatest.crt'? Perhaps 'ipaca.crt' >> would be a better name? > Or simply ipa.crt since it is the filename used everywhere else... > > Martin Cert file name changed to ipa.crt. Comment added about AES not being available on RHEL5. Updated patch attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0075-02-Add-ipa-advise-plugins-for-nss-pam-ldapd-legacy-clie.patch Type: text/x-patch Size: 17056 bytes Desc: not available URL: From akrivoka at redhat.com Fri Oct 18 13:02:13 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 18 Oct 2013 15:02:13 +0200 Subject: [Freeipa-devel] [PATCH] 0075 Add ipa-advise plugins for nss-pam-ldapd legacy clients In-Reply-To: <52611C03.8030702@redhat.com> References: <526044B0.3020403@redhat.com> <20131017202938.GI25335@redhat.com> <5260E7E2.60601@redhat.com> <52611C03.8030702@redhat.com> Message-ID: <52613155.9020505@redhat.com> On 10/18/2013 01:31 PM, Ana Krivokapic wrote: > On 10/18/2013 09:48 AM, Martin Kosek wrote: >> On 10/17/2013 10:29 PM, Alexander Bokovoy wrote: >>> On Thu, 17 Oct 2013, Ana Krivokapic wrote: >>> >>>> Hello, >>>> >>>> This patch adds ipa-advise plugins for configuring legacy clients using >>>> nss-pam-ldapd. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3672 >>> Thanks. Looks good. I have one comment below >>> >>>> +class config_freebsd_nss_pam_ldapd(config_base_legacy_client): >>>> + """ >>>> + Legacy client configuration for FreeBSD, using nss-pam-ldapd. >>>> + """ >>>> + description = ('Instructions for configuring a FreeBSD system with ' >>>> + 'nss-pam-ldapd. ') >>>> + >>>> + def get_info(self): >>>> + uri, base = self.get_uri_and_base() >>>> + cacrt = '/usr/local/etc/ipatest.crt' >>> Is the cert file name is correct? 'ipatest.crt'? Perhaps 'ipaca.crt' >>> would be a better name? >> Or simply ipa.crt since it is the filename used everywhere else... >> >> Martin > Cert file name changed to ipa.crt. > > Comment added about AES not being available on RHEL5. > > Updated patch attached. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel This updated patch improves the note about possible issues regarding encryption algorithms. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0075-03-Add-ipa-advise-plugins-for-nss-pam-ldapd-legacy-clie.patch Type: text/x-patch Size: 17214 bytes Desc: not available URL: From jfenal at gmail.com Fri Oct 18 13:16:15 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Fri, 18 Oct 2013 15:16:15 +0200 Subject: [Freeipa-devel] [PATCH] [DOC] 0003 Split text commands & descriptions into XML tables. In-Reply-To: <5261138F.1070609@redhat.com> References: <525D5D98.7050005@redhat.com> <5261138F.1070609@redhat.com> Message-ID: 2013/10/18 Petr Viktorin : > On 10/15/2013 06:19 PM, J?r?me Fenal wrote: >> >> kk2013/10/15 Martin Kosek : >>> >>> Thanks. It would be ideal, if this table is (in future) generated somehow >>> semi-automatically as practically all this info can be gathered from >>> FreeIPA >>> code. But for now, this is great. >>> >>> I see some issues with the patch though: >>> >>> 1) Whitespaces before tabs >> >> >> OK, I fixed my attached script my removing leading spaces in the >> second part of s///. >> >>> I fixed some of them with >>> sed -i "s/\+\t$/+/g" >>> /tmp/freeipa-jfenal-0003-Split-commands-in-proper-tables.patch >>> >>> Bug there is the second issue: >>> >>> 2) Test&build fails: >>> >>> $ git am /tmp/freeipa-jfenal-0003-Split-commands-in-proper-tables-1.patch >>> Applying: Split commands in proper tables >>> /home/mkosek/freeipa-docs/.git/rebase-apply/patch:211: space before tab >>> in indent. >>> >>> /home/mkosek/freeipa-docs/.git/rebase-apply/patch:212: space before tab >>> in indent. >>> >>> /home/mkosek/freeipa-docs/.git/rebase-apply/patch:213: space before tab >>> in indent. >>> >>> automountkey-add >>> /home/mkosek/freeipa-docs/.git/rebase-apply/patch:214: space before tab >>> in indent. >>> >>> /home/mkosek/freeipa-docs/.git/rebase-apply/patch:215: space before tab >>> in indent. >>> >>> warning: squelched 1849 whitespace errors >>> warning: 1854 lines add whitespace errors. >> >> >> Will look into that. >> >> Side question, how did you get the initial text command list? > > > It looks like `ipa help commands` output. OK, I'll try give it a try to automate the creation of included files here this week-end. Regards, J. -- J?r?me Fenal From abokovoy at redhat.com Fri Oct 18 14:07:23 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 18 Oct 2013 17:07:23 +0300 Subject: [Freeipa-devel] [PATCH] 0075 Add ipa-advise plugins for nss-pam-ldapd legacy clients In-Reply-To: <52613155.9020505@redhat.com> References: <526044B0.3020403@redhat.com> <20131017202938.GI25335@redhat.com> <5260E7E2.60601@redhat.com> <52611C03.8030702@redhat.com> <52613155.9020505@redhat.com> Message-ID: <20131018140723.GJ25335@redhat.com> On Fri, 18 Oct 2013, Ana Krivokapic wrote: >On 10/18/2013 01:31 PM, Ana Krivokapic wrote: >> On 10/18/2013 09:48 AM, Martin Kosek wrote: >>> On 10/17/2013 10:29 PM, Alexander Bokovoy wrote: >>>> On Thu, 17 Oct 2013, Ana Krivokapic wrote: >>>> >>>>> Hello, >>>>> >>>>> This patch adds ipa-advise plugins for configuring legacy clients using >>>>> nss-pam-ldapd. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3672 >>>> Thanks. Looks good. I have one comment below >>>> >>>>> +class config_freebsd_nss_pam_ldapd(config_base_legacy_client): >>>>> + """ >>>>> + Legacy client configuration for FreeBSD, using nss-pam-ldapd. >>>>> + """ >>>>> + description = ('Instructions for configuring a FreeBSD system with ' >>>>> + 'nss-pam-ldapd. ') >>>>> + >>>>> + def get_info(self): >>>>> + uri, base = self.get_uri_and_base() >>>>> + cacrt = '/usr/local/etc/ipatest.crt' >>>> Is the cert file name is correct? 'ipatest.crt'? Perhaps 'ipaca.crt' >>>> would be a better name? >>> Or simply ipa.crt since it is the filename used everywhere else... >>> >>> Martin >> Cert file name changed to ipa.crt. >> >> Comment added about AES not being available on RHEL5. >> >> Updated patch attached. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > >This updated patch improves the note about possible issues regarding encryption >algorithms. Thanks. ACK. -- / Alexander Bokovoy From pviktori at redhat.com Fri Oct 18 14:16:05 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Oct 2013 16:16:05 +0200 Subject: [Freeipa-devel] [PATCH] 0075 Add ipa-advise plugins for nss-pam-ldapd legacy clients In-Reply-To: <20131018140723.GJ25335@redhat.com> References: <526044B0.3020403@redhat.com> <20131017202938.GI25335@redhat.com> <5260E7E2.60601@redhat.com> <52611C03.8030702@redhat.com> <52613155.9020505@redhat.com> <20131018140723.GJ25335@redhat.com> Message-ID: <526142A5.2090403@redhat.com> On 10/18/2013 04:07 PM, Alexander Bokovoy wrote: > On Fri, 18 Oct 2013, Ana Krivokapic wrote: > >> On 10/18/2013 01:31 PM, Ana Krivokapic wrote: >>> On 10/18/2013 09:48 AM, Martin Kosek wrote: >>>> On 10/17/2013 10:29 PM, Alexander Bokovoy wrote: >>>>> On Thu, 17 Oct 2013, Ana Krivokapic wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> This patch adds ipa-advise plugins for configuring legacy clients >>>>>> using >>>>>> nss-pam-ldapd. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3672 >>>>> Thanks. Looks good. I have one comment below >>>>> >>>>>> +class config_freebsd_nss_pam_ldapd(config_base_legacy_client): >>>>>> + """ >>>>>> + Legacy client configuration for FreeBSD, using nss-pam-ldapd. >>>>>> + """ >>>>>> + description = ('Instructions for configuring a FreeBSD system >>>>>> with ' >>>>>> + 'nss-pam-ldapd. ') >>>>>> + >>>>>> + def get_info(self): >>>>>> + uri, base = self.get_uri_and_base() >>>>>> + cacrt = '/usr/local/etc/ipatest.crt' >>>>> Is the cert file name is correct? 'ipatest.crt'? Perhaps 'ipaca.crt' >>>>> would be a better name? >>>> Or simply ipa.crt since it is the filename used everywhere else... >>>> >>>> Martin >>> Cert file name changed to ipa.crt. >>> >>> Comment added about AES not being available on RHEL5. >>> >>> Updated patch attached. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> This updated patch improves the note about possible issues regarding >> encryption >> algorithms. > Thanks. ACK. > Pushed to master: 92cd987e0a347123d81f83be99787ab77f39ca8e -- Petr? From akrivoka at redhat.com Fri Oct 18 14:21:07 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 18 Oct 2013 16:21:07 +0200 Subject: [Freeipa-devel] [PATCH] 0288 Use a user result template in tests In-Reply-To: <5249932F.10409@redhat.com> References: <5249932F.10409@redhat.com> Message-ID: <526143D3.9000906@redhat.com> On 09/30/2013 05:05 PM, Petr Viktorin wrote: > Hello, > > This patch introduces an user "template" with the result of a default user > add/show. The template is then customized and used in each test. > > This makes the tests shorter, and highlights the "non-default" (interesting) > pieces of the result instead of presenting a wall of text. > > Also, when a new default attribute is added to user results (as is the case in > my upcoming ACI patches), there's now only one place to change. > > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK with two tiny nitpicks: + Attributes named in ``omit`` are removed from the result; any additional + or non-default values can be specified in``overrides``. ^^^^^ missing space + """ + # sn can be None; this should only used from `get_admin_result` ... this should only *be* used ... -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Fri Oct 18 14:28:32 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Oct 2013 16:28:32 +0200 Subject: [Freeipa-devel] [PATCHES] 0289-0302 Managed Read permissions In-Reply-To: <524D49FB.1040801@redhat.com> References: <524A8E59.8010605@redhat.com> <524BDBBA.6060506@redhat.com> <1135777364.287904.1380712053236.JavaMail.root@redhat.com> <524C02C8.9030300@redhat.com> <524D49FB.1040801@redhat.com> Message-ID: <52614590.8020105@redhat.com> On 10/03/2013 12:42 PM, Martin Kosek wrote: > On 10/02/2013 01:26 PM, Petr Viktorin wrote: >> On 10/02/2013 01:07 PM, Simo Sorce wrote: > ... >>>> To sum it up, I would rather not build our permission system on this group. >>>> >>>> I think we need top base our ACIs on LDAP bind targets ldap:///all and >>>> ldap:///anyone to avoid performance issues and issues with ipausers not being >>>> complete: >>>> >>>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Access_Control-Bind_Rules.html >>>> >>>> >>>> I rather think we want to base the permissions on binddn. In the beginning, >>>> there would be 3 types of permissions based on binddn: >>>> >>>> * groupdn based: standard permissions that can be assigned privileges >>>> * ldap:///all permissions for all authenticated users. Cannot be assigned to >>>> privileges (would not make sense) >>>> * ldap:///anyone permissions for all, including anonymous users. Cannot be >>>> assigned to privileges (would not make sense) >>>> >>>> Just few examples: >>>> Read users - ldap:///anyone >>>> Read groups - ldap:///anyone >>>> Read sudo - ldap:///all >>>> Read hbac - ldap:///all >>>> ... >>>> >>>> Basing the permissions on these would allow us to get rid of all the awful >>>> deny permissions. >>>> >>>> To make the permission Bind part more user friendly, there should be an >>>> option >>>> in permission-find and a switch in Web UI to e.g. list permissions by bind >>>> type, i.e.: >>>> - anonymous permissions >>>> - authenticated users permissions >>>> - group based permissions >>>> >>>> If use would want to e.g restrict sudo only to specified group, I would see >>>> this workflow: >>>> 1) Change bind type from "authenticated users" to "group based" >>>> 2) Bind permission to chosen privilege >>>> 3) ... >>>> >>>> And the opposite, if he wants to make reading more open: >>>> 1) Unbind permission from privilege >>>> 2) Change bind type to "authenticated users" or "anonymous" >>>> >>>> Makes sense? >> >> Yes. >> >>> I agree with Martin's comments too. >>> >>> Simo. >> >> We use privileges to group related permissions. For example an "Automount >> Reader" privilege would contain "read automount keys" and "read automount maps" >> permissions. >> Wouldn't it make more sense (from the user's point of view at least) to have >> this setting at the privilege level? >> >> The selfservice plugin does pretty much the same thing. Should we (aim to) move >> selfservice functionality to this system? > > selfservice is not involved in privileges, neither is delegation, they are just > handling raw ACIs in a custom manner. > > With ldap:///all and ldap:///anyone we could theoretically add new permission > types and commands, like anonymousrbac-add or authenticatedrbac-add, but I > think it would be best to keep them with standard permissions for several reasons: > 1) Can use the new cool features you are adding to permission entries > 2) With these ACIs, it makes sense to convert them to group-based permission > and assign to a privilege (does not make that much sense with selfservice ACIs). > > AFAIU, we all agree on that and the only part is how the > anonymous/authenticated-user permissions should be grouped. > > I still think that grouping them in privileges or roles does not make much > sense - anonymous/authenticated-user ACIs do not need to be grouped anywhere, > setting binddn is enough. > > It would be just our custom wiring in framework without much benefit to real > functionality in LDAP. If you have a privilege "Automount Reader" with setting > "Access: Anonymous: or similar, what if you add more non-anonymous permission > to the privilege? What would happen then? Or what if you remove permission from > the privilege, should it automagically become group-based ACI? > > Going with the workflow I described above seems to me as the most direct > approach with keeping the anonymous/authenticated users/group based information > in the single authoritative source - ACI/permission. > >> >> And, since these permissions are longer be compatible with old versions, I >> could move them out of $SUFFIX and onto the relevant containers. That should >> also help performance. > > +1 > > Martin > Alright, I'm crafting an updated design page with the above in mind. Here are the main differences. New permissions won't (necessarily) be in $SUFFIX, so old IPA servers will not be able to modify them. Extra attribute types needed in addition to ipaPerm*Attributes would be: - ipaPermBindType (anonymous/any authenticated user/normal permission) - ipaPermDN (container DN where the ACI is stored) And objectclasses to group them: 'ipaPermissionV2' SUP ipaPermission AUXILIARY MUST ( ipaPermBindType $ ipaPermDN ) 'ipaManagedPermission' SUP ipaPermissionV2 AUXILIARY MAY ( ipaPermDefaultAttrs $ ipaPermAllowedAttrs $ ipaPermExcludedAttrs ) As for 'ipaPermissionV2', all non-SYSTEM permissions should be updated to it. Maybe a better name is needed. Another idea I had is to store all variable parts of the ACI in the permission entry. This would mean we'd not need to parse ACIs to read, search, or update them, which should make these operations faster and the code could be simplified. Doing this would require these new attribute types: - ipaPermRight (add, update, read, delete, etc.) - ipaPermObjectType - ipaPermMemberof - ipaPermFilter - ipaPermSubtree - ipaPermTargetgroup Would that make sense? -- Petr? From pviktori at redhat.com Fri Oct 18 15:00:09 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Oct 2013 17:00:09 +0200 Subject: [Freeipa-devel] Reviews still needed In-Reply-To: <1381345041.1760.60.camel@localhost> References: <1381345041.1760.60.camel@localhost> Message-ID: <52614CF9.2080304@redhat.com> On 10/09/2013 08:57 PM, Nathaniel McCallum wrote: > I still need reviews on the following patches. The first two (0015 and > 0016) should be close if not ready to merge. They have undergone four > revisions. The third is probably in the middle of reviews. Please help > me push this over the goal line. :) > > Nathaniel > > freeipa-npmccallum-0015-4-Add-support-for-managing-user-auth-types.patch > API.txt | 12 ++++++++---- > VERSION | 2 +- > install/updates/50-ipaconfig.update | 1 + > ipalib/plugins/config.py | 8 ++++++++ > ipalib/plugins/user.py | 35 ++++++++++++++++++++++------ > 5 files changed, 43 insertions(+), 15 deletions(-) I'm waiting for your response on this one. Did you reproduce the test failure? Unfortunately the other two don't apply to master. Could you rebase them? > > freeipa-npmccallum-0016-4-Add-RADIUS-proxy-support-to-ipalib-CLI.patch > API.txt | 95 +++++++++++++++++++++++-- > VERSION | 2 > install/share/70ipaotp.ldif | 2 > install/share/indices.ldif | 10 ++ > install/share/referint-conf.ldif | 3 > install/updates/10-70ipaotp.update | 2 > install/updates/20-indices.update | 7 + > install/updates/25-referint.update | 1 > install/updates/40-otp.update | 5 + > ipalib/constants.py | 1 > ipalib/plugins/config.py | 2 > ipalib/plugins/radiusproxy.py | 138 +++++++++++++++++++++++++++++ > ipalib/plugins/user.py | 44 ++++++++++- > 13 files changed, 298 insertions(+), 14 deletions(-) > > freeipa-npmccallum-0024-2-Add-OTP-support-to-ipalib-CLI.patch > API.txt | 101 +++++++++++++ > VERSION | 2 > freeipa.spec.in | 2 > ipalib/errors.py | 16 ++ > ipalib/plugins/config.py | 2 > ipalib/plugins/otptoken.py | 330 +++++++++++++++++++++++++++++++++++++ > ipalib/plugins/user.py | 10 + > 7 files changed, 456 insertions(+), 7 deletions(-) -- Petr? From mbasti at redhat.com Fri Oct 18 15:00:45 2013 From: mbasti at redhat.com (Martin Basti) Date: Fri, 18 Oct 2013 17:00:45 +0200 Subject: [Freeipa-devel] [PATCH] 0014 [RFE] ipa migrate-ds should have an argument to specify cert to use for DS connection Message-ID: <1382108445.2362.1.camel@unused-4-145.brq.redhat.com> Patch attached. Ticket: https://fedorahosted.org/freeipa/ticket/3243 -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0014-migrate-ds-added-ca-cert-file-FILE-option.patch Type: text/x-patch Size: 3974 bytes Desc: not available URL: From pviktori at redhat.com Fri Oct 18 15:12:53 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Oct 2013 17:12:53 +0200 Subject: [Freeipa-devel] [PATCH] 0288 Use a user result template in tests In-Reply-To: <526143D3.9000906@redhat.com> References: <5249932F.10409@redhat.com> <526143D3.9000906@redhat.com> Message-ID: <52614FF5.2000300@redhat.com> On 10/18/2013 04:21 PM, Ana Krivokapic wrote: > On 09/30/2013 05:05 PM, Petr Viktorin wrote: >> Hello, >> >> This patch introduces an user "template" with the result of a default >> user add/show. The template is then customized and used in each test. >> >> This makes the tests shorter, and highlights the "non-default" >> (interesting) pieces of the result instead of presenting a wall of text. >> >> Also, when a new default attribute is added to user results (as is the >> case in my upcoming ACI patches), there's now only one place to change. >> >> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK with two tiny nitpicks: > > + Attributes named in ``omit`` are removed from the result; any additional > + or non-default values can be specified in``overrides``. > ^^^^^ missing space > + """ > + # sn can be None; this should only used from `get_admin_result` > > ... this should only *be* used ... > Thanks for your attention to detail! Fixed & pushed to master: 756b997a7d2a4c23b41469ee272e412d7f8ca19f -- Petr? From akrivoka at redhat.com Fri Oct 18 15:53:50 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 18 Oct 2013 17:53:50 +0200 Subject: [Freeipa-devel] [PATCH] 0274 test_simple_replication: Fix waiting for replication In-Reply-To: <52333C29.1070907@redhat.com> References: <52333C29.1070907@redhat.com> Message-ID: <5261598E.6040808@redhat.com> On 09/13/2013 06:24 PM, Petr Viktorin wrote: > The "simple replication" test is failing intermittently. It's quite hard to > manually verify if this patch fixes that completely, but my testing says it > does make a positive difference. > > See commit message for details. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel The simple replication test seems to work fine with the patch applied, the code changes look sane, so ACK from me. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Fri Oct 18 15:53:40 2013 From: mbasti at redhat.com (Martin Basti) Date: Fri, 18 Oct 2013 17:53:40 +0200 Subject: [Freeipa-devel] [PATCH][DOC] 0015 Added section migration using TLS Message-ID: <1382111620.2362.3.camel@unused-4-145.brq.redhat.com> Document changes in patch freeipa-mbasti-0014 Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0015-Added-new-section-migration-with-TLS.patch Type: text/x-patch Size: 1660 bytes Desc: not available URL: From pviktori at redhat.com Fri Oct 18 16:02:12 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 18 Oct 2013 18:02:12 +0200 Subject: [Freeipa-devel] [PATCH] 0274 test_simple_replication: Fix waiting for replication In-Reply-To: <5261598E.6040808@redhat.com> References: <52333C29.1070907@redhat.com> <5261598E.6040808@redhat.com> Message-ID: <52615B84.6030203@redhat.com> On 10/18/2013 05:53 PM, Ana Krivokapic wrote: > On 09/13/2013 06:24 PM, Petr Viktorin wrote: >> The "simple replication" test is failing intermittently. It's quite >> hard to manually verify if this patch fixes that completely, but my >> testing says it does make a positive difference. >> >> See commit message for details. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > The simple replication test seems to work fine with the patch applied, > the code changes look sane, so ACK from me. > Thanks for the review! Pushed to master: f34b8896f97ee8b29da7f167c7262071000727e4 ipa-3-3: e6738ea68f318c45ad901f8ecfe2d9d94694c7f4 -- Petr? From simo at redhat.com Sun Oct 20 20:33:32 2013 From: simo at redhat.com (Simo Sorce) Date: Sun, 20 Oct 2013 16:33:32 -0400 Subject: [Freeipa-devel] Old tickets to close Message-ID: <1382301212.31620.206.camel@willson.li.ssimo.org> I was searching for a ticket in the depth of the backlog when I found some tickets we should probably just close as they are not relevant anymore or have been superseded by alternative implementations. If nobody objects I'd like to close the follwing tickets: #582 - simply old and no more relevant #232 - superseded by #3859 (or reference from #3859 ?) #233 - superseded by #3859 (or reference from #3859 ?) #192 - it seem we settled, do we still want to do this ? #191 - cryptic, do we still want to do something here ? #126 - I think we should close WONTFIX #908 - I do not think we care much for the openssl dependency anymore #2133 - superseded by #3007 Simo. -- Simo Sorce * Red Hat, Inc * New York From nkinder at redhat.com Sun Oct 20 23:42:05 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Sun, 20 Oct 2013 16:42:05 -0700 Subject: [Freeipa-devel] Old tickets to close In-Reply-To: <1382301212.31620.206.camel@willson.li.ssimo.org> References: <1382301212.31620.206.camel@willson.li.ssimo.org> Message-ID: <52646A4D.1030802@redhat.com> On 10/20/2013 01:33 PM, Simo Sorce wrote: > I was searching for a ticket in the depth of the backlog when I found > some tickets we should probably just close as they are not relevant > anymore or have been superseded by alternative implementations. > > If nobody objects I'd like to close the follwing tickets: > > #582 - simply old and no more relevant > #232 - superseded by #3859 (or reference from #3859 ?) > #233 - superseded by #3859 (or reference from #3859 ?) > #192 - it seem we settled, do we still want to do this ? I don't think that there a big need to do this anymore. We've added more and more capabilities to the FreeIPA password plug-in over time. In some ways, it's nice to have a separate password plug-in since just for FreeIPA as we've added all of these other capabilities that are really FreeIPA specific (such as OTP). If we wanted to leverage a 389 DS password policy plug-in that also allows us to plug-in all of these other password related capabilities, the (not yet developed) 389 DS password policy API might have to be fairly complex. > #191 - cryptic, do we still want to do something here ? > #126 - I think we should close WONTFIX > #908 - I do not think we care much for the openssl dependency anymore > #2133 - superseded by #3007 Agreed. -NGK > > > Simo. > From pspacek at redhat.com Mon Oct 21 06:33:45 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 21 Oct 2013 08:33:45 +0200 Subject: [Freeipa-devel] Old tickets to close In-Reply-To: <52646A4D.1030802@redhat.com> References: <1382301212.31620.206.camel@willson.li.ssimo.org> <52646A4D.1030802@redhat.com> Message-ID: <5264CAC9.4040105@redhat.com> On 21.10.2013 01:42, Nathan Kinder wrote: > On 10/20/2013 01:33 PM, Simo Sorce wrote: >> I was searching for a ticket in the depth of the backlog when I found >> some tickets we should probably just close as they are not relevant >> anymore or have been superseded by alternative implementations. >> >> If nobody objects I'd like to close the follwing tickets: >> >> #582 - simply old and no more relevant >> #232 - superseded by #3859 (or reference from #3859 ?) >> #233 - superseded by #3859 (or reference from #3859 ?) >> #192 - it seem we settled, do we still want to do this ? > I don't think that there a big need to do this anymore. We've added more and > more capabilities to the FreeIPA password plug-in over time. In some ways, > it's nice to have a separate password plug-in since just for FreeIPA as we've > added all of these other capabilities that are really FreeIPA specific (such > as OTP). If we wanted to leverage a 389 DS password policy plug-in that also > allows us to plug-in all of these other password related capabilities, the > (not yet developed) 389 DS password policy API might have to be fairly complex. >> #191 - cryptic, do we still want to do something here ? Are we speaking about Web UI, right? IMHO a search capability is necessary if you have thousands of users. You simply can't use paging to find a 1 user from 10 000. (This assumes that people with 10 000 users use Web UI...) >> #126 - I think we should close WONTFIX I agree. We have how-to for people who insist on chroot. >> #908 - I do not think we care much for the openssl dependency anymore >> #2133 - superseded by #3007 > Agreed. > > -NGK >> Simo. -- Petr^2 Spacek From mkosek at redhat.com Mon Oct 21 07:29:41 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 21 Oct 2013 09:29:41 +0200 Subject: [Freeipa-devel] [PATCH] 0014 [RFE] ipa migrate-ds should have an argument to specify cert to use for DS connection In-Reply-To: <1382108445.2362.1.camel@unused-4-145.brq.redhat.com> References: <1382108445.2362.1.camel@unused-4-145.brq.redhat.com> Message-ID: <5264D7E5.7000407@redhat.com> On 10/18/2013 05:00 PM, Martin Basti wrote: > Patch attached. > > Ticket: > https://fedorahosted.org/freeipa/ticket/3243 > I did not test the patch, just looked at the code and I have few comments: 1) Please put the ipalib/cli.py change to a sepparate change, we may want to backport it separately some day and this will make it easier. 2) When possible, please try to keep the lines up to 80 characters 3) This part is redundant and may hide the real exception source as you are re-raising it: + except Exception as e: + raise e I would rather do it like that, to keep it simple: + cacert = None + if options.get('cacertfile') is not None: + #store CA cert into file + with(tempfile.NamedTemporaryFile(prefix='ipa-', suffix='.crt', delete=False)) as tmp_ca_cert_f: + tmp_ca_cert_f.write(options['cacertfile']) + cacert = tmp_ca_cert_f.name + + #start connection + try: + ds_ldap.connect(bind_dn=options['binddn'], bind_pw=bindpw, tls_cacertfile=cacert) + finally: + #Cert file is no longer required + try: + os.remove(tmp_ca_cert_f.name) + except OSError: + pass HTH, Martin From mkosek at redhat.com Mon Oct 21 07:49:55 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 21 Oct 2013 09:49:55 +0200 Subject: [Freeipa-devel] Old tickets to close In-Reply-To: <5264CAC9.4040105@redhat.com> References: <1382301212.31620.206.camel@willson.li.ssimo.org> <52646A4D.1030802@redhat.com> <5264CAC9.4040105@redhat.com> Message-ID: <5264DCA3.2040806@redhat.com> On 10/21/2013 08:33 AM, Petr Spacek wrote: > On 21.10.2013 01:42, Nathan Kinder wrote: >> On 10/20/2013 01:33 PM, Simo Sorce wrote: >>> I was searching for a ticket in the depth of the backlog when I found >>> some tickets we should probably just close as they are not relevant >>> anymore or have been superseded by alternative implementations. >>> >>> If nobody objects I'd like to close the follwing tickets: >>> >>> #582 - simply old and no more relevant +1 >>> #232 - superseded by #3859 (or reference from #3859 ?) >>> #233 - superseded by #3859 (or reference from #3859 ?) I would rather close the old ones and refer to the new ticket, just for the case of easier ticket manipupation. >>> #192 - it seem we settled, do we still want to do this ? >> I don't think that there a big need to do this anymore. We've added more and >> more capabilities to the FreeIPA password plug-in over time. In some ways, >> it's nice to have a separate password plug-in since just for FreeIPA as we've >> added all of these other capabilities that are really FreeIPA specific (such >> as OTP). If we wanted to leverage a 389 DS password policy plug-in that also >> allows us to plug-in all of these other password related capabilities, the >> (not yet developed) 389 DS password policy API might have to be fairly complex. +1 > >>> #191 - cryptic, do we still want to do something here ? > Are we speaking about Web UI, right? IMHO a search capability is necessary if > you have thousands of users. You simply can't use paging to find a 1 user from > 10 000. (This assumes that people with 10 000 users use Web UI...) I would not close this one, I think it could prove useful in future. Currently, Web UI cannot search only on a specific user entry, AFAIR. > >>> #126 - I think we should close WONTFIX > I agree. We have how-to for people who insist on chroot. +1 >>> #908 - I do not think we care much for the openssl dependency anymore >>> #2133 - superseded by #3007 >> Agreed. Ok. Thanks for the archeological work you did, Simo. Martin From akrivoka at redhat.com Mon Oct 21 08:22:48 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 21 Oct 2013 10:22:48 +0200 Subject: [Freeipa-devel] Old tickets to close In-Reply-To: <5264DCA3.2040806@redhat.com> References: <1382301212.31620.206.camel@willson.li.ssimo.org> <52646A4D.1030802@redhat.com> <5264CAC9.4040105@redhat.com> <5264DCA3.2040806@redhat.com> Message-ID: <5264E458.703@redhat.com> On 10/21/2013 09:49 AM, Martin Kosek wrote: > On 10/21/2013 08:33 AM, Petr Spacek wrote: >> On 21.10.2013 01:42, Nathan Kinder wrote: >>> On 10/20/2013 01:33 PM, Simo Sorce wrote: >>>> I was searching for a ticket in the depth of the backlog when I found >>>> some tickets we should probably just close as they are not relevant >>>> anymore or have been superseded by alternative implementations. >>>> >>>> If nobody objects I'd like to close the follwing tickets: >>>> >>>> #582 - simply old and no more relevant > +1 > >>>> #232 - superseded by #3859 (or reference from #3859 ?) >>>> #233 - superseded by #3859 (or reference from #3859 ?) > I would rather close the old ones and refer to the new ticket, just for the > case of easier ticket manipupation. > >>>> #192 - it seem we settled, do we still want to do this ? >>> I don't think that there a big need to do this anymore. We've added more and >>> more capabilities to the FreeIPA password plug-in over time. In some ways, >>> it's nice to have a separate password plug-in since just for FreeIPA as we've >>> added all of these other capabilities that are really FreeIPA specific (such >>> as OTP). If we wanted to leverage a 389 DS password policy plug-in that also >>> allows us to plug-in all of these other password related capabilities, the >>> (not yet developed) 389 DS password policy API might have to be fairly complex. > +1 > >>>> #191 - cryptic, do we still want to do something here ? >> Are we speaking about Web UI, right? IMHO a search capability is necessary if >> you have thousands of users. You simply can't use paging to find a 1 user from >> 10 000. (This assumes that people with 10 000 users use Web UI...) > I would not close this one, I think it could prove useful in future. Currently, > Web UI cannot search only on a specific user entry, AFAIR. > >>>> #126 - I think we should close WONTFIX >> I agree. We have how-to for people who insist on chroot. > +1 > >>>> #908 - I do not think we care much for the openssl dependency anymore >>>> #2133 - superseded by #3007 >>> Agreed. > Ok. > > Thanks for the archeological work you did, Simo. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Found another one: #2766 - superseeded by #3797 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From mbasti at redhat.com Mon Oct 21 08:29:12 2013 From: mbasti at redhat.com (Martin Basti) Date: Mon, 21 Oct 2013 10:29:12 +0200 Subject: [Freeipa-devel] [PATCHES] 0014, 0016 [RFE] ipa migrate-ds should have an argument to specify cert to use for DS connection In-Reply-To: <5264D7E5.7000407@redhat.com> References: <1382108445.2362.1.camel@unused-4-145.brq.redhat.com> <5264D7E5.7000407@redhat.com> Message-ID: <1382344152.2237.6.camel@unused-4-145.brq.redhat.com> On Mon, 2013-10-21 at 09:29 +0200, Martin Kosek wrote: > On 10/18/2013 05:00 PM, Martin Basti wrote: > > Patch attached. > > > > Ticket: > > https://fedorahosted.org/freeipa/ticket/3243 > > > > I did not test the patch, just looked at the code and I have few comments: > > 1) Please put the ipalib/cli.py change to a sepparate change, we may want to > backport it separately some day and this will make it easier. > Separated. Patch 0014-2 -- CLI Patch 0016 -- migration > 2) When possible, please try to keep the lines up to 80 characters Sorry. I will to try keep length. > 3) This part is redundant and may hide the real exception source as you are > re-raising it: > > + except Exception as e: > + raise e > > > I would rather do it like that, to keep it simple: > > + cacert = None > + if options.get('cacertfile') is not None: > + #store CA cert into file > + with(tempfile.NamedTemporaryFile(prefix='ipa-', suffix='.crt', > delete=False)) as tmp_ca_cert_f: > + tmp_ca_cert_f.write(options['cacertfile']) > + cacert = tmp_ca_cert_f.name > + > + #start connection > + try: > + ds_ldap.connect(bind_dn=options['binddn'], bind_pw=bindpw, > tls_cacertfile=cacert) > + finally: > + #Cert file is no longer required > + try: > + os.remove(tmp_ca_cert_f.name) > + except OSError: > + pass Fixed > HTH, > Martin NOTE: Patch 0016 also changes help description of --ca-cert-file param Thank you for review and advice. -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0014-2-Changed-CLI-to-allow-to-use-FILE-as-optional-param.patch Type: text/x-patch Size: 1130 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0016-migrate-ds-added-ca-cert-file-FILE-option.patch Type: text/x-patch Size: 3073 bytes Desc: not available URL: From mkosek at redhat.com Mon Oct 21 10:11:31 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 21 Oct 2013 12:11:31 +0200 Subject: [Freeipa-devel] Old tickets to close In-Reply-To: <5264E458.703@redhat.com> References: <1382301212.31620.206.camel@willson.li.ssimo.org> <52646A4D.1030802@redhat.com> <5264CAC9.4040105@redhat.com> <5264DCA3.2040806@redhat.com> <5264E458.703@redhat.com> Message-ID: <5264FDD3.6060208@redhat.com> On 10/21/2013 10:22 AM, Ana Krivokapic wrote: > On 10/21/2013 09:49 AM, Martin Kosek wrote: >> On 10/21/2013 08:33 AM, Petr Spacek wrote: >>> On 21.10.2013 01:42, Nathan Kinder wrote: >>>> On 10/20/2013 01:33 PM, Simo Sorce wrote: >>>>> I was searching for a ticket in the depth of the backlog when I found >>>>> some tickets we should probably just close as they are not relevant >>>>> anymore or have been superseded by alternative implementations. >>>>> >>>>> If nobody objects I'd like to close the follwing tickets: >>>>> >>>>> #582 - simply old and no more relevant >> +1 >> >>>>> #232 - superseded by #3859 (or reference from #3859 ?) >>>>> #233 - superseded by #3859 (or reference from #3859 ?) >> I would rather close the old ones and refer to the new ticket, just for the >> case of easier ticket manipupation. >> >>>>> #192 - it seem we settled, do we still want to do this ? >>>> I don't think that there a big need to do this anymore. We've added more and >>>> more capabilities to the FreeIPA password plug-in over time. In some ways, >>>> it's nice to have a separate password plug-in since just for FreeIPA as we've >>>> added all of these other capabilities that are really FreeIPA specific (such >>>> as OTP). If we wanted to leverage a 389 DS password policy plug-in that also >>>> allows us to plug-in all of these other password related capabilities, the >>>> (not yet developed) 389 DS password policy API might have to be fairly complex. >> +1 >> >>>>> #191 - cryptic, do we still want to do something here ? >>> Are we speaking about Web UI, right? IMHO a search capability is necessary if >>> you have thousands of users. You simply can't use paging to find a 1 user from >>> 10 000. (This assumes that people with 10 000 users use Web UI...) >> I would not close this one, I think it could prove useful in future. Currently, >> Web UI cannot search only on a specific user entry, AFAIR. >> >>>>> #126 - I think we should close WONTFIX >>> I agree. We have how-to for people who insist on chroot. >> +1 >> >>>>> #908 - I do not think we care much for the openssl dependency anymore >>>>> #2133 - superseded by #3007 >>>> Agreed. >> Ok. >> >> Thanks for the archeological work you did, Simo. >> >> Martin >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Found another one: > > #2766 - superseeded by #3797 > Right, thanks for the pointer. I closed this one. Simo, do you want to close the tickets you found yourself or do you want me to do it? Martin From tbabej at redhat.com Mon Oct 21 12:17:52 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 21 Oct 2013 14:17:52 +0200 Subject: [Freeipa-devel] [PATCH 120] Get the created range type in case of re-establishing trust Message-ID: <52651B70.6030609@redhat.com> Hi, This is a regression fix introduced by commit id: 285ed59889590ddd0d6ca2e2a030b28527941cbf Fixes internal error in case of re-establishing the trust. -- 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-0120-Get-the-created-range-type-in-case-of-re-establishin.patch Type: text/x-patch Size: 1096 bytes Desc: not available URL: From sbose at redhat.com Mon Oct 21 13:31:00 2013 From: sbose at redhat.com (Sumit Bose) Date: Mon, 21 Oct 2013 15:31:00 +0200 Subject: [Freeipa-devel] [PATCH 120] Get the created range type in case of re-establishing trust In-Reply-To: <52651B70.6030609@redhat.com> References: <52651B70.6030609@redhat.com> Message-ID: <20131021133059.GL3517@localhost.localdomain> On Mon, Oct 21, 2013 at 02:17:52PM +0200, Tomas Babej wrote: > Hi, > > This is a regression fix introduced by commit id: > 285ed59889590ddd0d6ca2e2a030b28527941cbf > > Fixes internal error in case of re-establishing the trust. ACK, "UnboundLocalError: local variable 'created_range_type' referenced before assignment" error is fixed by this patch. bye, Sumit > > -- > Tomas Babej > Associate Software Engeneer | Red Hat | Identity Management > RHCE | Brno Site | IRC: tbabej | freeipa.org > From dpal at redhat.com Mon Oct 21 13:45:30 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 21 Oct 2013 09:45:30 -0400 Subject: [Freeipa-devel] Old tickets to close In-Reply-To: <1382301212.31620.206.camel@willson.li.ssimo.org> References: <1382301212.31620.206.camel@willson.li.ssimo.org> Message-ID: <52652FFA.1050009@redhat.com> On 10/20/2013 04:33 PM, Simo Sorce wrote: > I was searching for a ticket in the depth of the backlog when I found > some tickets we should probably just close as they are not relevant > anymore or have been superseded by alternative implementations. > > If nobody objects I'd like to close the follwing tickets: > > #582 - simply old and no more relevant > #232 - superseded by #3859 (or reference from #3859 ?) > #233 - superseded by #3859 (or reference from #3859 ?) > #192 - it seem we settled, do we still want to do this ? > #191 - cryptic, do we still want to do something here ? > #126 - I think we should close WONTFIX > #908 - I do not think we care much for the openssl dependency anymore > #2133 - superseded by #3007 > > > Simo. > I agree with the assessment that have been done in the thread. 191 - should stay as Martin mentioned. I have a question about 126. Would that be a requirement to be able to run IPA in a OpenShift gear? If this is the case I would rather fix it when we prepare such gear. -- 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 Mon Oct 21 13:47:01 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 21 Oct 2013 15:47:01 +0200 Subject: [Freeipa-devel] [PATCH 120] Get the created range type in case of re-establishing trust In-Reply-To: <20131021133059.GL3517@localhost.localdomain> References: <52651B70.6030609@redhat.com> <20131021133059.GL3517@localhost.localdomain> Message-ID: <52653055.1030804@redhat.com> On 10/21/2013 03:31 PM, Sumit Bose wrote: > On Mon, Oct 21, 2013 at 02:17:52PM +0200, Tomas Babej wrote: >> Hi, >> >> This is a regression fix introduced by commit id: >> 285ed59889590ddd0d6ca2e2a030b28527941cbf >> >> Fixes internal error in case of re-establishing the trust. > > ACK, "UnboundLocalError: local variable 'created_range_type' > referenced before assignment" error is fixed by this patch. > > bye, > Sumit Thanks. Pushed to master, ipa-3-3. Martin From mkosek at redhat.com Mon Oct 21 13:57:01 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 21 Oct 2013 15:57:01 +0200 Subject: [Freeipa-devel] [PATCHES] 0289-0302 Managed Read permissions In-Reply-To: <52614590.8020105@redhat.com> References: <524A8E59.8010605@redhat.com> <524BDBBA.6060506@redhat.com> <1135777364.287904.1380712053236.JavaMail.root@redhat.com> <524C02C8.9030300@redhat.com> <524D49FB.1040801@redhat.com> <52614590.8020105@redhat.com> Message-ID: <526532AD.6050909@redhat.com> On 10/18/2013 04:28 PM, Petr Viktorin wrote: > On 10/03/2013 12:42 PM, Martin Kosek wrote: >> On 10/02/2013 01:26 PM, Petr Viktorin wrote: >>> On 10/02/2013 01:07 PM, Simo Sorce wrote: >> ... >>>>> To sum it up, I would rather not build our permission system on this group. >>>>> >>>>> I think we need top base our ACIs on LDAP bind targets ldap:///all and >>>>> ldap:///anyone to avoid performance issues and issues with ipausers not being >>>>> complete: >>>>> >>>>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Access_Control-Bind_Rules.html >>>>> >>>>> >>>>> >>>>> I rather think we want to base the permissions on binddn. In the beginning, >>>>> there would be 3 types of permissions based on binddn: >>>>> >>>>> * groupdn based: standard permissions that can be assigned privileges >>>>> * ldap:///all permissions for all authenticated users. Cannot be assigned to >>>>> privileges (would not make sense) >>>>> * ldap:///anyone permissions for all, including anonymous users. Cannot be >>>>> assigned to privileges (would not make sense) >>>>> >>>>> Just few examples: >>>>> Read users - ldap:///anyone >>>>> Read groups - ldap:///anyone >>>>> Read sudo - ldap:///all >>>>> Read hbac - ldap:///all >>>>> ... >>>>> >>>>> Basing the permissions on these would allow us to get rid of all the awful >>>>> deny permissions. >>>>> >>>>> To make the permission Bind part more user friendly, there should be an >>>>> option >>>>> in permission-find and a switch in Web UI to e.g. list permissions by bind >>>>> type, i.e.: >>>>> - anonymous permissions >>>>> - authenticated users permissions >>>>> - group based permissions >>>>> >>>>> If use would want to e.g restrict sudo only to specified group, I would see >>>>> this workflow: >>>>> 1) Change bind type from "authenticated users" to "group based" >>>>> 2) Bind permission to chosen privilege >>>>> 3) ... >>>>> >>>>> And the opposite, if he wants to make reading more open: >>>>> 1) Unbind permission from privilege >>>>> 2) Change bind type to "authenticated users" or "anonymous" >>>>> >>>>> Makes sense? >>> >>> Yes. >>> >>>> I agree with Martin's comments too. >>>> >>>> Simo. >>> >>> We use privileges to group related permissions. For example an "Automount >>> Reader" privilege would contain "read automount keys" and "read automount maps" >>> permissions. >>> Wouldn't it make more sense (from the user's point of view at least) to have >>> this setting at the privilege level? >>> >>> The selfservice plugin does pretty much the same thing. Should we (aim to) move >>> selfservice functionality to this system? >> >> selfservice is not involved in privileges, neither is delegation, they are just >> handling raw ACIs in a custom manner. >> >> With ldap:///all and ldap:///anyone we could theoretically add new permission >> types and commands, like anonymousrbac-add or authenticatedrbac-add, but I >> think it would be best to keep them with standard permissions for several >> reasons: >> 1) Can use the new cool features you are adding to permission entries >> 2) With these ACIs, it makes sense to convert them to group-based permission >> and assign to a privilege (does not make that much sense with selfservice ACIs). >> >> AFAIU, we all agree on that and the only part is how the >> anonymous/authenticated-user permissions should be grouped. >> >> I still think that grouping them in privileges or roles does not make much >> sense - anonymous/authenticated-user ACIs do not need to be grouped anywhere, >> setting binddn is enough. >> >> It would be just our custom wiring in framework without much benefit to real >> functionality in LDAP. If you have a privilege "Automount Reader" with setting >> "Access: Anonymous: or similar, what if you add more non-anonymous permission >> to the privilege? What would happen then? Or what if you remove permission from >> the privilege, should it automagically become group-based ACI? >> >> Going with the workflow I described above seems to me as the most direct >> approach with keeping the anonymous/authenticated users/group based information >> in the single authoritative source - ACI/permission. >> >>> >>> And, since these permissions are longer be compatible with old versions, I >>> could move them out of $SUFFIX and onto the relevant containers. That should >>> also help performance. >> >> +1 >> >> Martin >> > > Alright, I'm crafting an updated design page with the above in mind. Here are > the main differences. > > > New permissions won't (necessarily) be in $SUFFIX, so old IPA servers will not > be able to modify them. > Extra attribute types needed in addition to ipaPerm*Attributes would be: > - ipaPermBindType (anonymous/any authenticated user/normal permission) > - ipaPermDN (container DN where the ACI is stored) > > And objectclasses to group them: > > 'ipaPermissionV2' SUP ipaPermission AUXILIARY MUST ( ipaPermBindType $ ipaPermDN ) > 'ipaManagedPermission' SUP ipaPermissionV2 AUXILIARY MAY ( ipaPermDefaultAttrs > $ ipaPermAllowedAttrs $ ipaPermExcludedAttrs ) > > As for 'ipaPermissionV2', all non-SYSTEM permissions should be updated to it. > Maybe a better name is needed. > > > Another idea I had is to store all variable parts of the ACI in the permission > entry. This would mean we'd not need to parse ACIs to read, search, or update > them, which should make these operations faster and the code could be simplified. > Doing this would require these new attribute types: > - ipaPermRight (add, update, read, delete, etc.) > - ipaPermObjectType > - ipaPermMemberof > - ipaPermFilter > - ipaPermSubtree > - ipaPermTargetgroup > > Would that make sense? > It partially makes sense - it would speed up permission-find commands. However, it would also duplicate information and sets it in 2 places. Which smells like a bucket of potential bugs to me. What if somebody changes ipaPermObjectType, but ACI update fails or is interrupted for some reason? It would create inconsistency between permission entry and the ACI itself. Which should prevail? Unless permission-find performance is not a problem (yet?), I would not add these new attributes and only add ipaPermDN as this information is required. I am thinking if we need to add a special objectClass for this new attribute, it could be added as MAY to ipaPermission, along with ipaPermDefaultAttrs, ipaPermAllowedAttrs, ipaPermExcludedAttrs. When the DN is not there, it would simply default to SUFFIX DN. Martin From simo at redhat.com Mon Oct 21 14:08:57 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 21 Oct 2013 10:08:57 -0400 Subject: [Freeipa-devel] Old tickets to close In-Reply-To: <5264FDD3.6060208@redhat.com> References: <1382301212.31620.206.camel@willson.li.ssimo.org> <52646A4D.1030802@redhat.com> <5264CAC9.4040105@redhat.com> <5264DCA3.2040806@redhat.com> <5264E458.703@redhat.com> <5264FDD3.6060208@redhat.com> Message-ID: <1382364537.9794.0.camel@willson.li.ssimo.org> On Mon, 2013-10-21 at 12:11 +0200, Martin Kosek wrote: > On 10/21/2013 10:22 AM, Ana Krivokapic wrote: > > On 10/21/2013 09:49 AM, Martin Kosek wrote: > >> On 10/21/2013 08:33 AM, Petr Spacek wrote: > >>> On 21.10.2013 01:42, Nathan Kinder wrote: > >>>> On 10/20/2013 01:33 PM, Simo Sorce wrote: > >>>>> I was searching for a ticket in the depth of the backlog when I found > >>>>> some tickets we should probably just close as they are not relevant > >>>>> anymore or have been superseded by alternative implementations. > >>>>> > >>>>> If nobody objects I'd like to close the follwing tickets: > >>>>> > >>>>> #582 - simply old and no more relevant > >> +1 > >> > >>>>> #232 - superseded by #3859 (or reference from #3859 ?) > >>>>> #233 - superseded by #3859 (or reference from #3859 ?) > >> I would rather close the old ones and refer to the new ticket, just for the > >> case of easier ticket manipupation. > >> > >>>>> #192 - it seem we settled, do we still want to do this ? > >>>> I don't think that there a big need to do this anymore. We've added more and > >>>> more capabilities to the FreeIPA password plug-in over time. In some ways, > >>>> it's nice to have a separate password plug-in since just for FreeIPA as we've > >>>> added all of these other capabilities that are really FreeIPA specific (such > >>>> as OTP). If we wanted to leverage a 389 DS password policy plug-in that also > >>>> allows us to plug-in all of these other password related capabilities, the > >>>> (not yet developed) 389 DS password policy API might have to be fairly complex. > >> +1 > >> > >>>>> #191 - cryptic, do we still want to do something here ? > >>> Are we speaking about Web UI, right? IMHO a search capability is necessary if > >>> you have thousands of users. You simply can't use paging to find a 1 user from > >>> 10 000. (This assumes that people with 10 000 users use Web UI...) > >> I would not close this one, I think it could prove useful in future. Currently, > >> Web UI cannot search only on a specific user entry, AFAIR. > >> > >>>>> #126 - I think we should close WONTFIX > >>> I agree. We have how-to for people who insist on chroot. > >> +1 > >> > >>>>> #908 - I do not think we care much for the openssl dependency anymore > >>>>> #2133 - superseded by #3007 > >>>> Agreed. > >> Ok. > >> > >> Thanks for the archeological work you did, Simo. > >> > >> Martin > >> > >> _______________________________________________ > >> Freeipa-devel mailing list > >> Freeipa-devel at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > Found another one: > > > > #2766 - superseeded by #3797 > > > > Right, thanks for the pointer. I closed this one. > > Simo, do you want to close the tickets you found yourself or do you want me to > do it? I'll do it. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Oct 21 14:15:24 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 21 Oct 2013 10:15:24 -0400 Subject: [Freeipa-devel] Old tickets to close In-Reply-To: <5264FDD3.6060208@redhat.com> References: <1382301212.31620.206.camel@willson.li.ssimo.org> <52646A4D.1030802@redhat.com> <5264CAC9.4040105@redhat.com> <5264DCA3.2040806@redhat.com> <5264E458.703@redhat.com> <5264FDD3.6060208@redhat.com> Message-ID: <1382364924.9794.1.camel@willson.li.ssimo.org> On Mon, 2013-10-21 at 12:11 +0200, Martin Kosek wrote: > >>>>> #232 - superseded by #3859 (or reference from #3859 ?) > >>>>> #233 - superseded by #3859 (or reference from #3859 ?) > >> I would rather close the old ones and refer to the new ticket, just > for the > >> case of easier ticket manipupation. Btw I decided to assign these to myself and then close them all at once later. they have aspects I am keeping in mind while resolving #3859, but better to have them spelled out for now. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbabej at redhat.com Mon Oct 21 14:50:46 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 21 Oct 2013 16:50:46 +0200 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests In-Reply-To: <525E9825.2070008@redhat.com> References: <52370B90.2030009@redhat.com> <52381625.3010607@redhat.com> <52386896.3000909@redhat.com> <523B1F0F.3010101@redhat.com> <525C121E.3080406@redhat.com> <525E9825.2070008@redhat.com> Message-ID: <52653F46.7050503@redhat.com> On 10/16/2013 03:44 PM, Petr Viktorin wrote: > On 10/14/2013 05:47 PM, Tomas Babej wrote: >> Hi, >> >> Sending the updated version of the patchset. It includes many fixes, >> plus incorporations of the comments by the QE. Tests are now broken down >> into multiple test cases. >> >> This requires my patch 119. >> >> Tomas > > Patches 0100 & 0101: > > I still think it would be simpler if IPA and AD domains shared the > numbering namespace (users would need to define $AD_env2; if they had > $MASTER_env1 and $AD_env1 they would be in the same Domain). > > But if we use _env1 for both the AD and the IPA domain, they need to > be separated in Domain.from_env. With patch 0101 both MASTER_env1 and > AD_env1 will be in both domains[0] and ad_domains[0]. I would rather not join IPA and AD domains as they even cannot be in the same domain, as the service records would clash. So these will always be separate / sub / super domain relationship. As we already pass ad_domain flag to Domain.from_env, I did incorporate code that joins the machines to the domain depending on the their role. Is that a viable solution for you? > Also ipa-test-config should have an --ad-domain option to get info > about the AD domain. > > Fixed, also modified the man page. > Patch 0102: Looks good > > > Patch 0103: > Looks like run_repeatedly should always be called with an assert in > front. We may want it to raise an exception directly if it times out, > so forgetting the assert won't hide errors. > Fixed. > > Patch 0104: Looks good > > > Patch 0105: > In /ipatests/man/ipa-test-task.1: > - Typo in - s/generatee/generate/ > - Subcommand names have unescaped hyphens (e.g. > configure\-dns-for-trust should be configure\-dns\-for\-trust) > - The last subcommand should be sync-time > Fixed. > Wrappers for the tasks need to be added to ipatests/ipa-test-task. > Phew, fixed! > Nitpicks: > - In configure_dns_for_trust:is_subdomain, lockstep iteration over two > lists at once is better done with zip() than `for i in range(len(...))`. > - In estabilish_trust_with_ad, don't use mutable values for argument > defaults; do `extra_args=()` and `+ list(extra_args)` > - I can't say I'm a fan of configure_auth_to_local_rule, but I guess > it's OK for tests. > Fixed. > > Patch 0106: Looks OK; unfortunately I don't have an AD machine to test > functionality > > > I also incorporated Alexander's comments. Thanks for reviews, Alexander and Petr! Update patches attached. -- 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-0106-7-ipatests-Add-AD-integration-test-case.patch Type: text/x-patch Size: 7765 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0105-7-ipatests-Add-AD-integration-related-tasks.patch Type: text/x-patch Size: 17232 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0104-7-ipatests-Add-WinHost-class.patch Type: text/x-patch Size: 1733 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0103-7-ipatests-Create-util-module-for-ipatests.patch Type: text/x-patch Size: 2896 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0102-7-ipatests-Extend-IntegrationTest-with-multiple-AD-dom.patch Type: text/x-patch Size: 2840 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0101-7-ipatests-Extend-domain-object-with-ad-role-support-a.patch Type: text/x-patch Size: 6829 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0100-7-ipatests-Add-Active-Directory-support-to-configurati.patch Type: text/x-patch Size: 5659 bytes Desc: not available URL: From tbabej at redhat.com Mon Oct 21 15:08:35 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 21 Oct 2013 17:08:35 +0200 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests In-Reply-To: <52653F46.7050503@redhat.com> References: <52370B90.2030009@redhat.com> <52381625.3010607@redhat.com> <52386896.3000909@redhat.com> <523B1F0F.3010101@redhat.com> <525C121E.3080406@redhat.com> <525E9825.2070008@redhat.com> <52653F46.7050503@redhat.com> Message-ID: <52654373.9050909@redhat.com> On 10/21/2013 04:50 PM, Tomas Babej wrote: > On 10/16/2013 03:44 PM, Petr Viktorin wrote: >> On 10/14/2013 05:47 PM, Tomas Babej wrote: >>> Hi, >>> >>> Sending the updated version of the patchset. It includes many fixes, >>> plus incorporations of the comments by the QE. Tests are now broken >>> down >>> into multiple test cases. >>> >>> This requires my patch 119. >>> >>> Tomas >> >> Patches 0100 & 0101: >> >> I still think it would be simpler if IPA and AD domains shared the >> numbering namespace (users would need to define $AD_env2; if they had >> $MASTER_env1 and $AD_env1 they would be in the same Domain). >> >> But if we use _env1 for both the AD and the IPA domain, they need to >> be separated in Domain.from_env. With patch 0101 both MASTER_env1 and >> AD_env1 will be in both domains[0] and ad_domains[0]. > > I would rather not join IPA and AD domains as they even cannot be in > the same domain, as the service records would clash. So these will > always be separate / sub / super domain relationship. > > As we already pass ad_domain flag to Domain.from_env, I did > incorporate code that joins the machines to the domain depending on > the their role. Is that a viable solution for you? > >> Also ipa-test-config should have an --ad-domain option to get info >> about the AD domain. >> >> > Fixed, also modified the man page. >> Patch 0102: Looks good >> >> >> Patch 0103: >> Looks like run_repeatedly should always be called with an assert in >> front. We may want it to raise an exception directly if it times out, >> so forgetting the assert won't hide errors. >> > Fixed. >> >> Patch 0104: Looks good >> >> >> Patch 0105: >> In /ipatests/man/ipa-test-task.1: >> - Typo in - s/generatee/generate/ >> - Subcommand names have unescaped hyphens (e.g. >> configure\-dns-for-trust should be configure\-dns\-for\-trust) >> - The last subcommand should be sync-time >> > Fixed. >> Wrappers for the tasks need to be added to ipatests/ipa-test-task. >> > Phew, fixed! >> Nitpicks: >> - In configure_dns_for_trust:is_subdomain, lockstep iteration over >> two lists at once is better done with zip() than `for i in >> range(len(...))`. >> - In estabilish_trust_with_ad, don't use mutable values for argument >> defaults; do `extra_args=()` and `+ list(extra_args)` >> - I can't say I'm a fan of configure_auth_to_local_rule, but I guess >> it's OK for tests. >> > Fixed. >> >> Patch 0106: Looks OK; unfortunately I don't have an AD machine to >> test functionality >> >> >> > > I also incorporated Alexander's comments. > > Thanks for reviews, Alexander and Petr! > > Update patches attached. > In the patch 100, there was missing import for the itertools package, in ended up in another patch in the pile, which is not yet on the list. Sorry for the confusion, fixed patchset attached. -- 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-0106-8-ipatests-Add-AD-integration-test-case.patch Type: text/x-patch Size: 7765 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0105-8-ipatests-Add-AD-integration-related-tasks.patch Type: text/x-patch Size: 17232 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0104-8-ipatests-Add-WinHost-class.patch Type: text/x-patch Size: 1733 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0103-8-ipatests-Create-util-module-for-ipatests.patch Type: text/x-patch Size: 2896 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0102-8-ipatests-Extend-IntegrationTest-with-multiple-AD-dom.patch Type: text/x-patch Size: 2840 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0101-8-ipatests-Extend-domain-object-with-ad-role-support-a.patch Type: text/x-patch Size: 6829 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0100-8-ipatests-Add-Active-Directory-support-to-configurati.patch Type: text/x-patch Size: 5803 bytes Desc: not available URL: From pviktori at redhat.com Mon Oct 21 15:45:55 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 21 Oct 2013 17:45:55 +0200 Subject: [Freeipa-devel] [PATCHES] 0289-0302 Managed Read permissions In-Reply-To: <526532AD.6050909@redhat.com> References: <524A8E59.8010605@redhat.com> <524BDBBA.6060506@redhat.com> <1135777364.287904.1380712053236.JavaMail.root@redhat.com> <524C02C8.9030300@redhat.com> <524D49FB.1040801@redhat.com> <52614590.8020105@redhat.com> <526532AD.6050909@redhat.com> Message-ID: <52654C33.4070300@redhat.com> On 10/21/2013 03:57 PM, Martin Kosek wrote: > On 10/18/2013 04:28 PM, Petr Viktorin wrote: >> On 10/03/2013 12:42 PM, Martin Kosek wrote: >>> On 10/02/2013 01:26 PM, Petr Viktorin wrote: >>>> On 10/02/2013 01:07 PM, Simo Sorce wrote: >>> ... >>>>>> To sum it up, I would rather not build our permission system on this group. >>>>>> >>>>>> I think we need top base our ACIs on LDAP bind targets ldap:///all and >>>>>> ldap:///anyone to avoid performance issues and issues with ipausers not being >>>>>> complete: >>>>>> >>>>>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Access_Control-Bind_Rules.html >>>>>> >>>>>> >>>>>> >>>>>> I rather think we want to base the permissions on binddn. In the beginning, >>>>>> there would be 3 types of permissions based on binddn: >>>>>> >>>>>> * groupdn based: standard permissions that can be assigned privileges >>>>>> * ldap:///all permissions for all authenticated users. Cannot be assigned to >>>>>> privileges (would not make sense) >>>>>> * ldap:///anyone permissions for all, including anonymous users. Cannot be >>>>>> assigned to privileges (would not make sense) >>>>>> >>>>>> Just few examples: >>>>>> Read users - ldap:///anyone >>>>>> Read groups - ldap:///anyone >>>>>> Read sudo - ldap:///all >>>>>> Read hbac - ldap:///all >>>>>> ... >>>>>> >>>>>> Basing the permissions on these would allow us to get rid of all the awful >>>>>> deny permissions. >>>>>> >>>>>> To make the permission Bind part more user friendly, there should be an >>>>>> option >>>>>> in permission-find and a switch in Web UI to e.g. list permissions by bind >>>>>> type, i.e.: >>>>>> - anonymous permissions >>>>>> - authenticated users permissions >>>>>> - group based permissions >>>>>> >>>>>> If use would want to e.g restrict sudo only to specified group, I would see >>>>>> this workflow: >>>>>> 1) Change bind type from "authenticated users" to "group based" >>>>>> 2) Bind permission to chosen privilege >>>>>> 3) ... >>>>>> >>>>>> And the opposite, if he wants to make reading more open: >>>>>> 1) Unbind permission from privilege >>>>>> 2) Change bind type to "authenticated users" or "anonymous" >>>>>> >>>>>> Makes sense? >>>> >>>> Yes. >>>> >>>>> I agree with Martin's comments too. >>>>> >>>>> Simo. >>>> >>>> We use privileges to group related permissions. For example an "Automount >>>> Reader" privilege would contain "read automount keys" and "read automount maps" >>>> permissions. >>>> Wouldn't it make more sense (from the user's point of view at least) to have >>>> this setting at the privilege level? >>>> >>>> The selfservice plugin does pretty much the same thing. Should we (aim to) move >>>> selfservice functionality to this system? >>> >>> selfservice is not involved in privileges, neither is delegation, they are just >>> handling raw ACIs in a custom manner. >>> >>> With ldap:///all and ldap:///anyone we could theoretically add new permission >>> types and commands, like anonymousrbac-add or authenticatedrbac-add, but I >>> think it would be best to keep them with standard permissions for several >>> reasons: >>> 1) Can use the new cool features you are adding to permission entries >>> 2) With these ACIs, it makes sense to convert them to group-based permission >>> and assign to a privilege (does not make that much sense with selfservice ACIs). >>> >>> AFAIU, we all agree on that and the only part is how the >>> anonymous/authenticated-user permissions should be grouped. >>> >>> I still think that grouping them in privileges or roles does not make much >>> sense - anonymous/authenticated-user ACIs do not need to be grouped anywhere, >>> setting binddn is enough. >>> >>> It would be just our custom wiring in framework without much benefit to real >>> functionality in LDAP. If you have a privilege "Automount Reader" with setting >>> "Access: Anonymous: or similar, what if you add more non-anonymous permission >>> to the privilege? What would happen then? Or what if you remove permission from >>> the privilege, should it automagically become group-based ACI? >>> >>> Going with the workflow I described above seems to me as the most direct >>> approach with keeping the anonymous/authenticated users/group based information >>> in the single authoritative source - ACI/permission. >>> >>>> >>>> And, since these permissions are longer be compatible with old versions, I >>>> could move them out of $SUFFIX and onto the relevant containers. That should >>>> also help performance. >>> >>> +1 >>> >>> Martin >>> >> >> Alright, I'm crafting an updated design page with the above in mind. Here are >> the main differences. >> >> >> New permissions won't (necessarily) be in $SUFFIX, so old IPA servers will not >> be able to modify them. >> Extra attribute types needed in addition to ipaPerm*Attributes would be: >> - ipaPermBindType (anonymous/any authenticated user/normal permission) >> - ipaPermDN (container DN where the ACI is stored) >> >> And objectclasses to group them: >> >> 'ipaPermissionV2' SUP ipaPermission AUXILIARY MUST ( ipaPermBindType $ ipaPermDN ) >> 'ipaManagedPermission' SUP ipaPermissionV2 AUXILIARY MAY ( ipaPermDefaultAttrs >> $ ipaPermAllowedAttrs $ ipaPermExcludedAttrs ) >> >> As for 'ipaPermissionV2', all non-SYSTEM permissions should be updated to it. >> Maybe a better name is needed. >> >> >> Another idea I had is to store all variable parts of the ACI in the permission >> entry. This would mean we'd not need to parse ACIs to read, search, or update >> them, which should make these operations faster and the code could be simplified. >> Doing this would require these new attribute types: >> - ipaPermRight (add, update, read, delete, etc.) >> - ipaPermObjectType >> - ipaPermMemberof >> - ipaPermFilter >> - ipaPermSubtree >> - ipaPermTargetgroup >> >> Would that make sense? >> > > It partially makes sense - it would speed up permission-find commands. However, > it would also duplicate information and sets it in 2 places. Which smells like > a bucket of potential bugs to me. > > What if somebody changes ipaPermObjectType, but ACI update fails or is > interrupted for some reason? It would create inconsistency between permission > entry and the ACI itself. Which should prevail? > > Unless permission-find performance is not a problem (yet?), I would not add > these new attributes and only add ipaPermDN as this information is required. OK > I am thinking if we need to add a special objectClass for this new attribute, > it could be added as MAY to ipaPermission, along with ipaPermDefaultAttrs, > ipaPermAllowedAttrs, ipaPermExcludedAttrs. When the DN is not there, it would > simply default to SUFFIX DN. Yes, I'll add ipaPermDN to ipaPermission. However I'll put the ipaPerm*Attrs attributes in ipaManagedPermission, as in the original design. They don't make any sense on other types of permissions. There is another data duplication: both managed permissions and permissions with ipaPermDN need to have flags (ipaPermissionType) set to make sure old servers don't try to manipulate them. However if any inconsistencies happen here, it will only matter in the upgrade period. -- Petr? From deanhunter at comcast.net Tue Oct 22 00:41:27 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Mon, 21 Oct 2013 19:41:27 -0500 Subject: [Freeipa-devel] [PATCH][DOC] Configure sudo for FreeIPA 3.1.5 Message-ID: <1382402487.2620.3.camel@host.hunter.org> This patch is only for the FreeIPA 3.1.5 User Guide. The 3.1.5 User Guide currently has a procedure carried over from the 2.2 User Guide. And the procedure will be different, again, for the 3.4 User Guide. The procedure is based on http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf. https://fedorahosted.org/freeipa/ticket/3756 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-deanhunter-0001-Configure-sudo-for-FreeIPA-3.1.5.patch Type: text/x-patch Size: 13541 bytes Desc: not available URL: From tbabej at redhat.com Tue Oct 22 07:20:23 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 22 Oct 2013 09:20:23 +0200 Subject: [Freeipa-devel] [PATCH 0121] ipatests: Add support for hosts referenced by a keyword Message-ID: <52662737.7070705@redhat.com> Hi, Adds support for host definition by a environment variables of the following form: KEYWORDHOST__envX, where X is the number of the environment for which host referenced by a keyword should be defined. You can also optionally use KEYWORDHOST__IP_envX to define the IP address directly, otherwise the framework will try to resolve the hostname. Adds a required_keyword_hosts attribute to the IntegrationTest class, which can test developer use to specify the keyword hosts that this particular test requires. If not all required keyword hosts are available, the test will be skipped. All keyword hosts are accessible to the IntegrationTests via the keyword_hosts attribute, which contains a dictionary keyed by the keywords. Part of: https://fedorahosted.org/freeipa/ticket/3833 -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0121-ipatests-Add-support-for-hosts-referenced-by-a-keywo.patch Type: text/x-patch Size: 14250 bytes Desc: not available URL: From pviktori at redhat.com Tue Oct 22 07:54:39 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 22 Oct 2013 09:54:39 +0200 Subject: [Freeipa-devel] [PATCH 0121] ipatests: Add support for hosts referenced by a keyword In-Reply-To: <52662737.7070705@redhat.com> References: <52662737.7070705@redhat.com> Message-ID: <52662F3F.2050309@redhat.com> On 10/22/2013 09:20 AM, Tomas Babej wrote: > Hi, > > Adds support for host definition by a environment variables of the > following form: > > KEYWORDHOST__envX, where X is the number of the environment > for which host referenced by a keyword should be defined. > > You can also optionally use KEYWORDHOST__IP_envX to define > the IP address directly, otherwise the framework will try to resolve > the hostname. > > Adds a required_keyword_hosts attribute to the IntegrationTest class, > which can test developer use to specify the keyword hosts that this > particular test requires. If not all required keyword hosts are > available, the test will be skipped. > > All keyword hosts are accessible to the IntegrationTests via the > keyword_hosts attribute, which contains a dictionary keyed by the > keywords. > Why is this necessary? What's wrong with just extending the current scheme with more roles? -- Petr? From tbabej at redhat.com Tue Oct 22 08:09:06 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 22 Oct 2013 10:09:06 +0200 Subject: [Freeipa-devel] [PATCH 0121] ipatests: Add support for hosts referenced by a keyword In-Reply-To: <52662F3F.2050309@redhat.com> References: <52662737.7070705@redhat.com> <52662F3F.2050309@redhat.com> Message-ID: <526632A2.4030404@redhat.com> On 10/22/2013 09:54 AM, Petr Viktorin wrote: > On 10/22/2013 09:20 AM, Tomas Babej wrote: >> Hi, >> >> Adds support for host definition by a environment variables of the >> following form: >> >> KEYWORDHOST__envX, where X is the number of the environment >> for which host referenced by a keyword should be defined. >> >> You can also optionally use KEYWORDHOST__IP_envX to define >> the IP address directly, otherwise the framework will try to resolve >> the hostname. >> >> Adds a required_keyword_hosts attribute to the IntegrationTest class, >> which can test developer use to specify the keyword hosts that this >> particular test requires. If not all required keyword hosts are >> available, the test will be skipped. >> >> All keyword hosts are accessible to the IntegrationTests via the >> keyword_hosts attribute, which contains a dictionary keyed by the >> keywords. >> > > Why is this necessary? > What's wrong with just extending the current scheme with more roles? > > The need for keyword hosts arised with the implementation of the legacy client test suite. As each of these tests needs a precise type (pre-defined and pre-configured) of VM, and not a generic client, you need to restrict the test case to specific host type. One test might be restricted to RHEL 5.10 with nss-pam-ldapd, another to FreeBSD, next one to CentOS with nss-pam-ldapd, next to CentOS with old version of SSSD... Each testcase that needs a new type of preconfigured host, we would need to introduce a new role, which would need to be integrated in the framework. In such implementation, we would lose loose coupling between the test framework and the test themselves, and make them less pluggable. HTH, -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pviktori at redhat.com Tue Oct 22 08:37:53 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 22 Oct 2013 10:37:53 +0200 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests In-Reply-To: <52653F46.7050503@redhat.com> References: <52370B90.2030009@redhat.com> <52381625.3010607@redhat.com> <52386896.3000909@redhat.com> <523B1F0F.3010101@redhat.com> <525C121E.3080406@redhat.com> <525E9825.2070008@redhat.com> <52653F46.7050503@redhat.com> Message-ID: <52663961.3010606@redhat.com> Replying to one part only: On 10/21/2013 04:50 PM, Tomas Babej wrote: > On 10/16/2013 03:44 PM, Petr Viktorin wrote: >> >> I still think it would be simpler if IPA and AD domains shared the >> numbering namespace (users would need to define $AD_env2; if they had >> $MASTER_env1 and $AD_env1 they would be in the same Domain). >> >> But if we use _env1 for both the AD and the IPA domain, they need to >> be separated in Domain.from_env. With patch 0101 both MASTER_env1 and >> AD_env1 will be in both domains[0] and ad_domains[0]. > > I would rather not join IPA and AD domains as they even cannot be in the > same domain, as the service records would clash. So these will > always be separate / sub / super domain relationship. You're right that they should never share the same domain. But you should never say never, especially in testing -- what if we'll want to, in the future, test that the records *do* clash, or that IPA refuses to install in an AD domain? Another problem is that they are now separate namespaces. In all code that deals with domains you have to deal separately with the list of AD domains and separately with IPA domains. This makes every piece of code that doesn't care much about what type of domain it's dealing with (configuration, listing, possible automation scripts for turning on the VMs, etc.) more complicated. Also, in this scheme, adding a new type of domain would be quite hard, especially after more code is written with this split in mind. Do keep the domain type, though. tl;dr I'd really prefer "domain 1 (IPA); domain 2 (AD)" rather than "IPA domain 1; AD domain 1". If needed we can have a special check that would reject IPA masters in AD domains and vice versa, if that really turns out to be necessary. > As we already pass ad_domain flag to Domain.from_env, I did incorporate > code that joins the machines to the domain depending on the their role. > Is that a viable solution for you? Sorry. I think this design is less sustainable than having a shared namespace for the domains. -- Petr? From mkosek at redhat.com Tue Oct 22 08:39:44 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 22 Oct 2013 10:39:44 +0200 Subject: [Freeipa-devel] [PATCH][DOC] Configure sudo for FreeIPA 3.1.5 In-Reply-To: <1382402487.2620.3.camel@host.hunter.org> References: <1382402487.2620.3.camel@host.hunter.org> Message-ID: <526639D0.8060101@redhat.com> On 10/22/2013 02:41 AM, Dean Hunter wrote: > This patch is only for the FreeIPA 3.1.5 User Guide. The 3.1.5 User > Guide currently has a procedure carried over from the 2.2 User Guide. > And the procedure will be different, again, for the 3.4 User Guide. The > procedure is based on > http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf. > > https://fedorahosted.org/freeipa/ticket/3756 Hi Dean, Thanks for the patch! I have few comments though. 1) ipa-client-install in the first paragraph should be in . I also think there should be a short introduction of the section instead of directly jumping to editing configs. I think that a modification of the previous one would work. Something like that: ~~~ Actually implementing sudo policies is more complicated than simply creating the rules in FreeIPA. Those rules need to be applied to every local machine, which means that each system in the FreeIPA domain has to be configured to refer to FreeIPA for its policies. This example specifically configures a Fedora client for sudo rules. The sudo on client is configured to use SSSD as a source of the policies: ... ~~~ 2) I see that in the configuration examples you already pasted executable scripts from your automation. However, I think that the "echo" and "sed" like examples will not bring enough clarity for the users. I would rather prefer the standard examples (as in other places in the guide) showing how the file should look like and leave the automation on user (if he needs it), i.e. ~~~ vim /etc/nsswitch.conf sudoers: files ldap ~~~ instead of ~~~ [root at ipaclient] ~]# echo "sudoers: files sss" >>/etc/nsswitch.conf ~~~ or ~~~ [domain/example.com] krb5_server = ipa.example.com ldap_sasl_authid = host/hostname.example.com ldap_sasl_mech = GSSAPI ldap_sasl_realm = EXAMPLE.COM ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_uri = ldap://ipa.example.com sudo_provider = ldap ~~~ instead of ~~~ [root at ipaclient] ~]# sed "/^\[domain\/example.com\]/ a\\ > krb5_server = ipa.example.com\\ > ldap_sasl_authid = host/hostname.example.com\\ > ldap_sasl_mech = GSSAPI\\ > ldap_sasl_realm = EXAMPLE.COM\\ > ldap_sudo_search_base = ou=sudoers,dc=example,dc=com\\ > ldap_uri = ldap://ipa.example.com\\ > sudo_provider = ldap" /etc/sssd/sssd.conf ~~~ etc. This will make the examples easier to read and consistent with the rest of the guide. Martin From pviktori at redhat.com Tue Oct 22 08:44:06 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 22 Oct 2013 10:44:06 +0200 Subject: [Freeipa-devel] [PATCH 0121] ipatests: Add support for hosts referenced by a keyword In-Reply-To: <526632A2.4030404@redhat.com> References: <52662737.7070705@redhat.com> <52662F3F.2050309@redhat.com> <526632A2.4030404@redhat.com> Message-ID: <52663AD6.4070308@redhat.com> On 10/22/2013 10:09 AM, Tomas Babej wrote: > On 10/22/2013 09:54 AM, Petr Viktorin wrote: >> On 10/22/2013 09:20 AM, Tomas Babej wrote: >>> Hi, >>> >>> Adds support for host definition by a environment variables of the >>> following form: >>> >>> KEYWORDHOST__envX, where X is the number of the environment >>> for which host referenced by a keyword should be defined. >>> >>> You can also optionally use KEYWORDHOST__IP_envX to define >>> the IP address directly, otherwise the framework will try to resolve >>> the hostname. >>> >>> Adds a required_keyword_hosts attribute to the IntegrationTest class, >>> which can test developer use to specify the keyword hosts that this >>> particular test requires. If not all required keyword hosts are >>> available, the test will be skipped. >>> >>> All keyword hosts are accessible to the IntegrationTests via the >>> keyword_hosts attribute, which contains a dictionary keyed by the >>> keywords. >>> >> >> Why is this necessary? >> What's wrong with just extending the current scheme with more roles? >> >> > > The need for keyword hosts arised with the implementation of the legacy > client test suite. > > As each of these tests needs a precise type (pre-defined and > pre-configured) of VM, and not a generic client, you need to restrict > the test case to specific host type. > > One test might be restricted to RHEL 5.10 with nss-pam-ldapd, another to > FreeBSD, next one to CentOS with nss-pam-ldapd, next to CentOS with old > version of SSSD... > > Each testcase that needs a new type of preconfigured host, we would need > to introduce a new role, which would need to be integrated in the > framework. In such implementation, we would lose loose coupling between > the test framework and the test themselves, and make them less pluggable. The framework itself (excluding the configuration part) should be able to handle this nicely using the existing role mechanism. It's true that in some places it's currently hard-wired to just a few roles, but supporting completely custom roles shouldn't be a problem. I'd prefer if this system was used, rather than basically adding a second role system, which we'd have to support even if we get rid of the current config part. The envvar-based configuration is not as flexible, but I'd rather make this part somewhat unpleasant than making the framework complex. We plan to move to a simpler configuration method anyway. That said, you can basically keep the variable name scheme you use in this patch; just maybe use TESTHOST rather than KEYWORDHOST. -- Petr? From mbasti at redhat.com Tue Oct 22 08:53:51 2013 From: mbasti at redhat.com (Martin Basti) Date: Tue, 22 Oct 2013 10:53:51 +0200 Subject: [Freeipa-devel] [PATCH][DOC] Configure sudo for FreeIPA 3.1.5 In-Reply-To: <526639D0.8060101@redhat.com> References: <1382402487.2620.3.camel@host.hunter.org> <526639D0.8060101@redhat.com> Message-ID: <1382432031.2237.16.camel@unused-4-145.brq.redhat.com> On Tue, 2013-10-22 at 10:39 +0200, Martin Kosek wrote: > On 10/22/2013 02:41 AM, Dean Hunter wrote: > > This patch is only for the FreeIPA 3.1.5 User Guide. The 3.1.5 User > > Guide currently has a procedure carried over from the 2.2 User Guide. > > And the procedure will be different, again, for the 3.4 User Guide. The > > procedure is based on > > http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf. > > > > https://fedorahosted.org/freeipa/ticket/3756 > > Hi Dean, > > Thanks for the patch! I have few comments though. > > 1) ipa-client-install in the first paragraph should be in . I also think > there should be a short introduction of the section instead of directly jumping > to editing configs. > I suggest to use ipa-client-install. > I think that a modification of the previous one would work. Something like that: > ~~~ > Actually implementing sudo policies is more complicated than simply creating > the rules in FreeIPA. Those rules need to be applied to every local machine, > which means that each system in the FreeIPA domain has to be configured to > refer to FreeIPA for its policies. > > This example specifically configures a Fedora client for sudo rules. The sudo > on client is configured to use SSSD as a source of the policies: > ... > ~~~ Here is something from SSSD presentation which can helps you too: The SSSD works as a middleman between sudo command and the FreeIPA server. The SSSD caches sudo rules for a period of time, what makes sudo works even if the network is offline. > 2) I see that in the configuration examples you already pasted executable > scripts from your automation. > > However, I think that the "echo" and "sed" like examples will not bring enough > clarity for the users. I would rather prefer the standard examples (as in other > places in the guide) showing how the file should look like and leave the > automation on user (if he needs it), i.e. > > ~~~ > vim /etc/nsswitch.conf > > sudoers: files ldap > ~~~ > instead of > > ~~~ > [root at ipaclient] ~]# echo "sudoers: files sss" >>/etc/nsswitch.conf > ~~~ > > or > > ~~~ > [domain/example.com] > krb5_server = ipa.example.com > ldap_sasl_authid = host/hostname.example.com > ldap_sasl_mech = GSSAPI > ldap_sasl_realm = EXAMPLE.COM > ldap_sudo_search_base = ou=sudoers,dc=example,dc=com > ldap_uri = ldap://ipa.example.com > sudo_provider = ldap > ~~~ > > instead of > > ~~~ > [root at ipaclient] ~]# sed "/^\[domain\/example.com\]/ a\\ > > krb5_server = ipa.example.com\\ > > ldap_sasl_authid = host/hostname.example.com\\ > > ldap_sasl_mech = GSSAPI\\ > > ldap_sasl_realm = EXAMPLE.COM\\ > > ldap_sudo_search_base = ou=sudoers,dc=example,dc=com\\ > > ldap_uri = ldap://ipa.example.com\\ > > sudo_provider = ldap" /etc/sssd/sssd.conf > ~~~ > > etc. > > This will make the examples easier to read and consistent with the rest of the > guide. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Martin Basti From tbabej at redhat.com Tue Oct 22 10:27:19 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 22 Oct 2013 12:27:19 +0200 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests In-Reply-To: <52663961.3010606@redhat.com> References: <52370B90.2030009@redhat.com> <52381625.3010607@redhat.com> <52386896.3000909@redhat.com> <523B1F0F.3010101@redhat.com> <525C121E.3080406@redhat.com> <525E9825.2070008@redhat.com> <52653F46.7050503@redhat.com> <52663961.3010606@redhat.com> Message-ID: <52665307.3040906@redhat.com> On 10/22/2013 10:37 AM, Petr Viktorin wrote: > Replying to one part only: > > On 10/21/2013 04:50 PM, Tomas Babej wrote: >> On 10/16/2013 03:44 PM, Petr Viktorin wrote: >>> >>> I still think it would be simpler if IPA and AD domains shared the >>> numbering namespace (users would need to define $AD_env2; if they had >>> $MASTER_env1 and $AD_env1 they would be in the same Domain). >>> >>> But if we use _env1 for both the AD and the IPA domain, they need to >>> be separated in Domain.from_env. With patch 0101 both MASTER_env1 and >>> AD_env1 will be in both domains[0] and ad_domains[0]. >> >> I would rather not join IPA and AD domains as they even cannot be in the >> same domain, as the service records would clash. So these will >> always be separate / sub / super domain relationship. > > You're right that they should never share the same domain. But you > should never say never, especially in testing -- what if we'll want > to, in the future, test that the records *do* clash, or that IPA > refuses to install in an AD domain? > You could still set AD_env1 and MASTER_env1 to have the same domain. > Another problem is that they are now separate namespaces. In all code > that deals with domains you have to deal separately with the list of > AD domains and separately with IPA domains. This makes every piece of > code that doesn't care much about what type of domain it's dealing > with (configuration, listing, possible automation scripts for turning > on the VMs, etc.) more complicated. > Also, in this scheme, adding a new type of domain would be quite hard, > especially after more code is written with this split in mind. > > Do keep the domain type, though. tl;dr I'd really prefer "domain 1 > (IPA); domain 2 (AD)" rather than "IPA domain 1; AD domain 1". This will, however, require filtering the domains depending on the fact whether they contain AD or not. If a testcase wants to access an AD domain, it will still need to loop over the list of domains to see which ones are of AD type. Any code that does not care what domain type it's dealing with, can easily access all the domains by chaining the respective iterables. We could have a wrapper in the Config class for that, along the lines of get_all_domains(). So what I see here is that we're trading one complexity over another. I think we can agree on your approach since it hides the complexity from the user, especially in the ipa-test-config, which I admit is getting rather ugly, as we need to introduce new option there and that causes splitting. > > If needed we can have a special check that would reject IPA masters in > AD domains and vice versa, if that really turns out to be necessary. > With this check we should be fine. >> As we already pass ad_domain flag to Domain.from_env, I did incorporate >> code that joins the machines to the domain depending on the their role. >> Is that a viable solution for you? > > Sorry. I think this design is less sustainable than having a shared > namespace for the domains. > > I'll send revised patchset soon. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From deanhunter at comcast.net Tue Oct 22 11:12:09 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Tue, 22 Oct 2013 06:12:09 -0500 Subject: [Freeipa-devel] [PATCH][DOC] Configure sudo for FreeIPA 3.1.5 In-Reply-To: <526639D0.8060101@redhat.com> References: <1382402487.2620.3.camel@host.hunter.org> <526639D0.8060101@redhat.com> Message-ID: <1382440329.2620.12.camel@host.hunter.org> On Tue, 2013-10-22 at 10:39 +0200, Martin Kosek wrote: > On 10/22/2013 02:41 AM, Dean Hunter wrote: > > This patch is only for the FreeIPA 3.1.5 User Guide. The 3.1.5 User > > Guide currently has a procedure carried over from the 2.2 User Guide. > > And the procedure will be different, again, for the 3.4 User Guide. The > > procedure is based on > > http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf. > > > > https://fedorahosted.org/freeipa/ticket/3756 > > Hi Dean, > > Thanks for the patch! I have few comments though. > > 1) ipa-client-install in the first paragraph should be in . I also think > there should be a short introduction of the section instead of directly jumping > to editing configs. > > I think that a modification of the previous one would work. Something like that: > ~~~ > Actually implementing sudo policies is more complicated than simply creating > the rules in FreeIPA. Those rules need to be applied to every local machine, > which means that each system in the FreeIPA domain has to be configured to > refer to FreeIPA for its policies. > > This example specifically configures a Fedora client for sudo rules. The sudo > on client is configured to use SSSD as a source of the policies: > ... > ~~~ For this reason I considered moving the entire section to chapter 3, Setting up Systems as FreeIPA Clients. > 2) I see that in the configuration examples you already pasted executable > scripts from your automation. > > However, I think that the "echo" and "sed" like examples will not bring enough > clarity for the users. I would rather prefer the standard examples (as in other > places in the guide) showing how the file should look like and leave the > automation on user (if he needs it), i.e. > > ~~~ > vim /etc/nsswitch.conf > > sudoers: files ldap > ~~~ > instead of > > ~~~ > [root at ipaclient] ~]# echo "sudoers: files sss" >>/etc/nsswitch.conf > ~~~ > > or > > ~~~ > [domain/example.com] > krb5_server = ipa.example.com > ldap_sasl_authid = host/hostname.example.com > ldap_sasl_mech = GSSAPI > ldap_sasl_realm = EXAMPLE.COM > ldap_sudo_search_base = ou=sudoers,dc=example,dc=com > ldap_uri = ldap://ipa.example.com > sudo_provider = ldap > ~~~ > > instead of > > ~~~ > [root at ipaclient] ~]# sed "/^\[domain\/example.com\]/ a\\ > > krb5_server = ipa.example.com\\ > > ldap_sasl_authid = host/hostname.example.com\\ > > ldap_sasl_mech = GSSAPI\\ > > ldap_sasl_realm = EXAMPLE.COM\\ > > ldap_sudo_search_base = ou=sudoers,dc=example,dc=com\\ > > ldap_uri = ldap://ipa.example.com\\ > > sudo_provider = ldap" /etc/sssd/sssd.conf > ~~~ > > etc. > > This will make the examples easier to read and consistent with the rest of the > guide. "What" instead of "How", got it. So even "vim /etc/nsswitch.conf" should not be specified, just list the changed lines of the affected file. > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Tue Oct 22 12:15:07 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 22 Oct 2013 14:15:07 +0200 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests In-Reply-To: <52665307.3040906@redhat.com> References: <52370B90.2030009@redhat.com> <52381625.3010607@redhat.com> <52386896.3000909@redhat.com> <523B1F0F.3010101@redhat.com> <525C121E.3080406@redhat.com> <525E9825.2070008@redhat.com> <52653F46.7050503@redhat.com> <52663961.3010606@redhat.com> <52665307.3040906@redhat.com> Message-ID: <52666C4B.1040404@redhat.com> On 10/22/2013 12:27 PM, Tomas Babej wrote: > On 10/22/2013 10:37 AM, Petr Viktorin wrote: >> Replying to one part only: >> >> On 10/21/2013 04:50 PM, Tomas Babej wrote: >>> On 10/16/2013 03:44 PM, Petr Viktorin wrote: >>>> >>>> I still think it would be simpler if IPA and AD domains shared the >>>> numbering namespace (users would need to define $AD_env2; if they had >>>> $MASTER_env1 and $AD_env1 they would be in the same Domain). >>>> >>>> But if we use _env1 for both the AD and the IPA domain, they need to >>>> be separated in Domain.from_env. With patch 0101 both MASTER_env1 and >>>> AD_env1 will be in both domains[0] and ad_domains[0]. >>> >>> I would rather not join IPA and AD domains as they even cannot be in >>> the >>> same domain, as the service records would clash. So these will >>> always be separate / sub / super domain relationship. >> >> You're right that they should never share the same domain. But you >> should never say never, especially in testing -- what if we'll want >> to, in the future, test that the records *do* clash, or that IPA >> refuses to install in an AD domain? >> > > You could still set AD_env1 and MASTER_env1 to have the same domain. > >> Another problem is that they are now separate namespaces. In all code >> that deals with domains you have to deal separately with the list of >> AD domains and separately with IPA domains. This makes every piece of >> code that doesn't care much about what type of domain it's dealing >> with (configuration, listing, possible automation scripts for turning >> on the VMs, etc.) more complicated. >> Also, in this scheme, adding a new type of domain would be quite >> hard, especially after more code is written with this split in mind. >> >> Do keep the domain type, though. tl;dr I'd really prefer "domain 1 >> (IPA); domain 2 (AD)" rather than "IPA domain 1; AD domain 1". > > This will, however, require filtering the domains depending on the > fact whether they contain AD or not. If a testcase wants to access an > AD domain, it will still need to loop over the list of domains to see > which ones are of AD type. > > Any code that does not care what domain type it's dealing with, can > easily access all the domains by chaining the respective iterables. We > could have a wrapper in the Config class for that, along the lines of > get_all_domains(). > > So what I see here is that we're trading one complexity over another. > > I think we can agree on your approach since it hides the complexity > from the user, especially in the ipa-test-config, which I admit is > getting rather ugly, as we need to introduce new option there and that > causes splitting. > >> >> If needed we can have a special check that would reject IPA masters >> in AD domains and vice versa, if that really turns out to be necessary. >> > > With this check we should be fine. > >>> As we already pass ad_domain flag to Domain.from_env, I did incorporate >>> code that joins the machines to the domain depending on the their role. >>> Is that a viable solution for you? >> >> Sorry. I think this design is less sustainable than having a shared >> namespace for the domains. >> >> > I'll send revised patchset soon. > > Updated patchset attached. -- 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-0106-9-ipatests-Add-AD-integration-test-case.patch Type: text/x-patch Size: 7765 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0105-9-ipatests-Add-AD-integration-related-tasks.patch Type: text/x-patch Size: 17330 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0104-9-ipatests-Add-WinHost-class.patch Type: text/x-patch Size: 1733 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0103-9-ipatests-Create-util-module-for-ipatests.patch Type: text/x-patch Size: 2896 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0102-9-ipatests-Extend-IntegrationTest-with-multiple-AD-dom.patch Type: text/x-patch Size: 2840 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0101-9-ipatests-Extend-domain-object-with-ad-role-support-a.patch Type: text/x-patch Size: 3661 bytes Desc: not available URL: From tbabej at redhat.com Tue Oct 22 12:24:22 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 22 Oct 2013 14:24:22 +0200 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests In-Reply-To: <52666C4B.1040404@redhat.com> References: <52370B90.2030009@redhat.com> <52381625.3010607@redhat.com> <52386896.3000909@redhat.com> <523B1F0F.3010101@redhat.com> <525C121E.3080406@redhat.com> <525E9825.2070008@redhat.com> <52653F46.7050503@redhat.com> <52663961.3010606@redhat.com> <52665307.3040906@redhat.com> <52666C4B.1040404@redhat.com> Message-ID: <52666E76.80104@redhat.com> On 10/22/2013 02:15 PM, Tomas Babej wrote: > On 10/22/2013 12:27 PM, Tomas Babej wrote: >> On 10/22/2013 10:37 AM, Petr Viktorin wrote: >>> Replying to one part only: >>> >>> On 10/21/2013 04:50 PM, Tomas Babej wrote: >>>> On 10/16/2013 03:44 PM, Petr Viktorin wrote: >>>>> >>>>> I still think it would be simpler if IPA and AD domains shared the >>>>> numbering namespace (users would need to define $AD_env2; if they had >>>>> $MASTER_env1 and $AD_env1 they would be in the same Domain). >>>>> >>>>> But if we use _env1 for both the AD and the IPA domain, they need to >>>>> be separated in Domain.from_env. With patch 0101 both MASTER_env1 and >>>>> AD_env1 will be in both domains[0] and ad_domains[0]. >>>> >>>> I would rather not join IPA and AD domains as they even cannot be >>>> in the >>>> same domain, as the service records would clash. So these will >>>> always be separate / sub / super domain relationship. >>> >>> You're right that they should never share the same domain. But you >>> should never say never, especially in testing -- what if we'll want >>> to, in the future, test that the records *do* clash, or that IPA >>> refuses to install in an AD domain? >>> >> >> You could still set AD_env1 and MASTER_env1 to have the same domain. >> >>> Another problem is that they are now separate namespaces. In all >>> code that deals with domains you have to deal separately with the >>> list of AD domains and separately with IPA domains. This makes every >>> piece of code that doesn't care much about what type of domain it's >>> dealing with (configuration, listing, possible automation scripts >>> for turning on the VMs, etc.) more complicated. >>> Also, in this scheme, adding a new type of domain would be quite >>> hard, especially after more code is written with this split in mind. >>> >>> Do keep the domain type, though. tl;dr I'd really prefer "domain 1 >>> (IPA); domain 2 (AD)" rather than "IPA domain 1; AD domain 1". >> >> This will, however, require filtering the domains depending on the >> fact whether they contain AD or not. If a testcase wants to access an >> AD domain, it will still need to loop over the list of domains to see >> which ones are of AD type. >> >> Any code that does not care what domain type it's dealing with, can >> easily access all the domains by chaining the respective iterables. >> We could have a wrapper in the Config class for that, along the lines >> of get_all_domains(). >> >> So what I see here is that we're trading one complexity over another. >> >> I think we can agree on your approach since it hides the complexity >> from the user, especially in the ipa-test-config, which I admit is >> getting rather ugly, as we need to introduce new option there and >> that causes splitting. >> >>> >>> If needed we can have a special check that would reject IPA masters >>> in AD domains and vice versa, if that really turns out to be necessary. >>> >> >> With this check we should be fine. >> >>>> As we already pass ad_domain flag to Domain.from_env, I did >>>> incorporate >>>> code that joins the machines to the domain depending on the their >>>> role. >>>> Is that a viable solution for you? >>> >>> Sorry. I think this design is less sustainable than having a shared >>> namespace for the domains. >>> >>> >> I'll send revised patchset soon. >> >> > Updated patchset attached. > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Attaching the patch 100 I missed. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0100-9-ipatests-Add-Active-Directory-support-to-configurati.patch Type: text/x-patch Size: 6254 bytes Desc: not available URL: From pspacek at redhat.com Tue Oct 22 14:42:11 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 22 Oct 2013 16:42:11 +0200 Subject: [Freeipa-devel] FreeIPA.org/Documentation improvements: request for comments In-Reply-To: <1382446811.9794.36.camel@willson.li.ssimo.org> References: <5261D896.2030004@redhat.com> <1382167087.31620.109.camel@willson.li.ssimo.org> <5262F503.60709@redhat.com> <1382305266.31620.244.camel@willson.li.ssimo.org> <20131021065922.GA13851@mail.corp.redhat.com> <5264E5B3.7050109@redhat.com> <526531F9.50304@redhat.com> <5265393A.7060001@redhat.com> <526552F2.80004@redhat.com> <5266619C.3080908@redhat.com> <1382446811.9794.36.camel@willson.li.ssimo.org> Message-ID: <52668EC3.8000406@redhat.com> Hello list, here is never-ending discussion about freeipa.org wiki and documentation. Any opinions are more than welcome! (Each participating user will receive e-thank-you e-mail, I promise! :-D) We started the discussion privately and then realized that we should move it to mailing list, so some ideas are on the table. This doesn't mean that we have to stick with any of current proposals! Bring you ideas! On 22.10.2013 15:00, Simo Sorce wrote: > On Tue, 2013-10-22 at 13:29 +0200, Martin Kosek wrote: >> On 10/21/2013 06:14 PM, Petr Spacek wrote: >>> On 21.10.2013 16:24, Martin Kosek wrote: >>>> On 10/21/2013 03:54 PM, Dmitri Pal wrote: >>>>> On 10/21/2013 04:28 AM, Petr Spacek wrote: [snip] >>>>>> http://www.freeipa.org/page/Documentation needs significant >>>>>> improvement, I agree. [snip] >>>> >>>> Sure. Though I am already tracking this page. Since summer, I have been >>>> continuously working on merging the documentation on FreeIPA (like some obscure >>>> Tips or three different FAQ sections), obsoleting information that is obsolete >>>> and adding warnings or moving v1/v2 development-specific documentation to >>>> specific name spaces to avoid them interfering with standard doc and other >>>> changes. >>>> >>>> I think the Documentation page is easier to digest already, compared to what >>>> was there before: >>>> >>>> http://www.freeipa.org/index.php?title=Documentation&diff=6912&oldid=6203 >>>> >>>> So instead of "FreeIPA.org wiki is wrong, awful and eats little puppies" I >>>> would prefer to see some concrete ideas for improvements or better UX so that I >>>> can follow up on them and continue driving it to be better. >>> >>> Sure :-) Here are my proposals: >> >> Thank you! >> >>> - move "Developer Documentation" away from "/Documentation" to separate page >> >> Why? It will make it less visible. I think that it contain a lot of useful >> information, even for users/power-users. > > I agree this will plunge us back to the old wiki which was bad. I don't belive that regular users search/read design docs. Is the design valueable for normal user? Then a) relevant information should be extracted to a article for users AND/OR b) the design page should be linked directly from Components/FAQ/how-to >>> - move section "By Component" to the end of the page - it is mostly empty ... >>> (of course, we can move it back to the beginning after some time!) >> >> Can be done, though it would be even better to simply add the component >> documentation - otherwise we are just hiding a missing doc, not fixing it. > > Indeed, my aim in creating the section was to highlight what people > would like to see and entice some of us in producing more content. It is > time we do. If we do it right we'll have great value for our users. > > And right is not hard, perhaps a bit tedious, but it is just about > describing with medium level details the various components with > particular care in describing how they interact with others (9bonus > point if links between the various pages are provided when we mention > interactions. > > Seem a good project for a new engineer that needs to go through and > understand what is going on. By writing these pages he'll have to ask > the right questions to older engineers and put them into words, I found > it is an invaluable way to actually get to understand the big picture. My point is that the wiki should expose useful information *at the beginning*. I definitelly agree that filling the wiki with information is much better than hidding empty pages, but this great idea doesn't help to users looking for help right now. I propose to move "Components" to the end (or before "Devel" docs) for now - simply to make more valuable sections more visible. My intention is to make the /Documentation page more useful right now and I belive that this trivial re-ordering will help with that. Sure, we can move "Components" back as soon as it will contain some useful information. Does it explain my intention? >>> - merge "Additional Resources" section with "FreeIPA Training Series" section >>> and "Public Presentations" section >> >> How FAQ or HOWTOs relate to Training Series or Public Presentations? Or you >> just meant placing them close together? > > I also failed to understand this, they are completely different > categories. > > The videos and presentations are for people that want generic info. The > HowTo/Faqs are for peopl that have a specific problem and are looking > for a solution. Exactly. That is what I proposed below - separate sections 'marketing' (high level stuff) and 'get your hands dirty' (the useful stuff). See below. >>> - pull all how-tos to "/Documentation" >> >> I am not sure that placing all these articles directly to /Documentation would >> make it simpler. I understand /Documentation rather as a focal point of all >> documentation, which can lead you directly to the information you seek. I can see you point. The reply to this matter continues at the end of e-mail, I noticed that you wrote some other points about how-tos there. > They should be in a Troubleshooting section at most, but they are > clearly Documentation. I'm not following you. How is "How to configure Zimbra" related to "Troubleshooting"? >>> I don't think that users care about distinction between "Additional >>> Resources"/"FreeIPA Training Series"/"Public Presentations" section. The >>> differentiation could be more about 'marketing' and 'get your hands dirty' >>> categories. >> >> Makes sense. We can switch from User Documentation/Developer Documentation to >> this distinction. > > This sounds like a good improvement. > >>> Reorganize how-tos: >>> My intention is to have all articles related e.g. to 'Zimbra' linked from one >>> place, all articles about NFS from another place etc. I don't have much >>> experience with "sub/categories" in Wikimedia, but I hope that we can create >>> something like this: >>> http://en.wikipedia.org/wiki/Category:Cryptographic_algorithms >> >> We can, if it makes sense. We can simply mark the howtos with categories and >> mediawiki will do the rest. >> >> Did you check the HOWTO page lately? I did a bit of reorganization there last >> week, grouping HOWTOs to sections, like "Mail Services" - this should help the >> grouping you have in mind. > > Nice work! Really good work! I wasn't there last week. I still think that structure like '3rd party/Zimbra/Authentication' and '3rd party/Zimbra/Address Book from LDAP' could be clearer and easier to navigate. (Mediawiki can generate even some fancy category/article trees like this one: http://en.wikipedia.org/w/index.php?title=Special%3ACategoryTree&target=Computer+science&mode=all .) Maybe that some non-application-specific articles from 'Working with FreeIPA' and 'Interoperability with other systems' sections can be moved to "Components" in /Documentation ... (e.g. working with 3rd party certificates, migration, NIS etc.) What about task-oriented structure for /Documentation ? (Note that one article can be linked multiple times.) Something like: 1. What FreeIPA is - marketing stuff 2. Getting Started - articles about installation & client setup 3. Cool features (detailed presentations, articles), like: - SUDO presentations and articles - SSH key management 4. Applications/3rd party integration 4.a. Trusting Microsoft Windows world 5. Troubleshooting articles 6. Devel docs The question is where guides and similar docs fit to this schema. I'm not sure. Maybe that this 'task-oriented' structure is good only for beginners, maybe that is it wireframe for 'Getting Started page'. I'm not sure... -- Petr^2 Spacek From mkosek at redhat.com Tue Oct 22 14:59:15 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 22 Oct 2013 16:59:15 +0200 Subject: [Freeipa-devel] FreeIPA.org/Documentation improvements: request for comments In-Reply-To: <52668EC3.8000406@redhat.com> References: <5261D896.2030004@redhat.com> <1382167087.31620.109.camel@willson.li.ssimo.org> <5262F503.60709@redhat.com> <1382305266.31620.244.camel@willson.li.ssimo.org> <20131021065922.GA13851@mail.corp.redhat.com> <5264E5B3.7050109@redhat.com> <526531F9.50304@redhat.com> <5265393A.7060001@redhat.com> <526552F2.80004@redhat.com> <5266619C.3080908@redhat.com> <1382446811.9794.36.camel@willson.li.ssimo.org> <52668EC3.8000406@redhat.com> Message-ID: <526692C3.4060107@redhat.com> On 10/22/2013 04:42 PM, Petr Spacek wrote: > Hello list, > > here is never-ending discussion about freeipa.org wiki and documentation. Any > opinions are more than welcome! (Each participating user will receive > e-thank-you e-mail, I promise! :-D) > > We started the discussion privately and then realized that we should move it to > mailing list, so some ideas are on the table. This doesn't mean that we have to > stick with any of current proposals! Bring you ideas! > > On 22.10.2013 15:00, Simo Sorce wrote: >> On Tue, 2013-10-22 at 13:29 +0200, Martin Kosek wrote: >>> On 10/21/2013 06:14 PM, Petr Spacek wrote: >>>> On 21.10.2013 16:24, Martin Kosek wrote: >>>>> On 10/21/2013 03:54 PM, Dmitri Pal wrote: >>>>>> On 10/21/2013 04:28 AM, Petr Spacek wrote: > [snip] >>>>>>> http://www.freeipa.org/page/Documentation needs significant >>>>>>> improvement, I agree. > [snip] >>>>> >>>>> Sure. Though I am already tracking this page. Since summer, I have been >>>>> continuously working on merging the documentation on FreeIPA (like some >>>>> obscure >>>>> Tips or three different FAQ sections), obsoleting information that is >>>>> obsolete >>>>> and adding warnings or moving v1/v2 development-specific documentation to >>>>> specific name spaces to avoid them interfering with standard doc and other >>>>> changes. >>>>> >>>>> I think the Documentation page is easier to digest already, compared to what >>>>> was there before: >>>>> >>>>> http://www.freeipa.org/index.php?title=Documentation&diff=6912&oldid=6203 >>>>> >>>>> So instead of "FreeIPA.org wiki is wrong, awful and eats little puppies" I >>>>> would prefer to see some concrete ideas for improvements or better UX so >>>>> that I >>>>> can follow up on them and continue driving it to be better. >>>> >>>> Sure :-) Here are my proposals: >>> >>> Thank you! >>> >>>> - move "Developer Documentation" away from "/Documentation" to separate page >>> >>> Why? It will make it less visible. I think that it contain a lot of useful >>> information, even for users/power-users. >> >> I agree this will plunge us back to the old wiki which was bad. > > I don't belive that regular users search/read design docs. Is the design > valueable for normal user? I think so, at least the use cases and work flows can be interesting for users and administrators. It is just another source of on-topic information at the minimum Then > a) relevant information should be extracted to a article for users > AND/OR > b) the design page should be linked directly from Components/FAQ/how-to I would stick with b). I see a big value in the by component documentation. I think that the general component overview is a good place for people to learn what it is, what it does, where to get more information - links to other useful resources on our wiki - like the aforementioned designs. Look for example on the Trusts component, some progress already sparkled there: http://www.freeipa.org/page/TrustsServices ... and should be improved in the future. When we have these components with information, we can then pretty effectively link to them when writing about a design (i.e. [[Trusts]] or [[Web UI]]) and thus achieve the right wiki spirit and interlinked information on FreeIPA.org. > >>>> - move section "By Component" to the end of the page - it is mostly empty ... >>>> (of course, we can move it back to the beginning after some time!) >>> >>> Can be done, though it would be even better to simply add the component >>> documentation - otherwise we are just hiding a missing doc, not fixing it. >> >> Indeed, my aim in creating the section was to highlight what people >> would like to see and entice some of us in producing more content. It is >> time we do. If we do it right we'll have great value for our users. >> >> And right is not hard, perhaps a bit tedious, but it is just about >> describing with medium level details the various components with >> particular care in describing how they interact with others (9bonus >> point if links between the various pages are provided when we mention >> interactions. >> >> Seem a good project for a new engineer that needs to go through and >> understand what is going on. By writing these pages he'll have to ask >> the right questions to older engineers and put them into words, I found >> it is an invaluable way to actually get to understand the big picture. > > My point is that the wiki should expose useful information *at the beginning*. > > I definitelly agree that filling the wiki with information is much better than > hidding empty pages, but this great idea doesn't help to users looking for help > right now. > > I propose to move "Components" to the end (or before "Devel" docs) for now - > simply to make more valuable sections more visible. > > My intention is to make the /Documentation page more useful right now and I > belive that this trivial re-ordering will help with that. > > Sure, we can move "Components" back as soon as it will contain some useful > information. > > Does it explain my intention? It does, though I still do not think this step is needed. Some components already have some information (Trusts, Web UI, Client, DNS), which is should help a bit. Would adding http://en.wikipedia.org/wiki/Template:Stub like warning to the pages make it less confusing and invite people more to help us improve it? :) > ... > Really good work! I wasn't there last week. > > I still think that structure like '3rd party/Zimbra/Authentication' and '3rd > party/Zimbra/Address Book from LDAP' could be clearer and easier to navigate. > (Mediawiki can generate even some fancy category/article trees like this one: > http://en.wikipedia.org/w/index.php?title=Special%3ACategoryTree&target=Computer+science&mode=all > .) Makes sense. It would need to be used by every contributor though in order for the result to make sense. > > Maybe that some non-application-specific articles from 'Working with FreeIPA' > and 'Interoperability with other systems' sections can be moved to "Components" > in /Documentation ... (e.g. working with 3rd party certificates, migration, NIS > etc.) > > > What about task-oriented structure for /Documentation ? (Note that one article > can be linked multiple times.) > > Something like: > 1. What FreeIPA is - marketing stuff > 2. Getting Started - articles about installation & client setup > 3. Cool features (detailed presentations, articles), like: > - SUDO presentations and articles > - SSH key management > 4. Applications/3rd party integration > 4.a. Trusting Microsoft Windows world > 5. Troubleshooting articles > 6. Devel docs > > The question is where guides and similar docs fit to this schema. I'm not sure. > > > Maybe that this 'task-oriented' structure is good only for beginners, maybe > that is it wireframe for 'Getting Started page'. I'm not sure... More task-oriented approach to FreeIPA.org front page and Documentation page may indeed be helpful. The challenge is indeed in making it task oriented and still keep it as useful reference for experienced users. Martin From akrivoka at redhat.com Tue Oct 22 18:15:26 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 22 Oct 2013 20:15:26 +0200 Subject: [Freeipa-devel] [PATCH] 0076 Add test for external CA installation Message-ID: <5266C0BE.2000504@redhat.com> Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3819 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0076-Add-test-for-external-CA-installation.patch Type: text/x-patch Size: 4691 bytes Desc: not available URL: From mbasti at redhat.com Wed Oct 23 11:17:05 2013 From: mbasti at redhat.com (Martin Basti) Date: Wed, 23 Oct 2013 13:17:05 +0200 Subject: [Freeipa-devel] [PATCH][DOC] 0017 Chapter 16 defining SELinux user maps update Message-ID: <1382527025.2265.1.camel@unused-4-145.brq.redhat.com> Patch attached. -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0017-Chapter-16-defining-SELinux-user-maps-update.patch Type: text/x-patch Size: 462635 bytes Desc: not available URL: From thozza at redhat.com Wed Oct 23 14:54:06 2013 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 23 Oct 2013 16:54:06 +0200 Subject: [Freeipa-devel] [PATCH 0186-0191] Replace LDAP cache with RBTDB In-Reply-To: <5256DCBC.3070901@redhat.com> References: <51FA694C.1000302@redhat.com> <520B9373.1070707@redhat.com> <520B9755.70503@redhat.com> <523313C3.8070306@redhat.com> <524BFBFD.1000901@redhat.com> <5253D7A0.2020108@redhat.com> <5256DCBC.3070901@redhat.com> Message-ID: <5267E30E.4010401@redhat.com> On 10/10/2013 06:58 PM, Petr Spacek wrote: > On 8.10.2013 12:00, Tomas Hozza wrote: >> On 10/02/2013 12:57 PM, Petr Spacek wrote: >>> On 13.9.2013 15:31, Petr Spacek wrote: >>>> On 14.8.2013 16:42, Petr Spacek wrote: >>>>> On 14.8.2013 16:25, Petr Spacek wrote: >>>>>> On 1.8.2013 15:57, Petr Spacek wrote: >>>>>>> Hello, >>>>>>> >>>>>>> attached monster patches replace our internal cache/database with >>>>>>> RBTDB >>>>>>> implementation. See commit messages and comments inside. >>>>>>> >>>>>>> This patch set provides very basic functionality (including DNS >>>>>>> support for >>>>>>> updates). Error handling definitely needs more love, but it should >>>>>>> be enough >>>>>>> for rapid DNSSEC prototyping. >>>>>> >>>>>> Patch 186 v2: The code now applies incremental changes in LDAP to the >>>>>> in-memory database. Commit message was modified to mention that >>>>>> wildcards are >>>>>> now supported. >>>>>> >>>>>> Patch 187 v2: The code was re-worked and now it respects >>>>>> serial_autoincrement >>>>>> option. >>>>>> >>>>>> Patch 188 v2: Minor comment clean-up and rebase on top of patch >>>>>> 187 v2. >>>>>> >>>>>> Patch 189 v2: Call to deleterdataset() nested in substractrdataset() >>>>>> was >>>>>> deleted. This code was meant only for testing purposes. >>>>>> >>>>>> These patch set is now ready for review. Please see commit messages! >>>>>> Some >>>>>> functionality is missing intentionally, but it will be fixed by >>>>>> separate >>>>>> patches. >>>>> >>>>> It would be too easy! >>>>> >>>>> Patch 186 v3: Commit message was extended with information that LDAP >>>>> MODRDN >>>>> operation is not supported at the moment. >>>>> >>>>> Patch 187 v3: Missing file ldap_driver.h was added. >>>> >>>> This extended patch set handles correctly object deletion from LDAP. >>>> >>>> Patches 186-189 contain very minor changes, only moving code from one >>>> place to >>>> the other. >>>> >>>> See commit messages for patches 190 and 191. >>>> >>>> This should be testable. I would recommend to test the whole patch >>>> set at >>>> once, most probably it doesn't make much sense to test patches >>>> separately. >>> >>> bind-dyndb-ldap-pspacek-0186-5-Use-RBTDB-instead-of-internal-LDAP-cache.patch >>> >>> adds missing missing include (db.h) to zone_register.c. >>> >> >> ACK. >> >> Patches 186-191 tested. Adding/removing/modifying records works fine. >> Also PTR synchronization works. Zone transfer to slave and NOTIFY >> tested when changes occurred on master. > > Patch 191-2 fixed problem with zone removal and race condition during > zone load. I would recommend you to test it with other patch I plan to > send today :-) > ACK. Patch looks good. Regards, Tomas From thozza at redhat.com Wed Oct 23 15:12:08 2013 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 23 Oct 2013 17:12:08 +0200 Subject: [Freeipa-devel] [PATCH 0192-0196] Write all changes to journal In-Reply-To: <5256DE40.4060000@redhat.com> References: <5256DE40.4060000@redhat.com> Message-ID: <5267E748.5000800@redhat.com> On 10/10/2013 07:05 PM, Petr Spacek wrote: > Hello, > > this patch set adds journaling to bind-dyndb-ldap. > > Journaling requires proper SOA serial maintenance, so from now > SOA serial auto-incrementation is mandatory. > > Journal file is deleted on each start, so IXFR is limited to time frame > from last BIND start. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/64 > > > You can use my personal branch for testing: > https://github.com/spacekpe/bind-dyndb-ldap/tree/rbtdb.v7 > > It contains all unpushed patches. Basically, next master should be identical > to this branch. > > Thank you for your time! > > -- Petr^2 Spacek ACK. IXFR works as should. Also tested that journal is cleared after BIND restart, so server responds with AXFR. Patches look good, I have only one small thing to patch 0193: > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 0786979a1970f4b61ac5b92dd5554bf87032d1ff..89acbe610519bbe0610a07d5fa5d4ffceddc71cd 100644 > > --- a/src/ldap_helper.c > > +++ b/src/ldap_helper.c > > ... > > @@ -1401,7 +1405,155 @@ > > cleanup: > return result; > } > +/** > + * Process strictly minimal diff and detect if data were changed > + * and return latest SOA RR. > + * > + * @pre Input diff has to be minimal, i.e. it can't contain DEL & ADD > operation > + * for the same data under the same name and TTL. > + * > + * @pre If the tuple list contains SOA RR, then exactly one SOA RR > deletion > + * has to precede exactly one SOA RR addition. > + * (Each SOA RR deletion has to have matching addition.) > + * > + * @param[in] diff Input diff. List of tuples can be empty. > + * @param[out] soa_latest Pointer to last added SOA RR from tuple list. > + * Result can be NULL if there is no added SOA RR > + * in the tuple list. > + * @param[out] data_changed ISC_TRUE if any data other than SOA serial > were > + * changed. ISC_FALSE if nothing (except SOA > + * serial) was changed. > + * > + */ > +static isc_result_t ATTR_NONNULLS > +diff_analyze_serial(dns_diff_t *diff, dns_difftuple_t **soa_latest, > + isc_boolean_t *data_changed) { > + dns_difftuple_t *t = NULL; > + dns_rdata_t *del_soa = NULL; /* last seen SOA with op == DEL */ > + dns_difftuple_t *tmp_tuple = NULL; /* tuple used for SOA comparison */ > + isc_result_t result = ISC_R_SUCCESS; > + int ret; > + > + REQUIRE(DNS_DIFF_VALID(diff)); > + REQUIRE(soa_latest != NULL && *soa_latest == NULL); > + REQUIRE(data_changed != NULL); > + > + *data_changed = ISC_FALSE; > + for (t = HEAD(diff->tuples); > + t != NULL; > + t = NEXT(t, link)) { > + INSIST(tmp_tuple == NULL); after this ^^^ line tmp_tuple is NULL in the current for loop cycle. > + if (t->rdata.type != dns_rdatatype_soa) > + *data_changed = ISC_TRUE; > + else { /* SOA is always special case */ > + if (t->op == DNS_DIFFOP_DEL || > + t->op == DNS_DIFFOP_DELRESIGN) { > + /* delete operation has to precede add */ > + INSIST(del_soa == NULL); > + INSIST(tmp_tuple == NULL); so this ^^^ check is duplicit > + del_soa = &t->rdata; > + } else if (t->op == DNS_DIFFOP_ADD || > + t->op == DNS_DIFFOP_ADDRESIGN) { > + /* add operation has to follow a delete */ > + INSIST(del_soa != NULL); > + INSIST(tmp_tuple == NULL); and also this ^^^ check is duplicit > + *soa_latest = t; > + > + /* detect if fields other than serial > + * were changed (compute only if necessary) */ > + if (*data_changed == ISC_FALSE) { > + CHECK(dns_difftuple_copy(t, &tmp_tuple)); > + dns_soa_setserial(dns_soa_getserial(del_soa), > + &tmp_tuple->rdata); > + ret = dns_rdata_compare(del_soa, > + &tmp_tuple->rdata); > + *data_changed = ISC_TF(ret != 0); > + } > + if (tmp_tuple != NULL) > + dns_difftuple_free(&tmp_tuple); > + /* re-start the SOA delete-add search cycle */ > + del_soa = NULL; > + } else { > + INSIST("unexpected diff: op != ADD || DEL" > + == NULL); > + } > + } > + } > + /* SOA deletions & additions has to create self-contained couples */ > + INSIST(del_soa == NULL && tmp_tuple == NULL); > + > +cleanup: > + if (tmp_tuple != NULL) > + dns_difftuple_free(&tmp_tuple); > + return result; > +} > + > ... Sorry for the formatting, obviously my email client is not perfect. Hope you can understand it... Regards, Tomas From thozza at redhat.com Wed Oct 23 15:12:40 2013 From: thozza at redhat.com (Tomas Hozza) Date: Wed, 23 Oct 2013 17:12:40 +0200 Subject: [Freeipa-devel] [PATCH 0197-0200] Preparation for bind-dyndb-ldap release 4.0 In-Reply-To: <5257FEB1.6020306@redhat.com> References: <5257FEB1.6020306@redhat.com> Message-ID: <5267E768.1020709@redhat.com> On 10/11/2013 03:35 PM, Petr Spacek wrote: > Hello, > > update documentation and schema files for upcoming version 4.0. > > This fixes typo in schema file: > https://fedorahosted.org/bind-dyndb-ldap/ticket/121 > > Have a nice weekend! > ACK. Looks good. Regards, Tomas From pspacek at redhat.com Wed Oct 23 15:14:23 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 23 Oct 2013 17:14:23 +0200 Subject: [Freeipa-devel] [PATCH 0201] Report error if RFC 4533 initialization failed Message-ID: <5267E7CF.2000202@redhat.com> Hello, this patch belongs to 4.0 release. It allows the user to catch some mis-configurations. It produces error messages like this: LDAP error: Critical extension is unavailable: unable to start SyncRepl session: is RFC 4533 supported on LDAP server? -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0201-Report-error-if-RFC-4533-initialization-failed.patch Type: text/x-patch Size: 1125 bytes Desc: not available URL: From pspacek at redhat.com Wed Oct 23 15:20:46 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 23 Oct 2013 17:20:46 +0200 Subject: [Freeipa-devel] [PATCH 0192-0196] Write all changes to journal In-Reply-To: <5267E748.5000800@redhat.com> References: <5256DE40.4060000@redhat.com> <5267E748.5000800@redhat.com> Message-ID: <5267E94E.1050001@redhat.com> On 23.10.2013 17:12, Tomas Hozza wrote: > On 10/10/2013 07:05 PM, Petr Spacek wrote: >> Hello, >> >> this patch set adds journaling to bind-dyndb-ldap. >> >> Journaling requires proper SOA serial maintenance, so from now >> SOA serial auto-incrementation is mandatory. >> >> Journal file is deleted on each start, so IXFR is limited to time frame >> from last BIND start. >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/64 >> >> >> You can use my personal branch for testing: >> https://github.com/spacekpe/bind-dyndb-ldap/tree/rbtdb.v7 >> >> It contains all unpushed patches. Basically, next master should be identical >> to this branch. >> >> Thank you for your time! >> >> -- Petr^2 Spacek > > ACK. > > IXFR works as should. Also tested that journal is cleared after BIND > restart, so server responds with AXFR. > > Patches look good, I have only one small thing to patch 0193: > >> diff --git a/src/ldap_helper.c b/src/ldap_helper.c >> index 0786979a1970f4b61ac5b92dd5554bf87032d1ff..89acbe610519bbe0610a07d5fa5d4ffceddc71cd 100644 >> >> --- a/src/ldap_helper.c >> >> +++ b/src/ldap_helper.c >> >> ... >> >> @@ -1401,7 +1405,155 @@ >> >> cleanup: >> return result; >> } >> +/** >> + * Process strictly minimal diff and detect if data were changed >> + * and return latest SOA RR. >> + * >> + * @pre Input diff has to be minimal, i.e. it can't contain DEL & ADD >> operation >> + * for the same data under the same name and TTL. >> + * >> + * @pre If the tuple list contains SOA RR, then exactly one SOA RR >> deletion >> + * has to precede exactly one SOA RR addition. >> + * (Each SOA RR deletion has to have matching addition.) >> + * >> + * @param[in] diff Input diff. List of tuples can be empty. >> + * @param[out] soa_latest Pointer to last added SOA RR from tuple list. >> + * Result can be NULL if there is no added SOA RR >> + * in the tuple list. >> + * @param[out] data_changed ISC_TRUE if any data other than SOA serial >> were >> + * changed. ISC_FALSE if nothing (except SOA >> + * serial) was changed. >> + * >> + */ >> +static isc_result_t ATTR_NONNULLS >> +diff_analyze_serial(dns_diff_t *diff, dns_difftuple_t **soa_latest, >> + isc_boolean_t *data_changed) { >> + dns_difftuple_t *t = NULL; >> + dns_rdata_t *del_soa = NULL; /* last seen SOA with op == DEL */ >> + dns_difftuple_t *tmp_tuple = NULL; /* tuple used for SOA comparison */ >> + isc_result_t result = ISC_R_SUCCESS; >> + int ret; >> + >> + REQUIRE(DNS_DIFF_VALID(diff)); >> + REQUIRE(soa_latest != NULL && *soa_latest == NULL); >> + REQUIRE(data_changed != NULL); >> + >> + *data_changed = ISC_FALSE; >> + for (t = HEAD(diff->tuples); >> + t != NULL; >> + t = NEXT(t, link)) { >> + INSIST(tmp_tuple == NULL); > after this ^^^ line tmp_tuple is NULL in the current for loop cycle. >> + if (t->rdata.type != dns_rdatatype_soa) >> + *data_changed = ISC_TRUE; >> + else { /* SOA is always special case */ >> + if (t->op == DNS_DIFFOP_DEL || >> + t->op == DNS_DIFFOP_DELRESIGN) { >> + /* delete operation has to precede add */ >> + INSIST(del_soa == NULL); >> + INSIST(tmp_tuple == NULL); > so this ^^^ check is duplicit >> + del_soa = &t->rdata; >> + } else if (t->op == DNS_DIFFOP_ADD || >> + t->op == DNS_DIFFOP_ADDRESIGN) { >> + /* add operation has to follow a delete */ >> + INSIST(del_soa != NULL); >> + INSIST(tmp_tuple == NULL); > and also this ^^^ check is duplicit >> + *soa_latest = t; >> + >> + /* detect if fields other than serial >> + * were changed (compute only if necessary) */ >> + if (*data_changed == ISC_FALSE) { >> + CHECK(dns_difftuple_copy(t, &tmp_tuple)); >> + dns_soa_setserial(dns_soa_getserial(del_soa), >> + &tmp_tuple->rdata); >> + ret = dns_rdata_compare(del_soa, >> + &tmp_tuple->rdata); >> + *data_changed = ISC_TF(ret != 0); >> + } >> + if (tmp_tuple != NULL) >> + dns_difftuple_free(&tmp_tuple); >> + /* re-start the SOA delete-add search cycle */ >> + del_soa = NULL; >> + } else { >> + INSIST("unexpected diff: op != ADD || DEL" >> + == NULL); >> + } >> + } >> + } >> + /* SOA deletions & additions has to create self-contained couples */ >> + INSIST(del_soa == NULL && tmp_tuple == NULL); >> + >> +cleanup: >> + if (tmp_tuple != NULL) >> + dns_difftuple_free(&tmp_tuple); >> + return result; >> +} >> + >> ... > > Sorry for the formatting, obviously my email client is not perfect. > Hope you can understand it... I will fix it before push. Thank you for your time! -- Petr^2 Spacek From pviktori at redhat.com Wed Oct 23 15:35:19 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 23 Oct 2013 17:35:19 +0200 Subject: [Freeipa-devel] [PATCHES] 0289-0294 Fixes in permissions Message-ID: <5267ECB7.2050403@redhat.com> Here are refactorings and fixes for small issues I found so far while working on ticket #3566. Having these already in master should make the final patchset easier to review. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0289.2-Update-Permission-and-ACI-plugins-to-decorator-regis.patch Type: text/x-patch Size: 5661 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0290.2-Fix-indentation-in-permission-plugin-tests.patch Type: text/x-patch Size: 8525 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0291.2-Fix-invalid-assumption-NSS-initialization-check-in-S.patch Type: text/x-patch Size: 1240 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0292.2-Help-plugin-don-t-fail-if-a-topic-s-module-is-not-fo.patch Type: text/x-patch Size: 1651 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0293.2-Use-new-ipaldap-entry-API-in-aci-and-permission-plug.patch Type: text/x-patch Size: 6352 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0294.2-Improve-permission-plugin-test-cleanup.patch Type: text/x-patch Size: 1426 bytes Desc: not available URL: From abokovoy at redhat.com Thu Oct 24 05:01:12 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 24 Oct 2013 08:01:12 +0300 Subject: [Freeipa-devel] Ticket 3994 Message-ID: <20131024050112.GZ25335@redhat.com> Hi! I've committed one-liner fix to #3994, courtesy of Jakub Hrozek, who found that we are using wrong grouping of the filter elements (OR instead of AND) in the filter that defines trusted forest root domains. Due to this bug multiple trusts were not properly shown in CLI. Committed to master, ipa-3-3. https://fedorahosted.org/freeipa/ticket/3994 -- / Alexander Bokovoy -------------- next part -------------- >From 150b84b95494bfbc62555c5d9d094045b4f8d72a Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Wed, 23 Oct 2013 19:39:17 +0200 Subject: [PATCH] trusts: combine filters with AND to make sure only the intended domain matches --- 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 af7bf33a184fb8e138db9dac7e9c860a776f8daf..0d651f8861446cf8d31eb1ea303237bcd2b73201 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -255,7 +255,8 @@ class trust(LDAPObject): trust_type = kwargs.get('trust_type') if trust_type is None: ldap = self.backend - filter = ldap.make_filter({'objectclass': ['ipaNTTrustedDomain'], 'cn': [keys[-1]]}) + filter = ldap.make_filter({'objectclass': ['ipaNTTrustedDomain'], 'cn': [keys[-1]] }, + rules=ldap.MATCH_ALL) filter = ldap.combine_filters((filter, "ipaNTSIDBlacklistIncoming=*"), rules=ldap.MATCH_ALL) try: result = ldap.get_entries(DN(self.container_dn, self.env.basedn), -- 1.8.3.1 From mbasti at redhat.com Thu Oct 24 09:02:04 2013 From: mbasti at redhat.com (Martin Basti) Date: Thu, 24 Oct 2013 11:02:04 +0200 Subject: [Freeipa-devel] [PATCH][DOC] 0018 Chapter 18 Def. Access Control within freeIPA update Message-ID: <1382605324.2282.2.camel@unused-4-145.brq.redhat.com> Patch attached. -- Martin^2 Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0018-Chapter-18-Def.-access-control-within-freeIPA-update.patch Type: text/x-patch Size: 978722 bytes Desc: not available URL: From tbabej at redhat.com Thu Oct 24 10:20:21 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 24 Oct 2013 12:20:21 +0200 Subject: [Freeipa-devel] [PATCH 0121] ipatests: Add support for hosts referenced by a keyword In-Reply-To: <52663AD6.4070308@redhat.com> References: <52662737.7070705@redhat.com> <52662F3F.2050309@redhat.com> <526632A2.4030404@redhat.com> <52663AD6.4070308@redhat.com> Message-ID: <5268F465.7040800@redhat.com> On 10/22/2013 10:44 AM, Petr Viktorin wrote: > On 10/22/2013 10:09 AM, Tomas Babej wrote: >> On 10/22/2013 09:54 AM, Petr Viktorin wrote: >>> On 10/22/2013 09:20 AM, Tomas Babej wrote: >>>> Hi, >>>> >>>> Adds support for host definition by a environment variables of the >>>> following form: >>>> >>>> KEYWORDHOST__envX, where X is the number of the environment >>>> for which host referenced by a keyword should be defined. >>>> >>>> You can also optionally use KEYWORDHOST__IP_envX to define >>>> the IP address directly, otherwise the framework will try to resolve >>>> the hostname. >>>> >>>> Adds a required_keyword_hosts attribute to the IntegrationTest class, >>>> which can test developer use to specify the keyword hosts that this >>>> particular test requires. If not all required keyword hosts are >>>> available, the test will be skipped. >>>> >>>> All keyword hosts are accessible to the IntegrationTests via the >>>> keyword_hosts attribute, which contains a dictionary keyed by the >>>> keywords. >>>> >>> >>> Why is this necessary? >>> What's wrong with just extending the current scheme with more roles? >>> >>> >> >> The need for keyword hosts arised with the implementation of the legacy >> client test suite. >> >> As each of these tests needs a precise type (pre-defined and >> pre-configured) of VM, and not a generic client, you need to restrict >> the test case to specific host type. >> >> One test might be restricted to RHEL 5.10 with nss-pam-ldapd, another to >> FreeBSD, next one to CentOS with nss-pam-ldapd, next to CentOS with old >> version of SSSD... >> >> Each testcase that needs a new type of preconfigured host, we would need >> to introduce a new role, which would need to be integrated in the >> framework. In such implementation, we would lose loose coupling between >> the test framework and the test themselves, and make them less >> pluggable. > > The framework itself (excluding the configuration part) should be able > to handle this nicely using the existing role mechanism. It's true > that in some places it's currently hard-wired to just a few roles, but > supporting completely custom roles shouldn't be a problem. > I'd prefer if this system was used, rather than basically adding a > second role system, which we'd have to support even if we get rid of > the current config part. > > The envvar-based configuration is not as flexible, but I'd rather make > this part somewhat unpleasant than making the framework complex. We > plan to move to a simpler configuration method anyway. > That said, you can basically keep the variable name scheme you use in > this patch; just maybe use TESTHOST rather than KEYWORDHOST. > I rewired the patch to use the current role system. Please look if you have any additional issues. -- 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-0121-2-ipatests-Add-support-for-dynamic-roles-referenced-by.patch Type: text/x-patch Size: 16452 bytes Desc: not available URL: From pviktori at redhat.com Thu Oct 24 11:29:07 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 24 Oct 2013 13:29:07 +0200 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests In-Reply-To: <52666E76.80104@redhat.com> References: <52370B90.2030009@redhat.com> <52381625.3010607@redhat.com> <52386896.3000909@redhat.com> <523B1F0F.3010101@redhat.com> <525C121E.3080406@redhat.com> <525E9825.2070008@redhat.com> <52653F46.7050503@redhat.com> <52663961.3010606@redhat.com> <52665307.3040906@redhat.com> <52666C4B.1040404@redhat.com> <52666E76.80104@redhat.com> Message-ID: <52690483.40206@redhat.com> On 10/22/2013 02:24 PM, Tomas Babej wrote: > On 10/22/2013 02:15 PM, Tomas Babej wrote: >> On 10/22/2013 12:27 PM, Tomas Babej wrote: >>> On 10/22/2013 10:37 AM, Petr Viktorin wrote: >>>> Replying to one part only: >>>> >>>> On 10/21/2013 04:50 PM, Tomas Babej wrote: >>>>> On 10/16/2013 03:44 PM, Petr Viktorin wrote: >>>>>> >>>>>> I still think it would be simpler if IPA and AD domains shared the >>>>>> numbering namespace (users would need to define $AD_env2; if they had >>>>>> $MASTER_env1 and $AD_env1 they would be in the same Domain). >>>>>> >>>>>> But if we use _env1 for both the AD and the IPA domain, they need to >>>>>> be separated in Domain.from_env. With patch 0101 both MASTER_env1 and >>>>>> AD_env1 will be in both domains[0] and ad_domains[0]. >>>>> >>>>> I would rather not join IPA and AD domains as they even cannot be >>>>> in the >>>>> same domain, as the service records would clash. So these will >>>>> always be separate / sub / super domain relationship. >>>> >>>> You're right that they should never share the same domain. But you >>>> should never say never, especially in testing -- what if we'll want >>>> to, in the future, test that the records *do* clash, or that IPA >>>> refuses to install in an AD domain? >>>> >>> >>> You could still set AD_env1 and MASTER_env1 to have the same domain. >>> >>>> Another problem is that they are now separate namespaces. In all >>>> code that deals with domains you have to deal separately with the >>>> list of AD domains and separately with IPA domains. This makes every >>>> piece of code that doesn't care much about what type of domain it's >>>> dealing with (configuration, listing, possible automation scripts >>>> for turning on the VMs, etc.) more complicated. >>>> Also, in this scheme, adding a new type of domain would be quite >>>> hard, especially after more code is written with this split in mind. >>>> >>>> Do keep the domain type, though. tl;dr I'd really prefer "domain 1 >>>> (IPA); domain 2 (AD)" rather than "IPA domain 1; AD domain 1". >>> >>> This will, however, require filtering the domains depending on the >>> fact whether they contain AD or not. If a testcase wants to access an >>> AD domain, it will still need to loop over the list of domains to see >>> which ones are of AD type. >>> >>> Any code that does not care what domain type it's dealing with, can >>> easily access all the domains by chaining the respective iterables. >>> We could have a wrapper in the Config class for that, along the lines >>> of get_all_domains(). >>> >>> So what I see here is that we're trading one complexity over another. >>> >>> I think we can agree on your approach since it hides the complexity >>> from the user, especially in the ipa-test-config, which I admit is >>> getting rather ugly, as we need to introduce new option there and >>> that causes splitting. >>> >>>> >>>> If needed we can have a special check that would reject IPA masters >>>> in AD domains and vice versa, if that really turns out to be necessary. >>>> >>> >>> With this check we should be fine. >>> >>>>> As we already pass ad_domain flag to Domain.from_env, I did >>>>> incorporate >>>>> code that joins the machines to the domain depending on the their >>>>> role. >>>>> Is that a viable solution for you? >>>> >>>> Sorry. I think this design is less sustainable than having a shared >>>> namespace for the domains. >>>> >>>> >>> I'll send revised patchset soon. >>> >>> >> Updated patchset attached. Patch 105: Typo: 'Sets DNS ib given host for trust with the given AD ^^ Should be "in", right? I'll fix it before pushing. Otherwise, these are good to go! Patch 106: In ADTrustBase, it looks like if test_install_adtrust or test_configure_dns_and_time fail, it doesn't make much sense to run the other tests. If that's the case they can go in an install() classmethod. Same with test_establish_trust* in the subclasses. Also, there's a typo in test_estabilish_trusts several times. -----^---- -- Petr? From pviktori at redhat.com Thu Oct 24 13:26:56 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 24 Oct 2013 15:26:56 +0200 Subject: [Freeipa-devel] [PATCHES] 0313-0314 Integration test fixes Message-ID: <52692020.7070104@redhat.com> Here are fixes for two bugs found while running integration tests under Beaker. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0313-Tests-mkdir_recursive-Don-t-fail-when-top-level-dire.patch Type: text/x-patch Size: 1343 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0314-beakerlib-plugin-Don-t-try-to-submit-logs-if-they-ar.patch Type: text/x-patch Size: 897 bytes Desc: not available URL: From pvoborni at redhat.com Thu Oct 24 13:48:14 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 24 Oct 2013 15:48:14 +0200 Subject: [Freeipa-devel] [PATCHES] 0072-0074 Add automember rebuild membership to the web UI In-Reply-To: <525F0736.7080605@redhat.com> References: <5242B235.6020608@redhat.com> <52459883.2070702@redhat.com> <525F0736.7080605@redhat.com> Message-ID: <5269251E.2000709@redhat.com> On 10/16/2013 11:37 PM, Ana Krivokapic wrote: > On 09/27/2013 04:38 PM, Petr Vobornik wrote: >> On 09/25/2013 11:51 AM, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch set addresses ticket >>> https://fedorahosted.org/freeipa/ticket/3928. >>> >>> Patch 0072 hooks the new automember-rebuild command to the web UI >>> (user and host >>> pages). >>> Patch 0073 adds some fixes to the web UI test driver, which are >>> necessary for >>> patch 0074. >>> Patch 0074 adds web UI integration tests for the new feature. >>> >>> The patch set applies on top of my patches 0068-0071 >>> >> >> patch 72: Me, Ana and Kyle discussed position of the actions and the >> decision was to move them to action list. >> >> `ipa automember-rebuild --type=hostgroup` can't be run from UI >> (already discussed with Ana as well) >> >> I'm thinking about adding/creating refresh facet policies for this >> action so that appropriate facet would be marked as dirty and >> therefore refreshed so user would not have click association facet >> refresh button. >> >> patch 73: Looks OK but some changes might not be needed. >> >> patch 74: I would use different methods for certain actions to be >> consistent with other tests and to make the test more robust against >> Web UI refactoring: >> >> 1. >>> self.click_on_link('Refresh') >> >> For buttons in .facet-controls use rather >> `self.facet_button_click('refresh')` where 'refresh' is the button >> name, not text. >> >> 2. >>> self.add_record( >>> 'automember', >>> {'pkey': 'webservers', 'add': [ >>> ('selectbox', 'key', 'fqdn'), >>> ('textbox', 'automemberinclusiveregex', '^web[1-9]+') >>> ]}, >>> facet='hostgrouprule', >>> facet_btn_css_class='widget', >>> navigate=False >>> ) >> >> use `add_table_record('automemberinclusiveregex', data, parent)`. >> Example in test_dns.py:94. >> >> 3. A nitpick(or not even that): When working on one entity, I would >> rather use `navigate_by_breadcrumb('link text') instead of direct >> `navigate_to_record` call which changes url. It resembles user's >> behavior more. But it depends on situation. Ie. when I'm on hostgroup >> page and want to go to host search page, but the last host page was >> some details or association I may just use `navigate_to_entity('host', >> 'search'). Anyway, the important thing is to avoid navigating to the >> same url twice in a row - IE10 does not like that. >> >> 4. Do not use `wait(1)` for AJAX calls. The test will fail if there is >> bigger delay. User rather `wait_for_request(n=X)` where X is number of >> AJAX calls you want to wait for. >> >> 5. Instead of `click_on_link('Rebuild auto membership')` you should >> use `action_panel_action(panel_name, action)` There is also similar >> call for >> executing action list action: `action_list_action(action_name)`. >> >> 6. Nitpick: you can reduce the cleanup code: >>> self.navigate_by_menu('identity/host') >>> self.delete('host', [{'pkey': host1}]) >>> self.delete('host', [{'pkey': host2}]) >> >> Can be written as: >> >> self.delete('host', [{'pkey': host1}, {'pkey': host2}]) >> >> or >> self.navigate_by_menu('identity/host') >> self.delete_record('host', [host1, host2]) >> >> `delete` is basically a shortcut for `navigate_to_entity` and >> `delete_record` with CRUD data format. > > All fixed, new patches attached. > Patch 72: ACK Patch 73: existing UI_driver.select method has the same functionality as new select_option method. Patch 74: ACK -- Petr Vobornik From thozza at redhat.com Thu Oct 24 14:00:07 2013 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 24 Oct 2013 16:00:07 +0200 Subject: [Freeipa-devel] [PATCH 0201] Report error if RFC 4533 initialization failed In-Reply-To: <5267E7CF.2000202@redhat.com> References: <5267E7CF.2000202@redhat.com> Message-ID: <526927E7.9060404@redhat.com> On 10/23/2013 05:14 PM, Petr Spacek wrote: > Hello, > > this patch belongs to 4.0 release. It allows the user to catch some > mis-configurations. > > It produces error messages like this: > LDAP error: Critical extension is unavailable: unable to start SyncRepl > session: is RFC 4533 supported on LDAP server? > ACK. Patch works and looks good. Regards, Tomas Hozza From tbabej at redhat.com Thu Oct 24 14:38:24 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 24 Oct 2013 16:38:24 +0200 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests In-Reply-To: <52690483.40206@redhat.com> References: <52370B90.2030009@redhat.com> <52381625.3010607@redhat.com> <52386896.3000909@redhat.com> <523B1F0F.3010101@redhat.com> <525C121E.3080406@redhat.com> <525E9825.2070008@redhat.com> <52653F46.7050503@redhat.com> <52663961.3010606@redhat.com> <52665307.3040906@redhat.com> <52666C4B.1040404@redhat.com> <52666E76.80104@redhat.com> <52690483.40206@redhat.com> Message-ID: <526930E0.40809@redhat.com> On 10/24/2013 01:29 PM, Petr Viktorin wrote: > On 10/22/2013 02:24 PM, Tomas Babej wrote: >> On 10/22/2013 02:15 PM, Tomas Babej wrote: >>> On 10/22/2013 12:27 PM, Tomas Babej wrote: >>>> On 10/22/2013 10:37 AM, Petr Viktorin wrote: >>>>> Replying to one part only: >>>>> >>>>> On 10/21/2013 04:50 PM, Tomas Babej wrote: >>>>>> On 10/16/2013 03:44 PM, Petr Viktorin wrote: >>>>>>> >>>>>>> I still think it would be simpler if IPA and AD domains shared the >>>>>>> numbering namespace (users would need to define $AD_env2; if >>>>>>> they had >>>>>>> $MASTER_env1 and $AD_env1 they would be in the same Domain). >>>>>>> >>>>>>> But if we use _env1 for both the AD and the IPA domain, they >>>>>>> need to >>>>>>> be separated in Domain.from_env. With patch 0101 both >>>>>>> MASTER_env1 and >>>>>>> AD_env1 will be in both domains[0] and ad_domains[0]. >>>>>> >>>>>> I would rather not join IPA and AD domains as they even cannot be >>>>>> in the >>>>>> same domain, as the service records would clash. So these will >>>>>> always be separate / sub / super domain relationship. >>>>> >>>>> You're right that they should never share the same domain. But you >>>>> should never say never, especially in testing -- what if we'll want >>>>> to, in the future, test that the records *do* clash, or that IPA >>>>> refuses to install in an AD domain? >>>>> >>>> >>>> You could still set AD_env1 and MASTER_env1 to have the same domain. >>>> >>>>> Another problem is that they are now separate namespaces. In all >>>>> code that deals with domains you have to deal separately with the >>>>> list of AD domains and separately with IPA domains. This makes every >>>>> piece of code that doesn't care much about what type of domain it's >>>>> dealing with (configuration, listing, possible automation scripts >>>>> for turning on the VMs, etc.) more complicated. >>>>> Also, in this scheme, adding a new type of domain would be quite >>>>> hard, especially after more code is written with this split in mind. >>>>> >>>>> Do keep the domain type, though. tl;dr I'd really prefer "domain 1 >>>>> (IPA); domain 2 (AD)" rather than "IPA domain 1; AD domain 1". >>>> >>>> This will, however, require filtering the domains depending on the >>>> fact whether they contain AD or not. If a testcase wants to access an >>>> AD domain, it will still need to loop over the list of domains to see >>>> which ones are of AD type. >>>> >>>> Any code that does not care what domain type it's dealing with, can >>>> easily access all the domains by chaining the respective iterables. >>>> We could have a wrapper in the Config class for that, along the lines >>>> of get_all_domains(). >>>> >>>> So what I see here is that we're trading one complexity over another. >>>> >>>> I think we can agree on your approach since it hides the complexity >>>> from the user, especially in the ipa-test-config, which I admit is >>>> getting rather ugly, as we need to introduce new option there and >>>> that causes splitting. >>>> >>>>> >>>>> If needed we can have a special check that would reject IPA masters >>>>> in AD domains and vice versa, if that really turns out to be >>>>> necessary. >>>>> >>>> >>>> With this check we should be fine. >>>> >>>>>> As we already pass ad_domain flag to Domain.from_env, I did >>>>>> incorporate >>>>>> code that joins the machines to the domain depending on the their >>>>>> role. >>>>>> Is that a viable solution for you? >>>>> >>>>> Sorry. I think this design is less sustainable than having a shared >>>>> namespace for the domains. >>>>> >>>>> >>>> I'll send revised patchset soon. >>>> >>>> >>> Updated patchset attached. > > Patch 105: > Typo: 'Sets DNS ib given host for trust with the given AD > ^^ > Should be "in", right? I'll fix it before pushing. c > > Otherwise, these are good to go! > > > Patch 106: > > In ADTrustBase, it looks like if test_install_adtrust or > test_configure_dns_and_time fail, it doesn't make much sense to run > the other tests. > If that's the case they can go in an install() classmethod. Same with > test_establish_trust* in the subclasses. > I made them part of the install() classmethod. As for the test_estabilish_trust, I would have to still override that in each class that uses it, since all of them use it in a slightly different way. > Also, there's a typo in test_estabilish_trusts several times. > -----^---- > Typo fixed. Also attaching a patch that fixes the same type in the other parts of the codebase. -- 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-0122-trusts-Fix-typo-in-error-message-for-realm-domain-mi.patch Type: text/x-patch Size: 1313 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0106-10-ipatests-Add-AD-integration-test-case.patch Type: text/x-patch Size: 7880 bytes Desc: not available URL: From akrivoka at redhat.com Thu Oct 24 15:48:27 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 24 Oct 2013 17:48:27 +0200 Subject: [Freeipa-devel] [PATCH] 0077 Do not roll back failed client installation on server Message-ID: <5269414B.7040001@redhat.com> Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3990 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0077-Do-not-roll-back-failed-client-installation-on-serve.patch Type: text/x-patch Size: 1374 bytes Desc: not available URL: From akrivoka at redhat.com Thu Oct 24 18:39:48 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 24 Oct 2013 20:39:48 +0200 Subject: [Freeipa-devel] [PATCH] 0078 Make sure nsds5ReplicaStripAttrs is set on agreements Message-ID: <52696974.8040305@redhat.com> Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3989 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0078-Make-sure-nsds5ReplicaStripAttrs-is-set-on-agreement.patch Type: text/x-patch Size: 1329 bytes Desc: not available URL: From mkosek at redhat.com Fri Oct 25 08:31:49 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Oct 2013 10:31:49 +0200 Subject: [Freeipa-devel] [PATCH] 433-434 Remove mod_ssl conflict Message-ID: <526A2C75.5070704@redhat.com> Since mod_nss-1.0.8-24, mod_nss and mod_ssl can co-exist on one machine (of course, when listening to different ports). To make sure that mod_ssl is not configured to listen on 443 (default mod_ssl configuration), add a check to the installer checking of either mod_nss or mod_ssl was configured to listen on that port. https://fedorahosted.org/freeipa/ticket/3974 TO TEST: 1. Install newest mod_nss: F19: http://koji.fedoraproject.org/koji/buildinfo?buildID=473624 2. Install patched freeipa 3. Install mod_ssl 4. Update /etc/httpd/conf.d/ssl.conf to not listen on 443, but rather on 10443 or others 5. "setenforce 0" to allow httpd listen on that port 6. ipa-server-install The server should now listen on both 443 with mod_nss and 10443 with mod_ssl. CLI and Web UI should continue to work, as well as cert operations like "cert-show 1" - cert operations would not work if new mod_nss is not updated. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-433-make-set_directive-and-get_directive-more-strict.patch Type: text/x-patch Size: 1594 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-434-remove-mod_ssl-conflict.patch Type: text/x-patch Size: 7334 bytes Desc: not available URL: From pviktori at redhat.com Fri Oct 25 10:33:25 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 25 Oct 2013 12:33:25 +0200 Subject: [Freeipa-devel] [PATCH] 433-434 Remove mod_ssl conflict In-Reply-To: <526A2C75.5070704@redhat.com> References: <526A2C75.5070704@redhat.com> Message-ID: <526A48F5.1060600@redhat.com> On 10/25/2013 10:31 AM, Martin Kosek wrote: > Since mod_nss-1.0.8-24, mod_nss and mod_ssl can co-exist on one > machine (of course, when listening to different ports). > > To make sure that mod_ssl is not configured to listen on 443 > (default mod_ssl configuration), add a check to the installer checking > of either mod_nss or mod_ssl was configured to listen on that port. > > https://fedorahosted.org/freeipa/ticket/3974 > > > > TO TEST: > 1. Install newest mod_nss: > F19: http://koji.fedoraproject.org/koji/buildinfo?buildID=473624 > 2. Install patched freeipa > 3. Install mod_ssl > 4. Update /etc/httpd/conf.d/ssl.conf to not listen on 443, but rather on > 10443 or others > 5. "setenforce 0" to allow httpd listen on that port > 6. ipa-server-install When mod_ssl.rpm is instaled *after* ipa-server-install, no check is done, Apache just fails to start. We need to document this. > The server should now listen on both 443 with mod_nss and 10443 with > mod_ssl. CLI and Web UI should continue to work, as well as cert > operations like "cert-show 1" - cert operations would not work if new > mod_nss is not updated. That is the Apache server, right? IPA is only on 443. > Martin > freeipa-mkosek-433-make-set_directive-and-get_directive-more-strict.patch ACK > freeipa-mkosek-434-remove-mod_ssl-conflict.patch Just a comment on logging: > +def httpd_443_configured(): > + """ > + We now allow mod_ssl to be installed so don't automatically disable it. > + However it can't share the same listen port as mod_nss, so check for that. > + > + Returns True if something other than mod_nss is listening on 443. > + False otherwise. > + """ > + try: > + (stdout, stderr, rc) = ipautil.run(['/usr/sbin/httpd', '-t', '-D', 'DUMP_VHOSTS']) > + except ipautil.CalledProcessError, e: > + print >> sys.stderr, "WARNING: cannot check if port 443 is already configured." > + print >> sys.stderr, "httpd returned error when checking:", str(e) > + return False > + > + port_line_re = re.compile(r'(?P
\S+):(?P\d+)') > + for line in stdout.splitlines(): > + m = port_line_re.match(line) > + if m and int(m.group('port')) == 443: > + print "WARNING: Apache is already configured with a listener on port 443:" > + print line > + return True Please also log these messages, otherwise the log ends up not being very helpful. Since the installation aborts, I think these should be ERROR or CRITICAL, not WARNING. -- Petr? From pviktori at redhat.com Fri Oct 25 11:54:23 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 25 Oct 2013 13:54:23 +0200 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests In-Reply-To: <526930E0.40809@redhat.com> References: <52370B90.2030009@redhat.com> <52381625.3010607@redhat.com> <52386896.3000909@redhat.com> <523B1F0F.3010101@redhat.com> <525C121E.3080406@redhat.com> <525E9825.2070008@redhat.com> <52653F46.7050503@redhat.com> <52663961.3010606@redhat.com> <52665307.3040906@redhat.com> <52666C4B.1040404@redhat.com> <52666E76.80104@redhat.com> <52690483.40206@redhat.com> <526930E0.40809@redhat.com> Message-ID: <526A5BEF.2080201@redhat.com> On 10/24/2013 04:38 PM, Tomas Babej wrote: > On 10/24/2013 01:29 PM, Petr Viktorin wrote: [...] >> >> Patch 106: >> >> In ADTrustBase, it looks like if test_install_adtrust or >> test_configure_dns_and_time fail, it doesn't make much sense to run >> the other tests. >> If that's the case they can go in an install() classmethod. Same with >> test_establish_trust* in the subclasses. >> > I made them part of the install() classmethod. > > As for the test_estabilish_trust, I would have to still override that in > each class that uses it, since all of them use it in a slightly > different way. I'd prefer an "establish_trust" classmethod called from install(), but it's not really important in this case. >> Also, there's a typo in test_estabilish_trusts several times. >> -----^---- >> > > Typo fixed. Also attaching a patch that fixes the same type in the other > parts of the codebase. > ACK, ACK, pushed to master: df5f5c9fab5dd66c50bf202e1ebd19f558e3e0c6 ipa-3-3: 5dbd11722e365f50b7496b4ab2559122cd927d53 Thanks for your patience! -- Petr? From pviktori at redhat.com Fri Oct 25 12:00:53 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 25 Oct 2013 14:00:53 +0200 Subject: [Freeipa-devel] [PATCH] 0077 Do not roll back failed client installation on server In-Reply-To: <5269414B.7040001@redhat.com> References: <5269414B.7040001@redhat.com> Message-ID: <526A5D75.7070701@redhat.com> On 10/24/2013 05:48 PM, Ana Krivokapic wrote: > Hello, > > This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3990 ACK, pushed to: master: c518a80ab7faa8cbb399e3ed32c213ad518d997c ipa-3-3: 24073d22e2e829ccba49e698c45e07b69cf25770 -- Petr? From mkosek at redhat.com Fri Oct 25 12:09:39 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Oct 2013 14:09:39 +0200 Subject: [Freeipa-devel] [PATCH] 433-434 Remove mod_ssl conflict In-Reply-To: <526A48F5.1060600@redhat.com> References: <526A2C75.5070704@redhat.com> <526A48F5.1060600@redhat.com> Message-ID: <526A5F83.6000005@redhat.com> On 10/25/2013 12:33 PM, Petr Viktorin wrote: > On 10/25/2013 10:31 AM, Martin Kosek wrote: >> Since mod_nss-1.0.8-24, mod_nss and mod_ssl can co-exist on one >> machine (of course, when listening to different ports). >> >> To make sure that mod_ssl is not configured to listen on 443 >> (default mod_ssl configuration), add a check to the installer checking >> of either mod_nss or mod_ssl was configured to listen on that port. >> >> https://fedorahosted.org/freeipa/ticket/3974 >> >> >> >> TO TEST: >> 1. Install newest mod_nss: >> F19: http://koji.fedoraproject.org/koji/buildinfo?buildID=473624 >> 2. Install patched freeipa >> 3. Install mod_ssl >> 4. Update /etc/httpd/conf.d/ssl.conf to not listen on 443, but rather on >> 10443 or others >> 5. "setenforce 0" to allow httpd listen on that port >> 6. ipa-server-install > > When mod_ssl.rpm is instaled *after* ipa-server-install, no check is done, > Apache just fails to start. > We need to document this. Document where exactly? Ideas welcome. FreeIPA server uses set of ports, defined in http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/installing-ipa.html#prerequisites When any other service binds to any of these port, some IPA service won't work. Regardless if it is mod_ssl or custom user service. People would probably not read FreeIPA documentation before installing mod_ssl anyway... >> The server should now listen on both 443 with mod_nss and 10443 with >> mod_ssl. CLI and Web UI should continue to work, as well as cert >> operations like "cert-show 1" - cert operations would not work if new >> mod_nss is not updated. > > That is the Apache server, right? IPA is only on 443. Yup. This just refers to testing hints above, where I suggested to configure mod_ssl to listen on some custom port to prove that both mod_ssl and mod_nss can run on the same server. > >> Martin > > > >> freeipa-mkosek-433-make-set_directive-and-get_directive-more-strict.patch > > ACK > >> freeipa-mkosek-434-remove-mod_ssl-conflict.patch > > Just a comment on logging: > >> +def httpd_443_configured(): >> + """ >> + We now allow mod_ssl to be installed so don't automatically disable it. >> + However it can't share the same listen port as mod_nss, so check for that. >> + >> + Returns True if something other than mod_nss is listening on 443. >> + False otherwise. >> + """ >> + try: >> + (stdout, stderr, rc) = ipautil.run(['/usr/sbin/httpd', '-t', '-D', >> 'DUMP_VHOSTS']) >> + except ipautil.CalledProcessError, e: >> + print >> sys.stderr, "WARNING: cannot check if port 443 is already >> configured." >> + print >> sys.stderr, "httpd returned error when checking:", str(e) >> + return False >> + >> + port_line_re = re.compile(r'(?P
\S+):(?P\d+)') >> + for line in stdout.splitlines(): >> + m = port_line_re.match(line) >> + if m and int(m.group('port')) == 443: >> + print "WARNING: Apache is already configured with a listener on >> port 443:" >> + print line >> + return True > > Please also log these messages, otherwise the log ends up not being very helpful. > > Since the installation aborts, I think these should be ERROR or CRITICAL, not > WARNING. Right. I used service.print_msg as you suggested on IRC. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-434-2-remove-mod_ssl-conflict.patch Type: text/x-patch Size: 7329 bytes Desc: not available URL: From mkosek at redhat.com Fri Oct 25 12:59:14 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Oct 2013 14:59:14 +0200 Subject: [Freeipa-devel] [PATCH] 0078 Make sure nsds5ReplicaStripAttrs is set on agreements In-Reply-To: <52696974.8040305@redhat.com> References: <52696974.8040305@redhat.com> Message-ID: <526A6B22.9030509@redhat.com> On 10/24/2013 08:39 PM, Ana Krivokapic wrote: > Hello, > > This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3989 ACK! Tested installation of 3 replicas and then connect operation. nsds5ReplicaStripAttrs was always set correctly. Pushed to master, ipa-3-3. Martin From mkosek at redhat.com Fri Oct 25 13:28:28 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 25 Oct 2013 15:28:28 +0200 Subject: [Freeipa-devel] [PATCH] 435 Do not add kadmin/changepw ACIs on new installs Message-ID: <526A71FC.2010003@redhat.com> These ACI were needed when FreeIPA had a custom ipa_kpasswd daemon, now that a standard kadmin is used, ACIs are not needed anymore as kadmin uses the same driver as the KDC. The ACIs is not removed on upgrades to avoid breaking older replicas which may still use FreeIPA version with the ipa_kpasswd daemon. https://fedorahosted.org/freeipa/ticket/3987 -- Pushed to master, ipa-3-3 as a tested one(two) liner. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-435-do-not-add-kadmin-changepw-acis-on-new-installs.patch Type: text/x-patch Size: 5776 bytes Desc: not available URL: From pviktori at redhat.com Fri Oct 25 13:46:49 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 25 Oct 2013 15:46:49 +0200 Subject: [Freeipa-devel] [PATCH] 433-434 Remove mod_ssl conflict In-Reply-To: <526A5F83.6000005@redhat.com> References: <526A2C75.5070704@redhat.com> <526A48F5.1060600@redhat.com> <526A5F83.6000005@redhat.com> Message-ID: <526A7649.8010702@redhat.com> On 10/25/2013 02:09 PM, Martin Kosek wrote: > On 10/25/2013 12:33 PM, Petr Viktorin wrote: >> On 10/25/2013 10:31 AM, Martin Kosek wrote: >>> Since mod_nss-1.0.8-24, mod_nss and mod_ssl can co-exist on one >>> machine (of course, when listening to different ports). >>> >>> To make sure that mod_ssl is not configured to listen on 443 >>> (default mod_ssl configuration), add a check to the installer checking >>> of either mod_nss or mod_ssl was configured to listen on that port. >>> >>> https://fedorahosted.org/freeipa/ticket/3974 >>> >>> >>> >>> TO TEST: >>> 1. Install newest mod_nss: >>> F19: http://koji.fedoraproject.org/koji/buildinfo?buildID=473624 >>> 2. Install patched freeipa >>> 3. Install mod_ssl >>> 4. Update /etc/httpd/conf.d/ssl.conf to not listen on 443, but rather on >>> 10443 or others >>> 5. "setenforce 0" to allow httpd listen on that port >>> 6. ipa-server-install Okay, I found another problem. After the above steps: - ipa-server-install --uninstall - Uninstall mod_ssl - ipa-server-install >> When mod_ssl.rpm is instaled *after* ipa-server-install, no check is >> done, >> Apache just fails to start. >> We need to document this. > > Document where exactly? Ideas welcome. FreeIPA server uses set of ports, > defined in > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/installing-ipa.html#prerequisites Well, at least in the release notes. The guide you linked to could also have note that this conflicts with the mod_nss defaults. > When any other service binds to any of these port, some IPA service > won't work. Regardless if it is mod_ssl or custom user service. People > would probably not read FreeIPA documentation before installing mod_ssl > anyway... Right. But still, we're removing the Conflicts with a package that will break IPA when installed (even indirectly). We need to be careful here. >>> The server should now listen on both 443 with mod_nss and 10443 with >>> mod_ssl. CLI and Web UI should continue to work, as well as cert >>> operations like "cert-show 1" - cert operations would not work if new >>> mod_nss is not updated. >> >> That is the Apache server, right? IPA is only on 443. > > Yup. This just refers to testing hints above, where I suggested to > configure mod_ssl to listen on some custom port to prove that both > mod_ssl and mod_nss can run on the same server. > >> >>> Martin >> >> >> >>> freeipa-mkosek-433-make-set_directive-and-get_directive-more-strict.patch >>> >> >> ACK >> >>> freeipa-mkosek-434-remove-mod_ssl-conflict.patch >> >> Just a comment on logging: >> [...] >>> + print "WARNING: Apache is already configured with a >>> listener on >>> port 443:" >>> + print line >>> + return True >> >> Please also log these messages, otherwise the log ends up not being >> very helpful. >> >> Since the installation aborts, I think these should be ERROR or >> CRITICAL, not >> WARNING. > > Right. I used service.print_msg as you suggested on IRC. ACK, pushed to: master: 4bed0de60d5bac005c9c54c7376b8dd873d1dd1d (fixed up spec changelog) ipa-3-3: 6d24870c870d0cff0857dd7219d5475854bf8b85 -- Petr? From pviktori at redhat.com Fri Oct 25 14:17:36 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 25 Oct 2013 16:17:36 +0200 Subject: [Freeipa-devel] [PATCH] 433-434 Remove mod_ssl conflict In-Reply-To: <526A7649.8010702@redhat.com> References: <526A2C75.5070704@redhat.com> <526A48F5.1060600@redhat.com> <526A5F83.6000005@redhat.com> <526A7649.8010702@redhat.com> Message-ID: <526A7D80.1010104@redhat.com> On 10/25/2013 03:46 PM, Petr Viktorin wrote: > On 10/25/2013 02:09 PM, Martin Kosek wrote: >> On 10/25/2013 12:33 PM, Petr Viktorin wrote: >>> On 10/25/2013 10:31 AM, Martin Kosek wrote: >>>> Since mod_nss-1.0.8-24, mod_nss and mod_ssl can co-exist on one >>>> machine (of course, when listening to different ports). >>>> >>>> To make sure that mod_ssl is not configured to listen on 443 >>>> (default mod_ssl configuration), add a check to the installer checking >>>> of either mod_nss or mod_ssl was configured to listen on that port. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3974 >>>> [...] >> >> Right. I used service.print_msg as you suggested on IRC. > > ACK, pushed to: > master: 4bed0de60d5bac005c9c54c7376b8dd873d1dd1d (fixed up spec changelog) > ipa-3-3: 6d24870c870d0cff0857dd7219d5475854bf8b85 Jenkins found one more issue: wrong date(s) in the changelog(s). Pushed as one-liner to master: 88154b5709a898b94aa0338f16af67b37c9a95ff and two-liner to ipa-3-3: c8a4f041ced515cf164003534a07aa675d0f323a -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0315-Fix-date-in-last-changelog-entry.patch Type: text/x-patch Size: 798 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa3.3-pviktori-0315-freeipa.spec-Fix-changelog-dates.patch Type: text/x-patch Size: 1088 bytes Desc: not available URL: From jfenal at gmail.com Fri Oct 25 14:48:16 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Fri, 25 Oct 2013 16:48:16 +0200 Subject: [Freeipa-devel] Daily build of the documentation? Message-ID: 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. -- J?r?me Fenal From pviktori at redhat.com Fri Oct 25 15:00:50 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 25 Oct 2013 17:00:50 +0200 Subject: [Freeipa-devel] [PATCH] 0076 Add test for external CA installation In-Reply-To: <5266C0BE.2000504@redhat.com> References: <5266C0BE.2000504@redhat.com> Message-ID: <526A87A2.5030901@redhat.com> On 10/22/2013 08:15 PM, Ana Krivokapic wrote: > Hello, > > This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3819 > ACK, thanks! Do we want to push this to 3.3 as well? It's a stand-alone test module; unless it's called it's as if it wasn't there. (Assuming no one runs *all* integration tests at once; I don't think anyone does) -- Petr? From akrivoka at redhat.com Fri Oct 25 15:03:04 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 25 Oct 2013 17:03:04 +0200 Subject: [Freeipa-devel] [PATCH] 0079 Enable Retro Changelog and Content Synchronization DS plugins Message-ID: <526A8828.3010807@redhat.com> Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3967. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0079-Enable-Retro-Changelog-and-Content-Synchronization-D.patch Type: text/x-patch Size: 2936 bytes Desc: not available URL: From mbasti at redhat.com Fri Oct 25 15:13:41 2013 From: mbasti at redhat.com (Martin Basti) Date: Fri, 25 Oct 2013 17:13:41 +0200 Subject: [Freeipa-devel] Daily build of the documentation? In-Reply-To: References: Message-ID: <1382714021.2282.5.camel@unused-4-145.brq.redhat.com> 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 . -- Martin^2 Basti From jfenal at gmail.com Fri Oct 25 15:22:15 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Fri, 25 Oct 2013 17:22:15 +0200 Subject: [Freeipa-devel] Daily build of the documentation? In-Reply-To: <1382714021.2282.5.camel@unused-4-145.brq.redhat.com> References: <1382714021.2282.5.camel@unused-4-145.brq.redhat.com> Message-ID: 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. -- J?r?me Fenal From abokovoy at redhat.com Mon Oct 28 11:10:04 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 28 Oct 2013 13:10:04 +0200 Subject: [Freeipa-devel] [PATCH] Split out function In-Reply-To: <1381504446.2684.86.camel@willson.li.ssimo.org> References: <1381504446.2684.86.camel@willson.li.ssimo.org> Message-ID: <20131028111004.GB25335@redhat.com> On Fri, 11 Oct 2013, Simo Sorce wrote: >During the Kerberos interop we found out we are still missing to >generate a Ms-PAc field the MS testsuite wants to see. > >I did some work in the past to create the UPN_DNS_INFO buffer in the >samba IDL files but it has been recently reverted upstream due to some >issues it created for Samba4 and is being reworked by G?nther and Metze. > >However I still went ahead and created a prototype patch that would use >the new union buffer once it is released. > >In doing that I realize recent changes made it difficult to add the >buffer so I created a patch that splits out some checks. > >I would like to push patch 0001, so that in the future we will also be >able to push patch 0002, however 0002 cannot be pushed now as we miss >the necessary code in the samba packages. So 0002 is added here only for >reference to understand why I coded 0001 the way I did. NACK for patch 0001 I'm getting crash when DNS driver attempts to obtain TGT for DNS/hostname for own operations shortly after ipa-server-install configures DNS server to use Kerberos. As result, whole ipa-server-install fails to complete because ipa-client-install is unable to obtain admin's ticket. I think we miss some check for empty PAC somewhere. Program received signal SIGSEGV, Segmentation fault. _wordcopy_bwd_aligned (dstp=140688504844288, srcp=140688504844264, len=2305843009213619456) at wordcopy.c:306 306 a1 = ((op_t *) srcp)[2]; (gdb) bt full #0 _wordcopy_bwd_aligned (dstp=140688504844288, srcp=140688504844264, len=2305843009213619456) at wordcopy.c:306 a0 = 0 a1 = #1 0x00007ff4948b41e5 in __memmove_sse2 (dest=0x7ff498640838, src=, len=18446744073709550664) at ../string/memmove.c:105 dstp = srcp = #2 0x00007ff495cd4041 in memmove (__len=, __src=, __dest=) at /usr/include/bits/string3.h:57 No locals. #3 k5_pac_add_buffer (context=context at entry=0x7ff4985f4b80, pac=pac at entry=0x7ff498640470, type=type at entry=10, data=data at entry=0x7fffc0736930, zerofill=zerofill at entry=1, out_data=out_data at entry=0x7fffc0736930) at pac.c:79 header = header_len = i = pad = 4 pac_data = __PRETTY_FUNCTION__ = "k5_pac_add_buffer" #4 0x00007ff495cd536f in k5_insert_client_info (principal=0x0, authtime=1382956873, pac=0x7ff498640470, context=0x7ff4985f4b80) at pac_sign.c:66 ret = 0 client_info = {magic = 3, length = 20, data = 0x0} princ_name_utf8 = 0x7ff498640160 "olicyaux!" princ_name_ucs2 = 0x7ff4986401d0 "" p = princ_name_ucs2_len = 10 nt_authtime = 140688505441072 #5 krb5_pac_sign (context=context at entry=0x7ff4985f4b80, pac=pac at entry=0x7ff498640470, authtime=authtime at entry=1382956873, principal=principal at entry=0x7ff49863f760, server_key=server_key at entry=0x7ff49863f860, privsvr_key=privsvr_key at entry=0x7ff49863f860, data=data at entry=0x7fffc0736b20) at pac_sign.c:196 ret = server_cksum = {magic = -1738274000, length = 32756, data = 0x7e30eef8dd79dd00
} privsvr_cksum = {magic = 3, length = 20, data = 0x0} server_cksumtype = -1738276400 privsvr_cksumtype = 10 iov = {{flags = 128, data = {magic = -1738531088, length = 32756, data = 0x19781a78c9096184
}}, { flags = -1916284466, data = {magic = -453314037, length = 3105196167, data = 0x7fffc0736aae "\001"}}} __PRETTY_FUNCTION__ = "krb5_pac_sign" #6 0x00007ff48dc7e107 in ipadb_sign_pac (server=, krbtgt=, pac_data=0x7fffc0736b20, pac=0x7ff498640470, authtime=1382956873, krbtgt_key=0x7ff49863f860, server_key=0x7ff49863f860, client_princ=0x7ff49863f760, context=0x7ff4985f4b80) at ipa_kdb_mspac.c:1868 kerr = right_krbtgt_signing_key = 0x7ff49863f860 right_krbtgt_key = 0x7e30eef8dd79dd00 right_krbtgt = 0x0 krbtgt_princ = 0x0 princ = 0x0 #7 ipadb_sign_authdata (context=, flags=, client_princ=, client=, server=, krbtgt=, client_key=0x7ff49863f878, server_key=0x7ff49863f860, krbtgt_key=0x7ff49863f860, session_key=0x7ff49863f940, authtime=1382956873, tgt_auth_data=0x0, signed_auth_data=0x7fffc0736ce0) at ipa_kdb_mspac.c:2113 ks_client_princ = pac_auth_data = 0x0 authdata = {0x0, 0x0} ad = {magic = 0, ad_type = 0, length = 0, contents = 0x6e0000005b
} is_as_req = kerr = pac = 0x7ff498640470 pac_data = {magic = 48, length = 0, data = 0x0} ipactx = with_pac = true with_pad = false result = -1066177793 #8 0x00007ff4963cc7ae in krb5_db_sign_authdata (kcontext=kcontext at entry=0x7ff4985f4b80, flags=96, client_princ=0x7ff49863f760, client=0x7ff49863fb80, server=0x7ff49863ff80, krbtgt=0x7ff49863ff80, client_key=0x7ff49863f878, server_key=server_key at entry=0x7ff49863f860, krbtgt_key=krbtgt_key at entry=0x7ff49863f860, session_key=0x7ff49863f940, authtime=authtime at entry=1382956873, tgt_auth_data=tgt_auth_data at entry=0x0, signed_auth_data=signed_auth_data at entry=0x7fffc0736ce0) at kdb5.c:2522 status = v = 0x7ff4985f51c0 #9 0x00007ff496a36c4b in handle_kdb_authdata (context=0x7ff4985f4b80, flags=, client=, server=, krbtgt=, client_key=, server_key=0x7ff49863f860, krbtgt_key=0x7ff49863f860, req_pkt=0x7ff49862f2e0, request=0x7ff49863f470, for_user_princ=0x0, enc_tkt_request=0x0, enc_tkt_reply=0x7ff49863f788) at kdc_authdata.c:717 code = tgt_authdata = 0x0 -- / Alexander Bokovoy From mkosek at redhat.com Tue Oct 29 07:26:34 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 29 Oct 2013 08:26:34 +0100 Subject: [Freeipa-devel] [PATCH] 0076 Add test for external CA installation In-Reply-To: <526A87A2.5030901@redhat.com> References: <5266C0BE.2000504@redhat.com> <526A87A2.5030901@redhat.com> Message-ID: <526F632A.4070602@redhat.com> On 10/25/2013 05:00 PM, Petr Viktorin wrote: > On 10/22/2013 08:15 PM, Ana Krivokapic wrote: >> Hello, >> >> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3819 >> > > ACK, thanks! > > > Do we want to push this to 3.3 as well? It's a stand-alone test module; unless > it's called it's as if it wasn't there. > > (Assuming no one runs *all* integration tests at once; I don't think anyone does) Makes sense. Pushed to ipa-3-3. Martin From mkosek at redhat.com Tue Oct 29 07:29:10 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 29 Oct 2013 08:29:10 +0100 Subject: [Freeipa-devel] [PATCH] 0076 Add test for external CA installation In-Reply-To: <526A87A2.5030901@redhat.com> References: <5266C0BE.2000504@redhat.com> <526A87A2.5030901@redhat.com> Message-ID: <526F63C6.5040003@redhat.com> On 10/25/2013 05:00 PM, Petr Viktorin wrote: > On 10/22/2013 08:15 PM, Ana Krivokapic wrote: >> Hello, >> >> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3819 >> > > ACK, thanks! > > > Do we want to push this to 3.3 as well? It's a stand-alone test module; unless > it's called it's as if it wasn't there. > > (Assuming no one runs *all* integration tests at once; I don't think anyone does) Makes sense. Pushed to master, ipa-3-3. Martin From pspacek at redhat.com Tue Oct 29 10:40:16 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 29 Oct 2013 11:40:16 +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: <526F9090.2030503@redhat.com> On 25.10.2013 17:22, 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. I think that nightly build with "Draft" stamp is a good idea! Martin^1, is it possible to create an 'machine account' with FTP/git access to some part of freeipa.org? We can run publican from cron and push results to freeipa.org. -- Petr^2 Spacek From akrivoka at redhat.com Tue Oct 29 09:49:30 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 29 Oct 2013 10:49:30 +0100 Subject: [Freeipa-devel] [PATCHES] 0080-0081 Add userClass attributes for users and hosts Message-ID: <526F84AA.3090004@redhat.com> Hello, Patch 0080 adds userClass attribute for users to IPA CLI. Patch 0081 adds userClass attribute for users and hosts to the web UI. Design page: http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems Tickets: https://fedorahosted.org/freeipa/ticket/3588 https://fedorahosted.org/freeipa/ticket/3590 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0080-Add-userClass-attribute-for-users.patch Type: text/x-patch Size: 10603 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0081-WebUI-Add-userClass-attribute-to-user-and-host-pages.patch Type: text/x-patch Size: 1605 bytes Desc: not available URL: From mkosek at redhat.com Tue Oct 29 10:03:21 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 29 Oct 2013 11:03:21 +0100 Subject: [Freeipa-devel] Daily build of the documentation? In-Reply-To: <526F9090.2030503@redhat.com> References: <1382714021.2282.5.camel@unused-4-145.brq.redhat.com> <526F9090.2030503@redhat.com> Message-ID: <526F87E9.6090109@redhat.com> On 10/29/2013 11:40 AM, Petr Spacek wrote: > On 25.10.2013 17:22, 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. > > I think that nightly build with "Draft" stamp is a good idea! > > Martin^1, is it possible to create an 'machine account' with FTP/git access to > some part of freeipa.org? We can run publican from cron and push results to > freeipa.org. > We planned to do exactly this. The problem here is, that in order to the script be able to upload the data, I would need to add it's public key to our FreeIPA.org app and I cannot limit it just to the user guide directory, but it would then have access to the entire wiki gear, write access to git and everything... So question is, if we want to add such access to a public VM in Jenkins or we want to keep it secure in... hm... my notebook. Martin From pvoborni at redhat.com Tue Oct 29 10:09:21 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 29 Oct 2013 11:09:21 +0100 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <1380917810.1760.23.camel@localhost> References: <1380917810.1760.23.camel@localhost> Message-ID: <526F8951.7030007@redhat.com> On 10/04/2013 10:16 PM, Nathaniel McCallum wrote: > This patch supersedes my patch 0017 and requires patches 0020-0023. I > believe I have solved all of the outstanding issues from the review of > patch 0017, unless otherwise noted: > > 1. I'm not actually sure what the format of the date parameters is. > Could someone clarify this for me? Should I do something differently > here? I think that date parameter is not used anywhere. IMO it should be designed soon since it will be needed in other tickets [1], [2] as well. [1] https://fedorahosted.org/freeipa/ticket/547 [RFE] Implement iCal based time managment in HBAC [2] https://fedorahosted.org/freeipa/ticket/3127 [RFE] Time-Based Account Lockout Policies in IPA > > 2. In this new version of the patch, we are writing default values for > many of the token attributes. It would be nice to have some global > defaults for these default values, but this is not currently > implemented. I think this would make a clean secondary patch on top of > this current patch. > > 3. Dmitri brought up the idea of having tokens automatically expire by > default. Is this a good idea? I think this dovetails nicely with #2 > above. > > 4. This patch does not currently protect the deletion of the last token > as previously discussed. Here is why I think this is still needed, but > in the form of a DS plugin: > > We need to account for a state when the user is enabled for OTP but has > not yet configured any tokens. I believe this state should be when the > "otp" user auth type is set, but the user has no assigned tokens. In > this state, the user should be able to log in with single factor > authentication. > > Once the user has added tokens, however, should we allow the user to > remove all his own tokens and return to single factor authentication? If > yes, nothing further is needed. If no, then protection in the FreeIPA > framework is not sufficient and this needs to be checked at the DS > plugin level. I suspect Dmitri might answer that this needs to be a > matter of policy. > > 5. There appears to be some sort of permissions issue with users and > adding their own tokens. I have not looked into this yet, but I will > review this early next week. Since this is a small bug fix to an > existing feature, I figured it was out of scope for this patch. > > 6. When a user is deleted, all his tokens are deleted as well. This is > sensible default behavior. However, in the case of hardware tokens, it > may be more desirable to orphan these objects for future assignment to > new users. Does anyone have any opinions on this topic? > > Nathaniel > -- Petr Vobornik From akrivoka at redhat.com Tue Oct 29 11:30:44 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 29 Oct 2013 12:30:44 +0100 Subject: [Freeipa-devel] [PATCHES] 0068-0070 Automember rebuild membership In-Reply-To: <525D68BF.9050901@redhat.com> References: <523AFC1E.4080005@redhat.com> <52407D33.6000009@redhat.com> <52458177.30301@redhat.com> <52458455.6040403@redhat.com> <52493029.7060501@redhat.com> <525D68BF.9050901@redhat.com> Message-ID: <526F9C64.5000301@redhat.com> On 10/15/2013 06:09 PM, Ana Krivokapic wrote: > On 09/30/2013 10:02 AM, Petr Viktorin wrote: >> On 09/27/2013 03:12 PM, Martin Kosek wrote: >>> On 09/27/2013 03:00 PM, Jan Cholasta wrote: >>>> On 23.9.2013 19:41, Ana Krivokapic wrote: >>>>> On 09/19/2013 03:29 PM, Ana Krivokapic wrote: >>> ... >>>> Patch 69: >>>> >>>> I think the changes in the update file should be also done in the >>>> right LDIF >>>> files in install/share, though I don't know what is the recent >>>> consensus on this. >>>> >>>> >>>> Honza >>>> >>> Last time I checked, we used to do the change both in LDIF and update >>> file. Just to avoid the LDIF become obsolete. >>> >>> Martin >> Rob recently said his preference is to move everything from LDIF to updates, >> and out of the the LDIF files: >> http://www.redhat.com/archives/freeipa-devel/2013-September/msg00106.html >> >> I would agree, having two places with the same information is redundant and >> error-prone. >> > Thanks Honza for the review. > > I incorporated your suggestions in this updated patchset. I attached all the > patches for more convenient reviewing, but only patches 68 and 70 have changed. > > I haven't done any changes in the LDIF files since the consensus seems to be not > to do that. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Patch 70 needed a rebase, attaching the whole patchset again. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0070-04-Add-unit-tests-for-automember-rebuild-command.patch Type: text/x-patch Size: 21152 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0071-Fix-error-message-when-adding-duplicate-automember-r.patch Type: text/x-patch Size: 3819 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0069-02-Add-permissions-for-automember-rebuild-command.patch Type: text/x-patch Size: 2389 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0068-03-Add-automember-rebuild-command.patch Type: text/x-patch Size: 7090 bytes Desc: not available URL: From akrivoka at redhat.com Tue Oct 29 11:33:08 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 29 Oct 2013 12:33:08 +0100 Subject: [Freeipa-devel] [PATCHES] 0072-0074 Add automember rebuild membership to the web UI In-Reply-To: <5269251E.2000709@redhat.com> References: <5242B235.6020608@redhat.com> <52459883.2070702@redhat.com> <525F0736.7080605@redhat.com> <5269251E.2000709@redhat.com> Message-ID: <526F9CF4.5090406@redhat.com> On 10/24/2013 03:48 PM, Petr Vobornik wrote: > On 10/16/2013 11:37 PM, Ana Krivokapic wrote: >> On 09/27/2013 04:38 PM, Petr Vobornik wrote: >>> On 09/25/2013 11:51 AM, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> This patch set addresses ticket >>>> https://fedorahosted.org/freeipa/ticket/3928. >>>> >>>> Patch 0072 hooks the new automember-rebuild command to the web UI >>>> (user and host >>>> pages). >>>> Patch 0073 adds some fixes to the web UI test driver, which are >>>> necessary for >>>> patch 0074. >>>> Patch 0074 adds web UI integration tests for the new feature. >>>> >>>> The patch set applies on top of my patches 0068-0071 >>>> >>> >>> patch 72: Me, Ana and Kyle discussed position of the actions and the >>> decision was to move them to action list. >>> >>> `ipa automember-rebuild --type=hostgroup` can't be run from UI >>> (already discussed with Ana as well) >>> >>> I'm thinking about adding/creating refresh facet policies for this >>> action so that appropriate facet would be marked as dirty and >>> therefore refreshed so user would not have click association facet >>> refresh button. >>> >>> patch 73: Looks OK but some changes might not be needed. >>> >>> patch 74: I would use different methods for certain actions to be >>> consistent with other tests and to make the test more robust against >>> Web UI refactoring: >>> >>> 1. >>>> self.click_on_link('Refresh') >>> >>> For buttons in .facet-controls use rather >>> `self.facet_button_click('refresh')` where 'refresh' is the button >>> name, not text. >>> >>> 2. >>>> self.add_record( >>>> 'automember', >>>> {'pkey': 'webservers', 'add': [ >>>> ('selectbox', 'key', 'fqdn'), >>>> ('textbox', 'automemberinclusiveregex', '^web[1-9]+') >>>> ]}, >>>> facet='hostgrouprule', >>>> facet_btn_css_class='widget', >>>> navigate=False >>>> ) >>> >>> use `add_table_record('automemberinclusiveregex', data, parent)`. >>> Example in test_dns.py:94. >>> >>> 3. A nitpick(or not even that): When working on one entity, I would >>> rather use `navigate_by_breadcrumb('link text') instead of direct >>> `navigate_to_record` call which changes url. It resembles user's >>> behavior more. But it depends on situation. Ie. when I'm on hostgroup >>> page and want to go to host search page, but the last host page was >>> some details or association I may just use `navigate_to_entity('host', >>> 'search'). Anyway, the important thing is to avoid navigating to the >>> same url twice in a row - IE10 does not like that. >>> >>> 4. Do not use `wait(1)` for AJAX calls. The test will fail if there is >>> bigger delay. User rather `wait_for_request(n=X)` where X is number of >>> AJAX calls you want to wait for. >>> >>> 5. Instead of `click_on_link('Rebuild auto membership')` you should >>> use `action_panel_action(panel_name, action)` There is also similar >>> call for >>> executing action list action: `action_list_action(action_name)`. >>> >>> 6. Nitpick: you can reduce the cleanup code: >>>> self.navigate_by_menu('identity/host') >>>> self.delete('host', [{'pkey': host1}]) >>>> self.delete('host', [{'pkey': host2}]) >>> >>> Can be written as: >>> >>> self.delete('host', [{'pkey': host1}, {'pkey': host2}]) >>> >>> or >>> self.navigate_by_menu('identity/host') >>> self.delete_record('host', [host1, host2]) >>> >>> `delete` is basically a shortcut for `navigate_to_entity` and >>> `delete_record` with CRUD data format. >> >> All fixed, new patches attached. >> > > Patch 72: ACK > > Patch 73: existing UI_driver.select method has the same functionality as new > select_option method. > > Patch 74: ACK Oops, I missed the existing select() method. Thanks for poining it out. Updated patch 73 drops the unnecessary select_option() and uses existing select(). -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0073-03-Web-UI-integration-test-driver-enhancements.patch Type: text/x-patch Size: 1148 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0074-02-Add-web-UI-integration-tests-for-automember-rebuild.patch Type: text/x-patch Size: 7746 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0072-02-Add-automember-rebuild-command-to-the-web-UI.patch Type: text/x-patch Size: 8465 bytes Desc: not available URL: From mkosek at redhat.com Tue Oct 29 11:42:15 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 29 Oct 2013 12:42:15 +0100 Subject: [Freeipa-devel] [PATCHES] 0080-0081 Add userClass attributes for users and hosts In-Reply-To: <526F84AA.3090004@redhat.com> References: <526F84AA.3090004@redhat.com> Message-ID: <526F9F17.6090702@redhat.com> On 10/29/2013 10:49 AM, Ana Krivokapic wrote: > Hello, > > Patch 0080 adds userClass attribute for users to IPA CLI. > Patch 0081 adds userClass attribute for users and hosts to the web UI. > > Design page: > http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems > > Tickets: > https://fedorahosted.org/freeipa/ticket/3588 > https://fedorahosted.org/freeipa/ticket/3590 NACK to just extending posixAccount objectclass. This is a standard objectclass defined by RFC 2307 and we cannot just simply extend and overwrite it as we wish. We will need to come up with some custom objectclass, like ipaUser. This is the reason why I wrote to ticket "A second goal of this ticket is to review current objectClass hierarchy of users and do changes if needed." so that we can pick the best option where to place it. Martin From mkosek at redhat.com Tue Oct 29 11:46:08 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 29 Oct 2013 12:46:08 +0100 Subject: [Freeipa-devel] [PATCH] 0079 Enable Retro Changelog and Content Synchronization DS plugins In-Reply-To: <526A8828.3010807@redhat.com> References: <526A8828.3010807@redhat.com> Message-ID: <526FA000.7000806@redhat.com> On 10/25/2013 05:03 PM, Ana Krivokapic wrote: > Hello, > > This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3967. > NACK. I do not think this will work well with the case when DNS is not used. As bind-dyndb-ldap is not required component, FreeIPA could be installed on a machine without bind installed. And in that case, /var/named/ won't be there. I think that this directory will follow similar pattern as %{_localstatedir}/lib/ipa/pki-ca/publish and be just %ghost and be created in when bind-dyndb-ldap is being configured in bindinstance.py. Martin From pviktori at redhat.com Tue Oct 29 12:00:46 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 29 Oct 2013 13:00:46 +0100 Subject: [Freeipa-devel] [PATCH 0121] ipatests: Add support for hosts referenced by a keyword In-Reply-To: <5268F465.7040800@redhat.com> References: <52662737.7070705@redhat.com> <52662F3F.2050309@redhat.com> <526632A2.4030404@redhat.com> <52663AD6.4070308@redhat.com> <5268F465.7040800@redhat.com> Message-ID: <526FA36E.3070000@redhat.com> On 10/24/2013 12:20 PM, Tomas Babej wrote: > On 10/22/2013 10:44 AM, Petr Viktorin wrote: >> On 10/22/2013 10:09 AM, Tomas Babej wrote: >>> On 10/22/2013 09:54 AM, Petr Viktorin wrote: >>>> On 10/22/2013 09:20 AM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> Adds support for host definition by a environment variables of the >>>>> following form: >>>>> >>>>> KEYWORDHOST__envX, where X is the number of the environment >>>>> for which host referenced by a keyword should be defined. >>>>> >>>>> You can also optionally use KEYWORDHOST__IP_envX to define >>>>> the IP address directly, otherwise the framework will try to resolve >>>>> the hostname. >>>>> >>>>> Adds a required_keyword_hosts attribute to the IntegrationTest class, >>>>> which can test developer use to specify the keyword hosts that this >>>>> particular test requires. If not all required keyword hosts are >>>>> available, the test will be skipped. >>>>> >>>>> All keyword hosts are accessible to the IntegrationTests via the >>>>> keyword_hosts attribute, which contains a dictionary keyed by the >>>>> keywords. >>>>> >>>> >>>> Why is this necessary? >>>> What's wrong with just extending the current scheme with more roles? >>>> >>>> >>> >>> The need for keyword hosts arised with the implementation of the legacy >>> client test suite. >>> >>> As each of these tests needs a precise type (pre-defined and >>> pre-configured) of VM, and not a generic client, you need to restrict >>> the test case to specific host type. >>> >>> One test might be restricted to RHEL 5.10 with nss-pam-ldapd, another to >>> FreeBSD, next one to CentOS with nss-pam-ldapd, next to CentOS with old >>> version of SSSD... >>> >>> Each testcase that needs a new type of preconfigured host, we would need >>> to introduce a new role, which would need to be integrated in the >>> framework. In such implementation, we would lose loose coupling between >>> the test framework and the test themselves, and make them less >>> pluggable. >> >> The framework itself (excluding the configuration part) should be able >> to handle this nicely using the existing role mechanism. It's true >> that in some places it's currently hard-wired to just a few roles, but >> supporting completely custom roles shouldn't be a problem. >> I'd prefer if this system was used, rather than basically adding a >> second role system, which we'd have to support even if we get rid of >> the current config part. >> >> The envvar-based configuration is not as flexible, but I'd rather make >> this part somewhat unpleasant than making the framework complex. We >> plan to move to a simpler configuration method anyway. >> That said, you can basically keep the variable name scheme you use in >> this patch; just maybe use TESTHOST rather than KEYWORDHOST. >> > > I rewired the patch to use the current role system. > > Please look if you have any additional issues. > I only have two naming nitpicks. - The roles aren't really "dynamic"; eventually all the "dynamicness" should be specific just to the envvar configuration system, and a few shortcuts like `replicas` for `host_by_role('replica')`. I think "extra" would be a better term. - The environment variable names could be more descriptive. They store a hostname, not a role, so instead of $ROLE__envX I'd prefer $TESTHOST__envX Other than that the changes look great! -- Petr? From pvoborni at redhat.com Tue Oct 29 12:04:24 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 29 Oct 2013 13:04:24 +0100 Subject: [Freeipa-devel] [PATCHES] 0080-0081 Add userClass attributes for users and hosts In-Reply-To: <526F84AA.3090004@redhat.com> References: <526F84AA.3090004@redhat.com> Message-ID: <526FA448.5030205@redhat.com> On 10/29/2013 10:49 AM, Ana Krivokapic wrote: > Hello, > > Patch 0080 adds userClass attribute for users to IPA CLI. > Patch 0081 adds userClass attribute for users and hosts to the web UI. > > Design page: > http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems > > Tickets: > https://fedorahosted.org/freeipa/ticket/3588 > https://fedorahosted.org/freeipa/ticket/3590 > In addition to the posixAccount issue: 1. I think we should also add a field to host and user adder dialogs. This feature was designed to work with automember plugin. Without it in adder dialog, user would have to modify the entry and then run automember-rebuild. That said, I understand that we may decide not to include it in adder dialogs if we say that this feature is only for provisioning systems, which don't use Web UI. -- Petr Vobornik From pviktori at redhat.com Tue Oct 29 12:07:09 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 29 Oct 2013 13:07:09 +0100 Subject: [Freeipa-devel] [PATCHES] 0080-0081 Add userClass attributes for users and hosts In-Reply-To: <526F84AA.3090004@redhat.com> References: <526F84AA.3090004@redhat.com> Message-ID: <526FA4ED.2060100@redhat.com> On 10/29/2013 10:49 AM, Ana Krivokapic wrote: > Hello, > > Patch 0080 adds userClass attribute for users to IPA CLI. > Patch 0081 adds userClass attribute for users and hosts to the web UI. > > Design page: > http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems > > Tickets: > https://fedorahosted.org/freeipa/ticket/3588 > https://fedorahosted.org/freeipa/ticket/3590 And another comment: please also add any schema changes to the .ldif files. For "content" we're moving to use update files only, but for schema we're moving the other way, to ldif only. See https://fedorahosted.org/freeipa/ticket/3454 -- Petr? From jcholast at redhat.com Tue Oct 29 12:34:26 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 29 Oct 2013 13:34:26 +0100 Subject: [Freeipa-devel] [PATCHES] 106-113 Access raw LDAP values directly from LDAPEntry In-Reply-To: <525EBB0D.9040003@redhat.com> References: <512E26E1.5010302@redhat.com> <52419527.70200@redhat.com> <524426F5.6010006@redhat.com> <525544A3.6080807@redhat.com> <52565B09.2090909@redhat.com> <525BB27C.1000507@redhat.com> <525EBB0D.9040003@redhat.com> Message-ID: <526FAB52.5080300@redhat.com> On 16.10.2013 18:13, Petr Viktorin wrote: > On 10/14/2013 10:59 AM, Jan Cholasta wrote: >> On 10.10.2013 09:45, Jan Cholasta wrote: >>> On 9.10.2013 13:57, Petr Viktorin wrote: >>>> On 09/26/2013 02:22 PM, Jan Cholasta wrote: >>>>> On 24.9.2013 15:35, Jan Cholasta wrote: >>>>>> On 27.2.2013 16:31, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> these patches add the ability to access and manipulate raw attribute >>>>>>> values as they are returned from python-ldap to the LDAPEntry class. >>>>>>> This is useful for comparing entries, computing modlists for the >>>>>>> modify >>>>>>> operation, deleting values that don't match the syntax of an >>>>>>> attribute, >>>>>>> etc., because we don't need to care what syntax does a particular >>>>>>> attribute use, or what Python type is used for it in the framework >>>>>>> (raw >>>>>>> values are always list of str). It should also make interaction with >>>>>>> non-389 DS LDAP servers easier in the framework. >>>>>>> >>>>>>> (It might be too late for this kind of changes to get into 3.2 now, >>>>>>> I'm >>>>>>> posting these patches mainly so that you are aware that they exist.) >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> This is now planned for 3.4: >>>>>> >>>>>> >>>>>> I fixed some issues in these patches and refined the API. Updated >>>>>> patches attached. >>>>>> >>>>>> Also added a patch to use raw values when adding new entries and a >>>>>> patch >>>>>> which refines LDAPEntry.single_value, so that it is consistent with >>>>>> the >>>>>> rest of the changes introduced in the patches. >>>>>> >>>>>> Patch 110 will probably be dropped in favor of Petr Viktorin's schema >>>>>> update patches, but I included it anyway. >>>>>> >>>>>> Incidentally, this also fixes >>>>>> and possibly also >>>>>> . >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> Noticed a couple more issues and fixed them. Updated patches attached. >>>>> >>>>> Honza >>>> >>>> Thanks for the patches! >>>> >>>> >>>> 106. Make LDAPEntry a wrapper around dict rather than a dict subclass. > > Git rants about one more whitespace error. Fixed. > > [...] >>>> + def __eq__(self, other): >>>> + if not isinstance(other, LDAPEntry): >>>> + return NotImplemented >>>> + if self._dn != other._dn: >>>> + return False >>>> + return super(LDAPEntry, self).__eq__(other) >>>> >>>> I don't think equality checking makes sense on a LDAPEntry, where you >>>> might have different capitalizations/variants of attribute names, >>>> different _orig, or a different set of attributes loaded on the same >>>> entry. It's not obvious which of those differences should make the >>>> entries inequal. >>>> I'd just base it on identity (`self is other`). >>> >>> Right, I'm not sure why I even did it this way. But I remember seeing >>> some code that did comparison of entries with ==... > > Thanks. > Please also implement __ne__() when reimplementing __eq__(). Done. > >>> >>>> >>>> def __iter__(self): >>>> yield self._dn >>>> yield self >>>> >>>> This makes the whole thing sort of hackish -- we need to reimplement >>>> everything in MutableMapping that uses iter() internally :( >>>> Hopefully we can get rid of it soon. >>> >>> Yes, it's a shame MutableMapping uses iter() instead of iterkeys(). >>> >>>> I'd welcome FIXME comments on whatever is reimplemented for this >>>> reason. >>> >>> I thought the comment above __iter__ would be enough. Apparently I was >>> wrong. > > Right, IMO it's not immediately obvious that these are reimplemented > because they depend on __iter__. > > [...] >>>> 109. Decode and encode attribute values in LDAPEntry on demand. >>>> >>>> The syncing looks rather over-engineered to me. >>>> Did you consider a custom MutableSequence for the values? >>>> I think it would be much cleaner in the end than merging two sets of >>>> changes together. >>> >>> I'm not entirely happy about it either, but it works. I did consider a >>> custom sequence type, but I didn't feel like it was the right time to >>> this kind of change in this patchset. >>> >>> Unlike the (DN, dict) -> LDAPEntry >>> transition, this change won't be backward compatible and there is a lot >>> of isinstance(value, list) and entry[attr] = list() kind of things in >>> the framework code. > > That's what I was afraid of. > > We could live with `isinstance(value, list)`; hopefully we could get rid > of `type(value) == list` that is the real problem. > With `entry[attr] = list()` we could convert automatically. > > But OK, let's settle for a worse solution in the meantime. > > > To be frank I don't particularly like the LDAPEntryView. > While the dict-like interface is great, there isn't a case for storing a > Raw view long-term, i.e. you'd always want to do something like > values = entry.raw[x] > ... > entry.raw[x] = new_values > rather than > raw = entry.raw > values = raw[x] > ... > raw[x] = new_values > The latter is confusing because LDAPEntryView and RawLDAPEntryView are > two classes that have exactly the same interface, but do something > different. In a duck-typed world that's a recipe for disaster. > I think it would be better if the view implemented just the dict > protocol, and not `conn`, `dn`, `nice`, `raw`, etc. > The code would also be much simpler without the elaborate view class > hierarchy. > > If you don't agree then at least don't make `raw` available on raw views > and `nice` on nice views; the programmer *always* needs to know which > version they're working with so these aren't necessary. I agree. Most of the attributes are leftovers from a previous implementation, which didn't work very well. I should have removed them a long time ago. Thanks for pointing this out! Updated the views to provide only the dict interface, removed "nice" and "multi_value" properties and also removed "single_value" from the raw view. > >>>> I think it would also help (in the future?) to make the value lists >>>> more >>>> set-like, since the order doesn't matter. >>> >>> +1 >>> >>> Honza >>> >> >> Updated patches attached. >> > > 110. > It can't hurt to have this in for now. > > 111 - 121 look great! > > 169. > For reasons I said before I'd prefer if single_value stayed a simple > function. IMO a view better matches its semantics, plus I changed the code, so I would like to keep it a view, if you don't mind. Updated patches attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-106.5-Make-LDAPEntry-a-wrapper-around-dict-rather-than-a-d.patch Type: text/x-patch Size: 8741 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-107.5-Introduce-IPASimpleLDAPObject.decode-method-for-deco.patch Type: text/x-patch Size: 3810 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-108.5-Always-use-lists-for-values-in-LDAPEntry-internally.patch Type: text/x-patch Size: 4163 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-109.5-Decode-and-encode-attribute-values-in-LDAPEntry-on-d.patch Type: text/x-patch Size: 13477 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-110.5-Make-sure-attributeTypes-updates-are-done-before-obj.patch Type: text/x-patch Size: 1088 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-111.5-Remove-legacy-toDict-and-origDataDict-methods-of-LDA.patch Type: text/x-patch Size: 4874 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-112.5-Store-encoded-attribute-values-from-search-results-d.patch Type: text/x-patch Size: 886 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-113.5-Use-encoded-values-from-entry-objects-directly-when-.patch Type: text/x-patch Size: 3253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-121.5-Use-encoded-values-from-entry-objects-directly-when-.patch Type: text/x-patch Size: 1478 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-169.5-Turn-LDAPEntry.single_value-into-a-dictionary-like-p.patch Type: text/x-patch Size: 48610 bytes Desc: not available URL: From simo at redhat.com Tue Oct 29 13:04:33 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 29 Oct 2013 09:04:33 -0400 Subject: [Freeipa-devel] [PATCHES] 0080-0081 Add userClass attributes for users and hosts In-Reply-To: <526F9F17.6090702@redhat.com> References: <526F84AA.3090004@redhat.com> <526F9F17.6090702@redhat.com> Message-ID: <1383051873.2826.13.camel@willson.li.ssimo.org> On Tue, 2013-10-29 at 12:42 +0100, Martin Kosek wrote: > On 10/29/2013 10:49 AM, Ana Krivokapic wrote: > > Hello, > > > > Patch 0080 adds userClass attribute for users to IPA CLI. > > Patch 0081 adds userClass attribute for users and hosts to the web UI. > > > > Design page: > > http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems > > > > Tickets: > > https://fedorahosted.org/freeipa/ticket/3588 > > https://fedorahosted.org/freeipa/ticket/3590 > > NACK to just extending posixAccount objectclass. This is a standard objectclass > defined by RFC 2307 and we cannot just simply extend and overwrite it as we wish. Uhh indeed this is a big No-no. > We will need to come up with some custom objectclass, like ipaUser. This is the > reason why I wrote to ticket "A second goal of this ticket is to review current > objectClass hierarchy of users and do changes if needed." so that we can pick > the best option where to place it. userClass is used in ipaHost, so I guess it could be instead add to an ipa objectclass. ipaObject might be used perhaps, otherwise we'll need a new ipaUser objectlass. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Oct 29 13:08:12 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 29 Oct 2013 09:08:12 -0400 Subject: [Freeipa-devel] Daily build of the documentation? In-Reply-To: <526F87E9.6090109@redhat.com> References: <1382714021.2282.5.camel@unused-4-145.brq.redhat.com> <526F9090.2030503@redhat.com> <526F87E9.6090109@redhat.com> Message-ID: <1383052092.2826.15.camel@willson.li.ssimo.org> On Tue, 2013-10-29 at 11:03 +0100, Martin Kosek wrote: > On 10/29/2013 11:40 AM, Petr Spacek wrote: > > On 25.10.2013 17:22, 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. > > > > I think that nightly build with "Draft" stamp is a good idea! > > > > Martin^1, is it possible to create an 'machine account' with FTP/git access to > > some part of freeipa.org? We can run publican from cron and push results to > > freeipa.org. > > > > We planned to do exactly this. > > The problem here is, that in order to the script be able to upload the data, I > would need to add it's public key to our FreeIPA.org app and I cannot limit it > just to the user guide directory, but it would then have access to the entire > wiki gear, write access to git and everything... So question is, if we want to > add such access to a public VM in Jenkins or we want to keep it secure in... > hm... my notebook. Maybe we can go the other way around and have a cron job in the freeipa.org VM that pulls from a public git tree where the publican changes are pushed. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Oct 29 14:18:29 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Oct 2013 10:18:29 -0400 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <526F8951.7030007@redhat.com> References: <1380917810.1760.23.camel@localhost> <526F8951.7030007@redhat.com> Message-ID: <526FC3B5.1010009@redhat.com> Petr Vobornik wrote: > On 10/04/2013 10:16 PM, Nathaniel McCallum wrote: >> This patch supersedes my patch 0017 and requires patches 0020-0023. I >> believe I have solved all of the outstanding issues from the review of >> patch 0017, unless otherwise noted: >> >> 1. I'm not actually sure what the format of the date parameters is. >> Could someone clarify this for me? Should I do something differently >> here? > > I think that date parameter is not used anywhere. IMO it should be > designed soon since it will be needed in other tickets [1], [2] as well. > > [1] https://fedorahosted.org/freeipa/ticket/547 [RFE] Implement iCal > based time managment in HBAC > [2] https://fedorahosted.org/freeipa/ticket/3127 [RFE] Time-Based > Account Lockout Policies in IPA FYI the original HBAC time class is still in ipalib/parameters.py::AccessTime. It is supposed to provide a generalized time-like API. Not saying it has to remain. I can't remember how much previous conversations about date/time handling were in mailing lists vs shouting matches on the phone, but it is quite a hard problem in a distributed system like IPA, particularly for the UI. Thar be dragons. rob > >> >> 2. In this new version of the patch, we are writing default values for >> many of the token attributes. It would be nice to have some global >> defaults for these default values, but this is not currently >> implemented. I think this would make a clean secondary patch on top of >> this current patch. >> >> 3. Dmitri brought up the idea of having tokens automatically expire by >> default. Is this a good idea? I think this dovetails nicely with #2 >> above. >> >> 4. This patch does not currently protect the deletion of the last token >> as previously discussed. Here is why I think this is still needed, but >> in the form of a DS plugin: >> >> We need to account for a state when the user is enabled for OTP but has >> not yet configured any tokens. I believe this state should be when the >> "otp" user auth type is set, but the user has no assigned tokens. In >> this state, the user should be able to log in with single factor >> authentication. >> >> Once the user has added tokens, however, should we allow the user to >> remove all his own tokens and return to single factor authentication? If >> yes, nothing further is needed. If no, then protection in the FreeIPA >> framework is not sufficient and this needs to be checked at the DS >> plugin level. I suspect Dmitri might answer that this needs to be a >> matter of policy. >> >> 5. There appears to be some sort of permissions issue with users and >> adding their own tokens. I have not looked into this yet, but I will >> review this early next week. Since this is a small bug fix to an >> existing feature, I figured it was out of scope for this patch. >> >> 6. When a user is deleted, all his tokens are deleted as well. This is >> sensible default behavior. However, in the case of hardware tokens, it >> may be more desirable to orphan these objects for future assignment to >> new users. Does anyone have any opinions on this topic? >> >> Nathaniel >> > > From rcritten at redhat.com Tue Oct 29 14:20:19 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Oct 2013 10:20:19 -0400 Subject: [Freeipa-devel] Daily build of the documentation? In-Reply-To: <1383052092.2826.15.camel@willson.li.ssimo.org> References: <1382714021.2282.5.camel@unused-4-145.brq.redhat.com> <526F9090.2030503@redhat.com> <526F87E9.6090109@redhat.com> <1383052092.2826.15.camel@willson.li.ssimo.org> Message-ID: <526FC423.90602@redhat.com> Simo Sorce wrote: > On Tue, 2013-10-29 at 11:03 +0100, Martin Kosek wrote: >> On 10/29/2013 11:40 AM, Petr Spacek wrote: >>> On 25.10.2013 17:22, 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. >>> >>> I think that nightly build with "Draft" stamp is a good idea! >>> >>> Martin^1, is it possible to create an 'machine account' with FTP/git access to >>> some part of freeipa.org? We can run publican from cron and push results to >>> freeipa.org. >>> >> >> We planned to do exactly this. >> >> The problem here is, that in order to the script be able to upload the data, I >> would need to add it's public key to our FreeIPA.org app and I cannot limit it >> just to the user guide directory, but it would then have access to the entire >> wiki gear, write access to git and everything... So question is, if we want to >> add such access to a public VM in Jenkins or we want to keep it secure in... >> hm... my notebook. > > Maybe we can go the other way around and have a cron job in the > freeipa.org VM that pulls from a public git tree where the publican > changes are pushed. We may not be able to run cron jobs within the gear, but I agree, this is a preferrable solution to me too. rob From mkosek at redhat.com Tue Oct 29 14:25:07 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 29 Oct 2013 15:25:07 +0100 Subject: [Freeipa-devel] Daily build of the documentation? In-Reply-To: <526FC423.90602@redhat.com> References: <1382714021.2282.5.camel@unused-4-145.brq.redhat.com> <526F9090.2030503@redhat.com> <526F87E9.6090109@redhat.com> <1383052092.2826.15.camel@willson.li.ssimo.org> <526FC423.90602@redhat.com> Message-ID: <526FC543.5080607@redhat.com> On 10/29/2013 03:20 PM, Rob Crittenden wrote: > Simo Sorce wrote: >> On Tue, 2013-10-29 at 11:03 +0100, Martin Kosek wrote: >>> On 10/29/2013 11:40 AM, Petr Spacek wrote: >>>> On 25.10.2013 17:22, 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. >>>> >>>> I think that nightly build with "Draft" stamp is a good idea! >>>> >>>> Martin^1, is it possible to create an 'machine account' with FTP/git access to >>>> some part of freeipa.org? We can run publican from cron and push results to >>>> freeipa.org. >>>> >>> >>> We planned to do exactly this. >>> >>> The problem here is, that in order to the script be able to upload the data, I >>> would need to add it's public key to our FreeIPA.org app and I cannot limit it >>> just to the user guide directory, but it would then have access to the entire >>> wiki gear, write access to git and everything... So question is, if we want to >>> add such access to a public VM in Jenkins or we want to keep it secure in... >>> hm... my notebook. >> >> Maybe we can go the other way around and have a cron job in the >> freeipa.org VM that pulls from a public git tree where the publican >> changes are pushed. > > We may not be able to run cron jobs within the gear, but I agree, this is a > preferrable solution to me too. > > rob > Interesting idea, OpenShift already has means to schedule periodical tasks: https://access.redhat.com/site/documentation/en-US/OpenShift/2.0/html/User_Guide/sect-OpenShift-User_Guide-Scheduling_Timed_Jobs_with_Cron.html However, I do not think we can build the doc on the gear itself as publican is not available on the gear. We would need to copy the doc built in our Jenkins instance and update the documentation on the gear. This would be a better and more maintainable solution than a custom script on my notebook, yes. Martin From pviktori at redhat.com Tue Oct 29 14:31:58 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 29 Oct 2013 15:31:58 +0100 Subject: [Freeipa-devel] [PATCH] 197 Track DS certificate with certmonger on replicas In-Reply-To: <525FE5B8.8090702@redhat.com> References: <525FE5B8.8090702@redhat.com> Message-ID: <526FC6DE.8000408@redhat.com> On 10/17/2013 03:27 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza > Thanks! Works for me, ACK, pushed to master: e98abdca9b4cf772e93176b42e17ec5fb5736ea4 ipa-3-3: 074816faf36650dbfa5aa8a22a3896a31b64dbf1 -- Petr? From pviktori at redhat.com Tue Oct 29 15:17:18 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 29 Oct 2013 16:17:18 +0100 Subject: [Freeipa-devel] [PATCHES] 106-113 Access raw LDAP values directly from LDAPEntry In-Reply-To: <526FAB52.5080300@redhat.com> References: <512E26E1.5010302@redhat.com> <52419527.70200@redhat.com> <524426F5.6010006@redhat.com> <525544A3.6080807@redhat.com> <52565B09.2090909@redhat.com> <525BB27C.1000507@redhat.com> <525EBB0D.9040003@redhat.com> <526FAB52.5080300@redhat.com> Message-ID: <526FD17E.7020607@redhat.com> On 10/29/2013 01:34 PM, Jan Cholasta wrote: > On 16.10.2013 18:13, Petr Viktorin wrote: >> On 10/14/2013 10:59 AM, Jan Cholasta wrote: >>> On 10.10.2013 09:45, Jan Cholasta wrote: >>>> On 9.10.2013 13:57, Petr Viktorin wrote: [...] >>>>> 109. Decode and encode attribute values in LDAPEntry on demand. >>>>> >>>>> The syncing looks rather over-engineered to me. >>>>> Did you consider a custom MutableSequence for the values? >>>>> I think it would be much cleaner in the end than merging two sets of >>>>> changes together. >>>> >>>> I'm not entirely happy about it either, but it works. I did consider a >>>> custom sequence type, but I didn't feel like it was the right time to >>>> this kind of change in this patchset. >>>> >>>> Unlike the (DN, dict) -> LDAPEntry >>>> transition, this change won't be backward compatible and there is a lot >>>> of isinstance(value, list) and entry[attr] = list() kind of things in >>>> the framework code. >> >> That's what I was afraid of. >> >> We could live with `isinstance(value, list)`; hopefully we could get rid >> of `type(value) == list` that is the real problem. >> With `entry[attr] = list()` we could convert automatically. >> >> But OK, let's settle for a worse solution in the meantime. >> >> >> To be frank I don't particularly like the LDAPEntryView. >> While the dict-like interface is great, there isn't a case for storing a >> Raw view long-term, i.e. you'd always want to do something like >> values = entry.raw[x] >> ... >> entry.raw[x] = new_values >> rather than >> raw = entry.raw >> values = raw[x] >> ... >> raw[x] = new_values >> The latter is confusing because LDAPEntryView and RawLDAPEntryView are >> two classes that have exactly the same interface, but do something >> different. In a duck-typed world that's a recipe for disaster. >> I think it would be better if the view implemented just the dict >> protocol, and not `conn`, `dn`, `nice`, `raw`, etc. >> The code would also be much simpler without the elaborate view class >> hierarchy. >> >> If you don't agree then at least don't make `raw` available on raw views >> and `nice` on nice views; the programmer *always* needs to know which >> version they're working with so these aren't necessary. > > I agree. Most of the attributes are leftovers from a previous > implementation, which didn't work very well. I should have removed them > a long time ago. Thanks for pointing this out! > > Updated the views to provide only the dict interface, removed "nice" and > "multi_value" properties and also removed "single_value" from the raw view. Looks much better now. Hopefully _sync_attr can dissappear one day. >>>>> I think it would also help (in the future?) to make the value lists >>>>> more >>>>> set-like, since the order doesn't matter. >>>> >>>> +1 >>>> >>>> Honza >>>> >>> >>> Updated patches attached. >>> >> >> 110. >> It can't hurt to have this in for now. >> >> 111 - 121 look great! 106 - 121: ACK >> 169. >> For reasons I said before I'd prefer if single_value stayed a simple >> function. > > IMO a view better matches its semantics, plus I changed the code, so I > would like to keep it a view, if you don't mind. OK, ACK to that one as well, but I'd rather wait a few weeks (until 3.3 churn dies out) before pushing it, since it could complicate backporting patches. -- Petr? From mkosek at redhat.com Tue Oct 29 16:52:29 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 29 Oct 2013 17:52:29 +0100 Subject: [Freeipa-devel] [PATCH] 436 Remove ipa-pwd-extop and ipa-enrollment duplicate error messages Message-ID: <526FE7CD.6000704@redhat.com> Some error strings were duplicate which makes it then harder to see what is the real root cause of it. https://fedorahosted.org/freeipa/ticket/3988 --- I tried to leave the most general error messages as is (entry not found) and only specify the rare ones -> test suite is still passing. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-436-remove-ipa-pwd-extop-and-ipa-enrollment-duplicate-er.patch Type: text/x-patch Size: 7303 bytes Desc: not available URL: From mkosek at redhat.com Tue Oct 29 16:57:29 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 29 Oct 2013 17:57:29 +0100 Subject: [Freeipa-devel] [PATCH] 437 Add nsswitch.conf to FILES section of ipa-client-install man Message-ID: <526FE8F9.9050703@redhat.com> This file is always updated when client is installed or uninstalled. https://fedorahosted.org/freeipa/ticket/3995 ---- Pushed to master, ipa-3-3 as a one-liner change. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-437-add-nsswitch.conf-to-files-section-of-ipa-client-ins.patch Type: text/x-patch Size: 920 bytes Desc: not available URL: From akrivoka at redhat.com Tue Oct 29 17:57:33 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 29 Oct 2013 18:57:33 +0100 Subject: [Freeipa-devel] [PATCH] 0079 Enable Retro Changelog and Content Synchronization DS plugins In-Reply-To: <526FA000.7000806@redhat.com> References: <526A8828.3010807@redhat.com> <526FA000.7000806@redhat.com> Message-ID: <526FF70D.408@redhat.com> On 10/29/2013 12:46 PM, Martin Kosek wrote: > On 10/25/2013 05:03 PM, Ana Krivokapic wrote: >> Hello, >> >> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3967. >> > NACK. I do not think this will work well with the case when DNS is not used. As > bind-dyndb-ldap is not required component, FreeIPA could be installed on a > machine without bind installed. And in that case, /var/named/ won't be there. > > I think that this directory will follow similar pattern as > %{_localstatedir}/lib/ipa/pki-ca/publish > and be just %ghost and be created in when bind-dyndb-ldap is being configured > in bindinstance.py. > > Martin Fixed, updated patch attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0079-02-Enable-Retro-Changelog-and-Content-Synchronization-D.patch Type: text/x-patch Size: 4735 bytes Desc: not available URL: From dpal at redhat.com Tue Oct 29 22:08:10 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 29 Oct 2013 18:08:10 -0400 Subject: [Freeipa-devel] [PATCHES] 0080-0081 Add userClass attributes for users and hosts In-Reply-To: <526FA448.5030205@redhat.com> References: <526F84AA.3090004@redhat.com> <526FA448.5030205@redhat.com> Message-ID: <527031CA.6040109@redhat.com> On 10/29/2013 08:04 AM, Petr Vobornik wrote: > On 10/29/2013 10:49 AM, Ana Krivokapic wrote: >> Hello, >> >> Patch 0080 adds userClass attribute for users to IPA CLI. >> Patch 0081 adds userClass attribute for users and hosts to the web UI. >> >> Design page: >> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >> >> Tickets: >> https://fedorahosted.org/freeipa/ticket/3588 >> https://fedorahosted.org/freeipa/ticket/3590 >> > > In addition to the posixAccount issue: > > 1. I think we should also add a field to host and user adder dialogs. > This feature was designed to work with automember plugin. Without it > in adder dialog, user would have to modify the entry and then run > automember-rebuild. > > That said, I understand that we may decide not to include it in adder > dialogs if we say that this feature is only for provisioning systems, > which don't use Web UI. I agree with this. Please open a separate ticket to expose these fields in the UI. -- 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 Oct 29 22:23:11 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 29 Oct 2013 18:23:11 -0400 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <526FC3B5.1010009@redhat.com> References: <1380917810.1760.23.camel@localhost> <526F8951.7030007@redhat.com> <526FC3B5.1010009@redhat.com> Message-ID: <5270354F.6090306@redhat.com> On 10/29/2013 10:18 AM, Rob Crittenden wrote: > Petr Vobornik wrote: >> On 10/04/2013 10:16 PM, Nathaniel McCallum wrote: >>> This patch supersedes my patch 0017 and requires patches 0020-0023. I >>> believe I have solved all of the outstanding issues from the review of >>> patch 0017, unless otherwise noted: >>> >>> 1. I'm not actually sure what the format of the date parameters is. >>> Could someone clarify this for me? Should I do something differently >>> here? >> >> I think that date parameter is not used anywhere. IMO it should be >> designed soon since it will be needed in other tickets [1], [2] as well. >> >> [1] https://fedorahosted.org/freeipa/ticket/547 [RFE] Implement iCal >> based time managment in HBAC >> [2] https://fedorahosted.org/freeipa/ticket/3127 [RFE] Time-Based >> Account Lockout Policies in IPA > > FYI the original HBAC time class is still in > ipalib/parameters.py::AccessTime. It is supposed to provide a > generalized time-like API. Not saying it has to remain. > > I can't remember how much previous conversations about date/time > handling were in mailing lists vs shouting matches on the phone, but > it is quite a hard problem in a distributed system like IPA, > particularly for the UI. > > Thar be dragons. > We have time defined as: ------------------------------------------------------------- Expressing Time in a Rule There are several approaches that can be used to deal with time. * One approach is to use binary blob to represent an array of access time buckets * Another is to have ranges. We evaluated the two approaches and decided to go with the approach based on ranges. Time Attribute The following attribute is used to store range information: attributeTypes ( 2.16.840.1.113730.3.8.3.15 NAME 'accessTime' DESC 'Access time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v2' ) It is important to acknowledge that this is a multi-valued attribute and that the same rule can have a number of range values. All of these values are retrieved by the client and validated for each HBAC rule. If no value is specified then the caller should assume that the rule always applies. Grammar The following grammar describes the format used to express ranges: timerange = Absolute / Periodic Absolute = "absolute" WSP generalizedTime WSP "~" WSP generalizedTime generalizedTime as defined in RFC 4517 section 3.3.13 but without time zone at the end. Periodic = "periodic" WSP Yearly / Monthly / Weekly / Daily Yearly = "yearly" WSP Y-specifier WSP HHMM WSP "~" WSP HHMM Monthly = "monthly" WSP M-specifier WSP HHMM WSP "~" WSP HHMM Weekly = "weekly" WSP W-specifier WSP HHMM WSP "~" WSP HHMM Daily = "daily" WSP HHMM WSP "~" WSP HHMM Y-specifier = Y-month / Y-week / Y-day Y-month = "month" WSP month-number WSP M-specifier Y-week = "week" WSP week-of-the-year WSP W-specifier Y-day = "day" WSP day-of-the-year M-specifier = M-week / M-day M-week = "week" WSP week-of-the-month WSP W-specifier M-day = "day" WSP day-of-the-month W-specifier = "day" WSP day-of-the-week month-number = interval 1-12 week-of-the-year = interval 1-52 week-of-the-month = interval 1-6 day-of-the-month = interval 1-31 day-of-the-week = interval 1-7 (or Mon-Sun) HH = "00" to "23" MM = "00" to "59" interval XX-YY = a comma-separated list of items from XX to YY, or dash-separated ranges. For example, (interval 1-31) 3-7,10,12,15,25-31 with no spaces inside. This grammar allows the creation of a flexible set of time ranges that include both absolute and periodic date ranges. The dates in the range do not contain any time zone information. Periodic ranges are stored without time zone information in the same format as specified in the UI and the CLI, and are interpreted on the client as a time range in the local machine's time. Absolute ranges do not specify the time zone because absolute time ranges must be specified in UTC. The UI and CLI must convert time stamps entered in local time format during management operations into UTC format. Applications that access LDAP directly for this data must be aware of the rules and assumptions described above. Examples of Expressing Time Ranges To express a time range that applies on Saturday and Sunday from 9AM to 1PM EST every second week of every month, local machine time: periodic monthly week 2 day Sat,Sun 0900-1300 To express a time range that applies from midnight, 10th of October, 2008, until midday, 15th of October, 2008, in UTC: absolute 20081010000000 ~ 20081015120000 -------------------------------------------- I am not sure it is best though. There were some thoughts to express it some other more standard calendaring format that is used in scheduling meetings or events like in Zimbra. This needs to be investigated. Here are some pointers: http://stackoverflow.com/questions/8657183/looking-for-an-advanced-jquery-based-scheduler-widget > rob > >> >>> >>> 2. In this new version of the patch, we are writing default values for >>> many of the token attributes. It would be nice to have some global >>> defaults for these default values, but this is not currently >>> implemented. I think this would make a clean secondary patch on top of >>> this current patch. >>> >>> 3. Dmitri brought up the idea of having tokens automatically expire by >>> default. Is this a good idea? I think this dovetails nicely with #2 >>> above. >>> >>> 4. This patch does not currently protect the deletion of the last token >>> as previously discussed. Here is why I think this is still needed, but >>> in the form of a DS plugin: >>> >>> We need to account for a state when the user is enabled for OTP but has >>> not yet configured any tokens. I believe this state should be when the >>> "otp" user auth type is set, but the user has no assigned tokens. In >>> this state, the user should be able to log in with single factor >>> authentication. >>> >>> Once the user has added tokens, however, should we allow the user to >>> remove all his own tokens and return to single factor >>> authentication? If >>> yes, nothing further is needed. If no, then protection in the FreeIPA >>> framework is not sufficient and this needs to be checked at the DS >>> plugin level. I suspect Dmitri might answer that this needs to be a >>> matter of policy. >>> >>> 5. There appears to be some sort of permissions issue with users and >>> adding their own tokens. I have not looked into this yet, but I will >>> review this early next week. Since this is a small bug fix to an >>> existing feature, I figured it was out of scope for this patch. >>> >>> 6. When a user is deleted, all his tokens are deleted as well. This is >>> sensible default behavior. However, in the case of hardware tokens, it >>> may be more desirable to orphan these objects for future assignment to >>> new users. Does anyone have any opinions on this topic? >>> >>> 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Wed Oct 30 07:57:19 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 30 Oct 2013 08:57:19 +0100 Subject: [Freeipa-devel] [PATCH 0024] Add OTP support to ipalib CLI In-Reply-To: <1381242923.1760.38.camel@localhost> References: <1380917810.1760.23.camel@localhost> <1381181688.1760.36.camel@localhost> <5253B212.6000403@redhat.com> <1381242923.1760.38.camel@localhost> Message-ID: <5270BBDF.5050506@redhat.com> On 8.10.2013 16:35, Nathaniel McCallum wrote: > On Tue, 2013-10-08 at 09:19 +0200, Jan Cholasta wrote: >> >> +class Base32DecodeError(ExecutionError): >> >> Is this really necessary? Are we going to add DecodeError for >> every kind of new encoding in IPA? Can't we just have generic >> DecodeError? (This is not an issue in your patch per se, I'm just >> wondering if we can do it better in the framework.) > > I added the new error due to the existence of a Base64DecodeError. I > figured changing the existing error to be more generic would break api. > > Nathaniel > I think you can use ConversionError instead. I don't see any reason why base32/64 decoding errors should be special cased like this and would like to see Base64DecodeError gone. Honza -- Jan Cholasta From lslebodn at redhat.com Wed Oct 30 08:21:32 2013 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Wed, 30 Oct 2013 09:21:32 +0100 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] Fix warning duplicate 'const' declaration specifier Message-ID: <20131030082131.GA32671@mail.corp.redhat.com> ehlo, There were few warnings in bind-dyndb-ldap "duplicate 'const' declaration specifier". It does not make sense to have const twice in declaration like a "const settings_set_t const settings_default_set" This one was false positive. The 2nd warning revealed potential problem. const char const * dns_str With previous declaration, you cannot modify data, but you can modify pointer itself. *dns_str = "asdasd" //compilation error dns_str++ //works fine If you want to disable modification data and disable modification of pointer you will need to have 2nd const modifier after star "*" You can find some examples of "const" usage in attached file test.c or you can read article with explanation of next declaration "char *(*(**foo [][8])())[];" http://eli.thegreenplace.net/2008/07/18/reading-c-type-declarations/ Simple patch is attached. LS -------------- next part -------------- >From cd87f93f81e2d74506757b87117064eea6b3f282 Mon Sep 17 00:00:00 2001 From: Lukas Slebodnik Date: Wed, 30 Oct 2013 08:52:59 +0100 Subject: [PATCH] Fix warning duplicate 'const' declaration specifier It does not make sense to have const twice in declaration like a "const settings_set_t const settings_default_set" This one was false positive. The 2nd warning revealed potential problem. const char const * dns_str With previous declaration, you cannot modify data, but you can modify pointer itself. *dns_str = "asdasd" //compilation error dns_str++ //works fine If you want to disable modification data and disable modification of pointer you will need to have 2nd const modifier after star "*" --- src/ldap_convert.c | 2 +- src/ldap_helper.c | 2 +- src/settings.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/ldap_convert.c b/src/ldap_convert.c index 5b01b4db8e9cd9b88a8ade735ff82788808d0017..6493fddceb18c07f1ff25003b650df9aa5f62169 100644 --- a/src/ldap_convert.c +++ b/src/ldap_convert.c @@ -231,7 +231,7 @@ cleanup: * will be checked & copied to the output buffer, without any additional escaping. */ isc_result_t -dns_to_ldap_dn_escape(isc_mem_t *mctx, const char const * dns_str, char ** ldap_name) { +dns_to_ldap_dn_escape(isc_mem_t *mctx, const char * const dns_str, char ** ldap_name) { isc_result_t result = ISC_R_FAILURE; char * esc_name = NULL; int idx_symb_first = -1; /* index of first "nice" printable symbol in dns_str */ diff --git a/src/ldap_helper.c b/src/ldap_helper.c index 6a04d2b7da3977e3517fd7f449b7d218be6e1e93..38811d80e28e25e1c8ed90065301e71cbf0606e1 100644 --- a/src/ldap_helper.c +++ b/src/ldap_helper.c @@ -234,7 +234,7 @@ struct ldap_psearchevent { int chgtype; }; -extern const settings_set_t const settings_default_set; +extern const settings_set_t settings_default_set; /** Local configuration file */ static const setting_t settings_local_default[] = { diff --git a/src/settings.c b/src/settings.c index ceb525e5a949086a9486b4c70882f11c5ebe2030..ae5acf93a4f7fb442237400be275f00e0b9806c1 100644 --- a/src/settings.c +++ b/src/settings.c @@ -80,7 +80,7 @@ static const setting_t settings_default[] = { }; /** Settings set for built-in defaults. */ -const settings_set_t const settings_default_set = { +const settings_set_t settings_default_set = { NULL, "built-in defaults", NULL, -- 1.8.3.1 -------------- next part -------------- int main(void) { int localVar=0; // Example A const int * ptr_to_const_data = &localVar; // compilation will fail, try to uncomment //*ptr_to_const_data = 1; //test.c: error: assignment of read-only location ?*ptr_to_const_data? // *ptr_to_const_data = 1; // incrementation of pointer work fine ptr_to_const_data++; // Example B int const * ptr_to_data_const = &localVar; // compilation will fail, try to uncomment //*ptr_to_data_const = 2; //test.c: error: assignment of read-only location ?*ptr_to_data_const? // *ptr_to_data_const = 2; // incrementation of pointer work fine ptr_to_data_const++; // As you can see, there is no difference between example A and example B // But you can try yourself with const int const * ptr_to_const_data_const = &localVar; // example C int * const const_ptr_to_data = &localVar; // modification to refered data is OK *const_ptr_to_data = 3; // cannot compile incrementation of pointer, try to uncomment //const_ptr_to_data++; //test.c: error: increment of read-only variable ?const_ptr_to_data? // const_ptr_to_data++; //example D int const * const const_ptr_to_const_data = &localVar; // compilation will fail, try to uncomment //*const_ptr_to_const_data = 4; //test.c: error: assignment of read-only location ?*const_ptr_to_const_data // *const_ptr_to_const_data = 4; // cannot compile incrementation of pointer, try to uncomment //const_ptr_to_const_data++; //test.c: error: increment of read-only variable ?const_ptr_to_const_data? // const_ptr_to_const_data++; //example E // situation is the same as in example D const int * const const_ptr_to_data_const = &localVar; return 0; } From pvoborni at redhat.com Wed Oct 30 08:51:20 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 30 Oct 2013 09:51:20 +0100 Subject: [Freeipa-devel] [PATCH] 462 Fix password expiration notification Message-ID: <5270C888.70509@redhat.com> Fix password expiration notification - was broken by navigation and application controller refactoring https://fedorahosted.org/freeipa/ticket/4003 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0462-Fix-password-expiration-notification.patch Type: text/x-patch Size: 9950 bytes Desc: not available URL: From mkosek at redhat.com Wed Oct 30 10:52:38 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 30 Oct 2013 11:52:38 +0100 Subject: [Freeipa-devel] [PATCHES] 0289-0294 Fixes in permissions In-Reply-To: <5267ECB7.2050403@redhat.com> References: <5267ECB7.2050403@redhat.com> Message-ID: <5270E4F6.7080402@redhat.com> On 10/23/2013 05:35 PM, Petr Viktorin wrote: > Here are refactorings and fixes for small issues I found so far while working > on ticket #3566. > > Having these already in master should make the final patchset easier to review. I went through all the patches, tested them - works fine. ACK. Pushed to master. Martin From mkosek at redhat.com Wed Oct 30 11:16:07 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 30 Oct 2013 12:16:07 +0100 Subject: [Freeipa-devel] [PATCHES] 0313-0314 Integration test fixes In-Reply-To: <52692020.7070104@redhat.com> References: <52692020.7070104@redhat.com> Message-ID: <5270EA77.5050809@redhat.com> On 10/24/2013 03:26 PM, Petr Viktorin wrote: > Here are fixes for two bugs found while running integration tests under Beaker. Looks good, recursive algorithm works fine now. ACK. Pushed both to master, ipa-3-3. Martin From pspacek at redhat.com Wed Oct 30 11:22:57 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 30 Oct 2013 12:22:57 +0100 Subject: [Freeipa-devel] [PATCH][bind-dyndb-ldap] Fix warning duplicate 'const' declaration specifier In-Reply-To: <20131030082131.GA32671@mail.corp.redhat.com> References: <20131030082131.GA32671@mail.corp.redhat.com> Message-ID: <5270EC11.1010607@redhat.com> On 30.10.2013 09:21, Lukas Slebodnik wrote: > ehlo, > > There were few warnings in bind-dyndb-ldap "duplicate 'const' declaration > specifier". > > It does not make sense to have const twice in declaration > like a "const settings_set_t const settings_default_set" > This one was false positive. > > The 2nd warning revealed potential problem. > const char const * dns_str > With previous declaration, you cannot modify data, but you can modify > pointer itself. > *dns_str = "asdasd" //compilation error > dns_str++ //works fine > > If you want to disable modification data and disable modification of pointer > you will need to have 2nd const modifier after star "*" > > You can find some examples of "const" usage in attached file test.c or > you can read article with explanation of next declaration > "char *(*(**foo [][8])())[];" > http://eli.thegreenplace.net/2008/07/18/reading-c-type-declarations/ > > Simple patch is attached. ACK, thank you for catching this. I will add you patch (with modified commit message) to 4.0 release. Please be so kind and use bind-dyndb-ldap-lslebodn- prefix for your new patches :-) -- Petr^2 Spacek From sbose at redhat.com Wed Oct 30 11:34:41 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 30 Oct 2013 12:34:41 +0100 Subject: [Freeipa-devel] [PATCHES] 122-123 Remove generation and handling of LM hashes Message-ID: <20131030113441.GO2783@localhost.localdomain> Hi, those two patches try to fix https://fedorahosted.org/freeipa/ticket/3795 (Remove LANMAN hash support). The first patch removes to option to enable the support while the second removes all the related C-code. Although the ticket is schedule for the 3.3.x bugfix release I'm not sure if it is a good idea to remove the support in a minor release. Since the LM hashes are not enabled by default I would expect that in setups where it is enabled the hashes are needed one way or the other. Those setup should get time to adopt. Maybe we can add to the release notes of 3.3.x that LM hash support will go away with the next major release and add the patches to master only? If the patches are needed/wanted on some platforms I think they can be easily backported and added as a patch to those platforms. bye, Sumit -------------- next part -------------- From c9c2510a087eb91afa718ccd6d731478c461c8fc Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 29 Oct 2013 11:37:03 +0100 Subject: [PATCH 122/123] Remove AllowLMhash from the allowed IPA config strings Fixes https://fedorahosted.org/freeipa/ticket/3795 --- API.txt | 2 +- install/ui/src/freeipa/serverconfig.js | 2 +- install/ui/test/data/ipa_init_commands.json | 1 - install/ui/test/data/ipa_init_objects.json | 1 - ipalib/plugins/config.py | 2 +- 5 files changed, 3 insertions(+), 5 deletions(-) diff --git a/API.txt b/API.txt index 40871f6a8b105a7b161df34ce4f6feaf785a6107..605f9ee30b7a945e529dc208c8e719cd04ec3a87 100644 --- a/API.txt +++ b/API.txt @@ -499,7 +499,7 @@ args: 0,24,3 option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('delattr*', cli_name='delattr', exclude='webui') -option: StrEnum('ipaconfigstring', attribute=True, autofill=False, cli_name='ipaconfigstring', csv=True, multivalue=True, required=False, values=(u'AllowLMhash', u'AllowNThash', u'KDC:Disable Last Success', u'KDC:Disable Lockout')) +option: StrEnum('ipaconfigstring', attribute=True, autofill=False, cli_name='ipaconfigstring', csv=True, multivalue=True, required=False, values=(u'AllowNThash', u'KDC:Disable Last Success', u'KDC:Disable Lockout')) option: Str('ipadefaultemaildomain', attribute=True, autofill=False, cli_name='emaildomain', multivalue=False, required=False) option: Str('ipadefaultloginshell', attribute=True, autofill=False, cli_name='defaultshell', multivalue=False, required=False) option: Str('ipadefaultprimarygroup', attribute=True, autofill=False, cli_name='defaultgroup', multivalue=False, required=False) diff --git a/install/ui/src/freeipa/serverconfig.js b/install/ui/src/freeipa/serverconfig.js index 94e1454adebc3dd6848b0251db5e3e460211084e..7dea5d1f5344d187e746333824416b85874414e3 100644 --- a/install/ui/src/freeipa/serverconfig.js +++ b/install/ui/src/freeipa/serverconfig.js @@ -69,7 +69,7 @@ return { name: 'ipaconfigstring', $type: 'checkboxes', options: IPA.create_options([ - 'AllowLMhash', 'AllowNThash', + 'AllowNThash', 'KDC:Disable Last Success', 'KDC:Disable Lockout' ]) }, diff --git a/install/ui/test/data/ipa_init_commands.json b/install/ui/test/data/ipa_init_commands.json index 4f28701fb1db2913a8317a9299a4cc7de73155da..207318115cc9a0d9f7cbd2c6f1bf31aae9aa8814 100644 --- a/install/ui/test/data/ipa_init_commands.json +++ b/install/ui/test/data/ipa_init_commands.json @@ -2278,7 +2278,6 @@ "name": "ipaconfigstring", "type": "unicode", "values": [ - "AllowLMhash", "AllowNThash", "KDC:Disable Last Success", "KDC:Disable Lockout" diff --git a/install/ui/test/data/ipa_init_objects.json b/install/ui/test/data/ipa_init_objects.json index bef3cc65d45a8473f7fed3b67124bbc892213ca5..8550e8280a69d4eafdac5529ba39f162f3dbc9eb 100644 --- a/install/ui/test/data/ipa_init_objects.json +++ b/install/ui/test/data/ipa_init_objects.json @@ -580,7 +580,6 @@ "name": "ipaconfigstring", "type": "unicode", "values": [ - "AllowLMhash", "AllowNThash", "KDC:Disable Last Success", "KDC:Disable Lockout" diff --git a/ipalib/plugins/config.py b/ipalib/plugins/config.py index b9cf05016bf80cd48134cca5a50cdca7db423ca9..fbaacb7b9daafac4de49f23794b807e99aab6fc3 100644 --- a/ipalib/plugins/config.py +++ b/ipalib/plugins/config.py @@ -178,7 +178,7 @@ class config(LDAPObject): cli_name='ipaconfigstring', label=_('Password plugin features'), doc=_('Extra hashes to generate in password plug-in'), - values=(u'AllowLMhash', u'AllowNThash', + values=(u'AllowNThash', u'KDC:Disable Last Success', u'KDC:Disable Lockout'), csv=True, ), -- 1.8.1.4 -------------- next part -------------- From 01ec90e42b4f66fa0478c30ad9ab826ab1786fdf Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 29 Oct 2013 12:19:01 +0100 Subject: [PATCH 123/123] Remove generation and handling of LM hashes https://fedorahosted.org/freeipa/ticket/3795 --- daemons/ipa-sam/ipa_sam.c | 6 +- daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c | 14 +--- daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c | 11 +-- daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h | 3 +- daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 17 +---- util/ipa_pwd.h | 1 - util/ipa_pwd_ntlm.c | 89 +--------------------- 7 files changed, 10 insertions(+), 131 deletions(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 59ddcef2e66f59297d2e42dadb5512e242f60657..5743a792f27b45937b709b15f2e79e1562dc0c18 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -2711,17 +2711,13 @@ static bool init_sam_from_td(struct samu *user, struct pdb_trusted_domain *td, goto done; } - ret = encode_ntlm_keys(trustpw_utf8, trustpw_utf8_uc, true, true, + ret = encode_ntlm_keys(trustpw_utf8, trustpw_utf8_uc, true, &ntlm_keys); if (ret != 0) { res = false; goto done; } - if (!pdb_set_lanman_passwd(user, ntlm_keys.lm, PDB_SET)) { - res = false; - goto done; - } if (!pdb_set_nt_passwd(user, ntlm_keys.nt, PDB_SET)) { res = false; goto done; diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c index f0339c47c5b242b436d77c4845c5914eae79814f..2538a4094bd9a166e61b0911e5ea93426092d88a 100644 --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c @@ -366,7 +366,6 @@ static struct ipapwd_krbcfg *ipapwd_getConfig(void) slapi_entry_free(config_entry); /* get the ipa etc/ipaConfig entry */ - config->allow_lm_hash = false; config->allow_nt_hash = false; ret = ipapwd_getEntry(ipa_etc_config_dn, &config_entry, NULL); if (ret != LDAP_SUCCESS) { @@ -376,10 +375,6 @@ static struct ipapwd_krbcfg *ipapwd_getConfig(void) tmparray = slapi_entry_attr_get_charray(config_entry, "ipaConfigString"); for (i = 0; tmparray && tmparray[i]; i++) { - if (strcasecmp(tmparray[i], "AllowLMhash") == 0) { - config->allow_lm_hash = true; - continue; - } if (strcasecmp(tmparray[i], "AllowNThash") == 0) { config->allow_nt_hash = true; continue; @@ -928,7 +923,6 @@ int ipapwd_SetPassword(struct ipapwd_krbcfg *krbcfg, Slapi_Value **pwvals = NULL; struct tm utctime; char timestr[GENERALIZED_TIME_LENGTH+1]; - char *lm = NULL; char *nt = NULL; int is_smb = 0; int is_ipant = 0; @@ -965,7 +959,7 @@ int ipapwd_SetPassword(struct ipapwd_krbcfg *krbcfg, ret = ipapwd_gen_hashes(krbcfg, data, data->password, is_krb, is_smb, is_ipant, - &svals, &nt, &lm, &ntvals, &errMesg); + &svals, &nt, &ntvals, &errMesg); if (ret) { goto free_and_return; } @@ -1004,11 +998,6 @@ int ipapwd_SetPassword(struct ipapwd_krbcfg *krbcfg, } } - if (lm && is_smb) { - slapi_mods_add_string(smods, LDAP_MOD_REPLACE, - "sambaLMPassword", lm); - } - if (nt && is_smb) { slapi_mods_add_string(smods, LDAP_MOD_REPLACE, "sambaNTPassword", nt); @@ -1069,7 +1058,6 @@ int ipapwd_SetPassword(struct ipapwd_krbcfg *krbcfg, LOG_TRACE("<= result: %d\n", ret); free_and_return: - if (lm) slapi_ch_free((void **)&lm); if (nt) slapi_ch_free((void **)&nt); if (modtime) slapi_ch_free((void **)&modtime); slapi_mods_free(&smods); diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c index a92eaf0da33809e5a4b81c7f10a801e256880743..aa06b5302f0a76a270c7aeed66d60a2551ef4d89 100644 --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c @@ -201,7 +201,7 @@ enc_error: int ipapwd_gen_hashes(struct ipapwd_krbcfg *krbcfg, struct ipapwd_data *data, char *userpw, int is_krb, int is_smb, int is_ipant, Slapi_Value ***svals, - char **nthash, char **lmhash, Slapi_Value ***ntvals, + char **nthash, Slapi_Value ***ntvals, char **errMesg) { int rc; @@ -209,7 +209,6 @@ int ipapwd_gen_hashes(struct ipapwd_krbcfg *krbcfg, *svals = NULL; *nthash = NULL; - *lmhash = NULL; *errMesg = NULL; if (is_krb) { @@ -225,7 +224,7 @@ int ipapwd_gen_hashes(struct ipapwd_krbcfg *krbcfg, } if (is_smb || is_ipant) { - char lm[33], nt[33]; + char nt[33]; struct ntlm_keys ntlm; int ret; @@ -239,7 +238,6 @@ int ipapwd_gen_hashes(struct ipapwd_krbcfg *krbcfg, ret = encode_ntlm_keys(userpw, userpw_uc, - krbcfg->allow_lm_hash, krbcfg->allow_nt_hash, &ntlm); memset(userpw_uc, 0, strlen(userpw_uc)); @@ -250,11 +248,6 @@ int ipapwd_gen_hashes(struct ipapwd_krbcfg *krbcfg, rc = LDAP_OPERATIONS_ERROR; goto done; } - if (krbcfg->allow_lm_hash) { - hexbuf(lm, ntlm.lm); - lm[32] = '\0'; - *lmhash = slapi_ch_strdup(lm); - } if (krbcfg->allow_nt_hash) { hexbuf(nt, ntlm.nt); nt[32] = '\0'; diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h index 74b63627689da9e519ec15d1e2020fa50ea7f75c..b4087488ccf2081aeed9aa02d1a4f0d37f4cf7f4 100644 --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h @@ -132,7 +132,6 @@ struct ipapwd_krbcfg { krb5_key_salt_tuple *pref_encsalts; char **passsync_mgrs; int num_passsync_mgrs; - bool allow_lm_hash; bool allow_nt_hash; }; @@ -172,7 +171,7 @@ void ipapwd_keyset_free(struct ipapwd_keyset **pkset); int ipapwd_gen_hashes(struct ipapwd_krbcfg *krbcfg, struct ipapwd_data *data, char *userpw, int is_krb, int is_smb, int is_ipant, - Slapi_Value ***svals, char **nthash, char **lmhash, + Slapi_Value ***svals, char **nthash, Slapi_Value ***ntvals, char **errMesg); /* from prepost.c */ diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c index f5100a292adcb6db63fcad7b4780d4b2a5ab512e..fa956acebe974a2b07bb2ea6abfdd4c339b6eb47 100644 --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c @@ -329,13 +329,12 @@ static int ipapwd_pre_add(Slapi_PBlock *pb) Slapi_Value **svals = NULL; Slapi_Value **ntvals = NULL; char *nt = NULL; - char *lm = NULL; pwdop->is_krb = is_krb; rc = ipapwd_gen_hashes(krbcfg, &pwdop->pwdata, userpw, is_krb, is_smb, is_ipant, - &svals, &nt, &lm, &ntvals, &errMesg); + &svals, &nt, &ntvals, &errMesg); if (rc != LDAP_SUCCESS) { goto done; } @@ -353,11 +352,6 @@ static int ipapwd_pre_add(Slapi_PBlock *pb) ipapwd_free_slapi_value_array(&svals); } - if (lm && is_smb) { - /* set value */ - slapi_entry_attr_set_charptr(e, "sambaLMPassword", lm); - slapi_ch_free_string(&lm); - } if (nt && is_smb) { /* set value */ slapi_entry_attr_set_charptr(e, "sambaNTPassword", nt); @@ -823,11 +817,10 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb) Slapi_Value **svals = NULL; Slapi_Value **ntvals = NULL; char *nt = NULL; - char *lm = NULL; rc = ipapwd_gen_hashes(krbcfg, &pwdop->pwdata, unhashedpw, gen_krb_keys, is_smb, is_ipant, - &svals, &nt, &lm, &ntvals, &errMesg); + &svals, &nt, &ntvals, &errMesg); if (rc) { goto done; } @@ -839,12 +832,6 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb) ipapwd_free_slapi_value_array(&svals); } - if (lm && is_smb) { - /* replace value */ - slapi_mods_add_string(smods, LDAP_MOD_REPLACE, - "sambaLMPassword", lm); - slapi_ch_free_string(&lm); - } if (nt && is_smb) { /* replace value */ slapi_mods_add_string(smods, LDAP_MOD_REPLACE, diff --git a/util/ipa_pwd.h b/util/ipa_pwd.h index a6990cac6333bf2582fb071a507001b10145df6d..fecf89650b18ea64393c69b71127305036d336cd 100644 --- a/util/ipa_pwd.h +++ b/util/ipa_pwd.h @@ -81,7 +81,6 @@ struct ntlm_keys { int encode_ntlm_keys(char *newPasswd, char *upperPasswd, - bool do_lm_hash, bool do_nt_hash, struct ntlm_keys *keys); diff --git a/util/ipa_pwd_ntlm.c b/util/ipa_pwd_ntlm.c index a3399b58e006e340677fa43773e6282249858062..92f56099fdad23e777488fcf0fdc1fd1cfce599d 100644 --- a/util/ipa_pwd_ntlm.c +++ b/util/ipa_pwd_ntlm.c @@ -43,104 +43,21 @@ static const uint8_t parity_table[128] = { 224,227,229,230,233,234,236,239,241,242,244,247,248,251,253,254 }; -static void lm_shuffle(uint8_t *out, uint8_t *in) -{ - out[0] = parity_table[in[0]>>1]; - out[1] = parity_table[((in[0]<<6)|(in[1]>>2)) & 0x7F]; - out[2] = parity_table[((in[1]<<5)|(in[2]>>3)) & 0x7F]; - out[3] = parity_table[((in[2]<<4)|(in[3]>>4)) & 0x7F]; - out[4] = parity_table[((in[3]<<3)|(in[4]>>5)) & 0x7F]; - out[5] = parity_table[((in[4]<<2)|(in[5]>>6)) & 0x7F]; - out[6] = parity_table[((in[5]<<1)|(in[6]>>7)) & 0x7F]; - out[7] = parity_table[in[6] & 0x7F]; -} - -/* create the lm and nt hashes +/* create the nt hash newPassword: the clear text utf8 password upperPasswd: upper case version of clear text utf8 password - do_lm_hash: determine if LM hash is generated do_nt_hash: determine if NT hash is generated keys[out]: array with generated hashes */ int encode_ntlm_keys(char *newPasswd, char *upperPasswd, - bool do_lm_hash, bool do_nt_hash, struct ntlm_keys *keys) { int ret = 0; - /* do lanman first */ - if (do_lm_hash) { - iconv_t cd; - size_t cs, il, ol; - char *inc, *outc; - char *asciiPasswd; - DES_key_schedule schedule; - DES_cblock deskey; - DES_cblock magic = "KGS!@#$%"; - - if (upperPasswd == NULL) { - ret = -1; - goto done; - } - il = strlen(upperPasswd); - - /* TODO: must store the dos charset somewhere in the directory */ - cd = iconv_open(KTF_DOS_CHARSET, KTF_UTF8); - if (cd == (iconv_t)(-1)) { - ret = -1; - goto done; - } - - /* an ascii string can only be smaller than or equal to an utf8 one */ - ol = il; - if (ol < 14) ol = 14; - asciiPasswd = calloc(ol+1, 1); - if (!asciiPasswd) { - iconv_close(cd); - ret = -1; - goto done; - } - - inc = upperPasswd; - outc = asciiPasswd; - cs = iconv(cd, &inc, &il, &outc, &ol); - if (cs == -1) { - ret = -1; - free(asciiPasswd); - iconv_close(cd); - goto done; - } - - /* done with these */ - iconv_close(cd); - - /* we are interested only in the first 14 ASCII chars for lanman */ - if (strlen(asciiPasswd) > 14) { - asciiPasswd[14] = '\0'; - } - - /* first half */ - lm_shuffle(deskey, (uint8_t *)asciiPasswd); - - DES_set_key_unchecked(&deskey, &schedule); - DES_ecb_encrypt(&magic, (DES_cblock *)keys->lm, - &schedule, DES_ENCRYPT); - - /* second half */ - lm_shuffle(deskey, (uint8_t *)&asciiPasswd[7]); - - DES_set_key_unchecked(&deskey, &schedule); - DES_ecb_encrypt(&magic, (DES_cblock *)&(keys->lm[8]), - &schedule, DES_ENCRYPT); - - /* done with it */ - free(asciiPasswd); - - } else { - memset(keys->lm, 0, 16); - } + /* clear ln hash so that old values might get cleared as well */ + memset(keys->lm, 0, 16); if (do_nt_hash) { iconv_t cd; -- 1.8.1.4 From akrivoka at redhat.com Wed Oct 30 12:18:13 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 30 Oct 2013 13:18:13 +0100 Subject: [Freeipa-devel] [PATCH] 462 Fix password expiration notification In-Reply-To: <5270C888.70509@redhat.com> References: <5270C888.70509@redhat.com> Message-ID: <5270F905.1070301@redhat.com> The patch fixes the issue. I have just one nitpick: > + # reset password if needed > + if (self.get_auth_dialog()): ^^ ^^ <- redundant parentheses -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From pvoborni at redhat.com Wed Oct 30 12:24:12 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 30 Oct 2013 13:24:12 +0100 Subject: [Freeipa-devel] [PATCH] 462 Fix password expiration notification In-Reply-To: <5270F905.1070301@redhat.com> References: <5270C888.70509@redhat.com> <5270F905.1070301@redhat.com> Message-ID: <5270FA6C.3050009@redhat.com> On 10/30/2013 01:18 PM, Ana Krivokapic wrote: > The patch fixes the issue. > > I have just one nitpick: > > >> + # reset password if needed >> + if (self.get_auth_dialog()): > ^^ ^^ <- redundant parentheses > > Fixed -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0462-1-Fix-password-expiration-notification.patch Type: text/x-patch Size: 9948 bytes Desc: not available URL: From akrivoka at redhat.com Wed Oct 30 12:27:52 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 30 Oct 2013 13:27:52 +0100 Subject: [Freeipa-devel] [PATCH] 462 Fix password expiration notification In-Reply-To: <5270FA6C.3050009@redhat.com> References: <5270C888.70509@redhat.com> <5270F905.1070301@redhat.com> <5270FA6C.3050009@redhat.com> Message-ID: <5270FB48.2050202@redhat.com> On 10/30/2013 01:24 PM, Petr Vobornik wrote: > On 10/30/2013 01:18 PM, Ana Krivokapic wrote: >> The patch fixes the issue. >> >> I have just one nitpick: >> >> >>> + # reset password if needed >>> + if (self.get_auth_dialog()): >> ^^ ^^ <- redundant parentheses >> >> > Fixed ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From abokovoy at redhat.com Wed Oct 30 12:28:34 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 30 Oct 2013 14:28:34 +0200 Subject: [Freeipa-devel] [PATCHES] 122-123 Remove generation and handling of LM hashes In-Reply-To: <20131030113441.GO2783@localhost.localdomain> References: <20131030113441.GO2783@localhost.localdomain> Message-ID: <20131030122833.GJ25335@redhat.com> On Wed, 30 Oct 2013, Sumit Bose wrote: >Hi, > >those two patches try to fix >https://fedorahosted.org/freeipa/ticket/3795 (Remove LANMAN hash >support). The first patch removes to option to enable the support while >the second removes all the related C-code. ACK on these patches but see below. >Although the ticket is schedule for the 3.3.x bugfix release I'm not >sure if it is a good idea to remove the support in a minor release. >Since the LM hashes are not enabled by default I would expect that in >setups where it is enabled the hashes are needed one way or the other. >Those setup should get time to adopt. We should add removal of the 'allowlmhash' from the IPA config with upgrade plugin. -- / Alexander Bokovoy From pvoborni at redhat.com Wed Oct 30 12:34:55 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 30 Oct 2013 13:34:55 +0100 Subject: [Freeipa-devel] [PATCH] 462 Fix password expiration notification In-Reply-To: <5270FB48.2050202@redhat.com> References: <5270C888.70509@redhat.com> <5270F905.1070301@redhat.com> <5270FA6C.3050009@redhat.com> <5270FB48.2050202@redhat.com> Message-ID: <5270FCEF.3030007@redhat.com> On 10/30/2013 01:27 PM, Ana Krivokapic wrote: > On 10/30/2013 01:24 PM, Petr Vobornik wrote: >> On 10/30/2013 01:18 PM, Ana Krivokapic wrote: >>> The patch fixes the issue. >>> >>> I have just one nitpick: >>> >>> >>>> + # reset password if needed >>>> + if (self.get_auth_dialog()): >>> ^^ ^^ <- redundant parentheses >>> >>> >> Fixed > > ACK > Pushed to master, ipa-3-3. -- Petr Vobornik From mkosek at redhat.com Wed Oct 30 13:12:23 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 30 Oct 2013 14:12:23 +0100 Subject: [Freeipa-devel] [PATCHES] 122-123 Remove generation and handling of LM hashes In-Reply-To: <20131030122833.GJ25335@redhat.com> References: <20131030113441.GO2783@localhost.localdomain> <20131030122833.GJ25335@redhat.com> Message-ID: <527105B7.50900@redhat.com> On 10/30/2013 01:28 PM, Alexander Bokovoy wrote: > On Wed, 30 Oct 2013, Sumit Bose wrote: > >> Hi, >> >> those two patches try to fix >> https://fedorahosted.org/freeipa/ticket/3795 (Remove LANMAN hash >> support). The first patch removes to option to enable the support while >> the second removes all the related C-code. > ACK on these patches but see below. I have few comments on the patches: 1) In util/ipa_pwd_ntlm.c, we can now also remove parity_table. 2) In util/ipa_pwd_ntlm.c, in encode_ntlm_keys, upperPasswd is no longer needed (i.e. the UTF upper-casing calls in caller functions are not needed either). I am thinking we could simplify the function just to: int encode_nt_key(char *newPasswd, uint8_t *ntHash) i.e. it seems to me that ntlm_keys structure may not be needed now, since we removed one item of two in it. keys->lm is not used anywhere anyway. >> Although the ticket is schedule for the 3.3.x bugfix release I'm not >> sure if it is a good idea to remove the support in a minor release. >> Since the LM hashes are not enabled by default I would expect that in >> setups where it is enabled the hashes are needed one way or the other. >> Those setup should get time to adopt. > We should add removal of the 'allowlmhash' from the IPA config with > upgrade plugin. Not sure this is the best way. With Sumit's patches, generation of the LM hash is not stopped despite the configuration. So if someone still needs an old IPA server where these hashes are used, they are still generated and used there. If you remove allowlmhash from the config, once you install a patched IPA replica, the value would get replicated and old IPA server would not generate the hashes. Martin From abokovoy at redhat.com Wed Oct 30 13:36:32 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 30 Oct 2013 15:36:32 +0200 Subject: [Freeipa-devel] [PATCHES] 122-123 Remove generation and handling of LM hashes In-Reply-To: <527105B7.50900@redhat.com> References: <20131030113441.GO2783@localhost.localdomain> <20131030122833.GJ25335@redhat.com> <527105B7.50900@redhat.com> Message-ID: <20131030133632.GK25335@redhat.com> On Wed, 30 Oct 2013, Martin Kosek wrote: >On 10/30/2013 01:28 PM, Alexander Bokovoy wrote: >> On Wed, 30 Oct 2013, Sumit Bose wrote: >> >>> Hi, >>> >>> those two patches try to fix >>> https://fedorahosted.org/freeipa/ticket/3795 (Remove LANMAN hash >>> support). The first patch removes to option to enable the support while >>> the second removes all the related C-code. >> ACK on these patches but see below. > >I have few comments on the patches: > >1) In util/ipa_pwd_ntlm.c, we can now also remove parity_table. > >2) In util/ipa_pwd_ntlm.c, in encode_ntlm_keys, upperPasswd is no longer needed >(i.e. the UTF upper-casing calls in caller functions are not needed either). I >am thinking we could simplify the function just to: > >int encode_nt_key(char *newPasswd, > uint8_t *ntHash) > >i.e. it seems to me that ntlm_keys structure may not be needed now, since we >removed one item of two in it. keys->lm is not used anywhere anyway. > >>> Although the ticket is schedule for the 3.3.x bugfix release I'm not >>> sure if it is a good idea to remove the support in a minor release. >>> Since the LM hashes are not enabled by default I would expect that in >>> setups where it is enabled the hashes are needed one way or the other. >>> Those setup should get time to adopt. >> We should add removal of the 'allowlmhash' from the IPA config with >> upgrade plugin. > >Not sure this is the best way. With Sumit's patches, generation of the LM hash >is not stopped despite the configuration. So if someone still needs an old IPA >server where these hashes are used, they are still generated and used there. > >If you remove allowlmhash from the config, once you install a patched IPA >replica, the value would get replicated and old IPA server would not generate >the hashes. And that's precisely what we need: stop generating and using, and even storing LM hashes. They are too easy to crack with rainbow tables existing for this purpose, making possible to crack LM hash in few seconds. So, I still would go with an update plugin and a task to remove existing configuration, and remove LM hashes for existing users on all replicas. -- / Alexander Bokovoy From tbabej at redhat.com Wed Oct 30 14:57:42 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 30 Oct 2013 15:57:42 +0100 Subject: [Freeipa-devel] [PATCH 0121] ipatests: Add support for hosts referenced by a keyword In-Reply-To: <526FA36E.3070000@redhat.com> References: <52662737.7070705@redhat.com> <52662F3F.2050309@redhat.com> <526632A2.4030404@redhat.com> <52663AD6.4070308@redhat.com> <5268F465.7040800@redhat.com> <526FA36E.3070000@redhat.com> Message-ID: <52711E66.20409@redhat.com> On 10/29/2013 01:00 PM, Petr Viktorin wrote: > On 10/24/2013 12:20 PM, Tomas Babej wrote: >> On 10/22/2013 10:44 AM, Petr Viktorin wrote: >>> On 10/22/2013 10:09 AM, Tomas Babej wrote: >>>> On 10/22/2013 09:54 AM, Petr Viktorin wrote: >>>>> On 10/22/2013 09:20 AM, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> Adds support for host definition by a environment variables of the >>>>>> following form: >>>>>> >>>>>> KEYWORDHOST__envX, where X is the number of the environment >>>>>> for which host referenced by a keyword should be defined. >>>>>> >>>>>> You can also optionally use KEYWORDHOST__IP_envX to define >>>>>> the IP address directly, otherwise the framework will try to resolve >>>>>> the hostname. >>>>>> >>>>>> Adds a required_keyword_hosts attribute to the IntegrationTest >>>>>> class, >>>>>> which can test developer use to specify the keyword hosts that this >>>>>> particular test requires. If not all required keyword hosts are >>>>>> available, the test will be skipped. >>>>>> >>>>>> All keyword hosts are accessible to the IntegrationTests via the >>>>>> keyword_hosts attribute, which contains a dictionary keyed by the >>>>>> keywords. >>>>>> >>>>> >>>>> Why is this necessary? >>>>> What's wrong with just extending the current scheme with more roles? >>>>> >>>>> >>>> >>>> The need for keyword hosts arised with the implementation of the >>>> legacy >>>> client test suite. >>>> >>>> As each of these tests needs a precise type (pre-defined and >>>> pre-configured) of VM, and not a generic client, you need to restrict >>>> the test case to specific host type. >>>> >>>> One test might be restricted to RHEL 5.10 with nss-pam-ldapd, >>>> another to >>>> FreeBSD, next one to CentOS with nss-pam-ldapd, next to CentOS with >>>> old >>>> version of SSSD... >>>> >>>> Each testcase that needs a new type of preconfigured host, we would >>>> need >>>> to introduce a new role, which would need to be integrated in the >>>> framework. In such implementation, we would lose loose coupling >>>> between >>>> the test framework and the test themselves, and make them less >>>> pluggable. >>> >>> The framework itself (excluding the configuration part) should be able >>> to handle this nicely using the existing role mechanism. It's true >>> that in some places it's currently hard-wired to just a few roles, but >>> supporting completely custom roles shouldn't be a problem. >>> I'd prefer if this system was used, rather than basically adding a >>> second role system, which we'd have to support even if we get rid of >>> the current config part. >>> >>> The envvar-based configuration is not as flexible, but I'd rather make >>> this part somewhat unpleasant than making the framework complex. We >>> plan to move to a simpler configuration method anyway. >>> That said, you can basically keep the variable name scheme you use in >>> this patch; just maybe use TESTHOST rather than KEYWORDHOST. >>> >> >> I rewired the patch to use the current role system. >> >> Please look if you have any additional issues. >> > > I only have two naming nitpicks. > - The roles aren't really "dynamic"; eventually all the "dynamicness" > should be specific just to the envvar configuration system, and a few > shortcuts like `replicas` for `host_by_role('replica')`. I think > "extra" would be a better term. > - The environment variable names could be more descriptive. They store > a hostname, not a role, so instead of $ROLE__envX I'd prefer > $TESTHOST__envX > > Other than that the changes look great! > Thanks, updated patch attached. -- 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-0121-3-ipatests-Add-support-for-extra-roles-referenced-by-a.patch Type: text/x-patch Size: 17125 bytes Desc: not available URL: From rcritten at redhat.com Wed Oct 30 14:58:56 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 30 Oct 2013 10:58:56 -0400 Subject: [Freeipa-devel] [PATCH] 436 Remove ipa-pwd-extop and ipa-enrollment duplicate error messages In-Reply-To: <526FE7CD.6000704@redhat.com> References: <526FE7CD.6000704@redhat.com> Message-ID: <52711EB0.80304@redhat.com> Martin Kosek wrote: > Some error strings were duplicate which makes it then harder to > see what is the real root cause of it. > > https://fedorahosted.org/freeipa/ticket/3988 > > --- > > I tried to leave the most general error messages as is (entry not found) and > only specify the rare ones -> test suite is still passing. > > Martin > ACK if you drop the str(e) of the exceptions. rob From akrivoka at redhat.com Wed Oct 30 15:03:11 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 30 Oct 2013 16:03:11 +0100 Subject: [Freeipa-devel] [PATCHES] 0080-0081 Add userClass attributes for users and hosts In-Reply-To: <527031CA.6040109@redhat.com> References: <526F84AA.3090004@redhat.com> <526FA448.5030205@redhat.com> <527031CA.6040109@redhat.com> Message-ID: <52711FAF.8090706@redhat.com> On 10/29/2013 11:08 PM, Dmitri Pal wrote: > On 10/29/2013 08:04 AM, Petr Vobornik wrote: >> On 10/29/2013 10:49 AM, Ana Krivokapic wrote: >>> Hello, >>> >>> Patch 0080 adds userClass attribute for users to IPA CLI. >>> Patch 0081 adds userClass attribute for users and hosts to the web UI. >>> >>> Design page: >>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >>> >>> Tickets: >>> https://fedorahosted.org/freeipa/ticket/3588 >>> https://fedorahosted.org/freeipa/ticket/3590 >>> >> In addition to the posixAccount issue: >> >> 1. I think we should also add a field to host and user adder dialogs. >> This feature was designed to work with automember plugin. Without it >> in adder dialog, user would have to modify the entry and then run >> automember-rebuild. >> >> That said, I understand that we may decide not to include it in adder >> dialogs if we say that this feature is only for provisioning systems, >> which don't use Web UI. > I agree with this. Please open a separate ticket to expose these fields > in the UI. > I think we can do that within the scope of ticket #3590. I added a comment to specify exactly what needs to be done: https://fedorahosted.org/freeipa/ticket/3590#comment:5 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From tbabej at redhat.com Wed Oct 30 15:01:28 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 30 Oct 2013 16:01:28 +0100 Subject: [Freeipa-devel] [PATCH 0123] ipatests: Do not use /usr/bin hardcoded paths Message-ID: <52711F48.2020602@redhat.com> Hi, The RHEL 5.9 clients do not have /usr/bin symlinks. Part of: https://fedorahosted.org/freeipa/ticket/3833 -- 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-0123-ipatests-Do-not-use-usr-bin-hardcoded-paths.patch Type: text/x-patch Size: 2647 bytes Desc: not available URL: From tbabej at redhat.com Wed Oct 30 15:18:16 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 30 Oct 2013 16:18:16 +0100 Subject: [Freeipa-devel] [PATCH 0125] ipatests: Add which package to legacy client advice Message-ID: <52712338.2030509@redhat.com> Hi, Adds which package to the requirements, since older distros do not have it by default. Part of: https://fedorahosted.org/freeipa/ticket/3833 -- 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-0125-ipatests-Add-which-package-to-legacy-client-advice-r.patch Type: text/x-patch Size: 2787 bytes Desc: not available URL: From tbabej at redhat.com Wed Oct 30 15:19:13 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 30 Oct 2013 16:19:13 +0100 Subject: [Freeipa-devel] [PATCH 0126] ipatests: Restore SELinux context after restoring files from Message-ID: <52712371.5070803@redhat.com> Hi, Without this patch, restored directories get home_t SELinux context. Part of: https://fedorahosted.org/freeipa/ticket/3833 -- 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-0126-ipatests-Restore-SELinux-context-after-restoring-fil.patch Type: text/x-patch Size: 1621 bytes Desc: not available URL: From tbabej at redhat.com Wed Oct 30 15:40:45 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 30 Oct 2013 16:40:45 +0100 Subject: [Freeipa-devel] [PATCH 0124] ipatests: Extend clear_sssd_cache to support non-systemd Message-ID: <5271287D.2080304@redhat.com> Hi, This allows us to clean sssd cache on older, non-systemd platforms. Part of: https://fedorahosted.org/freeipa/ticket/3833 -- 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-0124-ipatests-Extend-clear_sssd_cache-to-support-non-syst.patch Type: text/x-patch Size: 1821 bytes Desc: not available URL: From sbose at redhat.com Wed Oct 30 16:30:53 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 30 Oct 2013 17:30:53 +0100 Subject: [Freeipa-devel] [PATCH] trust-add/del: send a signal to SSSD to reset timeouts Message-ID: <20131030163053.GW2783@localhost.localdomain> Hi, this patch is mostly intended to make automated testing easier. Since SSSD uses a timeout before the list of known trusted domains is read again users and groups from a new trust might not be available immediately. With this patch a signal to rest the timeout is send to SSSD running on the host where the ipa command to add the trust is called if the caller is root. Currently SSSD does not provider a better interface for this task, the alternative would be a restart which might be a bit disruptive. Fixes https://fedorahosted.org/freeipa/ticket/4006 , related to https://fedorahosted.org/sssd/ticket/2030 . bye, Sumit -------------- next part -------------- From 5686769945db285d06b9fec8deee1bc1bdf0cebc Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 29 Oct 2013 11:34:56 +0100 Subject: [PATCH] trust-add/del: send a signal to SSSD to reset timeouts SSSD uses some timeouts when looking up new domains. If the timeout is not expired a newly added trusted domain will not be resolved immediately. This might be irritating for an admin and might lead to unexpected failures during testing. With this patch a SIGUSR2 signal which will reset the timeouts is send to SSSD when a trusted domain is added or deleted. Since SSSD is running as root this currently only works if the ipa command is called as root as well. Future version of SSSD will provide better interfaces for this kind of tasks. Fixes https://fedorahosted.org/freeipa/ticket/4006 --- ipalib/plugins/trust.py | 33 ++++++++++++++++++++++++++++++++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 32a93834394273c9f896ff5fd17bfcc753fe7b8e..d39e6b68ba0119f734e30e2c4cc83635dd6bd43f 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -20,12 +20,13 @@ from ipalib.plugins.baseldap import * from ipalib.plugins.dns import dns_container_exists -from ipapython.ipautil import realm_to_suffix +from ipapython.ipautil import realm_to_suffix, run from ipalib import api, Str, StrEnum, Password, _, ngettext from ipalib import Command from ipalib import errors from ldap import SCOPE_SUBTREE from time import sleep +from os import geteuid try: import pysss_murmur #pylint: disable=F0401 @@ -188,6 +189,15 @@ def make_trust_dn(env, trust_type, dn): return DN(dn, container_dn) return dn +def send_usr2_to_sssd(): + """ + If running as root send SIGUSR2 to SSSD to reset the domain lookup related + timeouts. This will allow the local SSSD instance e.g. to get the users + from a newly created trust immediately. + """ + if geteuid()==0: + run(["/bin/pkill", "-USR2", "sssd"]) + class trust(LDAPObject): """ Trust object. @@ -728,11 +738,19 @@ sides. raise errors.ValidationError(name=_('AD Trust setup'), error=_('Not enough arguments specified to perform trust setup')) + def forward(self, *args, **kw): + send_usr2_to_sssd() + return self.api.Backend.xmlclient.forward(self.name, *args, **kw) + class trust_del(LDAPDelete): __doc__ = _('Delete a trust.') msg_summary = _('Deleted trust "%(value)s"') + def forward(self, *args, **kw): + send_usr2_to_sssd() + return self.api.Backend.xmlclient.forward(self.name, *args, **kw) + class trust_mod(LDAPUpdate): __doc__ = _(""" Modify a trust (for future use). @@ -1196,6 +1214,11 @@ class trustdomain_add(LDAPCreate): if 'ipanttrustpartner' in options: entry_attrs['ipanttrustpartner'] = [options['ipanttrustpartner']] return dn + + def forward(self, *args, **kw): + send_usr2_to_sssd() + return self.api.Backend.xmlclient.forward(self.name, *args, **kw) + api.register(trustdomain_add) class trustdomain_del(LDAPDelete): @@ -1219,6 +1242,10 @@ class trustdomain_del(LDAPDelete): result['value'] = u','.join(keys[1]) return result + def forward(self, *args, **kw): + send_usr2_to_sssd() + return self.api.Backend.xmlclient.forward(self.name, *args, **kw) + api.register(trustdomain_del) @@ -1290,6 +1317,10 @@ class trust_fetch_domains(LDAPRetrieve): result['truncated'] = False return result + def forward(self, *args, **kw): + send_usr2_to_sssd() + return self.api.Backend.xmlclient.forward(self.name, *args, **kw) + api.register(trust_fetch_domains) class trustdomain_enable(LDAPQuery): -- 1.8.1.4 From mkosek at redhat.com Wed Oct 30 17:00:37 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 30 Oct 2013 18:00:37 +0100 Subject: [Freeipa-devel] [PATCH] 436 Remove ipa-pwd-extop and ipa-enrollment duplicate error messages In-Reply-To: <52711EB0.80304@redhat.com> References: <526FE7CD.6000704@redhat.com> <52711EB0.80304@redhat.com> Message-ID: <52713B35.6090108@redhat.com> On 10/30/2013 03:58 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> Some error strings were duplicate which makes it then harder to >> see what is the real root cause of it. >> >> https://fedorahosted.org/freeipa/ticket/3988 >> >> --- >> >> I tried to leave the most general error messages as is (entry not found) and >> only specify the rare ones -> test suite is still passing. >> >> Martin >> > > ACK if you drop the str(e) of the exceptions. > > rob Fixed and pushed to master, ipa-3-3. Martin From akrivoka at redhat.com Wed Oct 30 18:01:27 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 30 Oct 2013 19:01:27 +0100 Subject: [Freeipa-devel] [PATCHES] 0080-0081 Add userClass attributes for users and hosts In-Reply-To: <1383051873.2826.13.camel@willson.li.ssimo.org> References: <526F84AA.3090004@redhat.com> <526F9F17.6090702@redhat.com> <1383051873.2826.13.camel@willson.li.ssimo.org> Message-ID: <52714977.8010101@redhat.com> On 10/29/2013 02:04 PM, Simo Sorce wrote: > On Tue, 2013-10-29 at 12:42 +0100, Martin Kosek wrote: >> On 10/29/2013 10:49 AM, Ana Krivokapic wrote: >>> Hello, >>> >>> Patch 0080 adds userClass attribute for users to IPA CLI. >>> Patch 0081 adds userClass attribute for users and hosts to the web UI. >>> >>> Design page: >>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >>> >>> Tickets: >>> https://fedorahosted.org/freeipa/ticket/3588 >>> https://fedorahosted.org/freeipa/ticket/3590 >> NACK to just extending posixAccount objectclass. This is a standard objectclass >> defined by RFC 2307 and we cannot just simply extend and overwrite it as we wish. > Uhh indeed this is a big No-no. > >> We will need to come up with some custom objectclass, like ipaUser. This is the >> reason why I wrote to ticket "A second goal of this ticket is to review current >> objectClass hierarchy of users and do changes if needed." so that we can pick >> the best option where to place it. > userClass is used in ipaHost, so I guess it could be instead add to an > ipa objectclass. ipaObject might be used perhaps, otherwise we'll need a > new ipaUser objectlass. > > Simo. > If there are no objections to using the ipaObject objectclass, the attached patches implement this approach. Also, the schema change has been added to the appropriate .ldif file, and the addeer dialogs in the web UI have been extended to support the new userclass attribute. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0081-02-WebUI-Add-userClass-attribute-to-user-and-host-pages.patch Type: text/x-patch Size: 2223 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0080-02-Add-userClass-attribute-for-users.patch Type: text/x-patch Size: 11950 bytes Desc: not available URL: From Roger.Vaede at fincen.gov Wed Oct 30 18:05:44 2013 From: Roger.Vaede at fincen.gov (Vaede, Roger (Contractor)) Date: Wed, 30 Oct 2013 18:05:44 +0000 Subject: [Freeipa-devel] certificate renewal Message-ID: <647D6B6B44F7C046AFE8E069C0CF70FC284FB772@hqexdb01.hqfincen.gov> I have two IPA servers, one primary and one is backup. (Redhat 5) The primary servers certificate has expired. I am not able to renew it. I turned off the ssl on the clients and now the users can login. I did a lot of research on certificate renewal and I am lost at this point. I am able to make changes using the backup IPA server. [root at xxxxx01 ~]# ipa-getcert list Number of certificates and requests being tracked: 3. Request ID '20131023184633': status: CA_UNCONFIGURED ca-error: Unable to determine principal name for signing request. stuck: yes key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='/usr/share/ipa/html/ca.crt',token='NSS Certificate DB' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='/usr/share/ipa/html/ca.crt' CA: IPA issuer: subject: expires: unknown track: yes auto-renew: yes Request ID '20131023184901': status: CA_UNCONFIGURED ca-error: Unable to determine principal name for signing request. stuck: yes key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='/etc/httpd/conf/ssl.crt/hqfincen_root_ca.cer',token='NSS Certifica te DB' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='/etc/httpd/conf/ssl.crt/xxxxxx_root_ca.cer' CA: IPA issuer: subject: expires: unknown track: yes auto-renew: yes Request ID '20131021155935': status: NEED_KEY_GEN_PIN stuck: yes key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ServerCert' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ServerCert' CA: IPA issuer: subject: expires: unknown track: yes auto-renew: yes -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Oct 30 18:11:20 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 30 Oct 2013 14:11:20 -0400 Subject: [Freeipa-devel] [PATCHES] 0080-0081 Add userClass attributes for users and hosts In-Reply-To: <52714977.8010101@redhat.com> References: <526F84AA.3090004@redhat.com> <526F9F17.6090702@redhat.com> <1383051873.2826.13.camel@willson.li.ssimo.org> <52714977.8010101@redhat.com> Message-ID: <1383156680.8612.22.camel@willson.li.ssimo.org> On Wed, 2013-10-30 at 19:01 +0100, Ana Krivokapic wrote: > On 10/29/2013 02:04 PM, Simo Sorce wrote: > > On Tue, 2013-10-29 at 12:42 +0100, Martin Kosek wrote: > >> On 10/29/2013 10:49 AM, Ana Krivokapic wrote: > >>> Hello, > >>> > >>> Patch 0080 adds userClass attribute for users to IPA CLI. > >>> Patch 0081 adds userClass attribute for users and hosts to the web UI. > >>> > >>> Design page: > >>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems > >>> > >>> Tickets: > >>> https://fedorahosted.org/freeipa/ticket/3588 > >>> https://fedorahosted.org/freeipa/ticket/3590 > >> NACK to just extending posixAccount objectclass. This is a standard objectclass > >> defined by RFC 2307 and we cannot just simply extend and overwrite it as we wish. > > Uhh indeed this is a big No-no. > > > >> We will need to come up with some custom objectclass, like ipaUser. This is the > >> reason why I wrote to ticket "A second goal of this ticket is to review current > >> objectClass hierarchy of users and do changes if needed." so that we can pick > >> the best option where to place it. > > userClass is used in ipaHost, so I guess it could be instead add to an > > ipa objectclass. ipaObject might be used perhaps, otherwise we'll need a > > new ipaUser objectlass. > > > > Simo. > > > > If there are no objections to using the ipaObject objectclass, the attached > patches implement this approach. After some thinking ipaObject is more generic than just users, not sure that attaching userClass there is appropriate. I think we really need ipaUser at this point. > Also, the schema change has been added to the appropriate .ldif file, and the > addeer dialogs in the web UI have been extended to support the new userclass > attribute. good. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Oct 30 18:30:20 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 30 Oct 2013 14:30:20 -0400 Subject: [Freeipa-devel] certificate renewal In-Reply-To: <647D6B6B44F7C046AFE8E069C0CF70FC284FB772@hqexdb01.hqfincen.gov> References: <647D6B6B44F7C046AFE8E069C0CF70FC284FB772@hqexdb01.hqfincen.gov> Message-ID: <5271503C.9020207@redhat.com> Vaede, Roger (Contractor) wrote: > I have two IPA servers, one primary and one is backup. (Redhat 5) What version of ipa-server is this? > The primary servers certificate has expired. > > I am not able to renew it. > > I turned off the ssl on the clients and now the users can login. > > I did a lot of research on certificate renewal and I am lost at this point. > > I am able to make changes using the backup IPA server. This getcert output is quite strange. Did you start these tracking yourself? Did you replace the IPA CA certificate at some point? rob From Roger.Vaede at fincen.gov Wed Oct 30 18:32:17 2013 From: Roger.Vaede at fincen.gov (Vaede, Roger (Contractor)) Date: Wed, 30 Oct 2013 18:32:17 +0000 Subject: [Freeipa-devel] certificate renewal In-Reply-To: <5271503C.9020207@redhat.com> References: <647D6B6B44F7C046AFE8E069C0CF70FC284FB772@hqexdb01.hqfincen.gov> <5271503C.9020207@redhat.com> Message-ID: <647D6B6B44F7C046AFE8E069C0CF70FC284FB7A4@hqexdb01.hqfincen.gov> Its freeipa-2.1.1 Regards Roger -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Wednesday, October 30, 2013 2:30 PM To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' Subject: Re: [Freeipa-devel] certificate renewal Vaede, Roger (Contractor) wrote: > I have two IPA servers, one primary and one is backup. (Redhat 5) What version of ipa-server is this? > The primary servers certificate has expired. > > I am not able to renew it. > > I turned off the ssl on the clients and now the users can login. > > I did a lot of research on certificate renewal and I am lost at this point. > > I am able to make changes using the backup IPA server. This getcert output is quite strange. Did you start these tracking yourself? Did you replace the IPA CA certificate at some point? rob From Roger.Vaede at fincen.gov Wed Oct 30 18:36:56 2013 From: Roger.Vaede at fincen.gov (Vaede, Roger (Contractor)) Date: Wed, 30 Oct 2013 18:36:56 +0000 Subject: [Freeipa-devel] certificate renewal In-Reply-To: <5271503C.9020207@redhat.com> References: <647D6B6B44F7C046AFE8E069C0CF70FC284FB772@hqexdb01.hqfincen.gov> <5271503C.9020207@redhat.com> Message-ID: <647D6B6B44F7C046AFE8E069C0CF70FC284FB7AE@hqexdb01.hqfincen.gov> I never installed freeipa, the person that installed it left the company. I removed the request ID at one point by using the stop-tracking command then I used this command to reinstate them: ipa-getcert start-tracking -d /var/lib/pki-ca/alias -n ServerCert -r Initially they expired around October 25th. Regards Roger -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Wednesday, October 30, 2013 2:30 PM To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' Subject: Re: [Freeipa-devel] certificate renewal Vaede, Roger (Contractor) wrote: > I have two IPA servers, one primary and one is backup. (Redhat 5) What version of ipa-server is this? > The primary servers certificate has expired. > > I am not able to renew it. > > I turned off the ssl on the clients and now the users can login. > > I did a lot of research on certificate renewal and I am lost at this point. > > I am able to make changes using the backup IPA server. This getcert output is quite strange. Did you start these tracking yourself? Did you replace the IPA CA certificate at some point? rob From Roger.Vaede at fincen.gov Wed Oct 30 18:56:28 2013 From: Roger.Vaede at fincen.gov (Vaede, Roger (Contractor)) Date: Wed, 30 Oct 2013 18:56:28 +0000 Subject: [Freeipa-devel] certificate renewal In-Reply-To: <647D6B6B44F7C046AFE8E069C0CF70FC284FB7AE@hqexdb01.hqfincen.gov> References: <647D6B6B44F7C046AFE8E069C0CF70FC284FB772@hqexdb01.hqfincen.gov> <5271503C.9020207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7AE@hqexdb01.hqfincen.gov> Message-ID: <647D6B6B44F7C046AFE8E069C0CF70FC284FB7CF@hqexdb01.hqfincen.gov> I did try to replace the certificate with a self signed one at one point but then I was getting an error saying the certificate wasn't valid. Regards Roger -----Original Message----- From: Vaede, Roger (Contractor) Sent: Wednesday, October 30, 2013 2:37 PM To: 'Rob Crittenden'; 'freeipa-devel at redhat.com' Subject: RE: [Freeipa-devel] certificate renewal I never installed freeipa, the person that installed it left the company. I removed the request ID at one point by using the stop-tracking command then I used this command to reinstate them: ipa-getcert start-tracking -d /var/lib/pki-ca/alias -n ServerCert -r Initially they expired around October 25th. Regards Roger -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Wednesday, October 30, 2013 2:30 PM To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' Subject: Re: [Freeipa-devel] certificate renewal Vaede, Roger (Contractor) wrote: > I have two IPA servers, one primary and one is backup. (Redhat 5) What version of ipa-server is this? > The primary servers certificate has expired. > > I am not able to renew it. > > I turned off the ssl on the clients and now the users can login. > > I did a lot of research on certificate renewal and I am lost at this point. > > I am able to make changes using the backup IPA server. This getcert output is quite strange. Did you start these tracking yourself? Did you replace the IPA CA certificate at some point? rob From rcritten at redhat.com Wed Oct 30 19:29:18 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 30 Oct 2013 15:29:18 -0400 Subject: [Freeipa-devel] certificate renewal In-Reply-To: <647D6B6B44F7C046AFE8E069C0CF70FC284FB7CF@hqexdb01.hqfincen.gov> References: <647D6B6B44F7C046AFE8E069C0CF70FC284FB772@hqexdb01.hqfincen.gov> <5271503C.9020207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7AE@hqexdb01.hqfincen.gov> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7CF@hqexdb01.hqfincen.gov> Message-ID: <52715E0E.5090207@redhat.com> Vaede, Roger (Contractor) wrote: > I did try to replace the certificate with a self signed one at one point but then I was getting an error saying the certificate wasn't valid. Ok, I need to get a better handle on how this was originally installed in order to guide you. Can you look to see if /var/log/ipaserver-install.log still exists? It should have the original arguments passed. What I need to know is if this was installed using a dogtag CA or if it was installed as a selfsign server. rob > > Regards > Roger > > -----Original Message----- > From: Vaede, Roger (Contractor) > Sent: Wednesday, October 30, 2013 2:37 PM > To: 'Rob Crittenden'; 'freeipa-devel at redhat.com' > Subject: RE: [Freeipa-devel] certificate renewal > > I never installed freeipa, the person that installed it left the company. > I removed the request ID at one point by using the stop-tracking command then I used this command to reinstate them: > ipa-getcert start-tracking -d /var/lib/pki-ca/alias -n ServerCert -r > > Initially they expired around October 25th. > > Regards > Roger > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Wednesday, October 30, 2013 2:30 PM > To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' > Subject: Re: [Freeipa-devel] certificate renewal > > Vaede, Roger (Contractor) wrote: >> I have two IPA servers, one primary and one is backup. (Redhat 5) > > What version of ipa-server is this? > >> The primary servers certificate has expired. >> >> I am not able to renew it. >> >> I turned off the ssl on the clients and now the users can login. >> >> I did a lot of research on certificate renewal and I am lost at this point. >> >> I am able to make changes using the backup IPA server. > > This getcert output is quite strange. Did you start these tracking yourself? > > Did you replace the IPA CA certificate at some point? > > rob > > From Roger.Vaede at fincen.gov Wed Oct 30 19:40:16 2013 From: Roger.Vaede at fincen.gov (Vaede, Roger (Contractor)) Date: Wed, 30 Oct 2013 19:40:16 +0000 Subject: [Freeipa-devel] certificate renewal In-Reply-To: <52715E0E.5090207@redhat.com> References: <647D6B6B44F7C046AFE8E069C0CF70FC284FB772@hqexdb01.hqfincen.gov> <5271503C.9020207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7AE@hqexdb01.hqfincen.gov> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7CF@hqexdb01.hqfincen.gov> <52715E0E.5090207@redhat.com> Message-ID: <647D6B6B44F7C046AFE8E069C0CF70FC284FB80C@hqexdb01.hqfincen.gov> The certificate that I tried to install was a self signed certificate. Here is the contents of the file: /var/log/ipaserver-install.log 2013-10-21 11:42:44,031 DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2013-10-21 11:42:44,032 DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2013-10-21 11:42:44,032 DEBUG httpd is configured 2013-10-21 11:42:44,032 DEBUG ipa_kpasswd is configured 2013-10-21 11:42:44,032 DEBUG dirsrv is configured 2013-10-21 11:42:44,033 DEBUG pki-cad is configured 2013-10-21 11:42:44,033 DEBUG pkids is configured 2013-10-21 11:42:44,033 DEBUG install is configured 2013-10-21 11:42:44,033 DEBUG krb5kdc is configured 2013-10-21 11:42:44,033 DEBUG ntpd is not configured 2013-10-21 11:42:44,033 DEBUG named is not configured 2013-10-21 11:42:44,033 DEBUG filestore has files The (good) backup server here is the contents of the certificate: [root at xxxxx ~]# ipa-getcert list Number of certificates and requests being tracked: 2. Request ID '20111020180721': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-xxx ',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxx-xxx//pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-xx',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=xxxxxx.xxx subject: CN=xxxxxxx.xxxxxx.xxx,O=xxxxxxx.xx expires: 2015-09-23 17:46:26 UTC eku: id-kp-serverAuth,id-kp-clientAuth command: track: yes auto-renew: yes Request ID '20111020180816': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=xxxxxx.xxx subject: CN=xxxxxx.xxxx.xxx,O=xxxxxxx.xxx expires: 2015-09-23 17:46:26 UTC eku: id-kp-serverAuth,id-kp-clientAuth command: track: yes auto-renew: yes regards Roger -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Wednesday, October 30, 2013 3:29 PM To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' Subject: Re: [Freeipa-devel] certificate renewal Vaede, Roger (Contractor) wrote: > I did try to replace the certificate with a self signed one at one point but then I was getting an error saying the certificate wasn't valid. Ok, I need to get a better handle on how this was originally installed in order to guide you. Can you look to see if /var/log/ipaserver-install.log still exists? It should have the original arguments passed. What I need to know is if this was installed using a dogtag CA or if it was installed as a selfsign server. rob > > Regards > Roger > > -----Original Message----- > From: Vaede, Roger (Contractor) > Sent: Wednesday, October 30, 2013 2:37 PM > To: 'Rob Crittenden'; 'freeipa-devel at redhat.com' > Subject: RE: [Freeipa-devel] certificate renewal > > I never installed freeipa, the person that installed it left the company. > I removed the request ID at one point by using the stop-tracking command then I used this command to reinstate them: > ipa-getcert start-tracking -d /var/lib/pki-ca/alias -n ServerCert -r > > Initially they expired around October 25th. > > Regards > Roger > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Wednesday, October 30, 2013 2:30 PM > To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' > Subject: Re: [Freeipa-devel] certificate renewal > > Vaede, Roger (Contractor) wrote: >> I have two IPA servers, one primary and one is backup. (Redhat 5) > > What version of ipa-server is this? > >> The primary servers certificate has expired. >> >> I am not able to renew it. >> >> I turned off the ssl on the clients and now the users can login. >> >> I did a lot of research on certificate renewal and I am lost at this point. >> >> I am able to make changes using the backup IPA server. > > This getcert output is quite strange. Did you start these tracking yourself? > > Did you replace the IPA CA certificate at some point? > > rob > > From rcritten at redhat.com Wed Oct 30 20:28:38 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 30 Oct 2013 16:28:38 -0400 Subject: [Freeipa-devel] certificate renewal In-Reply-To: <647D6B6B44F7C046AFE8E069C0CF70FC284FB80C@hqexdb01.hqfincen.gov> References: <647D6B6B44F7C046AFE8E069C0CF70FC284FB772@hqexdb01.hqfincen.gov> <5271503C.9020207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7AE@hqexdb01.hqfincen.gov> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7CF@hqexdb01.hqfincen.gov> <52715E0E.5090207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB80C@hqexdb01.hqfincen.gov> Message-ID: <52716BF6.1060607@redhat.com> Vaede, Roger (Contractor) wrote: > The certificate that I tried to install was a self signed certificate. > Here is the contents of the file: /var/log/ipaserver-install.log > > 2013-10-21 11:42:44,031 DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' > 2013-10-21 11:42:44,032 DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' > 2013-10-21 11:42:44,032 DEBUG httpd is configured > 2013-10-21 11:42:44,032 DEBUG ipa_kpasswd is configured > 2013-10-21 11:42:44,032 DEBUG dirsrv is configured > 2013-10-21 11:42:44,033 DEBUG pki-cad is configured > 2013-10-21 11:42:44,033 DEBUG pkids is configured > 2013-10-21 11:42:44,033 DEBUG install is configured > 2013-10-21 11:42:44,033 DEBUG krb5kdc is configured > 2013-10-21 11:42:44,033 DEBUG ntpd is not configured > 2013-10-21 11:42:44,033 DEBUG named is not configured > 2013-10-21 11:42:44,033 DEBUG filestore has files Ok, you have a dogtag CA. We didn't add support for automated renewal until IPA 3.0. We need to see the state of the CA itself, its subsystem certificates. To get the list of nicknames: # certutil -L -d /var/lib/pki-ca/alias Then for each one do: # certutil -L -n -d /var/lib/pki-ca/alias | grep Not You don't need to post this necessarily, just look to see if they are already expired. Like I said, we didn't tackle renewal until IPA 3.0. This required some work in certmonger as well as some changes within IPA. I don't know if the same procedures will work against an IPA 2 server. The bulk of the work is done by certmonger. But first, see what the state of the CA and its subsystem certificates are, then we can see what we need to renew. rob > > > The (good) backup server here is the contents of the certificate: > > [root at xxxxx ~]# ipa-getcert list > Number of certificates and requests being tracked: 2. > Request ID '20111020180721': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-xxx ',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxx-xxx//pwdfile.txt' > certificate: type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-xx',nickname='Server-Cert',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxxx.xxx > subject: CN=xxxxxxx.xxxxxx.xxx,O=xxxxxxx.xx > expires: 2015-09-23 17:46:26 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > command: > track: yes > auto-renew: yes > Request ID '20111020180816': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxxx.xxx > subject: CN=xxxxxx.xxxx.xxx,O=xxxxxxx.xxx > expires: 2015-09-23 17:46:26 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > command: > track: yes > auto-renew: yes > > regards > Roger > > > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Wednesday, October 30, 2013 3:29 PM > To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' > Subject: Re: [Freeipa-devel] certificate renewal > > Vaede, Roger (Contractor) wrote: >> I did try to replace the certificate with a self signed one at one point but then I was getting an error saying the certificate wasn't valid. > > Ok, I need to get a better handle on how this was originally installed in order to guide you. Can you look to see if /var/log/ipaserver-install.log still exists? It should have the original arguments passed. > > What I need to know is if this was installed using a dogtag CA or if it was installed as a selfsign server. > > rob > >> >> Regards >> Roger >> >> -----Original Message----- >> From: Vaede, Roger (Contractor) >> Sent: Wednesday, October 30, 2013 2:37 PM >> To: 'Rob Crittenden'; 'freeipa-devel at redhat.com' >> Subject: RE: [Freeipa-devel] certificate renewal >> >> I never installed freeipa, the person that installed it left the company. >> I removed the request ID at one point by using the stop-tracking command then I used this command to reinstate them: >> ipa-getcert start-tracking -d /var/lib/pki-ca/alias -n ServerCert -r >> >> Initially they expired around October 25th. >> >> Regards >> Roger >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Wednesday, October 30, 2013 2:30 PM >> To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' >> Subject: Re: [Freeipa-devel] certificate renewal >> >> Vaede, Roger (Contractor) wrote: >>> I have two IPA servers, one primary and one is backup. (Redhat 5) >> >> What version of ipa-server is this? >> >>> The primary servers certificate has expired. >>> >>> I am not able to renew it. >>> >>> I turned off the ssl on the clients and now the users can login. >>> >>> I did a lot of research on certificate renewal and I am lost at this point. >>> >>> I am able to make changes using the backup IPA server. >> >> This getcert output is quite strange. Did you start these tracking yourself? >> >> Did you replace the IPA CA certificate at some point? >> >> rob >> >> > > From Roger.Vaede at fincen.gov Wed Oct 30 20:37:45 2013 From: Roger.Vaede at fincen.gov (Vaede, Roger (Contractor)) Date: Wed, 30 Oct 2013 20:37:45 +0000 Subject: [Freeipa-devel] certificate renewal In-Reply-To: <52716BF6.1060607@redhat.com> References: <647D6B6B44F7C046AFE8E069C0CF70FC284FB772@hqexdb01.hqfincen.gov> <5271503C.9020207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7AE@hqexdb01.hqfincen.gov> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7CF@hqexdb01.hqfincen.gov> <52715E0E.5090207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB80C@hqexdb01.hqfincen.gov> <52716BF6.1060607@redhat.com> Message-ID: <647D6B6B44F7C046AFE8E069C0CF70FC284FB848@hqexdb01.hqfincen.gov> Everyone of the nicknames have expired except for this one: certutil -L -n "caSigningCert cert-pki-ca" -d /var/lib/pki-ca/alias | grep Not Not Before: Thu Oct 20 11:44:18 2011 Not After : Sun Oct 20 11:44:18 2019 Regards Roger -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Wednesday, October 30, 2013 4:29 PM To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' Subject: Re: [Freeipa-devel] certificate renewal Vaede, Roger (Contractor) wrote: > The certificate that I tried to install was a self signed certificate. > Here is the contents of the file: /var/log/ipaserver-install.log > > 2013-10-21 11:42:44,031 DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' > 2013-10-21 11:42:44,032 DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' > 2013-10-21 11:42:44,032 DEBUG httpd is configured > 2013-10-21 11:42:44,032 DEBUG ipa_kpasswd is configured > 2013-10-21 11:42:44,032 DEBUG dirsrv is configured > 2013-10-21 11:42:44,033 DEBUG pki-cad is configured > 2013-10-21 11:42:44,033 DEBUG pkids is configured > 2013-10-21 11:42:44,033 DEBUG install is configured > 2013-10-21 11:42:44,033 DEBUG krb5kdc is configured > 2013-10-21 11:42:44,033 DEBUG ntpd is not configured > 2013-10-21 11:42:44,033 DEBUG named is not configured > 2013-10-21 11:42:44,033 DEBUG filestore has files Ok, you have a dogtag CA. We didn't add support for automated renewal until IPA 3.0. We need to see the state of the CA itself, its subsystem certificates. To get the list of nicknames: # certutil -L -d /var/lib/pki-ca/alias Then for each one do: # certutil -L -n -d /var/lib/pki-ca/alias | grep Not You don't need to post this necessarily, just look to see if they are already expired. Like I said, we didn't tackle renewal until IPA 3.0. This required some work in certmonger as well as some changes within IPA. I don't know if the same procedures will work against an IPA 2 server. The bulk of the work is done by certmonger. But first, see what the state of the CA and its subsystem certificates are, then we can see what we need to renew. rob > > > The (good) backup server here is the contents of the certificate: > > [root at xxxxx ~]# ipa-getcert list > Number of certificates and requests being tracked: 2. > Request ID '20111020180721': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-xxx ',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxx-xxx//pwdfile.txt' > certificate: type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-xx',nickname='Server-Cert',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxxx.xxx > subject: CN=xxxxxxx.xxxxxx.xxx,O=xxxxxxx.xx > expires: 2015-09-23 17:46:26 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > command: > track: yes > auto-renew: yes > Request ID '20111020180816': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxxx.xxx > subject: CN=xxxxxx.xxxx.xxx,O=xxxxxxx.xxx > expires: 2015-09-23 17:46:26 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > command: > track: yes > auto-renew: yes > > regards > Roger > > > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Wednesday, October 30, 2013 3:29 PM > To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' > Subject: Re: [Freeipa-devel] certificate renewal > > Vaede, Roger (Contractor) wrote: >> I did try to replace the certificate with a self signed one at one point but then I was getting an error saying the certificate wasn't valid. > > Ok, I need to get a better handle on how this was originally installed in order to guide you. Can you look to see if /var/log/ipaserver-install.log still exists? It should have the original arguments passed. > > What I need to know is if this was installed using a dogtag CA or if it was installed as a selfsign server. > > rob > >> >> Regards >> Roger >> >> -----Original Message----- >> From: Vaede, Roger (Contractor) >> Sent: Wednesday, October 30, 2013 2:37 PM >> To: 'Rob Crittenden'; 'freeipa-devel at redhat.com' >> Subject: RE: [Freeipa-devel] certificate renewal >> >> I never installed freeipa, the person that installed it left the company. >> I removed the request ID at one point by using the stop-tracking command then I used this command to reinstate them: >> ipa-getcert start-tracking -d /var/lib/pki-ca/alias -n ServerCert >> -r >> >> Initially they expired around October 25th. >> >> Regards >> Roger >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Wednesday, October 30, 2013 2:30 PM >> To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' >> Subject: Re: [Freeipa-devel] certificate renewal >> >> Vaede, Roger (Contractor) wrote: >>> I have two IPA servers, one primary and one is backup. (Redhat 5) >> >> What version of ipa-server is this? >> >>> The primary servers certificate has expired. >>> >>> I am not able to renew it. >>> >>> I turned off the ssl on the clients and now the users can login. >>> >>> I did a lot of research on certificate renewal and I am lost at this point. >>> >>> I am able to make changes using the backup IPA server. >> >> This getcert output is quite strange. Did you start these tracking yourself? >> >> Did you replace the IPA CA certificate at some point? >> >> rob >> >> > > From Roger.Vaede at fincen.gov Wed Oct 30 20:43:02 2013 From: Roger.Vaede at fincen.gov (Vaede, Roger (Contractor)) Date: Wed, 30 Oct 2013 20:43:02 +0000 Subject: [Freeipa-devel] certificate renewal In-Reply-To: <647D6B6B44F7C046AFE8E069C0CF70FC284FB848@hqexdb01.hqfincen.gov> References: <647D6B6B44F7C046AFE8E069C0CF70FC284FB772@hqexdb01.hqfincen.gov> <5271503C.9020207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7AE@hqexdb01.hqfincen.gov> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7CF@hqexdb01.hqfincen.gov> <52715E0E.5090207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB80C@hqexdb01.hqfincen.gov> <52716BF6.1060607@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB848@hqexdb01.hqfincen.gov> Message-ID: <647D6B6B44F7C046AFE8E069C0CF70FC284FB851@hqexdb01.hqfincen.gov> There are two location of the alias: In the backup: /etc/httpd/alias/ In the one that has expired: /var/lib/pki-ca/alias Regards Roger -----Original Message----- From: Vaede, Roger (Contractor) Sent: Wednesday, October 30, 2013 4:38 PM To: 'Rob Crittenden'; 'freeipa-devel at redhat.com' Subject: RE: [Freeipa-devel] certificate renewal Everyone of the nicknames have expired except for this one: certutil -L -n "caSigningCert cert-pki-ca" -d /var/lib/pki-ca/alias | grep Not Not Before: Thu Oct 20 11:44:18 2011 Not After : Sun Oct 20 11:44:18 2019 Regards Roger -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Wednesday, October 30, 2013 4:29 PM To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' Subject: Re: [Freeipa-devel] certificate renewal Vaede, Roger (Contractor) wrote: > The certificate that I tried to install was a self signed certificate. > Here is the contents of the file: /var/log/ipaserver-install.log > > 2013-10-21 11:42:44,031 DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' > 2013-10-21 11:42:44,032 DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' > 2013-10-21 11:42:44,032 DEBUG httpd is configured > 2013-10-21 11:42:44,032 DEBUG ipa_kpasswd is configured > 2013-10-21 11:42:44,032 DEBUG dirsrv is configured > 2013-10-21 11:42:44,033 DEBUG pki-cad is configured > 2013-10-21 11:42:44,033 DEBUG pkids is configured > 2013-10-21 11:42:44,033 DEBUG install is configured > 2013-10-21 11:42:44,033 DEBUG krb5kdc is configured > 2013-10-21 11:42:44,033 DEBUG ntpd is not configured > 2013-10-21 11:42:44,033 DEBUG named is not configured > 2013-10-21 11:42:44,033 DEBUG filestore has files Ok, you have a dogtag CA. We didn't add support for automated renewal until IPA 3.0. We need to see the state of the CA itself, its subsystem certificates. To get the list of nicknames: # certutil -L -d /var/lib/pki-ca/alias Then for each one do: # certutil -L -n -d /var/lib/pki-ca/alias | grep Not You don't need to post this necessarily, just look to see if they are already expired. Like I said, we didn't tackle renewal until IPA 3.0. This required some work in certmonger as well as some changes within IPA. I don't know if the same procedures will work against an IPA 2 server. The bulk of the work is done by certmonger. But first, see what the state of the CA and its subsystem certificates are, then we can see what we need to renew. rob > > > The (good) backup server here is the contents of the certificate: > > [root at xxxxx ~]# ipa-getcert list > Number of certificates and requests being tracked: 2. > Request ID '20111020180721': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-xxx ',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-xxxxx-xxx//pwdfile.txt' > certificate: type=NSSDB,location='/etc/dirsrv/slapd-xxxxx-xx',nickname='Server-Cert',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxxx.xxx > subject: CN=xxxxxxx.xxxxxx.xxx,O=xxxxxxx.xx > expires: 2015-09-23 17:46:26 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > command: > track: yes > auto-renew: yes > Request ID '20111020180816': > status: MONITORING > stuck: no > key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' > certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=xxxxxx.xxx > subject: CN=xxxxxx.xxxx.xxx,O=xxxxxxx.xxx > expires: 2015-09-23 17:46:26 UTC > eku: id-kp-serverAuth,id-kp-clientAuth > command: > track: yes > auto-renew: yes > > regards > Roger > > > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Wednesday, October 30, 2013 3:29 PM > To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' > Subject: Re: [Freeipa-devel] certificate renewal > > Vaede, Roger (Contractor) wrote: >> I did try to replace the certificate with a self signed one at one point but then I was getting an error saying the certificate wasn't valid. > > Ok, I need to get a better handle on how this was originally installed in order to guide you. Can you look to see if /var/log/ipaserver-install.log still exists? It should have the original arguments passed. > > What I need to know is if this was installed using a dogtag CA or if it was installed as a selfsign server. > > rob > >> >> Regards >> Roger >> >> -----Original Message----- >> From: Vaede, Roger (Contractor) >> Sent: Wednesday, October 30, 2013 2:37 PM >> To: 'Rob Crittenden'; 'freeipa-devel at redhat.com' >> Subject: RE: [Freeipa-devel] certificate renewal >> >> I never installed freeipa, the person that installed it left the company. >> I removed the request ID at one point by using the stop-tracking command then I used this command to reinstate them: >> ipa-getcert start-tracking -d /var/lib/pki-ca/alias -n ServerCert >> -r >> >> Initially they expired around October 25th. >> >> Regards >> Roger >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Wednesday, October 30, 2013 2:30 PM >> To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' >> Subject: Re: [Freeipa-devel] certificate renewal >> >> Vaede, Roger (Contractor) wrote: >>> I have two IPA servers, one primary and one is backup. (Redhat 5) >> >> What version of ipa-server is this? >> >>> The primary servers certificate has expired. >>> >>> I am not able to renew it. >>> >>> I turned off the ssl on the clients and now the users can login. >>> >>> I did a lot of research on certificate renewal and I am lost at this point. >>> >>> I am able to make changes using the backup IPA server. >> >> This getcert output is quite strange. Did you start these tracking yourself? >> >> Did you replace the IPA CA certificate at some point? >> >> rob >> >> > > From mkosek at redhat.com Wed Oct 30 20:56:52 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 30 Oct 2013 16:56:52 -0400 (EDT) Subject: [Freeipa-devel] [PATCHES] 0080-0081 Add userClass attributes for users and hosts In-Reply-To: <1383156680.8612.22.camel@willson.li.ssimo.org> References: <526F84AA.3090004@redhat.com> <526F9F17.6090702@redhat.com> <1383051873.2826.13.camel@willson.li.ssimo.org> <52714977.8010101@redhat.com> <1383156680.8612.22.camel@willson.li.ssimo.org> Message-ID: <680482948.14270903.1383166612061.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Simo Sorce" > To: "Ana Krivokapic" > Cc: "Martin Kosek" , "freeipa-devel" > Sent: Wednesday, October 30, 2013 7:11:20 PM > Subject: Re: [Freeipa-devel] [PATCHES] 0080-0081 Add userClass attributes for users and hosts > > On Wed, 2013-10-30 at 19:01 +0100, Ana Krivokapic wrote: > > On 10/29/2013 02:04 PM, Simo Sorce wrote: > > > On Tue, 2013-10-29 at 12:42 +0100, Martin Kosek wrote: > > >> On 10/29/2013 10:49 AM, Ana Krivokapic wrote: > > >>> Hello, > > >>> > > >>> Patch 0080 adds userClass attribute for users to IPA CLI. > > >>> Patch 0081 adds userClass attribute for users and hosts to the web UI. > > >>> > > >>> Design page: > > >>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems > > >>> > > >>> Tickets: > > >>> https://fedorahosted.org/freeipa/ticket/3588 > > >>> https://fedorahosted.org/freeipa/ticket/3590 > > >> NACK to just extending posixAccount objectclass. This is a standard > > >> objectclass > > >> defined by RFC 2307 and we cannot just simply extend and overwrite it as > > >> we wish. > > > Uhh indeed this is a big No-no. > > > > > >> We will need to come up with some custom objectclass, like ipaUser. This > > >> is the > > >> reason why I wrote to ticket "A second goal of this ticket is to review > > >> current > > >> objectClass hierarchy of users and do changes if needed." so that we can > > >> pick > > >> the best option where to place it. > > > userClass is used in ipaHost, so I guess it could be instead add to an > > > ipa objectclass. ipaObject might be used perhaps, otherwise we'll need a > > > new ipaUser objectlass. > > > > > > Simo. > > > > > > > If there are no objections to using the ipaObject objectclass, the attached > > patches implement this approach. > > After some thinking ipaObject is more generic than just users, not sure > that attaching userClass there is appropriate. I think we really need > ipaUser at this point. +1. I also do not think that ipaObject is the right OC to place the attribute, it is just too general. Let's go with the ipaUser objectClass, looking something like that: ( NAME 'ipaUser' AUXILIARY MUST ( uid ) MAY ( userClass ) X-ORIGIN 'IPA v3' ) We will need to add the OC when needed, we cannot just add it to default list. Ideally, we could also implement https://fedorahosted.org/freeipa/ticket/3922 in scope of this effort as this need to add additional OCs is piling up. Martin From rcritten at redhat.com Wed Oct 30 21:06:58 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 30 Oct 2013 17:06:58 -0400 Subject: [Freeipa-devel] certificate renewal In-Reply-To: <647D6B6B44F7C046AFE8E069C0CF70FC284FB851@hqexdb01.hqfincen.gov> References: <647D6B6B44F7C046AFE8E069C0CF70FC284FB772@hqexdb01.hqfincen.gov> <5271503C.9020207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7AE@hqexdb01.hqfincen.gov> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7CF@hqexdb01.hqfincen.gov> <52715E0E.5090207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB80C@hqexdb01.hqfincen.gov> <52716BF6.1060607@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB848@hqexdb01.hqfincen.gov> <647D6B6B44F7C046AFE8E069C0CF70FC284FB851@hqexdb01.hqfincen.gov> Message-ID: <527174F2.7080200@redhat.com> Vaede, Roger (Contractor) wrote: > There are two location of the alias: > In the backup: /etc/httpd/alias/ > In the one that has expired: /var/lib/pki-ca/alias These are separate entities and will need to be dealt with seprately. /var/lib/pki-ca/alias is the NSS database that contains the certificates for the CA itself. With the subsystem certs being expired it means that the CA itself is basically dead in the water because nothing can talk to it. We're really moving into some uncharted waters here. I don't really want to recommend upgrading to 3.0 just to get the certs renewed, though there are lots of other good reasons to upgrade. I don't know what will happen if we try to renew the certs using the 3.0 method on a 2.x server. So you've got two IPA masters. Are you running the CA on both or only on one? It makes a difference in how we do the renewal because it will be more complex if you have it on both (not a show stopper). I *think* we can use the latest certmonger to do the majority of the heavy lifting. The basic process will be to update those bits, go back in time, the tell it to start tracking the CA certs one by one and get them renewed. We'll need to do the same with some other certs, some of which are in /etc/httpd/alias and some of which are in /etc/dirsrv/slapd-REALM/. If you have another instance of the CA we'll need to extract some of the renewed certs and import them on the other side. Then we return to present time. So let me know what your environment looks like and I'll try to come up with some steps to do the renewal. rob From sbose at redhat.com Wed Oct 30 21:44:51 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 30 Oct 2013 22:44:51 +0100 Subject: [Freeipa-devel] [PATCHES] 122-123 Remove generation and handling of LM hashes In-Reply-To: <527105B7.50900@redhat.com> References: <20131030113441.GO2783@localhost.localdomain> <20131030122833.GJ25335@redhat.com> <527105B7.50900@redhat.com> Message-ID: <20131030214451.GA2783@localhost.localdomain> On Wed, Oct 30, 2013 at 02:12:23PM +0100, Martin Kosek wrote: > On 10/30/2013 01:28 PM, Alexander Bokovoy wrote: > > On Wed, 30 Oct 2013, Sumit Bose wrote: > > > >> Hi, > >> > >> those two patches try to fix > >> https://fedorahosted.org/freeipa/ticket/3795 (Remove LANMAN hash > >> support). The first patch removes to option to enable the support while > >> the second removes all the related C-code. > > ACK on these patches but see below. > > I have few comments on the patches: > > 1) In util/ipa_pwd_ntlm.c, we can now also remove parity_table. > > 2) In util/ipa_pwd_ntlm.c, in encode_ntlm_keys, upperPasswd is no longer needed > (i.e. the UTF upper-casing calls in caller functions are not needed either). I > am thinking we could simplify the function just to: > > int encode_nt_key(char *newPasswd, > uint8_t *ntHash) > > i.e. it seems to me that ntlm_keys structure may not be needed now, since we > removed one item of two in it. keys->lm is not used anywhere anyway. I removed/changed the code as you suggested. New version attached. > > >> Although the ticket is schedule for the 3.3.x bugfix release I'm not > >> sure if it is a good idea to remove the support in a minor release. > >> Since the LM hashes are not enabled by default I would expect that in > >> setups where it is enabled the hashes are needed one way or the other. > >> Those setup should get time to adopt. > > We should add removal of the 'allowlmhash' from the IPA config with > > upgrade plugin. > > Not sure this is the best way. With Sumit's patches, generation of the LM hash > is not stopped despite the configuration. So if someone still needs an old IPA > server where these hashes are used, they are still generated and used there. > > If you remove allowlmhash from the config, once you install a patched IPA > replica, the value would get replicated and old IPA server would not generate > the hashes. We discussed this and came to the conclusion that we might want to add a script which removes existing LM hashes and config entries from the directory tree. This way the admin can decide based on his environment when is the best time to remove them. bye, Sumit > > Martin -------------- next part -------------- From b4d725f527a50bd2b067cc6a88ef51118da1ff30 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 29 Oct 2013 11:37:03 +0100 Subject: [PATCH 122/123] Remove AllowLMhash from the allowed IPA config strings Fixes https://fedorahosted.org/freeipa/ticket/3795 --- API.txt | 2 +- install/ui/src/freeipa/serverconfig.js | 2 +- install/ui/test/data/ipa_init_commands.json | 1 - install/ui/test/data/ipa_init_objects.json | 1 - ipalib/plugins/config.py | 2 +- 5 files changed, 3 insertions(+), 5 deletions(-) diff --git a/API.txt b/API.txt index 40871f6a8b105a7b161df34ce4f6feaf785a6107..605f9ee30b7a945e529dc208c8e719cd04ec3a87 100644 --- a/API.txt +++ b/API.txt @@ -499,7 +499,7 @@ args: 0,24,3 option: Str('addattr*', cli_name='addattr', exclude='webui') option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') option: Str('delattr*', cli_name='delattr', exclude='webui') -option: StrEnum('ipaconfigstring', attribute=True, autofill=False, cli_name='ipaconfigstring', csv=True, multivalue=True, required=False, values=(u'AllowLMhash', u'AllowNThash', u'KDC:Disable Last Success', u'KDC:Disable Lockout')) +option: StrEnum('ipaconfigstring', attribute=True, autofill=False, cli_name='ipaconfigstring', csv=True, multivalue=True, required=False, values=(u'AllowNThash', u'KDC:Disable Last Success', u'KDC:Disable Lockout')) option: Str('ipadefaultemaildomain', attribute=True, autofill=False, cli_name='emaildomain', multivalue=False, required=False) option: Str('ipadefaultloginshell', attribute=True, autofill=False, cli_name='defaultshell', multivalue=False, required=False) option: Str('ipadefaultprimarygroup', attribute=True, autofill=False, cli_name='defaultgroup', multivalue=False, required=False) diff --git a/install/ui/src/freeipa/serverconfig.js b/install/ui/src/freeipa/serverconfig.js index 94e1454adebc3dd6848b0251db5e3e460211084e..7dea5d1f5344d187e746333824416b85874414e3 100644 --- a/install/ui/src/freeipa/serverconfig.js +++ b/install/ui/src/freeipa/serverconfig.js @@ -69,7 +69,7 @@ return { name: 'ipaconfigstring', $type: 'checkboxes', options: IPA.create_options([ - 'AllowLMhash', 'AllowNThash', + 'AllowNThash', 'KDC:Disable Last Success', 'KDC:Disable Lockout' ]) }, diff --git a/install/ui/test/data/ipa_init_commands.json b/install/ui/test/data/ipa_init_commands.json index 4f28701fb1db2913a8317a9299a4cc7de73155da..207318115cc9a0d9f7cbd2c6f1bf31aae9aa8814 100644 --- a/install/ui/test/data/ipa_init_commands.json +++ b/install/ui/test/data/ipa_init_commands.json @@ -2278,7 +2278,6 @@ "name": "ipaconfigstring", "type": "unicode", "values": [ - "AllowLMhash", "AllowNThash", "KDC:Disable Last Success", "KDC:Disable Lockout" diff --git a/install/ui/test/data/ipa_init_objects.json b/install/ui/test/data/ipa_init_objects.json index bef3cc65d45a8473f7fed3b67124bbc892213ca5..8550e8280a69d4eafdac5529ba39f162f3dbc9eb 100644 --- a/install/ui/test/data/ipa_init_objects.json +++ b/install/ui/test/data/ipa_init_objects.json @@ -580,7 +580,6 @@ "name": "ipaconfigstring", "type": "unicode", "values": [ - "AllowLMhash", "AllowNThash", "KDC:Disable Last Success", "KDC:Disable Lockout" diff --git a/ipalib/plugins/config.py b/ipalib/plugins/config.py index b9cf05016bf80cd48134cca5a50cdca7db423ca9..fbaacb7b9daafac4de49f23794b807e99aab6fc3 100644 --- a/ipalib/plugins/config.py +++ b/ipalib/plugins/config.py @@ -178,7 +178,7 @@ class config(LDAPObject): cli_name='ipaconfigstring', label=_('Password plugin features'), doc=_('Extra hashes to generate in password plug-in'), - values=(u'AllowLMhash', u'AllowNThash', + values=(u'AllowNThash', u'KDC:Disable Last Success', u'KDC:Disable Lockout'), csv=True, ), -- 1.8.1.4 -------------- next part -------------- From 27ff66e180082f0e32f88ac1ef07664ecfe4553b Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 29 Oct 2013 12:19:01 +0100 Subject: [PATCH 123/123] Remove generation and handling of LM hashes https://fedorahosted.org/freeipa/ticket/3795 --- daemons/ipa-sam/ipa_sam.c | 21 +-- daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c | 14 +- daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c | 48 ++--- daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h | 3 +- daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 17 +- util/ipa_pwd.h | 11 +- util/ipa_pwd_ntlm.c | 210 +++++---------------- 7 files changed, 74 insertions(+), 250 deletions(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 59ddcef2e66f59297d2e42dadb5512e242f60657..674085d2a14c67359df16458dbbb098414a24d8b 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -2637,10 +2637,9 @@ static bool init_sam_from_td(struct samu *user, struct pdb_trusted_domain *td, char *name; char *trustpw = NULL; char *trustpw_utf8 = NULL; - char *trustpw_utf8_uc = NULL; char *tmp_str = NULL; int ret; - struct ntlm_keys ntlm_keys; + uint8_t nt_key[16]; size_t converted_size; bool res; char *sid_str; @@ -2706,23 +2705,13 @@ static bool init_sam_from_td(struct samu *user, struct pdb_trusted_domain *td, goto done; } - if (!push_utf8_talloc(user, &trustpw_utf8_uc, tmp_str, &converted_size)) { - res = false; - goto done; - } - - ret = encode_ntlm_keys(trustpw_utf8, trustpw_utf8_uc, true, true, - &ntlm_keys); + ret = encode_nt_key(trustpw_utf8, nt_key); if (ret != 0) { res = false; goto done; } - if (!pdb_set_lanman_passwd(user, ntlm_keys.lm, PDB_SET)) { - res = false; - goto done; - } - if (!pdb_set_nt_passwd(user, ntlm_keys.nt, PDB_SET)) { + if (!pdb_set_nt_passwd(user, nt_key, PDB_SET)) { res = false; goto done; } @@ -2741,10 +2730,6 @@ done: memset(tmp_str, 0, strlen(tmp_str)); talloc_free(tmp_str); } - if (trustpw_utf8_uc != NULL) { - memset(trustpw_utf8_uc, 0, strlen(trustpw_utf8_uc)); - talloc_free(trustpw_utf8_uc); - } return res; } diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c index f0339c47c5b242b436d77c4845c5914eae79814f..2538a4094bd9a166e61b0911e5ea93426092d88a 100644 --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c @@ -366,7 +366,6 @@ static struct ipapwd_krbcfg *ipapwd_getConfig(void) slapi_entry_free(config_entry); /* get the ipa etc/ipaConfig entry */ - config->allow_lm_hash = false; config->allow_nt_hash = false; ret = ipapwd_getEntry(ipa_etc_config_dn, &config_entry, NULL); if (ret != LDAP_SUCCESS) { @@ -376,10 +375,6 @@ static struct ipapwd_krbcfg *ipapwd_getConfig(void) tmparray = slapi_entry_attr_get_charray(config_entry, "ipaConfigString"); for (i = 0; tmparray && tmparray[i]; i++) { - if (strcasecmp(tmparray[i], "AllowLMhash") == 0) { - config->allow_lm_hash = true; - continue; - } if (strcasecmp(tmparray[i], "AllowNThash") == 0) { config->allow_nt_hash = true; continue; @@ -928,7 +923,6 @@ int ipapwd_SetPassword(struct ipapwd_krbcfg *krbcfg, Slapi_Value **pwvals = NULL; struct tm utctime; char timestr[GENERALIZED_TIME_LENGTH+1]; - char *lm = NULL; char *nt = NULL; int is_smb = 0; int is_ipant = 0; @@ -965,7 +959,7 @@ int ipapwd_SetPassword(struct ipapwd_krbcfg *krbcfg, ret = ipapwd_gen_hashes(krbcfg, data, data->password, is_krb, is_smb, is_ipant, - &svals, &nt, &lm, &ntvals, &errMesg); + &svals, &nt, &ntvals, &errMesg); if (ret) { goto free_and_return; } @@ -1004,11 +998,6 @@ int ipapwd_SetPassword(struct ipapwd_krbcfg *krbcfg, } } - if (lm && is_smb) { - slapi_mods_add_string(smods, LDAP_MOD_REPLACE, - "sambaLMPassword", lm); - } - if (nt && is_smb) { slapi_mods_add_string(smods, LDAP_MOD_REPLACE, "sambaNTPassword", nt); @@ -1069,7 +1058,6 @@ int ipapwd_SetPassword(struct ipapwd_krbcfg *krbcfg, LOG_TRACE("<= result: %d\n", ret); free_and_return: - if (lm) slapi_ch_free((void **)&lm); if (nt) slapi_ch_free((void **)&nt); if (modtime) slapi_ch_free((void **)&modtime); slapi_mods_free(&smods); diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c index a92eaf0da33809e5a4b81c7f10a801e256880743..28f164eb8990ec9212df726b19e7ddc9db28fb8a 100644 --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c @@ -201,15 +201,13 @@ enc_error: int ipapwd_gen_hashes(struct ipapwd_krbcfg *krbcfg, struct ipapwd_data *data, char *userpw, int is_krb, int is_smb, int is_ipant, Slapi_Value ***svals, - char **nthash, char **lmhash, Slapi_Value ***ntvals, + char **nthash, Slapi_Value ***ntvals, char **errMesg) { int rc; - char *userpw_uc = NULL; *svals = NULL; *nthash = NULL; - *lmhash = NULL; *errMesg = NULL; if (is_krb) { @@ -225,40 +223,24 @@ int ipapwd_gen_hashes(struct ipapwd_krbcfg *krbcfg, } if (is_smb || is_ipant) { - char lm[33], nt[33]; - struct ntlm_keys ntlm; + char nt[33]; + uint8_t nt_key[16]; int ret; - userpw_uc = (char *) slapi_utf8StrToUpper((unsigned char *) userpw); - if (!userpw_uc) { - *errMesg = "Failed to generate upper case password\n"; - LOG_FATAL("%s", *errMesg); - rc = LDAP_OPERATIONS_ERROR; - goto done; - } - - ret = encode_ntlm_keys(userpw, - userpw_uc, - krbcfg->allow_lm_hash, - krbcfg->allow_nt_hash, - &ntlm); - memset(userpw_uc, 0, strlen(userpw_uc)); - slapi_ch_free_string(&userpw_uc); - if (ret) { - *errMesg = "Failed to generate NT/LM hashes\n"; - LOG_FATAL("%s", *errMesg); - rc = LDAP_OPERATIONS_ERROR; - goto done; - } - if (krbcfg->allow_lm_hash) { - hexbuf(lm, ntlm.lm); - lm[32] = '\0'; - *lmhash = slapi_ch_strdup(lm); - } if (krbcfg->allow_nt_hash) { - hexbuf(nt, ntlm.nt); + ret = encode_nt_key(userpw, nt_key); + if (ret) { + *errMesg = "Failed to generate NT/LM hashes\n"; + LOG_FATAL("%s", *errMesg); + rc = LDAP_OPERATIONS_ERROR; + goto done; + } + + hexbuf(nt, nt_key); nt[32] = '\0'; *nthash = slapi_ch_strdup(nt); + } else { + memset(nt_key, 0, 16); } if (is_ipant) { @@ -269,7 +251,7 @@ int ipapwd_gen_hashes(struct ipapwd_krbcfg *krbcfg, goto done; } (*ntvals)[0] = slapi_value_new(); - if (slapi_value_set((*ntvals)[0], ntlm.nt, 16) == NULL) { + if (slapi_value_set((*ntvals)[0], nt_key, 16) == NULL) { rc = LDAP_OPERATIONS_ERROR; goto done; } diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h index 74b63627689da9e519ec15d1e2020fa50ea7f75c..b4087488ccf2081aeed9aa02d1a4f0d37f4cf7f4 100644 --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h @@ -132,7 +132,6 @@ struct ipapwd_krbcfg { krb5_key_salt_tuple *pref_encsalts; char **passsync_mgrs; int num_passsync_mgrs; - bool allow_lm_hash; bool allow_nt_hash; }; @@ -172,7 +171,7 @@ void ipapwd_keyset_free(struct ipapwd_keyset **pkset); int ipapwd_gen_hashes(struct ipapwd_krbcfg *krbcfg, struct ipapwd_data *data, char *userpw, int is_krb, int is_smb, int is_ipant, - Slapi_Value ***svals, char **nthash, char **lmhash, + Slapi_Value ***svals, char **nthash, Slapi_Value ***ntvals, char **errMesg); /* from prepost.c */ diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c index f5100a292adcb6db63fcad7b4780d4b2a5ab512e..fa956acebe974a2b07bb2ea6abfdd4c339b6eb47 100644 --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c @@ -329,13 +329,12 @@ static int ipapwd_pre_add(Slapi_PBlock *pb) Slapi_Value **svals = NULL; Slapi_Value **ntvals = NULL; char *nt = NULL; - char *lm = NULL; pwdop->is_krb = is_krb; rc = ipapwd_gen_hashes(krbcfg, &pwdop->pwdata, userpw, is_krb, is_smb, is_ipant, - &svals, &nt, &lm, &ntvals, &errMesg); + &svals, &nt, &ntvals, &errMesg); if (rc != LDAP_SUCCESS) { goto done; } @@ -353,11 +352,6 @@ static int ipapwd_pre_add(Slapi_PBlock *pb) ipapwd_free_slapi_value_array(&svals); } - if (lm && is_smb) { - /* set value */ - slapi_entry_attr_set_charptr(e, "sambaLMPassword", lm); - slapi_ch_free_string(&lm); - } if (nt && is_smb) { /* set value */ slapi_entry_attr_set_charptr(e, "sambaNTPassword", nt); @@ -823,11 +817,10 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb) Slapi_Value **svals = NULL; Slapi_Value **ntvals = NULL; char *nt = NULL; - char *lm = NULL; rc = ipapwd_gen_hashes(krbcfg, &pwdop->pwdata, unhashedpw, gen_krb_keys, is_smb, is_ipant, - &svals, &nt, &lm, &ntvals, &errMesg); + &svals, &nt, &ntvals, &errMesg); if (rc) { goto done; } @@ -839,12 +832,6 @@ static int ipapwd_pre_mod(Slapi_PBlock *pb) ipapwd_free_slapi_value_array(&svals); } - if (lm && is_smb) { - /* replace value */ - slapi_mods_add_string(smods, LDAP_MOD_REPLACE, - "sambaLMPassword", lm); - slapi_ch_free_string(&lm); - } if (nt && is_smb) { /* replace value */ slapi_mods_add_string(smods, LDAP_MOD_REPLACE, diff --git a/util/ipa_pwd.h b/util/ipa_pwd.h index a6990cac6333bf2582fb071a507001b10145df6d..bc07549cc864cc9a1ed0b58617b4624fbb9a864b 100644 --- a/util/ipa_pwd.h +++ b/util/ipa_pwd.h @@ -74,15 +74,6 @@ int ipapwd_generate_new_history(char *password, char ***new_pwd_history, int *new_pwd_hlen); -struct ntlm_keys { - uint8_t lm[16]; - uint8_t nt[16]; -}; - -int encode_ntlm_keys(char *newPasswd, - char *upperPasswd, - bool do_lm_hash, - bool do_nt_hash, - struct ntlm_keys *keys); +int encode_nt_key(char *newPasswd, uint8_t *nt_key); #endif diff --git a/util/ipa_pwd_ntlm.c b/util/ipa_pwd_ntlm.c index a3399b58e006e340677fa43773e6282249858062..8ffa66660cac6ca99d4c3631872f96f96fc06b12 100644 --- a/util/ipa_pwd_ntlm.c +++ b/util/ipa_pwd_ntlm.c @@ -32,178 +32,70 @@ #define KTF_UTF8 "UTF-8" #define KTF_UCS2 "UCS-2LE" -static const uint8_t parity_table[128] = { - 1, 2, 4, 7, 8, 11, 13, 14, 16, 19, 21, 22, 25, 26, 28, 31, - 32, 35, 37, 38, 41, 42, 44, 47, 49, 50, 52, 55, 56, 59, 61, 62, - 64, 67, 69, 70, 73, 74, 76, 79, 81, 82, 84, 87, 88, 91, 93, 94, - 97, 98,100,103,104,107,109,110,112,115,117,118,121,122,124,127, - 128,131,133,134,137,138,140,143,145,146,148,151,152,155,157,158, - 161,162,164,167,168,171,173,174,176,179,181,182,185,186,188,191, - 193,194,196,199,200,203,205,206,208,211,213,214,217,218,220,223, - 224,227,229,230,233,234,236,239,241,242,244,247,248,251,253,254 -}; - -static void lm_shuffle(uint8_t *out, uint8_t *in) -{ - out[0] = parity_table[in[0]>>1]; - out[1] = parity_table[((in[0]<<6)|(in[1]>>2)) & 0x7F]; - out[2] = parity_table[((in[1]<<5)|(in[2]>>3)) & 0x7F]; - out[3] = parity_table[((in[2]<<4)|(in[3]>>4)) & 0x7F]; - out[4] = parity_table[((in[3]<<3)|(in[4]>>5)) & 0x7F]; - out[5] = parity_table[((in[4]<<2)|(in[5]>>6)) & 0x7F]; - out[6] = parity_table[((in[5]<<1)|(in[6]>>7)) & 0x7F]; - out[7] = parity_table[in[6] & 0x7F]; -} - -/* create the lm and nt hashes +/* create the nt hash newPassword: the clear text utf8 password - upperPasswd: upper case version of clear text utf8 password - do_lm_hash: determine if LM hash is generated - do_nt_hash: determine if NT hash is generated - keys[out]: array with generated hashes + nt_key[out]: array with generated hash */ -int encode_ntlm_keys(char *newPasswd, - char *upperPasswd, - bool do_lm_hash, - bool do_nt_hash, - struct ntlm_keys *keys) +int encode_nt_key(char *newPasswd, uint8_t *nt_key) { int ret = 0; + iconv_t cd; + size_t cs, il, ol, sl; + char *inc, *outc; + char *ucs2Passwd; + MD4_CTX md4ctx; + + /* TODO: must store the dos charset somewhere in the directory */ + cd = iconv_open(KTF_UCS2, KTF_UTF8); + if (cd == (iconv_t)(-1)) { + ret = -1; + goto done; + } - /* do lanman first */ - if (do_lm_hash) { - iconv_t cd; - size_t cs, il, ol; - char *inc, *outc; - char *asciiPasswd; - DES_key_schedule schedule; - DES_cblock deskey; - DES_cblock magic = "KGS!@#$%"; - - if (upperPasswd == NULL) { - ret = -1; - goto done; - } - il = strlen(upperPasswd); - - /* TODO: must store the dos charset somewhere in the directory */ - cd = iconv_open(KTF_DOS_CHARSET, KTF_UTF8); - if (cd == (iconv_t)(-1)) { - ret = -1; - goto done; - } - - /* an ascii string can only be smaller than or equal to an utf8 one */ - ol = il; - if (ol < 14) ol = 14; - asciiPasswd = calloc(ol+1, 1); - if (!asciiPasswd) { - iconv_close(cd); - ret = -1; - goto done; - } - - inc = upperPasswd; - outc = asciiPasswd; - cs = iconv(cd, &inc, &il, &outc, &ol); - if (cs == -1) { - ret = -1; - free(asciiPasswd); - iconv_close(cd); - goto done; - } + il = strlen(newPasswd); - /* done with these */ + /* an ucs2 string can be at most double than an utf8 one */ + sl = ol = (il+1)*2; + ucs2Passwd = calloc(ol, 1); + if (!ucs2Passwd) { + ret = -1; iconv_close(cd); - - /* we are interested only in the first 14 ASCII chars for lanman */ - if (strlen(asciiPasswd) > 14) { - asciiPasswd[14] = '\0'; - } - - /* first half */ - lm_shuffle(deskey, (uint8_t *)asciiPasswd); - - DES_set_key_unchecked(&deskey, &schedule); - DES_ecb_encrypt(&magic, (DES_cblock *)keys->lm, - &schedule, DES_ENCRYPT); - - /* second half */ - lm_shuffle(deskey, (uint8_t *)&asciiPasswd[7]); - - DES_set_key_unchecked(&deskey, &schedule); - DES_ecb_encrypt(&magic, (DES_cblock *)&(keys->lm[8]), - &schedule, DES_ENCRYPT); - - /* done with it */ - free(asciiPasswd); - - } else { - memset(keys->lm, 0, 16); + goto done; } - if (do_nt_hash) { - iconv_t cd; - size_t cs, il, ol, sl; - char *inc, *outc; - char *ucs2Passwd; - MD4_CTX md4ctx; - - /* TODO: must store the dos charset somewhere in the directory */ - cd = iconv_open(KTF_UCS2, KTF_UTF8); - if (cd == (iconv_t)(-1)) { - ret = -1; - goto done; - } - - il = strlen(newPasswd); - - /* an ucs2 string can be at most double than an utf8 one */ - sl = ol = (il+1)*2; - ucs2Passwd = calloc(ol, 1); - if (!ucs2Passwd) { - ret = -1; - iconv_close(cd); - goto done; - } - - inc = newPasswd; - outc = ucs2Passwd; - cs = iconv(cd, &inc, &il, &outc, &ol); - if (cs == -1) { - ret = -1; - free(ucs2Passwd); - iconv_close(cd); - goto done; - } - - /* done with it */ + inc = newPasswd; + outc = ucs2Passwd; + cs = iconv(cd, &inc, &il, &outc, &ol); + if (cs == -1) { + ret = -1; + free(ucs2Passwd); iconv_close(cd); + goto done; + } - /* get the final ucs2 string length */ - sl -= ol; + /* done with it */ + iconv_close(cd); - ret = MD4_Init(&md4ctx); - if (ret == 0) { - ret = -1; - free(ucs2Passwd); - goto done; - } - ret = MD4_Update(&md4ctx, ucs2Passwd, sl); - if (ret == 0) { - ret = -1; - free(ucs2Passwd); - goto done; - } - ret = MD4_Final(keys->nt, &md4ctx); - if (ret == 0) { - ret = -1; - free(ucs2Passwd); - goto done; - } + /* get the final ucs2 string length */ + sl -= ol; - } else { - memset(keys->nt, 0, 16); + ret = MD4_Init(&md4ctx); + if (ret == 0) { + ret = -1; + free(ucs2Passwd); + goto done; + } + ret = MD4_Update(&md4ctx, ucs2Passwd, sl); + if (ret == 0) { + ret = -1; + free(ucs2Passwd); + goto done; + } + ret = MD4_Final(nt_key, &md4ctx); + if (ret == 0) { + ret = -1; + free(ucs2Passwd); + goto done; } ret = 0; -- 1.8.1.4 From Roger.Vaede at fincen.gov Thu Oct 31 00:40:08 2013 From: Roger.Vaede at fincen.gov (Vaede, Roger (Contractor)) Date: Thu, 31 Oct 2013 00:40:08 +0000 Subject: [Freeipa-devel] certificate renewal In-Reply-To: <527174F2.7080200@redhat.com> References: <647D6B6B44F7C046AFE8E069C0CF70FC284FB772@hqexdb01.hqfincen.gov> <5271503C.9020207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7AE@hqexdb01.hqfincen.gov> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7CF@hqexdb01.hqfincen.gov> <52715E0E.5090207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB80C@hqexdb01.hqfincen.gov> <52716BF6.1060607@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB848@hqexdb01.hqfincen.gov> <647D6B6B44F7C046AFE8E069C0CF70FC284FB851@hqexdb01.hqfincen.gov> <527174F2.7080200@redhat.com> Message-ID: <647D6B6B44F7C046AFE8E069C0CF70FC284FB882@hqexdb01.hqfincen.gov> I cannot upgrade to IPA 3.0 at this time, these are live machines. I only want to renew only the primary server the one that has an expired certificate. How can I tell if the server is running on CA? Thanks for your help on this Rob. Regards Roger -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Wednesday, October 30, 2013 5:07 PM To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' Subject: Re: [Freeipa-devel] certificate renewal Vaede, Roger (Contractor) wrote: > There are two location of the alias: > In the backup: /etc/httpd/alias/ > In the one that has expired: /var/lib/pki-ca/alias These are separate entities and will need to be dealt with seprately. /var/lib/pki-ca/alias is the NSS database that contains the certificates for the CA itself. With the subsystem certs being expired it means that the CA itself is basically dead in the water because nothing can talk to it. We're really moving into some uncharted waters here. I don't really want to recommend upgrading to 3.0 just to get the certs renewed, though there are lots of other good reasons to upgrade. I don't know what will happen if we try to renew the certs using the 3.0 method on a 2.x server. So you've got two IPA masters. Are you running the CA on both or only on one? It makes a difference in how we do the renewal because it will be more complex if you have it on both (not a show stopper). I *think* we can use the latest certmonger to do the majority of the heavy lifting. The basic process will be to update those bits, go back in time, the tell it to start tracking the CA certs one by one and get them renewed. We'll need to do the same with some other certs, some of which are in /etc/httpd/alias and some of which are in /etc/dirsrv/slapd-REALM/. If you have another instance of the CA we'll need to extract some of the renewed certs and import them on the other side. Then we return to present time. So let me know what your environment looks like and I'll try to come up with some steps to do the renewal. rob From tbabej at redhat.com Thu Oct 31 01:44:10 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 31 Oct 2013 02:44:10 +0100 Subject: [Freeipa-devel] [PATCH 0127] advice: Add legacy client configuration script using nss-ldap Message-ID: <5271B5EA.3070300@redhat.com> Hi, Part of: https://fedorahosted.org/freeipa/ticket/3833 -- 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-0127-advice-Add-legacy-client-configuration-script-using-.patch Type: text/x-patch Size: 2502 bytes Desc: not available URL: From abokovoy at redhat.com Thu Oct 31 08:10:43 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 31 Oct 2013 10:10:43 +0200 Subject: [Freeipa-devel] [PATCH 0127] advice: Add legacy client configuration script using nss-ldap In-Reply-To: <5271B5EA.3070300@redhat.com> References: <5271B5EA.3070300@redhat.com> Message-ID: <20131031081043.GR25335@redhat.com> On Thu, 31 Oct 2013, Tomas Babej wrote: >Hi, > >Part of: https://fedorahosted.org/freeipa/ticket/3833 > ACK, since nss_ldap package contains both NSS and PAM modules. -- / Alexander Bokovoy From mkosek at redhat.com Thu Oct 31 08:31:28 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 31 Oct 2013 09:31:28 +0100 Subject: [Freeipa-devel] [PATCH 0127] advice: Add legacy client configuration script using nss-ldap In-Reply-To: <20131031081043.GR25335@redhat.com> References: <5271B5EA.3070300@redhat.com> <20131031081043.GR25335@redhat.com> Message-ID: <52721560.4040503@redhat.com> On 10/31/2013 09:10 AM, Alexander Bokovoy wrote: > On Thu, 31 Oct 2013, Tomas Babej wrote: > >> Hi, >> >> Part of: https://fedorahosted.org/freeipa/ticket/3833 >> > ACK, since nss_ldap package contains both NSS and PAM modules. > Pushed to master, ipa-3-3. Martin From akrivoka at redhat.com Thu Oct 31 11:10:51 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 31 Oct 2013 12:10:51 +0100 Subject: [Freeipa-devel] [PATCH 0125] ipatests: Add which package to legacy client advice In-Reply-To: <52712338.2030509@redhat.com> References: <52712338.2030509@redhat.com> Message-ID: <52723ABB.9010603@redhat.com> On 10/30/2013 04:18 PM, Tomas Babej wrote: > Hi, > > Adds which package to the requirements, since older distros do not have it by > default. > > Part of: https://fedorahosted.org/freeipa/ticket/3833 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel You can use the bash built-in command `command`, instead of `which`, to find out if a program exists: command -v cacertdir_rehash In other words, just replace `which` with `command -v`; there's no need to install any additional packages. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akrivoka at redhat.com Thu Oct 31 11:38:03 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 31 Oct 2013 12:38:03 +0100 Subject: [Freeipa-devel] [PATCH 0124] ipatests: Extend clear_sssd_cache to support non-systemd In-Reply-To: <5271287D.2080304@redhat.com> References: <5271287D.2080304@redhat.com> Message-ID: <5272411B.5040101@redhat.com> On 10/30/2013 04:40 PM, Tomas Babej wrote: > Hi, > > This allows us to clean sssd cache on older, non-systemd platforms. > > Part of: https://fedorahosted.org/freeipa/ticket/3833 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Looks good, ACK. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From akrivoka at redhat.com Thu Oct 31 12:02:05 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 31 Oct 2013 13:02:05 +0100 Subject: [Freeipa-devel] [PATCH 0126] ipatests: Restore SELinux context after restoring files from In-Reply-To: <52712371.5070803@redhat.com> References: <52712371.5070803@redhat.com> Message-ID: <527246BD.1010503@redhat.com> On 10/30/2013 04:19 PM, Tomas Babej wrote: > Hi, > > Without this patch, restored directories get home_t SELinux context. > > Part of: https://fedorahosted.org/freeipa/ticket/3833 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Thu Oct 31 12:16:40 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 31 Oct 2013 13:16:40 +0100 Subject: [Freeipa-devel] [PATCH 0124] ipatests: Extend clear_sssd_cache to support non-systemd In-Reply-To: <5272411B.5040101@redhat.com> References: <5271287D.2080304@redhat.com> <5272411B.5040101@redhat.com> Message-ID: <52724A28.3020209@redhat.com> On 10/31/2013 12:38 PM, Ana Krivokapic wrote: > On 10/30/2013 04:40 PM, Tomas Babej wrote: >> Hi, >> >> This allows us to clean sssd cache on older, non-systemd platforms. >> >> Part of: https://fedorahosted.org/freeipa/ticket/3833 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Looks good, ACK. > Pushed to master: 775f2de4ecc047428034ed68dbbae934fa38de8a ipa-3-3: a4ea378e5123c9883814952df06dfe6482da307d -- Petr? From pviktori at redhat.com Thu Oct 31 12:19:00 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 31 Oct 2013 13:19:00 +0100 Subject: [Freeipa-devel] [PATCH 0126] ipatests: Restore SELinux context after restoring files from In-Reply-To: <527246BD.1010503@redhat.com> References: <52712371.5070803@redhat.com> <527246BD.1010503@redhat.com> Message-ID: <52724AB4.2090801@redhat.com> On 10/31/2013 01:02 PM, Ana Krivokapic wrote: > On 10/30/2013 04:19 PM, Tomas Babej wrote: >> Hi, >> >> Without this patch, restored directories get home_t SELinux context. >> >> Part of: https://fedorahosted.org/freeipa/ticket/3833 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK > Pushed to: master: 4fd88140b181b5f69c9312070840a4020593eb90 ipa-3-3: 63451c0b16ea501fafc2678873e604f55ae81437 -- Petr? From akrivoka at redhat.com Thu Oct 31 13:05:24 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 31 Oct 2013 14:05:24 +0100 Subject: [Freeipa-devel] [PATCH 0123] ipatests: Do not use /usr/bin hardcoded paths In-Reply-To: <52711F48.2020602@redhat.com> References: <52711F48.2020602@redhat.com> Message-ID: <52725594.3020704@redhat.com> On 10/30/2013 04:01 PM, Tomas Babej wrote: > Hi, > > The RHEL 5.9 clients do not have /usr/bin symlinks. > > Part of: https://fedorahosted.org/freeipa/ticket/3833 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Thu Oct 31 13:11:37 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 31 Oct 2013 14:11:37 +0100 Subject: [Freeipa-devel] [PATCH 0123] ipatests: Do not use /usr/bin hardcoded paths In-Reply-To: <52725594.3020704@redhat.com> References: <52711F48.2020602@redhat.com> <52725594.3020704@redhat.com> Message-ID: <52725709.5000200@redhat.com> On 10/31/2013 02:05 PM, Ana Krivokapic wrote: > On 10/30/2013 04:01 PM, Tomas Babej wrote: >> Hi, >> >> The RHEL 5.9 clients do not have /usr/bin symlinks. >> >> Part of: https://fedorahosted.org/freeipa/ticket/3833 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK Pushed to: master: 44998feace93a01b3dfda8fce6ff7aa35fffbabf ipa-3-3: d90862aaabfe663c1696152e982460821b0cb564 -- Petr? From jcholast at redhat.com Thu Oct 31 13:45:59 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 31 Oct 2013 14:45:59 +0100 Subject: [Freeipa-devel] [PATCHES] 198-202 Refactor indirect membership processing Message-ID: <52725F17.2020800@redhat.com> Hi, the attached patches fix . Tested with 25000 users. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-198-Move-IPA-specific-code-from-LDAPClient-to-the-ldap2-.patch Type: text/x-patch Size: 18328 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-199-Add-wrapper-for-result3-to-IPASimpleLDAPObject.patch Type: text/x-patch Size: 1056 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-200-Support-searches-with-paged-results-control-in-LDAPC.patch Type: text/x-patch Size: 6195 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-201-Refactor-indirect-membership-processing.patch Type: text/x-patch Size: 11095 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-202-Remove-unused-method-get_api-of-the-ldap2-plugin.patch Type: text/x-patch Size: 749 bytes Desc: not available URL: From pviktori at redhat.com Thu Oct 31 15:52:46 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 31 Oct 2013 16:52:46 +0100 Subject: [Freeipa-devel] [PATCH 0121] ipatests: Add support for hosts referenced by a keyword In-Reply-To: <52711E66.20409@redhat.com> References: <52662737.7070705@redhat.com> <52662F3F.2050309@redhat.com> <526632A2.4030404@redhat.com> <52663AD6.4070308@redhat.com> <5268F465.7040800@redhat.com> <526FA36E.3070000@redhat.com> <52711E66.20409@redhat.com> Message-ID: <52727CCE.1060302@redhat.com> On 10/30/2013 03:57 PM, Tomas Babej wrote: > On 10/29/2013 01:00 PM, Petr Viktorin wrote: >> On 10/24/2013 12:20 PM, Tomas Babej wrote: >>> On 10/22/2013 10:44 AM, Petr Viktorin wrote: >>>> On 10/22/2013 10:09 AM, Tomas Babej wrote: >>>>> On 10/22/2013 09:54 AM, Petr Viktorin wrote: >>>>>> On 10/22/2013 09:20 AM, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Adds support for host definition by a environment variables of the >>>>>>> following form: >>>>>>> >>>>>>> KEYWORDHOST__envX, where X is the number of the environment >>>>>>> for which host referenced by a keyword should be defined. >>>>>>> >>>>>>> You can also optionally use KEYWORDHOST__IP_envX to define >>>>>>> the IP address directly, otherwise the framework will try to resolve >>>>>>> the hostname. >>>>>>> >>>>>>> Adds a required_keyword_hosts attribute to the IntegrationTest >>>>>>> class, >>>>>>> which can test developer use to specify the keyword hosts that this >>>>>>> particular test requires. If not all required keyword hosts are >>>>>>> available, the test will be skipped. >>>>>>> >>>>>>> All keyword hosts are accessible to the IntegrationTests via the >>>>>>> keyword_hosts attribute, which contains a dictionary keyed by the >>>>>>> keywords. >>>>>>> >>>>>> >>>>>> Why is this necessary? >>>>>> What's wrong with just extending the current scheme with more roles? >>>>>> >>>>>> >>>>> >>>>> The need for keyword hosts arised with the implementation of the >>>>> legacy >>>>> client test suite. >>>>> >>>>> As each of these tests needs a precise type (pre-defined and >>>>> pre-configured) of VM, and not a generic client, you need to restrict >>>>> the test case to specific host type. >>>>> >>>>> One test might be restricted to RHEL 5.10 with nss-pam-ldapd, >>>>> another to >>>>> FreeBSD, next one to CentOS with nss-pam-ldapd, next to CentOS with >>>>> old >>>>> version of SSSD... >>>>> >>>>> Each testcase that needs a new type of preconfigured host, we would >>>>> need >>>>> to introduce a new role, which would need to be integrated in the >>>>> framework. In such implementation, we would lose loose coupling >>>>> between >>>>> the test framework and the test themselves, and make them less >>>>> pluggable. >>>> >>>> The framework itself (excluding the configuration part) should be able >>>> to handle this nicely using the existing role mechanism. It's true >>>> that in some places it's currently hard-wired to just a few roles, but >>>> supporting completely custom roles shouldn't be a problem. >>>> I'd prefer if this system was used, rather than basically adding a >>>> second role system, which we'd have to support even if we get rid of >>>> the current config part. >>>> >>>> The envvar-based configuration is not as flexible, but I'd rather make >>>> this part somewhat unpleasant than making the framework complex. We >>>> plan to move to a simpler configuration method anyway. >>>> That said, you can basically keep the variable name scheme you use in >>>> this patch; just maybe use TESTHOST rather than KEYWORDHOST. >>>> >>> >>> I rewired the patch to use the current role system. >>> >>> Please look if you have any additional issues. >>> >> >> I only have two naming nitpicks. >> - The roles aren't really "dynamic"; eventually all the "dynamicness" >> should be specific just to the envvar configuration system, and a few >> shortcuts like `replicas` for `host_by_role('replica')`. I think >> "extra" would be a better term. >> - The environment variable names could be more descriptive. They store >> a hostname, not a role, so instead of $ROLE__envX I'd prefer >> $TESTHOST__envX >> >> Other than that the changes look great! >> > > Thanks, updated patch attached. > ACK, pushed to master: b1bffb5ecad0fdaa2f560efd2b75c76bedc4423c ipa-3-3: 960c6bf301fe3a00205a895acabe47bac5ac9349 -- Petr? From mkosek at redhat.com Thu Oct 31 17:11:58 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 31 Oct 2013 18:11:58 +0100 Subject: [Freeipa-devel] [PATCHES] 106-113 Access raw LDAP values directly from LDAPEntry In-Reply-To: <526FD17E.7020607@redhat.com> References: <512E26E1.5010302@redhat.com> <52419527.70200@redhat.com> <524426F5.6010006@redhat.com> <525544A3.6080807@redhat.com> <52565B09.2090909@redhat.com> <525BB27C.1000507@redhat.com> <525EBB0D.9040003@redhat.com> <526FAB52.5080300@redhat.com> <526FD17E.7020607@redhat.com> Message-ID: <52728F5E.8040507@redhat.com> On 10/29/2013 04:17 PM, Petr Viktorin wrote: > On 10/29/2013 01:34 PM, Jan Cholasta wrote: >> On 16.10.2013 18:13, Petr Viktorin wrote: >>> On 10/14/2013 10:59 AM, Jan Cholasta wrote: >>>> On 10.10.2013 09:45, Jan Cholasta wrote: >>>>> On 9.10.2013 13:57, Petr Viktorin wrote: > [...] >>>>>> 109. Decode and encode attribute values in LDAPEntry on demand. >>>>>> >>>>>> The syncing looks rather over-engineered to me. >>>>>> Did you consider a custom MutableSequence for the values? >>>>>> I think it would be much cleaner in the end than merging two sets of >>>>>> changes together. >>>>> >>>>> I'm not entirely happy about it either, but it works. I did consider a >>>>> custom sequence type, but I didn't feel like it was the right time to >>>>> this kind of change in this patchset. >>>>> >>>>> Unlike the (DN, dict) -> LDAPEntry >>>>> transition, this change won't be backward compatible and there is a lot >>>>> of isinstance(value, list) and entry[attr] = list() kind of things in >>>>> the framework code. >>> >>> That's what I was afraid of. >>> >>> We could live with `isinstance(value, list)`; hopefully we could get rid >>> of `type(value) == list` that is the real problem. >>> With `entry[attr] = list()` we could convert automatically. >>> >>> But OK, let's settle for a worse solution in the meantime. >>> >>> >>> To be frank I don't particularly like the LDAPEntryView. >>> While the dict-like interface is great, there isn't a case for storing a >>> Raw view long-term, i.e. you'd always want to do something like >>> values = entry.raw[x] >>> ... >>> entry.raw[x] = new_values >>> rather than >>> raw = entry.raw >>> values = raw[x] >>> ... >>> raw[x] = new_values >>> The latter is confusing because LDAPEntryView and RawLDAPEntryView are >>> two classes that have exactly the same interface, but do something >>> different. In a duck-typed world that's a recipe for disaster. >>> I think it would be better if the view implemented just the dict >>> protocol, and not `conn`, `dn`, `nice`, `raw`, etc. >>> The code would also be much simpler without the elaborate view class >>> hierarchy. >>> >>> If you don't agree then at least don't make `raw` available on raw views >>> and `nice` on nice views; the programmer *always* needs to know which >>> version they're working with so these aren't necessary. >> >> I agree. Most of the attributes are leftovers from a previous >> implementation, which didn't work very well. I should have removed them >> a long time ago. Thanks for pointing this out! >> >> Updated the views to provide only the dict interface, removed "nice" and >> "multi_value" properties and also removed "single_value" from the raw view. > > Looks much better now. Hopefully _sync_attr can dissappear one day. > >>>>>> I think it would also help (in the future?) to make the value lists >>>>>> more >>>>>> set-like, since the order doesn't matter. >>>>> >>>>> +1 >>>>> >>>>> Honza >>>>> >>>> >>>> Updated patches attached. >>>> >>> >>> 110. >>> It can't hurt to have this in for now. >>> >>> 111 - 121 look great! > > 106 - 121: ACK 106-121 pushed to master. Martin From akrivoka at redhat.com Thu Oct 31 17:52:10 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 31 Oct 2013 18:52:10 +0100 Subject: [Freeipa-devel] Reminder: Patchwork Message-ID: <527298CA.3080305@redhat.com> Hello IPA developers, I would like to remind everyone about our Patchwork instance[1]. This tool helps us to better coordinate work and be more efficient, so let's try to remember to use it consistently. It takes only a few seconds of extra work per patch submission/review, which could potentially save us much more time. It is especially useful to mark the patch as 'Under Review' when you start reviewing it, so that others are aware of it and they don't start reviewing the same patch. That way, we can avoid the situation of two people accidentally doing the review of the same patch at the same time. I have just cleaned up the Patchwork instance as best as I could so it should now hopefully reflect the real situation on the state of patches. We also have some instructions on how to use it on our wiki[2]. Thanks! [1] https://patchwork.acksyn.org/project/FreeIPA/list/ [2] http://www.freeipa.org/page/Contribute/Code#Tracking_patches_.28Experimental.29 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From simo at redhat.com Thu Oct 31 18:24:02 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 31 Oct 2013 14:24:02 -0400 Subject: [Freeipa-devel] Reminder: Patchwork In-Reply-To: <527298CA.3080305@redhat.com> References: <527298CA.3080305@redhat.com> Message-ID: <1383243842.8612.144.camel@willson.li.ssimo.org> On Thu, 2013-10-31 at 18:52 +0100, Ana Krivokapic wrote: > Hello IPA developers, > > I would like to remind everyone about our Patchwork instance[1]. This tool helps > us to better coordinate work and be more efficient, so let's try to remember to > use it consistently. It takes only a few seconds of extra work per patch > submission/review, which could potentially save us much more time. It is > especially useful to mark the patch as 'Under Review' when you start reviewing > it, so that others are aware of it and they don't start reviewing the same > patch. That way, we can avoid the situation of two people accidentally doing the > review of the same patch at the same time. > > I have just cleaned up the Patchwork instance as best as I could so it should > now hopefully reflect the real situation on the state of patches. > > We also have some instructions on how to use it on our wiki[2]. > > Thanks! > > [1] https://patchwork.acksyn.org/project/FreeIPA/list/ > [2] http://www.freeipa.org/page/Contribute/Code#Tracking_patches_.28Experimental.29 Ana, thanks for going through it, I try to keep it up to date but have had little time recently. I Incidentally the machine run out of memory and the database crashed :-( I added more memory and restarted the instance, please let me know if everything is ok, it looks good to me. Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Thu Oct 31 18:26:01 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 31 Oct 2013 19:26:01 +0100 Subject: [Freeipa-devel] Reminder: Patchwork In-Reply-To: <527298CA.3080305@redhat.com> References: <527298CA.3080305@redhat.com> Message-ID: <20131031182601.GN22498@hendrix.brq.redhat.com> On Thu, Oct 31, 2013 at 06:52:10PM +0100, Ana Krivokapic wrote: > Hello IPA developers, > > I would like to remind everyone about our Patchwork instance[1]. This tool helps > us to better coordinate work and be more efficient, so let's try to remember to > use it consistently. It takes only a few seconds of extra work per patch > submission/review, which could potentially save us much more time. It is > especially useful to mark the patch as 'Under Review' when you start reviewing > it, so that others are aware of it and they don't start reviewing the same > patch. That way, we can avoid the situation of two people accidentally doing the > review of the same patch at the same time. > > I have just cleaned up the Patchwork instance as best as I could so it should > now hopefully reflect the real situation on the state of patches. > > We also have some instructions on how to use it on our wiki[2]. > > Thanks! > > [1] https://patchwork.acksyn.org/project/FreeIPA/list/ > [2] http://www.freeipa.org/page/Contribute/Code#Tracking_patches_.28Experimental.29 Does setting the patch state with "X-Patchwork-Status:" header work for anyone? I haven't tried it recently, but it would be a nice improvement. Currently I update all SSSD reviews manually which is a bit tedious. With a sane e-mail client (*cough*mutt*cough*), one can add a header with one keystroke. btw I also found out that automatically marking the patch as Pushed only works for me some times. I'm not sure about the pattern, but it happens more often for patches that are pushed to multiple branches. Do other developers see the same? From rcritten at redhat.com Thu Oct 31 18:40:54 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 31 Oct 2013 14:40:54 -0400 Subject: [Freeipa-devel] certificate renewal In-Reply-To: <647D6B6B44F7C046AFE8E069C0CF70FC284FB882@hqexdb01.hqfincen.gov> References: <647D6B6B44F7C046AFE8E069C0CF70FC284FB772@hqexdb01.hqfincen.gov> <5271503C.9020207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7AE@hqexdb01.hqfincen.gov> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7CF@hqexdb01.hqfincen.gov> <52715E0E.5090207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB80C@hqexdb01.hqfincen.gov> <52716BF6.1060607@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB848@hqexdb01.hqfincen.gov> <647D6B6B44F7C046AFE8E069C0CF70FC284FB851@hqexdb01.hqfincen.gov> <527174F2.7080200@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB882@hqexdb01.hqfincen.gov> Message-ID: <5272A436.30002@redhat.com> Vaede, Roger (Contractor) wrote: > I cannot upgrade to IPA 3.0 at this time, these are live machines. > I only want to renew only the primary server the one that has an expired certificate. > How can I tell if the server is running on CA? If you do a search like this: # ldapsearch -LLL -Y GSSAPI -b cn=masters,cn=ipa,cn=etc,dc=example,dc=com cn You'll get a listing, per-master, of the services on it. Look for the CA service. Some of the certificates are common among multiple CA replicas, and some are machine-specific. They can be renewed only one one master and then copied to the others, this is why I asked. As you'll see, this process is rather hairy and prone to error. I've done this any number of times on an IPA 3.x server while I worked on automating it but AFAIK never on a 2.x one. In theory it should work the same. In theory. The first thing you'll need to do is get a newer version of certmonger, at least certmonger-0.61-3.el6. IIRC you are currently tracking a bunch of bogus certs in certmonger. I'd one by one stop tracking them: # getcert list | grep Request for each cert do # getcert stop-tracking -i Next, you need to determine the PIN for the CA NSS database: # grep internal= /var/lib/pki-ca/conf/password.conf Now we need to tell certmonger about all the CA certificates it needs to renew for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" do /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n \"${nickname}\" -c dogtag-ipa-renew-agent -P done We also need to renew the agent certificate that IPA uses to authenticate: # /usr/bin/getcert start-tracking -d /etc/httpd/alias -n ipaCert -c dogtag-ipa-renew-agent -p /etc/httpd/alias/pwdfile.txt Use "getcert list" to confirm that these 5 certs are now being tracked and note the Request IDs. Now time for the wayback machine, go back to when these certs are all still valid. I'd recommend a day or two before the earliest expiration. You can force a renewal with: # getcert resubmit -i Do this for each one. Each should end up in a MONITORING state. Double-check that the audit certificate has a trust of u,u,Pu. If not you can fix this with: # certutil -M -n "auditSigningCert cert-pki-ca" -d /var/lib/pki-ca/alias -t u,u,Pu Ok, now things get really fun. The dogtag configuration file has a base64-encoded copy of most of these certificates in it. You'll need to update those by hand. What I'd recommend is for each nickname in /var/lib/pki-ca/alias do: certutil -L -d /var/lib/pki-ca/alias -n -a > /tmp/nickname Then edit /etc/pki-ca/CS.cfg and find the cert entry for each one and replace the blobs. The option names are like ca.audit_signing.cert, ca.ocsp_signing.cert, etc. It should be fairly straightforward. There are 5 certs you need to replace. Here are the nicknames and values: 'auditSigningCert cert-pki-ca': 'ca.audit_signing.cert' 'ocspSigningCert cert-pki-ca': 'ca.ocsp_signing.cert' 'caSigningCert cert-pki-ca': 'ca.signing.cert' 'subsystemCert cert-pki-ca': 'ca.subsystem.cert' 'Server-Cert cert-pki-ca': 'ca.sslserver.cert' Note that the output from certutil will be in PEM format, with headers and broken on a 64-character line. You'll need to drop the header/footer and make them into a single line. Backing up this file in advance would be a good idea. Now you can try to restart the CA to see what happens. It should come up fine: # /sbin/service pki-cad restart For the ipaCert value in /etc/httpd/alias you have another job to do. The certificates allowed to authenticate are stored in the CA LDAP database. You'll need to use ldapmodify to fix things up. Start by looking at the new value for ipaCert. You need to do two things: # certutil -L -d /etc/httpd/alias -n ipaCert Note the value of serial number. Next you need the base64-encoded value of the cert like before: # certutil -L -d /etc/httpd/alias -n ipaCert -a Again you'll need to drop the header/footer and combine this into a single line. Next see what is already there with: # ldapsearch -x -h localhost -p 7389 -D 'cn=directory manager' -W -b uid=ipara,ou=People,o=ipaca You need to replace the serial number in the description attribute with the new one. The serial number is the 2nd number. The format of the description line is: 2;;; The change is going to look something like: # ldapmodify -x -h localhost -p 7389 -D 'cn=directory manager' -W dn: uid=ipara,ou=People,o=ipaca changetype: modify add: usercertificate;binary usercertificate;binary: MII...= replace: description description: 2;9;CN=Certificate Authority,O=EXAMPLE.COM;CN=IPA RA,O=EXAMPLE.COM ^D to exit Now tackle the Apache and 389-ds certs: # /usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-REALM -n Server-Cert -p /etc/dirsrv/slapd-REALM/pwdfile.txt # /usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt # /usr/bin/ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt Use getcert to check the status of these and resubmit as needed. It may be that certmonger will notice they are near expiration time and renew automagically. Restart those services: # /sbin/service httpd restart # /sbin/service dirsrv restart Return to present day. Now test to see if the new certs are working: # kinit admin # ipa cert-show 1 This simple command actually exercises everything fairly well. If you've done everything right, and I managed to not miss a step, it should return the cert and you're done. Further testing might include adding a test host and generating a certificate for it. In the future, when these certificates expire again, you'll still have to do some of this manual labor. The certificates themselves should renew ok, but you'll need to update the configuration files and the o=ipara entry manually. rob > > Thanks for your help on this Rob. > > Regards > Roger > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Wednesday, October 30, 2013 5:07 PM > To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' > Subject: Re: [Freeipa-devel] certificate renewal > > Vaede, Roger (Contractor) wrote: >> There are two location of the alias: >> In the backup: /etc/httpd/alias/ >> In the one that has expired: /var/lib/pki-ca/alias > > These are separate entities and will need to be dealt with seprately. > /var/lib/pki-ca/alias is the NSS database that contains the certificates for the CA itself. With the subsystem certs being expired it means that the CA itself is basically dead in the water because nothing can talk to it. > > We're really moving into some uncharted waters here. I don't really want to recommend upgrading to 3.0 just to get the certs renewed, though there are lots of other good reasons to upgrade. I don't know what will happen if we try to renew the certs using the 3.0 method on a 2.x server. > > So you've got two IPA masters. Are you running the CA on both or only on one? It makes a difference in how we do the renewal because it will be more complex if you have it on both (not a show stopper). > > I *think* we can use the latest certmonger to do the majority of the heavy lifting. The basic process will be to update those bits, go back in time, the tell it to start tracking the CA certs one by one and get them renewed. We'll need to do the same with some other certs, some of which are in /etc/httpd/alias and some of which are in /etc/dirsrv/slapd-REALM/. If you have another instance of the CA we'll need to extract some of the renewed certs and import them on the other side. Then we return to present time. > > So let me know what your environment looks like and I'll try to come up with some steps to do the renewal. > > rob > From simo at redhat.com Thu Oct 31 18:50:21 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 31 Oct 2013 14:50:21 -0400 Subject: [Freeipa-devel] Reminder: Patchwork In-Reply-To: <20131031182601.GN22498@hendrix.brq.redhat.com> References: <527298CA.3080305@redhat.com> <20131031182601.GN22498@hendrix.brq.redhat.com> Message-ID: <1383245421.8612.164.camel@willson.li.ssimo.org> On Thu, 2013-10-31 at 19:26 +0100, Jakub Hrozek wrote: > On Thu, Oct 31, 2013 at 06:52:10PM +0100, Ana Krivokapic wrote: > > Hello IPA developers, > > > > I would like to remind everyone about our Patchwork instance[1]. This tool helps > > us to better coordinate work and be more efficient, so let's try to remember to > > use it consistently. It takes only a few seconds of extra work per patch > > submission/review, which could potentially save us much more time. It is > > especially useful to mark the patch as 'Under Review' when you start reviewing > > it, so that others are aware of it and they don't start reviewing the same > > patch. That way, we can avoid the situation of two people accidentally doing the > > review of the same patch at the same time. > > > > I have just cleaned up the Patchwork instance as best as I could so it should > > now hopefully reflect the real situation on the state of patches. > > > > We also have some instructions on how to use it on our wiki[2]. > > > > Thanks! > > > > [1] https://patchwork.acksyn.org/project/FreeIPA/list/ > > [2] http://www.freeipa.org/page/Contribute/Code#Tracking_patches_.28Experimental.29 > > Does setting the patch state with "X-Patchwork-Status:" header work for > anyone? I haven't tried it recently, but it would be a nice improvement. I thought I had enabled it, ping me tomorrow morning (EST) if it doesn't work and we can test it. > Currently I update all SSSD reviews manually which is a bit tedious. > With a sane e-mail client (*cough*mutt*cough*), one can add a header > with one keystroke. > > btw I also found out that automatically marking the patch as Pushed only > works for me some times. I'm not sure about the pattern, but it happens > more often for patches that are pushed to multiple branches. Do other > developers see the same? It matches the patch using a sha hash, so if you do things like stripping automatically stripping whitespaces with git am or the sender uses a different mode to generate the diff (like presence or absence of --patience) it may fail to recognize the patch. Simo. -- Simo Sorce * Red Hat, Inc * New York From jhrozek at redhat.com Thu Oct 31 19:01:58 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 31 Oct 2013 20:01:58 +0100 Subject: [Freeipa-devel] Reminder: Patchwork In-Reply-To: <1383245421.8612.164.camel@willson.li.ssimo.org> References: <527298CA.3080305@redhat.com> <20131031182601.GN22498@hendrix.brq.redhat.com> <1383245421.8612.164.camel@willson.li.ssimo.org> Message-ID: <20131031190158.GV22498@hendrix.brq.redhat.com> On Thu, Oct 31, 2013 at 02:50:21PM -0400, Simo Sorce wrote: > On Thu, 2013-10-31 at 19:26 +0100, Jakub Hrozek wrote: > > On Thu, Oct 31, 2013 at 06:52:10PM +0100, Ana Krivokapic wrote: > > > Hello IPA developers, > > > > > > I would like to remind everyone about our Patchwork instance[1]. This tool helps > > > us to better coordinate work and be more efficient, so let's try to remember to > > > use it consistently. It takes only a few seconds of extra work per patch > > > submission/review, which could potentially save us much more time. It is > > > especially useful to mark the patch as 'Under Review' when you start reviewing > > > it, so that others are aware of it and they don't start reviewing the same > > > patch. That way, we can avoid the situation of two people accidentally doing the > > > review of the same patch at the same time. > > > > > > I have just cleaned up the Patchwork instance as best as I could so it should > > > now hopefully reflect the real situation on the state of patches. > > > > > > We also have some instructions on how to use it on our wiki[2]. > > > > > > Thanks! > > > > > > [1] https://patchwork.acksyn.org/project/FreeIPA/list/ > > > [2] http://www.freeipa.org/page/Contribute/Code#Tracking_patches_.28Experimental.29 > > > > Does setting the patch state with "X-Patchwork-Status:" header work for > > anyone? I haven't tried it recently, but it would be a nice improvement. > > I thought I had enabled it, ping me tomorrow morning (EST) if it doesn't > work and we can test it. Will do, I need someone to submit an acceptable patch first :-) > > > Currently I update all SSSD reviews manually which is a bit tedious. > > With a sane e-mail client (*cough*mutt*cough*), one can add a header > > with one keystroke. > > > > btw I also found out that automatically marking the patch as Pushed only > > works for me some times. I'm not sure about the pattern, but it happens > > more often for patches that are pushed to multiple branches. Do other > > developers see the same? > > It matches the patch using a sha hash, so if you do things like > stripping automatically stripping whitespaces with git am or the sender > uses a different mode to generate the diff (like presence or absence of > --patience) it may fail to recognize the patch. Ah, stripping the whitespace might be the culprit. I do have that option enabled. Most SSSD contributors use the same git format-patch flags[1], so hopefully that shouldn't be an issue. [1] git format-patch -M -C --patience --full-index From ayoung at redhat.com Thu Oct 31 19:19:46 2013 From: ayoung at redhat.com (Adam Young) Date: Thu, 31 Oct 2013 15:19:46 -0400 Subject: [Freeipa-devel] Building FreeIPA on Debian Unstable Message-ID: <5272AD52.5030507@redhat.com> I'm about to take off for a week, and want to make sure that I don't lose the momentum I've put in so far. I spent agood portion of yesterday and today trying to get a Debian build going, and I think that this is worth sharing with the larger team. Since FreeIPA has been RPM focused thus far, I suspect that there is a need to prime-the-pump on Debian development. 1. Installed Debian testing in a VM via an ISO. I've had this VM for a while, so really just had to clone it and boot it. 2. Set the repos to be the sid (unstable) repos instead of Jessie (testing) by editing the file /etc/apt/sources.list and replacing jessie with sid 3. created a file /etc/apt/apt.conf with just the following line: APT::Default-Release "unstable"; 4.apt-get dist-upgrade 5. Reboot. 6. Loggd in and cloned the debian repo: git clone git://anonscm.debian.org/git/pkg-freeipa/freeipa.git Technically, that is a lie...I had another FreeIPA repo already cloned, so instead I edited the .git/config file to add support for the above repo, and then did a fetch and checkout of the debian-unstable branch. OK...now I am in trial and error state. I've tried doing two different tasks, both related, but I am not sure how. I used this as a guide http://www.debian.org/doc/manuals/maint-guide/build.en.html To build the package I ran: dpkg-buildpackage Which told me about all of the missing packages. I had to modify the control file as some of the packages are no longer supporting the same files. Onechange I made, which is suspect is shown here: diff --git a/debian/control b/debian/control index 66aedb4..e69cf6c 100644 --- a/debian/control +++ b/debian/control @@ -33,9 +33,7 @@ Build-Depends: quilt, debhelper (>= 9), dh-autoreconf, python-support, # server 389-ds-base-dev (>= 1.1.3), - libndr-dev, - libndr-standard-dev, - libsamba-util-dev, + samba-dev, libsvrcore-dev, libtevent-dev, uuid-dev, Eventully this failed because I need a tarball to build a package. In FreeIPA, this is done via make tarballs but that failed early on. Rob's suggestion was to run make version-update tarballs which seemed to fix the issue somewhat. The dpkg-buildpackage seems to be applying patches in place in the git repo. I suspect that I should be running it with different command line switches telling it where to put the interim files etc. I was able to fake out the process above by doing cd .. tar -zcf freeipa_3.2.1.orig.tar.gz freeipa and re-running dpkg-buildpackage. That was how I identified that the the krad.h files were not in libkrb-dev. I comment them out with the below patch: diff --git a/daemons/configure.ac b/daemons/configure.ac index 21d4e7a..cda4498 100644 --- a/daemons/configure.ac +++ b/daemons/configure.ac @@ -53,15 +53,15 @@ dnl - Check for KRB5 dnl --------------------------------------------------------------------------- AC_CHECK_HEADER(krb5.h, [], [AC_MSG_ERROR([krb5.h not found])]) -AC_CHECK_HEADER(krad.h, [], [AC_MSG_ERROR([krad.h not found])]) +#AC_CHECK_HEADER(krad.h, [], [AC_MSG_ERROR([krad.h not found])]) AC_CHECK_LIB(krb5, main, [], [AC_MSG_ERROR([libkrb5 not found])]) AC_CHECK_LIB(k5crypto, main, [krb5crypto=k5crypto], [krb5crypto=crypto]) -AC_CHECK_LIB(krad, main, [], [AC_MSG_ERROR([libkrad not found])]) +#AC_CHECK_LIB(krad, main, [], [AC_MSG_ERROR([libkrad not found])]) KRB5_LIBS="-lkrb5 -l$krb5crypto -lcom_err" -KRAD_LIBS="-lkrad" +#KRAD_LIBS="-lkrad" And...that was pretty much as far as I got. Once we get a working process we can clean up the documentation. Looks like we need 1.12 of Kerberos to get Radius support, worth pinging the Debian krb supporters to see if they have a package in the works. From Roger.Vaede at fincen.gov Thu Oct 31 20:37:18 2013 From: Roger.Vaede at fincen.gov (Vaede, Roger (Contractor)) Date: Thu, 31 Oct 2013 20:37:18 +0000 Subject: [Freeipa-devel] certificate renewal In-Reply-To: <5272A436.30002@redhat.com> References: <647D6B6B44F7C046AFE8E069C0CF70FC284FB772@hqexdb01.hqfincen.gov> <5271503C.9020207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7AE@hqexdb01.hqfincen.gov> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7CF@hqexdb01.hqfincen.gov> <52715E0E.5090207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB80C@hqexdb01.hqfincen.gov> <52716BF6.1060607@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB848@hqexdb01.hqfincen.gov> <647D6B6B44F7C046AFE8E069C0CF70FC284FB851@hqexdb01.hqfincen.gov> <527174F2.7080200@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB882@hqexdb01.hqfincen.gov> <5272A436.30002@redhat.com> Message-ID: <647D6B6B44F7C046AFE8E069C0CF70FC284FB9ED@hqexdb01.hqfincen.gov> + for nickname in '"auditSigningCert cert-pki-ca"' '"ocspSigningCert cert-pki-ca"' '"subsystemCert cert-pki-ca"' '"Server-Cert cert-pki-ca"' + /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n '"Server-Cert' 'cert-pki-ca"' -c dogtag-ipa-renew-agent -P 969321642067 Error: unused extra arguments were supplied. getcert - client certificate enrollment tool error popped up. -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Thursday, October 31, 2013 2:41 PM To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' Subject: Re: [Freeipa-devel] certificate renewal Vaede, Roger (Contractor) wrote: > I cannot upgrade to IPA 3.0 at this time, these are live machines. > I only want to renew only the primary server the one that has an expired certificate. > How can I tell if the server is running on CA? If you do a search like this: # ldapsearch -LLL -Y GSSAPI -b cn=masters,cn=ipa,cn=etc,dc=example,dc=com cn You'll get a listing, per-master, of the services on it. Look for the CA service. Some of the certificates are common among multiple CA replicas, and some are machine-specific. They can be renewed only one one master and then copied to the others, this is why I asked. As you'll see, this process is rather hairy and prone to error. I've done this any number of times on an IPA 3.x server while I worked on automating it but AFAIK never on a 2.x one. In theory it should work the same. In theory. The first thing you'll need to do is get a newer version of certmonger, at least certmonger-0.61-3.el6. IIRC you are currently tracking a bunch of bogus certs in certmonger. I'd one by one stop tracking them: # getcert list | grep Request for each cert do # getcert stop-tracking -i Next, you need to determine the PIN for the CA NSS database: # grep internal= /var/lib/pki-ca/conf/password.conf Now we need to tell certmonger about all the CA certificates it needs to renew for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" do /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n \"${nickname}\" -c dogtag-ipa-renew-agent -P done We also need to renew the agent certificate that IPA uses to authenticate: # /usr/bin/getcert start-tracking -d /etc/httpd/alias -n ipaCert -c dogtag-ipa-renew-agent -p /etc/httpd/alias/pwdfile.txt Use "getcert list" to confirm that these 5 certs are now being tracked and note the Request IDs. Now time for the wayback machine, go back to when these certs are all still valid. I'd recommend a day or two before the earliest expiration. You can force a renewal with: # getcert resubmit -i Do this for each one. Each should end up in a MONITORING state. Double-check that the audit certificate has a trust of u,u,Pu. If not you can fix this with: # certutil -M -n "auditSigningCert cert-pki-ca" -d /var/lib/pki-ca/alias -t u,u,Pu Ok, now things get really fun. The dogtag configuration file has a base64-encoded copy of most of these certificates in it. You'll need to update those by hand. What I'd recommend is for each nickname in /var/lib/pki-ca/alias do: certutil -L -d /var/lib/pki-ca/alias -n -a > /tmp/nickname Then edit /etc/pki-ca/CS.cfg and find the cert entry for each one and replace the blobs. The option names are like ca.audit_signing.cert, ca.ocsp_signing.cert, etc. It should be fairly straightforward. There are 5 certs you need to replace. Here are the nicknames and values: 'auditSigningCert cert-pki-ca': 'ca.audit_signing.cert' 'ocspSigningCert cert-pki-ca': 'ca.ocsp_signing.cert' 'caSigningCert cert-pki-ca': 'ca.signing.cert' 'subsystemCert cert-pki-ca': 'ca.subsystem.cert' 'Server-Cert cert-pki-ca': 'ca.sslserver.cert' Note that the output from certutil will be in PEM format, with headers and broken on a 64-character line. You'll need to drop the header/footer and make them into a single line. Backing up this file in advance would be a good idea. Now you can try to restart the CA to see what happens. It should come up fine: # /sbin/service pki-cad restart For the ipaCert value in /etc/httpd/alias you have another job to do. The certificates allowed to authenticate are stored in the CA LDAP database. You'll need to use ldapmodify to fix things up. Start by looking at the new value for ipaCert. You need to do two things: # certutil -L -d /etc/httpd/alias -n ipaCert Note the value of serial number. Next you need the base64-encoded value of the cert like before: # certutil -L -d /etc/httpd/alias -n ipaCert -a Again you'll need to drop the header/footer and combine this into a single line. Next see what is already there with: # ldapsearch -x -h localhost -p 7389 -D 'cn=directory manager' -W -b uid=ipara,ou=People,o=ipaca You need to replace the serial number in the description attribute with the new one. The serial number is the 2nd number. The format of the description line is: 2;;; The change is going to look something like: # ldapmodify -x -h localhost -p 7389 -D 'cn=directory manager' -W dn: uid=ipara,ou=People,o=ipaca changetype: modify add: usercertificate;binary usercertificate;binary: MII...= replace: description description: 2;9;CN=Certificate Authority,O=EXAMPLE.COM;CN=IPA RA,O=EXAMPLE.COM ^D to exit Now tackle the Apache and 389-ds certs: # /usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-REALM -n Server-Cert -p /etc/dirsrv/slapd-REALM/pwdfile.txt # /usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt # /usr/bin/ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt Use getcert to check the status of these and resubmit as needed. It may be that certmonger will notice they are near expiration time and renew automagically. Restart those services: # /sbin/service httpd restart # /sbin/service dirsrv restart Return to present day. Now test to see if the new certs are working: # kinit admin # ipa cert-show 1 This simple command actually exercises everything fairly well. If you've done everything right, and I managed to not miss a step, it should return the cert and you're done. Further testing might include adding a test host and generating a certificate for it. In the future, when these certificates expire again, you'll still have to do some of this manual labor. The certificates themselves should renew ok, but you'll need to update the configuration files and the o=ipara entry manually. rob > > Thanks for your help on this Rob. > > Regards > Roger > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Wednesday, October 30, 2013 5:07 PM > To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' > Subject: Re: [Freeipa-devel] certificate renewal > > Vaede, Roger (Contractor) wrote: >> There are two location of the alias: >> In the backup: /etc/httpd/alias/ >> In the one that has expired: /var/lib/pki-ca/alias > > These are separate entities and will need to be dealt with seprately. > /var/lib/pki-ca/alias is the NSS database that contains the certificates for the CA itself. With the subsystem certs being expired it means that the CA itself is basically dead in the water because nothing can talk to it. > > We're really moving into some uncharted waters here. I don't really want to recommend upgrading to 3.0 just to get the certs renewed, though there are lots of other good reasons to upgrade. I don't know what will happen if we try to renew the certs using the 3.0 method on a 2.x server. > > So you've got two IPA masters. Are you running the CA on both or only on one? It makes a difference in how we do the renewal because it will be more complex if you have it on both (not a show stopper). > > I *think* we can use the latest certmonger to do the majority of the heavy lifting. The basic process will be to update those bits, go back in time, the tell it to start tracking the CA certs one by one and get them renewed. We'll need to do the same with some other certs, some of which are in /etc/httpd/alias and some of which are in /etc/dirsrv/slapd-REALM/. If you have another instance of the CA we'll need to extract some of the renewed certs and import them on the other side. Then we return to present time. > > So let me know what your environment looks like and I'll try to come up with some steps to do the renewal. > > rob > From rcritten at redhat.com Thu Oct 31 20:50:04 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 31 Oct 2013 16:50:04 -0400 Subject: [Freeipa-devel] certificate renewal In-Reply-To: <647D6B6B44F7C046AFE8E069C0CF70FC284FB9ED@hqexdb01.hqfincen.gov> References: <647D6B6B44F7C046AFE8E069C0CF70FC284FB772@hqexdb01.hqfincen.gov> <5271503C.9020207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7AE@hqexdb01.hqfincen.gov> <647D6B6B44F7C046AFE8E069C0CF70FC284FB7CF@hqexdb01.hqfincen.gov> <52715E0E.5090207@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB80C@hqexdb01.hqfincen.gov> <52716BF6.1060607@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB848@hqexdb01.hqfincen.gov> <647D6B6B44F7C046AFE8E069C0CF70FC284FB851@hqexdb01.hqfincen.gov> <527174F2.7080200@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB882@hqexdb01.hqfincen.gov> <5272A436.30002@redhat.com> <647D6B6B44F7C046AFE8E069C0CF70FC284FB9ED@hqexdb01.hqfincen.gov> Message-ID: <5272C27C.9060406@redhat.com> Vaede, Roger (Contractor) wrote: > + for nickname in '"auditSigningCert cert-pki-ca"' '"ocspSigningCert cert-pki-ca"' '"subsystemCert cert-pki-ca"' '"Server-Cert cert-pki-ca"' > + /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n '"Server-Cert' 'cert-pki-ca"' -c dogtag-ipa-renew-agent -P 969321642067 > Error: unused extra arguments were supplied. > getcert - client certificate enrollment tool > > error popped up. Looks like the quoting is a problem. I guess I'd run them individually, there are only 5 after all. The nicknames have a space so you need to quote them to keep the shell happy. rob > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Thursday, October 31, 2013 2:41 PM > To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' > Subject: Re: [Freeipa-devel] certificate renewal > > Vaede, Roger (Contractor) wrote: >> I cannot upgrade to IPA 3.0 at this time, these are live machines. >> I only want to renew only the primary server the one that has an expired certificate. >> How can I tell if the server is running on CA? > > If you do a search like this: > > # ldapsearch -LLL -Y GSSAPI -b cn=masters,cn=ipa,cn=etc,dc=example,dc=com cn > > You'll get a listing, per-master, of the services on it. Look for the CA service. > > Some of the certificates are common among multiple CA replicas, and some are machine-specific. They can be renewed only one one master and then copied to the others, this is why I asked. > > As you'll see, this process is rather hairy and prone to error. I've done this any number of times on an IPA 3.x server while I worked on automating it but AFAIK never on a 2.x one. In theory it should work the same. In theory. > > The first thing you'll need to do is get a newer version of certmonger, at least certmonger-0.61-3.el6. > > IIRC you are currently tracking a bunch of bogus certs in certmonger. > I'd one by one stop tracking them: > > # getcert list | grep Request > > for each cert do > > # getcert stop-tracking -i > > Next, you need to determine the PIN for the CA NSS database: > > # grep internal= /var/lib/pki-ca/conf/password.conf > > Now we need to tell certmonger about all the CA certificates it needs to renew > > for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" "subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca" > do > /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n \"${nickname}\" -c dogtag-ipa-renew-agent -P done > > We also need to renew the agent certificate that IPA uses to authenticate: > > # /usr/bin/getcert start-tracking -d /etc/httpd/alias -n ipaCert -c dogtag-ipa-renew-agent -p /etc/httpd/alias/pwdfile.txt > > Use "getcert list" to confirm that these 5 certs are now being tracked and note the Request IDs. > > Now time for the wayback machine, go back to when these certs are all still valid. I'd recommend a day or two before the earliest expiration. > > You can force a renewal with: > > # getcert resubmit -i > > Do this for each one. Each should end up in a MONITORING state. > > Double-check that the audit certificate has a trust of u,u,Pu. If not you can fix this with: > > # certutil -M -n "auditSigningCert cert-pki-ca" -d /var/lib/pki-ca/alias -t u,u,Pu > > Ok, now things get really fun. The dogtag configuration file has a base64-encoded copy of most of these certificates in it. You'll need to update those by hand. > > What I'd recommend is for each nickname in /var/lib/pki-ca/alias do: > > certutil -L -d /var/lib/pki-ca/alias -n -a > /tmp/nickname > > Then edit /etc/pki-ca/CS.cfg and find the cert entry for each one and replace the blobs. The option names are like ca.audit_signing.cert, ca.ocsp_signing.cert, etc. It should be fairly straightforward. There are 5 certs you need to replace. > > Here are the nicknames and values: > > 'auditSigningCert cert-pki-ca': 'ca.audit_signing.cert' > 'ocspSigningCert cert-pki-ca': 'ca.ocsp_signing.cert' > 'caSigningCert cert-pki-ca': 'ca.signing.cert' > 'subsystemCert cert-pki-ca': 'ca.subsystem.cert' > 'Server-Cert cert-pki-ca': 'ca.sslserver.cert' > > Note that the output from certutil will be in PEM format, with headers and broken on a 64-character line. You'll need to drop the header/footer and make them into a single line. > > Backing up this file in advance would be a good idea. > > Now you can try to restart the CA to see what happens. It should come up > fine: > > # /sbin/service pki-cad restart > > For the ipaCert value in /etc/httpd/alias you have another job to do. > The certificates allowed to authenticate are stored in the CA LDAP database. You'll need to use ldapmodify to fix things up. > > Start by looking at the new value for ipaCert. You need to do two things: > > # certutil -L -d /etc/httpd/alias -n ipaCert > > Note the value of serial number. > > Next you need the base64-encoded value of the cert like before: > > # certutil -L -d /etc/httpd/alias -n ipaCert -a > > Again you'll need to drop the header/footer and combine this into a single line. > > Next see what is already there with: > > # ldapsearch -x -h localhost -p 7389 -D 'cn=directory manager' -W -b uid=ipara,ou=People,o=ipaca > > You need to replace the serial number in the description attribute with the new one. The serial number is the 2nd number. The format of the description line is: > > 2;;; > > The change is going to look something like: > > # ldapmodify -x -h localhost -p 7389 -D 'cn=directory manager' -W > dn: uid=ipara,ou=People,o=ipaca > changetype: modify > add: usercertificate;binary > usercertificate;binary: MII...= > replace: description > description: 2;9;CN=Certificate Authority,O=EXAMPLE.COM;CN=IPA RA,O=EXAMPLE.COM ^D to exit > > Now tackle the Apache and 389-ds certs: > > # /usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-REALM -n Server-Cert -p /etc/dirsrv/slapd-REALM/pwdfile.txt > > # /usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA/pwdfile.txt > > # /usr/bin/ipa-getcert start-tracking -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt > > Use getcert to check the status of these and resubmit as needed. It may be that certmonger will notice they are near expiration time and renew automagically. > > Restart those services: > > # /sbin/service httpd restart > # /sbin/service dirsrv restart > > Return to present day. > > Now test to see if the new certs are working: > > # kinit admin > # ipa cert-show 1 > > This simple command actually exercises everything fairly well. > > If you've done everything right, and I managed to not miss a step, it should return the cert and you're done. Further testing might include adding a test host and generating a certificate for it. > > In the future, when these certificates expire again, you'll still have to do some of this manual labor. The certificates themselves should renew ok, but you'll need to update the configuration files and the o=ipara entry manually. > > rob > >> >> Thanks for your help on this Rob. >> >> Regards >> Roger >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Wednesday, October 30, 2013 5:07 PM >> To: Vaede, Roger (Contractor); 'freeipa-devel at redhat.com' >> Subject: Re: [Freeipa-devel] certificate renewal >> >> Vaede, Roger (Contractor) wrote: >>> There are two location of the alias: >>> In the backup: /etc/httpd/alias/ >>> In the one that has expired: /var/lib/pki-ca/alias >> >> These are separate entities and will need to be dealt with seprately. >> /var/lib/pki-ca/alias is the NSS database that contains the certificates for the CA itself. With the subsystem certs being expired it means that the CA itself is basically dead in the water because nothing can talk to it. >> >> We're really moving into some uncharted waters here. I don't really want to recommend upgrading to 3.0 just to get the certs renewed, though there are lots of other good reasons to upgrade. I don't know what will happen if we try to renew the certs using the 3.0 method on a 2.x server. >> >> So you've got two IPA masters. Are you running the CA on both or only on one? It makes a difference in how we do the renewal because it will be more complex if you have it on both (not a show stopper). >> >> I *think* we can use the latest certmonger to do the majority of the heavy lifting. The basic process will be to update those bits, go back in time, the tell it to start tracking the CA certs one by one and get them renewed. We'll need to do the same with some other certs, some of which are in /etc/httpd/alias and some of which are in /etc/dirsrv/slapd-REALM/. If you have another instance of the CA we'll need to extract some of the renewed certs and import them on the other side. Then we return to present time. >> >> So let me know what your environment looks like and I'll try to come up with some steps to do the renewal. >> >> rob >> > >