From vcardprocessor at vcardprocessor.com Fri Aug 1 07:26:55 2008 From: vcardprocessor at vcardprocessor.com (Eric) Date: Fri, 1 Aug 2008 00:26:55 -0700 Subject: [Freeipa-devel] Failed to decrypt password In-Reply-To: <1215101609.353.163.camel@localhost.localdomain> Message-ID: <20088102655.794746@C840> I tried on both the server and a client. The server has only one NIC. I just updated to your testing release, still get error message: the kinit(v5): Cannot contact any KDC for requested realm while getting initial credentials Here are my detailed logs: -------------------------- Jul 30 11:10:54 directory yum: Updated: ipa-python-1.1.0-6.fc9.i386 Jul 30 11:10:54 directory yum: Updated: ipa-admintools-1.1.0-6.fc9.i386 Jul 30 11:10:55 directory yum: Updated: ipa-client-1.1.0-6.fc9.i386 Jul 30 11:11:22 directory kernel: SELinux: policy loaded with handle_unknown=allow Jul 30 11:11:22 directory kernel: printk: 69 messages suppressed. Jul 30 11:11:22 directory kernel: type=1403 audit(1217409082.231:881): policy loaded auid=0 ses=664 Jul 30 11:11:25 directory yum: Updated: ipa-server-selinux-1.1.0-6.fc9.i386 Jul 30 11:11:29 directory yum: Updated: ipa-server-1.1.0-6.fc9.i386 Jul 30 11:11:30 directory kpasswd[26824]: Setting up socket for [127.0.0.1] Jul 30 11:11:30 directory kpasswd[26824]: Setting up socket for [10.0.0.5] Jul 30 11:11:30 directory kpasswd[26824]: Setting up socket for [::1] Jul 30 11:11:30 directory kernel: type=1400 audit(1217409090.414:882): avc: denied { read } for pid=26824 comm="ipa_kpasswd" name="net" dev=proc ino=4026531868 scontext=unconfined_u:system_r:ipa_kpasswd_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=lnk_file Jul 30 11:11:30 directory kpasswd[26824]: Setting up socket for [fe80::216:3eff:fe3e:d8a4%eth0] Jul 30 11:15:17 directory kpasswd[26875]: Failed to decrypt password: Incorrect net address Jul 30 11:15:54 directory kpasswd[26880]: Failed to decrypt password: Incorrect net address -------------------------- Eric. ============================================================= Are you performing kinit on the IPA server ?or on a client ? Does your IPA server have multiple NICs ? Simo. On Wed, 2008-07-02 at 15:11 -0700, Eric wrote: >?This is what I have: > >?Name ? ? ? : ipa-server >?Arch ? ? ? : i386 >?Version ? ?: 1.1.0 >?Release ? ?: 4.fc9 > >?Eric. > >?============================================================= >?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 > > > -- Simo Sorce * Red Hat, Inc * New York From vcardprocessor at vcardprocessor.com Fri Aug 1 07:29:59 2008 From: vcardprocessor at vcardprocessor.com (Eric) Date: Fri, 1 Aug 2008 00:29:59 -0700 Subject: [Freeipa-devel] Failed to decrypt password In-Reply-To: <200873022645.950568@C840> Message-ID: <20088102959.727699@C840> I added this rule: -------------------- require { type proc_net_t; type ipa_kpasswd_t; class lnk_file read; } require { type proc_net_t; type ipa_kpasswd_t; class lnk_file read; } -------------------- But I'm still getting: kpasswd[28872]: Failed to decrypt password: Incorrect net address Eric. ============================================================= I tried on both the server and a client. The server has only one NIC. I just updated to your testing release, still get error message: the kinit(v5): Cannot contact any KDC for requested realm while getting initial credentials Here are my detailed logs: -------------------------- Jul 30 11:10:54 directory yum: Updated: ipa-python-1.1.0-6.fc9.i386 Jul 30 11:10:54 directory yum: Updated: ipa-admintools-1.1.0-6.fc9.i386 Jul 30 11:10:55 directory yum: Updated: ipa-client-1.1.0-6.fc9.i386 Jul 30 11:11:22 directory kernel: SELinux: policy loaded with handle_unknown=allow Jul 30 11:11:22 directory kernel: printk: 69 messages suppressed. Jul 30 11:11:22 directory kernel: type=1403 audit(1217409082.231:881): policy loaded auid=0 ses=664 Jul 30 11:11:25 directory yum: Updated: ipa-server-selinux-1.1.0-6.fc9.i386 Jul 30 11:11:29 directory yum: Updated: ipa-server-1.1.0-6.fc9.i386 Jul 30 11:11:30 directory kpasswd[26824]: Setting up socket for [127.0.0.1] Jul 30 11:11:30 directory kpasswd[26824]: Setting up socket for [10.0.0.5] Jul 30 11:11:30 directory kpasswd[26824]: Setting up socket for [::1] Jul 30 11:11:30 directory kernel: type=1400 audit(1217409090.414:882): avc: ?denied ?{ read } for ?pid=26824 comm="ipa_kpasswd" name="net" dev=proc ino=4026531868 scontext=unconfined_u:system_r:ipa_kpasswd_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=lnk_file Jul 30 11:11:30 directory kpasswd[26824]: Setting up socket for [fe80::216:3eff:fe3e:d8a4%eth0] Jul 30 11:15:17 directory kpasswd[26875]: Failed to decrypt password: Incorrect net address Jul 30 11:15:54 directory kpasswd[26880]: Failed to decrypt password: Incorrect net address -------------------------- Eric. ============================================================= Are you performing kinit on the IPA server ?or on a client ? Does your IPA server have multiple NICs ? Simo. On Wed, 2008-07-02 at 15:11 -0700, Eric wrote: >?This is what I have: > >?Name ??????: ipa-server >?Arch ??????: i386 >?Version ???: 1.1.0 >?Release ???: 4.fc9 > >?Eric. > >?============================================================= >?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 > > > -- Simo Sorce * Red Hat, Inc * New York From mnagy at redhat.com Mon Aug 4 15:01:42 2008 From: mnagy at redhat.com (Martin Nagy) Date: Mon, 04 Aug 2008 17:01:42 +0200 Subject: [Freeipa-devel] [PATCH] tool to manage search and user policy In-Reply-To: <487B9AB8.8070502@redhat.com> References: <487B9AB8.8070502@redhat.com> Message-ID: <489719D6.6070904@redhat.com> Rob Crittenden wrote: > 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 No comments to the name of the utility :) Just a very few minor details: .dotest/patch:176: trailing whitespace. if options.show: From ipa-admintools/ipa-policyconfig, function update_policy(): For some attributes, the minimum of 0 is not appropriate. For the string attributes, I'd say specifying min=0 isn't required. Otherwise, the patch seems fine to me. Martin From rcritten at redhat.com Tue Aug 5 12:13:27 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Aug 2008 08:13:27 -0400 Subject: [Freeipa-devel] [PATCH] Don't assume that the Firefox autoconfig files exist. In-Reply-To: <1217081346.32580.3.camel@hopeson> References: <488A4095.7090102@redhat.com> <1217081346.32580.3.camel@hopeson> Message-ID: <489843E7.1080001@redhat.com> Simo Sorce wrote: > 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 > 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 Aug 5 12:14:02 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Aug 2008 08:14:02 -0400 Subject: [Freeipa-devel] [PATCH] skip header in certutil output In-Reply-To: <1217081371.32580.5.camel@hopeson> References: <488A42A7.2020100@redhat.com> <1217081371.32580.5.camel@hopeson> Message-ID: <4898440A.2090708@redhat.com> Simo Sorce wrote: > 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 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 Aug 5 12:31:47 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Aug 2008 08:31:47 -0400 Subject: [Freeipa-devel] [PATCH] fix build on CentOS In-Reply-To: <1217002391.24757.78.camel@hopeson> References: <4889EE37.7010700@redhat.com> <1217002391.24757.78.camel@hopeson> Message-ID: <48984833.2050900@redhat.com> Simo Sorce wrote: > 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 > 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 mnagy at redhat.com Tue Aug 5 12:48:44 2008 From: mnagy at redhat.com (Martin Nagy) Date: Tue, 05 Aug 2008 14:48:44 +0200 Subject: [Freeipa-devel] [RFC] show first/last name in ipa-finduser output In-Reply-To: <488A2757.2000709@redhat.com> References: <488A2757.2000709@redhat.com> Message-ID: <48984C2C.9010500@redhat.com> Hi, Rob Crittenden wrote: > 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. Regarding your approach, I think it might be just a bit inconvenient for the user, but it would at least be correct and avoid some confusion. Since I don't have any better idea, I say we do it. > So here is a patch for the current approach. Need some feedback. Regarding the patch: > + # Always have sn following givenname > + try: > + l = attr.index('givenname') -> + try: > + attr.remove('sn') -> + except: -> + pass > + attr.insert(l+1, 'sn') > + except: > + pass > + I'd remove the lines that I marked here with '-'. I think we don't want to insert 'sn' to the attr list if it wasn't there. I just hope [].remove() doesn't throw any other exceptions :) Hope this helps. Martin From rcritten at redhat.com Tue Aug 5 14:09:31 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 05 Aug 2008 10:09:31 -0400 Subject: [Freeipa-devel] [RFC] show first/last name in ipa-finduser output In-Reply-To: <48984C2C.9010500@redhat.com> References: <488A2757.2000709@redhat.com> <48984C2C.9010500@redhat.com> Message-ID: <48985F1B.8070407@redhat.com> Martin Nagy wrote: > Hi, > > Rob Crittenden wrote: >> 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. > > Regarding your approach, I think it might be just a bit inconvenient for > the user, but it would at least be correct and avoid some confusion. > Since I don't have any better idea, I say we do it. > >> So here is a patch for the current approach. Need some feedback. > > Regarding the patch: > > + # Always have sn following givenname > > + try: > > + l = attr.index('givenname') > -> + try: > > + attr.remove('sn') > -> + except: > -> + pass > > + attr.insert(l+1, 'sn') > > + except: > > + pass > > + > > I'd remove the lines that I marked here with '-'. I think we don't want > to insert 'sn' to the attr list if it wasn't there. I just hope > [].remove() doesn't throw any other exceptions :) Ok, I added a specific exception to catch and moved the insert into the inner try/except. The logic here goes like: If there is a givenname then move the surname (sn) attribute to follow it. When values are displayed the list of attributes is iterated over. Normally this is sorted alphabetically (so it is predictable). So this is an effort to keep the name together. It is possible, in the case of the admin user, to not have a givenname attribute. New patch attached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: name.diff Type: text/x-patch Size: 1844 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 Aug 6 13:29:58 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Aug 2008 09:29:58 -0400 Subject: [Freeipa-devel] [PATCH] use same regex for user/group names as shadow-utils Message-ID: <4899A756.2000802@redhat.com> The user/group name validator didn't match the standard *nix validator and disallowed some valid names and allowed some invalid ones (including those with spaces). This brings it inline with shadow-utils from Fedora 9. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-68-goodname.patch Type: text/x-patch Size: 9228 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 Wed Aug 6 13:39:34 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 06 Aug 2008 09:39:34 -0400 Subject: [Freeipa-devel] [PATCH] use same regex for user/group names as shadow-utils In-Reply-To: <4899A756.2000802@redhat.com> References: <4899A756.2000802@redhat.com> Message-ID: <4899A996.6060800@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Crittenden wrote: > The user/group name validator didn't match the standard *nix validator > and disallowed some valid names and allowed some invalid ones (including > those with spaces). > > This brings it inline with shadow-utils from Fedora 9. > > rob > I have a problem with a validate function returning True on failure. I think it's a reasonable expectation that it should return True only if the regex is matched properly. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiZqZYACgkQc7MaxVic+2pgHgCeJVI1wmTw2UcHL9SgraycFFma /hYAoJ+/+u+BXJRijyhNcl3SUdUnaP9O =5stw -----END PGP SIGNATURE----- From rcritten at redhat.com Wed Aug 6 13:44:21 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Aug 2008 09:44:21 -0400 Subject: [Freeipa-devel] [PATCH] use same regex for user/group names as shadow-utils In-Reply-To: <4899A996.6060800@redhat.com> References: <4899A756.2000802@redhat.com> <4899A996.6060800@redhat.com> Message-ID: <4899AAB5.6020409@redhat.com> Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rob Crittenden wrote: >> The user/group name validator didn't match the standard *nix validator >> and disallowed some valid names and allowed some invalid ones (including >> those with spaces). >> >> This brings it inline with shadow-utils from Fedora 9. >> >> rob >> > > I have a problem with a validate function returning True on failure. I > think it's a reasonable expectation that it should return True only if > the regex is matched properly. Technically it returns 1 and 0 where 1 is often a failure in C programs. Welcome to the world of C-turned-Python programmer. In truth all the validators should return True/False but that is an optimization for another day. 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 email.ahmedkamal at googlemail.com Wed Aug 6 13:53:28 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Wed, 6 Aug 2008 16:53:28 +0300 Subject: [Freeipa-devel] freeIPA and NIS Message-ID: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> Hi, Thanks for freeIPA, keep up the awesome work. I have a couple of questions please -Does freeIPA offer a migration path off of NIS ? (to maintain same UID/GIDs) ? -Can the freeIPA server present itself as a NIS server as well (same UID/GID), this is for clients that can't join freeIPA domain (like NAS boxes?) -I am considering running open-solaris (for ZFS as a storage box), did any of you guys try joining that to freeIPA ? Any idea of their in-kernel CIFS server would recognize users uid/gid as stored in ldap and that would be the same as used on NFS! -FreeIPA2 should be out fairly soon, is there a final word on how the Windows integration is going to look like (particularly if there's no AD) ? Thanks a lot -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Aug 6 14:21:11 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Aug 2008 10:21:11 -0400 Subject: [Freeipa-devel] [PATCH] fix validation return types Message-ID: <4899B357.4050304@redhat.com> The validation routines returned 0/1 instead of True/False which made readability difficult, particularly with the reversed logic. This patch depends on the patch "use same regex for user/group names as shadow-utils". This should address Stephen's concerns. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-69-validation.patch Type: text/x-patch Size: 79 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 Aug 6 14:26:17 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Aug 2008 10:26:17 -0400 Subject: [Freeipa-devel] RESEND [PATCH] fix validation return types Message-ID: <4899B489.3030308@redhat.com> The validation routines returned 0/1 instead of True/False which made readability difficult, particularly with the reversed logic. This patch depends on the patch "use same regex for user/group names as shadow-utils". This should address Stephen's concerns. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-69-validation.patch Type: text/x-patch Size: 80 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 Aug 6 14:31:52 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Aug 2008 10:31:52 -0400 Subject: [Freeipa-devel] RE-RESEND [PATCH] fix validation return types Message-ID: <4899B5D8.3020807@redhat.com> Ok, 3rd time is the charm. The validation routines returned 0/1 instead of True/False which made readability difficult, particularly with the reversed logic. This patch depends on the patch "use same regex for user/group names as shadow-utils". This should address Stephen's concerns. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-69-validation.patch Type: text/x-patch Size: 18296 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 Wed Aug 6 14:39:12 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 06 Aug 2008 10:39:12 -0400 Subject: [Freeipa-devel] RE-RESEND [PATCH] fix validation return types In-Reply-To: <4899B5D8.3020807@redhat.com> References: <4899B5D8.3020807@redhat.com> Message-ID: <4899B790.7020305@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Crittenden wrote: > Ok, 3rd time is the charm. > > The validation routines returned 0/1 instead of True/False which made > readability difficult, particularly with the reversed logic. > > This patch depends on the patch "use same regex for user/group names as > shadow-utils". > > This should address Stephen's concerns. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel diff --git a/ipa-python/radius_util.py b/ipa-python/radius_util.py index fb3e581..43357b6 100644 - --- a/ipa-python/radius_util.py +++ b/ipa-python/radius_util.py @@ -347,7 +347,7 @@ def validate_nastype(nastype, variable_name=None): return True def validate_desc(desc, variable_name=None): - - if ipavalidate.Plain(desc) != 0: + if not ipavalidate.Plain(desc) != 0: print valid_desc_msg return False return True "if not ipavalidate.Plain(desc) != 0:" seems wrong to me. Why are you still doing the numeric compare? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiZt5AACgkQc7MaxVic+2r51gCfYXx8HETIkKlb+2iYKW0hrNxR rpEAoIZfnggeE6d3vD4C9mad66MULyDr =Ff0X -----END PGP SIGNATURE----- From rcritten at redhat.com Wed Aug 6 14:44:43 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Aug 2008 10:44:43 -0400 Subject: [Freeipa-devel] RE-RESEND [PATCH] fix validation return types In-Reply-To: <4899B790.7020305@redhat.com> References: <4899B5D8.3020807@redhat.com> <4899B790.7020305@redhat.com> Message-ID: <4899B8DB.4040205@redhat.com> Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rob Crittenden wrote: >> Ok, 3rd time is the charm. >> >> The validation routines returned 0/1 instead of True/False which made >> readability difficult, particularly with the reversed logic. >> >> This patch depends on the patch "use same regex for user/group names as >> shadow-utils". >> >> This should address Stephen's concerns. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > diff --git a/ipa-python/radius_util.py b/ipa-python/radius_util.py > index fb3e581..43357b6 100644 > - --- a/ipa-python/radius_util.py > +++ b/ipa-python/radius_util.py > @@ -347,7 +347,7 @@ def validate_nastype(nastype, variable_name=None): > return True > > def validate_desc(desc, variable_name=None): > - - if ipavalidate.Plain(desc) != 0: > + if not ipavalidate.Plain(desc) != 0: > print valid_desc_msg > return False > return True > > > > "if not ipavalidate.Plain(desc) != 0:" seems wrong to me. Why are you > still doing the numeric compare? > Simply missed one. 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 Wed Aug 6 15:26:16 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Aug 2008 11:26:16 -0400 Subject: [Freeipa-devel] [PATCH] fix syntax error Message-ID: <4899C298.7040103@redhat.com> I've fixed a syntax error in ipa-server-install. A colon was missing on an if statement. I pushed this under the trivial-fix rule. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-70-syntax.patch Type: text/x-patch Size: 1078 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 Aug 6 17:04:45 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 06 Aug 2008 13:04:45 -0400 Subject: [Freeipa-devel] [PATCH] use same regex for user/group names as shadow-utils Message-ID: <4899D9AD.7030506@redhat.com> This patch replaces the patch of the same name and the "fix validation return types" patch(es). Turns out my tree was quite a bit out-of-date so I re-based the patches and combined them. The user/group name validator didn't match the standard *nix validator and disallowed some valid names and allowed some invalid ones (including those with spaces). This brings it inline with shadow-utils from Fedora 9. Also change the validation routines to return 0/1 instead of True/False which made readability difficult, particularly with the reversed logic. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-71-goodname.patch Type: text/x-patch Size: 21118 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 Wed Aug 6 17:20:45 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 06 Aug 2008 13:20:45 -0400 Subject: [Freeipa-devel] [PATCH] use same regex for user/group names as shadow-utils In-Reply-To: <4899D9AD.7030506@redhat.com> References: <4899D9AD.7030506@redhat.com> Message-ID: <4899DD6D.60705@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Crittenden wrote: > This patch replaces the patch of the same name and the "fix validation > return types" patch(es). > > Turns out my tree was quite a bit out-of-date so I re-based the patches > and combined them. > > The user/group name validator didn't match the standard *nix validator > and disallowed some valid names and allowed some invalid ones (including > those with spaces). > > This brings it inline with shadow-utils from Fedora 9. > > Also change the validation routines to return 0/1 instead of True/False > which made readability difficult, particularly with the reversed logic. > > rob ack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiZ3WwACgkQc7MaxVic+2qtsACgvHhILrGpJIfJgRhJBZtZoRdC likAoIJlK5fbeDFoqvjkltTxlJURjXaK =LKFE -----END PGP SIGNATURE----- From mnagy at redhat.com Wed Aug 6 17:22:53 2008 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 06 Aug 2008 19:22:53 +0200 Subject: [Freeipa-devel] [PATCH] Fix few syntax errors Message-ID: <4899DDED.8030000@redhat.com> Since the syntax error Rob found was from my patch, I looked at it to see if I didn't make more of them and I did actually. Commited under the trivial rule. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-few-syntax-errors.patch Type: application/mbox Size: 2187 bytes Desc: not available URL: From mnagy at redhat.com Wed Aug 6 18:02:17 2008 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 06 Aug 2008 20:02:17 +0200 Subject: [Freeipa-devel] [PATCH] use same regex for user/group names as shadow-utils In-Reply-To: <4899D9AD.7030506@redhat.com> References: <4899D9AD.7030506@redhat.com> Message-ID: <4899E729.9080604@redhat.com> Rob Crittenden wrote: > This patch replaces the patch of the same name and the "fix validation > return types" patch(es). > > Turns out my tree was quite a bit out-of-date so I re-based the patches > and combined them. > > The user/group name validator didn't match the standard *nix validator > and disallowed some valid names and allowed some invalid ones (including > those with spaces). > > This brings it inline with shadow-utils from Fedora 9. > > Also change the validation routines to return 0/1 instead of True/False > which made readability difficult, particularly with the reversed logic. > > rob ack From ssorce at redhat.com Wed Aug 6 21:30:10 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 06 Aug 2008 17:30:10 -0400 Subject: [Freeipa-devel] [PATCH] Treat Jan1 1970 as a special date for krbPrincipalExpiration Message-ID: <1218058210.11749.2.camel@hopeson> Some tool add a date of Jan 1 1970 as a special date meaning "never". Make sure we ignore that date and don't consider the account expired in that case. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Treat-Jan-1-1970-in-krbPrincipalExpiration-as-a-spec.patch Type: application/mbox Size: 1686 bytes Desc: not available URL: From sgallagh at redhat.com Wed Aug 6 21:36:05 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 06 Aug 2008 17:36:05 -0400 Subject: [Freeipa-devel] [PATCH] Treat Jan1 1970 as a special date for krbPrincipalExpiration In-Reply-To: <1218058210.11749.2.camel@hopeson> References: <1218058210.11749.2.camel@hopeson> Message-ID: <489A1945.7070806@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simo Sorce wrote: > Some tool add a date of Jan 1 1970 as a special date meaning "never". > Make sure we ignore that date and don't consider the account expired in > that case. > > Simo. > ack -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkiaGUUACgkQc7MaxVic+2rziwCeLcVwEAzKSgIYUGP8G6jevFW0 TVQAnj+2gthCKUWWFLDbI/tlrbiDoYvR =fBLo -----END PGP SIGNATURE----- From ssorce at redhat.com Thu Aug 7 13:35:43 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 07 Aug 2008 09:35:43 -0400 Subject: [Freeipa-devel] [PATCH] Use SystemRandom for better random passwords Message-ID: <1218116143.17304.1.camel@hopeson> While reviewing some code I realized we could do a better job at generating random password (and this was already implemented for one of our functions). The current code is *not* flawed, but using better methods is always a good thing. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-larger-set-from-which-to-choose-chars-for-random.patch Type: application/mbox Size: 1615 bytes Desc: not available URL: From rcritten at redhat.com Thu Aug 7 15:23:51 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Aug 2008 11:23:51 -0400 Subject: [Freeipa-devel] [PATCH] use same regex for user/group names as shadow-utils In-Reply-To: <4899DD6D.60705@redhat.com> References: <4899D9AD.7030506@redhat.com> <4899DD6D.60705@redhat.com> Message-ID: <489B1387.1050705@redhat.com> Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rob Crittenden wrote: >> This patch replaces the patch of the same name and the "fix validation >> return types" patch(es). >> >> Turns out my tree was quite a bit out-of-date so I re-based the patches >> and combined them. >> >> The user/group name validator didn't match the standard *nix validator >> and disallowed some valid names and allowed some invalid ones (including >> those with spaces). >> >> This brings it inline with shadow-utils from Fedora 9. >> >> Also change the validation routines to return 0/1 instead of True/False >> which made readability difficult, particularly with the reversed logic. >> >> 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 ssorce at redhat.com Thu Aug 7 16:30:22 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 07 Aug 2008 12:30:22 -0400 Subject: [Freeipa-devel] [PATCH] Treat Jan1 1970 as a special date for krbPrincipalExpiration In-Reply-To: <489A1945.7070806@redhat.com> References: <1218058210.11749.2.camel@hopeson> <489A1945.7070806@redhat.com> Message-ID: <1218126622.2991.3.camel@localhost.localdomain> On Wed, 2008-08-06 at 17:36 -0400, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Simo Sorce wrote: > > Some tool add a date of Jan 1 1970 as a special date meaning "never". > > Make sure we ignore that date and don't consider the account expired in > > that case. > > > > Simo. > > > > ack pushed to master Simo. From ssorce at redhat.com Thu Aug 7 20:19:15 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 07 Aug 2008 16:19:15 -0400 Subject: [Freeipa-devel] [PATCH] Add encrypt_file and decrypt_file functions Message-ID: <1218140355.3548.2.camel@hopeson> See patch, these functions will be used in ipa-replica-prepare and ipa-replica-install to make the data more safe. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-encrypt_file-and-decrypt_file-utility-functions.patch Type: application/mbox Size: 4607 bytes Desc: not available URL: From rcritten at redhat.com Thu Aug 7 20:53:14 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 07 Aug 2008 16:53:14 -0400 Subject: [Freeipa-devel] [PATCH] Add encrypt_file and decrypt_file functions In-Reply-To: <1218140355.3548.2.camel@hopeson> References: <1218140355.3548.2.camel@hopeson> Message-ID: <489B60BA.70709@redhat.com> Simo Sorce wrote: > See patch, these functions will be used in ipa-replica-prepare and > ipa-replica-install to make the data more safe. > > > Just a few minor things. You check that the password exists during encryption but not decryption. Should we do any validation that dest is ok? I suppose we'll find out soon enough from the call to run... A cleaner way of handling a failure would use try/except/finally, though Python 2.4 makes it a little icky. It would look something like this for encrypt_file() try: try: os.mkdir(gpgdir) args = ... except: raise finally: #clean up shutil.rmtree(tempdir, ignore_errors=True) The way it is now is fine but the cleanup code (one line) is duplicated). 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 Aug 7 21:16:27 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 07 Aug 2008 21:16:27 +0000 Subject: [Freeipa-devel] [PATCH] Add encrypt_file and decrypt_file functions In-Reply-To: <489B60BA.70709@redhat.com> References: <1218140355.3548.2.camel@hopeson> <489B60BA.70709@redhat.com> Message-ID: <1218143787.2991.7.camel@localhost.localdomain> On Thu, 2008-08-07 at 16:53 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > See patch, these functions will be used in ipa-replica-prepare and > > ipa-replica-install to make the data more safe. > > > > > > > > Just a few minor things. > > You check that the password exists during encryption but not decryption. ahh right > Should we do any validation that dest is ok? I suppose we'll find out > soon enough from the call to run... the operation would fail and we will get an exception, I wouldn't care too much about that at this point. the caller will need to check for exceptions anyway and decide what to do. > A cleaner way of handling a failure would use try/except/finally, though > Python 2.4 makes it a little icky. It would look something like this > for encrypt_file() > > try: > try: > os.mkdir(gpgdir) > args = ... > except: > raise > finally: > #clean up > shutil.rmtree(tempdir, ignore_errors=True) > > The way it is now is fine but the cleanup code (one line) is duplicated). right, I will change the patch to use finally Simo. From ssorce at redhat.com Thu Aug 7 22:31:17 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 07 Aug 2008 18:31:17 -0400 Subject: [Freeipa-devel] [PATCH] Add encrypt_file and decrypt_file functions In-Reply-To: <1218143787.2991.7.camel@localhost.localdomain> References: <1218140355.3548.2.camel@hopeson> <489B60BA.70709@redhat.com> <1218143787.2991.7.camel@localhost.localdomain> Message-ID: <1218148277.10857.1.camel@hopeson> On Thu, 2008-08-07 at 21:16 +0000, Simo Sorce wrote: > On Thu, 2008-08-07 at 16:53 -0400, Rob Crittenden wrote: > > Simo Sorce wrote: > > > See patch, these functions will be used in ipa-replica-prepare and > > > ipa-replica-install to make the data more safe. > > > > > > > > > > > > > Just a few minor things. > > > > You check that the password exists during encryption but not decryption. > > ahh right > > > Should we do any validation that dest is ok? I suppose we'll find out > > soon enough from the call to run... > > the operation would fail and we will get an exception, I wouldn't care > too much about that at this point. > > the caller will need to check for exceptions anyway and decide what to > do. > > > A cleaner way of handling a failure would use try/except/finally, though > > Python 2.4 makes it a little icky. It would look something like this > > for encrypt_file() > > > > try: > > try: > > os.mkdir(gpgdir) > > args = ... > > except: > > raise > > finally: > > #clean up > > shutil.rmtree(tempdir, ignore_errors=True) > > > > The way it is now is fine but the cleanup code (one line) is duplicated). > > right, I will change the patch to use finally Attached a patch that implement this and also remove mentions of 'tarfile' that were unused as Rob pointed out on IRC. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-encrypt_file-and-decrypt_file-utility-functions.patch Type: application/mbox Size: 4608 bytes Desc: not available URL: From sgallagh at redhat.com Fri Aug 8 11:45:59 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 08 Aug 2008 07:45:59 -0400 Subject: [Freeipa-devel] [PATCH] Add encrypt_file and decrypt_file functions In-Reply-To: <1218148277.10857.1.camel@hopeson> References: <1218140355.3548.2.camel@hopeson> <489B60BA.70709@redhat.com> <1218143787.2991.7.camel@localhost.localdomain> <1218148277.10857.1.camel@hopeson> Message-ID: <489C31F7.1000606@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simo Sorce wrote: > On Thu, 2008-08-07 at 21:16 +0000, Simo Sorce wrote: >> On Thu, 2008-08-07 at 16:53 -0400, Rob Crittenden wrote: >>> Simo Sorce wrote: >>>> See patch, these functions will be used in ipa-replica-prepare and >>>> ipa-replica-install to make the data more safe. >>>> >>>> >>>> >>> Just a few minor things. >>> >>> You check that the password exists during encryption but not decryption. >> ahh right >> >>> Should we do any validation that dest is ok? I suppose we'll find out >>> soon enough from the call to run... >> the operation would fail and we will get an exception, I wouldn't care >> too much about that at this point. >> >> the caller will need to check for exceptions anyway and decide what to >> do. >> >>> A cleaner way of handling a failure would use try/except/finally, though >>> Python 2.4 makes it a little icky. It would look something like this >>> for encrypt_file() >>> >>> try: >>> try: >>> os.mkdir(gpgdir) >>> args = ... >>> except: >>> raise >>> finally: >>> #clean up >>> shutil.rmtree(tempdir, ignore_errors=True) >>> >>> The way it is now is fine but the cleanup code (one line) is duplicated). >> right, I will change the patch to use finally > > Attached a patch that implement this and also remove mentions of > 'tarfile' that were unused as Rob pointed out on IRC. > Maybe I'm crazy, but the two functions encrypt_file() and decrypt_file() do not seem to be actually called anywhere. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkicMfcACgkQc7MaxVic+2rXxQCgra10hJ5Y9u5sIz9ChpM954tp NUwAnRX8A4GGDdp8nlqcM9pxFG0dCGgL =hLr6 -----END PGP SIGNATURE----- From sgallagh at redhat.com Fri Aug 8 11:47:54 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 08 Aug 2008 07:47:54 -0400 Subject: [Freeipa-devel] [PATCH] Add encrypt_file and decrypt_file functions In-Reply-To: <489C31F7.1000606@redhat.com> References: <1218140355.3548.2.camel@hopeson> <489B60BA.70709@redhat.com> <1218143787.2991.7.camel@localhost.localdomain> <1218148277.10857.1.camel@hopeson> <489C31F7.1000606@redhat.com> Message-ID: <489C326A.5090102@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Gallagher wrote: > Simo Sorce wrote: >> On Thu, 2008-08-07 at 21:16 +0000, Simo Sorce wrote: >>> On Thu, 2008-08-07 at 16:53 -0400, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> See patch, these functions will be used in ipa-replica-prepare and >>>>> ipa-replica-install to make the data more safe. >>>>> >>>>> >>>>> >>>> Just a few minor things. >>>> >>>> You check that the password exists during encryption but not decryption. >>> ahh right >>> >>>> Should we do any validation that dest is ok? I suppose we'll find out >>>> soon enough from the call to run... >>> the operation would fail and we will get an exception, I wouldn't care >>> too much about that at this point. >>> >>> the caller will need to check for exceptions anyway and decide what to >>> do. >>> >>>> A cleaner way of handling a failure would use try/except/finally, though >>>> Python 2.4 makes it a little icky. It would look something like this >>>> for encrypt_file() >>>> >>>> try: >>>> try: >>>> os.mkdir(gpgdir) >>>> args = ... >>>> except: >>>> raise >>>> finally: >>>> #clean up >>>> shutil.rmtree(tempdir, ignore_errors=True) >>>> >>>> The way it is now is fine but the cleanup code (one line) is duplicated). >>> right, I will change the patch to use finally >> Attached a patch that implement this and also remove mentions of >> 'tarfile' that were unused as Rob pointed out on IRC. > > > Maybe I'm crazy, but the two functions encrypt_file() and decrypt_file() > do not seem to be actually called anywhere. Please disregard this. I haven't had any caffeine yet today. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkicMmoACgkQc7MaxVic+2qR4ACgpIAqdiN4ji1LDvyUJUH2pn6M fvgAnRpG+l2fxckg3k6Y5ooWLFrGORPu =2KML -----END PGP SIGNATURE----- From rcritten at redhat.com Fri Aug 8 12:43:39 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Aug 2008 08:43:39 -0400 Subject: [Freeipa-devel] freeIPA and NIS In-Reply-To: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> References: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> Message-ID: <489C3F7B.50604@redhat.com> Ahmed Kamal wrote: > Hi, > Thanks for freeIPA, keep up the awesome work. I have a couple of > questions please > > -Does freeIPA offer a migration path off of NIS ? (to maintain same > UID/GIDs) ? We don't currently provide any tools for this, no. It should be possible to migrate the user/group information over using the admin tools. It is possible to set UID and GID values with those (as a modify after the user/group is added). > -Can the freeIPA server present itself as a NIS server as well (same > UID/GID), this is for clients that can't join freeIPA domain (like NAS > boxes?) A plugin is being developed for the directory server that can act as a NIS server. It was recently approved for inclusion in Fedora but has not yet been built. You can follow its progress at https://bugzilla.redhat.com/show_bug.cgi?id=456150 We are initially focusing on the "Schema Compatibility" plugin provided by that so that Solaris nss_ldap will work out-of-the-box and we don't need to use the PADL version. This will make it easier for workstations to join without having to install and configure additional software. The problem is that Solaris doesn't handle the memberOf attribute at all. > -I am considering running open-solaris (for ZFS as a storage box), did > any of you guys try joining that to freeIPA ? Any idea of their > in-kernel CIFS server would recognize users uid/gid as stored in ldap > and that would be the same as used on NFS! I don't believe we tried that specifically but 8, 9 and 10 work ok so it is probably a fairly safe assumption that this will work. I would assume that the OS would rely on whatever nss said the uid/gid numbers were so I would think it would work the same with CIFS and NFS (and everything else). > -FreeIPA2 should be out fairly soon, is there a final word on how the > Windows integration is going to look like (particularly if there's no AD) ? We are still working on this piece. The first step is going to be some limited syncing of users and passwords, later adding a more robust solution. If you have any specific needs please let us know. This can be very complex as some people want to only sync certain parts of their tree, only in one direction, etc. So the more requirements we gather the better the first release will be. 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 rcritten at redhat.com Fri Aug 8 18:45:01 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Aug 2008 14:45:01 -0400 Subject: [Freeipa-devel] [PATCH] Add encrypt_file and decrypt_file functions In-Reply-To: <1218148277.10857.1.camel@hopeson> References: <1218140355.3548.2.camel@hopeson> <489B60BA.70709@redhat.com> <1218143787.2991.7.camel@localhost.localdomain> <1218148277.10857.1.camel@hopeson> Message-ID: <489C942D.4090301@redhat.com> Simo Sorce wrote: > On Thu, 2008-08-07 at 21:16 +0000, Simo Sorce wrote: >> On Thu, 2008-08-07 at 16:53 -0400, Rob Crittenden wrote: >>> Simo Sorce wrote: >>>> See patch, these functions will be used in ipa-replica-prepare and >>>> ipa-replica-install to make the data more safe. >>>> >>>> >>>> >>> Just a few minor things. >>> >>> You check that the password exists during encryption but not decryption. >> ahh right >> >>> Should we do any validation that dest is ok? I suppose we'll find out >>> soon enough from the call to run... >> the operation would fail and we will get an exception, I wouldn't care >> too much about that at this point. >> >> the caller will need to check for exceptions anyway and decide what to >> do. >> >>> A cleaner way of handling a failure would use try/except/finally, though >>> Python 2.4 makes it a little icky. It would look something like this >>> for encrypt_file() >>> >>> try: >>> try: >>> os.mkdir(gpgdir) >>> args = ... >>> except: >>> raise >>> finally: >>> #clean up >>> shutil.rmtree(tempdir, ignore_errors=True) >>> >>> The way it is now is fine but the cleanup code (one line) is duplicated). >> right, I will change the patch to use finally > > Attached a patch that implement this and also remove mentions of > 'tarfile' that were unused as Rob pointed out on IRC. > 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 rcritten at redhat.com Fri Aug 8 18:47:21 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Aug 2008 14:47:21 -0400 Subject: [Freeipa-devel] [PATCH] Use SystemRandom for better random passwords In-Reply-To: <1218116143.17304.1.camel@hopeson> References: <1218116143.17304.1.camel@hopeson> Message-ID: <489C94B9.7050809@redhat.com> Simo Sorce wrote: > While reviewing some code I realized we could do a better job at > generating random password (and this was already implemented for one of > our functions). > The current code is *not* flawed, but using better methods is always a > good thing. ack but looks like you can remove the 'generator = random.SystemRandom()' 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 Fri Aug 8 19:31:30 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 08 Aug 2008 15:31:30 -0400 Subject: [Freeipa-devel] [PATCH] Fix versioning stuff in master tree Message-ID: <1218223890.20938.2.camel@hopeson> Setting version numbers was a bit too much manual, and obviously got out of sync. ipa-server and ipa-client configure were reporting version 0.6.0 ... This patch fixes some of these spots and also allows for easier control over RPMs versioning when using make local-dist Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-versioning-for-configure.ac-and-ipa-python-setup.patch Type: application/mbox Size: 13299 bytes Desc: not available URL: From rcritten at redhat.com Fri Aug 8 19:41:29 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 08 Aug 2008 15:41:29 -0400 Subject: [Freeipa-devel] [PATCH] Fix versioning stuff in master tree In-Reply-To: <1218223890.20938.2.camel@hopeson> References: <1218223890.20938.2.camel@hopeson> Message-ID: <489CA169.6050109@redhat.com> Simo Sorce wrote: > Setting version numbers was a bit too much manual, and obviously got out > of sync. ipa-server and ipa-client configure were reporting version > 0.6.0 ... > > This patch fixes some of these spots and also allows for easier control > over RPMs versioning when using make local-dist > > Simo. Bleh, guess I missed a few on the first pass. I'm not sure I follow the logic of moving the dependency of version-update to clean/dist-clean. Can you elaborate? 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 Aug 8 19:42:00 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 08 Aug 2008 15:42:00 -0400 Subject: [Freeipa-devel] [PATCH] Use SystemRandom for better random passwords In-Reply-To: <489C94B9.7050809@redhat.com> References: <1218116143.17304.1.camel@hopeson> <489C94B9.7050809@redhat.com> Message-ID: <1218224520.2991.19.camel@localhost.localdomain> On Fri, 2008-08-08 at 14:47 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > While reviewing some code I realized we could do a better job at > > generating random password (and this was already implemented for one of > > our functions). > > The current code is *not* flawed, but using better methods is always a > > good thing. > > ack but looks like you can remove the 'generator = > random.SystemRandom()' as well. arghh no, thanks for point this out because the bug is that the last line should look like: + password += generator.choice(password_chars) and NOT + password += r.choice(password_chars) bloody copy&paste errors :-) Simo. From ssorce at redhat.com Fri Aug 8 19:42:03 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 08 Aug 2008 15:42:03 -0400 Subject: [Freeipa-devel] [PATCH] Use SystemRandom for better random passwords In-Reply-To: <1218224520.2991.19.camel@localhost.localdomain> References: <1218116143.17304.1.camel@hopeson> <489C94B9.7050809@redhat.com> <1218224520.2991.19.camel@localhost.localdomain> Message-ID: <1218224523.21941.0.camel@hopeson> On Fri, 2008-08-08 at 15:42 -0400, Simo Sorce wrote: > On Fri, 2008-08-08 at 14:47 -0400, Rob Crittenden wrote: > > Simo Sorce wrote: > > > While reviewing some code I realized we could do a better job at > > > generating random password (and this was already implemented for one of > > > our functions). > > > The current code is *not* flawed, but using better methods is always a > > > good thing. > > > > ack but looks like you can remove the 'generator = > > random.SystemRandom()' as well. > > arghh no, thanks for point this out because the bug is that the last > line should look like: > > + password += generator.choice(password_chars) > > and NOT > > + password += r.choice(password_chars) > > bloody copy&paste errors :-) New patch fixing this. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Use-larger-set-from-which-to-choose-chars-for-random.patch Type: application/mbox Size: 1623 bytes Desc: not available URL: From ssorce at redhat.com Fri Aug 8 21:00:34 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 08 Aug 2008 17:00:34 -0400 Subject: [Freeipa-devel] [PATCH] Fix versioning stuff in master tree In-Reply-To: <489CA169.6050109@redhat.com> References: <1218223890.20938.2.camel@hopeson> <489CA169.6050109@redhat.com> Message-ID: <1218229234.2991.20.camel@localhost.localdomain> On Fri, 2008-08-08 at 15:41 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > Setting version numbers was a bit too much manual, and obviously got out > > of sync. ipa-server and ipa-client configure were reporting version > > 0.6.0 ... > > > > This patch fixes some of these spots and also allows for easier control > > over RPMs versioning when using make local-dist > > > > Simo. > > Bleh, guess I missed a few on the first pass. No problem :-) > I'm not sure I follow the logic of moving the dependency of > version-update to clean/dist-clean. Can you elaborate? It creates version.m4 without it any call to autoconf will fail as configure.ac includes it Simo. From ssorce at redhat.com Fri Aug 8 21:02:11 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 08 Aug 2008 17:02:11 -0400 Subject: [Freeipa-devel] [PATCH] Encrypt replica file Message-ID: <1218229331.26284.2.camel@hopeson> This patch encrypts the replica file so that even if the file is left around it does not expose security relevant information. Unfortunately while testing I got an error down the patch after my patch is concerned, setting up the replica fails with: [16/16]: configuring directory to start on boot done configuring dirsrv. creation of replica failed: {'info': 'Operation requires a secure connection.\n', 'desc': 'Confidentiality required'} I think this is unrelated to this patch but if you see anything that can cause it let me know, this is why I am sending the patch for review even if I could not successfully test a complete replication setup. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Used-the-encrypt_file-and-decrypt_file-utility-funct.patch Type: application/mbox Size: 7153 bytes Desc: not available URL: From ssorce at redhat.com Fri Aug 8 21:25:40 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 08 Aug 2008 21:25:40 +0000 Subject: [Freeipa-devel] [PATCH] Encrypt replica file In-Reply-To: <1218229331.26284.2.camel@hopeson> References: <1218229331.26284.2.camel@hopeson> Message-ID: <1218230740.2991.23.camel@localhost.localdomain> On Fri, 2008-08-08 at 17:02 -0400, Simo Sorce wrote: > I think this is unrelated to this patch but if you see anything that can > cause it let me know, this is why I am sending the patch for review even > if I could not successfully test a complete replication setup. Tested again backing out this patch and I still get the same error, so this patch seem not related, please consider it on its own merits :) Simo. From Colin.Simpson at iongeo.com Sun Aug 10 01:34:14 2008 From: Colin.Simpson at iongeo.com (Colin Simpson) Date: Sun, 10 Aug 2008 02:34:14 +0100 Subject: [Freeipa-devel] freeIPA and NIS In-Reply-To: <489C3F7B.50604@redhat.com> References: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> <489C3F7B.50604@redhat.com> Message-ID: <1218332054.7942.56.camel@shyster> On Fri, 2008-08-08 at 08:43 -0400, Rob Crittenden wrote: > > -FreeIPA2 should be out fairly soon, is there a final word on how the > > Windows integration is going to look like (particularly if there's no AD) ? > > We are still working on this piece. The first step is going to be some > limited syncing of users and passwords, later adding a more robust solution. > > If you have any specific needs please let us know. This can be very > complex as some people want to only sync certain parts of their tree, > only in one direction, etc. So the more requirements we gather the > better the first release will be. > > thanks > > rob I'm interested in your AD integration plans. We are a heavy RH Linux users but our parent is a big AD user (and we use AD on the Windows side). Our present Linux directory is a hand built OpenLDAP/MIT Kerberos solution, pretty much what IPA was designed to replace. We have at present password syncing via a couple of tools. Maybe we're pretty typical. In the future (hopefully near future) we'd like to have a much more integrated solution. We are looking at either Enterprise IPA or Samba 4 (saying that whenever that appears!) Features we'd look for: 1. True single sign on. If you say, log into a windows box and SSH into Linux you shouldn't be asked for a password and vice-versa if you say got to a Windows Sharepoint site in Firefox on Linux you should again not be asked for a password. Now I know this can be achieved already by a cross realm trust, but it's a bit of hassle to setup (IPA might help here by hiding some of the pain). One downside I have seen of this is that the Kerberos realm appears in the Windows drop down domains list on the login screen. We'd not really want Windows users logging into that for various reasons. Not sure if it's possible to hide a domain(realm) in windows from that dialog if it's trusted. Also with this approach telling windows AD that one user on a realm is equivalent to a user on another realm is a hassle to setup (again an IPA opportunity to ease the pain). And also, does the IPA's use of DNS to find directory servers interfere with AD's (i.e do they use the same mechanism/name spaces). I'd rather not maintain my Windows and Linux boxes in separate DNS zones just to keep various directory services happy (it makes DHCP with Dynamic DNS a non starter). 2. Support auto adding of Linux accounts when AD accounts are added would be nice, maybe based on a template of some kind, for things like automount points of home directories). Probably pulling in the Unix attributes from AD if that schema is loaded in AD, would be a nice feature. 3. Naturally, of course password syncing. 4. How will IPA support Samba servers? Just now we join Samba to AD and use a second krb5.conf file (with all the AD stuff in) that only samba uses (giving clean passwordless access to Samba shares for Windows users). My view of IPA vs potentially a Samba 4 solution would be: Samba 4 ======= No Cross Realm trust issues - As in it would issue krb tickets that were just tickets valid in AD. No separate management of a Linux directory. Having an AD account would automatically give you a Linux account. Can have windows systems authenticate safely to a Samba 4 server. IPA === Better Linux targeting - Management of policies and patches. No hoops to jump through to support *ix features e.g automount maps Kerberos Service (host, NFS) keys etc. Easier client configuration Good vendor support and IPA is here now. Or is there no choice here and IPA will be able to pull in all Samba 4 features. Have I missed anything or just given you job security for life... Thanks Colin This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original. From dpal at redhat.com Mon Aug 11 14:26:00 2008 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 11 Aug 2008 10:26:00 -0400 Subject: [Freeipa-devel] freeIPA and NIS In-Reply-To: <1218332054.7942.56.camel@shyster> References: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> <489C3F7B.50604@redhat.com> <1218332054.7942.56.camel@shyster> Message-ID: <48A04BF8.5070602@redhat.com> Colin, Our plans for the AD integration are following: a) We will release an AD synch tool later this year (most likely November). Since the freeIPA versions and Red Hat Enterprise versions are a bit out of synch I can't say exactly which freeIPA version it would be but 1.x for sure. It will be 1.1 for RHEIPA. The feature will deliver: 1) If user account is created in AD it is synchronized to IPA. 2) If user account is created in IPA it is NOT synchronized to AD 3) The changes to an account once created in AD and synchronized to IPA are synchronized in both directions. 4) The passwords for accounts mentioned in 3) are also synchronized in both directions but require installation of the password filter component on every DC. b) In freeIPA v2 we plan to offer trust between IPA and AD. This will probably ease some pain but to what extent it is hard to say at the moment. Yes we use DNS for the name resolution and IPA v2 will be even more integrated with DNS. There will be an option to use an already existing DNS instead of the one that would come with IPA but zoning is the preferred method. One of the features of the v2 is the capability of the clients to update their DNS information. The DNS back end will be integrated with IPA's DS and kerberos auth will be used to make sure the update is legitimate. c) Samba 4 and Penrose are other technologies that we seriously consider as solutions for the better AD integration down the road. It is unclear what shape and form this solution would take. It is unlikely that anything more than options a) and b) will be available soon. Tighter integration via Samba 4 is on our radar for v3 but may be Penrose based solution would come out earlier than that. From the use case you described it seems that Samba 4 will work fine for the Windows machines you have in your company. It most likely will be accepted as a domain (represented by Samba 4) by your parent company. IPA will be used for Linux/Unix machines and user accounts on those machines. There you will have an option of a) and b) and probably Penrose based solution. Having and integrated Samba 4 + IPA realm that can deal with both Windows and Linux/Unix might not be the best choice. We are working on such integration option but as I mentioned it is down the road in v3 time frame. I hope I did not miss anything. Thank you Dmitri Colin Simpson wrote: > On Fri, 2008-08-08 at 08:43 -0400, Rob Crittenden wrote: > > >>> -FreeIPA2 should be out fairly soon, is there a final word on how the >>> Windows integration is going to look like (particularly if there's no AD) ? >>> >> We are still working on this piece. The first step is going to be some >> limited syncing of users and passwords, later adding a more robust solution. >> >> If you have any specific needs please let us know. This can be very >> complex as some people want to only sync certain parts of their tree, >> only in one direction, etc. So the more requirements we gather the >> better the first release will be. >> >> thanks >> >> rob >> > > I'm interested in your AD integration plans. > > We are a heavy RH Linux users but our parent is a big AD user (and we > use AD on the Windows side). Our present Linux directory is a hand built > OpenLDAP/MIT Kerberos solution, pretty much what IPA was designed to > replace. We have at present password syncing via a couple of tools. > Maybe we're pretty typical. > > In the future (hopefully near future) we'd like to have a much more > integrated solution. We are looking at either Enterprise IPA or Samba 4 > (saying that whenever that appears!) > > Features we'd look for: > > 1. True single sign on. If you say, log into a windows box and SSH into > Linux you shouldn't be asked for a password and vice-versa if you say > got to a Windows Sharepoint site in Firefox on Linux you should again > not be asked for a password. > > Now I know this can be achieved already by a cross realm trust, but it's > a bit of hassle to setup (IPA might help here by hiding some of the > pain). One downside I have seen of this is that the Kerberos realm > appears in the Windows drop down domains list on the login screen. We'd > not really want Windows users logging into that for various reasons. Not > sure if it's possible to hide a domain(realm) in windows from that > dialog if it's trusted. > > Also with this approach telling windows AD that one user on a realm is > equivalent to a user on another realm is a hassle to setup (again an IPA > opportunity to ease the pain). > > And also, does the IPA's use of DNS to find directory servers interfere > with AD's (i.e do they use the same mechanism/name spaces). I'd rather > not maintain my Windows and Linux boxes in separate DNS zones just to > keep various directory services happy (it makes DHCP with Dynamic DNS a > non starter). > > 2. Support auto adding of Linux accounts when AD accounts are added > would be nice, maybe based on a template of some kind, for things like > automount points of home directories). > > Probably pulling in the Unix attributes from AD if that schema is loaded > in AD, would be a nice feature. > > 3. Naturally, of course password syncing. > > 4. How will IPA support Samba servers? Just now we join Samba to AD and > use a second krb5.conf file (with all the AD stuff in) that only samba > uses (giving clean passwordless access to Samba shares for Windows > users). > > My view of IPA vs potentially a Samba 4 solution would be: > > Samba 4 > ======= > No Cross Realm trust issues - As in it would issue krb tickets that were > just tickets valid in AD. > > No separate management of a Linux directory. Having an AD account would > automatically give you a Linux account. > > Can have windows systems authenticate safely to a Samba 4 server. > > IPA > === > Better Linux targeting - Management of policies and patches. > > No hoops to jump through to support *ix features e.g automount maps > Kerberos Service (host, NFS) keys etc. > > Easier client configuration > > Good vendor support and IPA is here now. > > > Or is there no choice here and IPA will be able to pull in all Samba 4 > features. > > Have I missed anything or just given you job security for life... > > Thanks > > Colin > > This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original. > > > > _______________________________________________ > 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 email.ahmedkamal at googlemail.com Mon Aug 11 16:45:15 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Mon, 11 Aug 2008 19:45:15 +0300 Subject: [Freeipa-devel] freeIPA and NIS In-Reply-To: <48A04BF8.5070602@redhat.com> References: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> <489C3F7B.50604@redhat.com> <1218332054.7942.56.camel@shyster> <48A04BF8.5070602@redhat.com> Message-ID: <3da3b5b40808110945w6f025fd5te4838ef57d601b15@mail.gmail.com> Thanks Dmitri for the very informative reply. I am planning on buying RHEIPA soon, I will probably use it in testing mode and let like 30 users play on it. After it has proved successful for us, is it possible to "link" the 30 user accounts from freeIPA to the same people's AD accounts (without deleting and re-creating all accounts) ? I hope the users would retain their UIDs so nothing breaks Thanks On Mon, Aug 11, 2008 at 5:26 PM, Dmitri Pal wrote: > Colin, > > Our plans for the AD integration are following: > a) We will release an AD synch tool later this year (most likely November). > Since the freeIPA versions and Red Hat Enterprise versions are a bit out of > synch I can't say exactly which freeIPA version it would be but 1.x for > sure. It will be 1.1 for RHEIPA. The feature will deliver: > 1) If user account is created in AD it is synchronized to IPA. > 2) If user account is created in IPA it is NOT synchronized to AD > 3) The changes to an account once created in AD and synchronized to IPA > are synchronized in both directions. > 4) The passwords for accounts mentioned in 3) are also synchronized in > both directions but require installation of the password filter component on > every DC. > b) In freeIPA v2 we plan to offer trust between IPA and AD. This will > probably ease some pain but to what extent it is hard to say at the moment. > Yes we use DNS for the name resolution and IPA v2 will be even more > integrated with DNS. There will be an option to use an already existing DNS > instead of the one that would come with IPA but zoning is the preferred > method. One of the features of the v2 is the capability of the clients to > update their DNS information. The DNS back end will be integrated with > IPA's DS and kerberos auth will be used to make sure the update is > legitimate. > c) Samba 4 and Penrose are other technologies that we seriously consider as > solutions for the better AD integration down the road. It is unclear what > shape and form this solution would take. It is unlikely that anything more > than options a) and b) will be available soon. Tighter integration via Samba > 4 is on our radar for v3 but may be Penrose based solution would come out > earlier than that. > > From the use case you described it seems that Samba 4 will work fine for > the Windows machines you have in your company. It most likely will be > accepted as a domain (represented by Samba 4) by your parent company. IPA > will be used for Linux/Unix machines and user accounts on those machines. > There you will have an option of a) and b) and probably Penrose based > solution. Having and integrated Samba 4 + IPA realm that can deal with both > Windows and Linux/Unix might not be the best choice. We are working on such > integration option but as I mentioned it is down the road in v3 time frame. > > I hope I did not miss anything. > > Thank you > Dmitri > > > Colin Simpson wrote: > >> On Fri, 2008-08-08 at 08:43 -0400, Rob Crittenden wrote: >> >> >> >>> -FreeIPA2 should be out fairly soon, is there a final word on how the >>>> Windows integration is going to look like (particularly if there's no AD) ? >>>> >>>> >>> We are still working on this piece. The first step is going to be some >>> limited syncing of users and passwords, later adding a more robust solution. >>> >>> If you have any specific needs please let us know. This can be very >>> complex as some people want to only sync certain parts of their tree, only >>> in one direction, etc. So the more requirements we gather the better the >>> first release will be. >>> >>> thanks >>> >>> rob >>> >>> >> >> I'm interested in your AD integration plans. >> >> We are a heavy RH Linux users but our parent is a big AD user (and we >> use AD on the Windows side). Our present Linux directory is a hand built >> OpenLDAP/MIT Kerberos solution, pretty much what IPA was designed to >> replace. We have at present password syncing via a couple of tools. >> Maybe we're pretty typical. >> >> In the future (hopefully near future) we'd like to have a much more >> integrated solution. We are looking at either Enterprise IPA or Samba 4 >> (saying that whenever that appears!) >> >> Features we'd look for: >> >> 1. True single sign on. If you say, log into a windows box and SSH into >> Linux you shouldn't be asked for a password and vice-versa if you say >> got to a Windows Sharepoint site in Firefox on Linux you should again >> not be asked for a password. >> Now I know this can be achieved already by a cross realm trust, but it's >> a bit of hassle to setup (IPA might help here by hiding some of the >> pain). One downside I have seen of this is that the Kerberos realm >> appears in the Windows drop down domains list on the login screen. We'd >> not really want Windows users logging into that for various reasons. Not >> sure if it's possible to hide a domain(realm) in windows from that >> dialog if it's trusted. >> Also with this approach telling windows AD that one user on a realm is >> equivalent to a user on another realm is a hassle to setup (again an IPA >> opportunity to ease the pain). >> And also, does the IPA's use of DNS to find directory servers interfere >> with AD's (i.e do they use the same mechanism/name spaces). I'd rather >> not maintain my Windows and Linux boxes in separate DNS zones just to >> keep various directory services happy (it makes DHCP with Dynamic DNS a >> non starter). >> 2. Support auto adding of Linux accounts when AD accounts are added >> would be nice, maybe based on a template of some kind, for things like >> automount points of home directories). >> Probably pulling in the Unix attributes from AD if that schema is loaded >> in AD, would be a nice feature. >> 3. Naturally, of course password syncing. >> 4. How will IPA support Samba servers? Just now we join Samba to AD and >> use a second krb5.conf file (with all the AD stuff in) that only samba >> uses (giving clean passwordless access to Samba shares for Windows >> users). >> >> My view of IPA vs potentially a Samba 4 solution would be: >> >> Samba 4 >> ======= >> No Cross Realm trust issues - As in it would issue krb tickets that were >> just tickets valid in AD. >> >> No separate management of a Linux directory. Having an AD account would >> automatically give you a Linux account. >> Can have windows systems authenticate safely to a Samba 4 server. >> >> IPA >> === >> Better Linux targeting - Management of policies and patches. >> >> No hoops to jump through to support *ix features e.g automount maps >> Kerberos Service (host, NFS) keys etc. >> Easier client configuration >> >> Good vendor support and IPA is here now. >> >> >> Or is there no choice here and IPA will be able to pull in all Samba 4 >> features. >> Have I missed anything or just given you job security for life... >> >> Thanks >> Colin >> >> This email and any files transmitted with it are confidential and are >> intended solely for the use of the individual or entity to whom they are >> addressed. If you are not the original recipient or the person responsible >> for delivering the email to the intended recipient, be advised that you have >> received this email in error, and that any use, dissemination, forwarding, >> printing, or copying of this email is strictly prohibited. If you received >> this email in error, please immediately notify the sender and delete the >> original. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> > > > -- > Dmitri Pal > Engineering Manager > Red Hat Inc. > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Aug 11 20:20:38 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Aug 2008 16:20:38 -0400 Subject: [Freeipa-devel] [PATCH] Use SystemRandom for better random passwords In-Reply-To: <1218224523.21941.0.camel@hopeson> References: <1218116143.17304.1.camel@hopeson> <489C94B9.7050809@redhat.com> <1218224520.2991.19.camel@localhost.localdomain> <1218224523.21941.0.camel@hopeson> Message-ID: <48A09F16.60408@redhat.com> Simo Sorce wrote: > On Fri, 2008-08-08 at 15:42 -0400, Simo Sorce wrote: >> On Fri, 2008-08-08 at 14:47 -0400, Rob Crittenden wrote: >>> Simo Sorce wrote: >>>> While reviewing some code I realized we could do a better job at >>>> generating random password (and this was already implemented for one of >>>> our functions). >>>> The current code is *not* flawed, but using better methods is always a >>>> good thing. >>> ack but looks like you can remove the 'generator = >>> random.SystemRandom()' as well. >> arghh no, thanks for point this out because the bug is that the last >> line should look like: >> >> + password += generator.choice(password_chars) >> >> and NOT >> >> + password += r.choice(password_chars) >> >> bloody copy&paste errors :-) > > New patch fixing this. > > Simo. 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 rcritten at redhat.com Mon Aug 11 20:25:03 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Aug 2008 16:25:03 -0400 Subject: [Freeipa-devel] [PATCH] Encrypt replica file In-Reply-To: <1218230740.2991.23.camel@localhost.localdomain> References: <1218229331.26284.2.camel@hopeson> <1218230740.2991.23.camel@localhost.localdomain> Message-ID: <48A0A01F.4020800@redhat.com> Simo Sorce wrote: > On Fri, 2008-08-08 at 17:02 -0400, Simo Sorce wrote: >> I think this is unrelated to this patch but if you see anything that can >> cause it let me know, this is why I am sending the patch for review even >> if I could not successfully test a complete replication setup. > > Tested again backing out this patch and I still get the same error, so > this patch seem not related, please consider it on its own merits :) > > Simo. 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 rcritten at redhat.com Mon Aug 11 20:28:04 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Aug 2008 16:28:04 -0400 Subject: [Freeipa-devel] [PATCH] Fix versioning stuff in master tree In-Reply-To: <1218229234.2991.20.camel@localhost.localdomain> References: <1218223890.20938.2.camel@hopeson> <489CA169.6050109@redhat.com> <1218229234.2991.20.camel@localhost.localdomain> Message-ID: <48A0A0D4.20601@redhat.com> Simo Sorce wrote: > On Fri, 2008-08-08 at 15:41 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> Setting version numbers was a bit too much manual, and obviously got out >>> of sync. ipa-server and ipa-client configure were reporting version >>> 0.6.0 ... >>> >>> This patch fixes some of these spots and also allows for easier control >>> over RPMs versioning when using make local-dist >>> >>> Simo. >> Bleh, guess I missed a few on the first pass. > > No problem :-) > >> I'm not sure I follow the logic of moving the dependency of >> version-update to clean/dist-clean. Can you elaborate? > > It creates version.m4 > without it any call to autoconf will fail as configure.ac includes it > > Simo. > maintainer-clean doesn't clean up a bunch of files used in the versioning: # RELEASE # ipa-admintools/ipa-admintools.spec # ipa-client/version.m4 # ipa-radius-admintools/ipa-radius-admintools.spec # ipa-radius-server/ipa-radius-server.spec # ipa-server/selinux/ipa-server-selinux.spec # ipa-server/version.m4 I'd think we'd want to remove these, right? 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 Aug 11 20:40:16 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 11 Aug 2008 16:40:16 -0400 Subject: [Freeipa-devel] [PATCH] Fix versioning stuff in master tree In-Reply-To: <48A0A0D4.20601@redhat.com> References: <1218223890.20938.2.camel@hopeson> <489CA169.6050109@redhat.com> <1218229234.2991.20.camel@localhost.localdomain> <48A0A0D4.20601@redhat.com> Message-ID: <1218487216.2991.45.camel@localhost.localdomain> On Mon, 2008-08-11 at 16:28 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Fri, 2008-08-08 at 15:41 -0400, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> Setting version numbers was a bit too much manual, and obviously got out > >>> of sync. ipa-server and ipa-client configure were reporting version > >>> 0.6.0 ... > >>> > >>> This patch fixes some of these spots and also allows for easier control > >>> over RPMs versioning when using make local-dist > >>> > >>> Simo. > >> Bleh, guess I missed a few on the first pass. > > > > No problem :-) > > > >> I'm not sure I follow the logic of moving the dependency of > >> version-update to clean/dist-clean. Can you elaborate? > > > > It creates version.m4 > > without it any call to autoconf will fail as configure.ac includes it > > > > Simo. > > > > maintainer-clean doesn't clean up a bunch of files used in the versioning: > > # RELEASE > # ipa-admintools/ipa-admintools.spec > # ipa-client/version.m4 > # ipa-radius-admintools/ipa-radius-admintools.spec > # ipa-radius-server/ipa-radius-server.spec > # ipa-server/selinux/ipa-server-selinux.spec > # ipa-server/version.m4 > > I'd think we'd want to remove these, right? maybe but it didn't remove the .spec files before :-) do you want me to add this clean up to this patch ? or should we have a separate patch for that ? Simo. From rcritten at redhat.com Mon Aug 11 21:35:42 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 11 Aug 2008 17:35:42 -0400 Subject: [Freeipa-devel] [PATCH] Fix versioning stuff in master tree In-Reply-To: <1218487216.2991.45.camel@localhost.localdomain> References: <1218223890.20938.2.camel@hopeson> <489CA169.6050109@redhat.com> <1218229234.2991.20.camel@localhost.localdomain> <48A0A0D4.20601@redhat.com> <1218487216.2991.45.camel@localhost.localdomain> Message-ID: <48A0B0AE.3030503@redhat.com> Simo Sorce wrote: > On Mon, 2008-08-11 at 16:28 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Fri, 2008-08-08 at 15:41 -0400, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> Setting version numbers was a bit too much manual, and obviously got out >>>>> of sync. ipa-server and ipa-client configure were reporting version >>>>> 0.6.0 ... >>>>> >>>>> This patch fixes some of these spots and also allows for easier control >>>>> over RPMs versioning when using make local-dist >>>>> >>>>> Simo. >>>> Bleh, guess I missed a few on the first pass. >>> No problem :-) >>> >>>> I'm not sure I follow the logic of moving the dependency of >>>> version-update to clean/dist-clean. Can you elaborate? >>> It creates version.m4 >>> without it any call to autoconf will fail as configure.ac includes it >>> >>> Simo. >>> >> maintainer-clean doesn't clean up a bunch of files used in the versioning: >> >> # RELEASE >> # ipa-admintools/ipa-admintools.spec >> # ipa-client/version.m4 >> # ipa-radius-admintools/ipa-radius-admintools.spec >> # ipa-radius-server/ipa-radius-server.spec >> # ipa-server/selinux/ipa-server-selinux.spec >> # ipa-server/version.m4 >> >> I'd think we'd want to remove these, right? > > maybe but it didn't remove the .spec files before :-) > do you want me to add this clean up to this patch ? > or should we have a separate patch for that ? In my unpatched tree the only file getting left over after a maintainer-clean is ipa-server/selinux/ipa-server-selinux.spec. It can be a separate patch. 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 Aug 11 22:12:03 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 11 Aug 2008 18:12:03 -0400 Subject: [Freeipa-devel] [PATCH] Fix versioning stuff in master tree In-Reply-To: <48A0B0AE.3030503@redhat.com> References: <1218223890.20938.2.camel@hopeson> <489CA169.6050109@redhat.com> <1218229234.2991.20.camel@localhost.localdomain> <48A0A0D4.20601@redhat.com> <1218487216.2991.45.camel@localhost.localdomain> <48A0B0AE.3030503@redhat.com> Message-ID: <1218492723.17089.0.camel@hopeson> On Mon, 2008-08-11 at 17:35 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Mon, 2008-08-11 at 16:28 -0400, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> On Fri, 2008-08-08 at 15:41 -0400, Rob Crittenden wrote: > >>>> Simo Sorce wrote: > >>>>> Setting version numbers was a bit too much manual, and obviously got out > >>>>> of sync. ipa-server and ipa-client configure were reporting version > >>>>> 0.6.0 ... > >>>>> > >>>>> This patch fixes some of these spots and also allows for easier control > >>>>> over RPMs versioning when using make local-dist > >>>>> > >>>>> Simo. > >>>> Bleh, guess I missed a few on the first pass. > >>> No problem :-) > >>> > >>>> I'm not sure I follow the logic of moving the dependency of > >>>> version-update to clean/dist-clean. Can you elaborate? > >>> It creates version.m4 > >>> without it any call to autoconf will fail as configure.ac includes it > >>> > >>> Simo. > >>> > >> maintainer-clean doesn't clean up a bunch of files used in the versioning: > >> > >> # RELEASE > >> # ipa-admintools/ipa-admintools.spec > >> # ipa-client/version.m4 > >> # ipa-radius-admintools/ipa-radius-admintools.spec > >> # ipa-radius-server/ipa-radius-server.spec > >> # ipa-server/selinux/ipa-server-selinux.spec > >> # ipa-server/version.m4 > >> > >> I'd think we'd want to remove these, right? > > > > maybe but it didn't remove the .spec files before :-) > > do you want me to add this clean up to this patch ? > > or should we have a separate patch for that ? > > In my unpatched tree the only file getting left over after a > maintainer-clean is ipa-server/selinux/ipa-server-selinux.spec. > > It can be a separate patch. No, I do not like regressions, here's an updated patch that fixes the problem, will commit it as the change was trivial and I tested it works. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-versioning-for-configure.ac-and-ipa-python-setup.patch Type: application/mbox Size: 14577 bytes Desc: not available URL: From ssorce at redhat.com Mon Aug 11 22:14:39 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 11 Aug 2008 18:14:39 -0400 Subject: [Freeipa-devel] [PATCH] fix replica-install to use SSL connections early on Message-ID: <1218492879.17089.4.camel@hopeson> This patch install the ca.crt file early on and enforce the use of SSL to set up the replication agreement. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Install-the-ca.crt-file-eraly-on-so-that-we-can-alwa.patch Type: application/mbox Size: 5597 bytes Desc: not available URL: From ssorce at redhat.com Mon Aug 11 22:17:06 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 11 Aug 2008 18:17:06 -0400 Subject: [Freeipa-devel] [PATCH] Support password change operation by direct manipulation of userPassword In-Reply-To: <1216912400.8999.45.camel@hopeson> References: <1216822832.937.16.camel@hopeson> <1216912400.8999.45.camel@hopeson> Message-ID: <1218493026.17089.8.camel@hopeson> On Thu, 2008-07-24 at 11:13 -0400, Simo Sorce wrote: > 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. Another revision, this one removes the requirement to have an ssl connection to just ldapadd/ldapmodify the userPassword attribute. This would be a change in behavior for DS and may cause problems to existing applications. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Implement-password-operation-checks-and-key-material.patch Type: application/mbox Size: 40273 bytes Desc: not available URL: From ssorce at redhat.com Mon Aug 11 22:35:13 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 11 Aug 2008 18:35:13 -0400 Subject: [Freeipa-devel] [PATCH] Encrypt replica file In-Reply-To: <48A0A01F.4020800@redhat.com> References: <1218229331.26284.2.camel@hopeson> <1218230740.2991.23.camel@localhost.localdomain> <48A0A01F.4020800@redhat.com> Message-ID: <1218494113.2991.48.camel@localhost.localdomain> On Mon, 2008-08-11 at 16:25 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Fri, 2008-08-08 at 17:02 -0400, Simo Sorce wrote: > >> I think this is unrelated to this patch but if you see anything that can > >> cause it let me know, this is why I am sending the patch for review even > >> if I could not successfully test a complete replication setup. > > > > Tested again backing out this patch and I still get the same error, so > > this patch seem not related, please consider it on its own merits :) > > > > Simo. > > ack pushed to master From ssorce at redhat.com Mon Aug 11 22:35:43 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 11 Aug 2008 18:35:43 -0400 Subject: [Freeipa-devel] [PATCH] Fix versioning stuff in master tree In-Reply-To: <1218492723.17089.0.camel@hopeson> References: <1218223890.20938.2.camel@hopeson> <489CA169.6050109@redhat.com> <1218229234.2991.20.camel@localhost.localdomain> <48A0A0D4.20601@redhat.com> <1218487216.2991.45.camel@localhost.localdomain> <48A0B0AE.3030503@redhat.com> <1218492723.17089.0.camel@hopeson> Message-ID: <1218494143.2991.50.camel@localhost.localdomain> On Mon, 2008-08-11 at 18:12 -0400, Simo Sorce wrote: > On Mon, 2008-08-11 at 17:35 -0400, Rob Crittenden wrote: > > Simo Sorce wrote: > > > On Mon, 2008-08-11 at 16:28 -0400, Rob Crittenden wrote: > > >> Simo Sorce wrote: > > >>> On Fri, 2008-08-08 at 15:41 -0400, Rob Crittenden wrote: > > >>>> Simo Sorce wrote: > > >>>>> Setting version numbers was a bit too much manual, and obviously got out > > >>>>> of sync. ipa-server and ipa-client configure were reporting version > > >>>>> 0.6.0 ... > > >>>>> > > >>>>> This patch fixes some of these spots and also allows for easier control > > >>>>> over RPMs versioning when using make local-dist > > >>>>> > > >>>>> Simo. > > >>>> Bleh, guess I missed a few on the first pass. > > >>> No problem :-) > > >>> > > >>>> I'm not sure I follow the logic of moving the dependency of > > >>>> version-update to clean/dist-clean. Can you elaborate? > > >>> It creates version.m4 > > >>> without it any call to autoconf will fail as configure.ac includes it > > >>> > > >>> Simo. > > >>> > > >> maintainer-clean doesn't clean up a bunch of files used in the versioning: > > >> > > >> # RELEASE > > >> # ipa-admintools/ipa-admintools.spec > > >> # ipa-client/version.m4 > > >> # ipa-radius-admintools/ipa-radius-admintools.spec > > >> # ipa-radius-server/ipa-radius-server.spec > > >> # ipa-server/selinux/ipa-server-selinux.spec > > >> # ipa-server/version.m4 > > >> > > >> I'd think we'd want to remove these, right? > > > > > > maybe but it didn't remove the .spec files before :-) > > > do you want me to add this clean up to this patch ? > > > or should we have a separate patch for that ? > > > > In my unpatched tree the only file getting left over after a > > maintainer-clean is ipa-server/selinux/ipa-server-selinux.spec. > > > > It can be a separate patch. > > No, I do not like regressions, here's an updated patch that fixes the > problem, will commit it as the change was trivial and I tested it works. pushed to master Simo. From ssorce at redhat.com Mon Aug 11 22:36:02 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 11 Aug 2008 22:36:02 +0000 Subject: [Freeipa-devel] [PATCH] Add encrypt_file and decrypt_file functions In-Reply-To: <489C942D.4090301@redhat.com> References: <1218140355.3548.2.camel@hopeson> <489B60BA.70709@redhat.com> <1218143787.2991.7.camel@localhost.localdomain> <1218148277.10857.1.camel@hopeson> <489C942D.4090301@redhat.com> Message-ID: <1218494162.2991.52.camel@localhost.localdomain> On Fri, 2008-08-08 at 14:45 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Thu, 2008-08-07 at 21:16 +0000, Simo Sorce wrote: > >> On Thu, 2008-08-07 at 16:53 -0400, Rob Crittenden wrote: > >>> Simo Sorce wrote: > >>>> See patch, these functions will be used in ipa-replica-prepare and > >>>> ipa-replica-install to make the data more safe. > >>>> > >>>> > >>>> > >>> Just a few minor things. > >>> > >>> You check that the password exists during encryption but not decryption. > >> ahh right > >> > >>> Should we do any validation that dest is ok? I suppose we'll find out > >>> soon enough from the call to run... > >> the operation would fail and we will get an exception, I wouldn't care > >> too much about that at this point. > >> > >> the caller will need to check for exceptions anyway and decide what to > >> do. > >> > >>> A cleaner way of handling a failure would use try/except/finally, though > >>> Python 2.4 makes it a little icky. It would look something like this > >>> for encrypt_file() > >>> > >>> try: > >>> try: > >>> os.mkdir(gpgdir) > >>> args = ... > >>> except: > >>> raise > >>> finally: > >>> #clean up > >>> shutil.rmtree(tempdir, ignore_errors=True) > >>> > >>> The way it is now is fine but the cleanup code (one line) is duplicated). > >> right, I will change the patch to use finally > > > > Attached a patch that implement this and also remove mentions of > > 'tarfile' that were unused as Rob pointed out on IRC. > > > > ack pushed to master Simo. From ssorce at redhat.com Mon Aug 11 22:36:49 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 11 Aug 2008 18:36:49 -0400 Subject: [Freeipa-devel] [PATCH] Use SystemRandom for better random passwords In-Reply-To: <48A09F16.60408@redhat.com> References: <1218116143.17304.1.camel@hopeson> <489C94B9.7050809@redhat.com> <1218224520.2991.19.camel@localhost.localdomain> <1218224523.21941.0.camel@hopeson> <48A09F16.60408@redhat.com> Message-ID: <1218494209.2991.54.camel@localhost.localdomain> On Mon, 2008-08-11 at 16:20 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Fri, 2008-08-08 at 15:42 -0400, Simo Sorce wrote: > >> On Fri, 2008-08-08 at 14:47 -0400, Rob Crittenden wrote: > >>> Simo Sorce wrote: > >>>> While reviewing some code I realized we could do a better job at > >>>> generating random password (and this was already implemented for one of > >>>> our functions). > >>>> The current code is *not* flawed, but using better methods is always a > >>>> good thing. > >>> ack but looks like you can remove the 'generator = > >>> random.SystemRandom()' as well. > >> arghh no, thanks for point this out because the bug is that the last > >> line should look like: > >> > >> + password += generator.choice(password_chars) > >> > >> and NOT > >> > >> + password += r.choice(password_chars) > >> > >> bloody copy&paste errors :-) > > > > New patch fixing this. > > > > Simo. > > ack Pushed to master Simo. -- Simo Sorce * Red Hat, Inc * New York From anmar at anmar.eu.org Tue Aug 12 06:39:04 2008 From: anmar at anmar.eu.org (Angel Marin) Date: Tue, 12 Aug 2008 08:39:04 +0200 Subject: [Freeipa-devel] freeIPA and NIS In-Reply-To: <48A04BF8.5070602@redhat.com> References: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> <489C3F7B.50604@redhat.com> <1218332054.7942.56.camel@shyster> <48A04BF8.5070602@redhat.com> Message-ID: <48A13008.4050705@anmar.eu.org> Dmitri, Dmitri Pal wrote: > Our plans for the AD integration are following: > a) We will release an AD synch tool later this year (most likely > November). Are there plans to support one time migrations from AD->freeIPA? We recently did one of those and it was a pain to recreate all the accounts, groups, memberships, ... + reset all user passwords as we couldn't get them out of AD. Anyway once in place freeIPA+pGina+OpenAFS are working great as an AD replacement (quirks aside) :) Regards, -- Angel Marin http://anmar.eu.org/ From mnagy at redhat.com Tue Aug 12 06:57:13 2008 From: mnagy at redhat.com (Martin Nagy) Date: Tue, 12 Aug 2008 08:57:13 +0200 Subject: [Freeipa-devel] [PATCH] Support password change operation by direct manipulation of userPassword In-Reply-To: <1218493026.17089.8.camel@hopeson> References: <1216822832.937.16.camel@hopeson> <1216912400.8999.45.camel@hopeson> <1218493026.17089.8.camel@hopeson> Message-ID: <48A13449.1050305@redhat.com> Simo Sorce wrote: > On Thu, 2008-07-24 at 11:13 -0400, Simo Sorce wrote: >> 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. > > Another revision, this one removes the requirement to have an ssl > connection to just ldapadd/ldapmodify the userPassword attribute. > This would be a change in behavior for DS and may cause problems to > existing applications. > > Simo. Simo, your patch uses spaces for intendation, whereas the file uses tabs. Martin From anmar at anmar.eu.org Tue Aug 12 09:43:14 2008 From: anmar at anmar.eu.org (Angel Marin) Date: Tue, 12 Aug 2008 11:43:14 +0200 Subject: [Freeipa-devel] freeIPA and NIS In-Reply-To: <20080812091957.GA28205@fluxcoil.net> References: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> <489C3F7B.50604@redhat.com> <1218332054.7942.56.camel@shyster> <48A04BF8.5070602@redhat.com> <48A13008.4050705@anmar.eu.org> <20080812091957.GA28205@fluxcoil.net> Message-ID: <48A15B32.9060705@anmar.eu.org> (sorry for the off-topic, but it might be of interest for people planning on moving to freeipa) Christian Horn wrote: > On Tue, Aug 12, 2008 at 08:39:04AM +0200, Angel Marin wrote: >> Anyway once in place freeIPA+pGina+OpenAFS are working great as an AD >> replacement (quirks aside) :) > > Nice to learn about pGina, just from glancing over the plugins i am > under the impression the windows-users are authenticated with pure ldap > in your place now, losing singlesignon that way? > Or did i miss something? We do auth through a home made pGina plugin that does kerberos auth and ensures openafs (roaming profiles and user dirs are in the afs cell) is ready; looking up user info in ldap, ensuring clock is in sync and enabling password change are in the works. Finally kfw and openafs integrated logon plugin takes care of actual tickets for user session so there's SSO*. We've had to patch pGina too as stock one was crashing on us. Once we've been able to polish all the quirks (currently sometimes users are randomly denied access to afs cell on first login) we'll release code and docs somewhere :) * Biggest issue with SSO is that it'll only work with apps capable of talking to kfw (firefox, thunderbird, openafs-client, ...), but that's not a problem around here. In theory with Vista clients kfw is capable of writing to system ccache (enabling SSO on IE and the like) but we haven't tried it here. -- Angel Marin http://anmar.eu.org/ From mnagy at redhat.com Tue Aug 12 10:28:38 2008 From: mnagy at redhat.com (Martin Nagy) Date: Tue, 12 Aug 2008 12:28:38 +0200 Subject: [Freeipa-devel] [PATCH] Encrypt replica file In-Reply-To: <1218229331.26284.2.camel@hopeson> References: <1218229331.26284.2.camel@hopeson> Message-ID: <48A165D6.10400@redhat.com> Simo Sorce wrote: > This patch encrypts the replica file so that even if the file is left > around it does not expose security relevant information. > > Unfortunately while testing I got an error down the patch after my patch > is concerned, setting up the replica fails with: > > [16/16]: configuring directory to start on boot > done configuring dirsrv. > creation of replica failed: {'info': 'Operation requires a secure > connection.\n', 'desc': 'Confidentiality required'} > > > I think this is unrelated to this patch but if you see anything that can > cause it let me know, this is why I am sending the patch for review even > if I could not successfully test a complete replication setup. > > Simo. Sorry that I didn't object sooner, but I'm strongly against adding the -p option: + parser.add_option("-p", "--password", dest="password", + help="Directory Manager (existing master) password") I know this is very convenient, but it is really insecure. Can we throw this option away? Martin From chorn at fluxcoil.net Tue Aug 12 10:40:51 2008 From: chorn at fluxcoil.net (Christian Horn) Date: Tue, 12 Aug 2008 12:40:51 +0200 Subject: [Freeipa-devel] freeIPA and NIS In-Reply-To: <48A15B32.9060705@anmar.eu.org> References: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> <489C3F7B.50604@redhat.com> <1218332054.7942.56.camel@shyster> <48A04BF8.5070602@redhat.com> <48A13008.4050705@anmar.eu.org> <20080812091957.GA28205@fluxcoil.net> <48A15B32.9060705@anmar.eu.org> Message-ID: <20080812104051.GA28357@fluxcoil.net> On Tue, Aug 12, 2008 at 11:43:14AM +0200, Angel Marin wrote: > (sorry for the off-topic, but it might be of interest for people > planning on moving to freeipa) Seeing what you implemented i guess it fits to @freeipa :) > We do auth through a home made pGina plugin that does kerberos auth and > ensures openafs (roaming profiles and user dirs are in the afs cell) is > ready; looking up user info in ldap, ensuring clock is in sync and > enabling password change are in the works. Finally kfw and openafs > integrated logon plugin takes care of actual tickets for user session so > there's SSO*. > > We've had to patch pGina too as stock one was crashing on us. Once we've > been able to polish all the quirks (currently sometimes users are > randomly denied access to afs cell on first login) we'll release code > and docs somewhere :) Great. > * Biggest issue with SSO is that it'll only work with apps capable of > talking to kfw (firefox, thunderbird, openafs-client, ...), but that's > not a problem around here. In theory with Vista clients kfw is capable > of writing to system ccache (enabling SSO on IE and the like) but we > haven't tried it here. I did look into running an AD-domain and having it crosstrusting the kerberosrealm, corporations do not lose the microsoft-support that way (what if $stuff happens!) and authentication also from IE works, see http://fluxcoil.net/files/sso_crossrealm_kerberos.htm . Having no AD server around like in your solution ofcourse feels much more convienient. Samba4 should be able to play that role in future. Christian From email.ahmedkamal at googlemail.com Tue Aug 12 10:51:15 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Tue, 12 Aug 2008 13:51:15 +0300 Subject: [Freeipa-devel] freeIPA and NIS In-Reply-To: <20080812104051.GA28357@fluxcoil.net> References: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> <489C3F7B.50604@redhat.com> <1218332054.7942.56.camel@shyster> <48A04BF8.5070602@redhat.com> <48A13008.4050705@anmar.eu.org> <20080812091957.GA28205@fluxcoil.net> <48A15B32.9060705@anmar.eu.org> <20080812104051.GA28357@fluxcoil.net> Message-ID: <3da3b5b40808120351xd9b65b0obfd4e6104c076671@mail.gmail.com> I played with pGina before, it was great, but the only limitation I faced was that Windows does not "see" other users and groups. Logged in users are created to be "local" users, which means one can't created shared folders, and apply permissions and such. Is this resolved by using open-afs (I've never touched that) ? If so, that would really rock! I'd even prefer that to a samba4 solution! On Tue, Aug 12, 2008 at 1:40 PM, Christian Horn wrote: > On Tue, Aug 12, 2008 at 11:43:14AM +0200, Angel Marin wrote: > > (sorry for the off-topic, but it might be of interest for people > > planning on moving to freeipa) > > Seeing what you implemented i guess it fits to @freeipa :) > > > > We do auth through a home made pGina plugin that does kerberos auth and > > ensures openafs (roaming profiles and user dirs are in the afs cell) is > > ready; looking up user info in ldap, ensuring clock is in sync and > > enabling password change are in the works. Finally kfw and openafs > > integrated logon plugin takes care of actual tickets for user session so > > there's SSO*. > > > > We've had to patch pGina too as stock one was crashing on us. Once we've > > been able to polish all the quirks (currently sometimes users are > > randomly denied access to afs cell on first login) we'll release code > > and docs somewhere :) > > Great. > > > > * Biggest issue with SSO is that it'll only work with apps capable of > > talking to kfw (firefox, thunderbird, openafs-client, ...), but that's > > not a problem around here. In theory with Vista clients kfw is capable > > of writing to system ccache (enabling SSO on IE and the like) but we > > haven't tried it here. > > I did look into running an AD-domain and having it crosstrusting the > kerberosrealm, corporations do not lose the microsoft-support that way > (what if $stuff happens!) and authentication also from IE works, see > http://fluxcoil.net/files/sso_crossrealm_kerberos.htm . > Having no AD server around like in your solution ofcourse feels > much more convienient. > Samba4 should be able to play that role in future. > > > Christian > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anmar at anmar.eu.org Tue Aug 12 11:44:50 2008 From: anmar at anmar.eu.org (Angel Marin) Date: Tue, 12 Aug 2008 13:44:50 +0200 Subject: [Freeipa-devel] freeIPA and NIS In-Reply-To: <20080812104051.GA28357@fluxcoil.net> References: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> <489C3F7B.50604@redhat.com> <1218332054.7942.56.camel@shyster> <48A04BF8.5070602@redhat.com> <48A13008.4050705@anmar.eu.org> <20080812091957.GA28205@fluxcoil.net> <48A15B32.9060705@anmar.eu.org> <20080812104051.GA28357@fluxcoil.net> Message-ID: <48A177B2.70701@anmar.eu.org> Christian Horn wrote: > On Tue, Aug 12, 2008 at 11:43:14AM +0200, Angel Marin wrote: >> * Biggest issue with SSO is that it'll only work with apps capable of >> talking to kfw (firefox, thunderbird, openafs-client, ...), but that's >> not a problem around here. In theory with Vista clients kfw is capable >> of writing to system ccache (enabling SSO on IE and the like) but we >> haven't tried it here. > > I did look into running an AD-domain and having it crosstrusting the > kerberosrealm, corporations do not lose the microsoft-support that way > (what if $stuff happens!) and authentication also from IE works, see > http://fluxcoil.net/files/sso_crossrealm_kerberos.htm . > Having no AD server around like in your solution ofcourse feels > much more convienient. > Samba4 should be able to play that role in future. We evaluated a cross-realm scenario, but though it was 'easier' to not remove AD, in our case being able to decommission the hardware of the aging AD deployment was part of the motivation to take the freeipa route :) Now we have each of the components lying in xen guests that can easily be upgraded/cloned/replaced/moved around. While at it, it would be great if freeipa scripts allowed to install each of the components (kdc, ldap server, web UI) independently in different hosts :) -- Angel Marin http://anmar.eu.org/ From anmar at anmar.eu.org Tue Aug 12 11:50:57 2008 From: anmar at anmar.eu.org (Angel Marin) Date: Tue, 12 Aug 2008 13:50:57 +0200 Subject: [Freeipa-devel] freeIPA and NIS In-Reply-To: <3da3b5b40808120351xd9b65b0obfd4e6104c076671@mail.gmail.com> References: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> <489C3F7B.50604@redhat.com> <1218332054.7942.56.camel@shyster> <48A04BF8.5070602@redhat.com> <48A13008.4050705@anmar.eu.org> <20080812091957.GA28205@fluxcoil.net> <48A15B32.9060705@anmar.eu.org> <20080812104051.GA28357@fluxcoil.net> <3da3b5b40808120351xd9b65b0obfd4e6104c076671@mail.gmail.com> Message-ID: <48A17921.5040000@anmar.eu.org> We sync freeipa groups with openafs groups and memberships (simple script) so permissions are managed as a regular openafs thing. openafs client honors those perms just fine based on the logged in principal. So 'local' users are only used for the workstation login, no need to use windows groups for anything :) They still can't create local shared folders in the regular way, but if everything is in the afs cell, every user can have folders with access granted to whoever they (or you) want. It's just a training problem :) In the broad sense it feel like a more convoluted setup, but it's order of magnitude nicer/easier to have linux home dirs on the same file servers as the windows ones while everyone is authenticating to a single freeipa realm :) Having the flexibility & network caching performance of openafs gives great value for remote & home offices setups too; but YMMV :) Considering Samba4 ships with it's own ldap-server implementation and doesn't work with a regular MIT kdc AFAIK, I'm not sure it would be cleaner in any way ;) Ahmed Kamal wrote: > I played with pGina before, it was great, but the only limitation I > faced was that Windows does not "see" other users and groups. Logged in > users are created to be "local" users, which means one can't created > shared folders, and apply permissions and such. Is this resolved by > using open-afs (I've never touched that) ? If so, that would really > rock! I'd even prefer that to a samba4 solution! > > On Tue, Aug 12, 2008 at 1:40 PM, Christian Horn > wrote: > > On Tue, Aug 12, 2008 at 11:43:14AM +0200, Angel Marin wrote: > > (sorry for the off-topic, but it might be of interest for people > > planning on moving to freeipa) > > Seeing what you implemented i guess it fits to @freeipa :) > > > > We do auth through a home made pGina plugin that does kerberos > auth and > > ensures openafs (roaming profiles and user dirs are in the afs > cell) is > > ready; looking up user info in ldap, ensuring clock is in sync and > > enabling password change are in the works. Finally kfw and openafs > > integrated logon plugin takes care of actual tickets for user > session so > > there's SSO*. > > > > We've had to patch pGina too as stock one was crashing on us. > Once we've > > been able to polish all the quirks (currently sometimes users are > > randomly denied access to afs cell on first login) we'll release code > > and docs somewhere :) > > Great. > > > > * Biggest issue with SSO is that it'll only work with apps capable of > > talking to kfw (firefox, thunderbird, openafs-client, ...), but > that's > > not a problem around here. In theory with Vista clients kfw is > capable > > of writing to system ccache (enabling SSO on IE and the like) but we > > haven't tried it here. > > I did look into running an AD-domain and having it crosstrusting the > kerberosrealm, corporations do not lose the microsoft-support that way > (what if $stuff happens!) and authentication also from IE works, see > http://fluxcoil.net/files/sso_crossrealm_kerberos.htm . > Having no AD server around like in your solution ofcourse feels > much more convienient. > Samba4 should be able to play that role in future. > > > Christian > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Angel Marin http://anmar.eu.org/ From email.ahmedkamal at googlemail.com Tue Aug 12 11:55:45 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Tue, 12 Aug 2008 14:55:45 +0300 Subject: [Freeipa-devel] freeIPA and NIS In-Reply-To: <48A17921.5040000@anmar.eu.org> References: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> <489C3F7B.50604@redhat.com> <1218332054.7942.56.camel@shyster> <48A04BF8.5070602@redhat.com> <48A13008.4050705@anmar.eu.org> <20080812091957.GA28205@fluxcoil.net> <48A15B32.9060705@anmar.eu.org> <20080812104051.GA28357@fluxcoil.net> <3da3b5b40808120351xd9b65b0obfd4e6104c076671@mail.gmail.com> <48A17921.5040000@anmar.eu.org> Message-ID: <3da3b5b40808120455s34836310q2eda39a2df204aa8@mail.gmail.com> I'm not so sure the final samba4 will still ship with their own kdc, I think I heard otherwise. But this setup of yours if surely interesting! It's great that you're finding AFS of production quality Regards On Tue, Aug 12, 2008 at 2:50 PM, Angel Marin wrote: > We sync freeipa groups with openafs groups and memberships (simple script) > so permissions are managed as a regular openafs thing. openafs client honors > those perms just fine based on the logged in principal. So 'local' users are > only used for the workstation login, no need to use windows groups for > anything :) > > They still can't create local shared folders in the regular way, but if > everything is in the afs cell, every user can have folders with access > granted to whoever they (or you) want. It's just a training problem :) > > In the broad sense it feel like a more convoluted setup, but it's order of > magnitude nicer/easier to have linux home dirs on the same file servers as > the windows ones while everyone is authenticating to a single freeipa realm > :) Having the flexibility & network caching performance of openafs gives > great value for remote & home offices setups too; but YMMV :) > > Considering Samba4 ships with it's own ldap-server implementation and > doesn't work with a regular MIT kdc AFAIK, I'm not sure it would be cleaner > in any way ;) > > Ahmed Kamal wrote: > >> I played with pGina before, it was great, but the only limitation I faced >> was that Windows does not "see" other users and groups. Logged in users are >> created to be "local" users, which means one can't created shared folders, >> and apply permissions and such. Is this resolved by using open-afs (I've >> never touched that) ? If so, that would really rock! I'd even prefer that to >> a samba4 solution! >> >> On Tue, Aug 12, 2008 at 1:40 PM, Christian Horn > chorn at fluxcoil.net>> wrote: >> >> On Tue, Aug 12, 2008 at 11:43:14AM +0200, Angel Marin wrote: >> > (sorry for the off-topic, but it might be of interest for people >> > planning on moving to freeipa) >> >> Seeing what you implemented i guess it fits to @freeipa :) >> >> >> > We do auth through a home made pGina plugin that does kerberos >> auth and >> > ensures openafs (roaming profiles and user dirs are in the afs >> cell) is >> > ready; looking up user info in ldap, ensuring clock is in sync and >> > enabling password change are in the works. Finally kfw and openafs >> > integrated logon plugin takes care of actual tickets for user >> session so >> > there's SSO*. >> > >> > We've had to patch pGina too as stock one was crashing on us. >> Once we've >> > been able to polish all the quirks (currently sometimes users are >> > randomly denied access to afs cell on first login) we'll release >> code >> > and docs somewhere :) >> >> Great. >> >> >> > * Biggest issue with SSO is that it'll only work with apps capable >> of >> > talking to kfw (firefox, thunderbird, openafs-client, ...), but >> that's >> > not a problem around here. In theory with Vista clients kfw is >> capable >> > of writing to system ccache (enabling SSO on IE and the like) but we >> > haven't tried it here. >> >> I did look into running an AD-domain and having it crosstrusting the >> kerberosrealm, corporations do not lose the microsoft-support that way >> (what if $stuff happens!) and authentication also from IE works, see >> http://fluxcoil.net/files/sso_crossrealm_kerberos.htm . >> Having no AD server around like in your solution ofcourse feels >> much more convienient. >> Samba4 should be able to play that role in future. >> >> >> Christian >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> > > -- > Angel Marin > http://anmar.eu.org/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnagy at redhat.com Tue Aug 12 12:59:18 2008 From: mnagy at redhat.com (Martin Nagy) Date: Tue, 12 Aug 2008 14:59:18 +0200 Subject: [Freeipa-devel] [PATCH] Delete old mercurial files Message-ID: <48A18926.7030100@redhat.com> A non-text attachment was scrubbed... Name: 0001-Delete-old-mercurial-files.patch Type: application/mbox Size: 2082 bytes Desc: not available URL: From sgallagh at redhat.com Tue Aug 12 13:10:14 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Tue, 12 Aug 2008 09:10:14 -0400 Subject: [Freeipa-devel] [PATCH] fix replica-install to use SSL connections early on In-Reply-To: <1218492879.17089.4.camel@hopeson> References: <1218492879.17089.4.camel@hopeson> Message-ID: <48A18BB6.60006@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simo Sorce wrote: > This patch install the ca.crt file early on and enforce the use of SSL > to set up the replication agreement. > > > ------------------------------------------------------------------------ I don't like the use of the hard-coded CACERT variable. We're trying to eliminate the use of hard-coded paths. See Bugzilla #430000 for more details. I also don't understand why you removed the try/except block around the LDAP bind in replication.py. What exactly did that gain us? - -- - -------------------- Stephen Gallagher RHCE 804006346421761 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkihi7YACgkQc7MaxVic+2oGtwCdH34pqpZgvZ7O4MpDwO0KhBZ+ dAYAoKQWxWdqCPdwpCKyKNCQ3bjSnZBO =kaJL -----END PGP SIGNATURE----- From dpal at redhat.com Tue Aug 12 13:15:50 2008 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 12 Aug 2008 09:15:50 -0400 Subject: [Freeipa-devel] freeIPA and NIS In-Reply-To: <3da3b5b40808110945w6f025fd5te4838ef57d601b15@mail.gmail.com> References: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> <489C3F7B.50604@redhat.com> <1218332054.7942.56.camel@shyster> <48A04BF8.5070602@redhat.com> <3da3b5b40808110945w6f025fd5te4838ef57d601b15@mail.gmail.com> Message-ID: <48A18D06.6030003@redhat.com> Ahmed Kamal wrote: > Thanks Dmitri for the very informative reply. I am planning on buying > RHEIPA soon, I will probably use it in testing mode and let like 30 > users play on it. After it has proved successful for us, is it > possible to "link" the 30 user accounts from freeIPA to the same > people's AD accounts (without deleting and re-creating all accounts) ? > I hope the users would retain their UIDs so nothing breaks Yes. The user entries coming from AD will "take over" control of the already existing entries in IPA. So there will be no need to delete and re-create them. > > Thanks > > On Mon, Aug 11, 2008 at 5:26 PM, Dmitri Pal > wrote: > > Colin, > > Our plans for the AD integration are following: > a) We will release an AD synch tool later this year (most likely > November). Since the freeIPA versions and Red Hat Enterprise > versions are a bit out of synch I can't say exactly which freeIPA > version it would be but 1.x for sure. It will be 1.1 for RHEIPA. > The feature will deliver: > 1) If user account is created in AD it is synchronized to IPA. > 2) If user account is created in IPA it is NOT synchronized to AD > 3) The changes to an account once created in AD and synchronized > to IPA are synchronized in both directions. > 4) The passwords for accounts mentioned in 3) are also > synchronized in both directions but require installation of the > password filter component on every DC. > b) In freeIPA v2 we plan to offer trust between IPA and AD. This > will probably ease some pain but to what extent it is hard to say > at the moment. > Yes we use DNS for the name resolution and IPA v2 will be even > more integrated with DNS. There will be an option to use an > already existing DNS instead of the one that would come with IPA > but zoning is the preferred method. One of the features of the v2 > is the capability of the clients to update their DNS information. > The DNS back end will be integrated with IPA's DS and kerberos > auth will be used to make sure the update is legitimate. > c) Samba 4 and Penrose are other technologies that we seriously > consider as solutions for the better AD integration down the road. > It is unclear what shape and form this solution would take. It is > unlikely that anything more than options a) and b) will be > available soon. Tighter integration via Samba 4 is on our radar > for v3 but may be Penrose based solution would come out earlier > than that. > > From the use case you described it seems that Samba 4 will work > fine for the Windows machines you have in your company. It most > likely will be accepted as a domain (represented by Samba 4) by > your parent company. IPA will be used for Linux/Unix machines and > user accounts on those machines. There you will have an option of > a) and b) and probably Penrose based solution. Having and > integrated Samba 4 + IPA realm that can deal with both Windows and > Linux/Unix might not be the best choice. We are working on such > integration option but as I mentioned it is down the road in v3 > time frame. > > I hope I did not miss anything. > > Thank you > Dmitri > > > Colin Simpson wrote: > > On Fri, 2008-08-08 at 08:43 -0400, Rob Crittenden wrote: > > > > -FreeIPA2 should be out fairly soon, is there a final > word on how the Windows integration is going to look > like (particularly if there's no AD) ? > > > We are still working on this piece. The first step is > going to be some limited syncing of users and passwords, > later adding a more robust solution. > > If you have any specific needs please let us know. This > can be very complex as some people want to only sync > certain parts of their tree, only in one direction, etc. > So the more requirements we gather the better the first > release will be. > > thanks > > rob > > > > I'm interested in your AD integration plans. > > We are a heavy RH Linux users but our parent is a big AD user > (and we > use AD on the Windows side). Our present Linux directory is a > hand built > OpenLDAP/MIT Kerberos solution, pretty much what IPA was > designed to > replace. We have at present password syncing via a couple of > tools. > Maybe we're pretty typical. > > In the future (hopefully near future) we'd like to have a much > more > integrated solution. We are looking at either Enterprise IPA > or Samba 4 > (saying that whenever that appears!) > > Features we'd look for: > > 1. True single sign on. If you say, log into a windows box and > SSH into > Linux you shouldn't be asked for a password and vice-versa if > you say > got to a Windows Sharepoint site in Firefox on Linux you > should again > not be asked for a password. > Now I know this can be achieved already by a cross realm > trust, but it's > a bit of hassle to setup (IPA might help here by hiding some > of the > pain). One downside I have seen of this is that the Kerberos realm > appears in the Windows drop down domains list on the login > screen. We'd > not really want Windows users logging into that for various > reasons. Not > sure if it's possible to hide a domain(realm) in windows from that > dialog if it's trusted. > Also with this approach telling windows AD that one user on a > realm is > equivalent to a user on another realm is a hassle to setup > (again an IPA > opportunity to ease the pain). > And also, does the IPA's use of DNS to find directory servers > interfere > with AD's (i.e do they use the same mechanism/name spaces). > I'd rather > not maintain my Windows and Linux boxes in separate DNS zones > just to > keep various directory services happy (it makes DHCP with > Dynamic DNS a > non starter). > 2. Support auto adding of Linux accounts when AD accounts are > added > would be nice, maybe based on a template of some kind, for > things like > automount points of home directories). > Probably pulling in the Unix attributes from AD if that schema > is loaded > in AD, would be a nice feature. > 3. Naturally, of course password syncing. > 4. How will IPA support Samba servers? Just now we join Samba > to AD and > use a second krb5.conf file (with all the AD stuff in) that > only samba > uses (giving clean passwordless access to Samba shares for Windows > users). > > My view of IPA vs potentially a Samba 4 solution would be: > > Samba 4 > ======= > No Cross Realm trust issues - As in it would issue krb tickets > that were > just tickets valid in AD. > > No separate management of a Linux directory. Having an AD > account would > automatically give you a Linux account. > Can have windows systems authenticate safely to a Samba 4 server. > > IPA > === > Better Linux targeting - Management of policies and patches. > > No hoops to jump through to support *ix features e.g > automount maps > Kerberos Service (host, NFS) keys etc. > Easier client configuration > > Good vendor support and IPA is here now. > > > Or is there no choice here and IPA will be able to pull in all > Samba 4 > features. > Have I missed anything or just given you job security for life... > > Thanks > Colin > > This email and any files transmitted with it are confidential > and are intended solely for the use of the individual or > entity to whom they are addressed. If you are not the > original recipient or the person responsible for delivering > the email to the intended recipient, be advised that you have > received this email in error, and that any use, dissemination, > forwarding, printing, or copying of this email is strictly > prohibited. If you received this email in error, please > immediately notify the sender and delete the original. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > > -- > Dmitri Pal > Engineering Manager > Red Hat Inc. > _______________________________________________ > 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 dpal at redhat.com Tue Aug 12 13:24:53 2008 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 12 Aug 2008 09:24:53 -0400 Subject: [Freeipa-devel] freeIPA and NIS In-Reply-To: <48A13008.4050705@anmar.eu.org> References: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> <489C3F7B.50604@redhat.com> <1218332054.7942.56.camel@shyster> <48A04BF8.5070602@redhat.com> <48A13008.4050705@anmar.eu.org> Message-ID: <48A18F25.2050703@redhat.com> Matin, It is great to hear the story of migration from AD to IPA! We realize that this would be painful as probably any other migration. Looking at the migration use cases we plan to focus on NIS migration and DS migration in v2. AD migration would be something for v3. We would also consider tighter integration with Samba 4 so you would not need to install pGina on all Windows machines. So the short answer - "Yes but down the road". Thanks Dmitri Angel Marin wrote: > Dmitri, > > Dmitri Pal wrote: >> Our plans for the AD integration are following: >> a) We will release an AD synch tool later this year (most likely >> November). > > Are there plans to support one time migrations from AD->freeIPA? We > recently did one of those and it was a pain to recreate all the > accounts, groups, memberships, ... + reset all user passwords as we > couldn't get them out of AD. > > Anyway once in place freeIPA+pGina+OpenAFS are working great as an AD > replacement (quirks aside) :) > > Regards, -- Dmitri Pal Engineering Manager Red Hat Inc. From email.ahmedkamal at googlemail.com Tue Aug 12 13:39:33 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Tue, 12 Aug 2008 16:39:33 +0300 Subject: [Freeipa-devel] freeIPA and NIS In-Reply-To: <48A18D06.6030003@redhat.com> References: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> <489C3F7B.50604@redhat.com> <1218332054.7942.56.camel@shyster> <48A04BF8.5070602@redhat.com> <3da3b5b40808110945w6f025fd5te4838ef57d601b15@mail.gmail.com> <48A18D06.6030003@redhat.com> Message-ID: <3da3b5b40808120639w7c80ba38hae3edb21bbaca910@mail.gmail.com> How would IPA know which accounts on AD to sync over to IPA? Do they need to share the same username ? anything else ? Also, does RHEIPA bundle DirectoryServer, or do I need to buy/install/configure that separately ? Thanks On Tue, Aug 12, 2008 at 4:15 PM, Dmitri Pal wrote: > Ahmed Kamal wrote: > >> Thanks Dmitri for the very informative reply. I am planning on buying >> RHEIPA soon, I will probably use it in testing mode and let like 30 users >> play on it. After it has proved successful for us, is it possible to "link" >> the 30 user accounts from freeIPA to the same people's AD accounts (without >> deleting and re-creating all accounts) ? I hope the users would retain their >> UIDs so nothing breaks >> > > Yes. The user entries coming from AD will "take over" control of the > already existing entries in IPA. So there will be no need to delete and > re-create them. > > >> Thanks >> >> >> On Mon, Aug 11, 2008 at 5:26 PM, Dmitri Pal > dpal at redhat.com>> wrote: >> >> Colin, >> >> Our plans for the AD integration are following: >> a) We will release an AD synch tool later this year (most likely >> November). Since the freeIPA versions and Red Hat Enterprise >> versions are a bit out of synch I can't say exactly which freeIPA >> version it would be but 1.x for sure. It will be 1.1 for RHEIPA. >> The feature will deliver: >> 1) If user account is created in AD it is synchronized to IPA. >> 2) If user account is created in IPA it is NOT synchronized to AD >> 3) The changes to an account once created in AD and synchronized >> to IPA are synchronized in both directions. >> 4) The passwords for accounts mentioned in 3) are also >> synchronized in both directions but require installation of the >> password filter component on every DC. >> b) In freeIPA v2 we plan to offer trust between IPA and AD. This >> will probably ease some pain but to what extent it is hard to say >> at the moment. >> Yes we use DNS for the name resolution and IPA v2 will be even >> more integrated with DNS. There will be an option to use an >> already existing DNS instead of the one that would come with IPA >> but zoning is the preferred method. One of the features of the v2 >> is the capability of the clients to update their DNS information. >> The DNS back end will be integrated with IPA's DS and kerberos >> auth will be used to make sure the update is legitimate. >> c) Samba 4 and Penrose are other technologies that we seriously >> consider as solutions for the better AD integration down the road. >> It is unclear what shape and form this solution would take. It is >> unlikely that anything more than options a) and b) will be >> available soon. Tighter integration via Samba 4 is on our radar >> for v3 but may be Penrose based solution would come out earlier >> than that. >> >> From the use case you described it seems that Samba 4 will work >> fine for the Windows machines you have in your company. It most >> likely will be accepted as a domain (represented by Samba 4) by >> your parent company. IPA will be used for Linux/Unix machines and >> user accounts on those machines. There you will have an option of >> a) and b) and probably Penrose based solution. Having and >> integrated Samba 4 + IPA realm that can deal with both Windows and >> Linux/Unix might not be the best choice. We are working on such >> integration option but as I mentioned it is down the road in v3 >> time frame. >> >> I hope I did not miss anything. >> >> Thank you >> Dmitri >> >> >> Colin Simpson wrote: >> >> On Fri, 2008-08-08 at 08:43 -0400, Rob Crittenden wrote: >> >> >> -FreeIPA2 should be out fairly soon, is there a final >> word on how the Windows integration is going to look >> like (particularly if there's no AD) ? >> >> We are still working on this piece. The first step is >> going to be some limited syncing of users and passwords, >> later adding a more robust solution. >> >> If you have any specific needs please let us know. This >> can be very complex as some people want to only sync >> certain parts of their tree, only in one direction, etc. >> So the more requirements we gather the better the first >> release will be. >> >> thanks >> >> rob >> >> >> I'm interested in your AD integration plans. >> >> We are a heavy RH Linux users but our parent is a big AD user >> (and we >> use AD on the Windows side). Our present Linux directory is a >> hand built >> OpenLDAP/MIT Kerberos solution, pretty much what IPA was >> designed to >> replace. We have at present password syncing via a couple of >> tools. >> Maybe we're pretty typical. >> >> In the future (hopefully near future) we'd like to have a much >> more >> integrated solution. We are looking at either Enterprise IPA >> or Samba 4 >> (saying that whenever that appears!) >> >> Features we'd look for: >> >> 1. True single sign on. If you say, log into a windows box and >> SSH into >> Linux you shouldn't be asked for a password and vice-versa if >> you say >> got to a Windows Sharepoint site in Firefox on Linux you >> should again >> not be asked for a password. >> Now I know this can be achieved already by a cross realm >> trust, but it's >> a bit of hassle to setup (IPA might help here by hiding some >> of the >> pain). One downside I have seen of this is that the Kerberos realm >> appears in the Windows drop down domains list on the login >> screen. We'd >> not really want Windows users logging into that for various >> reasons. Not >> sure if it's possible to hide a domain(realm) in windows from that >> dialog if it's trusted. >> Also with this approach telling windows AD that one user on a >> realm is >> equivalent to a user on another realm is a hassle to setup >> (again an IPA >> opportunity to ease the pain). >> And also, does the IPA's use of DNS to find directory servers >> interfere >> with AD's (i.e do they use the same mechanism/name spaces). >> I'd rather >> not maintain my Windows and Linux boxes in separate DNS zones >> just to >> keep various directory services happy (it makes DHCP with >> Dynamic DNS a >> non starter). >> 2. Support auto adding of Linux accounts when AD accounts are >> added >> would be nice, maybe based on a template of some kind, for >> things like >> automount points of home directories). >> Probably pulling in the Unix attributes from AD if that schema >> is loaded >> in AD, would be a nice feature. >> 3. Naturally, of course password syncing. >> 4. How will IPA support Samba servers? Just now we join Samba >> to AD and >> use a second krb5.conf file (with all the AD stuff in) that >> only samba >> uses (giving clean passwordless access to Samba shares for Windows >> users). >> >> My view of IPA vs potentially a Samba 4 solution would be: >> >> Samba 4 >> ======= >> No Cross Realm trust issues - As in it would issue krb tickets >> that were >> just tickets valid in AD. >> >> No separate management of a Linux directory. Having an AD >> account would >> automatically give you a Linux account. >> Can have windows systems authenticate safely to a Samba 4 server. >> >> IPA >> === >> Better Linux targeting - Management of policies and patches. >> >> No hoops to jump through to support *ix features e.g >> automount maps >> Kerberos Service (host, NFS) keys etc. >> Easier client configuration >> >> Good vendor support and IPA is here now. >> >> >> Or is there no choice here and IPA will be able to pull in all >> Samba 4 >> features. >> Have I missed anything or just given you job security for life... >> >> Thanks >> Colin >> >> This email and any files transmitted with it are confidential >> and are intended solely for the use of the individual or >> entity to whom they are addressed. If you are not the >> original recipient or the person responsible for delivering >> the email to the intended recipient, be advised that you have >> received this email in error, and that any use, dissemination, >> forwarding, printing, or copying of this email is strictly >> prohibited. If you received this email in error, please >> immediately notify the sender and delete the original. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> >> -- Dmitri Pal >> Engineering Manager >> Red Hat Inc. >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> > > -- > Dmitri Pal > Engineering Manager > Red Hat Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnagy at redhat.com Tue Aug 12 13:16:09 2008 From: mnagy at redhat.com (Martin Nagy) Date: Tue, 12 Aug 2008 15:16:09 +0200 Subject: [Freeipa-devel] [PATCH] fix replica-install to use SSL connections early on In-Reply-To: <48A18BB6.60006@redhat.com> References: <1218492879.17089.4.camel@hopeson> <48A18BB6.60006@redhat.com> Message-ID: <48A18D19.1070604@redhat.com> Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Simo Sorce wrote: >> This patch install the ca.crt file early on and enforce the use of SSL >> to set up the replication agreement. >> >> >> ------------------------------------------------------------------------ > > I don't like the use of the hard-coded CACERT variable. We're trying to > eliminate the use of hard-coded paths. See Bugzilla #430000 for more > details. No worries about that. I have a list of the hard-coded paths and am maintaining it, watching every commit. This is just for a short time, I'm planning to address the bug soon. Martin From ssorce at redhat.com Tue Aug 12 13:41:02 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 12 Aug 2008 09:41:02 -0400 Subject: [Freeipa-devel] [PATCH] Support password change operation by direct manipulation of userPassword In-Reply-To: <48A13449.1050305@redhat.com> References: <1216822832.937.16.camel@hopeson> <1216912400.8999.45.camel@hopeson> <1218493026.17089.8.camel@hopeson> <48A13449.1050305@redhat.com> Message-ID: <1218548462.2991.58.camel@localhost.localdomain> On Tue, 2008-08-12 at 08:57 +0200, Martin Nagy wrote: > Simo Sorce wrote: > > On Thu, 2008-07-24 at 11:13 -0400, Simo Sorce wrote: > >> 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. > > > > Another revision, this one removes the requirement to have an ssl > > connection to just ldapadd/ldapmodify the userPassword attribute. > > This would be a change in behavior for DS and may cause problems to > > existing applications. > > > > Simo. > > Simo, your patch uses spaces for intendation, whereas the file uses tabs. It was intentional. Given these are new functions I switched to use the official coding style as per: http://freeipa.org/page/Coding_Style I intend to slowly convert the rest of the file piece by piece. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Aug 12 13:44:37 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 12 Aug 2008 09:44:37 -0400 Subject: [Freeipa-devel] [PATCH] Encrypt replica file In-Reply-To: <48A165D6.10400@redhat.com> References: <1218229331.26284.2.camel@hopeson> <48A165D6.10400@redhat.com> Message-ID: <1218548677.2991.61.camel@localhost.localdomain> On Tue, 2008-08-12 at 12:28 +0200, Martin Nagy wrote: > Simo Sorce wrote: > > This patch encrypts the replica file so that even if the file is left > > around it does not expose security relevant information. > > > > Unfortunately while testing I got an error down the patch after my patch > > is concerned, setting up the replica fails with: > > > > [16/16]: configuring directory to start on boot > > done configuring dirsrv. > > creation of replica failed: {'info': 'Operation requires a secure > > connection.\n', 'desc': 'Confidentiality required'} > > > > > > I think this is unrelated to this patch but if you see anything that can > > cause it let me know, this is why I am sending the patch for review even > > if I could not successfully test a complete replication setup. > > > > Simo. > > Sorry that I didn't object sooner, but I'm strongly against adding the > -p option: > + parser.add_option("-p", "--password", dest="password", > + help="Directory Manager (existing master) password") > > I know this is very convenient, but it is really insecure. Can we throw > this option away? You can propose a later patch that replaces it with another way to pipe in the password (file, stdin, etc...) For now I'd like to keep it, unless another method for non-interactive installations is provided. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Aug 12 13:47:02 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 12 Aug 2008 13:47:02 +0000 Subject: [Freeipa-devel] [PATCH] fix replica-install to use SSL connections early on In-Reply-To: <48A18BB6.60006@redhat.com> References: <1218492879.17089.4.camel@hopeson> <48A18BB6.60006@redhat.com> Message-ID: <1218548822.2991.64.camel@localhost.localdomain> On Tue, 2008-08-12 at 09:10 -0400, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Simo Sorce wrote: > > This patch install the ca.crt file early on and enforce the use of SSL > > to set up the replication agreement. > > > > > > ------------------------------------------------------------------------ > > I don't like the use of the hard-coded CACERT variable. We're trying to > eliminate the use of hard-coded paths. See Bugzilla #430000 for more > details. Martin will provide a genarl solution to this problem soon. I leave it to him. > I also don't understand why you removed the try/except block around the > LDAP bind in replication.py. What exactly did that gain us? return None was useless (tested), by removing the try/except we allow the error to be raised to the caller (all callers correctly intercept these errors). Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Aug 12 13:56:20 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 12 Aug 2008 13:56:20 +0000 Subject: [Freeipa-devel] freeIPA and NIS In-Reply-To: <48A15B32.9060705@anmar.eu.org> References: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> <489C3F7B.50604@redhat.com> <1218332054.7942.56.camel@shyster> <48A04BF8.5070602@redhat.com> <48A13008.4050705@anmar.eu.org> <20080812091957.GA28205@fluxcoil.net> <48A15B32.9060705@anmar.eu.org> Message-ID: <1218549380.2991.67.camel@localhost.localdomain> On Tue, 2008-08-12 at 11:43 +0200, Angel Marin wrote: > (sorry for the off-topic, but it might be of interest for people > planning on moving to freeipa) Not off topic at all, although maybe freeipa-interest might also be a good place for good user experiences :) > Christian Horn wrote: > > On Tue, Aug 12, 2008 at 08:39:04AM +0200, Angel Marin wrote: > >> Anyway once in place freeIPA+pGina+OpenAFS are working great as an AD > >> replacement (quirks aside) :) > > > > Nice to learn about pGina, just from glancing over the plugins i am > > under the impression the windows-users are authenticated with pure ldap > > in your place now, losing singlesignon that way? > > Or did i miss something? > > We do auth through a home made pGina plugin that does kerberos auth and > ensures openafs (roaming profiles and user dirs are in the afs cell) is > ready; looking up user info in ldap, ensuring clock is in sync and > enabling password change are in the works. Finally kfw and openafs > integrated logon plugin takes care of actual tickets for user session so > there's SSO*. > > We've had to patch pGina too as stock one was crashing on us. Once we've > been able to polish all the quirks (currently sometimes users are > randomly denied access to afs cell on first login) we'll release code > and docs somewhere :) > > * Biggest issue with SSO is that it'll only work with apps capable of > talking to kfw (firefox, thunderbird, openafs-client, ...), but that's > not a problem around here. In theory with Vista clients kfw is capable > of writing to system ccache (enabling SSO on IE and the like) but we > haven't tried it here. I am eager to see your code once released please feel free to post here the details. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Aug 12 13:59:10 2008 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 12 Aug 2008 09:59:10 -0400 Subject: [Freeipa-devel] freeIPA and NIS In-Reply-To: <3da3b5b40808120639w7c80ba38hae3edb21bbaca910@mail.gmail.com> References: <3da3b5b40808060653x39e39c24ra4437cdb212231a5@mail.gmail.com> <489C3F7B.50604@redhat.com> <1218332054.7942.56.camel@shyster> <48A04BF8.5070602@redhat.com> <3da3b5b40808110945w6f025fd5te4838ef57d601b15@mail.gmail.com> <48A18D06.6030003@redhat.com> <3da3b5b40808120639w7c80ba38hae3edb21bbaca910@mail.gmail.com> Message-ID: <48A1972E.5060202@redhat.com> Ahmed Kamal wrote: > How would IPA know which accounts on AD to sync over to IPA? Do they > need to share the same username ? anything else ? They are matched by name. > Also, does RHEIPA bundle DirectoryServer, or do I need to > buy/install/configure that separately ? IPA embeds DS. The IPA server = MIT Kerberos + DS + WebUI + Command Line utilities. All nicely glued together and tested. > > Thanks > > On Tue, Aug 12, 2008 at 4:15 PM, Dmitri Pal > wrote: > > Ahmed Kamal wrote: > > Thanks Dmitri for the very informative reply. I am planning on > buying RHEIPA soon, I will probably use it in testing mode and > let like 30 users play on it. After it has proved successful > for us, is it possible to "link" the 30 user accounts from > freeIPA to the same people's AD accounts (without deleting and > re-creating all accounts) ? I hope the users would retain > their UIDs so nothing breaks > > > Yes. The user entries coming from AD will "take over" control of > the already existing entries in IPA. So there will be no need to > delete and re-create them. > > > Thanks > > > On Mon, Aug 11, 2008 at 5:26 PM, Dmitri Pal >> wrote: > > Colin, > > Our plans for the AD integration are following: > a) We will release an AD synch tool later this year (most > likely > November). Since the freeIPA versions and Red Hat Enterprise > versions are a bit out of synch I can't say exactly which > freeIPA > version it would be but 1.x for sure. It will be 1.1 for > RHEIPA. > The feature will deliver: > 1) If user account is created in AD it is synchronized to > IPA. > 2) If user account is created in IPA it is NOT > synchronized to AD > 3) The changes to an account once created in AD and > synchronized > to IPA are synchronized in both directions. > 4) The passwords for accounts mentioned in 3) are also > synchronized in both directions but require installation of the > password filter component on every DC. > b) In freeIPA v2 we plan to offer trust between IPA and AD. > This > will probably ease some pain but to what extent it is hard > to say > at the moment. > Yes we use DNS for the name resolution and IPA v2 will be even > more integrated with DNS. There will be an option to use an > already existing DNS instead of the one that would come > with IPA > but zoning is the preferred method. One of the features of > the v2 > is the capability of the clients to update their DNS > information. > The DNS back end will be integrated with IPA's DS and kerberos > auth will be used to make sure the update is legitimate. > c) Samba 4 and Penrose are other technologies that we seriously > consider as solutions for the better AD integration down > the road. > It is unclear what shape and form this solution would take. > It is > unlikely that anything more than options a) and b) will be > available soon. Tighter integration via Samba 4 is on our radar > for v3 but may be Penrose based solution would come out earlier > than that. > > From the use case you described it seems that Samba 4 will > work > fine for the Windows machines you have in your company. It most > likely will be accepted as a domain (represented by Samba 4) by > your parent company. IPA will be used for Linux/Unix > machines and > user accounts on those machines. There you will have an > option of > a) and b) and probably Penrose based solution. Having and > integrated Samba 4 + IPA realm that can deal with both > Windows and > Linux/Unix might not be the best choice. We are working on such > integration option but as I mentioned it is down the road in v3 > time frame. > > I hope I did not miss anything. > > Thank you > Dmitri > > > Colin Simpson wrote: > > On Fri, 2008-08-08 at 08:43 -0400, Rob Crittenden wrote: > > > -FreeIPA2 should be out fairly soon, is there a > final > word on how the Windows integration is going to > look > like (particularly if there's no AD) ? > > We are still working on this piece. The first step is > going to be some limited syncing of users and > passwords, > later adding a more robust solution. > > If you have any specific needs please let us know. This > can be very complex as some people want to only sync > certain parts of their tree, only in one direction, > etc. > So the more requirements we gather the better the first > release will be. > > thanks > > rob > > > I'm interested in your AD integration plans. > > We are a heavy RH Linux users but our parent is a big > AD user > (and we > use AD on the Windows side). Our present Linux > directory is a > hand built > OpenLDAP/MIT Kerberos solution, pretty much what IPA was > designed to > replace. We have at present password syncing via a > couple of > tools. > Maybe we're pretty typical. > > In the future (hopefully near future) we'd like to have > a much > more > integrated solution. We are looking at either > Enterprise IPA > or Samba 4 > (saying that whenever that appears!) > > Features we'd look for: > > 1. True single sign on. If you say, log into a windows > box and > SSH into > Linux you shouldn't be asked for a password and > vice-versa if > you say > got to a Windows Sharepoint site in Firefox on Linux you > should again > not be asked for a password. > Now I know this can be achieved already by a cross realm > trust, but it's > a bit of hassle to setup (IPA might help here by hiding > some > of the > pain). One downside I have seen of this is that the > Kerberos realm > appears in the Windows drop down domains list on the login > screen. We'd > not really want Windows users logging into that for various > reasons. Not > sure if it's possible to hide a domain(realm) in > windows from that > dialog if it's trusted. > Also with this approach telling windows AD that one > user on a > realm is > equivalent to a user on another realm is a hassle to setup > (again an IPA > opportunity to ease the pain). > And also, does the IPA's use of DNS to find directory > servers > interfere > with AD's (i.e do they use the same mechanism/name spaces). > I'd rather > not maintain my Windows and Linux boxes in separate DNS > zones > just to > keep various directory services happy (it makes DHCP with > Dynamic DNS a > non starter). > 2. Support auto adding of Linux accounts when AD > accounts are > added > would be nice, maybe based on a template of some kind, for > things like > automount points of home directories). > Probably pulling in the Unix attributes from AD if that > schema > is loaded > in AD, would be a nice feature. > 3. Naturally, of course password syncing. > 4. How will IPA support Samba servers? Just now we > join Samba > to AD and > use a second krb5.conf file (with all the AD stuff in) that > only samba > uses (giving clean passwordless access to Samba shares > for Windows > users). > > My view of IPA vs potentially a Samba 4 solution would be: > > Samba 4 > ======= > No Cross Realm trust issues - As in it would issue krb > tickets > that were > just tickets valid in AD. > > No separate management of a Linux directory. Having an AD > account would > automatically give you a Linux account. > Can have windows systems authenticate safely to a Samba > 4 server. > > IPA > === > Better Linux targeting - Management of policies and > patches. > > No hoops to jump through to support *ix features e.g > automount maps > Kerberos Service (host, NFS) keys etc. > Easier client configuration > > Good vendor support and IPA is here now. > > > Or is there no choice here and IPA will be able to pull > in all > Samba 4 > features. > Have I missed anything or just given you job security > for life... > > Thanks > Colin > > This email and any files transmitted with it are > confidential > and are intended solely for the use of the individual or > entity to whom they are addressed. If you are not the > original recipient or the person responsible for delivering > the email to the intended recipient, be advised that > you have > received this email in error, and that any use, > dissemination, > forwarding, printing, or copying of this email is strictly > prohibited. If you received this email in error, please > immediately notify the sender and delete the original. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > -- Dmitri Pal > Engineering Manager > Red Hat Inc. > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > > > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > > -- > Dmitri Pal > Engineering Manager > Red Hat Inc. > > -- Dmitri Pal Engineering Manager Red Hat Inc. From nkinder at redhat.com Tue Aug 12 18:38:54 2008 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 12 Aug 2008 11:38:54 -0700 Subject: [Freeipa-devel] [PATCH] Support password change operation by direct manipulation of userPassword In-Reply-To: <1218493026.17089.8.camel@hopeson> References: <1216822832.937.16.camel@hopeson> <1216912400.8999.45.camel@hopeson> <1218493026.17089.8.camel@hopeson> Message-ID: <48A1D8BE.6040600@redhat.com> Simo Sorce wrote: > On Thu, 2008-07-24 at 11:13 -0400, Simo Sorce wrote: > >> 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. >> > > Another revision, this one removes the requirement to have an ssl > connection to just ldapadd/ldapmodify the userPassword attribute. > This would be a change in behavior for DS and may cause problems to > existing applications. > There's a leak of a Slapi_Entry at the end of your pre-op function in the case of "rc == LDAP_SUCCESS". I already spoke with you about this one in IRC. I'd also prefer you #define the "sambaLMPassword" and "sambaNTPassword" attribute names. Other than that, it looks good. -NGK > Simo. > ------------------------------------------------------------------------ > > _______________________________________________ > 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 ssorce at redhat.com Tue Aug 12 18:48:09 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 12 Aug 2008 14:48:09 -0400 Subject: [Freeipa-devel] [PATCH] Support password change operation by direct manipulation of userPassword In-Reply-To: <48A1D8BE.6040600@redhat.com> References: <1216822832.937.16.camel@hopeson> <1216912400.8999.45.camel@hopeson> <1218493026.17089.8.camel@hopeson> <48A1D8BE.6040600@redhat.com> Message-ID: <1218566889.2991.77.camel@localhost.localdomain> On Tue, 2008-08-12 at 11:38 -0700, Nathan Kinder wrote: > Simo Sorce wrote: > > On Thu, 2008-07-24 at 11:13 -0400, Simo Sorce wrote: > > > >> 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. > >> > > > > Another revision, this one removes the requirement to have an ssl > > connection to just ldapadd/ldapmodify the userPassword attribute. > > This would be a change in behavior for DS and may cause problems to > > existing applications. > > > There's a leak of a Slapi_Entry at the end of your pre-op function in > the case of "rc == LDAP_SUCCESS". I already spoke with you about this > one in IRC. I'd also prefer you #define the "sambaLMPassword" and > "sambaNTPassword" attribute names. > > Other than that, it looks good. Ok I will address the sambaNTPassword/sambaLMPassword attribute names definition ina a following patch as they are used in other parts of the code too IIRC. I will quick fix the memleak and push the patch as is. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Aug 12 19:01:52 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 12 Aug 2008 15:01:52 -0400 Subject: [Freeipa-devel] [PATCH] Support password change operation by direct manipulation of userPassword In-Reply-To: <1218566889.2991.77.camel@localhost.localdomain> References: <1216822832.937.16.camel@hopeson> <1216912400.8999.45.camel@hopeson> <1218493026.17089.8.camel@hopeson> <48A1D8BE.6040600@redhat.com> <1218566889.2991.77.camel@localhost.localdomain> Message-ID: <1218567712.2991.79.camel@localhost.localdomain> On Tue, 2008-08-12 at 14:48 -0400, Simo Sorce wrote: > On Tue, 2008-08-12 at 11:38 -0700, Nathan Kinder wrote: > > Simo Sorce wrote: > > > On Thu, 2008-07-24 at 11:13 -0400, Simo Sorce wrote: > > > > > >> 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. > > >> > > > > > > Another revision, this one removes the requirement to have an ssl > > > connection to just ldapadd/ldapmodify the userPassword attribute. > > > This would be a change in behavior for DS and may cause problems to > > > existing applications. > > > > > There's a leak of a Slapi_Entry at the end of your pre-op function in > > the case of "rc == LDAP_SUCCESS". I already spoke with you about this > > one in IRC. I'd also prefer you #define the "sambaLMPassword" and > > "sambaNTPassword" attribute names. > > > > Other than that, it looks good. > > Ok I will address the sambaNTPassword/sambaLMPassword attribute names > definition ina a following patch as they are used in other parts of the > code too IIRC. > > I will quick fix the memleak and push the patch as is. pushed to master -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Aug 12 19:35:13 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 12 Aug 2008 15:35:13 -0400 Subject: [Freeipa-devel] [PATCH] fix replica-install to use SSL connections early on In-Reply-To: <48A18D19.1070604@redhat.com> References: <1218492879.17089.4.camel@hopeson> <48A18BB6.60006@redhat.com> <48A18D19.1070604@redhat.com> Message-ID: <48A1E5F1.9080208@redhat.com> Martin Nagy wrote: > Stephen Gallagher wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Simo Sorce wrote: >>> This patch install the ca.crt file early on and enforce the use of SSL >>> to set up the replication agreement. >>> >>> >>> ------------------------------------------------------------------------ >> >> I don't like the use of the hard-coded CACERT variable. We're trying to >> eliminate the use of hard-coded paths. See Bugzilla #430000 for more >> details. > > No worries about that. I have a list of the hard-coded paths and am > maintaining it, watching every commit. This is just for a short time, > I'm planning to address the bug soon. > Not sure this qualifies as an 'ack' so I'll go ahead and ack this :) 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 Aug 13 19:32:21 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 13 Aug 2008 15:32:21 -0400 Subject: [Freeipa-devel] [PATCH] Comment out bad code Message-ID: <1218655941.26449.7.camel@hopeson> This piece of code seem to generate bad keys. I must have misunderstood how the salt is treated, will re-enable once I find out if random salts can be used at all. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Comment-out-code-that-generates-keys-with-a-random-s.patch Type: application/mbox Size: 1651 bytes Desc: not available URL: From ssorce at redhat.com Wed Aug 13 19:30:57 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 13 Aug 2008 15:30:57 -0400 Subject: [Freeipa-devel] [PATCH] Fix compile with mozldap Message-ID: <1218655857.26449.4.camel@hopeson> Thanks to Mike for the fix, it seem to fix the mozldap issues we had we ipa-getkeytab. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Fix-usage-of-mozldap-libraries.patch Type: application/mbox Size: 1551 bytes Desc: not available URL: From ssorce at redhat.com Wed Aug 13 19:29:23 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 13 Aug 2008 15:29:23 -0400 Subject: [Freeipa-devel] [PATCH] 2 cleanup patches Message-ID: <1218655763.26449.1.camel@hopeson> These patches clean up stuff that seem not to be used. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-apparently-the-configure-target-is-never-used.patch Type: application/mbox Size: 913 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Remove-unused-stuff.patch Type: application/mbox Size: 1137 bytes Desc: not available URL: From ssorce at redhat.com Wed Aug 13 19:35:17 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 13 Aug 2008 15:35:17 -0400 Subject: [Freeipa-devel] [PATCH] ipa-getkeytab enhancements Message-ID: <1218656117.26449.11.camel@hopeson> Add 2 linked enhancements to ipa-getkeytab 1. make it possible to use a known password not forcibly a random secret 2. make it possible to specify a salt type along with the encryption type The server side needn't any modification as it was already built to accept optional salt fields. All seem to work as expected when using the 2 features (note that salts can be used only if a password is specified). Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-Add-2-features-to-ipa-getkeytab.patch Type: application/mbox Size: 23354 bytes Desc: not available URL: From simo at redhat.com Wed Aug 13 19:41:34 2008 From: simo at redhat.com (Simo Sorce) Date: Wed, 13 Aug 2008 15:41:34 -0400 Subject: [Freeipa-devel] [PATCH] fix replica-install to use SSL connections early on In-Reply-To: <48A1E5F1.9080208@redhat.com> References: <1218492879.17089.4.camel@hopeson> <48A18BB6.60006@redhat.com> <48A18D19.1070604@redhat.com> <48A1E5F1.9080208@redhat.com> Message-ID: <1218656494.32477.5.camel@localhost.localdomain> On Tue, 2008-08-12 at 15:35 -0400, Rob Crittenden wrote: > > Not sure this qualifies as an 'ack' so I'll go ahead and ack this :) pushed to master -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Aug 13 19:54:44 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Aug 2008 15:54:44 -0400 Subject: [Freeipa-devel] [PATCH] 2 cleanup patches In-Reply-To: <1218655763.26449.1.camel@hopeson> References: <1218655763.26449.1.camel@hopeson> Message-ID: <48A33C04.8060402@redhat.com> Simo Sorce wrote: > These patches clean up stuff that seem not to be used. > ack x2. -------------- 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 Aug 13 19:55:14 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 13 Aug 2008 15:55:14 -0400 Subject: [Freeipa-devel] [PATCH] Fix compile with mozldap In-Reply-To: <1218655857.26449.4.camel@hopeson> References: <1218655857.26449.4.camel@hopeson> Message-ID: <48A33C22.5030207@redhat.com> Simo Sorce wrote: > Thanks to Mike for the fix, it seem to fix the mozldap issues we had we > ipa-getkeytab. 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 Wed Aug 13 20:01:49 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 13 Aug 2008 16:01:49 -0400 Subject: [Freeipa-devel] [PATCH] 2 cleanup patches In-Reply-To: <48A33C04.8060402@redhat.com> References: <1218655763.26449.1.camel@hopeson> <48A33C04.8060402@redhat.com> Message-ID: <1218657709.32477.12.camel@localhost.localdomain> On Wed, 2008-08-13 at 15:54 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > These patches clean up stuff that seem not to be used. > > > > ack x2. pushed to master -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Aug 13 20:02:00 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 13 Aug 2008 16:02:00 -0400 Subject: [Freeipa-devel] [PATCH] Fix compile with mozldap In-Reply-To: <48A33C22.5030207@redhat.com> References: <1218655857.26449.4.camel@hopeson> <48A33C22.5030207@redhat.com> Message-ID: <1218657720.32477.14.camel@localhost.localdomain> On Wed, 2008-08-13 at 15:55 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > Thanks to Mike for the fix, it seem to fix the mozldap issues we had we > > ipa-getkeytab. > > ack pushed to master -- Simo Sorce * Red Hat, Inc * New York From email.ahmedkamal at googlemail.com Thu Aug 14 08:50:11 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 14 Aug 2008 11:50:11 +0300 Subject: [Freeipa-devel] Cached logins and sync'ed homes Message-ID: <3da3b5b40808140150o42f369eaq1d0bdc67013531d@mail.gmail.com> Hi there, I would very much like to implement RHEIPA for our network, I have a couple of questions though. Would it offer cached logins (for laptops at home) ? Also, Is it currently possible to have /homes on the network and on the laptop at the same time, and have them sync somehow ? If the answer is no, does redhat see that as a priority, i.e. is it being worked on ? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Thu Aug 14 12:28:28 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 14 Aug 2008 08:28:28 -0400 Subject: [Freeipa-devel] [PATCH] Comment out bad code In-Reply-To: <1218655941.26449.7.camel@hopeson> References: <1218655941.26449.7.camel@hopeson> Message-ID: <48A424EC.7020304@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simo Sorce wrote: > This piece of code seem to generate bad keys. I must have misunderstood > how the salt is treated, will re-enable once I find out if random salts > can be used at all. > > Simo. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ack - -- - -------------------- Stephen Gallagher RHCE 804006346421761 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkikJOwACgkQc7MaxVic+2pgawCfcjhVxhwqSLvE9rkRql3t9lHv JG0An2HSACiwbbFstBIbVj6Wd9vDk963 =tmnk -----END PGP SIGNATURE----- From ssorce at redhat.com Thu Aug 14 13:20:55 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 14 Aug 2008 09:20:55 -0400 Subject: [Freeipa-devel] Cached logins and sync'ed homes In-Reply-To: <3da3b5b40808140150o42f369eaq1d0bdc67013531d@mail.gmail.com> References: <3da3b5b40808140150o42f369eaq1d0bdc67013531d@mail.gmail.com> Message-ID: <1218720055.32477.34.camel@localhost.localdomain> On Thu, 2008-08-14 at 11:50 +0300, Ahmed Kamal wrote: > Hi there, > I would very much like to implement RHEIPA for our network, I have a > couple of questions though. Would it offer cached logins (for laptops > at home) ? Not yet, we are working on this. > Also, Is it currently possible to have /homes on the network and on > the laptop at the same time, and have them sync somehow ? No, and so far we are staying away from storage related issues as that is not our core interest. > If the answer is no, does redhat see that as a priority, i.e. is it > being worked on ? Red Hat probably has interest in both but the FreeIPA project focuses only on Identity, Policy and Audit, so far storage management is not a priority. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Aug 14 15:16:59 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Aug 2008 11:16:59 -0400 Subject: [Freeipa-devel] [PATCH] fix some syntax errors Message-ID: <48A44C6B.3050608@redhat.com> Fix some syntax errors in the recent big validators change. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-72-syntax.patch Type: text/x-patch Size: 2145 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 Aug 14 15:18:44 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 14 Aug 2008 11:18:44 -0400 Subject: [Freeipa-devel] [PATCH] fix some syntax errors In-Reply-To: <48A44C6B.3050608@redhat.com> References: <48A44C6B.3050608@redhat.com> Message-ID: <48A44CD4.4060301@redhat.com> An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Aug 14 15:23:17 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Aug 2008 11:23:17 -0400 Subject: [Freeipa-devel] [PATCH] Make Proxy directive wildcard match more specific Message-ID: <48A44DE5.1020007@redhat.com> Make Proxy directive wildcard match more specific so we can play nicer with other apps. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-73-proxy.patch Type: text/x-patch Size: 1310 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 Aug 14 15:35:55 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 14 Aug 2008 11:35:55 -0400 Subject: [Freeipa-devel] [PATCH] Make Proxy directive wildcard match more specific In-Reply-To: <48A44DE5.1020007@redhat.com> References: <48A44DE5.1020007@redhat.com> Message-ID: <48A450DB.1050609@redhat.com> An HTML attachment was scrubbed... URL: From ssorce at redhat.com Thu Aug 14 15:46:01 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 14 Aug 2008 11:46:01 -0400 Subject: [Freeipa-devel] [PATCH] Make Proxy directive wildcard match more specific In-Reply-To: <48A44DE5.1020007@redhat.com> References: <48A44DE5.1020007@redhat.com> Message-ID: <1218728761.32477.47.camel@localhost.localdomain> On Thu, 2008-08-14 at 11:23 -0400, Rob Crittenden wrote: > Make Proxy directive wildcard match more specific so we can play nicer > with other apps. Do we need to change the upgrade script too ? -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Aug 14 15:47:02 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Aug 2008 11:47:02 -0400 Subject: [Freeipa-devel] [PATCH] Make Proxy directive wildcard match more specific In-Reply-To: <1218728761.32477.47.camel@localhost.localdomain> References: <48A44DE5.1020007@redhat.com> <1218728761.32477.47.camel@localhost.localdomain> Message-ID: <48A45376.7060309@redhat.com> Simo Sorce wrote: > On Thu, 2008-08-14 at 11:23 -0400, Rob Crittenden wrote: >> Make Proxy directive wildcard match more specific so we can play nicer >> with other apps. > > Do we need to change the upgrade script too ? > No, I just bumped the version and it should be updated for us. 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 Aug 14 15:50:05 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 14 Aug 2008 11:50:05 -0400 Subject: [Freeipa-devel] [PATCH] Make Proxy directive wildcard match more specific In-Reply-To: <48A45376.7060309@redhat.com> References: <48A44DE5.1020007@redhat.com> <1218728761.32477.47.camel@localhost.localdomain> <48A45376.7060309@redhat.com> Message-ID: <1218729005.32477.49.camel@localhost.localdomain> On Thu, 2008-08-14 at 11:47 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Thu, 2008-08-14 at 11:23 -0400, Rob Crittenden wrote: > >> Make Proxy directive wildcard match more specific so we can play nicer > >> with other apps. > > > > Do we need to change the upgrade script too ? > > > > No, I just bumped the version and it should be updated for us. cool -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Aug 14 16:07:40 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 14 Aug 2008 12:07:40 -0400 Subject: [Freeipa-devel] [PATCH] Delete old mercurial files In-Reply-To: <48A18926.7030100@redhat.com> References: <48A18926.7030100@redhat.com> Message-ID: <1218730060.32477.54.camel@localhost.localdomain> On Tue, 2008-08-12 at 14:59 +0200, Martin Nagy wrote: > ack Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Aug 14 17:51:49 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Aug 2008 13:51:49 -0400 Subject: [Freeipa-devel] [PATCH] Make Proxy directive wildcard match more specific In-Reply-To: <1218729005.32477.49.camel@localhost.localdomain> References: <48A44DE5.1020007@redhat.com> <1218728761.32477.47.camel@localhost.localdomain> <48A45376.7060309@redhat.com> <1218729005.32477.49.camel@localhost.localdomain> Message-ID: <48A470B5.3030202@redhat.com> Simo Sorce wrote: > On Thu, 2008-08-14 at 11:47 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Thu, 2008-08-14 at 11:23 -0400, Rob Crittenden wrote: >>>> Make Proxy directive wildcard match more specific so we can play nicer >>>> with other apps. >>> Do we need to change the upgrade script too ? >>> >> No, I just bumped the version and it should be updated for us. > > cool > 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 Thu Aug 14 17:51:57 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Aug 2008 13:51:57 -0400 Subject: [Freeipa-devel] [PATCH] fix some syntax errors In-Reply-To: <48A44CD4.4060301@redhat.com> References: <48A44C6B.3050608@redhat.com> <48A44CD4.4060301@redhat.com> Message-ID: <48A470BD.6060503@redhat.com> Stephen Gallagher wrote: > Rob Crittenden wrote: >> Fix some syntax errors in the recent big validators change. >> >> rob >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > 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 rcritten at redhat.com Thu Aug 14 20:18:49 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Aug 2008 16:18:49 -0400 Subject: [Freeipa-devel] [PATCH] fix generating Firefox autoconfig files at install time Message-ID: <48A49329.5090203@redhat.com> When installing with an IPA-created CA generate the Firefox autoconfiguration files. This bug snuck in when I added support for PKCS#12 files at install time. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-74-autoconfig.patch Type: text/x-patch Size: 1254 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 mnagy at redhat.com Thu Aug 14 20:30:39 2008 From: mnagy at redhat.com (Martin Nagy) Date: Thu, 14 Aug 2008 22:30:39 +0200 Subject: [Freeipa-devel] [PATCH] fix generating Firefox autoconfig files at install time In-Reply-To: <48A49329.5090203@redhat.com> References: <48A49329.5090203@redhat.com> Message-ID: <20080814223039.097a90c8@notas> Rob Crittenden wrote: > When installing with an IPA-created CA generate the Firefox > autoconfiguration files. > > This bug snuck in when I added support for PKCS#12 files at install > time. > > rob ack From rcritten at redhat.com Thu Aug 14 21:43:38 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Aug 2008 17:43:38 -0400 Subject: [Freeipa-devel] [PATCH] fix generating Firefox autoconfig files at install time In-Reply-To: <20080814223039.097a90c8@notas> References: <48A49329.5090203@redhat.com> <20080814223039.097a90c8@notas> Message-ID: <48A4A70A.6020706@redhat.com> Martin Nagy wrote: > Rob Crittenden wrote: >> When installing with an IPA-created CA generate the Firefox >> autoconfiguration files. >> >> This bug snuck in when I added support for PKCS#12 files at install >> time. >> >> 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 rcritten at redhat.com Thu Aug 14 22:22:25 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 14 Aug 2008 18:22:25 -0400 Subject: [Freeipa-devel] [PATCH] use temp directory for cert request files Message-ID: <48A4B021.3010208@redhat.com> Use a temporary directory for files needed while generated certificates. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-75-tempdir.patch Type: text/x-patch Size: 1785 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 mnagy at redhat.com Fri Aug 15 06:57:52 2008 From: mnagy at redhat.com (Martin Nagy) Date: Fri, 15 Aug 2008 08:57:52 +0200 Subject: [Freeipa-devel] [PATCH] Delete old mercurial files In-Reply-To: <1218730060.32477.54.camel@localhost.localdomain> References: <48A18926.7030100@redhat.com> <1218730060.32477.54.camel@localhost.localdomain> Message-ID: <48A528F0.8060503@redhat.com> Simo Sorce wrote: > On Tue, 2008-08-12 at 14:59 +0200, Martin Nagy wrote: > > ack > > Simo. > pushed to master From mnagy at redhat.com Fri Aug 15 06:58:41 2008 From: mnagy at redhat.com (Martin Nagy) Date: Fri, 15 Aug 2008 08:58:41 +0200 Subject: [Freeipa-devel] [PATCH] Comment out bad code In-Reply-To: <48A424EC.7020304@redhat.com> References: <1218655941.26449.7.camel@hopeson> <48A424EC.7020304@redhat.com> Message-ID: <48A52921.3020208@redhat.com> Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Simo Sorce wrote: >> This piece of code seem to generate bad keys. I must have misunderstood >> how the salt is treated, will re-enable once I find out if random salts >> can be used at all. >> >> Simo. pushed to master From ssorce at redhat.com Fri Aug 15 12:22:36 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 15 Aug 2008 08:22:36 -0400 Subject: [Freeipa-devel] [PATCH] use temp directory for cert request files In-Reply-To: <48A4B021.3010208@redhat.com> References: <48A4B021.3010208@redhat.com> Message-ID: <1218802956.32477.141.camel@localhost.localdomain> On Thu, 2008-08-14 at 18:22 -0400, Rob Crittenden wrote: > Use a temporary directory for files needed while generated > certificates. ack -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Aug 15 15:06:12 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 15 Aug 2008 11:06:12 -0400 Subject: [Freeipa-devel] [PATCH] use temp directory for cert request files In-Reply-To: <1218802956.32477.141.camel@localhost.localdomain> References: <48A4B021.3010208@redhat.com> <1218802956.32477.141.camel@localhost.localdomain> Message-ID: <48A59B64.8050204@redhat.com> Simo Sorce wrote: > On Thu, 2008-08-14 at 18:22 -0400, Rob Crittenden wrote: >> Use a temporary directory for files needed while generated >> certificates. > > 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 Fri Aug 15 17:09:44 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 15 Aug 2008 13:09:44 -0400 Subject: [Freeipa-devel] [PATCH] tool to manage search and user policy In-Reply-To: <489719D6.6070904@redhat.com> References: <487B9AB8.8070502@redhat.com> <489719D6.6070904@redhat.com> Message-ID: <48A5B858.9080108@redhat.com> Martin Nagy wrote: > Rob Crittenden wrote: >> 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 > > No comments to the name of the utility :) > Just a very few minor details: > > .dotest/patch:176: trailing whitespace. > if options.show: > > From ipa-admintools/ipa-policyconfig, function update_policy(): > For some attributes, the minimum of 0 is not appropriate. > For the string attributes, I'd say specifying min=0 isn't required. > > Otherwise, the patch seems fine to me. > > Martin I rebased the patch, changed the tool name to ipa-defaultoptions, fixed the trailing space and the min allowed values. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-76-policy.patch Type: text/x-patch Size: 57 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 Fri Aug 15 17:16:16 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Fri, 15 Aug 2008 13:16:16 -0400 Subject: [Freeipa-devel] [PATCH] tool to manage search and user policy In-Reply-To: <48A5B858.9080108@redhat.com> References: <487B9AB8.8070502@redhat.com> <489719D6.6070904@redhat.com> <48A5B858.9080108@redhat.com> Message-ID: <48A5B9E0.8090907@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Empty patch Rob Crittenden wrote: > Martin Nagy wrote: >> Rob Crittenden wrote: >>> 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 >> >> No comments to the name of the utility :) >> Just a very few minor details: >> >> .dotest/patch:176: trailing whitespace. >> if options.show: >> >> From ipa-admintools/ipa-policyconfig, function update_policy(): >> For some attributes, the minimum of 0 is not appropriate. >> For the string attributes, I'd say specifying min=0 isn't required. >> >> Otherwise, the patch seems fine to me. >> >> Martin > > I rebased the patch, changed the tool name to ipa-defaultoptions, fixed > the trailing space and the min allowed values. > > rob > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 iEYEARECAAYFAkilueAACgkQc7MaxVic+2p0AgCfXwyNUzByD4n6q4Za1Axr788t YqYAoKOvk9DZ5lrZo0CJlKV6w/W9rnNv =hsoV -----END PGP SIGNATURE----- From rcritten at redhat.com Fri Aug 15 17:24:08 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 15 Aug 2008 13:24:08 -0400 Subject: [Freeipa-devel] [PATCH] tool to manage search and user policy In-Reply-To: <48A5B9E0.8090907@redhat.com> References: <487B9AB8.8070502@redhat.com> <489719D6.6070904@redhat.com> <48A5B858.9080108@redhat.com> <48A5B9E0.8090907@redhat.com> Message-ID: <48A5BBB8.5070601@redhat.com> Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Empty patch One of those days. rob > > Rob Crittenden wrote: >> Martin Nagy wrote: >>> Rob Crittenden wrote: >>>> 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 >>> No comments to the name of the utility :) >>> Just a very few minor details: >>> >>> .dotest/patch:176: trailing whitespace. >>> if options.show: >>> >>> From ipa-admintools/ipa-policyconfig, function update_policy(): >>> For some attributes, the minimum of 0 is not appropriate. >>> For the string attributes, I'd say specifying min=0 isn't required. >>> >>> Otherwise, the patch seems fine to me. >>> >>> Martin >> I rebased the patch, changed the tool name to ipa-defaultoptions, fixed >> the trailing space and the min allowed values. >> >> rob >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 > > iEYEARECAAYFAkilueAACgkQc7MaxVic+2p0AgCfXwyNUzByD4n6q4Za1Axr788t > YqYAoKOvk9DZ5lrZo0CJlKV6w/W9rnNv > =hsoV > -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-76-policy.patch Type: text/x-patch Size: 12488 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 mnagy at redhat.com Fri Aug 15 20:40:05 2008 From: mnagy at redhat.com (Martin Nagy) Date: Fri, 15 Aug 2008 22:40:05 +0200 Subject: [Freeipa-devel] [PATCH] tool to manage search and user policy In-Reply-To: <48A5BBB8.5070601@redhat.com> References: <487B9AB8.8070502@redhat.com> <489719D6.6070904@redhat.com> <48A5B858.9080108@redhat.com> <48A5B9E0.8090907@redhat.com> <48A5BBB8.5070601@redhat.com> Message-ID: <20080815224005.3b76119c@notas> Rob Crittenden wrote: > Stephen Gallagher wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Empty patch > > One of those days. > > rob > > > > > Rob Crittenden wrote: > >> Martin Nagy wrote: > >>> Rob Crittenden wrote: > >>>> 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 > >>> No comments to the name of the utility :) > >>> Just a very few minor details: > >>> > >>> .dotest/patch:176: trailing whitespace. > >>> if options.show: > >>> > >>> From ipa-admintools/ipa-policyconfig, function update_policy(): > >>> For some attributes, the minimum of 0 is not appropriate. > >>> For the string attributes, I'd say specifying min=0 isn't > >>> required. > >>> > >>> Otherwise, the patch seems fine to me. > >>> > >>> Martin > >> I rebased the patch, changed the tool name to ipa-defaultoptions, > >> fixed the trailing space and the min allowed values. > >> > >> rob Ugh, you still forgot to rename ipa-policyconfig in man/Makefile :) But ack anyway, just don't forget to change before the push. Martin From ssorce at redhat.com Fri Aug 15 21:46:11 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 15 Aug 2008 17:46:11 -0400 Subject: [Freeipa-devel] [PATCH] Fix segfault in ipa-pwd-plugin Message-ID: <1218836771.27050.1.camel@hopeson> A mod operation that intercept userPassword would end up in a segfault. Not sure how this escaped my previous testing, but here there is a fix. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-segfault-cause-by-empty-target-entry.patch Type: application/mbox Size: 3382 bytes Desc: not available URL: From rmeggins at redhat.com Fri Aug 15 22:18:01 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 15 Aug 2008 16:18:01 -0600 Subject: [Freeipa-devel] [PATCH] Fix segfault in ipa-pwd-plugin In-Reply-To: <1218836771.27050.1.camel@hopeson> References: <1218836771.27050.1.camel@hopeson> Message-ID: <48A60099.9020301@redhat.com> Simo Sorce wrote: > A mod operation that intercept userPassword would end up in a segfault. > Not sure how this escaped my previous testing, but here there is a fix. > ack > Simo. > > ------------------------------------------------------------------------ > > _______________________________________________ > 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: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From alex at davz.net Sat Aug 16 11:37:19 2008 From: alex at davz.net (Alex Davies) Date: Sat, 16 Aug 2008 13:37:19 +0200 Subject: [Freeipa-devel] Multiple Active Directory Domains authentication - is freeIPA my solution? Message-ID: <5fb622120808160437m32f5ac1didefd1530425ba57b@mail.gmail.com> Hi Everyone, I'm trying to find a open source solution to authenticate a bunch of Linux machines (and, ideally, network devices etc.) against Active Directory. The complication we have is that my organization has more than one Active Directory Domain, each hosted on its own collection of domain controllers. In windows, users select the relevant domain when they login to a PC and everyone is happy [there is a trust relationship between our domains]. I can not for the life of me get this to work properly on Linux. We setup Fedora Directory Server, and passsync on all our (very very many) domain controllers. We then setup multiple replication agreements (one per AD domain), and this seems to work - most of the time however sometimes passwords are not synced. We then used NIS netgroups to authenticate access to machines, and finally a centrally managed sudoers file (via Satellite) to allow users who have logged in to work as role accounts if required (such as "oracle"). This is a giant mess; adding a machine or user takes a very long time and requires changes in three places. We are unable to get a FDS replica to actually work. A small but significant number of password changes do not sync AD->LDAP. If a user is disabled in AD, this does not appear in FDS. I could go on, but the summary is we really really hate this setup. Can I ask if freeIPA will help me here? If not, can anyone point me in the direction of something that will? I suspect that the multiple AD domains thing will be a problem. Many thanks, Alex From sgallagh at redhat.com Mon Aug 18 12:05:01 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 18 Aug 2008 08:05:01 -0400 Subject: [Freeipa-devel] [PATCH] Fix segfault in ipa-pwd-plugin In-Reply-To: <1218836771.27050.1.camel@hopeson> References: <1218836771.27050.1.camel@hopeson> Message-ID: <48A9656D.40402@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simo Sorce wrote: > A mod operation that intercept userPassword would end up in a segfault. > Not sure how this escaped my previous testing, but here there is a fix. > > Simo. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Nitpick: Typo in both log messages. Should read "Failed to retrieve entry", not "Failed tpo retrieve entry" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkipZW0ACgkQc7MaxVic+2oU2QCaAzqqGsS3ITPzzPb2O36S+bR3 8PEAn3PS5RlGa63iJOhjIOqZFPxfaW+J =egeR -----END PGP SIGNATURE----- From rmeggins at redhat.com Mon Aug 18 14:14:50 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 18 Aug 2008 08:14:50 -0600 Subject: [Freeipa-devel] Multiple Active Directory Domains authentication - is freeIPA my solution? In-Reply-To: <5fb622120808160437m32f5ac1didefd1530425ba57b@mail.gmail.com> References: <5fb622120808160437m32f5ac1didefd1530425ba57b@mail.gmail.com> Message-ID: <48A983DA.5080304@redhat.com> Alex Davies wrote: > Hi Everyone, > > I'm trying to find a open source solution to authenticate a bunch of > Linux machines (and, ideally, network devices etc.) against Active > Directory. The complication we have is that my organization has more > than one Active Directory Domain, each hosted on its own collection of > domain controllers. In windows, users select the relevant domain when > they login to a PC and everyone is happy [there is a trust > relationship between our domains]. I can not for the life of me get > this to work properly on Linux. > > We setup Fedora Directory Server, and passsync on all our (very very > many) domain controllers. We then setup multiple replication > agreements (one per AD domain), and this seems to work - most of the > time however sometimes passwords are not synced. Can you provide passsync logs or Fedora DS logs showing failures? > We then used NIS > netgroups to authenticate access to machines, and finally a centrally > managed sudoers file (via Satellite) to allow users who have logged in > to work as role accounts if required (such as "oracle"). > > This is a giant mess; adding a machine or user takes a very long time > and requires changes in three places. We are unable to get a FDS > replica to actually work. A small but significant number of password > changes do not sync AD->LDAP. If a user is disabled in AD, this does > not appear in FDS. I could go on, but the summary is we really really > hate this setup. > > Can I ask if freeIPA will help me here? If not, can anyone point me in > the direction of something that will? I suspect that the multiple AD > domains thing will be a problem. > > Many thanks, > > Alex > > _______________________________________________ > 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: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From cobra at cobradevil.org Mon Aug 18 18:38:56 2008 From: cobra at cobradevil.org (cobra at cobradevil.org) Date: Mon, 18 Aug 2008 20:38:56 +0200 (CEST) Subject: [Freeipa-devel] Business Case: Advantage Opensource Directory VS Active Directory] Message-ID: <45575.77.162.228.253.1219084736.squirrel@webmail.spothost.nl> Hello all, I have a question why i should use an opensource directory server for my opensource activities! I work for a large company! 70k users We have a large MS Windows based infrastructure win2k3 with winxp workstations. For our open source servers and workstations we thought to get an Opensource Directory server because of the specific options that Active Directory cannot deliver. But now i get a lot of people who say that active directory can do all of it! Can someone help me with getting the right arguments so i have a valid reason to create an opensource directory server? The things i wanna administer are: Sudoldap Freeipa based authentication/dns application management and probably a lot more! Please let me know! With kind regards, William van de Velde From alex at davz.net Mon Aug 18 20:51:57 2008 From: alex at davz.net (Alex Davies) Date: Mon, 18 Aug 2008 22:51:57 +0200 Subject: [Freeipa-devel] Multiple Active Directory Domains authentication - is freeIPA my solution? In-Reply-To: <48A983DA.5080304@redhat.com> References: <5fb622120808160437m32f5ac1didefd1530425ba57b@mail.gmail.com> <48A983DA.5080304@redhat.com> Message-ID: <5fb622120808181351l34a27a83xbf8ca99d878038df@mail.gmail.com> Hi Rich, We think the problem is actually with some of our DCs in remote locations that have all sorts of funny security things installed on them which break the Passsync service from time to time, with no obvious cause in the log files. For us however the solution we currently have really sucks - if only because of the amount of configuration it takes to add a machine or ensure that no user accounts have been disabled - and we are really looking for a replacement! Any suggestions would be much appreciated. Best wishes, Alex On Mon, Aug 18, 2008 at 4:14 PM, Rich Megginson wrote: > Alex Davies wrote: >> >> Hi Everyone, >> >> I'm trying to find a open source solution to authenticate a bunch of >> Linux machines (and, ideally, network devices etc.) against Active >> Directory. The complication we have is that my organization has more >> than one Active Directory Domain, each hosted on its own collection of >> domain controllers. In windows, users select the relevant domain when >> they login to a PC and everyone is happy [there is a trust >> relationship between our domains]. I can not for the life of me get >> this to work properly on Linux. >> >> We setup Fedora Directory Server, and passsync on all our (very very >> many) domain controllers. We then setup multiple replication >> agreements (one per AD domain), and this seems to work - most of the >> time however sometimes passwords are not synced. > > Can you provide passsync logs or Fedora DS logs showing failures? >> >> We then used NIS >> netgroups to authenticate access to machines, and finally a centrally >> managed sudoers file (via Satellite) to allow users who have logged in >> to work as role accounts if required (such as "oracle"). >> >> This is a giant mess; adding a machine or user takes a very long time >> and requires changes in three places. We are unable to get a FDS >> replica to actually work. A small but significant number of password >> changes do not sync AD->LDAP. If a user is disabled in AD, this does >> not appear in FDS. I could go on, but the summary is we really really >> hate this setup. >> >> Can I ask if freeIPA will help me here? If not, can anyone point me in >> the direction of something that will? I suspect that the multiple AD >> domains thing will be a problem. >> >> Many thanks, >> >> Alex >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > -- Alex Davies This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender immediately by e-mail and delete this e-mail permanently. From chorn at fluxcoil.net Tue Aug 19 08:21:02 2008 From: chorn at fluxcoil.net (Christian Horn) Date: Tue, 19 Aug 2008 10:21:02 +0200 Subject: [Freeipa-devel] Multiple Active Directory Domains authentication - is freeIPA my solution? In-Reply-To: <5fb622120808181351l34a27a83xbf8ca99d878038df@mail.gmail.com> References: <5fb622120808160437m32f5ac1didefd1530425ba57b@mail.gmail.com> <48A983DA.5080304@redhat.com> <5fb622120808181351l34a27a83xbf8ca99d878038df@mail.gmail.com> Message-ID: <20080819082102.GA17743@fluxcoil.net> Alex Davies wrote: > > >> I'm trying to find a open source solution to authenticate a bunch of > >> Linux machines (and, ideally, network devices etc.) against Active > >> Directory. The complication we have is that my organization has more > >> than one Active Directory Domain, each hosted on its own collection of > >> domain controllers. In windows, users select the relevant domain when > >> they login to a PC and everyone is happy [there is a trust > >> relationship between our domains]. I can not for the life of me get > >> this to work properly on Linux. > >> > >> We setup Fedora Directory Server, and passsync on all our (very very > >> many) domain controllers. We then setup multiple replication > >> agreements (one per AD domain), and this seems to work - most of the > >> time however sometimes passwords are not synced. For now you try so sync the complete datasets between the two worlds, you could try an approach that makes a kerberos kdc or freeipa-server to look like one of the AD-controllers, so setup a trust between them. This is a different approach, not yet supported by freeipa but did technically work for me in a testsetup with an mit-kdc. This would handle authentication only, maybe for authorization you could make the linux-boxes contact the AD-controllers directly via ldap. Havent used this in enterprise-setups, just a thought. Christian From ssorce at redhat.com Tue Aug 19 15:19:25 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 19 Aug 2008 11:19:25 -0400 Subject: [Freeipa-devel] [PATCH] Fix segfault in ipa-pwd-plugin In-Reply-To: <48A60099.9020301@redhat.com> References: <1218836771.27050.1.camel@hopeson> <48A60099.9020301@redhat.com> Message-ID: <1219159165.15642.30.camel@localhost.localdomain> On Fri, 2008-08-15 at 16:18 -0600, Rich Megginson wrote: > ack pushed to master -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Tue Aug 19 22:18:21 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 19 Aug 2008 18:18:21 -0400 Subject: [Freeipa-devel] [PATCH] Minor bugs found during general code review Message-ID: <1219184301.29100.0.camel@hopeson> See subject -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Minor-bugs-found-while-testing-stuff.patch Type: application/mbox Size: 1459 bytes Desc: not available URL: From mnagy at redhat.com Tue Aug 19 22:23:43 2008 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 20 Aug 2008 00:23:43 +0200 Subject: [Freeipa-devel] [PATCH] Minor bugs found during general code review In-Reply-To: <1219184301.29100.0.camel@hopeson> References: <1219184301.29100.0.camel@hopeson> Message-ID: <20080820002343.09a51c86@notas> Simo Sorce wrote: > See subject ack From mnagy at redhat.com Wed Aug 20 13:26:04 2008 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 20 Aug 2008 15:26:04 +0200 Subject: [Freeipa-devel] [PATCH] ipa-getkeytab enhancements In-Reply-To: <1218656117.26449.11.camel@hopeson> References: <1218656117.26449.11.camel@hopeson> Message-ID: <20080820152604.2e29b338@notas> Simo Sorce wrote: > Add 2 linked enhancements to ipa-getkeytab > 1. make it possible to use a known password not forcibly a random > secret 2. make it possible to specify a salt type along with the > encryption type > > The server side needn't any modification as it was already built to > accept optional salt fields. All seem to work as expected when using > the 2 features (note that salts can be used only if a password is > specified). > > Simo. All line numbers refer to the patched ipa-getkeytab.c: For the consistency sake, I wouldn't use messages like "Out of memory!?\n", I think you should remove the !?. Also, you didn't add a message on line 169. You can remove line 160, it doesn't do anything. On line 181 I'd say "encryption type" instead of "enc type". Typo on line 283. On line 457 I think you meant to write keys[j] = keys[j + 1]. I'm reasonably convinced that the code is good, however I'm not an expert on the kerberos or lber functions (although where I could I looked at some documentation and source code). So I'd say you have a 95% ack from me. Martin From ssorce at redhat.com Wed Aug 20 14:54:55 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 20 Aug 2008 14:54:55 +0000 Subject: [Freeipa-devel] [PATCH] ipa-getkeytab enhancements In-Reply-To: <20080820152604.2e29b338@notas> References: <1218656117.26449.11.camel@hopeson> <20080820152604.2e29b338@notas> Message-ID: <1219244095.15642.87.camel@localhost.localdomain> On Wed, 2008-08-20 at 15:26 +0200, Martin Nagy wrote: > Simo Sorce wrote: > > Add 2 linked enhancements to ipa-getkeytab > > 1. make it possible to use a known password not forcibly a random > > secret 2. make it possible to specify a salt type along with the > > encryption type > > > > The server side needn't any modification as it was already built to > > accept optional salt fields. All seem to work as expected when using > > the 2 features (note that salts can be used only if a password is > > specified). > > > > Simo. > > All line numbers refer to the patched ipa-getkeytab.c: > For the consistency sake, I wouldn't use messages like "Out of > memory!?\n", I think you should remove the !?. ack > Also, you didn't add a > message on line 169. ack > You can remove line 160, it doesn't do anything. ack > On line 181 I'd say "encryption type" instead of "enc type". ah you caught me, I was trying to stay under 80 columns on that line :-P ack > Typo on line 283. ack > On line 457 I think you meant to write keys[j] = keys[j + 1]. arghh right, how did it work ? :) ack > I'm reasonably convinced that the code is good, however I'm not an > expert on the kerberos or lber functions (although where I could I > looked at some documentation and source code). So I'd > say you have a 95% ack from me. Ok re-sending with the spotted bugs fixed. Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Aug 20 14:59:47 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 20 Aug 2008 10:59:47 -0400 Subject: [Freeipa-devel] [PATCH] ipa-getkeytab enhancements In-Reply-To: <20080820152604.2e29b338@notas> References: <1218656117.26449.11.camel@hopeson> <20080820152604.2e29b338@notas> Message-ID: <1219244387.2816.0.camel@hopeson> On Wed, 2008-08-20 at 15:26 +0200, Martin Nagy wrote: > I'm reasonably convinced that the code is good, however I'm not an > expert on the kerberos or lber functions (although where I could I > looked at some documentation and source code). So I'd > say you have a 95% ack from me. Attached updated patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-2-features-to-ipa-getkeytab.patch Type: application/mbox Size: 23442 bytes Desc: not available URL: From mnagy at redhat.com Wed Aug 20 15:09:59 2008 From: mnagy at redhat.com (Martin Nagy) Date: Wed, 20 Aug 2008 17:09:59 +0200 Subject: [Freeipa-devel] [PATCH] ipa-getkeytab enhancements In-Reply-To: <1219244387.2816.0.camel@hopeson> References: <1218656117.26449.11.camel@hopeson> <20080820152604.2e29b338@notas> <1219244387.2816.0.camel@hopeson> Message-ID: <20080820170959.5fcf5a53@wolverine.englab.brq.redhat.com> On Wed, 20 Aug 2008 10:59:47 -0400, Simo Sorce wrote: > On Wed, 2008-08-20 at 15:26 +0200, Martin Nagy wrote: > > > I'm reasonably convinced that the code is good, however I'm not an > > expert on the kerberos or lber functions (although where I could I > > looked at some documentation and source code). So I'd > > say you have a 95% ack from me. > > Attached updated patch. ack From rcritten at redhat.com Wed Aug 20 19:30:37 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Aug 2008 15:30:37 -0400 Subject: [Freeipa-devel] [PATCH] limit mod_rewrite rule Message-ID: <48AC70DD.3090007@redhat.com> Limit the mod_rewrite rules to just /ipa to play nice with cobbler. We will still rewrite any request to / to the IPA ui by default but that can be easily disabled by the end-user. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-77-rewrite.patch Type: text/x-patch Size: 1439 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 Aug 20 21:40:58 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 20 Aug 2008 17:40:58 -0400 Subject: [Freeipa-devel] [PATCH] tool to manage search and user policy In-Reply-To: <20080815224005.3b76119c@notas> References: <487B9AB8.8070502@redhat.com> <489719D6.6070904@redhat.com> <48A5B858.9080108@redhat.com> <48A5B9E0.8090907@redhat.com> <48A5BBB8.5070601@redhat.com> <20080815224005.3b76119c@notas> Message-ID: <48AC8F6A.4000404@redhat.com> Martin Nagy wrote: > Rob Crittenden wrote: >> Stephen Gallagher wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Empty patch >> One of those days. >> >> rob >> >>> Rob Crittenden wrote: >>>> Martin Nagy wrote: >>>>> Rob Crittenden wrote: >>>>>> 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 >>>>> No comments to the name of the utility :) >>>>> Just a very few minor details: >>>>> >>>>> .dotest/patch:176: trailing whitespace. >>>>> if options.show: >>>>> >>>>> From ipa-admintools/ipa-policyconfig, function update_policy(): >>>>> For some attributes, the minimum of 0 is not appropriate. >>>>> For the string attributes, I'd say specifying min=0 isn't >>>>> required. >>>>> >>>>> Otherwise, the patch seems fine to me. >>>>> >>>>> Martin >>>> I rebased the patch, changed the tool name to ipa-defaultoptions, >>>> fixed the trailing space and the min allowed values. >>>> >>>> rob > > Ugh, you still forgot to rename ipa-policyconfig in man/Makefile :) > But ack anyway, just don't forget to change before the push. Fixed Makefile and trailing spaces and 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 sgallagh at redhat.com Thu Aug 21 12:17:06 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 21 Aug 2008 08:17:06 -0400 Subject: [Freeipa-devel] [PATCH] limit mod_rewrite rule In-Reply-To: <48AC70DD.3090007@redhat.com> References: <48AC70DD.3090007@redhat.com> Message-ID: <48AD5CC2.8060905@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Crittenden wrote: > Limit the mod_rewrite rules to just /ipa to play nice with cobbler. > > We will still rewrite any request to / to the IPA ui by default but that > can be easily disabled by the end-user. > > rob > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel One question: shouldn't the rewrite rule for the favicon.ico remain in the root? - -- - -------------------- Stephen Gallagher RHCE 804006346421761 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkitXL4ACgkQc7MaxVic+2o0twCcDiJCvWX4s1mFXdkcWWO8jChu 6cQAniA/8CVb+wkEBlEMV6FiEBgG+yLR =Hw8n -----END PGP SIGNATURE----- From rcritten at redhat.com Thu Aug 21 12:33:25 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Aug 2008 08:33:25 -0400 Subject: [Freeipa-devel] [PATCH] limit mod_rewrite rule In-Reply-To: <48AD5CC2.8060905@redhat.com> References: <48AC70DD.3090007@redhat.com> <48AD5CC2.8060905@redhat.com> Message-ID: <48AD6095.7060709@redhat.com> Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rob Crittenden wrote: >> Limit the mod_rewrite rules to just /ipa to play nice with cobbler. >> >> We will still rewrite any request to / to the IPA ui by default but that >> can be easily disabled by the end-user. >> >> rob >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > One question: shouldn't the rewrite rule for the favicon.ico remain in > the root? Excellent catch. I'll need to add this rule (and remove favicon.ico from the list) RewriteCond %{REQUEST_URI} !^/favicon.ico 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 Thu Aug 21 13:20:35 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 21 Aug 2008 09:20:35 -0400 Subject: [Freeipa-devel] [PATCH] limit mod_rewrite rule In-Reply-To: <48AD6095.7060709@redhat.com> References: <48AC70DD.3090007@redhat.com> <48AD5CC2.8060905@redhat.com> <48AD6095.7060709@redhat.com> Message-ID: <48AD6BA3.6040905@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Crittenden wrote: > Stephen Gallagher wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Rob Crittenden wrote: >>> Limit the mod_rewrite rules to just /ipa to play nice with cobbler. >>> >>> We will still rewrite any request to / to the IPA ui by default but that >>> can be easily disabled by the end-user. >>> >>> rob >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> One question: shouldn't the rewrite rule for the favicon.ico remain in >> the root? > > Excellent catch. I'll need to add this rule (and remove favicon.ico from > the list) > > RewriteCond %{REQUEST_URI} !^/favicon.ico > > rob Assuming that change: ack - -- - -------------------- Stephen Gallagher RHCE 804006346421761 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkita6AACgkQc7MaxVic+2ofewCfdDrfHsoIIJutnAhk+0lnZEmR +pAAoLV0cqymNJPu+q7zSlPlUHkVMZ9N =MB3T -----END PGP SIGNATURE----- From rcritten at redhat.com Thu Aug 21 13:50:33 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Aug 2008 09:50:33 -0400 Subject: [Freeipa-devel] [PATCH] limit mod_rewrite rule In-Reply-To: <48AD6BA3.6040905@redhat.com> References: <48AC70DD.3090007@redhat.com> <48AD5CC2.8060905@redhat.com> <48AD6095.7060709@redhat.com> <48AD6BA3.6040905@redhat.com> Message-ID: <48AD72A9.1020901@redhat.com> Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Rob Crittenden wrote: >> Stephen Gallagher wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Rob Crittenden wrote: >>>> Limit the mod_rewrite rules to just /ipa to play nice with cobbler. >>>> >>>> We will still rewrite any request to / to the IPA ui by default but that >>>> can be easily disabled by the end-user. >>>> >>>> rob >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> One question: shouldn't the rewrite rule for the favicon.ico remain in >>> the root? >> Excellent catch. I'll need to add this rule (and remove favicon.ico from >> the list) >> >> RewriteCond %{REQUEST_URI} !^/favicon.ico >> >> rob > > Assuming that change: > ack > As it turns out we don't need a special rule for favicon.ico anymore. The redirect rule only applies for things in /ipa so doesn't apply to /favicon.ico. I removed that rule. 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 Thu Aug 21 14:37:24 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Aug 2008 10:37:24 -0400 Subject: [Freeipa-devel] [PATCH] display name as separate attributes in ipa-finduser Message-ID: <48AD7DA4.6010203@redhat.com> Display name as separate attributes instead of showing common name. We allow one to individually set first and last name but we do not automatically update the common name so changes don't seem to happen. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-78-name.patch Type: text/x-patch Size: 2392 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 mnagy at redhat.com Thu Aug 21 14:45:21 2008 From: mnagy at redhat.com (Martin Nagy) Date: Thu, 21 Aug 2008 16:45:21 +0200 Subject: [Freeipa-devel] [PATCH] display name as separate attributes in ipa-finduser In-Reply-To: <48AD7DA4.6010203@redhat.com> References: <48AD7DA4.6010203@redhat.com> Message-ID: <20080821164521.223541da@wolverine.englab.brq.redhat.com> On Thu, 21 Aug 2008 10:37:24 -0400, Rob Crittenden wrote: > + try: > + l = attr.index('givenname') > + try: > + attr.remove('sn') > + attr.insert(l+1, 'sn') > + except ValueError: > + pass > + except ValueError: > + pass Please remove the nested try, the code will be equivalent. Martin From ssorce at redhat.com Thu Aug 21 15:08:36 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 21 Aug 2008 11:08:36 -0400 Subject: [Freeipa-devel] [PATCH] Minor bugs found during general code review In-Reply-To: <20080820002343.09a51c86@notas> References: <1219184301.29100.0.camel@hopeson> <20080820002343.09a51c86@notas> Message-ID: <1219331316.31737.58.camel@localhost.localdomain> On Wed, 2008-08-20 at 00:23 +0200, Martin Nagy wrote: > Simo Sorce wrote: > > See subject > ack pushed to master Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Thu Aug 21 15:08:52 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 21 Aug 2008 11:08:52 -0400 Subject: [Freeipa-devel] [PATCH] ipa-getkeytab enhancements In-Reply-To: <20080820170959.5fcf5a53@wolverine.englab.brq.redhat.com> References: <1218656117.26449.11.camel@hopeson> <20080820152604.2e29b338@notas> <1219244387.2816.0.camel@hopeson> <20080820170959.5fcf5a53@wolverine.englab.brq.redhat.com> Message-ID: <1219331332.31737.60.camel@localhost.localdomain> On Wed, 2008-08-20 at 17:09 +0200, Martin Nagy wrote: > On Wed, 20 Aug 2008 10:59:47 -0400, Simo Sorce > wrote: > > > On Wed, 2008-08-20 at 15:26 +0200, Martin Nagy wrote: > > > > > I'm reasonably convinced that the code is good, however I'm not an > > > expert on the kerberos or lber functions (although where I could I > > > looked at some documentation and source code). So I'd > > > say you have a 95% ack from me. > > > > Attached updated patch. > ack pushed to master -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Aug 21 15:21:02 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Aug 2008 11:21:02 -0400 Subject: [Freeipa-devel] [PATCH] display name as separate attributes in ipa-finduser In-Reply-To: <20080821164521.223541da@wolverine.englab.brq.redhat.com> References: <48AD7DA4.6010203@redhat.com> <20080821164521.223541da@wolverine.englab.brq.redhat.com> Message-ID: <48AD87DE.2060101@redhat.com> Martin Nagy wrote: > On Thu, 21 Aug 2008 10:37:24 -0400, Rob Crittenden > wrote: >> + try: >> + l = attr.index('givenname') >> + try: >> + attr.remove('sn') >> + attr.insert(l+1, 'sn') >> + except ValueError: >> + pass >> + except ValueError: >> + pass > > Please remove the nested try, the code will be equivalent. > Updated patch attached. rob -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: freeipa-78-name.patch2 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 mnagy at redhat.com Thu Aug 21 15:24:56 2008 From: mnagy at redhat.com (Martin Nagy) Date: Thu, 21 Aug 2008 17:24:56 +0200 Subject: [Freeipa-devel] [PATCH] display name as separate attributes in ipa-finduser In-Reply-To: <48AD87DE.2060101@redhat.com> References: <48AD7DA4.6010203@redhat.com> <20080821164521.223541da@wolverine.englab.brq.redhat.com> <48AD87DE.2060101@redhat.com> Message-ID: <20080821172456.1ed6f508@wolverine.englab.brq.redhat.com> On Thu, 21 Aug 2008 11:21:02 -0400, Rob Crittenden wrote: > Martin Nagy wrote: > > On Thu, 21 Aug 2008 10:37:24 -0400, Rob Crittenden > > wrote: > >> + try: > >> + l = attr.index('givenname') > >> + try: > >> + attr.remove('sn') > >> + attr.insert(l+1, 'sn') > >> + except ValueError: > >> + pass > >> + except ValueError: > >> + pass > > > > Please remove the nested try, the code will be equivalent. > > > > Updated patch attached. > > rob ack From rmeggins at redhat.com Thu Aug 21 17:41:35 2008 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 21 Aug 2008 11:41:35 -0600 Subject: [Freeipa-devel] [PATCH] New plugin - ipa-winsync - for Windows sync support Message-ID: <48ADA8CF.6020908@redhat.com> ipa-winsync is a new SLAPI plugin that allows IPA to hook into windows AD <-> dirsrv user addition and modification, so that it can add additional objectclasses and attributes required by IPA. This depends on an as-yet-unreleased Fedora DS windows sync api, so it won't compile out in the wild just yet. It also depends on the DNA plugin to automatically assign the uidNumber. Several plugin points have been added to the existing windows sync code to allow for callbacks in several places * just before a DS user/group entry is added to AD * just before an AD user/group entry is added to DS * just before modifications are sent in either direction * just before/after a total update occurs * just before/after an incremental update occurs * to get the DN of what a new DS entry synced from AD will be And others. This is how IPA uses these: * NOTE: for this first version, the plugin only cares about user entries, not groups * at startup, IPA reads its global config from its plugin config entry * when the sync agreement is created, the IPA agmt init callback is called with the DS subtree and the AD subtree. The DS subtree should be the user container (i.e. cn=users,cn=accounts,). The IPA winsync plugin creates a domain specific callback object which will be passed back to every callback. * just before an init or update, the IPA winsync plugin is called. The plugin searches the IPA configuration entries looking for information like the Kerberos realm name, the list of objectclasses to add to new entries, the posix homeDirectory prefix, and the default gidNumber. It also grabs other information from the global plugin config, such as the list of default attributes and values to add to each user entry. It stores this information in the domain specific config callback object * windows sync code calls into ipa-winsync to get the new user DN. By default, ipa-winsync will "flatten" the DN. In AD it is common to have users grouped into OUs - IPA will "flatten" these into just the cn=users,cn=accounts container, and store the OUs in the OU attribute in the new user entry * windows sync code calls into ipa-winsync to add the new user - the callback adds the list of objectclasses and attributes if any. There are a couple of attributes which get special handling ** krbPrincipalName - this is equal to the samAccountName (== uid) '@' the realm name from the domain specific config ** homeDirectory - domain config->homedir_prefix (read from ipa config) '/' samAccountName (== uid) ** gecos - set to the cn I've created a bug to track this and to attach patch files - https://bugzilla.redhat.com/show_bug.cgi?id=459729 Graphical diffs: https://bugzilla.redhat.com/attachment.cgi?id=314729&action=diff https://bugzilla.redhat.com/attachment.cgi?id=314730&action=diff https://bugzilla.redhat.com/attachment.cgi?id=314731&action=diff https://bugzilla.redhat.com/attachment.cgi?id=314732&action=diff https://bugzilla.redhat.com/attachment.cgi?id=314733&action=diff Raw patch files: https://bugzilla.redhat.com/attachment.cgi?id=314729 https://bugzilla.redhat.com/attachment.cgi?id=314730 https://bugzilla.redhat.com/attachment.cgi?id=314731 https://bugzilla.redhat.com/attachment.cgi?id=314732 https://bugzilla.redhat.com/attachment.cgi?id=314733 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Aug 21 20:57:55 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 21 Aug 2008 16:57:55 -0400 Subject: [Freeipa-devel] [PATCH] enhance ipa-listdelegation Message-ID: <48ADD6D3.9010803@redhat.com> Add options to display a subset of delegations and return 2 if none are found. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-79-delegation.patch Type: text/x-patch Size: 3157 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 mnagy at redhat.com Fri Aug 22 09:45:01 2008 From: mnagy at redhat.com (Martin Nagy) Date: Fri, 22 Aug 2008 11:45:01 +0200 Subject: [Freeipa-devel] [PATCH] enhance ipa-listdelegation In-Reply-To: <48ADD6D3.9010803@redhat.com> References: <48ADD6D3.9010803@redhat.com> Message-ID: <20080822114501.212d7c17@notas> Rob Crittenden wrote: > Add options to display a subset of delegations and return 2 if none > are found. > > rob Some thoughts: > def parse_options(): > - parser = OptionParser() > + usage = "%prog [options]" > + parser = OptionParser(usage) No need for usage, "%prog [options]" is the default. > + parser.add_option("-s", "--source", dest="source", > + help="Source group of delegation") > + parser.add_option("-n", "--name", dest="name", > + help="Name of delegation") > + parser.add_option("-t", "--target", dest="target", > + help="Target group of delegation") > parser.add_option("--usage", action="store_true", > help="Program usage") I suggest we also remove the --usage option, since it's the same as --help if you use parser.print_help() > parser.add_option("-v", "--verbose", action="store_true", > dest="verbose", @@ -56,14 +60,19 @@ def parse_options(): > args = ipa.config.init_config(sys.argv) > options, args = parser.parse_args(args) > > + if options.usage or len(args) != 1: > + parser.print_help() > + sys.exit(1) > + This can be accomplished by parser.error("too many arguments") (without the need for sys.exit(1). > + if (all or options.name == a.name or > + options.source == group_dn_to_cn[a.source_group] or > + options.target == group_dn_to_cn[a.dest_group]): Hm, wouldn't it be better if we required that all conditions are met in order to display them? > + print "Delegation Name: " + a.name > + print "Group " + group_dn_to_cn[a.source_group] Trailing whitespace (it was there before, but still :) Martin From rcritten at redhat.com Fri Aug 22 13:06:37 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 Aug 2008 09:06:37 -0400 Subject: [Freeipa-devel] [PATCH] enhance ipa-listdelegation In-Reply-To: <20080822114501.212d7c17@notas> References: <48ADD6D3.9010803@redhat.com> <20080822114501.212d7c17@notas> Message-ID: <48AEB9DD.5030302@redhat.com> Martin Nagy wrote: > Rob Crittenden wrote: >> Add options to display a subset of delegations and return 2 if none >> are found. >> >> rob > > Some thoughts: > >> def parse_options(): >> - parser = OptionParser() >> + usage = "%prog [options]" >> + parser = OptionParser(usage) > > No need for usage, "%prog [options]" is the default. Ok. > >> + parser.add_option("-s", "--source", dest="source", >> + help="Source group of delegation") >> + parser.add_option("-n", "--name", dest="name", >> + help="Name of delegation") >> + parser.add_option("-t", "--target", dest="target", >> + help="Target group of delegation") >> parser.add_option("--usage", action="store_true", >> help="Program usage") > > I suggest we also remove the --usage option, since it's the same as > --help if you use parser.print_help() I thought of that too but for continuity I decided to leave it. With 2.0 it'll be gone. > >> parser.add_option("-v", "--verbose", action="store_true", >> dest="verbose", @@ -56,14 +60,19 @@ def parse_options(): >> args = ipa.config.init_config(sys.argv) >> options, args = parser.parse_args(args) >> >> + if options.usage or len(args) != 1: >> + parser.print_help() >> + sys.exit(1) >> + > > This can be accomplished by parser.error("too many arguments") (without > the need for sys.exit(1). Ok. > >> + if (all or options.name == a.name or >> + options.source == group_dn_to_cn[a.source_group] or >> + options.target == group_dn_to_cn[a.dest_group]): > > Hm, wouldn't it be better if we required that all conditions are met > in order to display them? No, one may want to look at only one delegation, or to see all delegations that affect group foo or see all delegations that group bar owns. Or they may want to list them all. > >> + print "Delegation Name: " + a.name >> + print "Group " + group_dn_to_cn[a.source_group] > > Trailing whitespace (it was there before, but still :) Yeah, the bane of my existence. I still blame Karl. New patch coming soon. 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 Fri Aug 22 13:14:29 2008 From: mnagy at redhat.com (Martin Nagy) Date: Fri, 22 Aug 2008 15:14:29 +0200 Subject: [Freeipa-devel] [PATCH] enhance ipa-listdelegation In-Reply-To: <48AEB9DD.5030302@redhat.com> References: <48ADD6D3.9010803@redhat.com> <20080822114501.212d7c17@notas> <48AEB9DD.5030302@redhat.com> Message-ID: <20080822151429.6cf0eddc@wolverine.englab.brq.redhat.com> On Fri, 22 Aug 2008 09:06:37 -0400, Rob Crittenden wrote: > Martin Nagy wrote: > > Rob Crittenden wrote: > >> + parser.add_option("-s", "--source", dest="source", > >> + help="Source group of delegation") > >> + parser.add_option("-n", "--name", dest="name", > >> + help="Name of delegation") > >> + parser.add_option("-t", "--target", dest="target", > >> + help="Target group of delegation") > >> parser.add_option("--usage", action="store_true", > >> help="Program usage") > > > > I suggest we also remove the --usage option, since it's the same as > > --help if you use parser.print_help() > > I thought of that too but for continuity I decided to leave it. With > 2.0 it'll be gone. Ah, I've done some reworking of ipa-* tools (not sent yet) and I always removed the usage.. So I guess I'll just put it back.. Martin From rcritten at redhat.com Fri Aug 22 14:15:26 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 Aug 2008 10:15:26 -0400 Subject: [Freeipa-devel] [PATCH] enhance ipa-listdelegation In-Reply-To: <48AEB9DD.5030302@redhat.com> References: <48ADD6D3.9010803@redhat.com> <20080822114501.212d7c17@notas> <48AEB9DD.5030302@redhat.com> Message-ID: <48AEC9FE.7000009@redhat.com> Rob Crittenden wrote: > Martin Nagy wrote: >> Rob Crittenden wrote: >>> Add options to display a subset of delegations and return 2 if none >>> are found. >>> >>> rob >> >> Some thoughts: >> >>> def parse_options(): >>> - parser = OptionParser() >>> + usage = "%prog [options]" >>> + parser = OptionParser(usage) >> >> No need for usage, "%prog [options]" is the default. > > Ok. > >> >>> + parser.add_option("-s", "--source", dest="source", >>> + help="Source group of delegation") >>> + parser.add_option("-n", "--name", dest="name", >>> + help="Name of delegation") >>> + parser.add_option("-t", "--target", dest="target", >>> + help="Target group of delegation") >>> parser.add_option("--usage", action="store_true", >>> help="Program usage") >> >> I suggest we also remove the --usage option, since it's the same as >> --help if you use parser.print_help() > > I thought of that too but for continuity I decided to leave it. With 2.0 > it'll be gone. > >> >>> parser.add_option("-v", "--verbose", action="store_true", >>> dest="verbose", @@ -56,14 +60,19 @@ def parse_options(): >>> args = ipa.config.init_config(sys.argv) >>> options, args = parser.parse_args(args) >>> >>> + if options.usage or len(args) != 1: >>> + parser.print_help() >>> + sys.exit(1) >>> + >> >> This can be accomplished by parser.error("too many arguments") (without >> the need for sys.exit(1). > > Ok. > >> >>> + if (all or options.name == a.name or >>> + options.source == group_dn_to_cn[a.source_group] or >>> + options.target == group_dn_to_cn[a.dest_group]): >> >> Hm, wouldn't it be better if we required that all conditions are met >> in order to display them? > > No, one may want to look at only one delegation, or to see all > delegations that affect group foo or see all delegations that group bar > owns. Or they may want to list them all. > >> >>> + print "Delegation Name: " + a.name >>> + print "Group " + group_dn_to_cn[a.source_group] >> >> Trailing whitespace (it was there before, but still :) > > Yeah, the bane of my existence. I still blame Karl. > > New patch coming soon. > New patch attached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-79-delegation2.patch Type: text/x-patch Size: 3791 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 mnagy at redhat.com Fri Aug 22 18:03:43 2008 From: mnagy at redhat.com (Martin Nagy) Date: Fri, 22 Aug 2008 20:03:43 +0200 Subject: [Freeipa-devel] [PATCH] enhance ipa-listdelegation In-Reply-To: <48AEC9FE.7000009@redhat.com> References: <48ADD6D3.9010803@redhat.com> <20080822114501.212d7c17@notas> <48AEB9DD.5030302@redhat.com> <48AEC9FE.7000009@redhat.com> Message-ID: <20080822200343.1db037c3@notas> Rob Crittenden wrote: > > New patch attached. > > rob ack From rcritten at redhat.com Fri Aug 22 19:53:16 2008 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 22 Aug 2008 15:53:16 -0400 Subject: [Freeipa-devel] [PATCH] enhance ipa-listdelegation In-Reply-To: <20080822200343.1db037c3@notas> References: <48ADD6D3.9010803@redhat.com> <20080822114501.212d7c17@notas> <48AEB9DD.5030302@redhat.com> <48AEC9FE.7000009@redhat.com> <20080822200343.1db037c3@notas> Message-ID: <48AF192C.5010804@redhat.com> Martin Nagy wrote: > Rob Crittenden wrote: >> New patch attached. >> >> 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 davido at redhat.com Sun Aug 24 10:52:10 2008 From: davido at redhat.com (David O'Brien) Date: Sun, 24 Aug 2008 20:52:10 +1000 Subject: [Freeipa-devel] FreeIPA team introduces new mailing list Message-ID: <48B13D5A.7000407@redhat.com> To all freeipa-devel and freeipa-interest list members, The FreeIPA project team is pleased to announce the introduction of the freeipa-users mailing list. In conjunction with the freeipa-devel and freeipa-interest lists, this new list will provide a further source of information and discussion for users of FreeIPA. The freeipa-users list will focus on discussion of the deployment, configuration, and use of FreeIPA. It is the best place to ask "how to" questions and to share your experience with FreeIPA. The freeipa-devel list will continue to focus on discussion of the design and development of FreeIPA. The freeipa-interest list is primarily used for product-related announcements. You can subscribe to the freeipa-users mailing list at https://www.redhat.com/mailman/listinfo/freeipa-users Thank you for your interest in the FreeIPA project. -- The FreeIPA Team From aldop at mac.com Mon Aug 25 01:15:46 2008 From: aldop at mac.com (Aldo Pietropaolo) Date: Sun, 24 Aug 2008 20:15:46 -0500 Subject: [Freeipa-devel] Audit ability Message-ID: Hello freeIPA team, I have been in the identity management space now for more than 8 years. I am interested in your future features in regards to real time monitoring of security events and how they map to the identity stored in the directory service. This also brings up the topic of a real time identity monitor interface extension to freeIPA. I have done some work and research in this area and would like to entertain this as a possible proposal and contribution for an freeIPA extension. It looks like you are on a great road to solving some key problems for customers in a very cost efficient manner. This is the future of software! Best Regards, Aldo Pietropaolo -------------- next part -------------- An HTML attachment was scrubbed... URL: From aldop at mac.com Mon Aug 25 01:56:31 2008 From: aldop at mac.com (Aldo Pietropaolo) Date: Sun, 24 Aug 2008 20:56:31 -0500 Subject: [Freeipa-devel] Real Time Identity Monitoring Message-ID: Hello freeIPA team, I have taken initial ideas about an audit extension to freeIPA and corresponding monitoring clients and created a short 2 slide presentation to see if this would be a possibility for future versions. Looking forward to any feedback or ideas around this topic. Please see attached. Regards, Aldo Pietropaolo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeIPA-Audit-Plugins.pptx Type: application/x-mspowerpoint Size: 72211 bytes Desc: not available URL: From aldop at mac.com Mon Aug 25 02:03:48 2008 From: aldop at mac.com (Aldo Pietropaolo) Date: Sun, 24 Aug 2008 21:03:48 -0500 Subject: [Freeipa-devel] Re-send Message-ID: I apologize for the re-send but the .pptx file might be corrupt so I attached a pdf. Below are some notes I had in the second slide. ?The idea is to provide a stand alone freeIPA identity monitor that listens to real time event information performed in the directory service such as adds, modifications, deletes, password expiry, etc. These events would then be sent to freeIPA server and be processed by freeIPA Audit extensions in slide 1. Client side plugins may also be written to handle message normalization of event data and to send event to multiple event consumers if desired. ClientMonitor will register for identity events and receive the events asynchronously from the directory server. Call back interface may normalize the data with default schema and send to freeIPA Server for processing. Client monitor may also instantiate an audit plugin for additional processing.? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeIPA-Audit-Plugins.pdf Type: application/octet-stream Size: 290146 bytes Desc: not available URL: From jdennis at redhat.com Mon Aug 25 12:21:46 2008 From: jdennis at redhat.com (John Dennis) Date: Mon, 25 Aug 2008 08:21:46 -0400 Subject: [Freeipa-devel] Audit ability In-Reply-To: References: Message-ID: <48B2A3DA.5040109@redhat.com> Aldo Pietropaolo wrote: > Hello freeIPA team, > > I have been in the identity management space now for more than 8 > years. I am interested in your future features in regards to real time > monitoring of security events and how they map to the identity stored > in the directory service. This also brings up the topic of a real time > identity monitor interface extension to freeIPA. I have done some work > and research in this area and would like to entertain this as a > possible proposal and contribution for an freeIPA extension. First, lets clarify vocabulary. In IPA when we use the term audit it encompasses a wide range of "log" data from a variety of sources. However the term audit is also used to refer to the kernel audit subsystem and it's user space components. In IPA's world kernel audit is just one of many audit sources. Our primary focus for audit in the next release of IPA is centralized collection, storage, and search of data. We plan on collecting the data from a variety of sources, log files, streams, and via an API for IPA aware components. However, what is not on the immediate road map is real time monitoring and intrusion detection (IDS). Part of the reason is because the centralized collection and search of audit data is a large enough task in and of itself, but of equal importance is the fact the kernel audit team under the direction of Steve Grubb has added real time kernel audit support which feeds in the Prelude IDS. This gives a reasonably complete solution, albeit not under a single point of control. For more information concerning kernel audit IDS please see this: http://people.redhat.com/sgrubb/audit. The current thinking is that real time IDS is a specialized technology with currently available solutions, but centralized collection of a wide variety of audit log data with search capability is not however there is a strong demand from enterprises for this functionality in order to meet regulatory requirements. We expect the mapping of identity to be done via uid's on UNIX style systems because we expect uid's to be under the control of IPA and available in the directory server. We have not yet reached the point of designing how this would work for non-UNIX style systems. We of course would love to hear about your proposals and possible contributions, do take a moment to follow-up and if I've failed to answer any of your questions please don't hesitate to ask. Thank you for your interest in IPA. John -- John Dennis -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Mon Aug 25 12:44:31 2008 From: jdennis at redhat.com (John Dennis) Date: Mon, 25 Aug 2008 08:44:31 -0400 Subject: [Freeipa-devel] Re-send In-Reply-To: References: Message-ID: <48B2A92F.3070308@redhat.com> Aldo Pietropaolo wrote: > I apologize for the re-send but the .pptx file might be corrupt so I > attached a pdf. Below are some notes I had in the second slide. > > "The idea is to provide a stand alone freeIPA identity monitor that > listens to real time event information performed in the directory > service such as adds, modifications, deletes, password expiry, etc. > These events would then be sent to freeIPA server and be processed by > freeIPA Audit extensions in slide 1. Client side plugins may also be > written to handle message normalization of event data and to send > event to multiple event consumers if desired. > > > ClientMonitor will register for identity events and receive the events > asynchronously from the directory server. Call back interface may > normalize the data with default schema and send to freeIPA Server for > processing. Client monitor may also instantiate an audit plugin for > additional processing." This is an interesting idea. I would imagine the functionality could be provided by some sort of "trigger" which could be registered with IPA. When a matching event is seen then an action is taken. Directory server is one of the applications which we anticipate would be IPA audit aware and would use the IPA audit API. However, as I alluded to earlier we are not currently designing a real time monitoring system, although that may very well be a follow-on feature. One of my initial concerns with audit triggers distributing audit information to a listener is the security implications. It is vital audit data does not escape, if audit data were to be re-transmitted to a third party there would have to be a robust mechanism to assure the authenticity of the receiver and a centralized mechanism to shut the stream down. It is very hard to verify audit data sent to a third party will not escape from the 3rd party even if it's identity is verified. So while the idea of registering to receive audit events via a trigger has a lot of appeal in some scenarios I also imagine such a feature would be globally defeated by many organizations because it might violate enterprise security policy. These are some of the issues which would have to be solved. -- John Dennis -------------- next part -------------- An HTML attachment was scrubbed... URL: From aldop at mac.com Mon Aug 25 01:12:32 2008 From: aldop at mac.com (Aldo Pietropaolo) Date: Sun, 24 Aug 2008 20:12:32 -0500 Subject: [Freeipa-devel] Auditability Message-ID: Hello freeIPA team, I have been in the identity management space now for more than 8 years. I am interested in your future features in regards to real time monitoring of security events and how they map to the identity stored in the directory service. This also brings up the topic of a real time identity monitor interface extension to freeIPA. I have done some work and research in this area and would like to entertain this as a possible proposal and contribution for an freeIPA extension. It looks like you are on a great road to solving some key problems for customers in a very cost efficient manner. This is the future of software! Best Regards, Aldo Pietropaolo -------------- next part -------------- An HTML attachment was scrubbed... URL: From aldop at mac.com Mon Aug 25 13:31:07 2008 From: aldop at mac.com (Aldo Pietropaolo) Date: Mon, 25 Aug 2008 08:31:07 -0500 Subject: [Freeipa-devel] Re-send In-Reply-To: <48B2A92F.3070308@redhat.com> Message-ID: Hello John, I completely agree with your assessment. There would be some sort of authentication protocol between sender and receiver for both the client monitor / IPA and any third party receiver. Now there would also be some hashing mechanism or CRC to ensure that the message sent was intact. The other ideas that I have tested are client caching mechanisms to ensure the message gets sent in case of receiver failure. Although PKI might be a natural choice to provide keys for data encryption and confidentiality, there might be other options to make it less complicated to deploy and administer. There is of course an option to also include some sort of key server to rotate any symmetric keys used for clients and servers. Now the topic of kernel audit ability is an interesting topic I have not thought about before which is very interesting and necessary. It would be a very exciting to see this added to IPA. In any case, what areas do you need contribution in? Thank you for your feedback! Aldo Pietropaolo On 8/25/08 7:44 AM, "John Dennis" wrote: > Aldo Pietropaolo wrote: >> Re-send I apologize for the re-send but the .pptx file might be corrupt so I >> attached a pdf. Below are some notes I had in the second slide. >> >> ?The idea is to provide a stand alone freeIPA identity monitor that listens >> to real time event information performed in the directory service such as >> adds, modifications, deletes, password expiry, etc. These events would then >> be sent to freeIPA server and be processed by freeIPA Audit extensions in >> slide 1. Client side plugins may also be written to handle message >> normalization of event data and to send event to multiple event consumers if >> desired. >> >> >> ClientMonitor will register for identity events and receive the events >> asynchronously from the directory server. Call back interface may normalize >> the data with default schema and send to freeIPA Server for processing. >> Client monitor may also instantiate an audit plugin for additional >> processing.? >> > This is an interesting idea. I would imagine the functionality could be > provided by some sort of "trigger" which could be registered with IPA. When a > matching event is seen then an action is taken. Directory server is one of > the applications which we anticipate would be IPA audit aware and would use > the IPA audit API. However, as I alluded to earlier we are not currently > designing a real time monitoring system, although that may very well be a > follow-on feature. One of my initial concerns with audit triggers distributing > audit information to a listener is the security implications. It is vital > audit data does not escape, if audit data were to be re-transmitted to a third > party there would have to be a robust mechanism to assure the authenticity of > the receiver and a centralized mechanism to shut the stream down. It is very > hard to verify audit data sent to a third party will not escape from the 3rd > party even if it's identity is verified. So while the idea of registering to > receive audit events via a trigger has a lot of appeal in some scenarios I > also imagine such a feature would be globally defeated by many organizations > because it might violate enterprise security policy. These are some of the > issues which would have to be solved. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Aug 25 14:06:19 2008 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 25 Aug 2008 10:06:19 -0400 Subject: [Freeipa-devel] Re-send In-Reply-To: References: Message-ID: <48B2BC5B.3090701@redhat.com> Hello Aldo, We need contributions in many areas. Thanks for asking! We am actively working on the design pages. They will be put on the freeIPA site for review and comments. We will be publishing them throughout September. This would be a great opportunity for anyone to get involved more closely. As pages published the announcements will be sent and we will start coordination of the task execution between contributers. Thank you for your interest in freeIPA! Dmitri Pal Aldo Pietropaolo wrote: > Hello John, > > I completely agree with your assessment. There would be some sort of > authentication protocol between sender and receiver for both the > client monitor / IPA and any third party receiver. Now there would > also be some hashing mechanism or CRC to ensure that the message sent > was intact. The other ideas that I have tested are client caching > mechanisms to ensure the message gets sent in case of receiver > failure. Although PKI might be a natural choice to provide keys for > data encryption and confidentiality, there might be other options to > make it less complicated to deploy and administer. There is of course > an option to also include some sort of key server to rotate any > symmetric keys used for clients and servers. Now the topic of kernel > audit ability is an interesting topic I have not thought about before > which is very interesting and necessary. It would be a very exciting > to see this added to IPA. In any case, what areas do you need > contribution in? > > Thank you for your feedback! > > Aldo Pietropaolo > > On 8/25/08 7:44 AM, "John Dennis" wrote: > > Aldo Pietropaolo wrote: > > Re-send I apologize for the re-send but the .pptx file might > be corrupt so I attached a pdf. Below are some notes I had in > the second slide. > > ?The idea is to provide a stand alone freeIPA identity monitor > that listens to real time event information performed in the > directory service such as adds, modifications, deletes, > password expiry, etc. These events would then be sent to > freeIPA server and be processed by freeIPA Audit extensions in > slide 1. Client side plugins may also be written to handle > message normalization of event data and to send event to > multiple event consumers if desired. > > > ClientMonitor will register for identity events and receive > the events asynchronously from the directory server. Call back > interface may normalize the data with default schema and send > to freeIPA Server for processing. Client monitor may also > instantiate an audit plugin for additional processing.? > > This is an interesting idea. I would imagine the functionality > could be provided by some sort of "trigger" which could be > registered with IPA. When a matching event is seen then an action > is taken. Directory server is one of the applications which we > anticipate would be IPA audit aware and would use the IPA audit > API. However, as I alluded to earlier we are not currently > designing a real time monitoring system, although that may very > well be a follow-on feature. One of my initial concerns with audit > triggers distributing audit information to a listener is the > security implications. It is vital audit data does not escape, if > audit data were to be re-transmitted to a third party there would > have to be a robust mechanism to assure the authenticity of the > receiver and a centralized mechanism to shut the stream down. It > is very hard to verify audit data sent to a third party will not > escape from the 3rd party even if it's identity is verified. So > while the idea of registering to receive audit events via a > trigger has a lot of appeal in some scenarios I also imagine such > a feature would be globally defeated by many organizations because > it might violate enterprise security policy. These are some of the > issues which would have to be solved. > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 ssorce at redhat.com Thu Aug 28 20:58:38 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 28 Aug 2008 16:58:38 -0400 Subject: [Freeipa-devel] [PATCH] New plugin - ipa-winsync - for Windows sync support In-Reply-To: <48ADA8CF.6020908@redhat.com> References: <48ADA8CF.6020908@redhat.com> Message-ID: <1219957118.12117.227.camel@localhost.localdomain> On Thu, 2008-08-21 at 11:41 -0600, Rich Megginson wrote: > ipa-winsync is a new SLAPI plugin that allows IPA to hook into windows > AD <-> dirsrv user addition and modification, so that it can add > additional objectclasses and attributes required by IPA. This depends > on an as-yet-unreleased Fedora DS windows sync api, so it won't compile > out in the wild just yet. It also depends on the DNA plugin to > automatically assign the uidNumber. > > Several plugin points have been added to the existing windows sync code > to allow for callbacks in several places > * just before a DS user/group entry is added to AD > * just before an AD user/group entry is added to DS > * just before modifications are sent in either direction > * just before/after a total update occurs > * just before/after an incremental update occurs > * to get the DN of what a new DS entry synced from AD will be > > And others. This is how IPA uses these: > * NOTE: for this first version, the plugin only cares about user > entries, not groups > * at startup, IPA reads its global config from its plugin config entry > * when the sync agreement is created, the IPA agmt init callback is > called with the DS subtree and the AD subtree. The DS subtree should be > the user container (i.e. cn=users,cn=accounts,). The IPA > winsync plugin creates a domain specific callback object which will be > passed back to every callback. > * just before an init or update, the IPA winsync plugin is called. The > plugin searches the IPA configuration entries looking for information > like the Kerberos realm name, the list of objectclasses to add to new > entries, the posix homeDirectory prefix, and the default gidNumber. It > also grabs other information from the global plugin config, such as the > list of default attributes and values to add to each user entry. It > stores this information in the domain specific config callback object > * windows sync code calls into ipa-winsync to get the new user DN. By > default, ipa-winsync will "flatten" the DN. In AD it is common to have > users grouped into OUs - IPA will "flatten" these into just the > cn=users,cn=accounts container, and store the OUs in the OU attribute in > the new user entry > * windows sync code calls into ipa-winsync to add the new user - the > callback adds the list of objectclasses and attributes if any. There > are a couple of attributes which get special handling > ** krbPrincipalName - this is equal to the samAccountName (== uid) '@' > the realm name from the domain specific config > ** homeDirectory - domain config->homedir_prefix (read from ipa config) > '/' samAccountName (== uid) > ** gecos - set to the cn > > I've created a bug to track this and to attach patch files - > https://bugzilla.redhat.com/show_bug.cgi?id=459729 > Graphical diffs: > https://bugzilla.redhat.com/attachment.cgi?id=314729&action=diff > https://bugzilla.redhat.com/attachment.cgi?id=314730&action=diff > https://bugzilla.redhat.com/attachment.cgi?id=314731&action=diff > https://bugzilla.redhat.com/attachment.cgi?id=314732&action=diff > https://bugzilla.redhat.com/attachment.cgi?id=314733&action=diff > > Raw patch files: > https://bugzilla.redhat.com/attachment.cgi?id=314729 > https://bugzilla.redhat.com/attachment.cgi?id=314730 > https://bugzilla.redhat.com/attachment.cgi?id=314731 > https://bugzilla.redhat.com/attachment.cgi?id=314732 > https://bugzilla.redhat.com/attachment.cgi?id=314733 I've done an initial review of the code and it seem good. This is an half ack, I would like to test it once before a full ack, but if someone else feels confident (or has already tested it) please feel free to provide the other half of the ack :-D Simo. -- Simo Sorce * Red Hat, Inc * New York