From rcritten at redhat.com Tue Jul 1 14:10:25 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Jul 2008 10:10:25 -0400 Subject: [Freeipa-devel] [PATCH] Fix ipa-server-certinstall part 1 Message-ID: <486A3AD1.10709@redhat.com> This fixes the Apache NSS database file permission and ownership when importing a web server cert. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-53-certinstall.patch Type: text/x-patch Size: 1365 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Jul 1 14:19:49 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Jul 2008 10:19:49 -0400 Subject: [Freeipa-devel] [PATCH] ] Fix ipa-server-certinstall part 2 Message-ID: <486A3D05.5050400@redhat.com> The ipa-server-certinstall program was using the wrong function to convert realm into a DS instance name so it wasn't doing the "." to "-" conversion. This fixes that. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-54-certinstall.patch Type: text/x-patch Size: 1032 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Jul 1 16:48:50 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 01 Jul 2008 12:48:50 -0400 Subject: [Freeipa-devel] [PATCH] Fix ipa-server-certinstall part 1 In-Reply-To: <486A3AD1.10709@redhat.com> References: <486A3AD1.10709@redhat.com> Message-ID: <1214930930.353.66.camel@localhost.localdomain> On Tue, 2008-07-01 at 10:10 -0400, Rob Crittenden wrote: > This fixes the Apache NSS database file permission and ownership when > importing a web server cert. ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Jul 1 16:48:59 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 01 Jul 2008 12:48:59 -0400 Subject: [Freeipa-devel] [PATCH] ] Fix ipa-server-certinstall part 2 In-Reply-To: <486A3D05.5050400@redhat.com> References: <486A3D05.5050400@redhat.com> Message-ID: <1214930939.353.68.camel@localhost.localdomain> On Tue, 2008-07-01 at 10:19 -0400, Rob Crittenden wrote: > The ipa-server-certinstall program was using the wrong function to > convert realm into a DS instance name so it wasn't doing the "." to > "-" > conversion. This fixes that. ack -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Jul 1 18:24:48 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Jul 2008 14:24:48 -0400 Subject: [Freeipa-devel] [PATCH] add -v/--verbose docs to man pages Message-ID: <486A7670.8020708@redhat.com> I added a -v/--verbose debug option to the command-line utilities to display the XML-RPC conversation but didn't document it in the man pages. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-55-verbose.patch Type: text/x-patch Size: 11680 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Jul 1 19:13:20 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Jul 2008 15:13:20 -0400 Subject: [Freeipa-devel] [PATCH] Fix ipa-server-certinstall part 1 In-Reply-To: <1214930930.353.66.camel@localhost.localdomain> References: <486A3AD1.10709@redhat.com> <1214930930.353.66.camel@localhost.localdomain> Message-ID: <486A81D0.3000409@redhat.com> Simo Sorce wrote: > On Tue, 2008-07-01 at 10:10 -0400, Rob Crittenden wrote: >> This fixes the Apache NSS database file permission and ownership when >> importing a web server cert. > > ack. > > Simo. > pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Jul 1 19:13:28 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 01 Jul 2008 15:13:28 -0400 Subject: [Freeipa-devel] [PATCH] ] Fix ipa-server-certinstall part 2 In-Reply-To: <1214930939.353.68.camel@localhost.localdomain> References: <486A3D05.5050400@redhat.com> <1214930939.353.68.camel@localhost.localdomain> Message-ID: <486A81D8.3050102@redhat.com> Simo Sorce wrote: > On Tue, 2008-07-01 at 10:19 -0400, Rob Crittenden wrote: >> The ipa-server-certinstall program was using the wrong function to >> convert realm into a DS instance name so it wasn't doing the "." to >> "-" >> conversion. This fixes that. > > > ack > pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Jul 1 19:58:07 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 01 Jul 2008 15:58:07 -0400 Subject: [Freeipa-devel] [PATCH] add -v/--verbose docs to man pages In-Reply-To: <486A7670.8020708@redhat.com> References: <486A7670.8020708@redhat.com> Message-ID: <1214942287.353.80.camel@localhost.localdomain> On Tue, 2008-07-01 at 14:24 -0400, Rob Crittenden wrote: > I added a -v/--verbose debug option to the command-line utilities to > display the XML-RPC conversation but didn't document it in the man > pages. ack -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Jul 2 14:11:21 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 02 Jul 2008 10:11:21 -0400 Subject: [Freeipa-devel] [PATCH] Disable krb4 support Message-ID: <1215007881.353.92.camel@localhost.localdomain> -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-sure-we-listen-only-on-the-krb5-port-and-theref.patch Type: application/mbox Size: 707 bytes Desc: not available URL: From sgallagh at redhat.com Wed Jul 2 14:15:34 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 02 Jul 2008 10:15:34 -0400 Subject: [Freeipa-devel] [PATCH] Disable krb4 support In-Reply-To: <1215007881.353.92.camel@localhost.localdomain> References: <1215007881.353.92.camel@localhost.localdomain> Message-ID: <486B8D86.8000403@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simo Sorce wrote: > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhrjYYACgkQc7MaxVic+2ooFwCffNskNi9fWE+YfoPa4fnoB4RM SKsAn2kTgmeD4TW9nEYD6RhJQYjMTo59 =OGSu -----END PGP SIGNATURE----- From rcritten at redhat.com Wed Jul 2 14:22:34 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Jul 2008 10:22:34 -0400 Subject: [Freeipa-devel] [PATCH] Disable krb4 support In-Reply-To: <1215007881.353.92.camel@localhost.localdomain> References: <1215007881.353.92.camel@localhost.localdomain> Message-ID: <486B8F2A.8090809@redhat.com> Simo Sorce wrote: > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Do we need to listen on 750 as well? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Wed Jul 2 14:30:47 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 02 Jul 2008 10:30:47 -0400 Subject: [Freeipa-devel] [PATCH] Disable krb4 support In-Reply-To: <486B8F2A.8090809@redhat.com> References: <1215007881.353.92.camel@localhost.localdomain> <486B8F2A.8090809@redhat.com> Message-ID: <1215009047.353.94.camel@localhost.localdomain> On Wed, 2008-07-02 at 10:22 -0400, Rob Crittenden wrote: > Do we need to listen on 750 as well? I am explicitly disabling listening on 750 (the krb4 port). (default is 88,750) Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Jul 2 14:37:21 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Jul 2008 10:37:21 -0400 Subject: [Freeipa-devel] [PATCH] Disable krb4 support In-Reply-To: <1215009047.353.94.camel@localhost.localdomain> References: <1215007881.353.92.camel@localhost.localdomain> <486B8F2A.8090809@redhat.com> <1215009047.353.94.camel@localhost.localdomain> Message-ID: <486B92A1.2030101@redhat.com> Simo Sorce wrote: > On Wed, 2008-07-02 at 10:22 -0400, Rob Crittenden wrote: > >> Do we need to listen on 750 as well? > > I am explicitly disabling listening on 750 (the krb4 port). > (default is 88,750) > > Simo. > Oh, duh, hence that port being kerberos-iv :-( A very embarrassed ack. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Wed Jul 2 15:04:34 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 02 Jul 2008 11:04:34 -0400 Subject: [Freeipa-devel] [PATCH] Disable krb4 support In-Reply-To: <486B92A1.2030101@redhat.com> References: <1215007881.353.92.camel@localhost.localdomain> <486B8F2A.8090809@redhat.com> <1215009047.353.94.camel@localhost.localdomain> <486B92A1.2030101@redhat.com> Message-ID: <1215011074.353.105.camel@localhost.localdomain> On Wed, 2008-07-02 at 10:37 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Wed, 2008-07-02 at 10:22 -0400, Rob Crittenden wrote: > > > >> Do we need to listen on 750 as well? > > > > I am explicitly disabling listening on 750 (the krb4 port). > > (default is 88,750) > > > > Simo. > > > > Oh, duh, hence that port being kerberos-iv :-( > > A very embarrassed ack. I'd blame lack of proper coffee* in the morning :-) Simo. * I have to, from time to time, as well :) -- Simo Sorce * Red Hat, Inc * New York From janfrode at tanso.net Wed Jul 2 17:04:09 2008 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Wed, 2 Jul 2008 19:04:09 +0200 Subject: [Freeipa-devel] [PATCH] fix segfault in password change In-Reply-To: <1214849813.353.10.camel@localhost.localdomain> References: <1214591466.3822.295.camel@localhost.localdomain> <1214592825.3822.297.camel@localhost.localdomain> <48653BF2.80909@redhat.com> <1214596837.3822.304.camel@localhost.localdomain> <48654B74.5050007@redhat.com> <1214849813.353.10.camel@localhost.localdomain> Message-ID: <20080702170409.GA16116@lc4eb5760521341.ibm.com> On Mon, Jun 30, 2008 at 02:16:53PM -0400, Simo Sorce wrote: > > > > > > > > > Ok, attached patch tries to avoid memory leaks too. > > > > > ack > > pushed Great, got it today, and it's working fine. Only issue so far is that I've had a couple of avc denials : type=1400 audit(1215017904.493:17): avc: denied { read } for pid=2925 comm="ipa_kpasswd" name="net" dev=proc ino=4026531867 scontext=unconfined_u:system_r:ipa_kpasswd_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=lnk_file type=1400 audit(1215017904.494:18): avc: denied { read } for pid=2925 comm="ipa_kpasswd" name="unix" dev=proc ino=4026533123 scontext=unconfined_u:system_r:ipa_kpasswd_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=file That's for /proc/net /proc/net/unix And ipa_kpasswd_t might need these: #============= ipa_kpasswd_t ============== allow ipa_kpasswd_t proc_net_t:file read; allow ipa_kpasswd_t proc_net_t:lnk_file read; -jf From janfrode at tanso.net Wed Jul 2 17:20:18 2008 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Wed, 2 Jul 2008 19:20:18 +0200 Subject: [Freeipa-devel] self service Message-ID: <20080702172018.GB16116@lc4eb5760521341.ibm.com> There is a "self service" in the webgui, that can be used once you have an account, but how are users supposed to get the accounts registered ? It would be great if there was a "Click here to apply for account" for unregistered users. Which ipa-admins can approve/deny. Or is there something like this hidden anywhere ? At least it would be nice to be able to delegate the creation of new users to non-ipa-admins. I.e. Group leaders in our organization should be allowed to create new accounts that will be part of their group. We need something like this to put the last nail in the coffin for Sun Identity Manager :-) -jf From rcritten at redhat.com Wed Jul 2 17:30:23 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 02 Jul 2008 13:30:23 -0400 Subject: [Freeipa-devel] self service In-Reply-To: <20080702172018.GB16116@lc4eb5760521341.ibm.com> References: <20080702172018.GB16116@lc4eb5760521341.ibm.com> Message-ID: <486BBB2F.7050504@redhat.com> Jan-Frode Myklebust wrote: > There is a "self service" in the webgui, that can be used once you have > an account, but how are users supposed to get the accounts registered ? > > It would be great if there was a "Click here to apply for account" for > unregistered users. Which ipa-admins can approve/deny. Or is there > something like this hidden anywhere ? At least it would be nice to be > able to delegate the creation of new users to non-ipa-admins. I.e. Group > leaders in our organization should be allowed to create new accounts > that will be part of their group. > > We need something like this to put the last nail in the coffin for Sun > Identity Manager :-) I don't know that we'll add an "apply for account" page but a more flexible delegation system is planned for version 2. Current delegations are limited to "group A can write attributes of members in group B". rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Wed Jul 2 19:21:35 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 02 Jul 2008 15:21:35 -0400 Subject: [Freeipa-devel] self service In-Reply-To: <20080702172018.GB16116@lc4eb5760521341.ibm.com> References: <20080702172018.GB16116@lc4eb5760521341.ibm.com> Message-ID: <1215026495.353.129.camel@localhost.localdomain> On Wed, 2008-07-02 at 19:20 +0200, Jan-Frode Myklebust wrote: > There is a "self service" in the webgui, that can be used once you have > an account, but how are users supposed to get the accounts registered ? > > It would be great if there was a "Click here to apply for account" for > unregistered users. Which ipa-admins can approve/deny. Or is there > something like this hidden anywhere ? At least it would be nice to be > able to delegate the creation of new users to non-ipa-admins. I.e. Group > leaders in our organization should be allowed to create new accounts > that will be part of their group. > > We need something like this to put the last nail in the coffin for Sun > Identity Manager :-) Making it possible for a set of accounts to create users is quite easy you should be able to do that just by making these accounts part of the "Admins" group. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Jul 2 19:28:12 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 02 Jul 2008 15:28:12 -0400 Subject: [Freeipa-devel] [PATCH] Disable krb4 support In-Reply-To: <486B8D86.8000403@redhat.com> References: <1215007881.353.92.camel@localhost.localdomain> <486B8D86.8000403@redhat.com> Message-ID: <1215026892.353.135.camel@localhost.localdomain> On Wed, 2008-07-02 at 10:15 -0400, Stephen Gallagher wrote: > ack pushed to master -- Simo Sorce * Red Hat, Inc * New York From vcardprocessor at vcardprocessor.com Wed Jul 2 21:32:54 2008 From: vcardprocessor at vcardprocessor.com (Eric) Date: Wed, 2 Jul 2008 14:32:54 -0700 Subject: [Freeipa-devel] Failed to decrypt password Message-ID: <200872143254.067381@C840> Hello, When the system requests a new password when I do 'kinit user1' for the first time, I get the following error: kinit(v5): Cannot contact any KDC for requested realm while getting initial credentials kpasswd[1928]: Failed to decrypt password: Incorrect net address Is it a DNS problem? Eric. From ssorce at redhat.com Wed Jul 2 21:53:56 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 02 Jul 2008 17:53:56 -0400 Subject: [Freeipa-devel] Failed to decrypt password In-Reply-To: <200872143254.067381@C840> References: <200872143254.067381@C840> Message-ID: <1215035636.353.145.camel@localhost.localdomain> On Wed, 2008-07-02 at 14:32 -0700, Eric wrote: > Hello, > > When the system requests a new password when I do 'kinit user1' for the first time, I get the following error: > > kinit(v5): Cannot contact any KDC for requested realm while getting initial credentials > kpasswd[1928]: Failed to decrypt password: Incorrect net address > > Is it a DNS problem? No, I think you are using an older version of freeipa, we fixed some problems with ipa_kpasswd and multihomed systems that might cause this error, what version are you using ? Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Jul 2 22:00:37 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 02 Jul 2008 18:00:37 -0400 Subject: [Freeipa-devel] [PATCH] fix selinux policy for ipa_kpasswd Message-ID: <1215036037.353.149.camel@localhost.localdomain> -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-After-the-rework-of-the-code-that-binds-to-specific.patch Type: application/mbox Size: 1197 bytes Desc: not available URL: From matt.flusche at cox.net Thu Jul 3 03:36:22 2008 From: matt.flusche at cox.net (Matt Flusche) Date: Wed, 2 Jul 2008 22:36:22 -0500 Subject: [Freeipa-devel] 1.1.0-4 fedora 9 - password change still crashing ns-slapd Message-ID: <9D80D0B0-A7C6-4E7A-ABC4-F21A6CD06460@cox.net> I've upgraded to 1.1.0-4 for fedora 9 (x86_64) and am still having ns- slapd crash during password changes. # rpm -q ipa-server ipa-server-1.1.0-4.fc9.x86_64 # uname -a Linux ruff.flusche.co 2.6.25.9-76.fc9.x86_64 #1 SMP Fri Jun 27 15:58:30 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x41992950 (LWP 9201)] 0x000000392fc808f0 in strcmp () from /lib64/libc.so.6 (gdb) bt #0 0x000000392fc808f0 in strcmp () from /lib64/libc.so.6 #1 0x00007f95ec9dc093 in ?? () from /usr/lib64/dirsrv/plugins/ libipa_pwd_extop.so #2 0x00007f95ec9dd778 in ?? () from /usr/lib64/dirsrv/plugins/ libipa_pwd_extop.so #3 0x0000000000188f05 in plugin_call_exop_plugins (pb=0x1533f30, oid=0x150fc50 "1.3.6.1.4.1.4203.1.11.1") at ldap/servers/slapd/plugin.c:393 #4 0x000000000041698f in do_extended (pb=0x1533f30) at ldap/servers/ slapd/extendop.c:300 #5 0x0000000000412086 in connection_threadmain () at ldap/servers/ slapd/connection.c:562 #6 0x0000003ee8e29aa3 in _pt_root (arg=) at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:221 #7 0x000000393080729a in start_thread (arg=) at pthread_create.c:297 #8 0x000000392fce42cd in clone () from /lib64/libc.so.6 from /var/log/messages (during ns-slapd restart & crash) Jul 2 22:31:30 ruff ns-slapd: auxpropfunc error invalid parameter supplied Jul 2 22:31:30 ruff ns-slapd: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb Jul 2 22:31:30 ruff ns-slapd: sql_select option missing Jul 2 22:31:30 ruff ns-slapd: auxpropfunc error no mechanism available Jul 2 22:31:30 ruff ns-slapd: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql Jul 2 22:32:30 ruff kernel: ns-slapd[9662]: segfault at 0 ip 392fc808f0 sp 41736c38 error 4 in libc-2.8.so[392fc00000+162000] Jul 2 22:32:30 ruff kpasswd[9679]: ldap_result() failed. (-1) Jul 2 22:32:30 ruff kpasswd[9679]: Server Error while performing LDAP password change From rcritten at redhat.com Thu Jul 3 12:19:36 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 03 Jul 2008 08:19:36 -0400 Subject: [Freeipa-devel] [PATCH] fix selinux policy for ipa_kpasswd In-Reply-To: <1215036037.353.149.camel@localhost.localdomain> References: <1215036037.353.149.camel@localhost.localdomain> Message-ID: <486CC3D8.20504@redhat.com> Simo Sorce wrote: > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Jul 3 16:15:00 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 03 Jul 2008 12:15:00 -0400 Subject: [Freeipa-devel] 1.1.0-4 fedora 9 - password change still crashing ns-slapd In-Reply-To: <9D80D0B0-A7C6-4E7A-ABC4-F21A6CD06460@cox.net> References: <9D80D0B0-A7C6-4E7A-ABC4-F21A6CD06460@cox.net> Message-ID: <1215101700.353.165.camel@localhost.localdomain> On Wed, 2008-07-02 at 22:36 -0500, Matt Flusche wrote: > I've upgraded to 1.1.0-4 for fedora 9 (x86_64) and am still having ns- > slapd crash during password changes. > > # rpm -q ipa-server > ipa-server-1.1.0-4.fc9.x86_64 > > # uname -a > Linux ruff.flusche.co 2.6.25.9-76.fc9.x86_64 #1 SMP Fri Jun 27 > 15:58:30 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x41992950 (LWP 9201)] > 0x000000392fc808f0 in strcmp () from /lib64/libc.so.6 > (gdb) bt > #0 0x000000392fc808f0 in strcmp () from /lib64/libc.so.6 > #1 0x00007f95ec9dc093 in ?? () from /usr/lib64/dirsrv/plugins/ > libipa_pwd_extop.so > #2 0x00007f95ec9dd778 in ?? () from /usr/lib64/dirsrv/plugins/ > libipa_pwd_extop.so > #3 0x0000000000188f05 in plugin_call_exop_plugins (pb=0x1533f30, > oid=0x150fc50 "1.3.6.1.4.1.4203.1.11.1") > at ldap/servers/slapd/plugin.c:393 > #4 0x000000000041698f in do_extended (pb=0x1533f30) at ldap/servers/ > slapd/extendop.c:300 > #5 0x0000000000412086 in connection_threadmain () at ldap/servers/ > slapd/connection.c:562 > #6 0x0000003ee8e29aa3 in _pt_root (arg=) > at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:221 > #7 0x000000393080729a in start_thread (arg=) at > pthread_create.c:297 > #8 0x000000392fce42cd in clone () from /lib64/libc.so.6 > > > from /var/log/messages (during ns-slapd restart & crash) > > Jul 2 22:31:30 ruff ns-slapd: auxpropfunc error invalid parameter > supplied > Jul 2 22:31:30 ruff ns-slapd: _sasl_plugin_load failed on > sasl_auxprop_plug_init for plugin: ldapdb > Jul 2 22:31:30 ruff ns-slapd: sql_select option missing > Jul 2 22:31:30 ruff ns-slapd: auxpropfunc error no mechanism available > Jul 2 22:31:30 ruff ns-slapd: _sasl_plugin_load failed on > sasl_auxprop_plug_init for plugin: sql > Jul 2 22:32:30 ruff kernel: ns-slapd[9662]: segfault at 0 ip > 392fc808f0 sp 41736c38 error 4 in libc-2.8.so[392fc00000+162000] > Jul 2 22:32:30 ruff kpasswd[9679]: ldap_result() failed. (-1) > Jul 2 22:32:30 ruff kpasswd[9679]: Server Error while performing > LDAP password change > This looks strange. Can you load debuginfo packages so that I can understand where it is actually crashing exactly ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Jul 3 19:30:30 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 03 Jul 2008 15:30:30 -0400 Subject: [Freeipa-devel] [PATCH] add -v/--verbose docs to man pages In-Reply-To: <1214942287.353.80.camel@localhost.localdomain> References: <486A7670.8020708@redhat.com> <1214942287.353.80.camel@localhost.localdomain> Message-ID: <486D28D6.7060505@redhat.com> Simo Sorce wrote: > On Tue, 2008-07-01 at 14:24 -0400, Rob Crittenden wrote: >> I added a -v/--verbose debug option to the command-line utilities to >> display the XML-RPC conversation but didn't document it in the man >> pages. > > ack > pushed to ipa-1-0 and master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Jul 3 20:12:21 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 03 Jul 2008 16:12:21 -0400 Subject: [Freeipa-devel] Using your own certs Message-ID: <486D32A5.7090703@redhat.com> We wanted to provide an easy way to replace the self-signed certificates generated during IPA installation so we created a tool, ipa-server-certinstall. Unfortunately this is pretty badly broken in v1.1. I've fixed it in the tip but there is one last issue sort of peripherally related. When we create a replica using ipa-replica-prepare we pre-generate the SSL certs for use on the replica. If you've replaced the DS certs then you no longer have a CA to issue the certs so the replica preparation falls down pretty hard. The "CA" in IPA isn't really much of anything but we do keep a serial number file (/usr/share/ipa/serialno) to keep track of things. What I was thinking is that if the DS certificate is replaced then we rename/delete this file. I can then test for existence so I can do the right thing in ipa-replica-prepare (by prompting for the 2 PKCS#12 files to install on the remote server). Otherwise I'm going to need to test for the CA using certutil and try to parse the output to see whether I can continue or not. Does this sound reasonable? thanks rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Jul 3 20:26:45 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 03 Jul 2008 16:26:45 -0400 Subject: [Freeipa-devel] Using your own certs In-Reply-To: <486D32A5.7090703@redhat.com> References: <486D32A5.7090703@redhat.com> Message-ID: <1215116805.353.191.camel@localhost.localdomain> On Thu, 2008-07-03 at 16:12 -0400, Rob Crittenden wrote: > We wanted to provide an easy way to replace the self-signed certificates > generated during IPA installation so we created a tool, > ipa-server-certinstall. Unfortunately this is pretty badly broken in > v1.1. I've fixed it in the tip but there is one last issue sort of > peripherally related. > > When we create a replica using ipa-replica-prepare we pre-generate the > SSL certs for use on the replica. If you've replaced the DS certs then > you no longer have a CA to issue the certs so the replica preparation > falls down pretty hard. > > The "CA" in IPA isn't really much of anything but we do keep a serial > number file (/usr/share/ipa/serialno) to keep track of things. What I > was thinking is that if the DS certificate is replaced then we > rename/delete this file. I can then test for existence so I can do the > right thing in ipa-replica-prepare (by prompting for the 2 PKCS#12 files > to install on the remote server). > > Otherwise I'm going to need to test for the CA using certutil and try to > parse the output to see whether I can continue or not. > > Does this sound reasonable? Works for me, serialno is useless anyway if we are not using a selfsigned ca, go that route. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Jul 3 20:28:29 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 03 Jul 2008 16:28:29 -0400 Subject: [Freeipa-devel] Using your own certs In-Reply-To: <1215116805.353.191.camel@localhost.localdomain> References: <486D32A5.7090703@redhat.com> <1215116805.353.191.camel@localhost.localdomain> Message-ID: <1215116909.353.194.camel@localhost.localdomain> On Thu, 2008-07-03 at 16:26 -0400, Simo Sorce wrote: > On Thu, 2008-07-03 at 16:12 -0400, Rob Crittenden wrote: > > We wanted to provide an easy way to replace the self-signed certificates > > generated during IPA installation so we created a tool, > > ipa-server-certinstall. Unfortunately this is pretty badly broken in > > v1.1. I've fixed it in the tip but there is one last issue sort of > > peripherally related. > > > > When we create a replica using ipa-replica-prepare we pre-generate the > > SSL certs for use on the replica. If you've replaced the DS certs then > > you no longer have a CA to issue the certs so the replica preparation > > falls down pretty hard. > > > > The "CA" in IPA isn't really much of anything but we do keep a serial > > number file (/usr/share/ipa/serialno) to keep track of things. What I > > was thinking is that if the DS certificate is replaced then we > > rename/delete this file. I can then test for existence so I can do the > > right thing in ipa-replica-prepare (by prompting for the 2 PKCS#12 files > > to install on the remote server). > > > > Otherwise I'm going to need to test for the CA using certutil and try to > > parse the output to see whether I can continue or not. > > > > Does this sound reasonable? > > Works for me, serialno is useless anyway if we are not using a > selfsigned ca, go that route. The only gotcha is that we must move that file (in any case) unde /var/lib/ipa, as we are not supposed to change stuff in /usr during normal operations. Also we must make sure that file is not owned by the rpm package or rpm will a) complain, b) put back a new file on upgrade. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Jul 3 21:13:04 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 03 Jul 2008 17:13:04 -0400 Subject: [Freeipa-devel] [PATCH] Have ipa-delgroup be more careful Message-ID: <486D40E0.70002@redhat.com> The group delete XML-RPC function takes the DN as the argument so it is up to the client to provide the right group. This patch runs through the search results for the group to delete and explodes the returned DNs looking for an exact match of cn=GROUP_TO_DELETE So even if multiple groups are returned we'll do the right thing. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-57-delgroup.patch Type: text/x-patch Size: 1362 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Jul 3 21:46:13 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 03 Jul 2008 17:46:13 -0400 Subject: [Freeipa-devel] [PATCH] Have ipa-delgroup be more careful In-Reply-To: <486D40E0.70002@redhat.com> References: <486D40E0.70002@redhat.com> Message-ID: <1215121573.353.198.camel@localhost.localdomain> On Thu, 2008-07-03 at 17:13 -0400, Rob Crittenden wrote: > The group delete XML-RPC function takes the DN as the argument so it > is > up to the client to provide the right group. > > This patch runs through the search results for the group to delete > and > explodes the returned DNs looking for an exact match of > cn=GROUP_TO_DELETE > > So even if multiple groups are returned we'll do the right thing. ack, exactly the kind of patch I was expecting :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From matt.flusche at cox.net Fri Jul 4 02:38:29 2008 From: matt.flusche at cox.net (Matt Flusche) Date: Thu, 3 Jul 2008 21:38:29 -0500 Subject: [Freeipa-devel] 1.1.0-4 fedora 9 - password change still crashing ns-slapd In-Reply-To: <1215101700.353.165.camel@localhost.localdomain> References: <9D80D0B0-A7C6-4E7A-ABC4-F21A6CD06460@cox.net> <1215101700.353.165.camel@localhost.localdomain> Message-ID: On Jul 3, 2008, at 11:15 AM, Simo Sorce wrote: > On Wed, 2008-07-02 at 22:36 -0500, Matt Flusche wrote: >> I've upgraded to 1.1.0-4 for fedora 9 (x86_64) and am still having >> ns- >> slapd crash during password changes. >> >> # rpm -q ipa-server >> ipa-server-1.1.0-4.fc9.x86_64 >> >> # uname -a >> Linux ruff.flusche.co 2.6.25.9-76.fc9.x86_64 #1 SMP Fri Jun 27 >> 15:58:30 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0x41992950 (LWP 9201)] >> 0x000000392fc808f0 in strcmp () from /lib64/libc.so.6 >> (gdb) bt >> #0 0x000000392fc808f0 in strcmp () from /lib64/libc.so.6 >> #1 0x00007f95ec9dc093 in ?? () from /usr/lib64/dirsrv/plugins/ >> libipa_pwd_extop.so >> #2 0x00007f95ec9dd778 in ?? () from /usr/lib64/dirsrv/plugins/ >> libipa_pwd_extop.so >> #3 0x0000000000188f05 in plugin_call_exop_plugins (pb=0x1533f30, >> oid=0x150fc50 "1.3.6.1.4.1.4203.1.11.1") >> at ldap/servers/slapd/plugin.c:393 >> #4 0x000000000041698f in do_extended (pb=0x1533f30) at ldap/servers/ >> slapd/extendop.c:300 >> #5 0x0000000000412086 in connection_threadmain () at ldap/servers/ >> slapd/connection.c:562 >> #6 0x0000003ee8e29aa3 in _pt_root (arg=) >> at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:221 >> #7 0x000000393080729a in start_thread (arg=) at >> pthread_create.c:297 >> #8 0x000000392fce42cd in clone () from /lib64/libc.so.6 >> >> >> from /var/log/messages (during ns-slapd restart & crash) >> >> Jul 2 22:31:30 ruff ns-slapd: auxpropfunc error invalid parameter >> supplied >> Jul 2 22:31:30 ruff ns-slapd: _sasl_plugin_load failed on >> sasl_auxprop_plug_init for plugin: ldapdb >> Jul 2 22:31:30 ruff ns-slapd: sql_select option missing >> Jul 2 22:31:30 ruff ns-slapd: auxpropfunc error no mechanism >> available >> Jul 2 22:31:30 ruff ns-slapd: _sasl_plugin_load failed on >> sasl_auxprop_plug_init for plugin: sql >> Jul 2 22:32:30 ruff kernel: ns-slapd[9662]: segfault at 0 ip >> 392fc808f0 sp 41736c38 error 4 in libc-2.8.so[392fc00000+162000] >> Jul 2 22:32:30 ruff kpasswd[9679]: ldap_result() failed. (-1) >> Jul 2 22:32:30 ruff kpasswd[9679]: Server Error while performing >> LDAP password change >> > > This looks strange. > Can you load debuginfo packages so that I can understand where it is > actually crashing exactly ? > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > Is this what you are looking for? Regards, Matt Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x41044950 (LWP 13194)] 0x000000392fc808f0 in strcmp () from /lib64/libc.so.6 (gdb) bt #0 0x000000392fc808f0 in strcmp () from /lib64/libc.so.6 #1 0x00007ff13cb0e093 in ipapwd_chpwop (pb=0x223c780) at ipa_pwd_extop.c:1321 #2 0x00007ff13cb0f778 in ipapwd_extop (pb=0x223c780) at ipa_pwd_extop.c:2865 #3 0x0000000000188f05 in plugin_call_exop_plugins (pb=0x223c780, oid=0x2242ca0 "1.3.6.1.4.1.4203.1.11.1") at ldap/servers/slapd/ plugin.c:393 #4 0x000000000041698f in do_extended (pb=0x223c780) at ldap/servers/ slapd/extendop.c:300 #5 0x0000000000412086 in connection_threadmain () at ldap/servers/ slapd/connection.c:562 #6 0x0000003ee8e29aa3 in _pt_root (arg=) at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:221 #7 0x000000393080729a in start_thread (arg=) at pthread_create.c:297 #8 0x000000392fce42cd in clone () from /lib64/libc.so.6 From vcardprocessor at vcardprocessor.com Fri Jul 4 13:30:43 2008 From: vcardprocessor at vcardprocessor.com (Eric) Date: Fri, 4 Jul 2008 06:30:43 -0700 Subject: [Freeipa-devel] "Special" groups Message-ID: <20087463043.272921@C840> From your documentation: "editors" and "admins" are special groups. An example I have in mind would be to add a "private" group whose members would be invisible from other regular "ipausers" members. - I'm wondering if that makes sense to implement such a new group as a way to offer specific features. I fear there could be quickly too many groups for the sole purpose of governing roles (isn't already the case with delegations that need to be implemented via groups?) - What would be the way you favor to implement a special group? By developing a Fedory Directory Server plugin? ericdes From aleksander.adamowski.freeipa at altkom.pl Fri Jul 4 15:45:30 2008 From: aleksander.adamowski.freeipa at altkom.pl (Aleksander Adamowski) Date: Fri, 04 Jul 2008 17:45:30 +0200 Subject: [Freeipa-devel] Plans for configurable LDAP DIT structure do FreeIPA? Message-ID: <486E459A.1010308@altkom.pl> Hi! According to documentation (http://freeipa.org/wiki/index.php?title=UsingRhdsWithIpa), FreeIPA has some strict assumptions related to LDAP directory tree structure. There's no way to use FreeIPA with an arbitrary base DN; one can place users only in the BASE_DN,cn=accounts,cn=users subtree, etc. On the market, there are at least 2 widespread established LDAP DIT structuring styles: 1) dc=domain,dc=tld \- cn=accounts (or something similar) 2) o=OrganizationName \- ou=People FreeIPA follows the first one with some modifications (more levels - cn=accounts for example). Some proprietary, commercial software packages often make their own assumptions about some aspect of DIT structure. If there are too many such assumptions, the packages may become completely impossible to integrate with each other. And FreeIPA makes extremely numerous assumptions, thus making it very hard to integrate with other products. IMHO there are too many products that assume too much with respect to DIT structure. Such products become mutually exclusive because of such assumptions - you can't use two products together on the same LDAP directory if they expect different base DN's, different acount containers etc. The spirit of LDAP data model is to make its operations quite independent of directory structure - this is why you have the "subtree" scope for the search operation, and most of the time you launch the search without even thinking about how many levels are there below the search base and how they are structured. The point of the LDAP directory is also to centralize authentication, authorization and other data, organization-wide. So I can see a significant discrepancy here. On one hand, FreeIPA is meant as a product to enable centralization and unification of identity management. On the other hand, its design makes it hard to unify and centralize because it's hard to integrate with other LDAP-based systems because of its strict requirements pertaining to directory structure. Did you consider making some aspects of DIT structure configurable in FreeIPA? The more configurable, the better. Not only WRT naming of relevant subtrees, but also WRT their toplevel elements' objectclasses - so e.g. one can have ou=People instead of cn=users. The most important thing being the configurability of the base DN... Best Regards, -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl From ssorce at redhat.com Fri Jul 4 17:07:54 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 04 Jul 2008 13:07:54 -0400 Subject: [Freeipa-devel] 1.1.0-4 fedora 9 - password change still crashing ns-slapd In-Reply-To: References: <9D80D0B0-A7C6-4E7A-ABC4-F21A6CD06460@cox.net> <1215101700.353.165.camel@localhost.localdomain> Message-ID: <1215191274.353.204.camel@localhost.localdomain> On Thu, 2008-07-03 at 21:38 -0500, Matt Flusche wrote: > On Jul 3, 2008, at 11:15 AM, Simo Sorce wrote: > > > On Wed, 2008-07-02 at 22:36 -0500, Matt Flusche wrote: > >> I've upgraded to 1.1.0-4 for fedora 9 (x86_64) and am still having > >> ns- > >> slapd crash during password changes. > >> > >> # rpm -q ipa-server > >> ipa-server-1.1.0-4.fc9.x86_64 > >> > >> # uname -a > >> Linux ruff.flusche.co 2.6.25.9-76.fc9.x86_64 #1 SMP Fri Jun 27 > >> 15:58:30 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux > >> > >> Program received signal SIGSEGV, Segmentation fault. > >> [Switching to Thread 0x41992950 (LWP 9201)] > >> 0x000000392fc808f0 in strcmp () from /lib64/libc.so.6 > >> (gdb) bt > >> #0 0x000000392fc808f0 in strcmp () from /lib64/libc.so.6 > >> #1 0x00007f95ec9dc093 in ?? () from /usr/lib64/dirsrv/plugins/ > >> libipa_pwd_extop.so > >> #2 0x00007f95ec9dd778 in ?? () from /usr/lib64/dirsrv/plugins/ > >> libipa_pwd_extop.so > >> #3 0x0000000000188f05 in plugin_call_exop_plugins (pb=0x1533f30, > >> oid=0x150fc50 "1.3.6.1.4.1.4203.1.11.1") > >> at ldap/servers/slapd/plugin.c:393 > >> #4 0x000000000041698f in do_extended (pb=0x1533f30) at ldap/servers/ > >> slapd/extendop.c:300 > >> #5 0x0000000000412086 in connection_threadmain () at ldap/servers/ > >> slapd/connection.c:562 > >> #6 0x0000003ee8e29aa3 in _pt_root (arg=) > >> at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:221 > >> #7 0x000000393080729a in start_thread (arg=) at > >> pthread_create.c:297 > >> #8 0x000000392fce42cd in clone () from /lib64/libc.so.6 > >> > >> > >> from /var/log/messages (during ns-slapd restart & crash) > >> > >> Jul 2 22:31:30 ruff ns-slapd: auxpropfunc error invalid parameter > >> supplied > >> Jul 2 22:31:30 ruff ns-slapd: _sasl_plugin_load failed on > >> sasl_auxprop_plug_init for plugin: ldapdb > >> Jul 2 22:31:30 ruff ns-slapd: sql_select option missing > >> Jul 2 22:31:30 ruff ns-slapd: auxpropfunc error no mechanism > >> available > >> Jul 2 22:31:30 ruff ns-slapd: _sasl_plugin_load failed on > >> sasl_auxprop_plug_init for plugin: sql > >> Jul 2 22:32:30 ruff kernel: ns-slapd[9662]: segfault at 0 ip > >> 392fc808f0 sp 41736c38 error 4 in libc-2.8.so[392fc00000+162000] > >> Jul 2 22:32:30 ruff kpasswd[9679]: ldap_result() failed. (-1) > >> Jul 2 22:32:30 ruff kpasswd[9679]: Server Error while performing > >> LDAP password change > >> > > > > This looks strange. > > Can you load debuginfo packages so that I can understand where it is > > actually crashing exactly ? > > > > Simo. > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > > > Is this what you are looking for? > > Regards, > > Matt > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x41044950 (LWP 13194)] > 0x000000392fc808f0 in strcmp () from /lib64/libc.so.6 > (gdb) bt > #0 0x000000392fc808f0 in strcmp () from /lib64/libc.so.6 > #1 0x00007ff13cb0e093 in ipapwd_chpwop (pb=0x223c780) at > ipa_pwd_extop.c:1321 > #2 0x00007ff13cb0f778 in ipapwd_extop (pb=0x223c780) at > ipa_pwd_extop.c:2865 > #3 0x0000000000188f05 in plugin_call_exop_plugins (pb=0x223c780, > oid=0x2242ca0 "1.3.6.1.4.1.4203.1.11.1") at ldap/servers/slapd/ > plugin.c:393 > #4 0x000000000041698f in do_extended (pb=0x223c780) at ldap/servers/ > slapd/extendop.c:300 > #5 0x0000000000412086 in connection_threadmain () at ldap/servers/ > slapd/connection.c:562 > #6 0x0000003ee8e29aa3 in _pt_root (arg=) > at ../../../mozilla/nsprpub/pr/src/pthreads/ptthread.c:221 > #7 0x000000393080729a in start_thread (arg=) at > pthread_create.c:297 > #8 0x000000392fce42cd in clone () from /lib64/libc.so.6 Yes, I saw where it happens, but it shouldn't happen. Can you provide me (eventually via private email) an ldif dump of the user entry of the user you are trying to change the password of ? I will provide a fix for this, but I'd like to see what's in there to hopefully understand how this happened. Thanks, Simo. -- Simo Sorce * Red Hat, Inc * New York From vcardprocessor at vcardprocessor.com Fri Jul 4 17:52:10 2008 From: vcardprocessor at vcardprocessor.com (Eric) Date: Fri, 4 Jul 2008 10:52:10 -0700 Subject: [Freeipa-devel] Access the web gui with username/password Message-ID: <200874105210.033327@C840> Is there an alternative way to access the web gui with a username / password and not only through Kerberos? ericdes From ssorce at redhat.com Fri Jul 4 18:01:01 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 04 Jul 2008 14:01:01 -0400 Subject: [Freeipa-devel] [PATCH] Fix segfault and memleak Message-ID: <1215194461.353.206.camel@localhost.localdomain> -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-If-krbPasswordExpiration-or-krbLastPwdChange-are-not.patch Type: application/mbox Size: 3724 bytes Desc: not available URL: From ssorce at redhat.com Fri Jul 4 18:02:06 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 04 Jul 2008 14:02:06 -0400 Subject: [Freeipa-devel] Access the web gui with username/password In-Reply-To: <200874105210.033327@C840> References: <200874105210.033327@C840> Message-ID: <1215194526.353.208.camel@localhost.localdomain> On Fri, 2008-07-04 at 10:52 -0700, Eric wrote: > Is there an alternative way to access the web gui with a username / password and not only through Kerberos? Nope, only kerberos auth accepted. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Jul 4 18:05:48 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 04 Jul 2008 14:05:48 -0400 Subject: [Freeipa-devel] "Special" groups In-Reply-To: <20087463043.272921@C840> References: <20087463043.272921@C840> Message-ID: <1215194748.353.213.camel@localhost.localdomain> On Fri, 2008-07-04 at 06:30 -0700, Eric wrote: > From your documentation: "editors" and "admins" are special groups. An > example I have in mind would be to add a "private" group whose members > would be invisible from other regular "ipausers" members. All users are always visible as we allow anonymous read acces to the tree (except for some attributes). This is needed because of the way Linux/Unix system work, as they can always enumerate all users. To be able to conceal some user we would have to change how the single machine look-up users. Not an easy task. > - I'm wondering if that makes sense to implement such a new group as a > way to offer specific features. I fear there could be quickly too many > groups for the sole purpose of governing roles (isn't already the case > with delegations that need to be implemented via groups?) We are thinking if and how to implement roles in IPA, editors would need to be really a role not a posix Group, but for v1 groups is all we have. > - What would be the way you favor to implement a special group? By > developing a Fedory Directory Server plugin? if your aim is to conceal users that would not be enough. Normally though I would experiment with ACIs first (or Roles, Virtual Groups, Class of Service, etc...). Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Fri Jul 4 18:24:08 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 04 Jul 2008 14:24:08 -0400 Subject: [Freeipa-devel] Plans for configurable LDAP DIT structure do FreeIPA? In-Reply-To: <486E459A.1010308@altkom.pl> References: <486E459A.1010308@altkom.pl> Message-ID: <1215195848.353.233.camel@localhost.localdomain> On Fri, 2008-07-04 at 17:45 +0200, Aleksander Adamowski wrote: > Hi! > > According to documentation > (http://freeipa.org/wiki/index.php?title=UsingRhdsWithIpa), FreeIPA has > some strict assumptions related to LDAP directory tree structure. > > There's no way to use FreeIPA with an arbitrary base DN; one can place > users only in the BASE_DN,cn=accounts,cn=users subtree, etc. DNs are written the other way around: Cn=users,cn=accounts,BASE_DN > On the market, there are at least 2 widespread established LDAP DIT > structuring styles: > > 1) > dc=domain,dc=tld > \- cn=accounts (or something similar) Honestly I never saw this in the wild. > 2) > o=OrganizationName > \- ou=People This is popular yes. > FreeIPA follows the first one with some modifications (more levels - > cn=accounts for example). > > Some proprietary, commercial software packages often make their own > assumptions about some aspect of DIT structure. If they are just LDAP clients and they make assumptions on the DIT, they are buggy. > If there are too many such assumptions, the packages may become > completely impossible to integrate with each other. > And FreeIPA makes extremely numerous assumptions, thus making it very > hard to integrate with other products. FreeIPA is the master of the DIT, it provides a management interface, therefore needs to make assumptions. > IMHO there are too many products that assume too much with respect to > DIT structure. True, clients should never do it, they should rely on configuration as much as possible. They may require a specific subtree structure if they have some custom schema, but at the very least their base DN should be configurable. > Such products become mutually exclusive because of such assumptions - > you can't use two products together on the same LDAP directory if they > expect different base DN's, different acount containers etc. Base DNs should always be configurable, they must, as every LDAP instance have a different one. If they assume specific account containers they are simply buggy, unless they are very specific User Management interfaces built with a specific DIT in mind, but it is unlikely you need to use 2 different user management interfaces for the same tree, it is usually unhealthy anyway. > The spirit of LDAP data model is to make its operations quite > independent of directory structure - this is why you have the "subtree" > scope for the search operation, and most of the time you launch the > search without even thinking about how many levels are there below the > search base and how they are structured. > > The point of the LDAP directory is also to centralize authentication, > authorization and other data, organization-wide. In abstract, yes, then you have to deploy stuff, and you have to make choices. > So I can see a significant discrepancy here. > > On one hand, FreeIPA is meant as a product to enable centralization and > unification of identity management. Right. > On the other hand, its design makes it hard to unify and centralize > because it's hard to integrate with other LDAP-based systems because of > its strict requirements pertaining to directory structure. In IPA We control and define the DIT. Most software I know of, can cope with it, some is buggy,and some we are incompatible with (we use of rfc2307bis and groupOfNames for example, which not all software still understand). > Did you consider making some aspects of DIT structure configurable in > FreeIPA? Some of it is configurable, in some cases the mgmt UI cannot cope, but everything else can. We had to simplify the management UI to be able to deliver anything. We plan to make it more flexible going forward. But we cannot just have a completely free form DIT. > The more configurable, the better. Not only WRT naming of relevant > subtrees, but also WRT their toplevel elements' objectclasses - so e.g. > one can have ou=People instead of cn=users. The most important thing > being the configurability of the base DN... You should be able to create a ou=People in the tree, but current webui and tools would not cope with it at this moment. ?The core components (KDC, plugins, etc...) would have no problem with that, and the XML-RPC interface use DNs so you can build your custom tools if you want. But if you want free hand with DIT, and even objectclasses and tools, then you do not want an integrated product like freeipa, you just want a bare LDAP tree to manage they way you want. In this case you can use Directory Server or OpenLDAP, and spend the weeks or months it will take to make your own custom integrated product. Simo. -- Simo Sorce * Red Hat, Inc * New York From vcardprocessor at vcardprocessor.com Fri Jul 4 19:48:00 2008 From: vcardprocessor at vcardprocessor.com (Eric) Date: Fri, 4 Jul 2008 12:48:00 -0700 Subject: [Freeipa-devel] Users are unconfined_u:unconfined_r:unconfined_t Message-ID: <20087412480.825159@C840> Is there are reason why users are created within the context unconfined_u:unconfined_r:unconfined_t and not user_u:user_r:user_t? What would it take to create an IPA tool that allows to modify those SE-linux roles, types individually? From aleksander.adamowski.freeipa at altkom.pl Fri Jul 4 23:43:06 2008 From: aleksander.adamowski.freeipa at altkom.pl (Aleksander Adamowski) Date: Sat, 05 Jul 2008 01:43:06 +0200 Subject: [Freeipa-devel] Plans for configurable LDAP DIT structure do FreeIPA? In-Reply-To: <1215195848.353.233.camel@localhost.localdomain> References: <486E459A.1010308@altkom.pl> <1215195848.353.233.camel@localhost.localdomain> Message-ID: <486EB58A.8050707@altkom.pl> Simo Sorce wrote: > DNs are written the other way around: > Cn=users,cn=accounts,BASE_DN > Correct, I was typing that in a hurry >> On the market, there are at least 2 widespread established LDAP DIT >> structuring styles: >> >> 1) >> dc=domain,dc=tld >> \- cn=accounts (or something similar) >> > > Honestly I never saw this in the wild. > Older (but still quite recent) versions of eGroupWare required ou=accounts (yes, not cn, but I was typing this out of the top of my head too...): http://www.egroupware.org/index.php?page_name=wiki&wikipage=AddresbookAccountsConcept They also required special objectclasses. Luckily from eGW 1.4 on there are no such silly requirements. The cn=accounts,dc=domaincomponent,... scheme was also hinted at in RFC 4524, section 3.3: dn: uid=kdz,cn=Accounts,dc=Example,dc=COM They also use(d?) this scheme in Stanford AFAIK. Also, and old version of Netscape Messaging Server I worked with had accounts in l=Cityname subtrees placed directly under base DN, which was formed from comain components. >> FreeIPA follows the first one with some modifications (more levels - >> cn=accounts for example). >> >> Some proprietary, commercial software packages often make their own >> assumptions about some aspect of DIT structure. >> > > If they are just LDAP clients and they make assumptions on the DIT, they > are buggy. > Well, a large part of FreeIPA _is_ an LDAP client. And it makes assumptions on the DIT. So logically, it's kind of buggy from some point of view. I'll elaborate on that in the next point: >> If there are too many such assumptions, the packages may become >> completely impossible to integrate with each other. >> And FreeIPA makes extremely numerous assumptions, thus making it very >> hard to integrate with other products. >> > FreeIPA is the master of the DIT, it provides a management interface, > therefore needs to make assumptions. > It seems to me that FreeIPA makes the same mistake that eGW made - assumes that if it is _the_ server (not _a_ server), then it doesn't have to behave like the other LDAP clients. Deep somewhere in the design process lies a silent, subconscious assumption that it is the central, most important system in the IT infrastructure. In today's environment hardly any system can assume such privileged position. Especially a project like FreeIPA, which is currently starting up and needs first to gain ground in _existing_ infrastructures, with established directories which are already structured and filled with data. Also, if you look into the literature, and I think the most comprehensive material is IBM Redbooks' "Understanding LDAP", it's advised that the directory be structured according to organizational, or geographical criteria - most importantly, according to criteria which are unlikely to change significantly with time: http://www.redbooks.ibm.com/redbooks/SG244986/wwhelp/wwhimpl/common/html/wwhelp.htm?context=SG244986&file=10-25.htm We all know that IT systems come and go and most organizations will be reluctant to base their identity management infrastructure which insists on bending the directory structure to its technological quirks. And why the management interface needs to make those assumptions? Apart from simplifying its imlementation, I see no real benefits of that. I understand that it might be complex in implementation, but I think this configurability will pay in much faster adoption of FreeIPA in the wild. Currently FreeIPA is only usable for infrastructures built from scratch. That's a very serious limitation, one which can kill the project in the long term. FreeIPA is a newcomer, it has to be existing infrastructure friendly. >> IMHO there are too many products that assume too much with respect to DIT structure. >> > > True, clients should never do it, they should rely on configuration as > much as possible. They may require a specific subtree structure if they > have some custom schema, but at the very least their base DN should be > configurable. > I don't think the distinction you make here between clients and FreeIPA is justified. The LDAP directory in an organization inevitably evolves into a shared database, and many distinct applications use _and_ manage information contained there. FreeIPA needs to play well with others and should assume as little control over the directory, as possible - only the necessary minimum to do its job properly. > >> Such products become mutually exclusive because of such assumptions - >> you can't use two products together on the same LDAP directory if they >> expect different base DN's, different acount containers etc. >> > > Base DNs should always be configurable, they must, as every LDAP > instance have a different one. If they assume specific account > containers they are simply buggy, unless they are very specific User > Management interfaces built with a specific DIT in mind, but it is > unlikely you need to use 2 different user management interfaces for the > same tree, it is usually unhealthy anyway. > Well, in our company we are currently using a few interchangeable management interfaces, the most widely used is our own custom one (another one is phpLDAPadmin) and it doesn't assume a structure - it lets the admin pick the container in the DIT where he wants a new object (e.g. account) to be placed, with some configurable restrictions (the top DN for accounts, and so on). It's a Perl-Gtk2 GUI. > >> The spirit of LDAP data model is to make its operations quite >> independent of directory structure - this is why you have the "subtree" >> scope for the search operation, and most of the time you launch the >> search without even thinking about how many levels are there below the >> search base and how they are structured. >> >> The point of the LDAP directory is also to centralize authentication, >> authorization and other data, organization-wide. >> > > In abstract, yes, then you have to deploy stuff, and you have to make > choices. > That's true but I got the impression that FreeIPA is a project in an early stage of development, and it's still possible to undo design decisions which may prove to be catastrophic later on. I don't see why most aspects of its DIT structure couldn't be turned into configurable options. The base DN of the directory could be a config item. How the "accounts" subtree is named too. Or if it's present at all - one can make the location of users, groups, trees, computers and other subtrees configurable, and the default configuration would place them all in the cn=accounts container so that it's identical to the current state. E.g.: objectclass: ipaGuiConfig ipaUserAccountSubtreeRDN: cn=users,cn=accounts ipaGroupAccountSubtreeRDN: cn=groups,cn=accounts ipaComputerAccountSubtreeRDN: cn=computers,cn=accounts .... ipaKerberosSubtreeRDN: cn=Kerberos ... Note that above configuration is 100% compatible with FreeIPA 1.0. The ipaGuiConfig object could be placed by default in cn=etc subtree, but it should work if it's anywhere in the tree - after all, the system can search for objectclass=ipaGuiConfig, right? No need to make assumptions here. Now one can use it to marry FreeIPA with a preexisting directory, e.g.: objectclass: ipaGuiConfig ipaUserAccountSubtreeRDN: ou=People ipaGroupAccountSubtreeRDN: ou=Groups ipaComputerAccountSubtreeRDN: cn=computers .... ipaKerberosSubtreeRDN: o=mit # Note that o=mit is the example from official MIT Kerberos 5 documentation! Lots of systems in the wild use this. ... >> On the other hand, its design makes it hard to unify and centralize >> because it's hard to integrate with other LDAP-based systems because of >> its strict requirements pertaining to directory structure. >> > > In IPA We control and define the DIT. What for? Why do we do this? Apply Occam's Razor here. What does that buy us? Some simplification of management tools implementation. But they could be made to use configuration variables where now they have hardcoded values. Yes, it costs development time. Are there any other reasons for controlling the DIT? > Most software I know of, can cope > with it, true. > some is buggy, Yes, but note that you are creating yet another piece of this kind of software right now. It doesn't have to be this way. > and some we are incompatible with (we use of > rfc2307bis and groupOfNames for example, which not all software still > understand). > Well written software should ignore the stuff it doesn't understand and make the best effort to still work with the data it understands. That's why the x.509 standard defines a concept of critical and non-critical certificate fields. > >> Did you consider making some aspects of DIT structure configurable in >> FreeIPA? >> > > Some of it is configurable, in some cases the mgmt UI cannot cope, but > everything else can. Well, I understand that the current version of FreeIPA cannot cope. I'm concerned with its future development direction. Are there plans to make it configurable? I think it's very important for future adoption of the project to do it. > We had to simplify the management UI to be able to > deliver anything. We plan to make it more flexible going forward. > But we cannot just have a completely free form DIT. > Oh, that answers most of my question... Notice, however, that if you implement configurability similar to what I've suggested above, you'll get practically free form DIT. It's doable, it's not so hard, LDAP itself is designed to make it easy! >> The more configurable, the better. Not only WRT naming of relevant >> subtrees, but also WRT their toplevel elements' objectclasses - so e.g. >> one can have ou=People instead of cn=users. The most important thing >> being the configurability of the base DN... >> > > You should be able to create a ou=People in the tree, but current webui > and tools would not cope with it at this moment. > ?The core components (KDC, plugins, etc...) would have no problem with > that, and the XML-RPC interface use DNs so you can build your custom > tools if you want. > Yes, because those components are indeed marvelous pieces of engineering. It would be nice if the ui and tools followed that design too. > > But if you want free hand with DIT, and even objectclasses and tools, > then you do not want an integrated product like freeipa, Why? I view FreeIPA as a preconfigurator for LDAP+Kerberos+Radius+NTP+some other future subsystems (DNS?), bundled with easy to use management tools. It would be marvelous if it could preconfigure all this given a preexisting directory, provided that you point where in that directory are places you want it to put its stuff, and that it tries to reuse existing data (e.g. converting ordinary posixAccounts or inetOrgPersons to full-featured accounts). It's doable, IMHO, and would tremendously benefit FreeIPA's appeal. Am I missing something? > you just want a > bare LDAP tree to manage they way you want. In this case you can use > Directory Server or OpenLDAP, and spend the weeks or months it will take > to make your own custom integrated product. > This is the other extreme - on one end you have FreeIPA installer that sets up something from scratch and it is guaranteed to work. On the opposite, you have perspective of taking all the bits and setting them up together, FreeIPA-style, by hand. But the components of FreeIPA could be used for intermediate solutions - you'd use them on existing infrastructure, they'd make their best effort to set everything up given some initial configuration options (the DIT structure I were talking about) and convert the contents of DIT, then if all goes well - you got lucky and got a working system, otherwise you'd simply have to tweak it to make it work. Which would still be much less work than setting it up manually from scratch. -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl From ssorce at redhat.com Sat Jul 5 16:10:39 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 05 Jul 2008 12:10:39 -0400 Subject: [Freeipa-devel] Plans for configurable LDAP DIT structure do FreeIPA? In-Reply-To: <486EB58A.8050707@altkom.pl> References: <486E459A.1010308@altkom.pl> <1215195848.353.233.camel@localhost.localdomain> <486EB58A.8050707@altkom.pl> Message-ID: <1215274239.9532.41.camel@localhost.localdomain> On Sat, 2008-07-05 at 01:43 +0200, Aleksander Adamowski wrote: > It seems to me that FreeIPA makes the same mistake that eGW made - > assumes that if it is _the_ server (not _a_ server), then it doesn't > have to behave like the other LDAP clients. Yes, we make that assumption. > Deep somewhere in the design process lies a silent, subconscious > assumption that it is the central, most important system in the IT > infrastructure. Indeed. > In today's environment hardly any system can assume such privileged > position. > Especially a project like FreeIPA, which is currently starting up and > needs first to gain ground in _existing_ infrastructures, with > established directories which are already structured and filled with data. We know right now it is very difficult to do a migration, it was a conscious decision. > Also, if you look into the literature, and I think the most > comprehensive material is IBM Redbooks' "Understanding LDAP", it's > advised that the directory be structured according to organizational, or > geographical criteria - most importantly, according to criteria which > are unlikely to change significantly with time: > http://www.redbooks.ibm.com/redbooks/SG244986/wwhelp/wwhimpl/common/html/wwhelp.htm?context=SG244986&file=10-25.htm We do not think using organizational OUs to be a good idea, it is a very inflexible method. Directory Server can present views to other applications (search about views in RHDS documentation) so if you really want to see a virtual view of an organizational structure you can do that. We think that keeping the tree flat is the best course going forward and we are planning on providing powerful grouping mechanism to help admins organize their entries. > We all know that IT systems come and go and most organizations will be > reluctant to base their identity management infrastructure which insists > on bending the directory structure to its technological quirks. Experience shows that is not really true :) > And why the management interface needs to make those assumptions? Apart > from simplifying its imlementation, I see no real benefits of that. We needed to start with a manageable task, simplifying the implementation, but most importantly the user interfaces was a primary goal. > I understand that it might be complex in implementation, but I think this > configurability will pay in much faster adoption of FreeIPA in the wild. So far users are *gald* they do not have to learn LDAP and Kerberos and don't have to make choices they have no way to understand, at the same time I know some LDAP experts can be abit frusrated because we made different choices from their preferences, but LDAP experts are a handful, while people that need a centralized solution that just works are the majority. We decided to help fisrt the people that *needed* the most help. LDAP experts can easily build their own thing, we decided to make them happy a bit later where and when possible. > Currently FreeIPA is only usable for infrastructures built from scratch. > That's a very serious limitation, one which can kill the project in the > long term. FreeIPA is a newcomer, it has to be existing infrastructure > friendly. It may slow a bit adoption in places where they already have a good infrastructure (which are few). I am fully a ware of the limitations for migration, but we had to make choices to deliver anything. I welcome your criticism tho, you make good points, and I agree with most of them. > I don't think the distinction you make here between clients and FreeIPA > is justified. The LDAP directory in an organization inevitably evolves > into a shared database, and many distinct applications use _and_ manage > information contained there. > FreeIPA needs to play well with others and should assume as little > control over the directory, as possible - only the necessary minimum to > do its job properly. The minimum is what we did for now, we can relax yet some bits, but anything you make configurable becomes something you have to deal with at install AND replica time. It makes also future upgrades more difficult. > Well, in our company we are currently using a few interchangeable > management interfaces, the most widely used is our own custom one > (another one is phpLDAPadmin) and it doesn't assume a structure - it > lets the admin pick the container in the DIT where he wants a new object > (e.g. account) to be placed, with some configurable restrictions (the > top DN for accounts, and so on). It's a Perl-Gtk2 GUI. yup phpLdapAdmin does not assume structure, but it assume that to set it up you know LDAP very well, and you know how to customize phpLdapAdmin itself in case you need to create users in a way that is not templated already. That is not the kind of interface we wanted to provide to people that do not know anything about Kerberos or LDAP, or the way we mated Kerberos and LDAP together. We are trying to help *non*-experts with first releases, and slowly provide flexibility to experts when we can. > That's true but I got the impression that FreeIPA is a project in an > early stage of development, and it's still possible to undo design > decisions which may prove to be catastrophic later on. Nothing is fixed in stone, good people, with good ideas, and some patches can always help steer the project in better directions, provided our fundamental goals are not betrayed. > I don't see why most aspects of its DIT structure couldn't be turned > into configurable options. > > The base DN of the directory could be a config item. > How the "accounts" subtree is named too. > Or if it's present at all - one can make the location of users, groups, > trees, computers and other subtrees configurable, and the default > configuration would place them all in the cn=accounts container so that > it's identical to the current state. > > E.g.: > objectclass: ipaGuiConfig > ipaUserAccountSubtreeRDN: cn=users,cn=accounts > ipaGroupAccountSubtreeRDN: cn=groups,cn=accounts > ipaComputerAccountSubtreeRDN: cn=computers,cn=accounts > .... > ipaKerberosSubtreeRDN: cn=Kerberos > ... This is a very good suggestion actually, and to be honest I have been thinking of adding something similar in v2 so that clients can auto-configure themselves too. The problem is that to change this stuff you would need to make it manually or substantially change the ipa-server-install script. If you volunteer to send patches to ipa-server-install so that the default installation will not require any more prompts then what we require now in v1, then we could certainly extend IPA to handle these configuration options. > Note that above configuration is 100% compatible with FreeIPA 1.0. > The ipaGuiConfig object could be placed by default in cn=etc subtree, > but it should work if it's anywhere in the tree - after all, the system > can search for objectclass=ipaGuiConfig, right? No need to make > assumptions here. yup, not making assumption, but you have to store the kerberos subtree DN in the server's /etc/krb5.conf file, so this is not something you can change at will. You must install IPA from scratch with a specific subtree and stick with it (altrhough it could be configurable so not saying we cannot let users that know what they are doing change the defaults before installing the first IPA server instance). > Now one can use it to marry FreeIPA with a preexisting directory, e.g.: > > objectclass: ipaGuiConfig > ipaUserAccountSubtreeRDN: ou=People > ipaGroupAccountSubtreeRDN: ou=Groups > ipaComputerAccountSubtreeRDN: cn=computers > .... > ipaKerberosSubtreeRDN: o=mit > # Note that o=mit is the example from official MIT Kerberos 5 > documentation! Lots of systems in the wild use this. > ... Yes and no, a pre-existing directory will need to have the right objectclasses on users and groups, and then we have things like the memberof and DNA plugins, the fact we decided to use rfc2307bis with groupOfNames and the member attribute instead of the old memberUid attribute of the classic rfc2307 posixGroup objectclass, and so on. > you just want a > > bare LDAP tree to manage they way you want. In this case you can use > > Directory Server or OpenLDAP, and spend the weeks or months it will take > > to make your own custom integrated product. > > > This is the other extreme - on one end you have FreeIPA installer that > sets up something from scratch and it is guaranteed to work. On the > opposite, you have perspective of taking all the bits and setting them > up together, FreeIPA-style, by hand. > The DIT is not everything. > >> On the other hand, its design makes it hard to unify and centralize > >> because it's hard to integrate with other LDAP-based systems because of > >> its strict requirements pertaining to directory structure. > >> > > > > In IPA We control and define the DIT. > What for? Why do we do this? To simplify the problem mostly. > Apply Occam's Razor here. What does that buy us? Some simplification of > management tools implementation. But they could be made to use > configuration variables where now they have hardcoded values. Yes, it > costs development time. That's it, we could try to make the perfect super-configurable tool, and release in 10-15 years, or we can try to make a good tool, with some 'restrictions' and release it in a year, and then work on improving it where people demands and usage patterns show there is a problem of some sorts. We choose to follow the latter, in classic Open source style: release early, release often. > Are there any other reasons for controlling the DIT? > > > Most software I know of, can cope > > with it, > true. > > some is buggy, > Yes, but note that you are creating yet another piece of this kind of > software right now. It doesn't have to be this way. We are not building a management interface for generic directories, we are building an integrated IdM project. Flexibility is only one of the things we want to achieve but there are other priorities too, often more important, at this stage, than flexibility. > > and some we are incompatible with (we use of > > rfc2307bis and groupOfNames for example, which not all software still > > understand). > > > > Well written software should ignore the stuff it doesn't understand and > make the best effort to still work with the data it understands. That's > why the x.509 standard defines a concept of critical and non-critical > certificate fields. Sure, but if your OS can't see group members it simply does not work. The groupOfNames/member thing is one of those critical things and luckily, with the noticeable exception of Solaris (and we are working to address this problem), all other free or proprietary OSs seem to support it. > Well, I understand that the current version of FreeIPA cannot cope. I'm > concerned with its future development direction. Are there plans to make > it configurable? I think it's very important for future adoption of the > project to do it. Yes we are sensible to your kind of requests, especially if someone provides patches :) > I view FreeIPA as a preconfigurator for > LDAP+Kerberos+Radius+NTP+some other future subsystems (DNS?), bundled > with easy to use management tools. It would be marvelous if it could > preconfigure all this given a preexisting directory, provided that you > point where in that directory are places you want it to put its stuff, > and that it tries to reuse existing data (e.g. converting ordinary > posixAccounts or inetOrgPersons to full-featured accounts). It's doable, > IMHO, and would tremendously benefit FreeIPA's appeal. > > Am I missing something? No, only patches :-) The task you propose would be fantastic, but it would require a lot of code, we would be happy to add it to IPA, but we cannot do everything, the code is available, and contribution is very welcome, so if someone really badly wants that and can start contributing patches to go in that direction we will be happy to accept them and help. > But the components of FreeIPA could be used for intermediate solutions - > you'd use them on existing infrastructure, they'd make their best effort > to set everything up given some initial configuration options (the DIT > structure I were talking about) and convert the contents of DIT, then if > all goes well - you got lucky and got a working system, otherwise you'd > simply have to tweak it to make it work. Which would still be much less > work than setting it up manually from scratch. Yup, we nothing against this, except time :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Sat Jul 5 16:27:13 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 05 Jul 2008 12:27:13 -0400 Subject: [Freeipa-devel] Users are unconfined_u:unconfined_r:unconfined_t In-Reply-To: <20087412480.825159@C840> References: <20087412480.825159@C840> Message-ID: <1215275233.9532.47.camel@localhost.localdomain> On Fri, 2008-07-04 at 12:48 -0700, Eric wrote: > Is there are reason why users are created within the context > unconfined_u:unconfined_r:unconfined_t and not user_u:user_r:user_t? > What would it take to create an IPA tool that allows to modify those > SE-linux roles, types individually? The SELinux role is assigned at login time by the client system, as, so far, SELinux policies are only local. We are actually working to make it possible to centrally manage the SELinux user to IPA User association. But that will take some time and requires an agent/pam module on the client machine able to fetch this values from the directory. Simo. -- Simo Sorce * Red Hat, Inc * New York From mendbayar_b at mongol.net Mon Jul 7 12:01:19 2008 From: mendbayar_b at mongol.net (Byambaa Mendbayar) Date: Mon, 07 Jul 2008 20:01:19 +0800 Subject: [Freeipa-devel] solved + next problem :-( Message-ID: <1215432079.12479.10.camel@linux-gzha.site> Dear devs, I have solve my previous problem. It was blocked by firewall on my freeIPA server. After that i have getting still another error on my client's Firefox browser. It is a following on my browser: -------------------------------------------------------- Kerberos Authentication Failed Unable to verify your Kerberos credentials. Please make sure that you have valid Kerberos tickets (obtainable via kinit), and that you have configured your browser correctly. If you are still unable to access the IPA Web interface, please contact the helpdesk on for additional assistance. Import the IPA Certificate Authority. You can automatically configure your browser to work with Kerberos by importing the Certificate Authority above and clicking on the Configure Browser button. You must reload this page after importing the Certificate Authority for the automatic settings to work ?-------------------------------------------------------- I have checked everything again, again on my client computer it was all things OK (same stated in guideline). My client computer's OS is openSUSE 11.0 (I have installed krb5-client for kinit) What's wrong on my work? Please help and advice to me. Thanks and best regards, Byambaa Mendbayar From sgallagh at redhat.com Mon Jul 7 12:32:54 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 07 Jul 2008 08:32:54 -0400 Subject: [Freeipa-devel] [PATCH] Fix segfault and memleak In-Reply-To: <1215194461.353.206.camel@localhost.localdomain> References: <1215194461.353.206.camel@localhost.localdomain> Message-ID: <48720CF6.6060703@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simo Sorce wrote: > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhyDPYACgkQc7MaxVic+2rFyACfVTkNYAd5odFAmhK7eTiSC+a6 FPUAniJJuIq3fdU5vSQzWqs9/VpfBX1C =/eZp -----END PGP SIGNATURE----- From rcritten at redhat.com Mon Jul 7 13:06:34 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Jul 2008 09:06:34 -0400 Subject: [Freeipa-devel] [PATCH] Fix segfault and memleak In-Reply-To: <1215194461.353.206.camel@localhost.localdomain> References: <1215194461.353.206.camel@localhost.localdomain> Message-ID: <487214DA.5040203@redhat.com> Simo Sorce wrote: > > ------------------------------------------------------------------------ ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From aleksander.adamowski.freeipa at altkom.pl Mon Jul 7 13:24:57 2008 From: aleksander.adamowski.freeipa at altkom.pl (Aleksander Adamowski) Date: Mon, 07 Jul 2008 15:24:57 +0200 Subject: [Freeipa-devel] Plans for configurable LDAP DIT structure do FreeIPA? In-Reply-To: <1215274239.9532.41.camel@localhost.localdomain> References: <486E459A.1010308@altkom.pl> <1215195848.353.233.camel@localhost.localdomain> <486EB58A.8050707@altkom.pl> <1215274239.9532.41.camel@localhost.localdomain> Message-ID: <48721929.8050905@altkom.pl> Simo Sorce wrote: > On Sat, 2008-07-05 at 01:43 +0200, Aleksander Adamowski wrote: > >> E.g.: >> objectclass: ipaGuiConfig >> ipaUserAccountSubtreeRDN: cn=users,cn=accounts >> ipaGroupAccountSubtreeRDN: cn=groups,cn=accounts >> ipaComputerAccountSubtreeRDN: cn=computers,cn=accounts >> .... >> ipaKerberosSubtreeRDN: cn=Kerberos >> ... >> > > This is a very good suggestion actually, and to be honest I have been > thinking of adding something similar in v2 so that clients can > auto-configure themselves too. > > The problem is that to change this stuff you would need to make it > manually or substantially change the ipa-server-install script. > > If you volunteer to send patches to ipa-server-install so that the > default installation will not require any more prompts then what we > require now in v1, then we could certainly extend IPA to handle these > configuration options. > OK, I've pulled the tree from GIT. From grepping the code it seems to me that making those options configurable shouldn't be that hard, but there must be some limitations - e.g. the ACI container has to be a predecessor of all account containers. Would it work OK if the ACI container had been set to base DN? > yup, not making assumption, but you have to store the kerberos subtree > DN in the server's /etc/krb5.conf file, so this is not something you can > change at will. Well, some options have to be outside LDAP for now (as long as MIT Kerberos cannot get its configuration from LDAP) and it's OK as long as they can be overriden during initialization just like the other things. It would be hard to change them, but after everything has been set up, hardly anybody will have a reason to. > You must install IPA from scratch with a specific > subtree and stick with it (altrhough it could be configurable so not > saying we cannot let users that know what they are doing change the > defaults before installing the first IPA server instance). > That's the point. > Yes and no, a pre-existing directory will need to have the right > objectclasses on users and groups, I think the set up scripts could intelligently add missing objectclasses and required attributes to pre-existing entries. E.g. find all "(objectclass=posixAccount)" (or even "(uid=*)"), add objectclass=krbPrincipal to them, then add a krbPrincipalName generated from uid and realm name. And so on. Note that lots of data in such an LDAP database is redundant and there are functional dependencies. Codd definately wouldn't be happy seeing an object which has uid=jsmith and krbPrincipalName=jsmith at EXAMPLE.COM (not to mention mail=jsmith at example.com...). So many values can be automatically generated during conversion from existing LDAP to FreeIPA if they are missing. -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl From rcritten at redhat.com Mon Jul 7 13:57:40 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Jul 2008 09:57:40 -0400 Subject: [Freeipa-devel] solved + next problem :-( In-Reply-To: <1215432079.12479.10.camel@linux-gzha.site> References: <1215432079.12479.10.camel@linux-gzha.site> Message-ID: <487220D4.9010108@redhat.com> Byambaa Mendbayar wrote: > Dear devs, > > I have solve my previous problem. It was blocked by firewall on my > freeIPA server. After that i have getting still another error on my > client's Firefox browser. It is a following on my browser: > > -------------------------------------------------------- > Kerberos Authentication Failed > Unable to verify your Kerberos credentials. Please make sure that you > have valid Kerberos tickets (obtainable via kinit), and that you have > configured your browser correctly. If you are still unable to access the > IPA Web interface, please contact the helpdesk on for additional > assistance. > > Import the IPA Certificate Authority. > > You can automatically configure your browser to work with Kerberos by > importing the Certificate Authority above and clicking on the Configure > Browser button. > > You must reload this page after importing the Certificate Authority for > the automatic settings to work > > ?-------------------------------------------------------- > > I have checked everything again, again on my client computer it was all > things OK (same stated in guideline). My client computer's OS is > openSUSE 11.0 (I have installed krb5-client for kinit) > > What's wrong on my work? Please help and advice to me. > > Thanks and best regards, > Byambaa Mendbayar Did you get a kerberos ticket yet? If you had firefox running prior to obtaining a ticket you probably need to restart firefox. This page outlines how to debug the browser so you can better see what is going on. http://people.redhat.com/mikeb/negotiate/ rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Jul 7 14:00:52 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 07 Jul 2008 10:00:52 -0400 Subject: [Freeipa-devel] Plans for configurable LDAP DIT structure do FreeIPA? In-Reply-To: <48721929.8050905@altkom.pl> References: <486E459A.1010308@altkom.pl> <1215195848.353.233.camel@localhost.localdomain> <486EB58A.8050707@altkom.pl> <1215274239.9532.41.camel@localhost.localdomain> <48721929.8050905@altkom.pl> Message-ID: <1215439252.3554.17.camel@localhost.localdomain> On Mon, 2008-07-07 at 15:24 +0200, Aleksander Adamowski wrote: > Simo Sorce wrote: > > On Sat, 2008-07-05 at 01:43 +0200, Aleksander Adamowski wrote: > > > >> E.g.: > >> objectclass: ipaGuiConfig > >> ipaUserAccountSubtreeRDN: cn=users,cn=accounts > >> ipaGroupAccountSubtreeRDN: cn=groups,cn=accounts > >> ipaComputerAccountSubtreeRDN: cn=computers,cn=accounts > >> .... > >> ipaKerberosSubtreeRDN: cn=Kerberos > >> ... > >> > > > > This is a very good suggestion actually, and to be honest I have been > > thinking of adding something similar in v2 so that clients can > > auto-configure themselves too. > > > > The problem is that to change this stuff you would need to make it > > manually or substantially change the ipa-server-install script. > > > > If you volunteer to send patches to ipa-server-install so that the > > default installation will not require any more prompts then what we > > require now in v1, then we could certainly extend IPA to handle these > > configuration options. > > > OK, I've pulled the tree from GIT. > > From grepping the code it seems to me that making those options > configurable shouldn't be that hard, but there must be some limitations > - e.g. the ACI container has to be a predecessor of all account containers. > Would it work OK if the ACI container had been set to base DN? It depends on the ACIs, for example I think we have stricter ACIs for access to cn=kerberos > > Yes and no, a pre-existing directory will need to have the right > > objectclasses on users and groups, > > I think the set up scripts could intelligently add missing objectclasses > and required attributes to pre-existing entries. > > E.g. find all "(objectclass=posixAccount)" (or even "(uid=*)"), add > objectclass=krbPrincipal to them, then add a krbPrincipalName generated > from uid and realm name. And so on. > > Note that lots of data in such an LDAP database is redundant and there > are functional dependencies. Codd definately wouldn't be happy seeing an > object which has uid=jsmith and krbPrincipalName=jsmith at EXAMPLE.COM (not > to mention mail=jsmith at example.com...). > So many values can be automatically generated during conversion from > existing LDAP to FreeIPA if they are missing. This values are only incidentally equal, it might very well be that krbprincipalname, email and uid have distinct values. although right now , in v1, we depend on uid being equal to the name part of the principal name indeed. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Jul 7 14:08:10 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 07 Jul 2008 10:08:10 -0400 Subject: [Freeipa-devel] [PATCH] fix selinux policy for ipa_kpasswd In-Reply-To: <486CC3D8.20504@redhat.com> References: <1215036037.353.149.camel@localhost.localdomain> <486CC3D8.20504@redhat.com> Message-ID: <1215439690.3554.21.camel@localhost.localdomain> On Thu, 2008-07-03 at 08:19 -0400, Rob Crittenden wrote: > ack pushed to master -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Jul 7 14:08:33 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 07 Jul 2008 10:08:33 -0400 Subject: [Freeipa-devel] [PATCH] Fix segfault and memleak In-Reply-To: <48720CF6.6060703@redhat.com> References: <1215194461.353.206.camel@localhost.localdomain> <48720CF6.6060703@redhat.com> Message-ID: <1215439713.3554.23.camel@localhost.localdomain> On Mon, 2008-07-07 at 08:32 -0400, Stephen Gallagher wrote: > > ack pushed to master -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Mon Jul 7 14:09:05 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 07 Jul 2008 10:09:05 -0400 Subject: [Freeipa-devel] [PATCH] Fix Admin ACIs Message-ID: <1215439745.3554.25.camel@localhost.localdomain> -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Admin-must-be-able-to-add-delete-too.patch Type: application/mbox Size: 2449 bytes Desc: not available URL: From ssorce at redhat.com Mon Jul 7 14:09:31 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 07 Jul 2008 10:09:31 -0400 Subject: [Freeipa-devel] [PATCH] Fix openldap prototypes Message-ID: <1215439771.3554.27.camel@localhost.localdomain> -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Make-sure-we-have-the-right-prototypes-when-using-op.patch Type: application/mbox Size: 700 bytes Desc: not available URL: From sgallagh at redhat.com Mon Jul 7 14:11:28 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 07 Jul 2008 10:11:28 -0400 Subject: [Freeipa-devel] [PATCH] Fix Admin ACIs In-Reply-To: <1215439745.3554.25.camel@localhost.localdomain> References: <1215439745.3554.25.camel@localhost.localdomain> Message-ID: <48722410.3020804@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simo Sorce wrote: > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhyJA8ACgkQc7MaxVic+2q/ZACfW67lvDmlmn20eI2dFOVqIGAg qykAoKQL9+d9FYrk3XK+eZR9rA5Hv3GC =Ttfd -----END PGP SIGNATURE----- From sgallagh at redhat.com Mon Jul 7 14:12:58 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 07 Jul 2008 10:12:58 -0400 Subject: [Freeipa-devel] [PATCH] Fix openldap prototypes In-Reply-To: <1215439771.3554.27.camel@localhost.localdomain> References: <1215439771.3554.27.camel@localhost.localdomain> Message-ID: <4872246A.700@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simo, can you explain what effect setting the "LDAP_DEPRECATED" macro has elsewhere in the code? Simo Sorce wrote: > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhyJGoACgkQc7MaxVic+2rNpgCeO5Q8kn9iRaYAhUMDm74NqUOi psAAn0tnaQBr+J+cIkEjfOvNq4CLFBe1 =dJN7 -----END PGP SIGNATURE----- From rcritten at redhat.com Mon Jul 7 14:29:16 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Jul 2008 10:29:16 -0400 Subject: [Freeipa-devel] [PATCH] Have ipa-delgroup be more careful In-Reply-To: <1215121573.353.198.camel@localhost.localdomain> References: <486D40E0.70002@redhat.com> <1215121573.353.198.camel@localhost.localdomain> Message-ID: <4872283C.1090909@redhat.com> Simo Sorce wrote: > On Thu, 2008-07-03 at 17:13 -0400, Rob Crittenden wrote: >> The group delete XML-RPC function takes the DN as the argument so it >> is >> up to the client to provide the right group. >> >> This patch runs through the search results for the group to delete >> and >> explodes the returned DNs looking for an exact match of >> cn=GROUP_TO_DELETE >> >> So even if multiple groups are returned we'll do the right thing. > > > ack, exactly the kind of patch I was expecting :-) > > Simo. > pushed to master rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Jul 7 14:59:21 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 07 Jul 2008 10:59:21 -0400 Subject: [Freeipa-devel] [PATCH] Fix openldap prototypes In-Reply-To: <4872246A.700@redhat.com> References: <1215439771.3554.27.camel@localhost.localdomain> <4872246A.700@redhat.com> Message-ID: <1215442762.3554.44.camel@localhost.localdomain> On Mon, 2008-07-07 at 10:12 -0400, Stephen Gallagher wrote: > Simo, can you explain what effect setting the "LDAP_DEPRECATED" macro > has elsewhere in the code? As far as I can see it only adds prototypes for "deprecated" functions in the ldap API, like ldap_init() It seem to do nothing else, and it also seems ldap source themselves define LDAP_DEPRECATED in some files to use these older APIs Simo. -- Simo Sorce * Red Hat, Inc * New York From sgallagh at redhat.com Mon Jul 7 15:05:40 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 07 Jul 2008 11:05:40 -0400 Subject: [Freeipa-devel] [PATCH] Fix openldap prototypes In-Reply-To: <1215442762.3554.44.camel@localhost.localdomain> References: <1215439771.3554.27.camel@localhost.localdomain> <4872246A.700@redhat.com> <1215442762.3554.44.camel@localhost.localdomain> Message-ID: <487230C4.6030209@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simo Sorce wrote: > On Mon, 2008-07-07 at 10:12 -0400, Stephen Gallagher wrote: > >> Simo, can you explain what effect setting the "LDAP_DEPRECATED" macro >> has elsewhere in the code? > > As far as I can see it only adds prototypes for "deprecated" functions > in the ldap API, like ldap_init() > > It seem to do nothing else, and it also seems ldap source themselves > define LDAP_DEPRECATED in some files to use these older APIs > > Simo. > ack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhyMMQACgkQc7MaxVic+2plGQCeN1Ba499StBhrkB5NOPYRqiWb WxYAoJx5/lMwFsuQLd89vJ+SSS2KyiCr =jpKX -----END PGP SIGNATURE----- From rcritten at redhat.com Mon Jul 7 17:27:50 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 07 Jul 2008 13:27:50 -0400 Subject: [Freeipa-devel] Using your own certs In-Reply-To: <1215116909.353.194.camel@localhost.localdomain> References: <486D32A5.7090703@redhat.com> <1215116805.353.191.camel@localhost.localdomain> <1215116909.353.194.camel@localhost.localdomain> Message-ID: <48725216.3010903@redhat.com> Simo Sorce wrote: > On Thu, 2008-07-03 at 16:26 -0400, Simo Sorce wrote: >> On Thu, 2008-07-03 at 16:12 -0400, Rob Crittenden wrote: >>> We wanted to provide an easy way to replace the self-signed certificates >>> generated during IPA installation so we created a tool, >>> ipa-server-certinstall. Unfortunately this is pretty badly broken in >>> v1.1. I've fixed it in the tip but there is one last issue sort of >>> peripherally related. >>> >>> When we create a replica using ipa-replica-prepare we pre-generate the >>> SSL certs for use on the replica. If you've replaced the DS certs then >>> you no longer have a CA to issue the certs so the replica preparation >>> falls down pretty hard. >>> >>> The "CA" in IPA isn't really much of anything but we do keep a serial >>> number file (/usr/share/ipa/serialno) to keep track of things. What I >>> was thinking is that if the DS certificate is replaced then we >>> rename/delete this file. I can then test for existence so I can do the >>> right thing in ipa-replica-prepare (by prompting for the 2 PKCS#12 files >>> to install on the remote server). >>> >>> Otherwise I'm going to need to test for the CA using certutil and try to >>> parse the output to see whether I can continue or not. >>> >>> Does this sound reasonable? >> Works for me, serialno is useless anyway if we are not using a >> selfsigned ca, go that route. > > The only gotcha is that we must move that file (in any case) > unde /var/lib/ipa, as we are not supposed to change stuff in /usr during > normal operations. Also we must make sure that file is not owned by the > rpm package or rpm will a) complain, b) put back a new file on upgrade. > > Simo. > Good point. I may in fact move it to /etc/ipa. rpm doesn't know about this file so we're ok there. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Jul 7 17:53:15 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 07 Jul 2008 13:53:15 -0400 Subject: [Freeipa-devel] Using your own certs In-Reply-To: <48725216.3010903@redhat.com> References: <486D32A5.7090703@redhat.com> <1215116805.353.191.camel@localhost.localdomain> <1215116909.353.194.camel@localhost.localdomain> <48725216.3010903@redhat.com> Message-ID: <1215453195.3554.61.camel@localhost.localdomain> On Mon, 2008-07-07 at 13:27 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Thu, 2008-07-03 at 16:26 -0400, Simo Sorce wrote: > >> On Thu, 2008-07-03 at 16:12 -0400, Rob Crittenden wrote: > >>> We wanted to provide an easy way to replace the self-signed certificates > >>> generated during IPA installation so we created a tool, > >>> ipa-server-certinstall. Unfortunately this is pretty badly broken in > >>> v1.1. I've fixed it in the tip but there is one last issue sort of > >>> peripherally related. > >>> > >>> When we create a replica using ipa-replica-prepare we pre-generate the > >>> SSL certs for use on the replica. If you've replaced the DS certs then > >>> you no longer have a CA to issue the certs so the replica preparation > >>> falls down pretty hard. > >>> > >>> The "CA" in IPA isn't really much of anything but we do keep a serial > >>> number file (/usr/share/ipa/serialno) to keep track of things. What I > >>> was thinking is that if the DS certificate is replaced then we > >>> rename/delete this file. I can then test for existence so I can do the > >>> right thing in ipa-replica-prepare (by prompting for the 2 PKCS#12 files > >>> to install on the remote server). > >>> > >>> Otherwise I'm going to need to test for the CA using certutil and try to > >>> parse the output to see whether I can continue or not. > >>> > >>> Does this sound reasonable? > >> Works for me, serialno is useless anyway if we are not using a > >> selfsigned ca, go that route. > > > > The only gotcha is that we must move that file (in any case) > > unde /var/lib/ipa, as we are not supposed to change stuff in /usr during > > normal operations. Also we must make sure that file is not owned by the > > rpm package or rpm will a) complain, b) put back a new file on upgrade. > > > > Simo. > > > > Good point. I may in fact move it to /etc/ipa. > > rpm doesn't know about this file so we're ok there. /var/lib is better for stuff that users are not supposed to touch. Simo. -- Simo Sorce * Red Hat, Inc * New York From mnagy at redhat.com Tue Jul 8 15:06:43 2008 From: mnagy at redhat.com (Martin Nagy) Date: Tue, 08 Jul 2008 17:06:43 +0200 Subject: [Freeipa-devel] [PATCH] Rewrite the dns-related code to use python-dns instead of dnsclient.py Message-ID: <48738283.9030300@redhat.com> I hope nothing more needs to be added (dependencies?). In order to run, we'll need python-dns package, see dnspython.org Also, ipa-python/dnsclient.py should probably get deleted, since it's no longer used by any file. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Rewrite-the-dns-related-code-to-use-python-dns-inste.patch Type: application/mbox Size: 12508 bytes Desc: not available URL: From ssorce at redhat.com Tue Jul 8 21:55:51 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 08 Jul 2008 17:55:51 -0400 Subject: [Freeipa-devel] [PATCH] Rewrite the dns-related code to use python-dns instead of dnsclient.py In-Reply-To: <48738283.9030300@redhat.com> References: <48738283.9030300@redhat.com> Message-ID: <1215554151.3554.165.camel@localhost.localdomain> On Tue, 2008-07-08 at 17:06 +0200, Martin Nagy wrote: > I hope nothing more needs to be added (dependencies?). In order to run, > we'll need python-dns package, see dnspython.org > Also, ipa-python/dnsclient.py should probably get deleted, since it's no > longer used by any file. Looks good to me (but haven't tested). Simo. -- Simo Sorce * Red Hat, Inc * New York From mendbayar_b at mongol.net Wed Jul 9 06:22:24 2008 From: mendbayar_b at mongol.net (Byambaa Mendbayar) Date: Wed, 09 Jul 2008 14:22:24 +0800 Subject: [Freeipa-devel] solved + next problem :-( In-Reply-To: <487220D4.9010108@redhat.com> References: <1215432079.12479.10.camel@linux-gzha.site> <487220D4.9010108@redhat.com> Message-ID: <1215584544.3459.44.camel@linux-gzha.site> ?Dear Rob, Thank you very much for you response and kind help. I have solved my problem it was I haven't use firefox from a console which is defined KRB5_CONFIG=/etc/krb5_ipa.conf variable. It means I have successes when I use /usr/sbin/firefox command from ?KRB5_CONFIG variable defined console. Thank you again Rob! Now I trying to configure my LAN's clients to joining our freeIPA server. With kind regards, Byambaa Mendbayar On Mon, 2008-07-07 at 09:57 -0400, Rob Crittenden wrote: > Byambaa Mendbayar wrote: > > Dear devs, > > > > I have solve my previous problem. It was blocked by firewall on my > > freeIPA server. After that i have getting still another error on my > > client's Firefox browser. It is a following on my browser: > > > > -------------------------------------------------------- > > Kerberos Authentication Failed > > Unable to verify your Kerberos credentials. Please make sure that you > > have valid Kerberos tickets (obtainable via kinit), and that you have > > configured your browser correctly. If you are still unable to access the > > IPA Web interface, please contact the helpdesk on for additional > > assistance. > > > > Import the IPA Certificate Authority. > > > > You can automatically configure your browser to work with Kerberos by > > importing the Certificate Authority above and clicking on the Configure > > Browser button. > > > > You must reload this page after importing the Certificate Authority for > > the automatic settings to work > > > > ?-------------------------------------------------------- > > > > I have checked everything again, again on my client computer it was all > > things OK (same stated in guideline). My client computer's OS is > > openSUSE 11.0 (I have installed krb5-client for kinit) > > > > What's wrong on my work? Please help and advice to me. > > > > Thanks and best regards, > > Byambaa Mendbayar > > Did you get a kerberos ticket yet? > > If you had firefox running prior to obtaining a ticket you probably need > to restart firefox. > > This page outlines how to debug the browser so you can better see what > is going on. > > http://people.redhat.com/mikeb/negotiate/ > > rob > From ssorce at redhat.com Wed Jul 9 14:21:51 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 09 Jul 2008 10:21:51 -0400 Subject: [Freeipa-devel] [PATCH] Fix attribute parsing in ipa-* cli commands Message-ID: <1215613311.3554.176.camel@localhost.localdomain> -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-attribute-parsing-so-that-you-can-add-a-DN-or-an.patch Type: application/mbox Size: 4915 bytes Desc: not available URL: From rcritten at redhat.com Wed Jul 9 14:25:21 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 09 Jul 2008 10:25:21 -0400 Subject: [Freeipa-devel] [PATCH] Fix attribute parsing in ipa-* cli commands In-Reply-To: <1215613311.3554.176.camel@localhost.localdomain> References: <1215613311.3554.176.camel@localhost.localdomain> Message-ID: <4874CA51.6030200@redhat.com> Simo Sorce wrote: > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Wed Jul 9 14:25:38 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 09 Jul 2008 10:25:38 -0400 Subject: [Freeipa-devel] [PATCH] Fix attribute parsing in ipa-* cli commands In-Reply-To: <1215613311.3554.176.camel@localhost.localdomain> References: <1215613311.3554.176.camel@localhost.localdomain> Message-ID: <4874CA62.4050808@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simo Sorce wrote: > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh0ymIACgkQc7MaxVic+2pZDgCfYijo4QWWE8y0YgedR+tBFjrE LugAn2IrPdKPPnbH9aeQ4cqTYZ2CjcDx =hrIQ -----END PGP SIGNATURE----- From tflipa at radiantpoint.com Wed Jul 9 15:47:50 2008 From: tflipa at radiantpoint.com (tflipa at radiantpoint.com) Date: Wed, 9 Jul 2008 15:47:50 +0000 Subject: [Freeipa-devel] Changing non-admin passwords Message-ID: <1924372811-1215618402-cardhu_decombobulator_blackberry.rim.net-808884140-@bxe120.bisx.prod.on.blackberry> Hi everyone I just setup freeIPA v1.1 for fedora 9 and am having an issue with user accounts. I added a new user from the admin account web interface and read online that it will automatically set the password expiration to now. The issue I am having is that I am unable to change my password on login from my windows or centos hosts. In windows I downloaded the kfw package and installed, however when I try and login with "proguser" it asks me to change my password. I do so and it shows up with the error message Failed to get credentials for prog user at .... Requested protocol version not supported. In Centos I try kinit proguser and it says the same thing. I tried looking this info up with no avail. What am I doing wrong? Thanks in advance Tim Faltemier Sent from my Verizon Wireless BlackBerry From ssorce at redhat.com Wed Jul 9 15:53:37 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 09 Jul 2008 11:53:37 -0400 Subject: [Freeipa-devel] Changing non-admin passwords In-Reply-To: <1924372811-1215618402-cardhu_decombobulator_blackberry.rim.net-808884140-@bxe120.bisx.prod.on.blackberry> References: <1924372811-1215618402-cardhu_decombobulator_blackberry.rim.net-808884140-@bxe120.bisx.prod.on.blackberry> Message-ID: <1215618817.3554.189.camel@localhost.localdomain> On Wed, 2008-07-09 at 15:47 +0000, tflipa at radiantpoint.com wrote: > Hi everyone > > I just setup freeIPA v1.1 for fedora 9 and am having an issue with user accounts. I added a new user from the admin account web interface and read online that it will automatically set the password expiration to now. The issue I am having is that I am unable to change my password on login from my windows or centos hosts. > > In windows I downloaded the kfw package and installed, however when I try and login with "proguser" it asks me to change my password. I do so and it shows up with the error message > > Failed to get credentials for prog user at .... > > Requested protocol version not supported. > > In Centos I try kinit proguser and it says the same thing. I tried looking this info up with no avail. What am I doing wrong? Do you have an AD domain controller in the same DNS domain ? Simo. -- Simo Sorce * Red Hat, Inc * New York From tflipa at radiantpoint.com Wed Jul 9 16:17:00 2008 From: tflipa at radiantpoint.com (tflipa at radiantpoint.com) Date: Wed, 9 Jul 2008 16:17:00 +0000 Subject: e: [Freeipa-devel] Changing non-admin passwords Message-ID: <1855822492-1215620141-cardhu_decombobulator_blackberry.rim.net-1549425934-@bxe120.bisx.prod.on.blackberry> Our corp. network is running Active Directory, however it is doing so at a different realm (XXX.REALM.COM) whereas I have made my realm simply (REALM.COM). I am able to login successfully with my admin account (and its appropriate password) and kerberos knows when I have entered the wrong password for proguser which tells me the requests are at least going to the ipaserver. Any ideas? Thanks Tim ------Original Message------ From: Simo Sorce To: tflipa at radiantpoint.com Cc: freeipa-devel at redhat.com Subject: Re: [Freeipa-devel] Changing non-admin passwords Sent: Jul 9, 2008 11:53 AM On Wed, 2008-07-09 at 15:47 +0000, tflipa at radiantpoint.com wrote: > Hi everyone > > I just setup freeIPA v1.1 for fedora 9 and am having an issue with user accounts. I added a new user from the admin account web interface and read online that it will automatically set the password expiration to now. The issue I am having is that I am unable to change my password on login from my windows or centos hosts. > > In windows I downloaded the kfw package and installed, however when I try and login with "proguser" it asks me to change my password. I do so and it shows up with the error message > > Failed to get credentials for prog user at .... > > Requested protocol version not supported. > > In Centos I try kinit proguser and it says the same thing. I tried looking this info up with no avail. What am I doing wrong? Do you have an AD domain controller in the same DNS domain ? Simo. -- Simo Sorce * Red Hat, Inc * New York Sent from my Verizon Wireless BlackBerry From ssorce at redhat.com Wed Jul 9 17:09:19 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 09 Jul 2008 13:09:19 -0400 Subject: e: [Freeipa-devel] Changing non-admin passwords In-Reply-To: <1855822492-1215620141-cardhu_decombobulator_blackberry.rim.net-1549425934-@bxe120.bisx.prod.on.blackberry> References: <1855822492-1215620141-cardhu_decombobulator_blackberry.rim.net-1549425934-@bxe120.bisx.prod.on.blackberry> Message-ID: <1215623359.3554.192.camel@localhost.localdomain> On Wed, 2008-07-09 at 16:17 +0000, tflipa at radiantpoint.com wrote: > Our corp. network is running Active Directory, however it is doing so > at a different realm (XXX.REALM.COM) whereas I have made my realm > simply (REALM.COM). > > I am able to login successfully with my admin account (and its > appropriate password) and kerberos knows when I have entered the wrong > password for proguser which tells me the requests are at least going > to the ipaserver. > > Any ideas? The realm in this case does not matter, DNS do, if the DNS domain is the same then you are going to be redirected to the windows kpasswd server if you have DNS lookups enabled. If that's the case you have 2 ways: a) statically configure your clients to not do DNS resolution and fix the IPa server in the ldap and krb configurations b) use a different DNS domain for IPA related clients/servers (like getting a delegated dns domain zone where you set SRV records to refer to IPA and not AD). Simo. -- Simo Sorce * Red Hat, Inc * New York From mnagy at redhat.com Wed Jul 9 18:21:29 2008 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 09 Jul 2008 20:21:29 +0200 Subject: [Freeipa-devel] [PATCH] Fix attribute parsing in ipa-* cli commands In-Reply-To: <1215613311.3554.176.camel@localhost.localdomain> References: <1215613311.3554.176.camel@localhost.localdomain> Message-ID: <487501A9.4060501@redhat.com> Simo Sorce wrote: > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel This patch might be a bit better. Regards, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-attribute-parsing-so-that-you-can-add-a-DN-or-an.patch Type: application/mbox Size: 3251 bytes Desc: not available URL: From ssorce at redhat.com Wed Jul 9 18:51:03 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 09 Jul 2008 14:51:03 -0400 Subject: [Freeipa-devel] [PATCH] Fix attribute parsing in ipa-* cli commands In-Reply-To: <487501A9.4060501@redhat.com> References: <1215613311.3554.176.camel@localhost.localdomain> <487501A9.4060501@redhat.com> Message-ID: <1215629463.3554.194.camel@localhost.localdomain> On Wed, 2008-07-09 at 20:21 +0200, Martin Nagy wrote: > This patch might be a bit better. ack, I love patches that accomplish the same thing with less changes. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Jul 9 20:58:20 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 09 Jul 2008 16:58:20 -0400 Subject: [Freeipa-devel] [PATCH] Fix attribute parsing in ipa-* cli commands In-Reply-To: <1215629463.3554.194.camel@localhost.localdomain> References: <1215613311.3554.176.camel@localhost.localdomain> <487501A9.4060501@redhat.com> <1215629463.3554.194.camel@localhost.localdomain> Message-ID: <1215637100.3554.212.camel@localhost.localdomain> On Wed, 2008-07-09 at 14:51 -0400, Simo Sorce wrote: > On Wed, 2008-07-09 at 20:21 +0200, Martin Nagy wrote: > > > This patch might be a bit better. > > ack, I love patches that accomplish the same thing with less changes. pushed this one -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Jul 9 20:58:45 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 09 Jul 2008 16:58:45 -0400 Subject: [Freeipa-devel] [PATCH] Fix openldap prototypes In-Reply-To: <487230C4.6030209@redhat.com> References: <1215439771.3554.27.camel@localhost.localdomain> <4872246A.700@redhat.com> <1215442762.3554.44.camel@localhost.localdomain> <487230C4.6030209@redhat.com> Message-ID: <1215637125.3554.214.camel@localhost.localdomain> On Mon, 2008-07-07 at 11:05 -0400, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Simo Sorce wrote: > > On Mon, 2008-07-07 at 10:12 -0400, Stephen Gallagher wrote: > > > >> Simo, can you explain what effect setting the "LDAP_DEPRECATED" macro > >> has elsewhere in the code? > > > > As far as I can see it only adds prototypes for "deprecated" functions > > in the ldap API, like ldap_init() > > > > It seem to do nothing else, and it also seems ldap source themselves > > define LDAP_DEPRECATED in some files to use these older APIs > > > > Simo. > > > ack pushed to master -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Jul 9 20:58:58 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 09 Jul 2008 16:58:58 -0400 Subject: [Freeipa-devel] [PATCH] Fix Admin ACIs In-Reply-To: <48722410.3020804@redhat.com> References: <1215439745.3554.25.camel@localhost.localdomain> <48722410.3020804@redhat.com> Message-ID: <1215637138.3554.216.camel@localhost.localdomain> On Mon, 2008-07-07 at 10:11 -0400, Stephen Gallagher wrote: > > ack pushed to master -- Simo Sorce * Red Hat, Inc * New York From sailer at sailer.dynip.lugs.ch Fri Jul 11 15:16:54 2008 From: sailer at sailer.dynip.lugs.ch (Thomas Sailer) Date: Fri, 11 Jul 2008 17:16:54 +0200 Subject: [Freeipa-devel] ipa-adduser stopped working after IPA 1.1 upgrade, any idea why? Message-ID: <1215789414.30863.111.camel@xbox360.hq.axsem.com> I installed an Fedora 8 IPA server just before IPA 1.0, and upgraded it using yum ever since. Now, after the upgrade to IPA 1.1, ipa-adduser stopped working. The ipa-* command line tools basically work: # ipa-finduser t.sailer Full Name: Thomas Sailer Home Directory: /home/t.sailer Login Shell: /bin/bash Login: t.sailer However, when I try to add a new user, I get the following: # ipa-adduser -f Test -l User testuser * not found I get the same error message when I try to add a new user in the web gui. The output of ipa-adduser -v is the following: send: "\n\nadd_user\n\n\n\n\ndn\n\n\n\nkrbprincipalname\ntestuser at XX.COM\n\n\ngivenname\nTest\n\n\nsn\nUser\n\n\nuid\ntestuser\n\n\n\n\n__NONE__\n\n\n\n" reply: 'HTTP/1.1 200 OK\r\n' header: Date: Fri, 11 Jul 2008 15:12:06 GMT header: Server: Apache/2.2.8 (Fedora) header: WWW-Authenticate: Negotiate YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRv8WeyE2CMkQ06ZOTF+EHQgB0fLZUvZ2f946rwYQHn4tpp1L9gFv0R3FUjgSqhzk/ntVUk/b6kQB50zYuDNupV5TiEGiN/ntLiIsoLiQNVZCraW7oy8FUJXZFUB0jZdCVM53c1fWzWul16mic5KDbL header: Content-Length: 270 header: Connection: close header: Content-Type: text/xml body: "\n\n\n\n\nfaultCode\n65539\n\n\nfaultString\n* not found\n\n\n\n\n" Does anybody have an idea, what the problem is? Another problem I have is that after I add a new user, and then try to log into a machine, no matter whether using gdm or ssh, I can login, and I even get the correct default principal (verified using klist), but the user cannot access NFSv4 shares with sec=krb5p. If I then do kdestroy; kinit xx at XX.COM, logout, and login again, everything works. Why doesn't it work the first time, without the kdestroy; kinit thing? Thanks, Tom From rcritten at redhat.com Fri Jul 11 15:51:23 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Jul 2008 11:51:23 -0400 Subject: [Freeipa-devel] [PATCH] fix PKCS#12 file import Message-ID: <4877817B.3070804@redhat.com> Fairly major changes to the way PKCS#12 files are handled. One can now pass in PKCS#12 files to be installed during initial installation and when a replica is prepared. ipa-server-certinstall should finally work as one would expect. This can be used to install from a PKCS#12 file post-installation. A few gotchas: - If you use your own certs you'll need to also get an object signing cert to sign the jar file we use for Firefox auto-config. See the docs here http://freeipa.org/page/AdministratorsGuide#Using_Your_Own_Certificate_with_Firefox - A PIN is required for all PKCS#12 files - When using ipa-server-certinstall services are not automatically restarted after installing a new cert. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-58-pkcs12.patch Type: text/x-patch Size: 30375 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jul 11 15:53:18 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Jul 2008 11:53:18 -0400 Subject: [Freeipa-devel] ipa-adduser stopped working after IPA 1.1 upgrade, any idea why? In-Reply-To: <1215789414.30863.111.camel@xbox360.hq.axsem.com> References: <1215789414.30863.111.camel@xbox360.hq.axsem.com> Message-ID: <487781EE.2050405@redhat.com> Thomas Sailer wrote: > I installed an Fedora 8 IPA server just before IPA 1.0, and upgraded it > using yum ever since. Now, after the upgrade to IPA 1.1, ipa-adduser > stopped working. > > The ipa-* command line tools basically work: > # ipa-finduser t.sailer > Full Name: Thomas Sailer > Home Directory: /home/t.sailer > Login Shell: /bin/bash > Login: t.sailer > > However, when I try to add a new user, I get the following: > # ipa-adduser -f Test -l User testuser > * not found > > I get the same error message when I try to add a new user in the web > gui. I think we'll need to see the LDAP access log to see what is going on. You'll find it in /var/log/dirsrv/slapd-YOURINSTANCE/access. Just a 20 or 30 line snippet should be fine. > Another problem I have is that after I add a new user, and then try to > log into a machine, no matter whether using gdm or ssh, I can login, and > I even get the correct default principal (verified using klist), but the > user cannot access NFSv4 shares with sec=krb5p. If I then do kdestroy; > kinit xx at XX.COM, logout, and login again, everything works. Why doesn't > it work the first time, without the kdestroy; kinit thing? Not really sure. I'd look in the KDC log (/var/log/krb5kdc) to see if something is being denied. Can you do a klist on the user to see if they got a service ticket for nfs? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Fri Jul 11 19:24:14 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 11 Jul 2008 15:24:14 -0400 Subject: [Freeipa-devel] [PATCH] fix PKCS#12 file import In-Reply-To: <4877817B.3070804@redhat.com> References: <4877817B.3070804@redhat.com> Message-ID: <1215804254.3554.288.camel@localhost.localdomain> On Fri, 2008-07-11 at 11:51 -0400, Rob Crittenden wrote: > > > Fairly major changes to the way PKCS#12 files are handled. > > One can now pass in PKCS#12 files to be installed during initial > installation and when a replica is prepared. > > ipa-server-certinstall should finally work as one would expect. This > can > be used to install from a PKCS#12 file post-installation. > > A few gotchas: > > - If you use your own certs you'll need to also get an object signing > cert to sign the jar file we use for Firefox auto-config. See the > docs > here > http://freeipa.org/page/AdministratorsGuide#Using_Your_Own_Certificate_with_Firefox > - A PIN is required for all PKCS#12 files > - When using ipa-server-certinstall services are not automatically > restarted after installing a new cert. Wow, quite a patch :-) At a first read it seem all ok, so I'd ack. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbooth at redhat.com Fri Jul 11 20:06:38 2008 From: mbooth at redhat.com (Matthew Booth) Date: Fri, 11 Jul 2008 21:06:38 +0100 Subject: [Freeipa-devel] Audit Message-ID: <4877BD4E.1090606@redhat.com> Are there yet any documented plans for how audit data will be transported from a client system to FreeIPA? Even better, is there any code? Thanks, Matt -- Matthew Booth, RHCA, RHCSS Red Hat, Global Professional Services M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 From dpal at redhat.com Fri Jul 11 20:14:30 2008 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 11 Jul 2008 16:14:30 -0400 Subject: [Freeipa-devel] Audit In-Reply-To: <4877BD4E.1090606@redhat.com> References: <4877BD4E.1090606@redhat.com> Message-ID: <4877BF26.7080802@redhat.com> Matthew Booth wrote: > Are there yet any documented plans for how audit data will be > transported from a client system to FreeIPA? Even better, is there any > code? > > Thanks, > > Matt There is no code at the moment but plans are to leverage AMQP for this. http://www.redhat.com/mrg/messaging/ Designs are currently in preliminary stage so nothing to show but as as we have it in a more or less presentable form we will publish them on freeIPA for review, comments and suggestions. Thank you -- Dmitri Pal Engineering Manager Red Hat Inc. From jdennis at redhat.com Fri Jul 11 21:46:15 2008 From: jdennis at redhat.com (John Dennis) Date: Fri, 11 Jul 2008 17:46:15 -0400 Subject: [Freeipa-devel] Audit In-Reply-To: <4877BF26.7080802@redhat.com> References: <4877BD4E.1090606@redhat.com> <4877BF26.7080802@redhat.com> Message-ID: <4877D4A7.2050609@redhat.com> Dmitri Pal wrote: > Matthew Booth wrote: >> Are there yet any documented plans for how audit data will be >> transported from a client system to FreeIPA? Even better, is there >> any code? >> >> Thanks, >> >> Matt > There is no code at the moment but plans are to leverage AMQP for this. > http://www.redhat.com/mrg/messaging/ AMPQ is likely to be the transport, however that does not define the protocol on the transport (e.g. the byte stream data format). We need to have a better idea of the data we are actually exchanging before we can define this. However, it's likely to be a very simple model with containers consisting of sets of key/value pairs. Google just released a open source implementation of their "protocol buffers", an efficient easy to use extensible data exchange format which is currently supporting a large part of Google's infrastructure. At first blush this seems to hold a lot of promise for exchanging audit data (over a secure fault tolerant layer such as AMQP). But we're still very much in a design phase on this. > > Designs are currently in preliminary stage so nothing to show but as > as we have it in a more or less presentable form we will publish them > on freeIPA for review, comments and suggestions. > > Thank you > -- John Dennis From rcritten at redhat.com Fri Jul 11 21:48:44 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 11 Jul 2008 17:48:44 -0400 Subject: [Freeipa-devel] ipa-adduser stopped working after IPA 1.1 upgrade, any idea why? In-Reply-To: <1215789414.30863.111.camel@xbox360.hq.axsem.com> References: <1215789414.30863.111.camel@xbox360.hq.axsem.com> Message-ID: <4877D53C.2070305@redhat.com> Thomas Sailer wrote: > I installed an Fedora 8 IPA server just before IPA 1.0, and upgraded it > using yum ever since. Now, after the upgrade to IPA 1.1, ipa-adduser > stopped working. > > The ipa-* command line tools basically work: > # ipa-finduser t.sailer > Full Name: Thomas Sailer > Home Directory: /home/t.sailer > Login Shell: /bin/bash > Login: t.sailer > > However, when I try to add a new user, I get the following: > # ipa-adduser -f Test -l User testuser > * not found > > I get the same error message when I try to add a new user in the web > gui. > > The output of ipa-adduser -v is the following: > send: "\n\nadd_user\n\n\n\n\ndn\n\n\n\nkrbprincipalname\ntestuser at XX.COM\n\n\ngivenname\nTest\n\n\nsn\nUser\n\n\nuid\ntestuser\n\n\n\n\n__NONE__\n\n\n\n" > reply: 'HTTP/1.1 200 OK\r\n' > header: Date: Fri, 11 Jul 2008 15:12:06 GMT > header: Server: Apache/2.2.8 (Fedora) > header: WWW-Authenticate: Negotiate YIGZBgkqhkiG9xIBAgICAG+BiTCBhqADAgEFoQMCAQ+iejB4oAMCARKicQRv8WeyE2CMkQ06ZOTF+EHQgB0fLZUvZ2f946rwYQHn4tpp1L9gFv0R3FUjgSqhzk/ntVUk/b6kQB50zYuDNupV5TiEGiN/ntLiIsoLiQNVZCraW7oy8FUJXZFUB0jZdCVM53c1fWzWul16mic5KDbL > header: Content-Length: 270 > header: Connection: close > header: Content-Type: text/xml > body: "\n\n\n\n\nfaultCode\n65539\n\n\nfaultString\n* not found\n\n\n\n\n" > > Does anybody have an idea, what the problem is? > > Another problem I have is that after I add a new user, and then try to > log into a machine, no matter whether using gdm or ssh, I can login, and > I even get the correct default principal (verified using klist), but the > user cannot access NFSv4 shares with sec=krb5p. If I then do kdestroy; > kinit xx at XX.COM, logout, and login again, everything works. Why doesn't > it work the first time, without the kdestroy; kinit thing? > > Thanks, > Tom To close the loop on this after some private discussions, the problem was that the group that was defined as the default user's group was not where IPA expected to find it. I've filed a bug on this, https://bugzilla.redhat.com/show_bug.cgi?id=455092 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mnagy at redhat.com Sat Jul 12 16:20:53 2008 From: mnagy at redhat.com (Martin Nagy) Date: Sat, 12 Jul 2008 18:20:53 +0200 Subject: [Freeipa-devel] [PATCH] fix PKCS#12 file import In-Reply-To: <4877817B.3070804@redhat.com> References: <4877817B.3070804@redhat.com> Message-ID: <20080712182053.72238989@notas> Rob Crittenden wrote: > Fairly major changes to the way PKCS#12 files are handled. > > One can now pass in PKCS#12 files to be installed during initial > installation and when a replica is prepared. > > ipa-server-certinstall should finally work as one would expect. This > can be used to install from a PKCS#12 file post-installation. > > A few gotchas: > > - If you use your own certs you'll need to also get an object signing > cert to sign the jar file we use for Firefox auto-config. See the > docs here > http://freeipa.org/page/AdministratorsGuide#Using_Your_Own_Certificate_with_Firefox > - A PIN is required for all PKCS#12 files > - When using ipa-server-certinstall services are not automatically > restarted after installing a new cert. > > rob Hi, there are few minor whitespace issues. Could you search for "[^ ] $" pattern and fix them? Martin From anmar at anmar.eu.org Sun Jul 13 14:14:46 2008 From: anmar at anmar.eu.org (Angel Marin) Date: Sun, 13 Jul 2008 16:14:46 +0200 Subject: [Freeipa-devel] Changing passwords with kpasswd not working Message-ID: <487A0DD6.3020402@anmar.eu.org> Hi, On a new freeipa 1.1 setup (CentOS 5, DS 8.0.3) changing passwords through kpasswd (or kinit for expired passwords) is not working. kpasswd gives (debuging enabled): Client anmar at ANMAR.EU.ORG trying to set password [asdfghjkl12] 'ldap_parse_result(): [Password generation not implemented. ]' Using ldappasswd works though. Any ideas? Regards, -- Angel Marin http://anmar.eu.org/ From ssorce at redhat.com Sun Jul 13 14:33:16 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 13 Jul 2008 10:33:16 -0400 Subject: [Freeipa-devel] Changing passwords with kpasswd not working In-Reply-To: <487A0DD6.3020402@anmar.eu.org> References: <487A0DD6.3020402@anmar.eu.org> Message-ID: <1215959596.4661.37.camel@localhost.localdomain> On Sun, 2008-07-13 at 16:14 +0200, Angel Marin wrote: > Hi, > > On a new freeipa 1.1 setup (CentOS 5, DS 8.0.3) changing passwords > through kpasswd (or kinit for expired passwords) is not working. kpasswd > gives (debuging enabled): > > Client anmar at ANMAR.EU.ORG trying to set password [asdfghjkl12] > 'ldap_parse_result(): [Password generation not implemented. ]' > > Using ldappasswd works though. Any ideas? This apparently happen if you compile binaries using mozldap libraries, we are still unsure why. Using --with-openldap=yes at configure time will make binaries use openldap libraries and solve your issue. Simo. -- Simo Sorce * Red Hat, Inc * New York From anmar at anmar.eu.org Sun Jul 13 15:14:07 2008 From: anmar at anmar.eu.org (Angel Marin) Date: Sun, 13 Jul 2008 17:14:07 +0200 Subject: [Freeipa-devel] Changing passwords with kpasswd not working In-Reply-To: <1215959596.4661.37.camel@localhost.localdomain> References: <487A0DD6.3020402@anmar.eu.org> <1215959596.4661.37.camel@localhost.localdomain> Message-ID: <487A1BBF.4060108@anmar.eu.org> Simo Sorce wrote: > On Sun, 2008-07-13 at 16:14 +0200, Angel Marin wrote: >> Hi, >> >> On a new freeipa 1.1 setup (CentOS 5, DS 8.0.3) changing passwords >> through kpasswd (or kinit for expired passwords) is not working. kpasswd >> gives (debuging enabled): >> >> Client anmar at ANMAR.EU.ORG trying to set password [asdfghjkl12] >> 'ldap_parse_result(): [Password generation not implemented. ]' >> >> Using ldappasswd works though. Any ideas? > > This apparently happen if you compile binaries using mozldap libraries, > we are still unsure why. > Using --with-openldap=yes at configure time will make binaries use > openldap libraries and solve your issue. It's working now, thanks! :) -- Angel Marin http://anmar.eu.org/ From rcritten at redhat.com Mon Jul 14 12:48:41 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Jul 2008 08:48:41 -0400 Subject: [Freeipa-devel] [PATCH] fix PKCS#12 file import In-Reply-To: <20080712182053.72238989@notas> References: <4877817B.3070804@redhat.com> <20080712182053.72238989@notas> Message-ID: <487B4B29.1000702@redhat.com> Martin Nagy wrote: > Rob Crittenden wrote: >> Fairly major changes to the way PKCS#12 files are handled. >> >> One can now pass in PKCS#12 files to be installed during initial >> installation and when a replica is prepared. >> >> ipa-server-certinstall should finally work as one would expect. This >> can be used to install from a PKCS#12 file post-installation. >> >> A few gotchas: >> >> - If you use your own certs you'll need to also get an object signing >> cert to sign the jar file we use for Firefox auto-config. See the >> docs here >> http://freeipa.org/page/AdministratorsGuide#Using_Your_Own_Certificate_with_Firefox >> - A PIN is required for all PKCS#12 files >> - When using ipa-server-certinstall services are not automatically >> restarted after installing a new cert. >> >> rob > > Hi, > there are few minor whitespace issues. Could you search for "[^ ] $" > pattern and fix them? I can fix those before committing it upstream. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Jul 14 13:39:11 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Jul 2008 09:39:11 -0400 Subject: [Freeipa-devel] [PATCH] fix PKCS#12 file import In-Reply-To: <1215804254.3554.288.camel@localhost.localdomain> References: <4877817B.3070804@redhat.com> <1215804254.3554.288.camel@localhost.localdomain> Message-ID: <487B56FF.2060104@redhat.com> Simo Sorce wrote: > On Fri, 2008-07-11 at 11:51 -0400, Rob Crittenden wrote: >> >> Fairly major changes to the way PKCS#12 files are handled. >> >> One can now pass in PKCS#12 files to be installed during initial >> installation and when a replica is prepared. >> >> ipa-server-certinstall should finally work as one would expect. This >> can >> be used to install from a PKCS#12 file post-installation. >> >> A few gotchas: >> >> - If you use your own certs you'll need to also get an object signing >> cert to sign the jar file we use for Firefox auto-config. See the >> docs >> here >> http://freeipa.org/page/AdministratorsGuide#Using_Your_Own_Certificate_with_Firefox >> - A PIN is required for all PKCS#12 files >> - When using ipa-server-certinstall services are not automatically >> restarted after installing a new cert. > > Wow, quite a patch :-) > > At a first read it seem all ok, so I'd ack. > > Simo. > Pushed to master. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Jul 14 18:28:08 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 14 Jul 2008 14:28:08 -0400 Subject: [Freeipa-devel] [PATCH] tool to manage search and user policy Message-ID: <487B9AB8.8070502@redhat.com> The CLI had no tool to manage the Search and User policy though the web UI did. This patch adds a new tool to edit these values. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-59-policy.patch Type: text/x-patch Size: 12385 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Jul 15 21:03:49 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 15 Jul 2008 17:03:49 -0400 Subject: [Freeipa-devel] [Fwd: 2 commits - ipa-server/ipa-kpasswd] Message-ID: <1216155829.23973.63.camel@localhost.localdomain> Pushed the following under the trivial rule (fixes a segfault) Simo. ipa-server/ipa-kpasswd/ipa_kpasswd.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) New commits: commit 67f62709f83997945b69919cd744ce936ddf5596 Author: Simo Sorce Date: Tue Jul 15 16:13:43 2008 -0400 In openvz we found out some interfaces may return a null pointer here. Skip them if no address is provided or we later get a segfault because we dereference a null pointer. diff --git a/ipa-server/ipa-kpasswd/ipa_kpasswd.c b/ipa-server/ipa-kpasswd/ipa_kpasswd.c index 7b4f39e..43ca223 100644 --- a/ipa-server/ipa-kpasswd/ipa_kpasswd.c +++ b/ipa-server/ipa-kpasswd/ipa_kpasswd.c @@ -1299,6 +1299,10 @@ int main(int argc, char *argv[]) for (tifa = ifa; tifa; tifa = tifa->ifa_next) { + if (NULL == tifa->ifa_addr) + /* uhmm no address ?? skip it */ + continue; + if (tifa->ifa_addr->sa_family != AF_INET && tifa->ifa_addr->sa_family != AF_INET6) { /* not interesting for us */ commit 4b4e0e151687621f552ababab7bb960c59e3de86 Author: Simo Sorce Date: Tue Jul 15 16:16:17 2008 -0400 fix typo diff --git a/ipa-server/ipa-kpasswd/ipa_kpasswd.c b/ipa-server/ipa-kpasswd/ipa_kpasswd.c index 1c3ac93..7b4f39e 100644 --- a/ipa-server/ipa-kpasswd/ipa_kpasswd.c +++ b/ipa-server/ipa-kpasswd/ipa_kpasswd.c @@ -1319,7 +1319,7 @@ int main(int argc, char *argv[]) hints.ai_flags = AI_NUMERICHOST; hints.ai_family = AF_UNSPEC; - /* this shoud return 2 entries, one for UDP and one for TCP */ + /* this should return 2 entries, one for UDP and one for TCP */ ret = getaddrinfo(host, "kpasswd", &hints, &ai); if (ret) { syslog(LOG_ERR, "Error getting address info (%s) for [%s]", -- Simo Sorce * Red Hat, Inc * New York From kwirth at redhat.com Wed Jul 16 19:45:37 2008 From: kwirth at redhat.com (Karl Wirth) Date: Wed, 16 Jul 2008 15:45:37 -0400 Subject: [Freeipa-devel] Feedback requested on Audit piece of IPA Message-ID: <487E4FE1.9030806@redhat.com> Hi, Currently we identified that audit system in general can be targeted to: *Collect data from different sources *Consolidate data into a combined storage *Provide effective tools to analyze collected data *Archive collected data including signing and compression *Restore data from archives for audit purposes or analyses We need your feedback on a couple of questions: 1) Should we store structured log data for analysis, original log data, or both - To do analysis of the log data, it would be better to structure it and store it. - But structured data is not the same as the original log file that it was taken from. Do we need the original log file format for reasons of compliance or can we throw it away? - Storing both parsed and unparsed data will have significant storage impact. 2) Should we parse the data into a structure format locally or back on IPA server? - Parsing locally and passing both parsed and original log data will increase network traffic but reduce load on server 3) What is the scope of what should be included in the audit data in addition to what we will get from syslog, rsyslog, auditd, etc. Those will give us data like user access to a system, keystrokes, etc. What beyond that is needed. For example, is the following needed: Files user accessed on a system Regards, Karl From daobrien at redhat.com Thu Jul 17 01:19:39 2008 From: daobrien at redhat.com (David O'Brien) Date: Thu, 17 Jul 2008 11:19:39 +1000 Subject: [Freeipa-devel] Feedback requested on Audit piece of IPA In-Reply-To: <487E4FE1.9030806@redhat.com> References: <487E4FE1.9030806@redhat.com> Message-ID: <487E9E2B.4080105@redhat.com> Karl Wirth wrote: > Hi, > > Currently we identified that audit system in general can be targeted to: > *Collect data from different sources > *Consolidate data into a combined storage > *Provide effective tools to analyze collected data > *Archive collected data including signing and compression > *Restore data from archives for audit purposes or analyses > > We need your feedback on a couple of questions: > 1) Should we store structured log data for analysis, original log data, > or both > - To do analysis of the log data, it would be better to structure it and > store it. > - But structured data is not the same as the original log file that it > was taken from. Do we need the original log file format for reasons of > compliance or can we throw it away? > - Storing both parsed and unparsed data will have significant storage > impact. > I'm just a beginner but my first reaction here is How is this going to affect a forensics situation? Shouldn't we always have access to untouched/raw data? We can parse it and create whatever structure is required on demand, but if we do it immediately and trash the original data, there's no going back. > 2) Should we parse the data into a structure format locally or back on > IPA server? > - Parsing locally and passing both parsed and original log data will > increase network traffic but reduce load on server > > 3) What is the scope of what should be included in the audit data in > addition to what we will get from syslog, rsyslog, auditd, etc. Those > will give us data like user access to a system, keystrokes, etc. What > beyond that is needed. For example, is the following needed: Files user > accessed on a system > > Regards, > Karl > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- David O'Brien IPA Content Author Red Hat Asia Pacific "We couldn't care less about comfort. We make you feel good." Federico Minoli CEO Ducati Motor S.p.A. From gunnar.hellekson at redhat.com Thu Jul 17 01:49:38 2008 From: gunnar.hellekson at redhat.com (Gunnar Hellekson) Date: Wed, 16 Jul 2008 20:49:38 -0500 Subject: [Freeipa-interest] Re: [Freeipa-devel] Feedback requested on Audit piece of IPA In-Reply-To: <487E9E2B.4080105@redhat.com> References: <487E4FE1.9030806@redhat.com> <487E9E2B.4080105@redhat.com> Message-ID: <02FA00E3-9152-40E9-B72F-C676A0431632@redhat.com> On 16-Jul-2008, at 8:19 PM, David O'Brien wrote: > Karl Wirth wrote: >> Currently we identified that audit system in general can be >> targeted to: >> *Collect data from different sources >> *Consolidate data into a combined storage >> *Provide effective tools to analyze collected data >> *Archive collected data including signing and compression >> *Restore data from archives for audit purposes or analyses >> >> We need your feedback on a couple of questions: >> 1) Should we store structured log data for analysis, original log >> data, >> or both >> - To do analysis of the log data, it would be better to structure >> it and >> store it. >> - But structured data is not the same as the original log file that >> it >> was taken from. Do we need the original log file format for >> reasons of >> compliance or can we throw it away? >> - Storing both parsed and unparsed data will have significant storage >> impact. >> > I'm just a beginner but my first reaction here is How is this going > to affect a forensics situation? Shouldn't we always have access to > untouched/raw data? We can parse it and create whatever structure is > required on demand, but if we do it immediately and trash the > original data, there's no going back. That's right. The user should always have the option of keeping the raw data. Often, there are requirements to maintain that data on write- once media, etc. so I don't think they'd take kindly to summarily trashing it. It would be great it we could accommodate the more hard- core folks, or folks who'd like the raw data for third-party log- eating tools. I feel pretty strongly that we should at least have the option of maintaining the original log file format. We can then allow the raw logs to be managed via logrotate rules for retiring, compression, signing, etc. This may mean that they do not get touched at all, which is what some customers want. >> 2) Should we parse the data into a structure format locally or back >> on >> IPA server? >> - Parsing locally and passing both parsed and original log data will >> increase network traffic but reduce load on server The a priori "forensic expert" in me is suspicious of munging data on the client. It seems as though we're solving a problem destructively, since we lose the ability to verify the original data. What happens if there's a bug in the parser? If we're supporting this, it should be optional. >> 3) What is the scope of what should be included in the audit data in >> addition to what we will get from syslog, rsyslog, auditd, etc. >> Those >> will give us data like user access to a system, keystrokes, etc. >> What >> beyond that is needed. For example, is the following needed: Files >> user >> accessed on a system Between a keystroke logger, syslog and auditd, that takes care of just about everything, including a log of the files a user accessed on a system. g -- Gunnar Hellekson, RHCE Lead Architect, Red Hat Government From dpal at redhat.com Thu Jul 17 12:49:51 2008 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 17 Jul 2008 08:49:51 -0400 Subject: [Freeipa-interest] Re: [Freeipa-devel] Feedback requested on Audit piece of IPA In-Reply-To: <02FA00E3-9152-40E9-B72F-C676A0431632@redhat.com> References: <487E4FE1.9030806@redhat.com> <487E9E2B.4080105@redhat.com> <02FA00E3-9152-40E9-B72F-C676A0431632@redhat.com> Message-ID: <487F3FEF.2050408@redhat.com> Gunnar Hellekson wrote: > On 16-Jul-2008, at 8:19 PM, David O'Brien wrote: >> Karl Wirth wrote: >>> Currently we identified that audit system in general can be targeted >>> to: >>> *Collect data from different sources >>> *Consolidate data into a combined storage >>> *Provide effective tools to analyze collected data >>> *Archive collected data including signing and compression >>> *Restore data from archives for audit purposes or analyses >>> >>> We need your feedback on a couple of questions: >>> 1) Should we store structured log data for analysis, original log data, >>> or both >>> - To do analysis of the log data, it would be better to structure it >>> and >>> store it. >>> - But structured data is not the same as the original log file that it >>> was taken from. Do we need the original log file format for >>> reasons of >>> compliance or can we throw it away? >>> - Storing both parsed and unparsed data will have significant storage >>> impact. >>> >> I'm just a beginner but my first reaction here is How is this going >> to affect a forensics situation? Shouldn't we always have access to >> untouched/raw data? We can parse it and create whatever structure is >> required on demand, but if we do it immediately and trash the >> original data, there's no going back. > > That's right. The user should always have the option of keeping the > raw data. Often, there are requirements to maintain that data on > write-once media, etc. so I don't think they'd take kindly to > summarily trashing it. It would be great it we could accommodate the > more hard-core folks, or folks who'd like the raw data for third-party > log-eating tools. I feel pretty strongly that we should at least have > the option of maintaining the original log file format. We can then > allow the raw logs to be managed via logrotate rules for retiring, > compression, signing, etc. This may mean that they do not get touched > at all, which is what some customers want. > But this means that we will have to store twice as much data. It will be terabytes! Is this what customers want? I would require a high end hardware to process these logs if we want to provide any kind of analysis and correlation. This will be a trade off. We can collect raw data - not a big deal I just wanted to be sure that this is really the case. >>> 2) Should we parse the data into a structure format locally or back on >>> IPA server? >>> - Parsing locally and passing both parsed and original log data will >>> increase network traffic but reduce load on server > > The a priori "forensic expert" in me is suspicious of munging data on > the client. It seems as though we're solving a problem destructively, > since we lose the ability to verify the original data. What happens if > there's a bug in the parser? If we're supporting this, it should be > optional. Ok we will provide an optional capability to preserve raw data. What about filtering? The problem with the filtering is that you need to parse and sort out raw data. As a result you have raw data and parsed out data. Then you apply filter to parsed data and decide based upon the central policy if this event is of interest to you. If it is not of interest you throw it away. Is it a valid use case or in reality we need to collect everything and not filter anything? If we collect everything there is no need to parse on the client and thus there is only raw data to transfer to central location. We can do parsing there . This approach saves processing time on client and reduces network traffic but adds more burden to the server. We can create different architectures and provide same set of features, the question is more about which use case is primary. We should optimize the system for the primary use case. I see two main use cases: a) Customer wants to preserve and collect original data untouched without filtering and store it. Requirements to have capabilities to search and analyze are secondary. b) Customer wants to collect data for effective processing and analysis. Filtering is crucial. Raw data is optional and not that important. We are not talking about real time log monitoring and intrusion detection. There is a separate product to do this (Prelude + IDS) and we do not want to duplicate it. If we have to solve both use cases above we will seem to have worst of both worlds: a lot of processing, a lot of data to transfer and store. If we can select which use case is dominating we would be able to tune up the design to solve it best. Is this possible or these two use case are equal? > >>> 3) What is the scope of what should be included in the audit data in >>> addition to what we will get from syslog, rsyslog, auditd, etc. Those >>> will give us data like user access to a system, keystrokes, etc. What >>> beyond that is needed. For example, is the following needed: Files >>> user >>> accessed on a system > > Between a keystroke logger, syslog and auditd, that takes care of just > about everything, including a log of the files a user accessed on a > system. The problem is more about other platforms. On Linux we have auditd, inotify and a lot of other nice things that would help. But how to monitor file changes on Solaris, HP, AIX? We want to collect logs from all kinds of machines. Do we need to worry about this and build audit information collecting tools for those systems? Which tools a priority? How far we need to go? Dmitri > > g > > --Gunnar Hellekson, RHCE > Lead Architect, Red Hat Government > > > > > _______________________________________________ > Freeipa-interest mailing list > Freeipa-interest at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-interest -- Dmitri Pal Engineering Manager Red Hat Inc. From nkinder at redhat.com Thu Jul 17 21:55:19 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 17 Jul 2008 14:55:19 -0700 Subject: [Freeipa-devel] [Patch] Re-base memberOf plug-in off of current FDS memberOf plug-in Message-ID: <487FBFC7.9070403@redhat.com> This fixes many, many issues with the memberOf plug-in. -NGK -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Re-base-memberOf-plug-in-off-of-current-FDS-memberOf.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jul 18 14:17:11 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 18 Jul 2008 10:17:11 -0400 Subject: [Freeipa-devel] [Patch] Re-base memberOf plug-in off of current FDS memberOf plug-in In-Reply-To: <487FBFC7.9070403@redhat.com> References: <487FBFC7.9070403@redhat.com> Message-ID: <4880A5E7.5030909@redhat.com> Nathan Kinder wrote: > This fixes many, many issues with the memberOf plug-in. > > -NGK > > Wow, a lot to go through. I think I grok most of this. A couple of comments/questions. Most of the functions are renamed in a more generic way, I'm presuming to make it easier to keep in sync with the FDS version of the plugin, right? But some functions weren't renamed, ipamo_postop_init() for one. Do we want to go ahead and do that? Some comment blocks look really strange in the patch too: - * Online tasks interface (to support import, export, etc) - * After some cleanup, we could consider making these public. - */ + * * Online tasks interface (to support import, export, etc) + * * After some cleanup, we could consider making these public. + * */ What is the purpose of dont_allow_that()? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Fri Jul 18 15:59:03 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 18 Jul 2008 08:59:03 -0700 Subject: [Freeipa-devel] [Patch] Re-base memberOf plug-in off of current FDS memberOf plug-in In-Reply-To: <4880A5E7.5030909@redhat.com> References: <487FBFC7.9070403@redhat.com> <4880A5E7.5030909@redhat.com> Message-ID: <4880BDC7.6060303@redhat.com> Rob Crittenden wrote: > Nathan Kinder wrote: >> This fixes many, many issues with the memberOf plug-in. >> >> -NGK >> >> > > Wow, a lot to go through. I think I grok most of this. > > A couple of comments/questions. > > Most of the functions are renamed in a more generic way, I'm presuming > to make it easier to keep in sync with the FDS version of the plugin, > right? Yes. I want to make it as easy as possible to diff between the IPA and FDS memberOf plug-in code. This should help in any future fix porting work. > > But some functions weren't renamed, ipamo_postop_init() for one. Do we > want to go ahead and do that? This one function is the entry function for the plug-in. The configuration entry in dse.ldif has an attribute with this function name that is used to load the plug-in. I didn't want to do anything that required us to change the configuration entry since we'd need to handle making those changes during an upgrade. > > Some comment blocks look really strange in the patch too: > > - * Online tasks interface (to support import, export, etc) > - * After some cleanup, we could consider making these public. > - */ > + * * Online tasks interface (to support import, export, etc) > + * * After some cleanup, we could consider making these public. > + * */ That's caused by vim trying to be smart. We can clean those up. > > What is the purpose of dont_allow_that()? The FDS memberof plug-in allows dynamic configuration changes. In IPA, we are hardcoding the attribute that memberOf uses, but I wanted to leave the dynamic config code in place for the most part. We register callback functions to be invoked when one performs different operations against the memberOf plug-in's config entry. We don't want to allow anyone to modify, rename, or delete our config entry while the server is running, so we register dont_allow_that() as the callback for these types of operations. This will result in a DSE_UNWILLING_TO_PERFORM being returned to the client attempting to modify the config entry. -NGK > > rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jul 18 16:47:04 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 18 Jul 2008 12:47:04 -0400 Subject: [Freeipa-devel] [Patch] Re-base memberOf plug-in off of current FDS memberOf plug-in In-Reply-To: <4880BDC7.6060303@redhat.com> References: <487FBFC7.9070403@redhat.com> <4880A5E7.5030909@redhat.com> <4880BDC7.6060303@redhat.com> Message-ID: <4880C908.60907@redhat.com> Nathan Kinder wrote: > Rob Crittenden wrote: >> Nathan Kinder wrote: >>> This fixes many, many issues with the memberOf plug-in. >>> >>> -NGK >>> >>> >> >> Wow, a lot to go through. I think I grok most of this. >> >> A couple of comments/questions. >> >> Most of the functions are renamed in a more generic way, I'm presuming >> to make it easier to keep in sync with the FDS version of the plugin, >> right? > Yes. I want to make it as easy as possible to diff between the IPA and > FDS memberOf plug-in code. This should help in any future fix porting > work. >> >> But some functions weren't renamed, ipamo_postop_init() for one. Do we >> want to go ahead and do that? > This one function is the entry function for the plug-in. The > configuration entry in dse.ldif has an attribute with this function name > that is used to load the plug-in. I didn't want to do anything that > required us to change the configuration entry since we'd need to handle > making those changes during an upgrade. >> >> Some comment blocks look really strange in the patch too: >> >> - * Online tasks interface (to support import, export, etc) >> - * After some cleanup, we could consider making these public. >> - */ >> + * * Online tasks interface (to support import, export, etc) >> + * * After some cleanup, we could consider making these public. >> + * */ > That's caused by vim trying to be smart. We can clean those up. >> >> What is the purpose of dont_allow_that()? > The FDS memberof plug-in allows dynamic configuration changes. In IPA, > we are hardcoding the attribute that memberOf uses, but I wanted to > leave the dynamic config code in place for the most part. We register > callback functions to be invoked when one performs different operations > against the memberOf plug-in's config entry. We don't want to allow > anyone to modify, rename, or delete our config entry while the server is > running, so we register dont_allow_that() as the callback for these > types of operations. This will result in a DSE_UNWILLING_TO_PERFORM > being returned to the client attempting to modify the config entry. > > -NGK Ok, then ack rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Fri Jul 18 16:57:08 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 18 Jul 2008 09:57:08 -0700 Subject: [Freeipa-devel] [Patch] Re-base memberOf plug-in off of current FDS memberOf plug-in In-Reply-To: <4880C908.60907@redhat.com> References: <487FBFC7.9070403@redhat.com> <4880A5E7.5030909@redhat.com> <4880BDC7.6060303@redhat.com> <4880C908.60907@redhat.com> Message-ID: <4880CB64.3080308@redhat.com> Rob Crittenden wrote: > Nathan Kinder wrote: >> Rob Crittenden wrote: >>> Nathan Kinder wrote: >>>> This fixes many, many issues with the memberOf plug-in. >>>> >>>> -NGK >>>> >>>> >>> >>> Wow, a lot to go through. I think I grok most of this. >>> >>> A couple of comments/questions. >>> >>> Most of the functions are renamed in a more generic way, I'm >>> presuming to make it easier to keep in sync with the FDS version of >>> the plugin, right? >> Yes. I want to make it as easy as possible to diff between the IPA >> and FDS memberOf plug-in code. This should help in any future fix >> porting work. >>> >>> But some functions weren't renamed, ipamo_postop_init() for one. Do >>> we want to go ahead and do that? >> This one function is the entry function for the plug-in. The >> configuration entry in dse.ldif has an attribute with this function >> name that is used to load the plug-in. I didn't want to do anything >> that required us to change the configuration entry since we'd need to >> handle making those changes during an upgrade. >>> >>> Some comment blocks look really strange in the patch too: >>> >>> - * Online tasks interface (to support import, export, etc) >>> - * After some cleanup, we could consider making these public. >>> - */ >>> + * * Online tasks interface (to support import, export, etc) >>> + * * After some cleanup, we could consider making these public. >>> + * */ >> That's caused by vim trying to be smart. We can clean those up. I've attached a patch that cleans up these mangled comments. -NGK >>> >>> What is the purpose of dont_allow_that()? >> The FDS memberof plug-in allows dynamic configuration changes. In >> IPA, we are hardcoding the attribute that memberOf uses, but I wanted >> to leave the dynamic config code in place for the most part. We >> register callback functions to be invoked when one performs different >> operations against the memberOf plug-in's config entry. We don't >> want to allow anyone to modify, rename, or delete our config entry >> while the server is running, so we register dont_allow_that() as the >> callback for these types of operations. This will result in a >> DSE_UNWILLING_TO_PERFORM being returned to the client attempting to >> modify the config entry. >> >> -NGK > > Ok, then ack > > rob -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Cleaned-up-comments-that-were-mangled-by-vim.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jul 18 19:46:02 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 18 Jul 2008 15:46:02 -0400 Subject: [Freeipa-devel] [Patch] Re-base memberOf plug-in off of current FDS memberOf plug-in In-Reply-To: <4880CB64.3080308@redhat.com> References: <487FBFC7.9070403@redhat.com> <4880A5E7.5030909@redhat.com> <4880BDC7.6060303@redhat.com> <4880C908.60907@redhat.com> <4880CB64.3080308@redhat.com> Message-ID: <4880F2FA.9090601@redhat.com> Nathan Kinder wrote: > Rob Crittenden wrote: >> Nathan Kinder wrote: >>> Rob Crittenden wrote: >>>> Nathan Kinder wrote: >>>>> This fixes many, many issues with the memberOf plug-in. >>>>> >>>>> -NGK >>>>> >>>>> >>>> >>>> Wow, a lot to go through. I think I grok most of this. >>>> >>>> A couple of comments/questions. >>>> >>>> Most of the functions are renamed in a more generic way, I'm >>>> presuming to make it easier to keep in sync with the FDS version of >>>> the plugin, right? >>> Yes. I want to make it as easy as possible to diff between the IPA >>> and FDS memberOf plug-in code. This should help in any future fix >>> porting work. >>>> >>>> But some functions weren't renamed, ipamo_postop_init() for one. Do >>>> we want to go ahead and do that? >>> This one function is the entry function for the plug-in. The >>> configuration entry in dse.ldif has an attribute with this function >>> name that is used to load the plug-in. I didn't want to do anything >>> that required us to change the configuration entry since we'd need to >>> handle making those changes during an upgrade. >>>> >>>> Some comment blocks look really strange in the patch too: >>>> >>>> - * Online tasks interface (to support import, export, etc) >>>> - * After some cleanup, we could consider making these public. >>>> - */ >>>> + * * Online tasks interface (to support import, export, etc) >>>> + * * After some cleanup, we could consider making these public. >>>> + * */ >>> That's caused by vim trying to be smart. We can clean those up. > I've attached a patch that cleans up these mangled comments. > > -NGK >>>> >>>> What is the purpose of dont_allow_that()? >>> The FDS memberof plug-in allows dynamic configuration changes. In >>> IPA, we are hardcoding the attribute that memberOf uses, but I wanted >>> to leave the dynamic config code in place for the most part. We >>> register callback functions to be invoked when one performs different >>> operations against the memberOf plug-in's config entry. We don't >>> want to allow anyone to modify, rename, or delete our config entry >>> while the server is running, so we register dont_allow_that() as the >>> callback for these types of operations. This will result in a >>> DSE_UNWILLING_TO_PERFORM being returned to the client attempting to >>> modify the config entry. >>> >>> -NGK >> >> Ok, then ack >> >> rob > ack Pushed both to master. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mnagy at redhat.com Mon Jul 21 10:48:51 2008 From: mnagy at redhat.com (Martin Nagy) Date: Mon, 21 Jul 2008 12:48:51 +0200 Subject: [Freeipa-devel] [PATCH] Wrap up the raw_input() to user_input() for convenience and uniformity Message-ID: <20080721124851.42114c64@notas> A non-text attachment was scrubbed... Name: 0001-Wrap-up-the-raw_input-to-user_input-for-convenie.patch Type: text/x-patch Size: 24659 bytes Desc: not available URL: From email.ahmedkamal at googlemail.com Mon Jul 21 12:46:03 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Mon, 21 Jul 2008 15:46:03 +0300 Subject: [Freeipa-devel] policy enforcement mechanics Message-ID: <3da3b5b40807210546t58ba280al17780f513d736141@mail.gmail.com> Hi everyone, Is there any document or wiki page that describes exactly how policy enforcement is going to be handled in freeIPA. I'm basically interested in stuff like controlling unusual application behavior, like what if I allow vim to a user, and the user does ":bash" to get a shell ? Also, about auditing .. Would it be possible to audit the whole session of a user (all files he touched/changed, all commands he used) ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Jul 21 14:19:10 2008 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 21 Jul 2008 10:19:10 -0400 Subject: [Freeipa-devel] policy enforcement mechanics In-Reply-To: <3da3b5b40807210546t58ba280al17780f513d736141@mail.gmail.com> References: <3da3b5b40807210546t58ba280al17780f513d736141@mail.gmail.com> Message-ID: <48849ADE.8040102@redhat.com> Ahmed Kamal wrote: > Hi everyone, > > Is there any document or wiki page that describes exactly how policy > enforcement is going to be handled in freeIPA. Not yet. We are working on it. We will announce it as soon as we have it ready for everybody to look at and comment. > I'm basically interested in stuff like controlling unusual application > behavior, like what if I allow vim to a user, and the user does > ":bash" to get a shell ? The activity of the user will be captured via audit system. We are looking into monitoring file access. > Also, about auditing .. Would it be possible to audit the whole > session of a user (all files he touched/changed, all commands he used) ? > We will be collecting information from different sources. Including : * Our client that will provide authentication and host based access control (all supported platforms) * Syslog (All platforms) * Rsyslog (TBD) * Auditd (Linux only). Auditd has capability to do keystroke logging so we will be able to capture this too. * Other sources with some customarily defined parsing mechanisms. This is under design and we do not have a clear picture of this part yet. Thank you Dmitri > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Dmitri Pal Engineering Manager Red Hat Inc. From rcritten at redhat.com Mon Jul 21 19:49:01 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 21 Jul 2008 15:49:01 -0400 Subject: [Freeipa-devel] [PATCH] catch default group not found when adding a user Message-ID: <4884E82D.7050704@redhat.com> When adding a new user we find the default group and set the primary GID based on that. If the group isn't found we should, and do quit. The problem is that the wrong exception was used so we returned a really crappy error message instead of a descriptive one. This fixes that. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-60-defaultgroup.patch Type: text/x-patch Size: 1521 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Mon Jul 21 19:49:15 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 21 Jul 2008 15:49:15 -0400 Subject: [Freeipa-devel] [PATCH] Wrap up the raw_input() to user_input() for convenience and uniformity In-Reply-To: <20080721124851.42114c64@notas> References: <20080721124851.42114c64@notas> Message-ID: <4884E83B.8060009@redhat.com> Martin Nagy wrote: > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ack -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Mon Jul 21 19:50:56 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 21 Jul 2008 15:50:56 -0400 Subject: [Freeipa-devel] [PATCH] catch default group not found when adding a user In-Reply-To: <4884E82D.7050704@redhat.com> References: <4884E82D.7050704@redhat.com> Message-ID: <4884E8A0.7010202@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Crittenden wrote: > When adding a new user we find the default group and set the primary GID > based on that. If the group isn't found we should, and do quit. The > problem is that the wrong exception was used so we returned a really > crappy error message instead of a descriptive one. This fixes that. > > rob > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiE6KAACgkQc7MaxVic+2ooFQCgtBc9TP8VJz+IB180X2/dGZTt nyYAoJWNeAXjg6z1u00jDCdhbS5Xv5lh =W/Pl -----END PGP SIGNATURE----- From nkinder at redhat.com Mon Jul 21 19:50:32 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 21 Jul 2008 12:50:32 -0700 Subject: [Freeipa-devel] [PATCH] catch default group not found when adding a user In-Reply-To: <4884E82D.7050704@redhat.com> References: <4884E82D.7050704@redhat.com> Message-ID: <4884E888.6090905@redhat.com> Rob Crittenden wrote: > When adding a new user we find the default group and set the primary > GID based on that. If the group isn't found we should, and do quit. > The problem is that the wrong exception was used so we returned a > really crappy error message instead of a descriptive one. This fixes > that. ack > > rob > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From Frank.Botte at web.de Tue Jul 22 16:30:07 2008 From: Frank.Botte at web.de (Frank Botte) Date: Tue, 22 Jul 2008 18:30:07 +0200 Subject: [Freeipa-devel] ipa-kpasswd: segfault on startup Message-ID: <254401105@web.de> Hi list, while playing around with free-ipa i had the problem, that ipa-kpasswd kept segfaulting on startup. The problem started when i accidentally added a user that was already in the local userbase (/etc/passwd) After poking around a little bit in the code i found out the following: In line 1297 of ipa-kpasswd.c starts a for-loop that goes through a linked list of 'ifaddrs'. On my system one of those ifaddrs contains a NULL pointer for 'tifa->ifa_addr' and this is where ipa-kapasswd segfaults. I fixed the problem for me by simply checking if tifa->ifa_addr is a valid pointer (see patch) I have no clue if this is just some weirdness in my system or if this is a real problem, so can somebody with more knowledge please review my patch and include it if appropriate bye Frank -- The problem with troubleshooting is sometimes the trouble shoots back !! _________________________________________________________________ WEB.DE schenkt Ihnen jeden Monat einen hochkar?tigen Blockbuster von maxdome! Jetzt anmelden unter http://www.blockbuster.web.de -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa-kpasswd.patch Type: application/octet-stream Size: 468 bytes Desc: not available URL: From rcritten at redhat.com Tue Jul 22 18:45:30 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Jul 2008 14:45:30 -0400 Subject: [Freeipa-devel] ipa-kpasswd: segfault on startup In-Reply-To: <254401105@web.de> References: <254401105@web.de> Message-ID: <48862ACA.9020609@redhat.com> Frank Botte wrote: > Hi list, > > while playing around with free-ipa i had the problem, that ipa-kpasswd kept segfaulting on startup. > The problem started when i accidentally added a user that was already in the local userbase (/etc/passwd) > > After poking around a little bit in the code i found out the following: > > In line 1297 of ipa-kpasswd.c starts a for-loop that goes through a linked list of 'ifaddrs'. On my system one > of those ifaddrs contains a NULL pointer for 'tifa->ifa_addr' and this is where ipa-kapasswd segfaults. > > I fixed the problem for me by simply checking if tifa->ifa_addr is a valid pointer (see patch) > > I have no clue if this is just some weirdness in my system or if this is a real problem, so can somebody > with more knowledge please review my patch and include it if appropriate > > bye > Frank > Thanks for the patch. This is fixed in our source tip already, someone reported it in our IRC channel (#freeipa) last week (you perhaps?) It will be contained when we do our next release (no concrete plans on when that will be at the moment). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Jul 22 19:29:36 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 22 Jul 2008 15:29:36 -0400 Subject: [Freeipa-devel] [PATCH] fix encoding of loaded templates Message-ID: <48863520.8070704@redhat.com> We used to manually load the template files for the edit pages using turbogears.meta.load_kid_template(). Unfortunately this went through the one code path where encoding was completely ignored. It ended up defaulting to sys.getdefaultencoding() which is 'ascii'. So even though most of the templates are loaded as 'utf-8' the few that really mattered weren't. The fix is to call kid.load_template() ourselves and set the encoding of the class we just loaded to either the setting in the app.cfg file or to the normal default value of 'utf-8'. This does not remove all i18n issues. We still cannot handle non-ascii characters that will appear in the DN (group name and uid are two I know of). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-61-encoding.patch Type: text/x-patch Size: 8101 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Jul 23 14:13:28 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 23 Jul 2008 10:13:28 -0400 Subject: [Freeipa-devel] [PATCH] Wrap up the raw_input() to user_input() for convenience and uniformity In-Reply-To: <4884E83B.8060009@redhat.com> References: <20080721124851.42114c64@notas> <4884E83B.8060009@redhat.com> Message-ID: <48873C88.50409@redhat.com> Rob Crittenden wrote: > Martin Nagy wrote: >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ack > Pushed to master, f7ca405716b1ee8b92a940e07cd611f6b025795d -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Jul 23 14:14:04 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 23 Jul 2008 10:14:04 -0400 Subject: [Freeipa-devel] [PATCH] catch default group not found when adding a user In-Reply-To: <4884E888.6090905@redhat.com> References: <4884E82D.7050704@redhat.com> <4884E888.6090905@redhat.com> Message-ID: <48873CAC.6000204@redhat.com> Nathan Kinder wrote: > Rob Crittenden wrote: >> When adding a new user we find the default group and set the primary >> GID based on that. If the group isn't found we should, and do quit. >> The problem is that the wrong exception was used so we returned a >> really crappy error message instead of a descriptive one. This fixes >> that. > ack >> >> rob >> ------------------------------------------------------------------------ pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Wed Jul 23 14:20:32 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 23 Jul 2008 10:20:32 -0400 Subject: [Freeipa-devel] [PATCH] Support password change operation by direct manipulation of userPassword Message-ID: <1216822832.937.16.camel@hopeson> This is an initial patch to support generating kerberos key material (and other hashes) when an ldap ADD or MODIFY operation is performed on the userPassword attribute. Basic testing seem to work, but I'd like feedback both on the method used and on the implementation. I have probably missed something as I had to work on the patch at different times with large intervals between each coding session, so please test it if you can before I push it to master. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Implement-password-operation-checks-and-key-material.patch Type: application/mbox Size: 39199 bytes Desc: not available URL: From rcritten at redhat.com Wed Jul 23 19:50:42 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 23 Jul 2008 15:50:42 -0400 Subject: [Freeipa-devel] [PATCH] Support password change operation by direct manipulation of userPassword In-Reply-To: <1216822832.937.16.camel@hopeson> References: <1216822832.937.16.camel@hopeson> Message-ID: <48878B92.3080707@redhat.com> Simo Sorce wrote: > This is an initial patch to support generating kerberos key material > (and other hashes) when an ldap ADD or MODIFY operation is performed on > the userPassword attribute. > > Basic testing seem to work, but I'd like feedback both on the method > used and on the implementation. I have probably missed something as I > had to work on the patch at different times with large intervals between > each coding session, so please test it if you can before I push it to > master. > > Simo. > I'm sure Nathan will have some other input but here are my initial thoughts: You can probably pull out a bunch of code into functions that is duplicated in add and mod: - the is_krb and is_smb code checks - determining if the password is hashed or not I wonder if {CLEAR} is #defined somewhere... Is "unhashed#user#password" some sort of magic string? It generally looks ok but DS plugins aren't my forte. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Wed Jul 23 19:59:30 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 23 Jul 2008 12:59:30 -0700 Subject: [Freeipa-devel] [PATCH] Support password change operation by direct manipulation of userPassword In-Reply-To: <48878B92.3080707@redhat.com> References: <1216822832.937.16.camel@hopeson> <48878B92.3080707@redhat.com> Message-ID: <48878DA2.9090507@redhat.com> Rob Crittenden wrote: > Simo Sorce wrote: >> This is an initial patch to support generating kerberos key material >> (and other hashes) when an ldap ADD or MODIFY operation is performed on >> the userPassword attribute. >> >> Basic testing seem to work, but I'd like feedback both on the method >> used and on the implementation. I have probably missed something as I >> had to work on the patch at different times with large intervals between >> each coding session, so please test it if you can before I push it to >> master. >> >> Simo. > > I'm sure Nathan will have some other input but here are my initial > thoughts: I still need to go through the code in detail, but I have a couple of comments below... > > You can probably pull out a bunch of code into functions that is > duplicated in add and mod: > - the is_krb and is_smb code checks > - determining if the password is hashed or not > > I wonder if {CLEAR} is #defined somewhere... Nowhere public. A few places in the DS code #define "CLEAR" without braces, but these aren't exposed, so it won't help much. > > Is "unhashed#user#password" some sort of magic string? Yeah, this is a magic attribute used by DS. > > It generally looks ok but DS plugins aren't my forte. > > rob > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3254 bytes Desc: S/MIME Cryptographic Signature URL: From mike at flyn.org Thu Jul 24 07:22:17 2008 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 24 Jul 2008 03:22:17 -0400 Subject: [Freeipa-devel] [PATCH] Fix ipa_kpasswd + mozldap Message-ID: <78E1E700-BE7A-4789-B7C6-B7D2DFD79D1A@flyn.org> Attached is a patch against FreeIPA 1.1.0 to fix ipa_kpasswd + mozldap. This is the bug mentioned at [1]. The patch is trivial, changing the pattern used by a ber_printf from "{tstON}" to "{tstO}." I'm not sure what the 'N' is for, I don't see it in the ber_printf manpage. Mike [1] http://www.redhat.com/archives/freeipa-devel/2008-June/msg00097.html -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-1.1.0-mozldap-fix.patch Type: application/octet-stream Size: 515 bytes Desc: not available URL: From ssorce at redhat.com Thu Jul 24 13:10:18 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 24 Jul 2008 09:10:18 -0400 Subject: [Freeipa-devel] [PATCH] Fix ipa_kpasswd + mozldap In-Reply-To: <78E1E700-BE7A-4789-B7C6-B7D2DFD79D1A@flyn.org> References: <78E1E700-BE7A-4789-B7C6-B7D2DFD79D1A@flyn.org> Message-ID: <1216905018.8999.38.camel@hopeson> On Thu, 2008-07-24 at 03:22 -0400, W. Michael Petullo wrote: > Attached is a patch against FreeIPA 1.1.0 to fix ipa_kpasswd + > mozldap. This is the bug mentioned at [1]. The patch is trivial, > changing the pattern used by a ber_printf from "{tstON}" to "{tstO}." > > I'm not sure what the 'N' is for, I don't see it in the ber_printf > manpage. > > Mike > > [1] http://www.redhat.com/archives/freeipa-devel/2008-June/msg00097.html Nice catch, I'll test asap. Simo. From ssorce at redhat.com Thu Jul 24 15:13:20 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 24 Jul 2008 11:13:20 -0400 Subject: [Freeipa-devel] [PATCH] Support password change operation by direct manipulation of userPassword In-Reply-To: <1216822832.937.16.camel@hopeson> References: <1216822832.937.16.camel@hopeson> Message-ID: <1216912400.8999.45.camel@hopeson> On Wed, 2008-07-23 at 10:20 -0400, Simo Sorce wrote: > This is an initial patch to support generating kerberos key material > (and other hashes) when an ldap ADD or MODIFY operation is performed on > the userPassword attribute. > > Basic testing seem to work, but I'd like feedback both on the method > used and on the implementation. I have probably missed something as I > had to work on the patch at different times with large intervals between > each coding session, so please test it if you can before I push it to > master. New patch, this incorporate suggestions to create helper functions for common code and also fixes quite a number of bugs, thanks to Rich for a quite accurate analysis too. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Implement-password-operation-checks-and-key-material.patch Type: application/mbox Size: 39158 bytes Desc: not available URL: From ssorce at redhat.com Thu Jul 24 15:15:07 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 24 Jul 2008 11:15:07 -0400 Subject: [Freeipa-devel] [PATCH] Fix stupid error in variable assignment. Message-ID: <1216912507.8999.48.camel@hopeson> In a patch to fix one of the plugin segfault I introduced a shameful stupidity. This patch hopefully fixes it. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-a-stupidty-introduced-recently-in-a-fix-to-a-seg.patch Type: application/mbox Size: 1395 bytes Desc: not available URL: From sgallagh at redhat.com Thu Jul 24 15:21:26 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 24 Jul 2008 11:21:26 -0400 Subject: [Freeipa-devel] [PATCH] Fix stupid error in variable assignment. In-Reply-To: <1216912507.8999.48.camel@hopeson> References: <1216912507.8999.48.camel@hopeson> Message-ID: <48889DF6.6010901@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simo Sorce wrote: > In a patch to fix one of the plugin segfault I introduced a shameful > stupidity. > This patch hopefully fixes it. > > Simo. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Throw yourself upon your sword! Uh, I mean: ack. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiInfYACgkQc7MaxVic+2qfpACfe8Jk4xWO9iv/w9S0YynpI2Qz I4oAnRlxHclbu8tasmMqtKhpyFdfjh/o =V09q -----END PGP SIGNATURE----- From ssorce at redhat.com Thu Jul 24 15:36:52 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 24 Jul 2008 11:36:52 -0400 Subject: [Freeipa-devel] [PATCH] Fix stupid error in variable assignment. In-Reply-To: <48889DF6.6010901@redhat.com> References: <1216912507.8999.48.camel@hopeson> <48889DF6.6010901@redhat.com> Message-ID: <1216913812.8999.50.camel@hopeson> On Thu, 2008-07-24 at 11:21 -0400, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Simo Sorce wrote: > > In a patch to fix one of the plugin segfault I introduced a shameful > > stupidity. > > This patch hopefully fixes it. > > > > Simo. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Throw yourself upon your sword! > > Uh, I mean: ack. Pushed to master (ipa-1-0 was ok). Simo. From rcritten at redhat.com Thu Jul 24 18:44:41 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 24 Jul 2008 14:44:41 -0400 Subject: [Freeipa-devel] [PATCH] move self-signed CA serialno file Message-ID: <4888CD99.9020209@redhat.com> Move the self-signed CA serialno file to /var/lib/ipa to adhere to the FHS. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-62-serialno.patch Type: text/x-patch Size: 4348 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Thu Jul 24 19:03:26 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 24 Jul 2008 15:03:26 -0400 Subject: [Freeipa-devel] [PATCH] move self-signed CA serialno file In-Reply-To: <4888CD99.9020209@redhat.com> References: <4888CD99.9020209@redhat.com> Message-ID: <4888D1FE.2030602@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Crittenden wrote: > Move the self-signed CA serialno file to /var/lib/ipa to adhere to the FHS. > > rob > > > ack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiI0f4ACgkQc7MaxVic+2po6wCeLSOyZaDAWiaFM9AB4c+v3ygX JKwAn0E4VszJJLPmCkTMCozX9nlIWwaT =sxsm -----END PGP SIGNATURE----- From ssorce at redhat.com Fri Jul 25 08:44:46 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 25 Jul 2008 04:44:46 -0400 Subject: [Freeipa-devel] [PATCH] move self-signed CA serialno file In-Reply-To: <4888CD99.9020209@redhat.com> References: <4888CD99.9020209@redhat.com> Message-ID: <1216975486.24757.3.camel@hopeson> On Thu, 2008-07-24 at 14:44 -0400, Rob Crittenden wrote: > Move the self-signed CA serialno file to /var/lib/ipa to adhere to the > FHS. Ack. From rcritten at redhat.com Fri Jul 25 13:13:42 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Jul 2008 09:13:42 -0400 Subject: [Freeipa-devel] [PATCH] move self-signed CA serialno file In-Reply-To: <4888D1FE.2030602@redhat.com> References: <4888CD99.9020209@redhat.com> <4888D1FE.2030602@redhat.com> Message-ID: <4889D186.7000907@redhat.com> Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rob Crittenden wrote: >> Move the self-signed CA serialno file to /var/lib/ipa to adhere to the FHS. >> >> rob >> >> >> > > ack pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From gunnar.hellekson at redhat.com Fri Jul 25 13:57:38 2008 From: gunnar.hellekson at redhat.com (Gunnar Hellekson) Date: Fri, 25 Jul 2008 09:57:38 -0400 Subject: [Freeipa-interest] Re: [Freeipa-devel] Feedback requested on Audit piece of IPA In-Reply-To: <487F3FEF.2050408@redhat.com> References: <487E4FE1.9030806@redhat.com> <487E9E2B.4080105@redhat.com> <02FA00E3-9152-40E9-B72F-C676A0431632@redhat.com> <487F3FEF.2050408@redhat.com> Message-ID: Sorry I'm coming back to this so late... On 17-Jul-2008, at 8:49 AM, Dmitri Pal wrote: > Gunnar Hellekson wrote: >> On 16-Jul-2008, at 8:19 PM, David O'Brien wrote: >>> Karl Wirth wrote: >>>> Currently we identified that audit system in general can be >>>> targeted to: >>>> *Collect data from different sources >>>> *Consolidate data into a combined storage >>>> *Provide effective tools to analyze collected data >>>> *Archive collected data including signing and compression >>>> *Restore data from archives for audit purposes or analyses >>>> >>>> We need your feedback on a couple of questions: >>>> 1) Should we store structured log data for analysis, original log >>>> data, >>>> or both >>>> - To do analysis of the log data, it would be better to structure >>>> it and >>>> store it. >>>> - But structured data is not the same as the original log file >>>> that it >>>> was taken from. Do we need the original log file format for >>>> reasons of >>>> compliance or can we throw it away? >>>> - Storing both parsed and unparsed data will have significant >>>> storage >>>> impact. >>>> >>> I'm just a beginner but my first reaction here is How is this >>> going to affect a forensics situation? Shouldn't we always have >>> access to untouched/raw data? We can parse it and create whatever >>> structure is required on demand, but if we do it immediately and >>> trash the original data, there's no going back. >> >> That's right. The user should always have the option of keeping the >> raw data. Often, there are requirements to maintain that data on >> write-once media, etc. so I don't think they'd take kindly to >> summarily trashing it. It would be great it we could accommodate >> the more hard-core folks, or folks who'd like the raw data for >> third-party log-eating tools. I feel pretty strongly that we should >> at least have the option of maintaining the original log file >> format. We can then allow the raw logs to be managed via logrotate >> rules for retiring, compression, signing, etc. This may mean that >> they do not get touched at all, which is what some customers want. >> > But this means that we will have to store twice as much data. It > will be terabytes! Is this what customers want? I would require a > high end hardware to process these logs if we want to provide any > kind of analysis and correlation. This will be a trade off. We can > collect raw data - not a big deal I just wanted to be sure that this > is really the case. You're right. In fact, these customers already have big resource problems, but it's not something we want to fix. They're accustomed to this problem :) >>>> 2) Should we parse the data into a structure format locally or >>>> back on >>>> IPA server? >>>> - Parsing locally and passing both parsed and original log data >>>> will >>>> increase network traffic but reduce load on server >> >> The a priori "forensic expert" in me is suspicious of munging data >> on the client. It seems as though we're solving a problem >> destructively, since we lose the ability to verify the original >> data. What happens if there's a bug in the parser? If we're >> supporting this, it should be optional. > Ok we will provide an optional capability to preserve raw data. > What about filtering? The problem with the filtering is that you > need to parse and sort out raw data. As a result you have raw data > and parsed out data. Then you apply filter to parsed data and decide > based upon the central policy if this event is of interest to you. > If it is not of interest you throw it away. Is it a valid use case > or in reality we need to collect everything and not filter anything? > If we collect everything there is no need to parse on the client and > thus there is only raw data to transfer to central location. We can > do parsing there . This approach saves processing time on client and > reduces network traffic but adds more burden to the server. We can > create different architectures and provide same set of features, the > question is more about which use case is primary. We should optimize > the system for the primary use case. > I see two main use cases: > a) Customer wants to preserve and collect original data untouched > without filtering and store it. Requirements to have capabilities to > search and analyze are secondary. > b) Customer wants to collect data for effective processing and > analysis. Filtering is crucial. Raw data is optional and not that > important. > We are not talking about real time log monitoring and intrusion > detection. There is a separate product to do this (Prelude + IDS) > and we do not want to duplicate it. > If we have to solve both use cases above we will seem to have worst > of both worlds: a lot of processing, a lot of data to transfer and > store. If we can select which use case is dominating we would be > able to tune up the design to solve it best. Is this possible or > these two use case are equal? I'm not sure how much tuning we really need here -- I think we can solve all cases by having a filter on the client and filter on the server, and having both those filters optional and centrally managed. Even better, include a store-and-forward mechanism on the client, so we can elegantly handle the disconnected case, and I think everyone's happy. >>>> 3) What is the scope of what should be included in the audit data >>>> in >>>> addition to what we will get from syslog, rsyslog, auditd, etc. >>>> Those >>>> will give us data like user access to a system, keystrokes, etc. >>>> What >>>> beyond that is needed. For example, is the following needed: >>>> Files user >>>> accessed on a system >> >> Between a keystroke logger, syslog and auditd, that takes care of >> just about everything, including a log of the files a user accessed >> on a system. > > The problem is more about other platforms. On Linux we have auditd, > inotify and a lot of other nice things that would help. But how to > monitor file changes on Solaris, HP, AIX? We want to collect logs > from all kinds of machines. Do we need to worry about this and build > audit information collecting tools for those systems? Which tools a > priority? How far we need to go? I'm not sure we have to introduce any additional features on clients we don't own. We should be able to consume what they have to offer, but we don't need to go implementing new features to homogenize. Is that what you mean? g -- Gunnar Hellekson, RHCE Lead Architect, Red Hat Government From rcritten at redhat.com Fri Jul 25 14:13:11 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Jul 2008 10:13:11 -0400 Subject: [Freeipa-devel] [PATCH] change Title label Message-ID: <4889DF77.40301@redhat.com> Change the label "Title" to "Job Title" for clarity. This was never meant to be a "Mr., Mrs." type title. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-63-label.patch Type: text/x-patch Size: 5894 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jul 25 15:16:07 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Jul 2008 11:16:07 -0400 Subject: [Freeipa-devel] [PATCH] fix build on CentOS Message-ID: <4889EE37.7010700@redhat.com> Specify the mandir to configure so the man pages go where we expect them to go in our local spec files. This fixes the build on CentOS 5.2. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-64-centos.patch Type: text/x-patch Size: 971 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Fri Jul 25 16:13:11 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 25 Jul 2008 12:13:11 -0400 Subject: [Freeipa-devel] [PATCH] fix build on CentOS In-Reply-To: <4889EE37.7010700@redhat.com> References: <4889EE37.7010700@redhat.com> Message-ID: <1217002391.24757.78.camel@hopeson> On Fri, 2008-07-25 at 11:16 -0400, Rob Crittenden wrote: > Specify the mandir to configure so the man pages go where we expect > them > to go in our local spec files. This fixes the build on CentOS 5.2. ack From rcritten at redhat.com Fri Jul 25 19:19:51 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Jul 2008 15:19:51 -0400 Subject: [Freeipa-devel] [RFC] show first/last name in ipa-finduser output Message-ID: <488A2757.2000709@redhat.com> We currently display common name in ipa-finduser which can cause confusion since we explicitly provide options for managing first and last name. Updating those doesn't automatically update the cn field so it looks as if a change hasn't been applied. So here is my first crack at fixing it. All I've done is grab sn and givenname instead of cn and ensure that in the display sn comes after gn. It looks like: % ipa-finduser tuser1 First Name: Testy Last Name: User Home Directory: /home/tuser1 Login Shell: /bin/sh Login: tuser1 % ipa-finduser -a tuser1 |grep Full Full Name: Test User So you can see that the Full Name (cn) isn't the same as givenname + sn. I wanted to avoid creating some sort of special "full name" attribute because one can run this with -n to get the real LDAP attribute names and I didn't want anyone trying to query for LDAP attributes that don't exist. So here is a patch for the current approach. Need some feedback. diff --git a/ipa-admintools/ipa-finduser b/ipa-admintools/ipa-finduser index 40384a3..de0e6fc 100644 --- a/ipa-admintools/ipa-finduser +++ b/ipa-admintools/ipa-finduser @@ -93,7 +93,7 @@ def main(): client = ipaclient.IPAClient(verbose=options.verbose) if options.all is None: - users = client.find_users(args[1], sattrs=['uid','cn','homeDirectory',' loginshell']) + users = client.find_users(args[1], sattrs=['uid','givenname','sn','home Directory','loginshell']) else: users = client.find_users(args[1], sattrs=None) @@ -121,6 +121,18 @@ def main(): for ent in users: attr = ent.attrList() attr.sort() + + # Always have sn following givenname + try: + l = attr.index('givenname') + try: + attr.remove('sn') + except: + pass + attr.insert(l+1, 'sn') + except: + pass + if options.notranslate: labels = {} for a in attr: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jul 25 21:07:33 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Jul 2008 17:07:33 -0400 Subject: [Freeipa-devel] [PATCH] Don't assume that the Firefox autoconfig files exist. Message-ID: <488A4095.7090102@redhat.com> These are created by an object-signing cert and needs to be done after the fact if a server is created with user-supplied PKCS#12 files. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-65-replica.patch Type: text/x-patch Size: 3273 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jul 25 21:16:23 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 25 Jul 2008 17:16:23 -0400 Subject: [Freeipa-devel] [PATCH] skip header in certutil output Message-ID: <488A42A7.2020100@redhat.com> We have a function to get a list of all certs in a database. NSS 3.12 added a header to the certutil output we need to skip. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-66-certs.patch Type: text/x-patch Size: 918 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Sat Jul 26 14:09:06 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 26 Jul 2008 10:09:06 -0400 Subject: [Freeipa-devel] [PATCH] Don't assume that the Firefox autoconfig files exist. In-Reply-To: <488A4095.7090102@redhat.com> References: <488A4095.7090102@redhat.com> Message-ID: <1217081346.32580.3.camel@hopeson> On Fri, 2008-07-25 at 17:07 -0400, Rob Crittenden wrote: > These are created by an object-signing cert and needs to be done > after > the fact if a server is created with user-supplied PKCS#12 files. ack From ssorce at redhat.com Sat Jul 26 14:09:31 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 26 Jul 2008 10:09:31 -0400 Subject: [Freeipa-devel] [PATCH] skip header in certutil output In-Reply-To: <488A42A7.2020100@redhat.com> References: <488A42A7.2020100@redhat.com> Message-ID: <1217081371.32580.5.camel@hopeson> On Fri, 2008-07-25 at 17:16 -0400, Rob Crittenden wrote: > > We have a function to get a list of all certs in a database. NSS 3.12 > added a header to the certutil output we need to skip. ack From mike at flyn.org Sun Jul 27 00:42:36 2008 From: mike at flyn.org (W. Michael Petullo) Date: Sat, 26 Jul 2008 20:42:36 -0400 Subject: [Freeipa-devel] Safari and web interface Message-ID: <561D1E23-29C7-4C3A-98D5-284164D48C22@flyn.org> I have an iMac running Mac OS X 10.4 that authenticates against a FreeIPA 1.1.0 server. Although the computer otherwise works as a FreeIPA client, I am unable to connect to the FreeIPA web interface using Safari. Firefox connects fine from the same machine. Safari says: "Permission Denied" "You do not have permission to access this page." "Kerberos login failed" The Kerberos server logs this when I use Safari: Jul 26 20:38:28 golem.flyn.org krb5kdc[28682](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.0.102: ISSUE: authtime 1217119078, etypes {rep=18 tkt=18 ses=18}, admin at FLYN.ORG for HTTP/ golem.flyn.org at FLYN.ORG The Kerberos server logs this when I use Firefox: Jul 26 20:39:28 golem.flyn.org krb5kdc[28682](info): TGS_REQ (1 etypes {18}) 192.168.0.102: ISSUE: authtime 1217119078, etypes {rep=18 tkt=18 ses=18}, admin at FLYN.ORG for krbtgt/FLYN.ORG at FLYN.ORG Jul 26 20:39:29 golem.flyn.org krb5kdc[28682](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.0.10: ISSUE: authtime 1217119078, etypes {rep=18 tkt=18 ses=18}, admin at FLYN.ORG for ldap/ golem.flyn.org at FLYN.ORG [...] Is anyone using Safari to configure FreeIPA? Mike From ssorce at redhat.com Sun Jul 27 09:30:21 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 27 Jul 2008 05:30:21 -0400 Subject: [Freeipa-devel] Safari and web interface In-Reply-To: <561D1E23-29C7-4C3A-98D5-284164D48C22@flyn.org> References: <561D1E23-29C7-4C3A-98D5-284164D48C22@flyn.org> Message-ID: <1217151021.32580.9.camel@hopeson> On Sat, 2008-07-26 at 20:42 -0400, W. Michael Petullo wrote: > I have an iMac running Mac OS X 10.4 that authenticates against a > FreeIPA 1.1.0 server. Although the computer otherwise works as a > FreeIPA client, I am unable to connect to the FreeIPA web interface > using Safari. Firefox connects fine from the same machine. Safari says: > > "Permission Denied" > "You do not have permission to access this page." > "Kerberos login failed" > > The Kerberos server logs this when I use Safari: > > Jul 26 20:38:28 golem.flyn.org krb5kdc[28682](info): TGS_REQ (7 > etypes {18 17 16 23 1 3 2}) 192.168.0.102: ISSUE: authtime > 1217119078, etypes {rep=18 tkt=18 ses=18}, admin at FLYN.ORG for HTTP/ > golem.flyn.org at FLYN.ORG > > The Kerberos server logs this when I use Firefox: > > Jul 26 20:39:28 golem.flyn.org krb5kdc[28682](info): TGS_REQ (1 > etypes {18}) 192.168.0.102: ISSUE: authtime 1217119078, etypes > {rep=18 tkt=18 ses=18}, admin at FLYN.ORG for krbtgt/FLYN.ORG at FLYN.ORG > Jul 26 20:39:29 golem.flyn.org krb5kdc[28682](info): TGS_REQ (7 > etypes {18 17 16 23 1 3 2}) 192.168.0.10: ISSUE: authtime 1217119078, > etypes {rep=18 tkt=18 ses=18}, admin at FLYN.ORG for ldap/ > golem.flyn.org at FLYN.ORG > [...] > > Is anyone using Safari to configure FreeIPA? I never tried but from the logs it seem that Safari might not be forwarding the user TGT. Simo.h From rcritten at redhat.com Mon Jul 28 13:31:20 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 28 Jul 2008 09:31:20 -0400 Subject: [Freeipa-devel] Safari and web interface In-Reply-To: <1217151021.32580.9.camel@hopeson> References: <561D1E23-29C7-4C3A-98D5-284164D48C22@flyn.org> <1217151021.32580.9.camel@hopeson> Message-ID: <488DCA28.80901@redhat.com> Simo Sorce wrote: > On Sat, 2008-07-26 at 20:42 -0400, W. Michael Petullo wrote: >> I have an iMac running Mac OS X 10.4 that authenticates against a >> FreeIPA 1.1.0 server. Although the computer otherwise works as a >> FreeIPA client, I am unable to connect to the FreeIPA web interface >> using Safari. Firefox connects fine from the same machine. Safari says: >> >> "Permission Denied" >> "You do not have permission to access this page." >> "Kerberos login failed" >> >> The Kerberos server logs this when I use Safari: >> >> Jul 26 20:38:28 golem.flyn.org krb5kdc[28682](info): TGS_REQ (7 >> etypes {18 17 16 23 1 3 2}) 192.168.0.102: ISSUE: authtime >> 1217119078, etypes {rep=18 tkt=18 ses=18}, admin at FLYN.ORG for HTTP/ >> golem.flyn.org at FLYN.ORG >> >> The Kerberos server logs this when I use Firefox: >> >> Jul 26 20:39:28 golem.flyn.org krb5kdc[28682](info): TGS_REQ (1 >> etypes {18}) 192.168.0.102: ISSUE: authtime 1217119078, etypes >> {rep=18 tkt=18 ses=18}, admin at FLYN.ORG for krbtgt/FLYN.ORG at FLYN.ORG >> Jul 26 20:39:29 golem.flyn.org krb5kdc[28682](info): TGS_REQ (7 >> etypes {18 17 16 23 1 3 2}) 192.168.0.10: ISSUE: authtime 1217119078, >> etypes {rep=18 tkt=18 ses=18}, admin at FLYN.ORG for ldap/ >> golem.flyn.org at FLYN.ORG >> [...] >> >> Is anyone using Safari to configure FreeIPA? > > I never tried but from the logs it seem that Safari might not be > forwarding the user TGT. > IIRC Safari was originally based on Konqueror/KHTML. Currently Konqueror doesn't support delegation (though it does support GSSAPI). Not sure if this bug is apropos to Safari http://bugs.kde.org/show_bug.cgi?id=138414 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From mike at flyn.org Tue Jul 29 00:25:18 2008 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 28 Jul 2008 20:25:18 -0400 Subject: [Freeipa-devel] Safari and web interface In-Reply-To: <488DCA28.80901@redhat.com> References: <561D1E23-29C7-4C3A-98D5-284164D48C22@flyn.org> <1217151021.32580.9.camel@hopeson> <488DCA28.80901@redhat.com> Message-ID: >>> I have an iMac running Mac OS X 10.4 that authenticates against >>> a FreeIPA 1.1.0 server. Although the computer otherwise works as >>> a FreeIPA client, I am unable to connect to the FreeIPA web >>> interface using Safari. Firefox connects fine from the same >>> machine. Safari says: >>> >>> "Permission Denied" >>> "You do not have permission to access this page." >>> "Kerberos login failed" >>> >>> The Kerberos server logs this when I use Safari: >>> >>> Jul 26 20:38:28 golem.flyn.org krb5kdc[28682](info): TGS_REQ (7 >>> etypes {18 17 16 23 1 3 2}) 192.168.0.102: ISSUE: authtime >>> 1217119078, etypes {rep=18 tkt=18 ses=18}, admin at FLYN.ORG for >>> HTTP/ golem.flyn.org at FLYN.ORG >>> >>> The Kerberos server logs this when I use Firefox: >>> >>> Jul 26 20:39:28 golem.flyn.org krb5kdc[28682](info): TGS_REQ (1 >>> etypes {18}) 192.168.0.102: ISSUE: authtime 1217119078, etypes >>> {rep=18 tkt=18 ses=18}, admin at FLYN.ORG for krbtgt/FLYN.ORG at FLYN.ORG >>> Jul 26 20:39:29 golem.flyn.org krb5kdc[28682](info): TGS_REQ (7 >>> etypes {18 17 16 23 1 3 2}) 192.168.0.10: ISSUE: authtime >>> 1217119078, etypes {rep=18 tkt=18 ses=18}, admin at FLYN.ORG for >>> ldap/ golem.flyn.org at FLYN.ORG >>> [...] >>> >>> Is anyone using Safari to configure FreeIPA? >> I never tried but from the logs it seem that Safari might not be >> forwarding the user TGT. > > IIRC Safari was originally based on Konqueror/KHTML. > > Currently Konqueror doesn't support delegation (though it does > support GSSAPI). Not sure if this bug is apropos to Safari http:// > bugs.kde.org/show_bug.cgi?id=138414 Okay, I think you have it, Simo and Rob. Yes, Safari was based on Konqueror's engine, now called WebKit. I had to crack open my copy of Applied Cryptography, but now I see why and how Apache "proxies" the user TGT. This may become more of an issue in the future as other browsers (GNOME's epiphany in particular) are looking at moving from Mozilla's XULrunner to WebKit. I have submitted a bug against Apple's Open Source WebKit project (https://bugs.webkit.org/show_bug.cgi?id=20203) and Apple's Safari browser (bug report not available publicly). Mike From rcritten at redhat.com Tue Jul 29 13:05:55 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Jul 2008 09:05:55 -0400 Subject: [Freeipa-devel] [PATCH] Shift the search base Message-ID: <488F15B3.7000005@redhat.com> Currently we search $SUFFIX for users and groups but we plan in future to handle alternative representations of users and groups so need to restrict searching to cn=accounts to avoid picking up duplicate ghost entries. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-67-searchbase.patch Type: text/x-patch Size: 7843 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Jul 29 13:09:32 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Jul 2008 09:09:32 -0400 Subject: [Freeipa-devel] pending reviews Message-ID: <488F168C.4040406@redhat.com> I have some patches that still need a review after a couple of weeks. The subjects are: [PATCH] tool to manage search and user policy (Simo mentioned in IRC that ipa-policyconfig is a poor name for the tool. We thought ipa-defaultoptions is a reasonable alternative) [PATCH] fix encoding of loaded templates [PATCH] change Title label thanks rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From sgallagh at redhat.com Tue Jul 29 13:12:32 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 29 Jul 2008 09:12:32 -0400 Subject: [Freeipa-devel] [PATCH] Shift the search base In-Reply-To: <488F15B3.7000005@redhat.com> References: <488F15B3.7000005@redhat.com> Message-ID: <488F1740.6020602@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Crittenden wrote: > Currently we search $SUFFIX for users and groups but we plan in future > to handle alternative representations of users and groups so need to > restrict searching to cn=accounts to avoid picking up duplicate ghost > entries. > > rob > ack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiPF0AACgkQc7MaxVic+2pqlACgvoXWYvEHO3HCCXxT1xui3vlP uGAAoI+63efzISRuu9tI+oWHBRACDqQ7 =Z1nS -----END PGP SIGNATURE----- From sgallagh at redhat.com Tue Jul 29 13:19:51 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 29 Jul 2008 09:19:51 -0400 Subject: [Freeipa-devel] [PATCH] change Title label In-Reply-To: <4889DF77.40301@redhat.com> References: <4889DF77.40301@redhat.com> Message-ID: <488F18F7.5020606@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Crittenden wrote: > Change the label "Title" to "Job Title" for clarity. This was never > meant to be a "Mr., Mrs." type title. > > rob > > > ------------------------------------------------------------------------ > ack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiPGPYACgkQc7MaxVic+2o3GwCgmFfMiLitdn1BFLXsjQPQg/wc 7h4AoIFp1n0LTmLSlpEq1HjO5jxJvMMf =8Z4o -----END PGP SIGNATURE----- From sgallagh at redhat.com Tue Jul 29 13:26:52 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 29 Jul 2008 09:26:52 -0400 Subject: [Freeipa-devel] [PATCH] fix encoding of loaded templates In-Reply-To: <48863520.8070704@redhat.com> References: <48863520.8070704@redhat.com> Message-ID: <488F1A9C.7000804@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Crittenden wrote: > We used to manually load the template files for the edit pages using > turbogears.meta.load_kid_template(). Unfortunately this went through the > one code path where encoding was completely ignored. It ended up > defaulting to sys.getdefaultencoding() which is 'ascii'. So even though > most of the templates are loaded as 'utf-8' the few that really mattered > weren't. > > The fix is to call kid.load_template() ourselves and set the encoding of > the class we just loaded to either the setting in the app.cfg file or to > the normal default value of 'utf-8'. > > This does not remove all i18n issues. We still cannot handle non-ascii > characters that will appear in the DN (group name and uid are two I know > of). > > rob ack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiPGpwACgkQc7MaxVic+2q/GwCgpXtUHoOwtqlgahhrRfno8GAm mh0Anix0kkbaYZQ/bsPsryDirHo+xJF0 =mRax -----END PGP SIGNATURE----- From rcritten at redhat.com Tue Jul 29 15:32:28 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Jul 2008 11:32:28 -0400 Subject: [Freeipa-devel] [PATCH] change Title label In-Reply-To: <488F18F7.5020606@redhat.com> References: <4889DF77.40301@redhat.com> <488F18F7.5020606@redhat.com> Message-ID: <488F380C.60001@redhat.com> Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rob Crittenden wrote: >> Change the label "Title" to "Job Title" for clarity. This was never >> meant to be a "Mr., Mrs." type title. >> >> rob >> >> >> ------------------------------------------------------------------------ >> > > ack pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Jul 29 15:33:52 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Jul 2008 11:33:52 -0400 Subject: [Freeipa-devel] [PATCH] fix encoding of loaded templates In-Reply-To: <488F1A9C.7000804@redhat.com> References: <48863520.8070704@redhat.com> <488F1A9C.7000804@redhat.com> Message-ID: <488F3860.8040809@redhat.com> Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rob Crittenden wrote: >> We used to manually load the template files for the edit pages using >> turbogears.meta.load_kid_template(). Unfortunately this went through the >> one code path where encoding was completely ignored. It ended up >> defaulting to sys.getdefaultencoding() which is 'ascii'. So even though >> most of the templates are loaded as 'utf-8' the few that really mattered >> weren't. >> >> The fix is to call kid.load_template() ourselves and set the encoding of >> the class we just loaded to either the setting in the app.cfg file or to >> the normal default value of 'utf-8'. >> >> This does not remove all i18n issues. We still cannot handle non-ascii >> characters that will appear in the DN (group name and uid are two I know >> of). >> >> rob > > ack pushed to master -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Jul 29 15:35:33 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 29 Jul 2008 11:35:33 -0400 Subject: [Freeipa-devel] [PATCH] Shift the search base In-Reply-To: <488F1740.6020602@redhat.com> References: <488F15B3.7000005@redhat.com> <488F1740.6020602@redhat.com> Message-ID: <488F38C5.3050207@redhat.com> Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rob Crittenden wrote: >> Currently we search $SUFFIX for users and groups but we plan in future >> to handle alternative representations of users and groups so need to >> restrict searching to cn=accounts to avoid picking up duplicate ghost >> entries. >> >> rob >> > ack pushed -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jderose at redhat.com Tue Jul 29 19:16:45 2008 From: jderose at redhat.com (Jason Gerard DeRose) Date: Tue, 29 Jul 2008 13:16:45 -0600 Subject: [Freeipa-devel] [PATCH] Fixes 453779: Need space between the user's Display Name and Login Message-ID: <488F6C9D.2000703@redhat.com> A non-text attachment was scrubbed... Name: 0001-Use-format-string-to-fix-nbsp-problem-in-userlist.patch Type: text/x-diff Size: 1949 bytes Desc: not available URL: From sgallagh at redhat.com Wed Jul 30 13:19:20 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 30 Jul 2008 09:19:20 -0400 Subject: [Freeipa-devel] [PATCH] Fixes 453779: Need space between the user's Display Name and Login In-Reply-To: <488F6C9D.2000703@redhat.com> References: <488F6C9D.2000703@redhat.com> Message-ID: <48906A58.9010605@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >From 84e9616eab65c02c6e6ef0eb79ffd229e510a67f Mon Sep 17 00:00:00 2001 >From: Jason Gerard DeRose >Date: Tue, 29 Jul 2008 13:09:57 -0600 >Subject: [PATCH] Use % format string to fix nbsp problem in >userlist.kid (fixes #453779) ack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiQalgACgkQc7MaxVic+2qFrQCfW+V4XIxxQb5hhm2bJMVMz0XQ lmkAn11FY485LCmcYn85eVJqM3yexLAN =aJl6 -----END PGP SIGNATURE----- From sgallagh at redhat.com Wed Jul 30 14:32:07 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 30 Jul 2008 10:32:07 -0400 Subject: [Freeipa-devel] [PATCH] Fixes 453779: Need space between the user's Display Name and Login In-Reply-To: <488F6C9D.2000703@redhat.com> References: <488F6C9D.2000703@redhat.com> Message-ID: <48907B67.2080903@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jason Gerard DeRose wrote: > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Pushed to master -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiQe2cACgkQc7MaxVic+2p5JwCcDUFFXFqHZLX2i6qBhnybjP8S DfwAoJeJNHpev8YJUeCSZ9iQ89Ef5RMe =rADB -----END PGP SIGNATURE-----