From dpal at redhat.com Mon Aug 1 12:36:21 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 01 Aug 2011 08:36:21 -0400 Subject: [Freeipa-users] Once Again: Freeipa and Windows 7 In-Reply-To: References: Message-ID: <4E369DC5.2080504@redhat.com> On 07/31/2011 04:44 AM, roland.kaeser at intersoft-networks.ch wrote: > Hello > > I'm trying again to setup a pilot freeipa infrastructure for linux/afs > servers and windows clients. So the first (and most hard) task is to > join a "windows 7" into freeipa/kerberos. > I already read the available documentation and setup my pilot client > with the following parameters: > > ksetup /setdomain SAMPLE.CH > ksetup /SetRealm SAMPLE.CH > ksetup /AddKdc SAMPLE.CH freeipa.sample.ch > ksetup /AddKpasswd SAMPLE.CH freeipa.sample.ch > ksetup /SetComputerPassword MYPASSWORDHERE > ksetup /MapUser * * > > Changed the available encryption types for kerberos in secpool.msc > under Local Policies/Security Options/Network Security/Network > Security: Configure encryption types allowed for Kerberos to: > DES_CBC_CRC,DES_CBC_MD5,RC4_HMAC_MD5,AES128_HMAC_SHA1,AES256_HMAC_SHA1, Furter > encryption types > > Created a host principal in the freeipa webinterface and set the OTP > to MYPASSWORDHERE. You might be confused with this feature. This password is used with ipa-client auto enroll so that one can join a client into the IPA domain. The OTP is used for the authentication in this scenario. In your case you are not using the client so OTP is irrelevant. We do not test Win 7 hosts as clients but we know that in the past some people had success with such configuration. First please search archives as there was an earlier attempt with freeipa 2.0 earlier this year. As I recall it was successful. And earlier attempt with 1.x was covered here: http://freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_%28Windows/Linux%29_-_Step_by_step > > The clock of the windows 7 machine is synced with the ntpd of the > freeipa server. > > When I try to login I get the usual password change request dialog on > the windows 7 client and the following krb5log entry: > > Jul 31 10:39:05 freeipa.sample.ch krb5kdc[6780](info): AS_REQ (7 > etypes {18 17 23 3 1 24 -135}) 192.168.1.90: CLIENT KEY EXPIRED: > isn-roland at SAMPLE.CH for krbtgt/SAMPLE.CH at SAMPLE.CH, Password has expired > > When try to change the password I get only "The username or password > is wrong" with the following krb5log entries: > > Jul 31 10:39:43 freeipa.sample.ch krb5kdc[6780](info): AS_REQ (7 > etypes {18 17 23 3 1 24 -135}) 192.168.1.90: NEEDED_PREAUTH: > isn-roland at SAMPLE.CH for kadmin/changepw at SAMPLE.CH, Additional > pre-authentication required > Jul 31 10:39:43 freeipa.sample.ch krb5kdc[6780](info): preauth > (timestamp) verify failure: Decrypt integrity check failed > Jul 31 10:39:43 freeipa.sample.ch krb5kdc[6780](info): AS_REQ (7 > etypes {18 17 23 3 1 24 -135}) 192.168.1.90: PREAUTH_FAILED: > isn-roland at SAMPLE.CH for kadmin/changepw at SAMPLE.CH, Decrypt integrity > check failed > Jul 31 10:39:43 freeipa.sample.ch krb5kdc[6780](info): preauth > (timestamp) verify failure: Decrypt integrity check failed > Jul 31 10:39:43 freeipa.sample.ch krb5kdc[6780](info): AS_REQ (7 > etypes {18 17 23 3 1 24 -135}) 192.168.1.90: PREAUTH_FAILED: > isn-roland at SAMPLE.CH for kadmin/changepw at SAMPLE.CH, Decrypt integrity > check failed > > After long googeling and long investigation, I can't see the issue > behind this problems. > > Does someone has setup a similar environment and give me some advice > to get this up and running? > > Regards > > Roland > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Aug 1 13:02:06 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 01 Aug 2011 09:02:06 -0400 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <4E35DD48.5080405@net-optima.fr> References: <4E2EC378.9050401@romal.de>, <4E2EC930.1060501@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E35DD48.5080405@net-optima.fr> Message-ID: <4E36A3CE.90201@redhat.com> Sylvain PANNETRAT wrote: > Hi, > > You can take the file with F14 intallation DVD. It work for me. You may > need to make a script to be able to swap you libcurl file, because when > you install the old version, yum doesn't work any more. This has worked consistently for me on multiple distros: # yum downgrade curl libcurl* If you want to manually downgrade then fetching the last release from koji is probably a better way. rob > > Regards, > > Sylvain PANNETRAT > > Le 01/08/11 00:30, Steven Jones a ?crit : >> Hi, >> >> >> For RHEL6.1 64bit, Can you tell me which "old" libcurl is the right one? >> >> I seem to be getting bogged down with RH support....seems the >> gdowngrade wnet from x86_64 to i686 but still the same subpatch >> -26....I think I want -16? >> >> :/ >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> ________________________________________ >> From: Rob Crittenden [rcritten at redhat.com] >> Sent: Friday, 29 July 2011 10:17 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >> >> Steven Jones wrote: >>> client install attempt info >> What version of libcurl do you have installed on the client? I realize >> you downgraded it, just curious what you ended up with. >> >> Can you look on the server and see if there is an exception related to >> principal not being set? >> >> rob >> >>> regards >>> >>> Steven Jones >>> >>> Technical Specialist - Linux RHCE >>> >>> Victoria University, Wellington, NZ >>> >>> ________________________________________ >>> From: freeipa-users-bounces at redhat.com >>> [freeipa-users-bounces at redhat.com] on behalf of Steven Jones >>> [Steven.Jones at vuw.ac.nz] >>> Sent: Friday, 29 July 2011 9:59 a.m. >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >>> >>> I just downgraded libcurl and curl on rhel6.1 client....still broken. >>> >>> >>> regards >>> >>> Steven Jones >>> >>> Technical Specialist - Linux RHCE >>> >>> Victoria University, Wellington, NZ >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Mon Aug 1 13:10:32 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 01 Aug 2011 09:10:32 -0400 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <4E2EC378.9050401@romal.de>, <4E2EC930.1060501@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4E36A5C8.3030401@redhat.com> Steven Jones wrote: > Hi, > > > For RHEL6.1 64bit, Can you tell me which "old" libcurl is the right one? rpm -q --changelog will show the history of the package, including the v-r. So looks like 7.19.7-26 is what you want. > > I seem to be getting bogged down with RH support....seems the gdowngrade wnet from x86_64 to i686 but still the same subpatch -26....I think I want -16? That is very odd. Perhaps try with arch appended: # yum downgrade curl.x86_64 libcurl*.x86_64 curl.i686 libcurl*.i686 rob > > :/ > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Friday, 29 July 2011 10:17 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Steven Jones wrote: >> client install attempt info > > What version of libcurl do you have installed on the client? I realize > you downgraded it, just curious what you ended up with. > > Can you look on the server and see if there is an exception related to > principal not being set? > > rob > >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> ________________________________________ >> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] >> Sent: Friday, 29 July 2011 9:59 a.m. >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >> >> I just downgraded libcurl and curl on rhel6.1 client....still broken. >> >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > From roland.kaeser at intersoft-networks.ch Mon Aug 1 14:29:08 2011 From: roland.kaeser at intersoft-networks.ch (roland.kaeser at intersoft-networks.ch) Date: Mon, 1 Aug 2011 16:29:08 +0200 Subject: [Freeipa-users] Antwort: Re: Once Again: Freeipa and Windows 7 In-Reply-To: <4E369DC5.2080504@redhat.com> References: <4E369DC5.2080504@redhat.com> Message-ID: Hello > You might be confused with this feature. This password is used with ipa-client auto enroll so that one can join a client into the IPA domain. The OTP is used for the authentication in this scenario. > In your case you are not using the client so OTP is irrelevant. > We do not test Win 7 hosts as clients but we know that in the past some people had success with such configuration. > > First please search archives as there was an earlier attempt with freeipa 2.0 earlier this year. As I recall it was successful. And earlier attempt with 1.x was covered here: > ht tp://freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_%28Windows/Linux%29_-_Step_by_step The steps described in my mail where exactly the steps documented in the link above where its written under "Configuring Windows Client": ------------------ 3. On the IPA Server add the host principal and set the password for the xp client. ... ksetup /setmachpassword (the same password you have set in IPA server) ------------------ So this confuses me a lot more. Specially because the description in the discussed document just doesn't work. And, sorry to say that, it also says exactly the converse of what You wrote in Your mail. Also specially. When I use ipa-getkeytab as described in the document: ipa-getkeytab -s ds.example.com -p host/bmdata01.example.com -e des-cbc-crc -k krb5.keytab.txt -P I only get "SASL Bind failed!". So I only can create the host principal in the web interface. Then there is a kind of missing link between the exported keytab and what to do with it on the windows client. I wrote my mail only because I couldn't find any solution while googleing for it and also read the freeipa archives. The only thread I found in the archives regarding to Windows 7 and Freeipa was: https://www.redhat.com/archives/freeipa-users/2011-February/msg00039.html About the same question and ended in question from Simo about the installed krb5-package. I know its annoying with this windows questions but the most of us have to deal with mixed environments. Also Redhat has to deal with such environments for RHEV manager requires server 2008r2 and active directory (We currently make also a pilot for a larger VDI project). So it cannot be that this scenario (freeipa server and windows 7 clients) was never tested or documented As we (at our side) cannot change the customers desktop from windows to linux (cause there are already a lot of special applications which depends on a windows desktop), but we can choose the serverplatform and we wan't to have linux (specially rhel) as serverplatform and most desirable: freeipa as authentication and identity platform. But this can only work with a full integration of the windows clients into freeipa. Sorry for the hard mail but as I and My colleagues what to have Linux and opensource installed whenever possible, we face often the problem that the developers cannot see the problems and needs of us engineers and administrators in the front where where we deal with the heterogenous environments of our customers. So I hope somebody can post a final and working documentation about the windows 7 integration into freeipa. We realy depend on this. Regards Roland Von: Dmitri Pal An: freeipa-users at redhat.com Datum: 01.08.2011 14:39 Betreff: Re: [Freeipa-users] Once Again: Freeipa and Windows 7 Gesendet von: freeipa-users-bounces at redhat.com On 07/31/2011 04:44 AM, roland.kaeser at intersoft-networks.ch wrote: Hello I'm trying again to setup a pilot freeipa infrastructure for linux/afs servers and windows clients. So the first (and most hard) task is to join a "windows 7" into freeipa/kerberos. I already read the available documentation and setup my pilot client with the following parameters: ksetup /setdomain SAMPLE.CH ksetup /SetRealm SAMPLE.CH ksetup /AddKdc SAMPLE.CH freeipa.sample.ch ksetup /AddKpasswd SAMPLE.CH freeipa.sample.ch ksetup /SetComputerPassword MYPASSWORDHERE ksetup /MapUser * * Changed the available encryption types for kerberos in secpool.msc under Local Policies/Security Options/Network Security/Network Security: Configure encryption types allowed for Kerberos to: DES_CBC_CRC,DES_CBC_MD5,RC4_HMAC_MD5,AES128_HMAC_SHA1,AES256_HMAC_SHA1, Furter encryption types Created a host principal in the freeipa webinterface and set the OTP to MYPASSWORDHERE. You might be confused with this feature. This password is used with ipa-client auto enroll so that one can join a client into the IPA domain. The OTP is used for the authentication in this scenario. In your case you are not using the client so OTP is irrelevant. We do not test Win 7 hosts as clients but we know that in the past some people had success with such configuration. First please search archives as there was an earlier attempt with freeipa 2.0 earlier this year. As I recall it was successful. And earlier attempt with 1.x was covered here: http://freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_%28Windows/Linux%29_-_Step_by_step The clock of the windows 7 machine is synced with the ntpd of the freeipa server. When I try to login I get the usual password change request dialog on the windows 7 client and the following krb5log entry: Jul 31 10:39:05 freeipa.sample.ch krb5kdc[6780](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.1.90: CLIENT KEY EXPIRED: isn-roland at SAMPLE.CH for krbtgt/SAMPLE.CH at SAMPLE.CH, Password has expired When try to change the password I get only "The username or password is wrong" with the following krb5log entries: Jul 31 10:39:43 freeipa.sample.ch krb5kdc[6780](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.1.90: NEEDED_PREAUTH: isn-roland at SAMPLE.CH for kadmin/changepw at SAMPLE.CH, Additional pre-authentication required Jul 31 10:39:43 freeipa.sample.ch krb5kdc[6780](info): preauth (timestamp) verify failure: Decrypt integrity check failed Jul 31 10:39:43 freeipa.sample.ch krb5kdc[6780](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.1.90: PREAUTH_FAILED: isn-roland at SAMPLE.CH for kadmin/changepw at SAMPLE.CH, Decrypt integrity check failed Jul 31 10:39:43 freeipa.sample.ch krb5kdc[6780](info): preauth (timestamp) verify failure: Decrypt integrity check failed Jul 31 10:39:43 freeipa.sample.ch krb5kdc[6780](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.1.90: PREAUTH_FAILED: isn-roland at SAMPLE.CH for kadmin/changepw at SAMPLE.CH, Decrypt integrity check failed After long googeling and long investigation, I can't see the issue behind this problems. Does someone has setup a similar environment and give me some advice to get this up and running? Regards Roland _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Aug 1 14:47:56 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 01 Aug 2011 08:47:56 -0600 Subject: [Freeipa-users] Dead Freeipa In-Reply-To: <1311852629.19717.275.camel@willson.li.ssimo.org> References: <833D8E48405E064EBC54C84EC6B36E40369C89D9@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E307F63.2060107@redhat.com> , <833D8E48405E064EBC54C84EC6B36E40369C9568@STAWINCOX10MBX1.staff.vuw.ac.nz> , <833D8E48405E064EBC54C84EC6B36E40369C9587@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369C95A0@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E3088C5.6040105@redhat.com> <1311852629.19717.275.camel@willson.li.ssimo.org> Message-ID: <4E36BC9C.6000704@redhat.com> On 07/28/2011 05:30 AM, Simo Sorce wrote: > On Wed, 2011-07-27 at 15:53 -0600, Rich Megginson wrote: >> On 07/27/2011 03:40 PM, Steven Jones wrote: >>> regards >> Thanks. To follow up from IRC: >> If Steven starts up dirsrv manually, then krb, then named then httpd, >> everything works fine. Not sure what the ipa script is doing that >> kills >> dirsrv immediately upon startup. > The only case where ipactl stops dirsrv is when it fails to find > information with the ldapsearch done immediately after dirsrv starts. > > Is it possible the dirsrv init script returns before dirsrv is actually > ready to serve requests ? It is possible. Is there any way to get the output and/or result code of that ldapsearch? > Simo. > From dpal at redhat.com Mon Aug 1 14:58:57 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 01 Aug 2011 10:58:57 -0400 Subject: [Freeipa-users] Antwort: Re: Once Again: Freeipa and Windows 7 In-Reply-To: References: <4E369DC5.2080504@redhat.com> Message-ID: <4E36BF31.5060802@redhat.com> On 08/01/2011 10:29 AM, roland.kaeser at intersoft-networks.ch wrote: > Hello > > >You might be confused with this feature. This password is used with > ipa-client auto enroll so that one can join a client into the IPA > domain. The OTP is used for the authentication in this scenario. > >In your case you are not using the client so OTP is irrelevant. > >We do not test Win 7 hosts as clients but we know that in the past > some people had success with such configuration. > > > >First please search archives as there was an earlier attempt with > freeipa 2.0 earlier this year. As I recall it was successful. And > earlier attempt with 1.x was covered here: > >http://freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_%28Windows/Linux%29_-_Step_by_step > > The steps described in my mail where exactly the steps documented in > the link above where its written under "Configuring Windows Client": > ------------------ > 3. On the IPA Server add the host principal and set the password for > the xp client. > .. > ksetup /setmachpassword (the same password you have set in > IPA server) > ------------------ > > So this confuses me a lot more. Specially because the description in > the discussed document just doesn't work. And, sorry to say that, it > also says exactly the converse of what You wrote in Your mail. > Also specially. When I use ipa-getkeytab as described in the document: > > ipa-getkeytab -s ds.example.com -p host/bmdata01.example.com -e > des-cbc-crc -k krb5.keytab.txt -P > > I only get "SASL Bind failed!". So I only can create the host > principal in the web interface. Then there is a kind of missing link > between the exported keytab and what to do with it on the windows client. > > I wrote my mail only because I couldn't find any solution while > googleing for it and also read the freeipa archives. The only thread I > found in the archives regarding to Windows 7 and Freeipa was: > > _https://www.redhat.com/archives/freeipa-users/2011-February/msg00039.html_ > > About the same question and ended in question from Simo about the > installed krb5-package. I know its annoying with this windows > questions but the most of us have to deal with mixed environments. > Also Redhat has to deal with such environments for RHEV manager > requires server 2008r2 and active directory (We currently make also a > pilot for a larger VDI project). So it cannot be that this scenario > (freeipa server and windows 7 clients) was never tested or documented > > As we (at our side) cannot change the customers desktop from windows > to linux (cause there are already a lot of special applications which > depends on a windows desktop), but we can choose the serverplatform > and we wan't to have linux (specially rhel) as serverplatform and most > desirable: freeipa as authentication and identity platform. But this > can only work with a full integration of the windows clients into freeipa. > > Sorry for the hard mail but as I and My colleagues what to have Linux > and opensource installed whenever possible, we face often the problem > that the developers cannot see the problems and needs of us engineers > and administrators in the front where where we deal with the > heterogenous environments of our customers. > > So I hope somebody can post a final and working documentation about > the windows 7 integration into freeipa. We realy depend on this. > > Regards > > Roland Let me be fair and frank. We are not testing Windows clients with IPA. It has been done successfully by different people in the community several times and comments from them can be found in archive. Making Windows clients work with IPA is a big challenge which we have not taken on and do not plant to. The point is that in our opinion IPA would not be able to replace AD for Windows clients. There are too many protocols and specific properties that a Windows client expects from its DC. So the solution can only be very limited and in most cases not acceptable. So we think that the best approach to address the issue of Windows clients is to have them in AD but let IPA be the DC for the Linux servers. For the current version one can use synchronization of the user accounts from AD to IPA. It is not perfect but this is best available at the moment. We are actively working on a much better solution - Cross Forest Kerberos trusts. Hopefully it will be available next year. That feature would require users connecting from their desktops from AD domain have a SSO with services in IPA domain. There are other use cases too. But back to your point about clients working with IPA. We do not know about better info than the one we mentioned. There might be some MIT documentation about how to join a Windows machine to MIT KDC. If this can be done I am sure the same can be done with IPA. > > > > > > > Von: Dmitri Pal > An: freeipa-users at redhat.com > Datum: 01.08.2011 14:39 > Betreff: Re: [Freeipa-users] Once Again: Freeipa and Windows 7 > Gesendet von: freeipa-users-bounces at redhat.com > ------------------------------------------------------------------------ > > > > On 07/31/2011 04:44 AM, _roland.kaeser at intersoft-networks.ch_ > wrote: > Hello > > I'm trying again to setup a pilot freeipa infrastructure for linux/afs > servers and windows clients. So the first (and most hard) task is to > join a "windows 7" into freeipa/kerberos. > I already read the available documentation and setup my pilot client > with the following parameters: > > ksetup /setdomain SAMPLE.CH > ksetup /SetRealm SAMPLE.CH > ksetup /AddKdc SAMPLE.CH freeipa.sample.ch > ksetup /AddKpasswd SAMPLE.CH freeipa.sample.ch > ksetup /SetComputerPassword MYPASSWORDHERE > ksetup /MapUser * * > > Changed the available encryption types for kerberos in secpool.msc > under Local Policies/Security Options/Network Security/Network > Security: Configure encryption types allowed for Kerberos to: > DES_CBC_CRC,DES_CBC_MD5,RC4_HMAC_MD5,AES128_HMAC_SHA1,AES256_HMAC_SHA1, Furter > encryption types > > Created a host principal in the freeipa webinterface and set the OTP > to MYPASSWORDHERE. > > You might be confused with this feature. This password is used with > ipa-client auto enroll so that one can join a client into the IPA > domain. The OTP is used for the authentication in this scenario. > In your case you are not using the client so OTP is irrelevant. > We do not test Win 7 hosts as clients but we know that in the past > some people had success with such configuration. > > First please search archives as there was an earlier attempt with > freeipa 2.0 earlier this year. As I recall it was successful. And > earlier attempt with 1.x was covered here:_ > __http://freeipa.org/page/Implementing_FreeIPA_in_a_mixed_Environment_%28Windows/Linux%29_-_Step_by_step_ > > > The clock of the windows 7 machine is synced with the ntpd of the > freeipa server. > > When I try to login I get the usual password change request dialog on > the windows 7 client and the following krb5log entry: > > Jul 31 10:39:05 freeipa.sample.ch krb5kdc[6780](info): AS_REQ (7 > etypes {18 17 23 3 1 24 -135}) 192.168.1.90: CLIENT KEY EXPIRED: > _isn-roland at SAMPLE.CH_ for > _krbtgt/SAMPLE.CH at SAMPLE.CH_ , > Password has expired > > When try to change the password I get only "The username or password > is wrong" with the following krb5log entries: > > Jul 31 10:39:43 freeipa.sample.ch krb5kdc[6780](info): AS_REQ (7 > etypes {18 17 23 3 1 24 -135}) 192.168.1.90: NEEDED_PREAUTH: > _isn-roland at SAMPLE.CH_ for > _kadmin/changepw at SAMPLE.CH_ , > Additional pre-authentication required > Jul 31 10:39:43 freeipa.sample.ch krb5kdc[6780](info): preauth > (timestamp) verify failure: Decrypt integrity check failed > Jul 31 10:39:43 freeipa.sample.ch krb5kdc[6780](info): AS_REQ (7 > etypes {18 17 23 3 1 24 -135}) 192.168.1.90: PREAUTH_FAILED: > _isn-roland at SAMPLE.CH_ for > _kadmin/changepw at SAMPLE.CH_ , > Decrypt integrity check failed > Jul 31 10:39:43 freeipa.sample.ch krb5kdc[6780](info): preauth > (timestamp) verify failure: Decrypt integrity check failed > Jul 31 10:39:43 freeipa.sample.ch krb5kdc[6780](info): AS_REQ (7 > etypes {18 17 23 3 1 24 -135}) 192.168.1.90: PREAUTH_FAILED: > _isn-roland at SAMPLE.CH_ for > _kadmin/changepw at SAMPLE.CH_ , > Decrypt integrity check failed > > After long googeling and long investigation, I can't see the issue > behind this problems. > > Does someone has setup a similar environment and give me some advice > to get this up and running? > > Regards > > Roland > > > _______________________________________________ > Freeipa-users mailing list > _Freeipa-users at redhat.com_ > _https://www.redhat.com/mailman/listinfo/freeipa-users_ > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > _www.redhat.com/carveoutcosts/_ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at romal.de Mon Aug 1 18:31:08 2011 From: fedora at romal.de (Robert M. Albrecht) Date: Mon, 01 Aug 2011 20:31:08 +0200 Subject: [Freeipa-users] FreeIPA for Linux desktop deployment In-Reply-To: <4E30EF8B.8010008@romal.de> References: <1311701212.19704.YahooMailClassic@web161320.mail.bf1.yahoo.com> <4E30EF8B.8010008@romal.de> Message-ID: <4E36F0EC.2050202@romal.de> Hi, any ideas ? Something I can help with ? cu romal Am 28.07.11 07:11, schrieb Robert M. Albrecht: > Hi, > > my IPA is still dying. > > Strange thing is,it's very random. Most times is stops after some > minutes, but yesterday named worked for several hours. > > If it helps, I can provide shell access to the system. > > cu romal > > > > > Am 26.07.11 19:26, schrieb nasir nasir: >> >> Hi all, >> >> After applying the patches and restarting the service, everything was >> fine for about couple of hours. But again it crashed and gave core >> dump. I have updated the latest /var/log/messages and core dump with >> the bugzilla report. >> Please help. >> >> Regards, >> Nidal >> >> --- On Tue, 7/26/11, Adam Tkac wrote: >> >>> From: Adam Tkac >>> Subject: Re: [Freeipa-users] FreeIPA for Linux desktop deployment >>> To: "nasir nasir" >>> Cc: freeipa-users at redhat.com, "Robert M. Albrecht" >>> Date: Tuesday, July 26, 2011, 7:58 AM >>> On 07/26/2011 04:51 PM, nasir nasir >>> wrote: >>>> Hi All, >>>> >>>> Thanks a ton for every one who helped to have such a >>> quick fix for this issue. I truly appreciate it. I have >>> applied the patch (generated from the source rpm and applied >>> with rpm -Uvh ***) and restarted IPA service. Had a >>> preliminary test of the services and everything seems to be >>> fine. Will keep watching and update the list in due course. >>> >>>> >>>> Adam, >>>> >>>> Do you want me to update the bugzilla now or wait for >>> a couple of days to observe ? >>> >>> Thanks for your feedback, you don't have to update >>> bugzilla, update it >>> only in case if named crashes again, please. For now I will >>> consider the >>> patch as correct. >>> >>> Regards, Adam >>> >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From kollathodi at yahoo.com Mon Aug 1 18:56:14 2011 From: kollathodi at yahoo.com (nasir nasir) Date: Mon, 1 Aug 2011 11:56:14 -0700 (PDT) Subject: [Freeipa-users] FreeIPA for Linux desktop deployment In-Reply-To: <4E36F0EC.2050202@romal.de> Message-ID: <1312224974.26738.YahooMailClassic@web161311.mail.bf1.yahoo.com> Hi, The latest patch supplied by Adam have been applied to my system and it seems to be stable for the the past 3 days. I have already mailed Adam(Redhat developer for bind) and waiting for him to confirm this and close the bug. If you want the patch(for rhel 6.1), let me know. Regards, Nidal --- On Mon, 8/1/11, Robert M. Albrecht wrote: > From: Robert M. Albrecht > Subject: Re: [Freeipa-users] FreeIPA for Linux desktop deployment > To: freeipa-users at redhat.com > Date: Monday, August 1, 2011, 11:31 AM > Hi, > > any ideas ? Something I can help with ? > > cu romal > > > Am 28.07.11 07:11, schrieb Robert M. Albrecht: > > Hi, > > > > my IPA is still dying. > > > > Strange thing is,it's very random. Most times is stops > after some > > minutes, but yesterday named worked for several > hours. > > > > If it helps, I can provide shell access to the > system. > > > > cu romal > > > > > > > > > > Am 26.07.11 19:26, schrieb nasir nasir: > >> > >> Hi all, > >> > >> After applying the patches and restarting the > service, everything was > >> fine for about couple of hours. But again it > crashed and gave core > >> dump. I have updated the latest /var/log/messages > and core dump with > >> the bugzilla report. > >> Please help. > >> > >> Regards, > >> Nidal > >> > >> --- On Tue, 7/26/11, Adam Tkac > wrote: > >> > >>> From: Adam Tkac > >>> Subject: Re: [Freeipa-users] FreeIPA for Linux > desktop deployment > >>> To: "nasir nasir" > >>> Cc: freeipa-users at redhat.com, > "Robert M. Albrecht" > >>> Date: Tuesday, July 26, 2011, 7:58 AM > >>> On 07/26/2011 04:51 PM, nasir nasir > >>> wrote: > >>>> Hi All, > >>>> > >>>> Thanks a ton for every one who helped to > have such a > >>> quick fix for this issue. I truly appreciate > it. I have > >>> applied the patch (generated from the source > rpm and applied > >>> with rpm -Uvh ***) and restarted IPA service. > Had a > >>> preliminary test of the services and > everything seems to be > >>> fine. Will keep watching and update the list > in due course. > >>> > >>>> > >>>> Adam, > >>>> > >>>> Do you want me to update the bugzilla now > or wait for > >>> a couple of days to observe ? > >>> > >>> Thanks for your feedback, you don't have to > update > >>> bugzilla, update it > >>> only in case if named crashes again, please. > For now I will > >>> consider the > >>> patch as correct. > >>> > >>> Regards, Adam > >>> > >> > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From fedora at romal.de Mon Aug 1 19:24:47 2011 From: fedora at romal.de (Robert M. Albrecht) Date: Mon, 01 Aug 2011 21:24:47 +0200 Subject: [Freeipa-users] FreeIPA for Linux desktop deployment In-Reply-To: <1312224974.26738.YahooMailClassic@web161311.mail.bf1.yahoo.com> References: <1312224974.26738.YahooMailClassic@web161311.mail.bf1.yahoo.com> Message-ID: <4E36FD7F.1040802@romal.de> Hi, [root at zerberus ~]# rpm --query bind bind-9.8.0-8.P4.fc15.x86_64 it got worse on my system. Before the patch the named lived sometimes for several minutes. After the patch, named dies always after some seconds. [root at zerberus ~]# dig www.google.com ; <<>> DiG 9.8.0-P4-RedHat-9.8.0-8.P4.fc15 <<>> www.google.com ;; global options: +cmd ;; connection timed out; no servers could be reached [root at zerberus ~]# cat /etc/resolv.conf nameserver 127.0.0.1 nameserver ::1 domain vorlon.lan cu romal Am 01.08.11 20:56, schrieb nasir nasir: > Hi, > > The latest patch supplied by Adam have been applied to my system and it seems to be stable for the the past 3 days. I have already mailed Adam(Redhat developer for bind) and waiting for him to confirm this and close the bug. If you want the patch(for rhel 6.1), let me know. > > Regards, > Nidal > > > --- On Mon, 8/1/11, Robert M. Albrecht wrote: > >> From: Robert M. Albrecht >> Subject: Re: [Freeipa-users] FreeIPA for Linux desktop deployment >> To: freeipa-users at redhat.com >> Date: Monday, August 1, 2011, 11:31 AM >> Hi, >> >> any ideas ? Something I can help with ? >> >> cu romal >> >> >> Am 28.07.11 07:11, schrieb Robert M. Albrecht: >>> Hi, >>> >>> my IPA is still dying. >>> >>> Strange thing is,it's very random. Most times is stops >> after some >>> minutes, but yesterday named worked for several >> hours. >>> >>> If it helps, I can provide shell access to the >> system. >>> >>> cu romal >>> >>> >>> >>> >>> Am 26.07.11 19:26, schrieb nasir nasir: >>>> >>>> Hi all, >>>> >>>> After applying the patches and restarting the >> service, everything was >>>> fine for about couple of hours. But again it >> crashed and gave core >>>> dump. I have updated the latest /var/log/messages >> and core dump with >>>> the bugzilla report. >>>> Please help. >>>> >>>> Regards, >>>> Nidal >>>> >>>> --- On Tue, 7/26/11, Adam Tkac >> wrote: >>>> >>>>> From: Adam Tkac >>>>> Subject: Re: [Freeipa-users] FreeIPA for Linux >> desktop deployment >>>>> To: "nasir nasir" >>>>> Cc: freeipa-users at redhat.com, >> "Robert M. Albrecht" >>>>> Date: Tuesday, July 26, 2011, 7:58 AM >>>>> On 07/26/2011 04:51 PM, nasir nasir >>>>> wrote: >>>>>> Hi All, >>>>>> >>>>>> Thanks a ton for every one who helped to >> have such a >>>>> quick fix for this issue. I truly appreciate >> it. I have >>>>> applied the patch (generated from the source >> rpm and applied >>>>> with rpm -Uvh ***) and restarted IPA service. >> Had a >>>>> preliminary test of the services and >> everything seems to be >>>>> fine. Will keep watching and update the list >> in due course. >>>>> >>>>>> >>>>>> Adam, >>>>>> >>>>>> Do you want me to update the bugzilla now >> or wait for >>>>> a couple of days to observe ? >>>>> >>>>> Thanks for your feedback, you don't have to >> update >>>>> bugzilla, update it >>>>> only in case if named crashes again, please. >> For now I will >>>>> consider the >>>>> patch as correct. >>>>> >>>>> Regards, Adam >>>>> >>>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > From Steven.Jones at vuw.ac.nz Mon Aug 1 20:26:02 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 1 Aug 2011 20:26:02 +0000 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <4E36A5C8.3030401@redhat.com> References: <4E2EC378.9050401@romal.de>,<4E2EC930.1060501@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz> As below, I have that rpm and I have a failure. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ steven.jones at vuw.ac.nz 0064 4 463 6272 8><------------ rpm -q --changelog will show the history of the package, including the v-r. So looks like 7.19.7-26 is what you want. 8><-------------- See attached, its what I have, so there must be some other issue? > > I seem to be getting bogged down with RH support....seems the gdowngrade wnet from x86_64 to i686 but still the same subpatch -26....I think I want -16? That is very odd. Perhaps try with arch appended: # yum downgrade curl.x86_64 libcurl*.x86_64 curl.i686 libcurl*.i686 rob 8><-------- I find it not unusual for RH to break yum...... regards -------------- next part -------------- A non-text attachment was scrubbed... Name: lib-curl-freeipa.jpeg Type: image/jpeg Size: 122464 bytes Desc: lib-curl-freeipa.jpeg URL: From rcritten at redhat.com Mon Aug 1 20:51:23 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 01 Aug 2011 16:51:23 -0400 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <4E2EC378.9050401@romal.de>, <4E2EC930.1060501@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4E3711CB.3060604@redhat.com> Steven Jones wrote: > As below, I have that rpm and I have a failure. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > steven.jones at vuw.ac.nz 0064 4 463 6272 > > 8><------------ > > rpm -q --changelog will show the history of the package, including the v-r. > > So looks like 7.19.7-26 is what you want. > > 8><-------------- > > See attached, its what I have, so there must be some other issue? > >> >> I seem to be getting bogged down with RH support....seems the gdowngrade wnet from x86_64 to i686 but still the same subpatch -26....I think I want -16? > > That is very odd. Perhaps try with arch appended: > > # yum downgrade curl.x86_64 libcurl*.x86_64 curl.i686 libcurl*.i686 > > rob > > 8><-------- > > I find it not unusual for RH to break yum...... > > regards rpm -e != yum downgrade According to this you have the version of libcurl that supports ticket forwarding. Are you saying you still get an error when you try enrollment? This has to be installed on each client, not the server. The insulting comments are not necessary. rob From Steven.Jones at vuw.ac.nz Mon Aug 1 21:49:02 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 1 Aug 2011 21:49:02 +0000 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <4E3711CB.3060604@redhat.com> References: <4E2EC378.9050401@romal.de>,<4E2EC930.1060501@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40369DE45D@STAWINCOX10MBX1.staff.vuw.ac.nz> Sorry, what's insulting? That it is not unusual for Red Hat to break dependencies in yum/up2date? This is a fact, as a customer its was not unusual that I experienced failures at RHN. This was several times a year within the dependencies, it is getting better, but libcurl shows an oops still happens. Bear in mind that IPA will be like AD, breaking AD in Organisations throughout the World would be a major event and a PR disaster for Microsoft. Equally in the future having the same event with IPA will be a major issue for Red Hat and their customers. So at Red Hat I would hope someone is taking a strategic look at the libcurl event and putting in place or modifying "something" (policy/protocol/proceedure etc) to try an ensure it or similar never happens again. You will be mission critical, you have to think like that. Indeed I will take this up with Red Hat to determine what Red Hat has done at a high level to ensure it wont happen again. Otherwise anything else said was in no way meant to be insulting, (indeed the wasn't if this is what you refer to). So I will conclude that you have mis-read / mis-construed what I have said. Otherwise I am happy to apologise. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Tuesday, 2 August 2011 8:51 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] version mismatch while joining a client ? Steven Jones wrote: > As below, I have that rpm and I have a failure. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > steven.jones at vuw.ac.nz 0064 4 463 6272 > > 8><------------ > > rpm -q --changelog will show the history of the package, including the v-r. > > So looks like 7.19.7-26 is what you want. > > 8><-------------- > > See attached, its what I have, so there must be some other issue? > >> >> I seem to be getting bogged down with RH support....seems the gdowngrade wnet from x86_64 to i686 but still the same subpatch -26....I think I want -16? > > That is very odd. Perhaps try with arch appended: > > # yum downgrade curl.x86_64 libcurl*.x86_64 curl.i686 libcurl*.i686 > > rob > > 8><-------- > > I find it not unusual for RH to break yum...... > > regards rpm -e != yum downgrade According to this you have the version of libcurl that supports ticket forwarding. Are you saying you still get an error when you try enrollment? This has to be installed on each client, not the server. The insulting comments are not necessary. rob From Steven.Jones at vuw.ac.nz Mon Aug 1 21:57:10 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 1 Aug 2011 21:57:10 +0000 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <4E3711CB.3060604@redhat.com> References: <4E2EC378.9050401@romal.de>,<4E2EC930.1060501@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz> 8><--------- According to this you have the version of libcurl that supports ticket forwarding. Are you saying you still get an error when you try enrollment? This has to be installed on each client, not the server. 8><-------- Yes....enrolement now fails, previous messages I attached show that I think, it used to work. History, I had to remove all my working IPA clients due to a disk space problem on our SAN (we didnt have any). So I managed to keep the working IPA server and 2 x RHEL5 64 bit servers and the one un-configured template of RHEL6.1 64bit client I had. This I used to make client side clones off previously and connected them to IPA server and they worked. So lastweek I went back and with a running ipa server, I cloned in the old client/template and got the mis-match, so I put them on the production network and patched, same mismatch problem. I can do a sosreport of the old template I think and the client to look at the differences if that helps. regards From ondrejv at s3group.cz Tue Aug 2 12:16:14 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Tue, 02 Aug 2011 14:16:14 +0200 Subject: [Freeipa-users] Unable to start IPA server after server reboot Message-ID: <4E37EA8E.3020505@s3group.cz> Hi list, I have a problem with my IPA server: Symptoms: [root at polaris etc]# /etc/init.d/ipa start Starting Directory Service Starting dirsrv: EXAMPLE-COM... [ OK ] PKI-IPA... [ OK ] Failed to read data from Directory Service: Unknown error when retrieving list of services from LDAP: {'matched': 'cn=masters,cn=ipa,cn=etc,dc=example,dc=com', 'desc': 'No such object'} Shutting down Shutting down dirsrv: EXAMPLE-COM... [ OK ] PKI-IPA... [ OK ] I am able to start the services (dirsrv, named, krb5kdc) separately though and then read the configuration fine: [root at polaris log]# kinit admin Password for admin at EXAMPLE.COM: [root at polaris etc]# ldapsearch -Y GSSAPI -h localhost -b cn=masters,cn=ipa,cn=etc,dc=example,dc=com SASL/GSSAPI authentication started SASL username: admin at EXAMPLE.COM SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # masters, ipa, etc, example.com dn: cn=masters,cn=ipa,cn=etc,dc=example,dc=com objectClass: nsContainer objectClass: top cn: masters # polaris.example.com, masters, ipa, etc, example.com dn: cn=polaris.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com objectClass: top objectClass: nsContainer cn: polaris.example.com # CA, polaris.example.com, masters, ipa, etc, example.com dn: cn=CA,cn=polaris.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com objectClass: nsContainer objectClass: ipaConfigObject objectClass: top ipaConfigString: enabledService ipaConfigString: startOrder 50 cn: CA ..... Does it ring any bell to you? Note that the IPA server was running fine right after the installation.... Thanks! Ondrej The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Aug 2 12:53:02 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 02 Aug 2011 08:53:02 -0400 Subject: [Freeipa-users] FreeIPA for Linux desktop deployment In-Reply-To: <4E36F0EC.2050202@romal.de> References: <1311701212.19704.YahooMailClassic@web161320.mail.bf1.yahoo.com> <4E30EF8B.8010008@romal.de> <4E36F0EC.2050202@romal.de> Message-ID: <4E37F32E.90406@redhat.com> Robert M. Albrecht wrote: > Hi, > > any ideas ? Something I can help with ? Your best bet is to add yourself as a cc onto bug https://bugzilla.redhat.com/show_bug.cgi?id=725577 and include information on your crash. regards rob > > cu romal > > > Am 28.07.11 07:11, schrieb Robert M. Albrecht: >> Hi, >> >> my IPA is still dying. >> >> Strange thing is,it's very random. Most times is stops after some >> minutes, but yesterday named worked for several hours. >> >> If it helps, I can provide shell access to the system. >> >> cu romal >> >> >> >> >> Am 26.07.11 19:26, schrieb nasir nasir: >>> >>> Hi all, >>> >>> After applying the patches and restarting the service, everything was >>> fine for about couple of hours. But again it crashed and gave core >>> dump. I have updated the latest /var/log/messages and core dump with >>> the bugzilla report. >>> Please help. >>> >>> Regards, >>> Nidal >>> >>> --- On Tue, 7/26/11, Adam Tkac wrote: >>> >>>> From: Adam Tkac >>>> Subject: Re: [Freeipa-users] FreeIPA for Linux desktop deployment >>>> To: "nasir nasir" >>>> Cc: freeipa-users at redhat.com, "Robert M. Albrecht" >>>> Date: Tuesday, July 26, 2011, 7:58 AM >>>> On 07/26/2011 04:51 PM, nasir nasir >>>> wrote: >>>>> Hi All, >>>>> >>>>> Thanks a ton for every one who helped to have such a >>>> quick fix for this issue. I truly appreciate it. I have >>>> applied the patch (generated from the source rpm and applied >>>> with rpm -Uvh ***) and restarted IPA service. Had a >>>> preliminary test of the services and everything seems to be >>>> fine. Will keep watching and update the list in due course. >>>> >>>>> >>>>> Adam, >>>>> >>>>> Do you want me to update the bugzilla now or wait for >>>> a couple of days to observe ? >>>> >>>> Thanks for your feedback, you don't have to update >>>> bugzilla, update it >>>> only in case if named crashes again, please. For now I will >>>> consider the >>>> patch as correct. >>>> >>>> Regards, Adam >>>> >>> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Tue Aug 2 13:18:01 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 02 Aug 2011 09:18:01 -0400 Subject: [Freeipa-users] Unable to start IPA server after server reboot In-Reply-To: <4E37EA8E.3020505@s3group.cz> References: <4E37EA8E.3020505@s3group.cz> Message-ID: <4E37F909.1020107@redhat.com> Ondrej Valousek wrote: > Hi list, > > I have a problem with my IPA server: > Symptoms: > > [root at polaris etc]# /etc/init.d/ipa start > Starting Directory Service > Starting dirsrv: > EXAMPLE-COM... [ OK ] > PKI-IPA... [ OK ] > Failed to read data from Directory Service: Unknown error when > retrieving list of services from LDAP: {'matched': > 'cn=masters,cn=ipa,cn=etc,dc=example,dc=com', 'desc': 'No such object'} > Shutting down > Shutting down dirsrv: > EXAMPLE-COM... [ OK ] > PKI-IPA... [ OK ] > > I am able to start the services (dirsrv, named, krb5kdc) separately > though and then read the configuration fine: > > [root at polaris log]# kinit admin > Password for admin at EXAMPLE.COM: > [root at polaris etc]# ldapsearch -Y GSSAPI -h localhost -b > cn=masters,cn=ipa,cn=etc,dc=example,dc=com > SASL/GSSAPI authentication started > SASL username: admin at EXAMPLE.COM > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # masters, ipa, etc, example.com > dn: cn=masters,cn=ipa,cn=etc,dc=example,dc=com > objectClass: nsContainer > objectClass: top > cn: masters > > # polaris.example.com, masters, ipa, etc, example.com > dn: cn=polaris.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com > objectClass: top > objectClass: nsContainer > cn: polaris.example.com > > # CA, polaris.example.com, masters, ipa, etc, example.com > dn: cn=CA,cn=polaris.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com > objectClass: nsContainer > objectClass: ipaConfigObject > objectClass: top > ipaConfigString: enabledService > ipaConfigString: startOrder 50 > cn: CA > ..... > > Does it ring any bell to you? > Note that the IPA server was running fine right after the installation.... Is your hostname set to polaris.example.com or polaris (check /etc/sysconfig/network). What we search for is cn=$FQDN,cn=masters,cn=etc That explains the matched part. It matched everything except the hostname. rob From ondrejv at s3group.cz Tue Aug 2 13:42:59 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Tue, 02 Aug 2011 15:42:59 +0200 Subject: [Freeipa-users] Unable to start IPA server after server reboot In-Reply-To: <4E37F909.1020107@redhat.com> References: <4E37EA8E.3020505@s3group.cz> <4E37F909.1020107@redhat.com> Message-ID: <4E37FEE3.9010601@s3group.cz> Hi Rob, It was just "polaris" - so I tried: [root at polaris etc]# hostname polaris.example.com and it started working - Magic! That means that we rely on the fact that hostname is set to FQDN, right? Isn't it too strong requirement? Maybe we should guess FQDN using reverse lookups I do not know. The bottom line is that at least the IPA installation script should warn about the incorrect hostname. And the error message was bit confusing as well, because from that one none can even guess what went wrong, I even tried to add 'ipactl -d start' to print more debugging, but it did not help either. Just trying to bring some ideas, otherwise I am happy that it is working again for me :-) Thanks! Ondrej On 02.08.2011 15:18, Rob Crittenden wrote: > Is your hostname set to polaris.example.com or polaris (check /etc/sysconfig/network). > > What we search for is cn=$FQDN,cn=masters,cn=etc > > That explains the matched part. It matched everything except the hostname. > > rob The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Aug 2 13:48:22 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 02 Aug 2011 09:48:22 -0400 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <4E2EC378.9050401@romal.de>, <4E2EC930.1060501@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4E380026.5000707@redhat.com> Steven Jones wrote: > > Yes....enrolement now fails, previous messages I attached show that I think, it used to work. > > History, I had to remove all my working IPA clients due to a disk space problem on our SAN (we didnt have any). So I managed to keep the working IPA server and 2 x RHEL5 64 bit servers and the one un-configured template of RHEL6.1 64bit client I had. This I used to make client side clones off previously and connected them to IPA server and they worked. > > So lastweek I went back and with a running ipa server, I cloned in the old client/template and got the mis-match, so I put them on the production network and patched, same mismatch problem. > > I can do a sosreport of the old template I think and the client to look at the differences if that helps. I'm having a hard time following exactly what you are doing, on what machine. I think we need to be more systematic. Can you choose a machine to act as the client and provide the following: - distro and architecture (e.g. RHEL 6.1 on x86_64) - rpm -q curl libcurl - rpm -q ipa-client On the IPA server: - rpm -q ipa-server Start with a client that is not enrolled. If it has previously been enrolled run: ipa-client-install --uninstall -U Now run ipa-client-install and answer the questions as appropriate for your install. If it fails please provide the following: - any stdout you get from the client install - attach the full /var/log/ipaclient-install.log - attach the last 100 lines from /var/log/httpd/error_log from the IPA server rob From ayoung at redhat.com Tue Aug 2 14:04:40 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 02 Aug 2011 10:04:40 -0400 Subject: [Freeipa-users] Unable to start IPA server after server reboot In-Reply-To: <4E37FEE3.9010601@s3group.cz> References: <4E37EA8E.3020505@s3group.cz> <4E37F909.1020107@redhat.com> <4E37FEE3.9010601@s3group.cz> Message-ID: <4E3803F8.9090108@redhat.com> On 08/02/2011 09:42 AM, Ondrej Valousek wrote: > Hi Rob, > It was just "polaris" - so I tried: > [root at polaris etc]# hostname polaris.example.com > > and it started working - Magic! > That means that we rely on the fact that hostname is set to FQDN, > right? Isn't it too strong requirement? > Maybe we should guess FQDN using reverse lookups I do not know. The > bottom line is that at least the IPA installation script should warn > about the incorrect hostname. > This actually brought a chuckle....we've been through a few iterations of how to deal with this. The approach did do Reverse at one point, but that brought in a few other issues. Needless to say, we've felt your pain on numerous occasions. Kerberos depends on the hostname being right, and none of the auth works without Kerberos. This is an issue that seems to mess people up in testing and evaluation mode, but people want and need it to resolve correctly in live environments. > And the error message was bit confusing as well, because from that one > none can even guess what went wrong, I even tried to add 'ipactl -d > start' to print more debugging, but it did not help either. > > Just trying to bring some ideas, otherwise I am happy that it is > working again for me :-) > Thanks! > > Ondrej > > > > > On 02.08.2011 15:18, Rob Crittenden wrote: >> Is your hostname set to polaris.example.com or polaris (check >> /etc/sysconfig/network). >> >> What we search for is cn=$FQDN,cn=masters,cn=etc >> >> That explains the matched part. It matched everything except the >> hostname. >> >> rob > > ------------------------------------------------------------------------ > The information contained in this e-mail and in any attachments is > confidential and is designated solely for the attention of the > intended recipient(s). If you are not an intended recipient, you must > not use, disclose, copy, distribute or retain this e-mail or any part > thereof. If you have received this e-mail in error, please notify the > sender by return e-mail and delete all copies of this e-mail from your > computer system(s). Please direct any additional queries to: > communications at s3group.com. Thank You. Silicon and Software Systems > Limited (S3 Group). Registered in Ireland no. 378073. Registered > Office: South County Business Park, Leopardstown, Dublin 18 > ------------------------------------------------------------------------ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Aug 2 14:13:05 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 02 Aug 2011 08:13:05 -0600 Subject: [Freeipa-users] Unable to start IPA server after server reboot In-Reply-To: <4E3803F8.9090108@redhat.com> References: <4E37EA8E.3020505@s3group.cz> <4E37F909.1020107@redhat.com> <4E37FEE3.9010601@s3group.cz> <4E3803F8.9090108@redhat.com> Message-ID: <4E3805F1.8020000@redhat.com> On 08/02/2011 08:04 AM, Adam Young wrote: > On 08/02/2011 09:42 AM, Ondrej Valousek wrote: >> Hi Rob, >> It was just "polaris" - so I tried: >> [root at polaris etc]# hostname polaris.example.com >> >> and it started working - Magic! >> That means that we rely on the fact that hostname is set to FQDN, >> right? Isn't it too strong requirement? >> Maybe we should guess FQDN using reverse lookups I do not know. The >> bottom line is that at least the IPA installation script should warn >> about the incorrect hostname. >> > This actually brought a chuckle....we've been through a few iterations > of how to deal with this. The approach did do Reverse at one point, > but that brought in a few other issues. Needless to say, we've felt > your pain on numerous occasions. > > Kerberos depends on the hostname being right, and none of the auth > works without Kerberos. This is an issue that seems to mess people up > in testing and evaluation mode, but people want and need it to resolve > correctly in live environments. Most TLS/SSL implementations want to use the fqdn as well e.g. server certs will have cn=fqdn,something... as the Subject: in the cert. > > > >> And the error message was bit confusing as well, because from that >> one none can even guess what went wrong, I even tried to add 'ipactl >> -d start' to print more debugging, but it did not help either. >> >> Just trying to bring some ideas, otherwise I am happy that it is >> working again for me :-) >> Thanks! >> >> Ondrej >> >> >> >> >> On 02.08.2011 15:18, Rob Crittenden wrote: >>> Is your hostname set to polaris.example.com or polaris (check >>> /etc/sysconfig/network). >>> >>> What we search for is cn=$FQDN,cn=masters,cn=etc >>> >>> That explains the matched part. It matched everything except the >>> hostname. >>> >>> rob >> >> ------------------------------------------------------------------------ >> The information contained in this e-mail and in any attachments is >> confidential and is designated solely for the attention of the >> intended recipient(s). If you are not an intended recipient, you must >> not use, disclose, copy, distribute or retain this e-mail or any part >> thereof. If you have received this e-mail in error, please notify the >> sender by return e-mail and delete all copies of this e-mail from >> your computer system(s). Please direct any additional queries to: >> communications at s3group.com. Thank You. Silicon and Software Systems >> Limited (S3 Group). Registered in Ireland no. 378073. Registered >> Office: South County Business Park, Leopardstown, Dublin 18 >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Aug 2 14:40:35 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 02 Aug 2011 10:40:35 -0400 Subject: [Freeipa-users] Unable to start IPA server after server reboot In-Reply-To: <4E37FEE3.9010601@s3group.cz> References: <4E37EA8E.3020505@s3group.cz> <4E37F909.1020107@redhat.com> <4E37FEE3.9010601@s3group.cz> Message-ID: <4E380C63.7080400@redhat.com> Ondrej Valousek wrote: > Hi Rob, > It was just "polaris" - so I tried: > [root at polaris etc]# hostname polaris.example.com > > and it started working - Magic! > That means that we rely on the fact that hostname is set to FQDN, right? > Isn't it too strong requirement? > Maybe we should guess FQDN using reverse lookups I do not know. The > bottom line is that at least the IPA installation script should warn > about the incorrect hostname. > > And the error message was bit confusing as well, because from that one > none can even guess what went wrong, I even tried to add 'ipactl -d > start' to print more debugging, but it did not help either. > > Just trying to bring some ideas, otherwise I am happy that it is working > again for me :-) > Thanks! > > Ondrej Kerberos and SSL really want fully-qualified names. We've done some upstream work to address detecting when the hostname is not a fqdn. I filed a new ticket for the poor error message. thanks for the suggestions. rob From fedora at romal.de Tue Aug 2 16:20:40 2011 From: fedora at romal.de (Robert M. Albrecht) Date: Tue, 02 Aug 2011 18:20:40 +0200 Subject: [Freeipa-users] Unknown user pkisrv Message-ID: <4E3823D8.7030209@romal.de> Hi, from /var/log/messages Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: [/etc/tmpfiles.d/dirsrv-PKI-IPA.conf:1] Unknown user 'pkisrv'. Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: [/etc/tmpfiles.d/dirsrv-PKI-IPA.conf:2] Unknown user 'pkisrv'. Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: [/etc/tmpfiles.d/dirsrv-PKI-IPA.conf:3] Unknown user 'pkisrv'. Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: Two or more conflicting lines for /var/run/dirsrv configured, ignoring. Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: Two or more conflicting lines for /var/lock/dirsrv configured, ignoring. Aug 2 18:03:14 zerberus systemd[1]: systemd-tmpfiles-clean.service: main process exited, code=exited, status=1 Aug 2 18:03:14 zerberus systemd[1]: Unit systemd-tmpfiles-clean.service entered failed state. Is this normal ? cu romal From ijstokes at hkl.hms.harvard.edu Tue Aug 2 18:15:51 2011 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Tue, 02 Aug 2011 14:15:51 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys Message-ID: <4E383ED7.1030506@hkl.hms.harvard.edu> Is there some mechanism to store private keys (e.g. ssh, pgp, gpg, X.509) in FreeIPA, tied to a user account, so only the user (via kerb token or with password prompt) can fetch the token? If FreeIPA doesn't make this possible, can anyone suggest a good mechanism to have, effectively, a user keystore that would sync passwords with FreeIPA nicely. I am thinking, in particular, of the scenario where users forget their password -- we'd strongly prefer to just reset it for them (24 hours, one login) in a way that didn't mean also re-issuing all passphrase-secured identity tokens. Thanks, Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ijstokes.vcf Type: text/x-vcard Size: 380 bytes Desc: not available URL: From rmeggins at redhat.com Tue Aug 2 18:30:44 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 02 Aug 2011 12:30:44 -0600 Subject: [Freeipa-users] Unknown user pkisrv In-Reply-To: <4E3823D8.7030209@romal.de> References: <4E3823D8.7030209@romal.de> Message-ID: <4E384254.4060501@redhat.com> On 08/02/2011 10:20 AM, Robert M. Albrecht wrote: > Hi, > > from /var/log/messages > > Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: > [/etc/tmpfiles.d/dirsrv-PKI-IPA.conf:1] Unknown user 'pkisrv'. > Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: > [/etc/tmpfiles.d/dirsrv-PKI-IPA.conf:2] Unknown user 'pkisrv'. > Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: > [/etc/tmpfiles.d/dirsrv-PKI-IPA.conf:3] Unknown user 'pkisrv'. > Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: Two or more > conflicting lines for /var/run/dirsrv configured, ignoring. > Aug 2 18:03:14 zerberus systemd-tmpfiles[2148]: Two or more > conflicting lines for /var/lock/dirsrv configured, ignoring. > Aug 2 18:03:14 zerberus systemd[1]: systemd-tmpfiles-clean.service: > main process exited, code=exited, status=1 > Aug 2 18:03:14 zerberus systemd[1]: Unit > systemd-tmpfiles-clean.service entered failed state. > > Is this normal ? No. Did you use any sort of ipa-remove or ipa-delete command that would have removed or deleted ipa components? Beginning with Fedora 15, 389 has support for tmpfiles.d - running setup-ds.pl will create the necessary files, and running remove-ds.pl will remove them. I don't think ipa uses remove-ds.pl so it might have left these files around. If /etc/dirsrv/slapd-PKI-IPA does not exist, you can remove /etc/tmpfiles.d/dirsrv-PKI-IPA* > > cu romal > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Tue Aug 2 20:27:07 2011 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 02 Aug 2011 16:27:07 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E383ED7.1030506@hkl.hms.harvard.edu> References: <4E383ED7.1030506@hkl.hms.harvard.edu> Message-ID: <4E385D9B.8010207@redhat.com> On 08/02/2011 02:15 PM, Ian Stokes-Rees wrote: > Is there some mechanism to store private keys (e.g. ssh, pgp, gpg, > X.509) in FreeIPA, tied to a user account, so only the user (via kerb > token or with password prompt) can fetch the token? > > If FreeIPA doesn't make this possible, can anyone suggest a good > mechanism to have, effectively, a user keystore that would sync > passwords with FreeIPA nicely. I am thinking, in particular, of the > scenario where users forget their password -- we'd strongly prefer to > just reset it for them (24 hours, one login) in a way that didn't mean > also re-issuing all passphrase-secured identity tokens. > Not now however: https://fedorahosted.org/freeipa/ticket/754 https://fedorahosted.org/freeipa/ticket/237 https://fedorahosted.org/freeipa/ticket/521 There are also some thoughts and ideas about IPA as a secure vault for other credentials in other systems which is not logged as a ticket. Would you mind sharing with us your ideas about this functionality actually should work? Use cases, examples and design ideas are very welcome. > Thanks, > > Ian > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Tue Aug 2 21:00:01 2011 From: simo at redhat.com (Simo Sorce) Date: Tue, 02 Aug 2011 17:00:01 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E385D9B.8010207@redhat.com> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> Message-ID: <1312318801.26968.6.camel@willson.li.ssimo.org> On Tue, 2011-08-02 at 16:27 -0400, Dmitri Pal wrote: > On 08/02/2011 02:15 PM, Ian Stokes-Rees wrote: > > Is there some mechanism to store private keys (e.g. ssh, pgp, gpg, > > X.509) in FreeIPA, tied to a user account, so only the user (via > > kerb token or with password prompt) can fetch the token? > > > > If FreeIPA doesn't make this possible, can anyone suggest a good > > mechanism to have, effectively, a user keystore that would sync > > passwords with FreeIPA nicely. I am thinking, in particular, of the > > scenario where users forget their password -- we'd strongly prefer > > to just reset it for them (24 hours, one login) in a way that didn't > > mean also re-issuing all passphrase-secured identity tokens. > > > > Not now however: > https://fedorahosted.org/freeipa/ticket/754 > https://fedorahosted.org/freeipa/ticket/237 > https://fedorahosted.org/freeipa/ticket/521 Replaced the last one with: https://fedorahosted.org/freeipa/ticket/1560 Simo. -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Tue Aug 2 21:35:25 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 2 Aug 2011 21:35:25 +0000 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <4E380026.5000707@redhat.com> References: <4E2EC378.9050401@romal.de>,<4E2EC930.1060501@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E380026.5000707@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Client ========== rhel61-64cl04.unix.vuw.ac.nz Linux rhel61-64cl04.unix.vuw.ac.nz 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux ipa-client-2.0.0-23.el6_1.1.x86_64 libcurl-7.19.7-26.el6.x86_64 Red Hat Enterprise Linux Client release 6.1 (Santiago) ========== Server ========== Linux vuwunicoipamt01 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux libcurl-7.19.7-26.el6_1.1.x86_64 ipa-client-2.0.0-23.el6_1.1.x86_64 ipa-server-2.0.0-23.el6_1.1.x86_64 Red Hat Enterprise Linux Server release 6.1 (Santiago) ========== install output ========== [root at rhel61-64cl04 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz', 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw.ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server': None, 'mkhomedir': True, 'unattended': None, 'principal': None} root : DEBUG missing options might be asked for interactively later root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' root : DEBUG [ipacheckldap] root : DEBUG args=/usr/bin/wget -O /tmp/tmpaaTaqF/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt root : DEBUG stdout= root : DEBUG stderr=--2011-08-03 09:01:14-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 779 [application/x-x509-ca-cert] Saving to: `/tmp/tmpaaTaqF/ca.crt' 0K 100% 132M=0s 2011-08-03 09:01:14 (132 MB/s) - `/tmp/tmpaaTaqF/ca.crt' saved [779/779] root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 root : DEBUG Search rootdse root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': ['unix.vuw.ac.nz']})] root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vuw,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})] root : DEBUG will use domain: unix.vuw.ac.nz root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz Discovery was successful! root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz Hostname: rhel61-64cl04.unix.vuw.ac.nz Realm: UNIX.VUW.AC.NZ DNS Domain: unix.vuw.ac.nz IPA Server: vuwunicoipamt01.unix.vuw.ac.nz BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz Continue to configure the system with these values? [no]: yes Enrollment principal: admin root : DEBUG will use principal: admin root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt root : DEBUG stdout= root : DEBUG stderr=--2011-08-03 09:01:22-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 779 [application/x-x509-ca-cert] Saving to: `/etc/ipa/ca.crt' 0K 100% 96.5M=0s 2011-08-03 09:01:22 (96.5 MB/s) - `/etc/ipa/ca.crt' saved [779/779] Password for admin at UNIX.VUW.AC.NZ: root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: root : DEBUG stderr= root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d root : DEBUG stdout= root : DEBUG stderr=XML-RPC CALL: \r\n \r\n join\r\n \r\n \r\n rhel61-64cl04.unix.vuw.ac.nz\r\n \r\n \r\n nsosversion\r\n 2.6.32-131.6.1.el6.x86_64\r\n nshardwareplatform\r\n x86_64\r\n \r\n \r\n \r\n HTTP response code is 401, not 200 Joining realm failed because of failing XML-RPC request. This error may be caused by incompatible server/client major versions. root : DEBUG args=kdestroy root : DEBUG stdout= root : DEBUG stderr= [root at rhel61-64cl04 ~]# ========== Error log ========== [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [notice] caught SIGTERM, shutting down [Wed Aug 03 09:04:58 2011] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 [Wed Aug 03 09:04:58 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Wed Aug 03 09:04:58 2011] [notice] Digest: generating secret for digest authentication ... [Wed Aug 03 09:04:58 2011] [notice] Digest: done [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Compiled for Python/2.6.2. [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Runtime using Python/2.6.6. [Wed Aug 03 09:04:59 2011] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** ========== regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Wednesday, 3 August 2011 1:48 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] version mismatch while joining a client ? Steven Jones wrote: > > Yes....enrolement now fails, previous messages I attached show that I think, it used to work. > > History, I had to remove all my working IPA clients due to a disk space problem on our SAN (we didnt have any). So I managed to keep the working IPA server and 2 x RHEL5 64 bit servers and the one un-configured template of RHEL6.1 64bit client I had. This I used to make client side clones off previously and connected them to IPA server and they worked. > > So lastweek I went back and with a running ipa server, I cloned in the old client/template and got the mis-match, so I put them on the production network and patched, same mismatch problem. > > I can do a sosreport of the old template I think and the client to look at the differences if that helps. I'm having a hard time following exactly what you are doing, on what machine. I think we need to be more systematic. Can you choose a machine to act as the client and provide the following: - distro and architecture (e.g. RHEL 6.1 on x86_64) - rpm -q curl libcurl - rpm -q ipa-client On the IPA server: - rpm -q ipa-server Start with a client that is not enrolled. If it has previously been enrolled run: ipa-client-install --uninstall -U Now run ipa-client-install and answer the questions as appropriate for your install. If it fails please provide the following: - any stdout you get from the client install - attach the full /var/log/ipaclient-install.log - attach the last 100 lines from /var/log/httpd/error_log from the IPA server rob -------------- next part -------------- A non-text attachment was scrubbed... Name: ipaclient-install.log Type: application/octet-stream Size: 4823 bytes Desc: ipaclient-install.log URL: From ijstokes at hkl.hms.harvard.edu Tue Aug 2 21:51:44 2011 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Tue, 02 Aug 2011 17:51:44 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E385D9B.8010207@redhat.com> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> Message-ID: <4E387170.5010804@hkl.hms.harvard.edu> On 8/2/11 4:27 PM, Dmitri Pal wrote: > On 08/02/2011 02:15 PM, Ian Stokes-Rees wrote: >> Is there some mechanism to store private keys (e.g. ssh, pgp, gpg, >> X.509) in FreeIPA, tied to a user account, so only the user (via kerb >> token or with password prompt) can fetch the token? >> >> If FreeIPA doesn't make this possible, can anyone suggest a good >> mechanism to have, effectively, a user keystore that would sync >> passwords with FreeIPA nicely. I am thinking, in particular, of the >> scenario where users forget their password -- we'd strongly prefer to >> just reset it for them (24 hours, one login) in a way that didn't >> mean also re-issuing all passphrase-secured identity tokens. >> > > Not now however: > https://fedorahosted.org/freeipa/ticket/754 > https://fedorahosted.org/freeipa/ticket/237 > https://fedorahosted.org/freeipa/ticket/521 > > There are also some thoughts and ideas about IPA as a secure vault for > other credentials in other systems which is not logged as a ticket. > > > Would you mind sharing with us your ideas about this functionality > actually should work? > Use cases, examples and design ideas are very welcome. Is there any standard to keystores? It would be great if Linux, Mac, Windows could all be pointed at an FreeIPA to fetch credentials, usernames, passwords. Authentication could use kerberos tickets if available, otherwise prompt for username/password, or have configurable authentication policies. Users and administrators could set ACL policies on the keystores (I know very little about LDAP, but I believe LDAP already provides this kind of thing), and they could be hierarchical, with access policy inheritance. It could act as a password safe like http://kedpm.sourceforge.net/. Imagine storing SSH private keys in IPA. The user then wants to fetch these into ssh-agent, or to provide them for some other in-memory process that requires access to the unencrypted private-key. Another scenario is X.509 PKI where the private key is usually passphrase encrypted. If the user forgets their passphrase, the PKI token needs to be revoked and a new one issued. Much better (IMO) to hold it in a trusted authentication system and to provide the unencrypted key to applications on demand. User-passphrase can then be linked to FreeIPA system. Here is a quick idea of a command line to fetch credentials from an IPA keystore: ipa-keystore-fetch [-k keystore] [-u username] [-p password] [-P] [-o output_dir_or_file] \ [/path/to/token/]token_name[#attribute] \ [[/path/to/token/]token_name[#attribute]] [ ... ] Usual kind of thing: the user would have a default keystore, and their kerberos tokens (if available) would be used to authenticate for access to the keystore (based on username, I guess). Users could just dump tokens in the "root" space, or arrange the tokens hierarchically. Tokens could have attributes associated with them, with a "primary" or "default" token if none is specified. Tokens could be dumped to screen, routed to an application (pipe, IPC, socket, PID), or written to file. You could pretty easily imagine commands: chmod # acl changes add edit rm backup ls Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ijstokes.vcf Type: text/x-vcard Size: 380 bytes Desc: not available URL: From dpal at redhat.com Tue Aug 2 23:09:19 2011 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 02 Aug 2011 19:09:19 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E387170.5010804@hkl.hms.harvard.edu> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> Message-ID: <4E38839F.7030608@redhat.com> On 08/02/2011 05:51 PM, Ian Stokes-Rees wrote: > > > On 8/2/11 4:27 PM, Dmitri Pal wrote: >> On 08/02/2011 02:15 PM, Ian Stokes-Rees wrote: >>> Is there some mechanism to store private keys (e.g. ssh, pgp, gpg, >>> X.509) in FreeIPA, tied to a user account, so only the user (via >>> kerb token or with password prompt) can fetch the token? >>> >>> If FreeIPA doesn't make this possible, can anyone suggest a good >>> mechanism to have, effectively, a user keystore that would sync >>> passwords with FreeIPA nicely. I am thinking, in particular, of the >>> scenario where users forget their password -- we'd strongly prefer >>> to just reset it for them (24 hours, one login) in a way that didn't >>> mean also re-issuing all passphrase-secured identity tokens. >>> >> >> Not now however: >> https://fedorahosted.org/freeipa/ticket/754 >> https://fedorahosted.org/freeipa/ticket/237 >> https://fedorahosted.org/freeipa/ticket/521 >> >> There are also some thoughts and ideas about IPA as a secure vault >> for other credentials in other systems which is not logged as a ticket. >> >> >> Would you mind sharing with us your ideas about this functionality >> actually should work? >> Use cases, examples and design ideas are very welcome. > > Is there any standard to keystores? It would be great if Linux, Mac, > Windows could all be pointed at an FreeIPA to fetch credentials, > usernames, passwords. Authentication could use kerberos tickets if > available, otherwise prompt for username/password, or have > configurable authentication policies. > > Users and administrators could set ACL policies on the keystores (I > know very little about LDAP, but I believe LDAP already provides this > kind of thing), and they could be hierarchical, with access policy > inheritance. It could act as a password safe like > http://kedpm.sourceforge.net/. > > Imagine storing SSH private keys in IPA. The user then wants to fetch > these into ssh-agent, or to provide them for some other in-memory > process that requires access to the unencrypted private-key. > > Another scenario is X.509 PKI where the private key is usually > passphrase encrypted. If the user forgets their passphrase, the PKI > token needs to be revoked and a new one issued. Much better (IMO) to > hold it in a trusted authentication system and to provide the > unencrypted key to applications on demand. User-passphrase can then > be linked to FreeIPA system. > > Here is a quick idea of a command line to fetch credentials from an > IPA keystore: > > ipa-keystore-fetch [-k keystore] [-u username] [-p password] [-P] > [-o output_dir_or_file] \ > [/path/to/token/]token_name[#attribute] \ > [[/path/to/token/]token_name[#attribute]] [ ... ] > > Usual kind of thing: the user would have a default keystore, and their > kerberos tokens (if available) would be used to authenticate for > access to the keystore (based on username, I guess). Users could just > dump tokens in the "root" space, or arrange the tokens > hierarchically. Tokens could have attributes associated with them, > with a "primary" or "default" token if none is specified. Tokens > could be dumped to screen, routed to an application (pipe, IPC, > socket, PID), or written to file. You could pretty easily imagine > commands: > > chmod # acl changes > add > edit > rm > backup > ls > > Ian > First, security specialist would probably rebel about providing the password or keys in clear. The best practice says do not reveal the keys/passwords but rather encrypt them with some other "transport" secret that would be known to the user or destination host and would protect the password/key while in transit. Second, yes I was thinking about hierarchical storage too but then every user would have to turn into a container. That would have some implications that need to be researched. It might be easier to keep the key(s) in user entry and have ACLs attached to the key(s). And then have a separate vault storage in a form of a database for a quick and simple lookup. Needs investigation. Third there is a standard and protocol http://www.oasis-open.org/committees/kmip/ but last time I looked there were no open source implementations that we can take advantage of. Starting a whole new kmip related project is something that we can't afford... So: It can be solved and can be solved generically and more or less securely but it will take a lot of time before we would get there. I am sure we would though but not as soon as you might want. Our current plan is to focus on the storage and make sure we can address the use cases we need to address like keys for disk encryption, SSH etc. Serving them out is whole different story and I doubt it will be done soon. Design work in this area would hopefully start in the fall. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrejv at s3group.cz Wed Aug 3 08:22:10 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Wed, 03 Aug 2011 10:22:10 +0200 Subject: [Freeipa-users] Some questions regarding IPA, DNS and Samba4 Message-ID: <4E390532.8030808@s3group.cz> Hi List, I have some questions regarding IPA: 1. On the IPA client side, which daemon is looking after machine Kerberos host/ principal renewal? 2. If I installed Samba4 on the IPA server, what would happen? Is it possible? Would I get 2xKDCs, 2xLDAP servers and 2x DNS server or is it possible for Samba4 to re-use the existing IPA repository? 3. Can I use the Adam's LDAP plugin for BIND to deploy a DNS server with Active Directory integrated zone running on Linux? Many thanks, Ondrej The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrejv at s3group.cz Wed Aug 3 08:47:12 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Wed, 03 Aug 2011 10:47:12 +0200 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E38839F.7030608@redhat.com> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> Message-ID: <4E390B10.5090902@s3group.cz> Maybe stupid question, but I have to ask: Why would anyone want to store user RSA keys in LDAP? Once you have IPA server with KDC installed, you can use Kerberos for authentication as well. And you get single sign on as a special bonus :-) Ondrej The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Aug 3 11:44:07 2011 From: simo at redhat.com (Simo Sorce) Date: Wed, 03 Aug 2011 07:44:07 -0400 Subject: [Freeipa-users] Some questions regarding IPA, DNS and Samba4 In-Reply-To: <4E390532.8030808@s3group.cz> References: <4E390532.8030808@s3group.cz> Message-ID: <1312371847.26968.28.camel@willson.li.ssimo.org> On Wed, 2011-08-03 at 10:22 +0200, Ondrej Valousek wrote: > Hi List, > > I have some questions regarding IPA: > 1. On the IPA client side, which daemon is looking after machine > Kerberos host/ principal renewal? Keytabs are random secrets and do not need to expire as cracking them is consider a problem out of current computational reach unlike users passwords which use a much smaller set of values and is less randomic in nature. > 1. If I installed Samba4 on the IPA server, what would happen? Is > it possible? Would I get 2xKDCs, 2xLDAP servers and 2x DNS > server or is it possible for Samba4 to re-use the existing IPA > repository? Nothing would work as they would want to use the same ports (LDAP, KDC, kpasswd ...). No Samba4 cannot use FreeIPA's LDAP because Windows client wants a perfect copy of AD's schema and DIT so samba4 has to use the embedded LDAP and KDC. > 1. Can I use the Adam's LDAP plugin for BIND to deploy a DNS > server with Active Directory integrated zone running on Linux? The bind-dyndb-ldap plugin can be used to store any kind of data. And it properly allows bind to set record on DNS Updates. so yes, you can, but you may want to use a tool to make it easier to modify LDAP records then. Simo. -- Simo Sorce * Red Hat, Inc * New York From atkac at redhat.com Wed Aug 3 14:09:37 2011 From: atkac at redhat.com (Adam Tkac) Date: Wed, 03 Aug 2011 16:09:37 +0200 Subject: [Freeipa-users] FreeIPA for Linux desktop deployment In-Reply-To: <4E36FD7F.1040802@romal.de> References: <1312224974.26738.YahooMailClassic@web161311.mail.bf1.yahoo.com> <4E36FD7F.1040802@romal.de> Message-ID: <4E3956A1.7050906@redhat.com> Hello Robert, I've just submitted https://admin.fedoraproject.org/updates/bind-9.8.0-9.P4.fc15,bind-dyndb-ldap-0.2.0-4.fc15 update, can you please test if it is OK? It fixes one threading issue in bind-dyndb-ldap and wrong loading/unloading of modules in bind. Please update at least bind, bind-libs and bind-dyndb-ldap pkgs. Thanks in advance. Regards, Adam On 08/01/2011 09:24 PM, Robert M. Albrecht wrote: > Hi, > > [root at zerberus ~]# rpm --query bind > bind-9.8.0-8.P4.fc15.x86_64 > > it got worse on my system. Before the patch the named lived sometimes > for several minutes. After the patch, named dies always after some > seconds. > > [root at zerberus ~]# dig www.google.com > ; <<>> DiG 9.8.0-P4-RedHat-9.8.0-8.P4.fc15 <<>> www.google.com > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > [root at zerberus ~]# cat /etc/resolv.conf > nameserver 127.0.0.1 > nameserver ::1 > domain vorlon.lan > > > From ijstokes at hkl.hms.harvard.edu Wed Aug 3 14:10:46 2011 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Wed, 03 Aug 2011 10:10:46 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E38839F.7030608@redhat.com> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> Message-ID: <4E3956E6.7090103@hkl.hms.harvard.edu> An HTML attachment was scrubbed... URL: From ijstokes at hkl.hms.harvard.edu Wed Aug 3 14:14:13 2011 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Wed, 03 Aug 2011 10:14:13 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E390B10.5090902@s3group.cz> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> Message-ID: <4E3957B5.4090703@hkl.hms.harvard.edu> An HTML attachment was scrubbed... URL: From fedora at romal.de Wed Aug 3 14:22:40 2011 From: fedora at romal.de (Robert M. Albrecht) Date: Wed, 03 Aug 2011 16:22:40 +0200 Subject: [Freeipa-users] FreeIPA for Linux desktop deployment In-Reply-To: <4E3956A1.7050906@redhat.com> References: <1312224974.26738.YahooMailClassic@web161311.mail.bf1.yahoo.com> <4E36FD7F.1040802@romal.de> <4E3956A1.7050906@redhat.com> Message-ID: <4E3959B0.4010303@romal.de> Hi Adam, I've just installed them. Looking good so far. Keep fingers crossed. cu romal Am 03.08.11 16:09, schrieb Adam Tkac: > Hello Robert, > > I've just submitted > https://admin.fedoraproject.org/updates/bind-9.8.0-9.P4.fc15,bind-dyndb-ldap-0.2.0-4.fc15 > update, can you please test if it is OK? It fixes one threading issue in > bind-dyndb-ldap and wrong loading/unloading of modules in bind. Please > update at least bind, bind-libs and bind-dyndb-ldap pkgs. Thanks in advance. > > Regards, Adam > > On 08/01/2011 09:24 PM, Robert M. Albrecht wrote: >> Hi, >> >> [root at zerberus ~]# rpm --query bind >> bind-9.8.0-8.P4.fc15.x86_64 >> >> it got worse on my system. Before the patch the named lived sometimes >> for several minutes. After the patch, named dies always after some >> seconds. >> >> [root at zerberus ~]# dig www.google.com >> ;<<>> DiG 9.8.0-P4-RedHat-9.8.0-8.P4.fc15<<>> www.google.com >> ;; global options: +cmd >> ;; connection timed out; no servers could be reached >> >> [root at zerberus ~]# cat /etc/resolv.conf >> nameserver 127.0.0.1 >> nameserver ::1 >> domain vorlon.lan >> >> >> > > From sgallagh at redhat.com Wed Aug 3 14:37:45 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 03 Aug 2011 10:37:45 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E3957B5.4090703@hkl.hms.harvard.edu> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> <4E3957B5.4090703@hkl.hms.harvard.edu> Message-ID: <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> On Wed, 2011-08-03 at 10:14 -0400, Ian Stokes-Rees wrote: > > > On 8/3/11 4:47 AM, Ondrej Valousek wrote: > > Maybe stupid question, but I have to ask: > > Why would anyone want to store user RSA keys in LDAP? Once you have > > IPA server with KDC installed, you can use Kerberos for > > authentication as well. > > And you get single sign on as a special bonus :-) > > If you only work in a single administrative domain, this is fine. I > am constantly accessing systems all over the US, and internationally, > and the use of ssh-key-based authentication allows me to do this > without continuous password prompts. In fact, on many of the systems > I can *only* access them by ssh-key. Being able to hold those keys in > central keystore like FreeIPA with a single passphrase, and the > ability for an administrator to reset that passphrase, is very > desirable for me and for the other users of the systems I'm a part of. > Resetting key-based access control if the private key passphrase is > lost is always a nuisance. As a general rule, I would think that having your private key stored somewhere that an admin other than yourself can reset the password and have access to would be really dangerous. Most especially if this private key was being used to access sites in other administrative domains. That really sounds like an accident waiting to happen... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ijstokes at hkl.hms.harvard.edu Wed Aug 3 16:21:38 2011 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Wed, 03 Aug 2011 12:21:38 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> <4E3957B5.4090703@hkl.hms.harvard.edu> <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> Message-ID: <4E397592.8040406@hkl.hms.harvard.edu> On Wed Aug 3 10:37:45 2011, Stephen Gallagher wrote: > As a general rule, I would think that having your private key stored > somewhere that an admin other than yourself can reset the password and > have access to would be really dangerous. Most especially if this > private key was being used to access sites in other administrative > domains. > > That really sounds like an accident waiting to happen... If you are concerned about that, then don't make use of a centralized keystore. You may be a security expert and have a deeper understanding of this than I do, but from my limited experience and knowledge of security audits and risk assessment, if you don't trust your system administrators then you have a whole heap of other issues you need to contend with. Consider that the FreeIPA server is probably *more* secure than the user-accessible systems and file servers. If someone with administrative (root) privs for the part of the system where I store my passphrase encrypted private key would be the kind of person who would take the private key from a central keystore, if it existed, then do you not think they could get my passphrase and/or cleartext private key from the system *without* a central keystore? This is not to say there aren't arguments against it: a policy mix up or a bug in the central keystore could lead to *all* users having their private keys compromised, and an admin who can dip in and grab private keys without any evidence would also be bad, but hopefully the "Audit" part of IPA means that any access to private keys will be securely logged, and flagged if they are by users other than the "owner" of the private key. This is a topic that is very important to me, so I'm quite interested to hear how my reasoning may be flawed, or to hear opinions from others. Regards, Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: ijstokes.vcf Type: text/x-vcard Size: 394 bytes Desc: not available URL: From ayoung at redhat.com Wed Aug 3 16:38:45 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 03 Aug 2011 12:38:45 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E397592.8040406@hkl.hms.harvard.edu> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> <4E3957B5.4090703@hkl.hms.harvard.edu> <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> <4E397592.8040406@hkl.hms.harvard.edu> Message-ID: <4E397995.90403@redhat.com> On 08/03/2011 12:21 PM, Ian Stokes-Rees wrote: > > On Wed Aug 3 10:37:45 2011, Stephen Gallagher wrote: >> As a general rule, I would think that having your private key stored >> somewhere that an admin other than yourself can reset the password and >> have access to would be really dangerous. Most especially if this >> private key was being used to access sites in other administrative >> domains. >> >> That really sounds like an accident waiting to happen... > If you are concerned about that, then don't make use of a centralized > keystore. > > You may be a security expert and have a deeper understanding of this > than I do, but from my limited experience and knowledge of security > audits and risk assessment, if you don't trust your system > administrators then you have a whole heap of other issues you need to > contend with. > > Consider that the FreeIPA server is probably *more* secure than the > user-accessible systems and file servers. If someone with > administrative (root) privs for the part of the system where I store my > passphrase encrypted private key would be the kind of person who would > take the private key from a central keystore, if it existed, then do > you not think they could get my passphrase and/or cleartext private key > from the system *without* a central keystore? I think that it is a case of "Just becasue I am paranoid doesn't mean they are not out to get me." Its not that we don't trust sys admins, it is that we don't trust anyone. Typically, instead of trusting anyone, sysadmin or no, with long term access to keys, you might provide a window in which they know the shared secret in order to reset the key, but not to make that a permanent relationship. I think what you are interested in is the Data Recovery Manager (DRM...hey, we had the acronym first, but we also call it Key Recovery ) aspect of Certificate Server. Here's the redhat docs on it http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/7.1/html/Administrators_Guide/kra.html#22604 And from the RPM That is not integrated into FreeIPA, but the packages are in Fedora as pki-kra The Data Recovery Manager (DRM) is an optional PKI subsystem that can act as a Key Recovery Authority (KRA). When configured in conjunction with the Certificate Authority (CA), the DRM stores private encryption keys as part of the certificate enrollment process. The key archival mechanism is triggered when a user enrolls in the PKI and creates the certificate request. Using the Certificate Request Message Format (CRMF) request format, a request is generated for the user's private encryption key. This key is then stored in the DRM which is configured to store keys in an encrypted format that can only be decrypted by several agents requesting the key at one time, providing for protection of the public encryption keys for the users in the PKI deployment. > This is not to say there aren't arguments against it: a policy mix up > or a bug in the central keystore could lead to *all* users having their > private keys compromised, and an admin who can dip in and grab private > keys without any evidence would also be bad, but hopefully the "Audit" > part of IPA means that any access to private keys will be securely > logged, and flagged if they are by users other than the "owner" of the > private key. > > This is a topic that is very important to me, so I'm quite interested > to hear how my reasoning may be flawed, or to hear opinions from others. > > Regards, > > Ian > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Wed Aug 3 17:02:22 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 03 Aug 2011 13:02:22 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E397592.8040406@hkl.hms.harvard.edu> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> <4E3957B5.4090703@hkl.hms.harvard.edu> <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> <4E397592.8040406@hkl.hms.harvard.edu> Message-ID: <1312390943.2125.17.camel@sgallagh520.bos.redhat.com> On Wed, 2011-08-03 at 12:21 -0400, Ian Stokes-Rees wrote: > > On Wed Aug 3 10:37:45 2011, Stephen Gallagher wrote: > > As a general rule, I would think that having your private key stored > > somewhere that an admin other than yourself can reset the password and > > have access to would be really dangerous. Most especially if this > > private key was being used to access sites in other administrative > > domains. > > > > That really sounds like an accident waiting to happen... > > If you are concerned about that, then don't make use of a centralized > keystore. > > You may be a security expert and have a deeper understanding of this > than I do, but from my limited experience and knowledge of security > audits and risk assessment, if you don't trust your system > administrators then you have a whole heap of other issues you need to > contend with. > > Consider that the FreeIPA server is probably *more* secure than the > user-accessible systems and file servers. If someone with > administrative (root) privs for the part of the system where I store my > passphrase encrypted private key would be the kind of person who would > take the private key from a central keystore, if it existed, then do > you not think they could get my passphrase and/or cleartext private key > from the system *without* a central keystore? > > This is not to say there aren't arguments against it: a policy mix up > or a bug in the central keystore could lead to *all* users having their > private keys compromised, and an admin who can dip in and grab private > keys without any evidence would also be bad, but hopefully the "Audit" > part of IPA means that any access to private keys will be securely > logged, and flagged if they are by users other than the "owner" of the > private key. > > This is a topic that is very important to me, so I'm quite interested > to hear how my reasoning may be flawed, or to hear opinions from others. As Adam pointed out, the default assumption is that no one is trusted. But my main concern is not that the admins have access to your private keys, but that they have access to your private keys *for an unrelated domain*. Even if both domains exist in your organization (e.g. CORP and ENG), you are implicitly granting the admin of the CORP domain permission to impersonate you on the ENG domain. You're also significantly increasing the damage surface of a successful attack against this domain. It's analogous to using the same password at many major sites: compromise one and you have the keys to all of the others. So I guess what I'm saying is not "Don't use centrally managed key storage", but rather "If you use the key anywhere but in this administrative domain, do not put it in centrally-managed storage that anyone but you can ever gain access to it". -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ijstokes at hkl.hms.harvard.edu Wed Aug 3 17:16:28 2011 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Wed, 03 Aug 2011 13:16:28 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E397995.90403@redhat.com> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> <4E3957B5.4090703@hkl.hms.harvard.edu> <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> <4E397592.8040406@hkl.hms.harvard.edu> <4E397995.90403@redhat.com> Message-ID: <4E39826C.6070005@hkl.hms.harvard.edu> On 8/3/11 12:38 PM, Adam Young wrote: > I think what you are interested in is the Data Recovery Manager > (DRM...hey, we had the acronym first, but we also call it Key > Recovery ) aspect of Certificate Server. That is awesome. That is exactly what I want. Do you have experience with this? If so, does it work if the certificate requests are being handled by an external entity? We use a Department of Energy CA located in California, but the users in our community are from across the US (and international), and we're looking to improve the process of them acquiring a usable "identity" in a federated environment. We're using FreeIPA internally, but if we can link it in to the cert request process and cert mgmt process (from the user end, not the CA end) that would be great. Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ijstokes.vcf Type: text/x-vcard Size: 380 bytes Desc: not available URL: From ijstokes at hkl.hms.harvard.edu Wed Aug 3 17:41:13 2011 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Wed, 03 Aug 2011 13:41:13 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <1312390943.2125.17.camel@sgallagh520.bos.redhat.com> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> <4E3957B5.4090703@hkl.hms.harvard.edu> <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> <4E397592.8040406@hkl.hms.harvard.edu> <1312390943.2125.17.camel@sgallagh520.bos.redhat.com> Message-ID: <4E398839.3010601@hkl.hms.harvard.edu> On 8/3/11 1:02 PM, Stephen Gallagher wrote: > So I guess what I'm saying is not "Don't use centrally managed key > storage", but rather "If you use the key anywhere but in this > administrative domain, do not put it in centrally-managed storage that > anyone but you can ever gain access to it". Yes, I appreciate the distinction you raise. Regarding your last comment quoted above, to the best of my knowledge that is impossible. I regularly have discussions with people saying "an administrator could always do X,Y and Z to access your supposedly private data" -- if there are ways in which I could be wrong about that, I'd love to know them. Otherwise I believe that the key risks from a centralized keystore are: * ease of compromise by an unscrupulous administrator * extent of compromise if attacker gains administrative privs to central keystore (although it sounds like the RH DRM system could significantly reduce that) * risk of compromise due to security vulnerabilities in central keystore software I think the general consensus is that you are always exposed to some degree of risk, and it is necessary to evaluate the risks versus the benefits. There are some lovely lakes in northern Maine where you can probably use your laptop without too much risk of compromised privacy, or closer to home, I'm sure most of us can remember a day when we got lots of useful work done on a computer with no network connection and were excited when we got one new piece of software every few months. In my risk/benefit world, a centralized keystore would be really useful. And for the record, if any one of the computers I use is compromised with a keyboard scanner or theft of my private ssh or X.509 keys, then I'm in a whole world of pain, and not a small amount of inconvenience (and risk of malicious attacks) to the various systems I regularly access. Best I can tell, that isn't too different from most people in my situation, and short of that nice cabin in Maine, is simply the reality (risk) of the kind of work I do, and the people I do it for. Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ijstokes.vcf Type: text/x-vcard Size: 380 bytes Desc: not available URL: From sgallagh at redhat.com Wed Aug 3 17:46:38 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 03 Aug 2011 13:46:38 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E398839.3010601@hkl.hms.harvard.edu> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> <4E3957B5.4090703@hkl.hms.harvard.edu> <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> <4E397592.8040406@hkl.hms.harvard.edu> <1312390943.2125.17.camel@sgallagh520.bos.redhat.com> <4E398839.3010601@hkl.hms.harvard.edu> Message-ID: <1312393599.2125.20.camel@sgallagh520.bos.redhat.com> On Wed, 2011-08-03 at 13:41 -0400, Ian Stokes-Rees wrote: > > > On 8/3/11 1:02 PM, Stephen Gallagher wrote: > > So I guess what I'm saying is not "Don't use centrally managed key > > storage", but rather "If you use the key anywhere but in this > > administrative domain, do not put it in centrally-managed storage > > that anyone but you can ever gain access to it". > > Yes, I appreciate the distinction you raise. Regarding your last > comment quoted above, to the best of my knowledge that is impossible. > I regularly have discussions with people saying "an administrator > could always do X,Y and Z to access your supposedly private data" -- > if there are ways in which I could be wrong about that, I'd love to > know them. Otherwise I believe that the key risks from a centralized > keystore are: > > * ease of compromise by an unscrupulous administrator > * extent of compromise if attacker gains administrative privs to > central keystore (although it sounds like the RH DRM system could > significantly reduce that) > * risk of compromise due to security vulnerabilities in central > keystore software > > I think the general consensus is that you are always exposed to some > degree of risk, and it is necessary to evaluate the risks versus the > benefits. There are some lovely lakes in northern Maine where you can > probably use your laptop without too much risk of compromised privacy, > or closer to home, I'm sure most of us can remember a day when we got > lots of useful work done on a computer with no network connection and > were excited when we got one new piece of software every few months. > > In my risk/benefit world, a centralized keystore would be really > useful. > > And for the record, if any one of the computers I use is compromised > with a keyboard scanner or theft of my private ssh or X.509 keys, then > I'm in a whole world of pain, and not a small amount of inconvenience > (and risk of malicious attacks) to the various systems I regularly > access. Best I can tell, that isn't too different from most people in > my situation, and short of that nice cabin in Maine, is simply the > reality (risk) of the kind of work I do, and the people I do it for. Well, there exist central storage approaches that don't allow even the local admin access to the data. The trade-off of course is that they can't reinstate your access if you forget the password. In other words, you can set a password that is used as a symmetric key for encrypting your data in the central store. It's still central and can be retrieved from anywhere, but only you know how to read it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From simo at redhat.com Wed Aug 3 17:56:02 2011 From: simo at redhat.com (Simo Sorce) Date: Wed, 03 Aug 2011 13:56:02 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <1312393599.2125.20.camel@sgallagh520.bos.redhat.com> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> <4E3957B5.4090703@hkl.hms.harvard.edu> <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> <4E397592.8040406@hkl.hms.harvard.edu> <1312390943.2125.17.camel@sgallagh520.bos.redhat.com> <4E398839.3010601@hkl.hms.harvard.edu> <1312393599.2125.20.camel@sgallagh520.bos.redhat.com> Message-ID: <1312394162.26968.54.camel@willson.li.ssimo.org> On Wed, 2011-08-03 at 13:46 -0400, Stephen Gallagher wrote: > On Wed, 2011-08-03 at 13:41 -0400, Ian Stokes-Rees wrote: > > > > > > On 8/3/11 1:02 PM, Stephen Gallagher wrote: > > > So I guess what I'm saying is not "Don't use centrally managed key > > > storage", but rather "If you use the key anywhere but in this > > > administrative domain, do not put it in centrally-managed storage > > > that anyone but you can ever gain access to it". > > > > Yes, I appreciate the distinction you raise. Regarding your last > > comment quoted above, to the best of my knowledge that is impossible. > > I regularly have discussions with people saying "an administrator > > could always do X,Y and Z to access your supposedly private data" -- > > if there are ways in which I could be wrong about that, I'd love to > > know them. Otherwise I believe that the key risks from a centralized > > keystore are: > > > > * ease of compromise by an unscrupulous administrator > > * extent of compromise if attacker gains administrative privs to > > central keystore (although it sounds like the RH DRM system could > > significantly reduce that) > > * risk of compromise due to security vulnerabilities in central > > keystore software > > > > I think the general consensus is that you are always exposed to some > > degree of risk, and it is necessary to evaluate the risks versus the > > benefits. There are some lovely lakes in northern Maine where you can > > probably use your laptop without too much risk of compromised privacy, > > or closer to home, I'm sure most of us can remember a day when we got > > lots of useful work done on a computer with no network connection and > > were excited when we got one new piece of software every few months. > > > > In my risk/benefit world, a centralized keystore would be really > > useful. > > > > And for the record, if any one of the computers I use is compromised > > with a keyboard scanner or theft of my private ssh or X.509 keys, then > > I'm in a whole world of pain, and not a small amount of inconvenience > > (and risk of malicious attacks) to the various systems I regularly > > access. Best I can tell, that isn't too different from most people in > > my situation, and short of that nice cabin in Maine, is simply the > > reality (risk) of the kind of work I do, and the people I do it for. > > > Well, there exist central storage approaches that don't allow even the > local admin access to the data. The trade-off of course is that they > can't reinstate your access if you forget the password. > > In other words, you can set a password that is used as a symmetric key > for encrypting your data in the central store. It's still central and > can be retrieved from anywhere, but only you know how to read it. In these situations to allow recovery you can have all data encrypted a second time with a central store public key. But the corresponding private key is not stored in a place accessible online and gaining access to the means to recover keys is subject to logging on a specialized system which audits everything you do and notifies all interested parties automatically when you access anyone's keys. That can be done but it is expensive, something we can plan for a the future, but not something we can do in the short term. Simo. -- Simo Sorce * Red Hat, Inc * New York From ijstokes at hkl.hms.harvard.edu Wed Aug 3 18:02:57 2011 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Wed, 03 Aug 2011 14:02:57 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <1312393599.2125.20.camel@sgallagh520.bos.redhat.com> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> <4E3957B5.4090703@hkl.hms.harvard.edu> <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> <4E397592.8040406@hkl.hms.harvard.edu> <1312390943.2125.17.camel@sgallagh520.bos.redhat.com> <4E398839.3010601@hkl.hms.harvard.edu> <1312393599.2125.20.camel@sgallagh520.bos.redhat.com> Message-ID: <4E398D51.7040902@hkl.hms.harvard.edu> On 8/3/11 1:46 PM, Stephen Gallagher wrote: > Well, there exist central storage approaches that don't allow even the > local admin access to the data. The trade-off of course is that they > can't reinstate your access if you forget the password. In other > words, you can set a password that is used as a symmetric key for > encrypting your data in the central store. It's still central and can > be retrieved from anywhere, but only you know how to read it. You still seem to be missing the relevance of unscrupulous administrators and compromised systems to "man in the middle" any interactions you have with this system. Unless you never access the data yourself once the unscrupulous admin or attacker has gained access, then such a person can pretty easily intercept your password and get at your data. Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ijstokes.vcf Type: text/x-vcard Size: 380 bytes Desc: not available URL: From sgallagh at redhat.com Wed Aug 3 18:05:51 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 03 Aug 2011 14:05:51 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E398D51.7040902@hkl.hms.harvard.edu> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> <4E3957B5.4090703@hkl.hms.harvard.edu> <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> <4E397592.8040406@hkl.hms.harvard.edu> <1312390943.2125.17.camel@sgallagh520.bos.redhat.com> <4E398839.3010601@hkl.hms.harvard.edu> <1312393599.2125.20.camel@sgallagh520.bos.redhat.com> <4E398D51.7040902@hkl.hms.harvard.edu> Message-ID: <1312394752.2125.22.camel@sgallagh520.bos.redhat.com> On Wed, 2011-08-03 at 14:02 -0400, Ian Stokes-Rees wrote: > > > On 8/3/11 1:46 PM, Stephen Gallagher wrote: > > Well, there exist central storage approaches that don't allow even > > the local admin access to the data. The trade-off of course is that > > they can't reinstate your access if you forget the password. In > > other words, you can set a password that is used as a symmetric key > > for encrypting your data in the central store. It's still central > > and can be retrieved from anywhere, but only you know how to read > > it. > > You still seem to be missing the relevance of unscrupulous > administrators and compromised systems to "man in the middle" any > interactions you have with this system. Unless you never access the > data yourself once the unscrupulous admin or attacker has gained > access, then such a person can pretty easily intercept your password > and get at your data. > > Ian No, the way that such a system would work is that the password would never be passed to the central server. Only the encrypted data would be sent and received. All decryption would happen locally. The most a man-in-the-middle attack could accomplish would be damaging the file so it couldn't be decrypted anymore. That could accomplish a denial-of-service, but not grant the attacker privileges to use your keys. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ijstokes at hkl.hms.harvard.edu Wed Aug 3 18:13:06 2011 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Wed, 03 Aug 2011 14:13:06 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <1312394752.2125.22.camel@sgallagh520.bos.redhat.com> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> <4E3957B5.4090703@hkl.hms.harvard.edu> <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> <4E397592.8040406@hkl.hms.harvard.edu> <1312390943.2125.17.camel@sgallagh520.bos.redhat.com> <4E398839.3010601@hkl.hms.harvard.edu> <1312393599.2125.20.camel@sgallagh520.bos.redhat.com> <4E398D51.7040902@hkl.hms.harvard.edu> <1312394752.2125.22.camel@sgallagh520.bos.redhat.com> Message-ID: <4E398FB2.7000706@hkl.hms.harvard.edu> On Wed Aug 3 14:05:51 2011, Stephen Gallagher wrote: > No, the way that such a system would work is that the password would > never be passed to the central server. Only the encrypted data would be > sent and received. All decryption would happen locally. The most a > man-in-the-middle attack could accomplish would be damaging the file so > it couldn't be decrypted anymore. That could accomplish a > denial-of-service, but not grant the attacker privileges to use your > keys. Yes, of course. I work so much on machines hosted in racks in some server room that I forget a lot of people do most of their work on a single physical machine that could have strong privilege separation so even "administrators" can't normally access the machine. I guess I'm imagining an environment where if there is *any* interest in a central keystore, then there are administrators who have full access to all systems that would access that central keystore, but your scenario is certainly possible. As you've pointed out, with that degree of autonomy over your own system surely it follows that you could choose not to use a central keystore if one were provided. Ian -------------- next part -------------- A non-text attachment was scrubbed... Name: ijstokes.vcf Type: text/x-vcard Size: 394 bytes Desc: not available URL: From ayoung at redhat.com Wed Aug 3 18:29:22 2011 From: ayoung at redhat.com (Adam Young) Date: Wed, 03 Aug 2011 14:29:22 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E39826C.6070005@hkl.hms.harvard.edu> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> <4E3957B5.4090703@hkl.hms.harvard.edu> <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> <4E397592.8040406@hkl.hms.harvard.edu> <4E397995.90403@redhat.com> <4E39826C.6070005@hkl.hms.harvard.edu> Message-ID: <4E399382.9000805@redhat.com> On 08/03/2011 01:16 PM, Ian Stokes-Rees wrote: > > > On 8/3/11 12:38 PM, Adam Young wrote: >> I think what you are interested in is the Data Recovery Manager >> (DRM...hey, we had the acronym first, but we also call it Key >> Recovery ) aspect of Certificate Server. > > That is awesome. That is exactly what I want. > > Do you have experience with this? If so, does it work if the > certificate requests are being handled by an external entity? We use > a Department of Energy CA located in California, but the users in our > community are from across the US (and international), and we're > looking to improve the process of them acquiring a usable "identity" > in a federated environment. We're using FreeIPA internally, but if we > can link it in to the cert request process and cert mgmt process (from > the user end, not the CA end) that would be great. > > Ian Experience? I've been on the Dogtag project for over a week now. I'm learning about it as we speak. The place to ask about Dogtag and the pki products is pki-users at redhat.com and the IRC Channel on freednode is *#dogtag-pki. *Integrating KRA into IPA is on the map, although I am not sure the timeframe. However, I suspect that our approach would be assuming you wanted your own CA. Not sure if you can do KRA with**an external CA.* * -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Aug 3 20:42:44 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 03 Aug 2011 16:42:44 -0400 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <4E2EC378.9050401@romal.de>, <4E2EC930.1060501@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E380026.5000707@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4E39B2C4.4020303@redhat.com> Steven Jones wrote: > Hi, > > Client > ========== > rhel61-64cl04.unix.vuw.ac.nz > Linux rhel61-64cl04.unix.vuw.ac.nz 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux > ipa-client-2.0.0-23.el6_1.1.x86_64 > libcurl-7.19.7-26.el6.x86_64 > Red Hat Enterprise Linux Client release 6.1 (Santiago) > ========== > > Server > ========== > Linux vuwunicoipamt01 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux > libcurl-7.19.7-26.el6_1.1.x86_64 > ipa-client-2.0.0-23.el6_1.1.x86_64 > ipa-server-2.0.0-23.el6_1.1.x86_64 > Red Hat Enterprise Linux Server release 6.1 (Santiago) > ========== > > install output > ========== > [root at rhel61-64cl04 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d > root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz', 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw.ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server': None, 'mkhomedir': True, 'unattended': None, 'principal': None} > root : DEBUG missing options might be asked for interactively later > > root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' > root : DEBUG [ipacheckldap] > root : DEBUG args=/usr/bin/wget -O /tmp/tmpaaTaqF/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > root : DEBUG stdout= > root : DEBUG stderr=--2011-08-03 09:01:14-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 > Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 779 [application/x-x509-ca-cert] > Saving to: `/tmp/tmpaaTaqF/ca.crt' > > 0K 100% 132M=0s > > 2011-08-03 09:01:14 (132 MB/s) - `/tmp/tmpaaTaqF/ca.crt' saved [779/779] > > > root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 > root : DEBUG Search rootdse > root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) > root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': ['unix.vuw.ac.nz']})] > root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) > root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vuw,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})] > root : DEBUG will use domain: unix.vuw.ac.nz > > root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz > > Discovery was successful! > root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ > > root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz > > Hostname: rhel61-64cl04.unix.vuw.ac.nz > Realm: UNIX.VUW.AC.NZ > DNS Domain: unix.vuw.ac.nz > IPA Server: vuwunicoipamt01.unix.vuw.ac.nz > BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz > > > Continue to configure the system with these values? [no]: yes > Enrollment principal: admin > root : DEBUG will use principal: admin > > root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > root : DEBUG stdout= > root : DEBUG stderr=--2011-08-03 09:01:22-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 > Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 779 [application/x-x509-ca-cert] > Saving to: `/etc/ipa/ca.crt' > > 0K 100% 96.5M=0s > > 2011-08-03 09:01:22 (96.5 MB/s) - `/etc/ipa/ca.crt' saved [779/779] > > > Password for admin at UNIX.VUW.AC.NZ: > root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ > root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: > > root : DEBUG stderr= > > root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d > root : DEBUG stdout= > root : DEBUG stderr=XML-RPC CALL: > > \r\n > \r\n > join\r\n > \r\n > \r\n > rhel61-64cl04.unix.vuw.ac.nz\r\n > \r\n > \r\n > nsosversion\r\n > 2.6.32-131.6.1.el6.x86_64\r\n > nshardwareplatform\r\n > x86_64\r\n > \r\n > \r\n > \r\n > > HTTP response code is 401, not 200 > > Joining realm failed because of failing XML-RPC request. > This error may be caused by incompatible server/client major versions. > root : DEBUG args=kdestroy > root : DEBUG stdout= > root : DEBUG stderr= > [root at rhel61-64cl04 ~]# > ========== > > Error log > ========== > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [notice] caught SIGTERM, shutting down > [Wed Aug 03 09:04:58 2011] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 > [Wed Aug 03 09:04:58 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > [Wed Aug 03 09:04:58 2011] [notice] Digest: generating secret for digest authentication ... > [Wed Aug 03 09:04:58 2011] [notice] Digest: done > [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Compiled for Python/2.6.2. > [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Runtime using Python/2.6.6. > [Wed Aug 03 09:04:59 2011] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations > [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** > [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** > ========== > This appears to be a different issue. If it were the libcurl problem on the server side we would see something like: AttributeError: 'thread._local' object has no attribute 'principal' Because you are getting a 401 and not a 500 it means that the principal is not being authenticated. I suspect that this is a kerberos problem. Can you check /var/log/krb5kdc to see if it is getting a service ticket request from your client? Another thing to try is to set LogLevel debug in /etc/httpd/conf.d/nss.conf and restart Apache. This will provide much more logging information on the Negotiate request from the client. rob From Steven.Jones at vuw.ac.nz Wed Aug 3 20:49:23 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 3 Aug 2011 20:49:23 +0000 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <4E2EC378.9050401@romal.de>,<4E2EC930.1060501@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E380026.5000707@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <833D8E48405E064EBC54C84EC6B36E40369E0285@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, I have also done this on a new f15 client and it also fails. But its saying, 500 and not 401 which is the rhel6.1 failure. "HTTP response code is 401, not 200" == RHEL61 "HTTP response code is 500, not 200" == FED15 ============== more fed15-install-error [root at fed15-64-ws02 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz' , 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw. ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server' : None, 'mkhomedir': True, 'unattended': None, 'principal': None} root : DEBUG missing options might be asked for interactively later root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' root : DEBUG [ipacheckldap] root : DEBUG args=/usr/bin/wget -O /tmp/tmpsyC9Zx/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt root : DEBUG stdout= root : DEBUG stderr=--2011-08-03 15:18:07-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 779 [application/x-x509-ca-cert] Saving to: ?/tmp/tmpsyC9Zx/ca.crt? 0K 100% 111M=0s 2011-08-03 15:18:07 (111 MB/s) - ?/tmp/tmpsyC9Zx/ca.crt? saved [779/779] root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 root : DEBUG Search rootdse root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainOb ject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': [ 'unix.vuw.ac.nz']})] root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vu w,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hma c-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScop e': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special ', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal' , 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMax RenewableAge': ['604800']})] root : DEBUG will use domain: unix.vuw.ac.nz root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz Discovery was successful! root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz Hostname: fed15-64-ws02.unix.vuw.ac.nz Realm: UNIX.VUW.AC.NZ DNS Domain: unix.vuw.ac.nz IPA Server: vuwunicoipamt01.unix.vuw.ac.nz BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz Continue to configure the system with these values? [no]: yes Enrollment principal: admin root : DEBUG will use principal: admin root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt root : DEBUG stdout= root : DEBUG stderr=--2011-08-03 15:18:12-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 779 [application/x-x509-ca-cert] Saving to: ?/etc/ipa/ca.crt? 0K 100% 112M=0s 2011-08-03 15:18:12 (112 MB/s) - ?/etc/ipa/ca.crt? saved [779/779] root : DEBUG Writing Kerberos configuration to /tmp/tmpiFqnW9: #File modified by ipa-client-install [libdefaults] default_realm = UNIX.VUW.AC.NZ dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes [realms] UNIX.VUW.AC.NZ = { pkinit_anchors = FILE:/etc/ipa/ca.crt } [domain_realm] .unix.vuw.ac.nz = UNIX.VUW.AC.NZ unix.vuw.ac.nz = UNIX.VUW.AC.NZ [appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false } Password for admin at UNIX.VUW.AC.NZ: root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: root : DEBUG stderr= root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d root : DEBUG stdout= root : DEBUG stderr=XML-RPC CALL: \r\n \r\n join\r\n \r\n \r\n fed15-64-ws02.unix.vuw.ac.nz\r\n \r\n \r\n nsosversion\r\n 2.6.38.6-26.rc1.fc15.x86_64\r\n nshardwareplatform\r\n x86_64\r\n \r\n \r\n \r\n HTTP response code is 500, not 200 Joining realm failed because of failing XML-RPC request. This error may be caused by incompatible server/client major versions. root : DEBUG args=kdestroy root : DEBUG stdout= root : DEBUG stderr= [root at fed15-64-ws02 ~]# ======================= regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Wednesday, 3 August 2011 9:35 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] version mismatch while joining a client ? Hi, Client ========== rhel61-64cl04.unix.vuw.ac.nz Linux rhel61-64cl04.unix.vuw.ac.nz 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux ipa-client-2.0.0-23.el6_1.1.x86_64 libcurl-7.19.7-26.el6.x86_64 Red Hat Enterprise Linux Client release 6.1 (Santiago) ========== Server ========== Linux vuwunicoipamt01 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux libcurl-7.19.7-26.el6_1.1.x86_64 ipa-client-2.0.0-23.el6_1.1.x86_64 ipa-server-2.0.0-23.el6_1.1.x86_64 Red Hat Enterprise Linux Server release 6.1 (Santiago) ========== install output ========== [root at rhel61-64cl04 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz', 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw.ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server': None, 'mkhomedir': True, 'unattended': None, 'principal': None} root : DEBUG missing options might be asked for interactively later root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' root : DEBUG [ipacheckldap] root : DEBUG args=/usr/bin/wget -O /tmp/tmpaaTaqF/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt root : DEBUG stdout= root : DEBUG stderr=--2011-08-03 09:01:14-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 779 [application/x-x509-ca-cert] Saving to: `/tmp/tmpaaTaqF/ca.crt' 0K 100% 132M=0s 2011-08-03 09:01:14 (132 MB/s) - `/tmp/tmpaaTaqF/ca.crt' saved [779/779] root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 root : DEBUG Search rootdse root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': ['unix.vuw.ac.nz']})] root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vuw,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})] root : DEBUG will use domain: unix.vuw.ac.nz root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz Discovery was successful! root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz Hostname: rhel61-64cl04.unix.vuw.ac.nz Realm: UNIX.VUW.AC.NZ DNS Domain: unix.vuw.ac.nz IPA Server: vuwunicoipamt01.unix.vuw.ac.nz BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz Continue to configure the system with these values? [no]: yes Enrollment principal: admin root : DEBUG will use principal: admin root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt root : DEBUG stdout= root : DEBUG stderr=--2011-08-03 09:01:22-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 779 [application/x-x509-ca-cert] Saving to: `/etc/ipa/ca.crt' 0K 100% 96.5M=0s 2011-08-03 09:01:22 (96.5 MB/s) - `/etc/ipa/ca.crt' saved [779/779] Password for admin at UNIX.VUW.AC.NZ: root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: root : DEBUG stderr= root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d root : DEBUG stdout= root : DEBUG stderr=XML-RPC CALL: \r\n \r\n join\r\n \r\n \r\n rhel61-64cl04.unix.vuw.ac.nz\r\n \r\n \r\n nsosversion\r\n 2.6.32-131.6.1.el6.x86_64\r\n nshardwareplatform\r\n x86_64\r\n \r\n \r\n \r\n HTTP response code is 401, not 200 Joining realm failed because of failing XML-RPC request. This error may be caused by incompatible server/client major versions. root : DEBUG args=kdestroy root : DEBUG stdout= root : DEBUG stderr= [root at rhel61-64cl04 ~]# ========== Error log ========== [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored [Wed Aug 03 09:04:57 2011] [notice] caught SIGTERM, shutting down [Wed Aug 03 09:04:58 2011] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 [Wed Aug 03 09:04:58 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Wed Aug 03 09:04:58 2011] [notice] Digest: generating secret for digest authentication ... [Wed Aug 03 09:04:58 2011] [notice] Digest: done [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Compiled for Python/2.6.2. [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Runtime using Python/2.6.6. [Wed Aug 03 09:04:59 2011] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** ========== regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Wednesday, 3 August 2011 1:48 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] version mismatch while joining a client ? Steven Jones wrote: > > Yes....enrolement now fails, previous messages I attached show that I think, it used to work. > > History, I had to remove all my working IPA clients due to a disk space problem on our SAN (we didnt have any). So I managed to keep the working IPA server and 2 x RHEL5 64 bit servers and the one un-configured template of RHEL6.1 64bit client I had. This I used to make client side clones off previously and connected them to IPA server and they worked. > > So lastweek I went back and with a running ipa server, I cloned in the old client/template and got the mis-match, so I put them on the production network and patched, same mismatch problem. > > I can do a sosreport of the old template I think and the client to look at the differences if that helps. I'm having a hard time following exactly what you are doing, on what machine. I think we need to be more systematic. Can you choose a machine to act as the client and provide the following: - distro and architecture (e.g. RHEL 6.1 on x86_64) - rpm -q curl libcurl - rpm -q ipa-client On the IPA server: - rpm -q ipa-server Start with a client that is not enrolled. If it has previously been enrolled run: ipa-client-install --uninstall -U Now run ipa-client-install and answer the questions as appropriate for your install. If it fails please provide the following: - any stdout you get from the client install - attach the full /var/log/ipaclient-install.log - attach the last 100 lines from /var/log/httpd/error_log from the IPA server rob From Steven.Jones at vuw.ac.nz Wed Aug 3 21:20:40 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 3 Aug 2011 21:20:40 +0000 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <4E39B2C4.4020303@redhat.com> References: <4E2EC378.9050401@romal.de>,<4E2EC930.1060501@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E380026.5000707@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E39B2C4.4020303@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40369E02AB@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Hopefully these will help. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Thursday, 4 August 2011 8:42 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] version mismatch while joining a client ? Steven Jones wrote: > Hi, > > Client > ========== > rhel61-64cl04.unix.vuw.ac.nz > Linux rhel61-64cl04.unix.vuw.ac.nz 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux > ipa-client-2.0.0-23.el6_1.1.x86_64 > libcurl-7.19.7-26.el6.x86_64 > Red Hat Enterprise Linux Client release 6.1 (Santiago) > ========== > > Server > ========== > Linux vuwunicoipamt01 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux > libcurl-7.19.7-26.el6_1.1.x86_64 > ipa-client-2.0.0-23.el6_1.1.x86_64 > ipa-server-2.0.0-23.el6_1.1.x86_64 > Red Hat Enterprise Linux Server release 6.1 (Santiago) > ========== > > install output > ========== > [root at rhel61-64cl04 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d > root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz', 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw.ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server': None, 'mkhomedir': True, 'unattended': None, 'principal': None} > root : DEBUG missing options might be asked for interactively later > > root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' > root : DEBUG [ipacheckldap] > root : DEBUG args=/usr/bin/wget -O /tmp/tmpaaTaqF/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > root : DEBUG stdout= > root : DEBUG stderr=--2011-08-03 09:01:14-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 > Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 779 [application/x-x509-ca-cert] > Saving to: `/tmp/tmpaaTaqF/ca.crt' > > 0K 100% 132M=0s > > 2011-08-03 09:01:14 (132 MB/s) - `/tmp/tmpaaTaqF/ca.crt' saved [779/779] > > > root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 > root : DEBUG Search rootdse > root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) > root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': ['unix.vuw.ac.nz']})] > root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) > root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vuw,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})] > root : DEBUG will use domain: unix.vuw.ac.nz > > root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz > > Discovery was successful! > root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ > > root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz > > Hostname: rhel61-64cl04.unix.vuw.ac.nz > Realm: UNIX.VUW.AC.NZ > DNS Domain: unix.vuw.ac.nz > IPA Server: vuwunicoipamt01.unix.vuw.ac.nz > BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz > > > Continue to configure the system with these values? [no]: yes > Enrollment principal: admin > root : DEBUG will use principal: admin > > root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > root : DEBUG stdout= > root : DEBUG stderr=--2011-08-03 09:01:22-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 > Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 779 [application/x-x509-ca-cert] > Saving to: `/etc/ipa/ca.crt' > > 0K 100% 96.5M=0s > > 2011-08-03 09:01:22 (96.5 MB/s) - `/etc/ipa/ca.crt' saved [779/779] > > > Password for admin at UNIX.VUW.AC.NZ: > root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ > root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: > > root : DEBUG stderr= > > root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d > root : DEBUG stdout= > root : DEBUG stderr=XML-RPC CALL: > > \r\n > \r\n > join\r\n > \r\n > \r\n > rhel61-64cl04.unix.vuw.ac.nz\r\n > \r\n > \r\n > nsosversion\r\n > 2.6.32-131.6.1.el6.x86_64\r\n > nshardwareplatform\r\n > x86_64\r\n > \r\n > \r\n > \r\n > > HTTP response code is 401, not 200 > > Joining realm failed because of failing XML-RPC request. > This error may be caused by incompatible server/client major versions. > root : DEBUG args=kdestroy > root : DEBUG stdout= > root : DEBUG stderr= > [root at rhel61-64cl04 ~]# > ========== > > Error log > ========== > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [notice] caught SIGTERM, shutting down > [Wed Aug 03 09:04:58 2011] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 > [Wed Aug 03 09:04:58 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > [Wed Aug 03 09:04:58 2011] [notice] Digest: generating secret for digest authentication ... > [Wed Aug 03 09:04:58 2011] [notice] Digest: done > [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Compiled for Python/2.6.2. > [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Runtime using Python/2.6.6. > [Wed Aug 03 09:04:59 2011] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations > [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** > [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** > ========== > This appears to be a different issue. If it were the libcurl problem on the server side we would see something like: AttributeError: 'thread._local' object has no attribute 'principal' Because you are getting a 401 and not a 500 it means that the principal is not being authenticated. I suspect that this is a kerberos problem. Can you check /var/log/krb5kdc to see if it is getting a service ticket request from your client? Another thing to try is to set LogLevel debug in /etc/httpd/conf.d/nss.conf and restart Apache. This will provide much more logging information on the Negotiate request from the client. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: access_log Type: application/octet-stream Size: 11700 bytes Desc: access_log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: error_log Type: application/octet-stream Size: 15166 bytes Desc: error_log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: f15-ipaclient-install.log Type: application/octet-stream Size: 5419 bytes Desc: f15-ipaclient-install.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rhel61cl-ipaclient-install.log Type: application/octet-stream Size: 4822 bytes Desc: rhel61cl-ipaclient-install.log URL: From rcritten at redhat.com Wed Aug 3 21:38:22 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 03 Aug 2011 17:38:22 -0400 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40369E02AB@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <4E2EC378.9050401@romal.de>, <4E2EC930.1060501@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E380026.5000707@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E39B2C4.4020303@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369E02AB@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4E39BFCE.4080802@redhat.com> Steven Jones wrote: > Hi, > > Hopefully these will help. It shows that you have two clients, one of which has a working libcurl and another that does not. The client 130.195.53.109 does not have a working libcurl as can be seen in the error log with the error "Client didn't delegate us their credential" and the principal error. The HTTP response is a 500. The second client is 130.195.53.104 and does have a working libcurl. The authentication is not accepted though and the request rejected with a 401. Do you have another KDC somewhere on your network? In the RHEL bits we had dns_lookup_kdc and dns_realm_kdc both set to True which causes the enrollment to use the wrong KDC even if you have things otherwise entered properly. You should be able to work around this by using the --force flag in ipa-client-install. rob > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Thursday, 4 August 2011 8:42 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Steven Jones wrote: >> Hi, >> >> Client >> ========== >> rhel61-64cl04.unix.vuw.ac.nz >> Linux rhel61-64cl04.unix.vuw.ac.nz 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux >> ipa-client-2.0.0-23.el6_1.1.x86_64 >> libcurl-7.19.7-26.el6.x86_64 >> Red Hat Enterprise Linux Client release 6.1 (Santiago) >> ========== >> >> Server >> ========== >> Linux vuwunicoipamt01 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux >> libcurl-7.19.7-26.el6_1.1.x86_64 >> ipa-client-2.0.0-23.el6_1.1.x86_64 >> ipa-server-2.0.0-23.el6_1.1.x86_64 >> Red Hat Enterprise Linux Server release 6.1 (Santiago) >> ========== >> >> install output >> ========== >> [root at rhel61-64cl04 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d >> root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz', 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw.ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server': None, 'mkhomedir': True, 'unattended': None, 'principal': None} >> root : DEBUG missing options might be asked for interactively later >> >> root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' >> root : DEBUG [ipacheckldap] >> root : DEBUG args=/usr/bin/wget -O /tmp/tmpaaTaqF/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> root : DEBUG stdout= >> root : DEBUG stderr=--2011-08-03 09:01:14-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 779 [application/x-x509-ca-cert] >> Saving to: `/tmp/tmpaaTaqF/ca.crt' >> >> 0K 100% 132M=0s >> >> 2011-08-03 09:01:14 (132 MB/s) - `/tmp/tmpaaTaqF/ca.crt' saved [779/779] >> >> >> root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 >> root : DEBUG Search rootdse >> root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) >> root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': ['unix.vuw.ac.nz']})] >> root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) >> root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vuw,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})] >> root : DEBUG will use domain: unix.vuw.ac.nz >> >> root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz >> >> Discovery was successful! >> root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ >> >> root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz >> >> Hostname: rhel61-64cl04.unix.vuw.ac.nz >> Realm: UNIX.VUW.AC.NZ >> DNS Domain: unix.vuw.ac.nz >> IPA Server: vuwunicoipamt01.unix.vuw.ac.nz >> BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz >> >> >> Continue to configure the system with these values? [no]: yes >> Enrollment principal: admin >> root : DEBUG will use principal: admin >> >> root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> root : DEBUG stdout= >> root : DEBUG stderr=--2011-08-03 09:01:22-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 779 [application/x-x509-ca-cert] >> Saving to: `/etc/ipa/ca.crt' >> >> 0K 100% 96.5M=0s >> >> 2011-08-03 09:01:22 (96.5 MB/s) - `/etc/ipa/ca.crt' saved [779/779] >> >> >> Password for admin at UNIX.VUW.AC.NZ: >> root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ >> root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: >> >> root : DEBUG stderr= >> >> root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d >> root : DEBUG stdout= >> root : DEBUG stderr=XML-RPC CALL: >> >> \r\n >> \r\n >> join\r\n >> \r\n >> \r\n >> rhel61-64cl04.unix.vuw.ac.nz\r\n >> \r\n >> \r\n >> nsosversion\r\n >> 2.6.32-131.6.1.el6.x86_64\r\n >> nshardwareplatform\r\n >> x86_64\r\n >> \r\n >> \r\n >> \r\n >> >> HTTP response code is 401, not 200 >> >> Joining realm failed because of failing XML-RPC request. >> This error may be caused by incompatible server/client major versions. >> root : DEBUG args=kdestroy >> root : DEBUG stdout= >> root : DEBUG stderr= >> [root at rhel61-64cl04 ~]# >> ========== >> >> Error log >> ========== >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [notice] caught SIGTERM, shutting down >> [Wed Aug 03 09:04:58 2011] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 >> [Wed Aug 03 09:04:58 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >> [Wed Aug 03 09:04:58 2011] [notice] Digest: generating secret for digest authentication ... >> [Wed Aug 03 09:04:58 2011] [notice] Digest: done >> [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Compiled for Python/2.6.2. >> [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Runtime using Python/2.6.6. >> [Wed Aug 03 09:04:59 2011] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations >> [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** >> [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** >> ========== >> > > This appears to be a different issue. If it were the libcurl problem on > the server side we would see something like: > > AttributeError: 'thread._local' object has no attribute 'principal' > > Because you are getting a 401 and not a 500 it means that the principal > is not being authenticated. > > I suspect that this is a kerberos problem. Can you check > /var/log/krb5kdc to see if it is getting a service ticket request from > your client? > > Another thing to try is to set LogLevel debug in > /etc/httpd/conf.d/nss.conf and restart Apache. This will provide much > more logging information on the Negotiate request from the client. > > rob From dpal at redhat.com Wed Aug 3 21:52:54 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 03 Aug 2011 17:52:54 -0400 Subject: [Freeipa-users] Some questions regarding IPA, DNS and Samba4 In-Reply-To: <1312371847.26968.28.camel@willson.li.ssimo.org> References: <4E390532.8030808@s3group.cz> <1312371847.26968.28.camel@willson.li.ssimo.org> Message-ID: <4E39C336.3060404@redhat.com> On 08/03/2011 07:44 AM, Simo Sorce wrote: >> I have some questions regarding IPA: >> > 1. On the IPA client side, which daemon is looking after machine >> > Kerberos host/ principal renewal? > Keytabs are random secrets and do not need to expire as cracking them is > consider a problem out of current computational reach unlike users > passwords which use a much smaller set of values and is less randomic in > nature. > There is none at the moment however it is generally a good practice to rotate even secure keys like keytabs from time to time. One of the ideas I have for that is to allow certmonger to bind with mutual SSL auth or using current keytab and request a new keytab instead of the old one. But this has not been even filed as an enhancement as no one cared about such functionality until now. What is your use case for this functionality? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Aug 3 22:04:23 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 03 Aug 2011 18:04:23 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E399382.9000805@redhat.com> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> <4E3957B5.4090703@hkl.hms.harvard.edu> <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> <4E397592.8040406@hkl.hms.harvard.edu> <4E397995.90403@redhat.com> <4E39826C.6070005@hkl.hms.harvard.edu> <4E399382.9000805@redhat.com> Message-ID: <4E39C5E7.8020507@redhat.com> On 08/03/2011 02:29 PM, Adam Young wrote: > On 08/03/2011 01:16 PM, Ian Stokes-Rees wrote: >> >> >> On 8/3/11 12:38 PM, Adam Young wrote: >>> I think what you are interested in is the Data Recovery Manager >>> (DRM...hey, we had the acronym first, but we also call it Key >>> Recovery ) aspect of Certificate Server. >> >> That is awesome. That is exactly what I want. >> >> Do you have experience with this? If so, does it work if the >> certificate requests are being handled by an external entity? We use >> a Department of Energy CA located in California, but the users in our >> community are from across the US (and international), and we're >> looking to improve the process of them acquiring a usable "identity" >> in a federated environment. We're using FreeIPA internally, but if >> we can link it in to the cert request process and cert mgmt process >> (from the user end, not the CA end) that would be great. >> >> Ian > Experience? I've been on the Dogtag project for over a week now. > I'm learning about it as we speak. > > The place to ask about Dogtag and the pki products is > pki-users at redhat.com > and the IRC > Channel on freednode is *#dogtag-pki. > > *Integrating KRA into IPA is on the map, although I am not sure the > timeframe. However, I suspect that our approach would be assuming you > wanted your own CA. Not sure if you can do KRA with**an external CA.* > * > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users DRM is the way to go. However it does not support symmetric keys now. This is the pert that we need for volume keys. May be it is the vault to store all sorts of keys. This is something that needs to be designed and looked at as a broader perspective. Adam likes to repeat a phase about dreaming big so I do. I want IPA to be a vault for all sorts of keys and passwords and what else. If DRM is the answer - great. I can start listing the use cases that such a key store should satisfy and we can design something that would altimately fit the build but build gradually knocking use cases one by one. I will take an action idem to come with the use cases. Give me couple weeks as I am under water now... -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Wed Aug 3 22:11:17 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 3 Aug 2011 22:11:17 +0000 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <4E39BFCE.4080802@redhat.com> References: <4E2EC378.9050401@romal.de>,<4E2EC930.1060501@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E380026.5000707@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E39B2C4.4020303@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369E02AB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E39BFCE.4080802@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40369E03A9@STAWINCOX10MBX1.staff.vuw.ac.nz> I have 3 x AD setups but the client points to the right DNS domain and the IPA server for DNS....I can halt all the ADs and re-try. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Thursday, 4 August 2011 9:38 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] version mismatch while joining a client ? Steven Jones wrote: > Hi, > > Hopefully these will help. It shows that you have two clients, one of which has a working libcurl and another that does not. The client 130.195.53.109 does not have a working libcurl as can be seen in the error log with the error "Client didn't delegate us their credential" and the principal error. The HTTP response is a 500. The second client is 130.195.53.104 and does have a working libcurl. The authentication is not accepted though and the request rejected with a 401. Do you have another KDC somewhere on your network? In the RHEL bits we had dns_lookup_kdc and dns_realm_kdc both set to True which causes the enrollment to use the wrong KDC even if you have things otherwise entered properly. You should be able to work around this by using the --force flag in ipa-client-install. rob > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Thursday, 4 August 2011 8:42 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Steven Jones wrote: >> Hi, >> >> Client >> ========== >> rhel61-64cl04.unix.vuw.ac.nz >> Linux rhel61-64cl04.unix.vuw.ac.nz 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux >> ipa-client-2.0.0-23.el6_1.1.x86_64 >> libcurl-7.19.7-26.el6.x86_64 >> Red Hat Enterprise Linux Client release 6.1 (Santiago) >> ========== >> >> Server >> ========== >> Linux vuwunicoipamt01 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux >> libcurl-7.19.7-26.el6_1.1.x86_64 >> ipa-client-2.0.0-23.el6_1.1.x86_64 >> ipa-server-2.0.0-23.el6_1.1.x86_64 >> Red Hat Enterprise Linux Server release 6.1 (Santiago) >> ========== >> >> install output >> ========== >> [root at rhel61-64cl04 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d >> root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz', 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw.ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server': None, 'mkhomedir': True, 'unattended': None, 'principal': None} >> root : DEBUG missing options might be asked for interactively later >> >> root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' >> root : DEBUG [ipacheckldap] >> root : DEBUG args=/usr/bin/wget -O /tmp/tmpaaTaqF/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> root : DEBUG stdout= >> root : DEBUG stderr=--2011-08-03 09:01:14-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 779 [application/x-x509-ca-cert] >> Saving to: `/tmp/tmpaaTaqF/ca.crt' >> >> 0K 100% 132M=0s >> >> 2011-08-03 09:01:14 (132 MB/s) - `/tmp/tmpaaTaqF/ca.crt' saved [779/779] >> >> >> root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 >> root : DEBUG Search rootdse >> root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) >> root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': ['unix.vuw.ac.nz']})] >> root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) >> root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vuw,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})] >> root : DEBUG will use domain: unix.vuw.ac.nz >> >> root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz >> >> Discovery was successful! >> root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ >> >> root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz >> >> Hostname: rhel61-64cl04.unix.vuw.ac.nz >> Realm: UNIX.VUW.AC.NZ >> DNS Domain: unix.vuw.ac.nz >> IPA Server: vuwunicoipamt01.unix.vuw.ac.nz >> BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz >> >> >> Continue to configure the system with these values? [no]: yes >> Enrollment principal: admin >> root : DEBUG will use principal: admin >> >> root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> root : DEBUG stdout= >> root : DEBUG stderr=--2011-08-03 09:01:22-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 779 [application/x-x509-ca-cert] >> Saving to: `/etc/ipa/ca.crt' >> >> 0K 100% 96.5M=0s >> >> 2011-08-03 09:01:22 (96.5 MB/s) - `/etc/ipa/ca.crt' saved [779/779] >> >> >> Password for admin at UNIX.VUW.AC.NZ: >> root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ >> root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: >> >> root : DEBUG stderr= >> >> root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d >> root : DEBUG stdout= >> root : DEBUG stderr=XML-RPC CALL: >> >> \r\n >> \r\n >> join\r\n >> \r\n >> \r\n >> rhel61-64cl04.unix.vuw.ac.nz\r\n >> \r\n >> \r\n >> nsosversion\r\n >> 2.6.32-131.6.1.el6.x86_64\r\n >> nshardwareplatform\r\n >> x86_64\r\n >> \r\n >> \r\n >> \r\n >> >> HTTP response code is 401, not 200 >> >> Joining realm failed because of failing XML-RPC request. >> This error may be caused by incompatible server/client major versions. >> root : DEBUG args=kdestroy >> root : DEBUG stdout= >> root : DEBUG stderr= >> [root at rhel61-64cl04 ~]# >> ========== >> >> Error log >> ========== >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [notice] caught SIGTERM, shutting down >> [Wed Aug 03 09:04:58 2011] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 >> [Wed Aug 03 09:04:58 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >> [Wed Aug 03 09:04:58 2011] [notice] Digest: generating secret for digest authentication ... >> [Wed Aug 03 09:04:58 2011] [notice] Digest: done >> [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Compiled for Python/2.6.2. >> [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Runtime using Python/2.6.6. >> [Wed Aug 03 09:04:59 2011] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations >> [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** >> [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** >> ========== >> > > This appears to be a different issue. If it were the libcurl problem on > the server side we would see something like: > > AttributeError: 'thread._local' object has no attribute 'principal' > > Because you are getting a 401 and not a 500 it means that the principal > is not being authenticated. > > I suspect that this is a kerberos problem. Can you check > /var/log/krb5kdc to see if it is getting a service ticket request from > your client? > > Another thing to try is to set LogLevel debug in > /etc/httpd/conf.d/nss.conf and restart Apache. This will provide much > more logging information on the Negotiate request from the client. > > rob From dpal at redhat.com Wed Aug 3 22:13:13 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 03 Aug 2011 18:13:13 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E3956E6.7090103@hkl.hms.harvard.edu> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E3956E6.7090103@hkl.hms.harvard.edu> Message-ID: <4E39C7F9.8010706@redhat.com> On 08/03/2011 10:10 AM, Ian Stokes-Rees wrote: > If there were some way to securely embed an arbitrary string in the > user profile, that would go a long way to solving this problem. At > least 4KB to cover a 2048 X.509 public key, but ideally 10 KB or > more. To remove the ACL complexity, just having it accessible only by > the user (token or password based fetch) would be suitable. Do not quite understand how that would work or what you mean. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Aug 3 22:20:11 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 03 Aug 2011 18:20:11 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <1312394162.26968.54.camel@willson.li.ssimo.org> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> <4E3957B5.4090703@hkl.hms.harvard.edu> <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> <4E397592.8040406@hkl.hms.harvard.edu> <1312390943.2125.17.camel@sgallagh520.bos.redhat.com> <4E398839.3010601@hkl.hms.harvard.edu> <1312393599.2125.20.camel@sgallagh520.bos.redhat.com> <1312394162.26968.54.camel@willson.li.ssimo.org> Message-ID: <4E39C99B.1090206@redhat.com> On 08/03/2011 01:56 PM, Simo Sorce wrote: > On Wed, 2011-08-03 at 13:46 -0400, Stephen Gallagher wrote: >> On Wed, 2011-08-03 at 13:41 -0400, Ian Stokes-Rees wrote: >>> >>> On 8/3/11 1:02 PM, Stephen Gallagher wrote: >>>> So I guess what I'm saying is not "Don't use centrally managed key >>>> storage", but rather "If you use the key anywhere but in this >>>> administrative domain, do not put it in centrally-managed storage >>>> that anyone but you can ever gain access to it". >>> Yes, I appreciate the distinction you raise. Regarding your last >>> comment quoted above, to the best of my knowledge that is impossible. >>> I regularly have discussions with people saying "an administrator >>> could always do X,Y and Z to access your supposedly private data" -- >>> if there are ways in which I could be wrong about that, I'd love to >>> know them. Otherwise I believe that the key risks from a centralized >>> keystore are: >>> >>> * ease of compromise by an unscrupulous administrator >>> * extent of compromise if attacker gains administrative privs to >>> central keystore (although it sounds like the RH DRM system could >>> significantly reduce that) >>> * risk of compromise due to security vulnerabilities in central >>> keystore software >>> >>> I think the general consensus is that you are always exposed to some >>> degree of risk, and it is necessary to evaluate the risks versus the >>> benefits. There are some lovely lakes in northern Maine where you can >>> probably use your laptop without too much risk of compromised privacy, >>> or closer to home, I'm sure most of us can remember a day when we got >>> lots of useful work done on a computer with no network connection and >>> were excited when we got one new piece of software every few months. >>> >>> In my risk/benefit world, a centralized keystore would be really >>> useful. >>> >>> And for the record, if any one of the computers I use is compromised >>> with a keyboard scanner or theft of my private ssh or X.509 keys, then >>> I'm in a whole world of pain, and not a small amount of inconvenience >>> (and risk of malicious attacks) to the various systems I regularly >>> access. Best I can tell, that isn't too different from most people in >>> my situation, and short of that nice cabin in Maine, is simply the >>> reality (risk) of the kind of work I do, and the people I do it for. >> >> Well, there exist central storage approaches that don't allow even the >> local admin access to the data. The trade-off of course is that they >> can't reinstate your access if you forget the password. >> >> In other words, you can set a password that is used as a symmetric key >> for encrypting your data in the central store. It's still central and >> can be retrieved from anywhere, but only you know how to read it. > In these situations to allow recovery you can have all data encrypted a > second time with a central store public key. But the corresponding > private key is not stored in a place accessible online and gaining > access to the means to recover keys is subject to logging on a > specialized system which audits everything you do and notifies all > interested parties automatically when you access anyone's keys. > > That can be done but it is expensive, something we can plan for a the > future, but not something we can do in the short term. > > Simo. > Simo and Stephen, I do not think we would be able to design this right here an right now. It is a complex problem. I think we should design the solution when time comes (this fall) to be secure but allow people to loosen the security if the environment they work in allows it. For example we never know anything about the physical security of the deployment thus we always assume worst. But it does not mean that the environment does not have other means to secure access and that IPA has to be the lonely soldier. IMO it is up to the deployment to avoid our tight security recommendations and implement less secure approaches. It is all a trade off that should be evaluated in a specific environment by people in charge. We should educate about best practices but not enforce as there are reasons not to follow them. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ondrejv at s3group.cz Thu Aug 4 07:52:22 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Thu, 04 Aug 2011 09:52:22 +0200 Subject: [Freeipa-users] Some questions regarding IPA, DNS and Samba4 In-Reply-To: <4E39C336.3060404@redhat.com> References: <4E390532.8030808@s3group.cz> <1312371847.26968.28.camel@willson.li.ssimo.org> <4E39C336.3060404@redhat.com> Message-ID: <4E3A4FB6.8070007@s3group.cz> On 03.08.2011 23:52, Dmitri Pal wrote: > But this has not been even filed as an enhancement as no one cared about > such functionality until now. > > What is your use case for this functionality? Actually, I do not need such a functionality. I was asking because I know Windows rotate keytabs so I was expecting IPA might as well. I guess there is no big press for it now but I would say in general we should support it as well - for security reasons if not for anything else. Ondrej The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirantpatil at gmail.com Thu Aug 4 09:24:13 2011 From: kirantpatil at gmail.com (Kiran Patil) Date: Thu, 4 Aug 2011 14:54:13 +0530 Subject: [Freeipa-users] Is it possible FreeIPA for Web Apps SingleSignOn like CAS? Message-ID: Did anybody got it working ? Please share your experiences with configuration details. Thanks, Kiran. From rcritten at redhat.com Thu Aug 4 13:24:59 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 04 Aug 2011 09:24:59 -0400 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40369E0285@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <4E2EC378.9050401@romal.de>, <4E2EC930.1060501@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E380026.5000707@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E0285@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4E3A9DAB.30901@redhat.com> Steven Jones wrote: > Hi, > > I have also done this on a new f15 client and it also fails. > > But its saying, > > 500 and not 401 which is the rhel6.1 failure. > > "HTTP response code is 401, not 200" == RHEL61 > "HTTP response code is 500, not 200" == FED15 Assuming that the Fedora 15 client is 130.195.53.109 that I had seen in a previous log it has a libcurl that does not do ticket delegation. 500 is an HTTP server error, we assume a principal will be there and it isn't and things blow up (this is handled more gracefully in our dev tree). 401 is a HTTP authorization error, the user provide is now allowed to access the server. I'm guessing this is because the client is using the wrong kerberos server. We have this addressed too in the dev tree, we disable dns lookups in krb5.conf. In the meantime --force should make it use the info you provide. rob > > > ============== > more fed15-install-error > [root at fed15-64-ws02 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d > root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz' > , 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw. > ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server' > : None, 'mkhomedir': True, 'unattended': None, 'principal': None} > root : DEBUG missing options might be asked for interactively later > > root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' > root : DEBUG [ipacheckldap] > root : DEBUG args=/usr/bin/wget -O /tmp/tmpsyC9Zx/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > root : DEBUG stdout= > root : DEBUG stderr=--2011-08-03 15:18:07-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 > Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 779 [application/x-x509-ca-cert] > Saving to: ?/tmp/tmpsyC9Zx/ca.crt? > > 0K 100% 111M=0s > > 2011-08-03 15:18:07 (111 MB/s) - ?/tmp/tmpsyC9Zx/ca.crt? saved [779/779] > > > root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 > root : DEBUG Search rootdse > root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) > root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainOb > ject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': [ > 'unix.vuw.ac.nz']})] > root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) > root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vu > w,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hma > c-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScop > e': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special > ', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal' > , 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMax > RenewableAge': ['604800']})] > root : DEBUG will use domain: unix.vuw.ac.nz > > root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz > > Discovery was successful! > root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ > > root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz > > Hostname: fed15-64-ws02.unix.vuw.ac.nz > Realm: UNIX.VUW.AC.NZ > DNS Domain: unix.vuw.ac.nz > IPA Server: vuwunicoipamt01.unix.vuw.ac.nz > BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz > > > Continue to configure the system with these values? [no]: yes > Enrollment principal: admin > root : DEBUG will use principal: admin > > root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > root : DEBUG stdout= > root : DEBUG stderr=--2011-08-03 15:18:12-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 > Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 779 [application/x-x509-ca-cert] > Saving to: ?/etc/ipa/ca.crt? > > 0K 100% 112M=0s > > 2011-08-03 15:18:12 (112 MB/s) - ?/etc/ipa/ca.crt? saved [779/779] > > > root : DEBUG Writing Kerberos configuration to /tmp/tmpiFqnW9: > #File modified by ipa-client-install > > [libdefaults] > default_realm = UNIX.VUW.AC.NZ > dns_lookup_realm = true > dns_lookup_kdc = true > rdns = false > ticket_lifetime = 24h > forwardable = yes > > [realms] > UNIX.VUW.AC.NZ = { > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > [domain_realm] > .unix.vuw.ac.nz = UNIX.VUW.AC.NZ > unix.vuw.ac.nz = UNIX.VUW.AC.NZ > > [appdefaults] > pam = { > debug = false > ticket_lifetime = 36000 > renew_lifetime = 36000 > forwardable = true > krb4_convert = false > } > > Password for admin at UNIX.VUW.AC.NZ: > root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ > root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: > > root : DEBUG stderr= > > root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d > root : DEBUG stdout= > root : DEBUG stderr=XML-RPC CALL: > > \r\n > \r\n > join\r\n > \r\n > \r\n > fed15-64-ws02.unix.vuw.ac.nz\r\n > \r\n > \r\n > nsosversion\r\n > 2.6.38.6-26.rc1.fc15.x86_64\r\n > nshardwareplatform\r\n > x86_64\r\n > \r\n > \r\n > \r\n > > HTTP response code is 500, not 200 > > Joining realm failed because of failing XML-RPC request. > This error may be caused by incompatible server/client major versions. > root : DEBUG args=kdestroy > root : DEBUG stdout= > root : DEBUG stderr= > [root at fed15-64-ws02 ~]# > ======================= > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] > Sent: Wednesday, 3 August 2011 9:35 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Hi, > > Client > ========== > rhel61-64cl04.unix.vuw.ac.nz > Linux rhel61-64cl04.unix.vuw.ac.nz 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux > ipa-client-2.0.0-23.el6_1.1.x86_64 > libcurl-7.19.7-26.el6.x86_64 > Red Hat Enterprise Linux Client release 6.1 (Santiago) > ========== > > Server > ========== > Linux vuwunicoipamt01 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux > libcurl-7.19.7-26.el6_1.1.x86_64 > ipa-client-2.0.0-23.el6_1.1.x86_64 > ipa-server-2.0.0-23.el6_1.1.x86_64 > Red Hat Enterprise Linux Server release 6.1 (Santiago) > ========== > > install output > ========== > [root at rhel61-64cl04 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d > root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz', 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw.ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server': None, 'mkhomedir': True, 'unattended': None, 'principal': None} > root : DEBUG missing options might be asked for interactively later > > root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' > root : DEBUG [ipacheckldap] > root : DEBUG args=/usr/bin/wget -O /tmp/tmpaaTaqF/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > root : DEBUG stdout= > root : DEBUG stderr=--2011-08-03 09:01:14-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 > Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 779 [application/x-x509-ca-cert] > Saving to: `/tmp/tmpaaTaqF/ca.crt' > > 0K 100% 132M=0s > > 2011-08-03 09:01:14 (132 MB/s) - `/tmp/tmpaaTaqF/ca.crt' saved [779/779] > > > root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 > root : DEBUG Search rootdse > root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) > root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': ['unix.vuw.ac.nz']})] > root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) > root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vuw,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})] > root : DEBUG will use domain: unix.vuw.ac.nz > > root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz > > Discovery was successful! > root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ > > root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz > > Hostname: rhel61-64cl04.unix.vuw.ac.nz > Realm: UNIX.VUW.AC.NZ > DNS Domain: unix.vuw.ac.nz > IPA Server: vuwunicoipamt01.unix.vuw.ac.nz > BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz > > > Continue to configure the system with these values? [no]: yes > Enrollment principal: admin > root : DEBUG will use principal: admin > > root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > root : DEBUG stdout= > root : DEBUG stderr=--2011-08-03 09:01:22-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 > Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 779 [application/x-x509-ca-cert] > Saving to: `/etc/ipa/ca.crt' > > 0K 100% 96.5M=0s > > 2011-08-03 09:01:22 (96.5 MB/s) - `/etc/ipa/ca.crt' saved [779/779] > > > Password for admin at UNIX.VUW.AC.NZ: > root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ > root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: > > root : DEBUG stderr= > > root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d > root : DEBUG stdout= > root : DEBUG stderr=XML-RPC CALL: > > \r\n > \r\n > join\r\n > \r\n > \r\n > rhel61-64cl04.unix.vuw.ac.nz\r\n > \r\n > \r\n > nsosversion\r\n > 2.6.32-131.6.1.el6.x86_64\r\n > nshardwareplatform\r\n > x86_64\r\n > \r\n > \r\n > \r\n > > HTTP response code is 401, not 200 > > Joining realm failed because of failing XML-RPC request. > This error may be caused by incompatible server/client major versions. > root : DEBUG args=kdestroy > root : DEBUG stdout= > root : DEBUG stderr= > [root at rhel61-64cl04 ~]# > ========== > > Error log > ========== > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [notice] caught SIGTERM, shutting down > [Wed Aug 03 09:04:58 2011] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 > [Wed Aug 03 09:04:58 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > [Wed Aug 03 09:04:58 2011] [notice] Digest: generating secret for digest authentication ... > [Wed Aug 03 09:04:58 2011] [notice] Digest: done > [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Compiled for Python/2.6.2. > [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Runtime using Python/2.6.6. > [Wed Aug 03 09:04:59 2011] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations > [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** > [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** > ========== > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Wednesday, 3 August 2011 1:48 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Steven Jones wrote: >> >> Yes....enrolement now fails, previous messages I attached show that I think, it used to work. >> >> History, I had to remove all my working IPA clients due to a disk space problem on our SAN (we didnt have any). So I managed to keep the working IPA server and 2 x RHEL5 64 bit servers and the one un-configured template of RHEL6.1 64bit client I had. This I used to make client side clones off previously and connected them to IPA server and they worked. >> >> So lastweek I went back and with a running ipa server, I cloned in the old client/template and got the mis-match, so I put them on the production network and patched, same mismatch problem. >> >> I can do a sosreport of the old template I think and the client to look at the differences if that helps. > > I'm having a hard time following exactly what you are doing, on what > machine. I think we need to be more systematic. > > Can you choose a machine to act as the client and provide the following: > > - distro and architecture (e.g. RHEL 6.1 on x86_64) > - rpm -q curl libcurl > - rpm -q ipa-client > > On the IPA server: > - rpm -q ipa-server > > Start with a client that is not enrolled. If it has previously been > enrolled run: ipa-client-install --uninstall -U > > Now run ipa-client-install and answer the questions as appropriate for > your install. > > If it fails please provide the following: > - any stdout you get from the client install > - attach the full /var/log/ipaclient-install.log > - attach the last 100 lines from /var/log/httpd/error_log from the IPA > server > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Thu Aug 4 14:25:02 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 04 Aug 2011 10:25:02 -0400 Subject: [Freeipa-users] Some questions regarding IPA, DNS and Samba4 In-Reply-To: <4E3A4FB6.8070007@s3group.cz> References: <4E390532.8030808@s3group.cz> <1312371847.26968.28.camel@willson.li.ssimo.org> <4E39C336.3060404@redhat.com> <4E3A4FB6.8070007@s3group.cz> Message-ID: <4E3AABBE.1020104@redhat.com> On 08/04/2011 03:52 AM, Ondrej Valousek wrote: > > On 03.08.2011 23:52, Dmitri Pal wrote: >> But this has not been even filed as an enhancement as no one cared about >> such functionality until now. >> >> What is your use case for this functionality? > Actually, I do not need such a functionality. I was asking because I > know Windows rotate keytabs so I was expecting IPA might as well. > I guess there is no big press for it now but I would say in general we > should support it as well - for security reasons if not for anything else. > I created a BZ. I am not sure certmonger is the right component https://bugzilla.redhat.com/show_bug.cgi?id=728263 But at least it will be on the plate of the right person to make the decision and propose alternative approaches. > Ondrej > > ------------------------------------------------------------------------ > The information contained in this e-mail and in any attachments is > confidential and is designated solely for the attention of the > intended recipient(s). If you are not an intended recipient, you must > not use, disclose, copy, distribute or retain this e-mail or any part > thereof. If you have received this e-mail in error, please notify the > sender by return e-mail and delete all copies of this e-mail from your > computer system(s). Please direct any additional queries to: > communications at s3group.com. Thank You. Silicon and Software Systems > Limited (S3 Group). Registered in Ireland no. 378073. Registered > Office: South County Business Park, Leopardstown, Dublin 18 > ------------------------------------------------------------------------ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Aug 4 14:28:55 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 04 Aug 2011 10:28:55 -0400 Subject: [Freeipa-users] Some questions regarding IPA, DNS and Samba4 In-Reply-To: <4E3AABBE.1020104@redhat.com> References: <4E390532.8030808@s3group.cz> <1312371847.26968.28.camel@willson.li.ssimo.org> <4E39C336.3060404@redhat.com> <4E3A4FB6.8070007@s3group.cz> <4E3AABBE.1020104@redhat.com> Message-ID: <1312468135.11512.7.camel@willson.li.ssimo.org> On Thu, 2011-08-04 at 10:25 -0400, Dmitri Pal wrote: > On 08/04/2011 03:52 AM, Ondrej Valousek wrote: > > > > On 03.08.2011 23:52, Dmitri Pal wrote: > > > But this has not been even filed as an enhancement as no one cared about > > > such functionality until now. > > > > > > What is your use case for this functionality? > > Actually, I do not need such a functionality. I was asking because I > > know Windows rotate keytabs so I was expecting IPA might as well. > > I guess there is no big press for it now but I would say in general > > we should support it as well - for security reasons if not for > > anything else. > > > > I created a BZ. I am not sure certmonger is the right component > https://bugzilla.redhat.com/show_bug.cgi?id=728263 > But at least it will be on the plate of the right person to make the > decision and propose alternative approaches. SSSD is probably a more appropriate component for keytabs, given in the IPA case it is a primary user of the keytab for validation purposes. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Thu Aug 4 14:43:02 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 04 Aug 2011 10:43:02 -0400 Subject: [Freeipa-users] Some questions regarding IPA, DNS and Samba4 In-Reply-To: <1312468135.11512.7.camel@willson.li.ssimo.org> References: <4E390532.8030808@s3group.cz> <1312371847.26968.28.camel@willson.li.ssimo.org> <4E39C336.3060404@redhat.com> <4E3A4FB6.8070007@s3group.cz> <4E3AABBE.1020104@redhat.com> <1312468135.11512.7.camel@willson.li.ssimo.org> Message-ID: <4E3AAFF6.9080204@redhat.com> On 08/04/2011 10:28 AM, Simo Sorce wrote: > On Thu, 2011-08-04 at 10:25 -0400, Dmitri Pal wrote: >> On 08/04/2011 03:52 AM, Ondrej Valousek wrote: >>> On 03.08.2011 23:52, Dmitri Pal wrote: >>>> But this has not been even filed as an enhancement as no one cared about >>>> such functionality until now. >>>> >>>> What is your use case for this functionality? >>> Actually, I do not need such a functionality. I was asking because I >>> know Windows rotate keytabs so I was expecting IPA might as well. >>> I guess there is no big press for it now but I would say in general >>> we should support it as well - for security reasons if not for >>> anything else. >>> >> I created a BZ. I am not sure certmonger is the right component >> https://bugzilla.redhat.com/show_bug.cgi?id=728263 >> But at least it will be on the plate of the right person to make the >> decision and propose alternative approaches. > SSSD is probably a more appropriate component for keytabs, given in the > IPA case it is a primary user of the keytab for validation purposes. > > Simo. > Yes. May be it is SSSD. But may be the kerberos library should have a way to rotate keytabs over the kerberos protocol? That would be even better as key rotation would then become a centrally managed policy rather than triggered by a client. The BZ will help me not to forget to start a broader discussion on the matter when time comes. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Thu Aug 4 14:44:01 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 04 Aug 2011 10:44:01 -0400 Subject: [Freeipa-users] Is it possible FreeIPA for Web Apps SingleSignOn like CAS? In-Reply-To: References: Message-ID: <4E3AB031.8010209@redhat.com> On 08/04/2011 05:24 AM, Kiran Patil wrote: > Did anybody got it working ? > > Please share your experiences with configuration details. > > Thanks, > Kiran. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > Which CAS server implementation you are using? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ayoung at redhat.com Thu Aug 4 14:50:45 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 04 Aug 2011 10:50:45 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E39C5E7.8020507@redhat.com> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> <4E3957B5.4090703@hkl.hms.harvard.edu> <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> <4E397592.8040406@hkl.hms.harvard.edu> <4E397995.90403@redhat.com> <4E39826C.6070005@hkl.hms.harvard.edu> <4E399382.9000805@redhat.com> <4E39C5E7.8020507@redhat.com> Message-ID: <4E3AB1C5.5040806@redhat.com> > DRM is the way to go. However it does not support symmetric keys now. > This is the pert that we need for volume keys. May be it is the vault > to store all sorts of keys. This is something that needs to be > designed and looked at as a broader perspective. > Adam likes to repeat a phase about dreaming big so I do. I want IPA to > be a vault for all sorts of keys and passwords and what else. If DRM > is the answer - great. > I can start listing the use cases that such a key store should satisfy > and we can design something that would altimately fit the build but > build gradually knocking use cases one by one. > I will take an action idem to come with the use cases. Give me couple > weeks as I am under water now... Specifically: the phrase is "Dream big, implement small." There are four things here, I'd guess, that should play into the design. 1. User certificates in IPA. Discussed already, and probably the first thing to implement on the IPA side. 2. DRM/KRA talking to an external CA. Not sure if this makes sense, has been discussed etc. 3. DRM/KRA Integration into IPA. Regardless of 2, we should talk through the use cases for integration 4. DRM/KRA Support for symmetric keys etc. From simo at redhat.com Thu Aug 4 14:47:32 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 04 Aug 2011 10:47:32 -0400 Subject: [Freeipa-users] Some questions regarding IPA, DNS and Samba4 In-Reply-To: <4E3AAFF6.9080204@redhat.com> References: <4E390532.8030808@s3group.cz> <1312371847.26968.28.camel@willson.li.ssimo.org> <4E39C336.3060404@redhat.com> <4E3A4FB6.8070007@s3group.cz> <4E3AABBE.1020104@redhat.com> <1312468135.11512.7.camel@willson.li.ssimo.org> <4E3AAFF6.9080204@redhat.com> Message-ID: <1312469252.11512.13.camel@willson.li.ssimo.org> On Thu, 2011-08-04 at 10:43 -0400, Dmitri Pal wrote: > On 08/04/2011 10:28 AM, Simo Sorce wrote: > > On Thu, 2011-08-04 at 10:25 -0400, Dmitri Pal wrote: > >> On 08/04/2011 03:52 AM, Ondrej Valousek wrote: > >>> On 03.08.2011 23:52, Dmitri Pal wrote: > >>>> But this has not been even filed as an enhancement as no one cared about > >>>> such functionality until now. > >>>> > >>>> What is your use case for this functionality? > >>> Actually, I do not need such a functionality. I was asking because I > >>> know Windows rotate keytabs so I was expecting IPA might as well. > >>> I guess there is no big press for it now but I would say in general > >>> we should support it as well - for security reasons if not for > >>> anything else. > >>> > >> I created a BZ. I am not sure certmonger is the right component > >> https://bugzilla.redhat.com/show_bug.cgi?id=728263 > >> But at least it will be on the plate of the right person to make the > >> decision and propose alternative approaches. > > SSSD is probably a more appropriate component for keytabs, given in the > > IPA case it is a primary user of the keytab for validation purposes. > > > > Simo. > > > Yes. May be it is SSSD. But may be the kerberos library should have a > way to rotate keytabs over the kerberos protocol? Yes it is called a password change technically :) > That would be even better as key rotation would then become a centrally > managed policy rather than triggered by a client. You cannot do it outside of a client, only the client has the original key to do (and be able to receive on a secure channel) the password change. > The BZ will help me not to forget to start a broader discussion on the > matter when time comes. Ok. Simo. -- Simo Sorce * Red Hat, Inc * New York From ondrejv at s3group.cz Thu Aug 4 14:48:21 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Thu, 04 Aug 2011 16:48:21 +0200 Subject: [Freeipa-users] Some questions regarding IPA, DNS and Samba4 In-Reply-To: <1312468135.11512.7.camel@willson.li.ssimo.org> References: <4E390532.8030808@s3group.cz> <1312371847.26968.28.camel@willson.li.ssimo.org> <4E39C336.3060404@redhat.com> <4E3A4FB6.8070007@s3group.cz> <4E3AABBE.1020104@redhat.com> <1312468135.11512.7.camel@willson.li.ssimo.org> Message-ID: <4E3AB135.6060001@s3group.cz> I agree with Simo, I would expect this from sssd instead, also given the fact that sssd will in future also handle winbind's "net *" commands, this seems to me like a most natural way... Ondrej On 04.08.2011 16:28, Simo Sorce wrote: > SSSD is probably a more appropriate component for keytabs, given in the > IPA case it is a primary user of the keytab for validation purposes. > The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Aug 4 14:53:39 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 04 Aug 2011 10:53:39 -0400 Subject: [Freeipa-users] Some questions regarding IPA, DNS and Samba4 In-Reply-To: <1312469252.11512.13.camel@willson.li.ssimo.org> References: <4E390532.8030808@s3group.cz> <1312371847.26968.28.camel@willson.li.ssimo.org> <4E39C336.3060404@redhat.com> <4E3A4FB6.8070007@s3group.cz> <4E3AABBE.1020104@redhat.com> <1312468135.11512.7.camel@willson.li.ssimo.org> <4E3AAFF6.9080204@redhat.com> <1312469252.11512.13.camel@willson.li.ssimo.org> Message-ID: <4E3AB273.1010907@redhat.com> On 08/04/2011 10:47 AM, Simo Sorce wrote: > On Thu, 2011-08-04 at 10:43 -0400, Dmitri Pal wrote: >> On 08/04/2011 10:28 AM, Simo Sorce wrote: >>> On Thu, 2011-08-04 at 10:25 -0400, Dmitri Pal wrote: >>>> On 08/04/2011 03:52 AM, Ondrej Valousek wrote: >>>>> On 03.08.2011 23:52, Dmitri Pal wrote: >>>>>> But this has not been even filed as an enhancement as no one cared about >>>>>> such functionality until now. >>>>>> >>>>>> What is your use case for this functionality? >>>>> Actually, I do not need such a functionality. I was asking because I >>>>> know Windows rotate keytabs so I was expecting IPA might as well. >>>>> I guess there is no big press for it now but I would say in general >>>>> we should support it as well - for security reasons if not for >>>>> anything else. >>>>> >>>> I created a BZ. I am not sure certmonger is the right component >>>> https://bugzilla.redhat.com/show_bug.cgi?id=728263 >>>> But at least it will be on the plate of the right person to make the >>>> decision and propose alternative approaches. >>> SSSD is probably a more appropriate component for keytabs, given in the >>> IPA case it is a primary user of the keytab for validation purposes. >>> >>> Simo. >>> >> Yes. May be it is SSSD. But may be the kerberos library should have a >> way to rotate keytabs over the kerberos protocol? > Yes it is called a password change technically :) > >> That would be even better as key rotation would then become a centrally >> managed policy rather than triggered by a client. > You cannot do it outside of a client, only the client has the original > key to do (and be able to receive on a secure channel) the password > change. Yes but server can indicate in some attribute to the client that it is time to start doing this and the client will do the change. >> The BZ will help me not to forget to start a broader discussion on the >> matter when time comes. > Ok. > > Simo. > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ondrejv at s3group.cz Thu Aug 4 14:59:22 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Thu, 04 Aug 2011 16:59:22 +0200 Subject: [Freeipa-users] Some questions regarding IPA, DNS and Samba4 In-Reply-To: <4E3AB273.1010907@redhat.com> References: <4E390532.8030808@s3group.cz> <1312371847.26968.28.camel@willson.li.ssimo.org> <4E39C336.3060404@redhat.com> <4E3A4FB6.8070007@s3group.cz> <4E3AABBE.1020104@redhat.com> <1312468135.11512.7.camel@willson.li.ssimo.org> <4E3AAFF6.9080204@redhat.com> <1312469252.11512.13.camel@willson.li.ssimo.org> <4E3AB273.1010907@redhat.com> Message-ID: <4E3AB3CA.8060402@s3group.cz> On 04.08.2011 16:53, Dmitri Pal wrote: > Yes but server can indicate in some attribute to the client that it is > time to start doing this and the client will do the change. > Would not be just easiest to steal some code from winbind? It is doing the same thing for Samba right? I guess it should not be that different in IPA. But it is only a wild guess... Ondrej The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirantpatil at gmail.com Thu Aug 4 15:07:34 2011 From: kirantpatil at gmail.com (Kiran Patil) Date: Thu, 4 Aug 2011 20:37:34 +0530 Subject: [Freeipa-users] Is it possible FreeIPA for Web Apps SingleSignOn like CAS? In-Reply-To: <4E3AB031.8010209@redhat.com> References: <4E3AB031.8010209@redhat.com> Message-ID: >> > Which CAS server implementation you are using? > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > Sorry, I picked the subject from one of the earlier thread of FreeIPA user list. Right now we are evaluating different solutions. We found that FreeIPA project interesting, which provides all in one solution which is backed by Redhat and community members. I have also seen a enhancement request of SAML in FreeIPA (https://fedorahosted.org/freeipa/ticket/1275). I wanted to know, since RapidNoreapeat(https://www.redhat.com/archives/freeipa-users/2011-July/msg00103.html) has raised this question earlier, that he is succeeded in implementing the solution. Thanks, Kiran Patil. From dpal at redhat.com Thu Aug 4 16:21:41 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 04 Aug 2011 12:21:41 -0400 Subject: [Freeipa-users] Some questions regarding IPA, DNS and Samba4 In-Reply-To: <4E3AB3CA.8060402@s3group.cz> References: <4E390532.8030808@s3group.cz> <1312371847.26968.28.camel@willson.li.ssimo.org> <4E39C336.3060404@redhat.com> <4E3A4FB6.8070007@s3group.cz> <4E3AABBE.1020104@redhat.com> <1312468135.11512.7.camel@willson.li.ssimo.org> <4E3AAFF6.9080204@redhat.com> <1312469252.11512.13.camel@willson.li.ssimo.org> <4E3AB273.1010907@redhat.com> <4E3AB3CA.8060402@s3group.cz> Message-ID: <4E3AC715.4080805@redhat.com> On 08/04/2011 10:59 AM, Ondrej Valousek wrote: > > > On 04.08.2011 16:53, Dmitri Pal wrote: >> Yes but server can indicate in some attribute to the client that it is >> time to start doing this and the client will do the change. >> > Would not be just easiest to steal some code from winbind? It is doing > the same thing for Samba right? I guess it should not be that > different in IPA. > But it is only a wild guess... That might be a way too. We will consider all options when time comes. Ticket was filed. > > Ondrej > > ------------------------------------------------------------------------ > The information contained in this e-mail and in any attachments is > confidential and is designated solely for the attention of the > intended recipient(s). If you are not an intended recipient, you must > not use, disclose, copy, distribute or retain this e-mail or any part > thereof. If you have received this e-mail in error, please notify the > sender by return e-mail and delete all copies of this e-mail from your > computer system(s). Please direct any additional queries to: > communications at s3group.com. Thank You. Silicon and Software Systems > Limited (S3 Group). Registered in Ireland no. 378073. Registered > Office: South County Business Park, Leopardstown, Dublin 18 > ------------------------------------------------------------------------ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Aug 4 16:23:46 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 04 Aug 2011 12:23:46 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E3AB1C5.5040806@redhat.com> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E390B10.5090902@s3group.cz> <4E3957B5.4090703@hkl.hms.harvard.edu> <1312382266.2125.9.camel@sgallagh520.bos.redhat.com> <4E397592.8040406@hkl.hms.harvard.edu> <4E397995.90403@redhat.com> <4E39826C.6070005@hkl.hms.harvard.edu> <4E399382.9000805@redhat.com> <4E39C5E7.8020507@redhat.com> <4E3AB1C5.5040806@redhat.com> Message-ID: <4E3AC792.40100@redhat.com> On 08/04/2011 10:50 AM, Adam Young wrote: > >> DRM is the way to go. However it does not support symmetric keys now. >> This is the pert that we need for volume keys. May be it is the vault >> to store all sorts of keys. This is something that needs to be >> designed and looked at as a broader perspective. >> Adam likes to repeat a phase about dreaming big so I do. I want IPA >> to be a vault for all sorts of keys and passwords and what else. If >> DRM is the answer - great. >> I can start listing the use cases that such a key store should >> satisfy and we can design something that would altimately fit the >> build but build gradually knocking use cases one by one. >> I will take an action idem to come with the use cases. Give me couple >> weeks as I am under water now... > > > Specifically: the phrase is "Dream big, implement small." > > > There are four things here, I'd guess, that should play into the design. > > > 1. User certificates in IPA. Discussed already, and probably the > first thing to implement on the IPA side. > 2. DRM/KRA talking to an external CA. Not sure if this makes sense, > has been discussed etc. > 3. DRM/KRA Integration into IPA. Regardless of 2, we should talk > through the use cases for integration > 4. DRM/KRA Support for symmetric keys etc. Except that use case 4 has a clear demand while 1 is a much bigger undertaking and might require more time thus might be pushed further down the road. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Thu Aug 4 16:31:09 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 04 Aug 2011 12:31:09 -0400 Subject: [Freeipa-users] Is it possible FreeIPA for Web Apps SingleSignOn like CAS? In-Reply-To: References: <4E3AB031.8010209@redhat.com> Message-ID: <4E3AC94D.1060100@redhat.com> On 08/04/2011 11:07 AM, Kiran Patil wrote: >> Which CAS server implementation you are using? >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IPA project, >> Red Hat Inc. >> > Sorry, I picked the subject from one of the earlier thread of FreeIPA user list. > > Right now we are evaluating different solutions. > > We found that FreeIPA project interesting, which provides all in one > solution which is backed by Redhat and community members. > > I have also seen a enhancement request of SAML in FreeIPA > (https://fedorahosted.org/freeipa/ticket/1275). > > I wanted to know, since > RapidNoreapeat(https://www.redhat.com/archives/freeipa-users/2011-July/msg00103.html) > has raised this question earlier, that he is succeeded in implementing > the solution. > There was no follow up on this so what I am specifically interested is how CAS server integrates with external servers. Does it have some sort of pluggable interface like PAM? Even if it does it is probably implementation specific. So is it just a configuration issue to configure the auth sources or auth providers like IPA have to actually build a special provider module? If it is a config issue it might be something that we can try and document as a solution. If it requires development I want to understand what is the cost and benefits. It is unclear how widely CAS is used in general and is there one most popular implementation that we should focus on in future. > Thanks, > Kiran Patil. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ijstokes at hkl.hms.harvard.edu Thu Aug 4 20:05:34 2011 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Thu, 04 Aug 2011 16:05:34 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E39C7F9.8010706@redhat.com> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E3956E6.7090103@hkl.hms.harvard.edu> <4E39C7F9.8010706@redhat.com> Message-ID: <4E3AFB8E.5060405@hkl.hms.harvard.edu> An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Aug 4 20:12:59 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 04 Aug 2011 14:12:59 -0600 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E3AFB8E.5060405@hkl.hms.harvard.edu> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E3956E6.7090103@hkl.hms.harvard.edu> <4E39C7F9.8010706@redhat.com> <4E3AFB8E.5060405@hkl.hms.harvard.edu> Message-ID: <4E3AFD4B.4080408@redhat.com> On 08/04/2011 02:05 PM, Ian Stokes-Rees wrote: > > > On 8/3/11 6:13 PM, Dmitri Pal wrote: >> On 08/03/2011 10:10 AM, Ian Stokes-Rees wrote: >>> If there were some way to securely embed an arbitrary string in the >>> user profile, that would go a long way to solving this problem. At >>> least 4KB to cover a 2048 X.509 public key, but ideally 10 KB or >>> more. To remove the ACL complexity, just having it accessible only by >>> the user (token or password based fetch) would be suitable. >> Do not quite understand how that would work or what you mean. > > I've just realized that I think the functionality I'm looking for is > already available. I want the same system that is used for storing > passwords. Consider the following trace: > > $ ldapsearch -h freeipa -b > uid=tester,cn=users,cn=portal,dc=nebiogrid,dc=org -Y GSSAPI -LLL -d 0 > -T ~/.ldapresults/ > > SASL/GSSAPI authentication started > SASL username: ijstokes at NEBIOGRID.ORG > SASL SSF: 56 > SASL data security layer installed. > dn: uid=tester,cn=users,cn=portal,dc=nebiogrid,dc=org > objectClass: person > objectClass: posixAccount > objectClass: account > objectClass: inetOrgPerson > objectClass: top > objectClass: organizationalPerson > givenName: test > sn: test > cn: test test > mail: meghan at hkl.hms.harvard.edu > uidNumber: 1031 > gidNumber: 1031 > homeDirectory: /p/home//tester > uid: tester > userPassword:: e2NyeXB0fXNCb2drN3p4c2lha1E= > > [aside: I'd love a tip on how to get rid of the non-LDIF SASL headers] > > The userpassword (hash) is stored in base-64 format and is only > accessible by me because I have permissions to access this. Some > other user doing the same query would not get the userPassword > attribute. Even better, I can use the "-tt" option to write the > base64-decoded content to a file. > > The parts of the puzzle that I'd have to work out are: > > 1. are there objectClass schemas that have fields that would be > suitable for a set of common private keys (rsa1, rsa2, dsa, gpg, pgp, > and x509)? x509 schema are included with 389 (05rfc4523.ldif et. al.) I think there is a schema for storage of ssh keys > > 2. if not, instructions on how to set up such a schema (basically with > exactly the set of attributes above), with the fields being base64 > (binary?) Take a look at the existing schema. For most fields that hold opaque blob data, you will probably want to use OctetString syntax. > > 3. what do I have to do to get the behavior that only certain parties > can read a particular attribute? Read up on Access Control (acis): http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Managing_Access_Control > > 4. any way to get ldapsearch to write out particular attributes to > particular files? Not really - all you have is -T and -tt But any non-trivial application is not going to use ldapsearch as the main interface for getting these values. I suggest using python with python-ldap. > > Thanks, > > Ian > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Thu Aug 4 20:42:22 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 4 Aug 2011 20:42:22 +0000 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <4E3A9DAB.30901@redhat.com> References: <4E2EC378.9050401@romal.de>,<4E2EC930.1060501@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E380026.5000707@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E0285@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3A9DAB.30901@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40369E0FE4@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Yes the first is F15. I am halting all the AD machines I will retry without the --force first to test this, when I built IPA originally there was no AD to conflict. However its plain weird because the RHEL6.1 client points to the IPA server for DNS. I will get back to you. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Friday, 5 August 2011 1:24 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] version mismatch while joining a client ? Steven Jones wrote: > Hi, > > I have also done this on a new f15 client and it also fails. > > But its saying, > > 500 and not 401 which is the rhel6.1 failure. > > "HTTP response code is 401, not 200" == RHEL61 > "HTTP response code is 500, not 200" == FED15 Assuming that the Fedora 15 client is 130.195.53.109 that I had seen in a previous log it has a libcurl that does not do ticket delegation. 500 is an HTTP server error, we assume a principal will be there and it isn't and things blow up (this is handled more gracefully in our dev tree). 401 is a HTTP authorization error, the user provide is now allowed to access the server. I'm guessing this is because the client is using the wrong kerberos server. We have this addressed too in the dev tree, we disable dns lookups in krb5.conf. In the meantime --force should make it use the info you provide. rob > > > ============== > more fed15-install-error > [root at fed15-64-ws02 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d > root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz' > , 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw. > ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server' > : None, 'mkhomedir': True, 'unattended': None, 'principal': None} > root : DEBUG missing options might be asked for interactively later > > root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' > root : DEBUG [ipacheckldap] > root : DEBUG args=/usr/bin/wget -O /tmp/tmpsyC9Zx/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > root : DEBUG stdout= > root : DEBUG stderr=--2011-08-03 15:18:07-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 > Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 779 [application/x-x509-ca-cert] > Saving to: ?/tmp/tmpsyC9Zx/ca.crt? > > 0K 100% 111M=0s > > 2011-08-03 15:18:07 (111 MB/s) - ?/tmp/tmpsyC9Zx/ca.crt? saved [779/779] > > > root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 > root : DEBUG Search rootdse > root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) > root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainOb > ject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': [ > 'unix.vuw.ac.nz']})] > root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) > root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vu > w,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hma > c-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScop > e': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special > ', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal' > , 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMax > RenewableAge': ['604800']})] > root : DEBUG will use domain: unix.vuw.ac.nz > > root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz > > Discovery was successful! > root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ > > root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz > > Hostname: fed15-64-ws02.unix.vuw.ac.nz > Realm: UNIX.VUW.AC.NZ > DNS Domain: unix.vuw.ac.nz > IPA Server: vuwunicoipamt01.unix.vuw.ac.nz > BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz > > > Continue to configure the system with these values? [no]: yes > Enrollment principal: admin > root : DEBUG will use principal: admin > > root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > root : DEBUG stdout= > root : DEBUG stderr=--2011-08-03 15:18:12-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 > Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 779 [application/x-x509-ca-cert] > Saving to: ?/etc/ipa/ca.crt? > > 0K 100% 112M=0s > > 2011-08-03 15:18:12 (112 MB/s) - ?/etc/ipa/ca.crt? saved [779/779] > > > root : DEBUG Writing Kerberos configuration to /tmp/tmpiFqnW9: > #File modified by ipa-client-install > > [libdefaults] > default_realm = UNIX.VUW.AC.NZ > dns_lookup_realm = true > dns_lookup_kdc = true > rdns = false > ticket_lifetime = 24h > forwardable = yes > > [realms] > UNIX.VUW.AC.NZ = { > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > [domain_realm] > .unix.vuw.ac.nz = UNIX.VUW.AC.NZ > unix.vuw.ac.nz = UNIX.VUW.AC.NZ > > [appdefaults] > pam = { > debug = false > ticket_lifetime = 36000 > renew_lifetime = 36000 > forwardable = true > krb4_convert = false > } > > Password for admin at UNIX.VUW.AC.NZ: > root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ > root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: > > root : DEBUG stderr= > > root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d > root : DEBUG stdout= > root : DEBUG stderr=XML-RPC CALL: > > \r\n > \r\n > join\r\n > \r\n > \r\n > fed15-64-ws02.unix.vuw.ac.nz\r\n > \r\n > \r\n > nsosversion\r\n > 2.6.38.6-26.rc1.fc15.x86_64\r\n > nshardwareplatform\r\n > x86_64\r\n > \r\n > \r\n > \r\n > > HTTP response code is 500, not 200 > > Joining realm failed because of failing XML-RPC request. > This error may be caused by incompatible server/client major versions. > root : DEBUG args=kdestroy > root : DEBUG stdout= > root : DEBUG stderr= > [root at fed15-64-ws02 ~]# > ======================= > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] > Sent: Wednesday, 3 August 2011 9:35 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Hi, > > Client > ========== > rhel61-64cl04.unix.vuw.ac.nz > Linux rhel61-64cl04.unix.vuw.ac.nz 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux > ipa-client-2.0.0-23.el6_1.1.x86_64 > libcurl-7.19.7-26.el6.x86_64 > Red Hat Enterprise Linux Client release 6.1 (Santiago) > ========== > > Server > ========== > Linux vuwunicoipamt01 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux > libcurl-7.19.7-26.el6_1.1.x86_64 > ipa-client-2.0.0-23.el6_1.1.x86_64 > ipa-server-2.0.0-23.el6_1.1.x86_64 > Red Hat Enterprise Linux Server release 6.1 (Santiago) > ========== > > install output > ========== > [root at rhel61-64cl04 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d > root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz', 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw.ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server': None, 'mkhomedir': True, 'unattended': None, 'principal': None} > root : DEBUG missing options might be asked for interactively later > > root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' > root : DEBUG [ipacheckldap] > root : DEBUG args=/usr/bin/wget -O /tmp/tmpaaTaqF/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > root : DEBUG stdout= > root : DEBUG stderr=--2011-08-03 09:01:14-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 > Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 779 [application/x-x509-ca-cert] > Saving to: `/tmp/tmpaaTaqF/ca.crt' > > 0K 100% 132M=0s > > 2011-08-03 09:01:14 (132 MB/s) - `/tmp/tmpaaTaqF/ca.crt' saved [779/779] > > > root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 > root : DEBUG Search rootdse > root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) > root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': ['unix.vuw.ac.nz']})] > root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) > root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vuw,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})] > root : DEBUG will use domain: unix.vuw.ac.nz > > root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz > > Discovery was successful! > root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ > > root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz > > Hostname: rhel61-64cl04.unix.vuw.ac.nz > Realm: UNIX.VUW.AC.NZ > DNS Domain: unix.vuw.ac.nz > IPA Server: vuwunicoipamt01.unix.vuw.ac.nz > BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz > > > Continue to configure the system with these values? [no]: yes > Enrollment principal: admin > root : DEBUG will use principal: admin > > root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > root : DEBUG stdout= > root : DEBUG stderr=--2011-08-03 09:01:22-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 > Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 779 [application/x-x509-ca-cert] > Saving to: `/etc/ipa/ca.crt' > > 0K 100% 96.5M=0s > > 2011-08-03 09:01:22 (96.5 MB/s) - `/etc/ipa/ca.crt' saved [779/779] > > > Password for admin at UNIX.VUW.AC.NZ: > root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ > root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: > > root : DEBUG stderr= > > root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d > root : DEBUG stdout= > root : DEBUG stderr=XML-RPC CALL: > > \r\n > \r\n > join\r\n > \r\n > \r\n > rhel61-64cl04.unix.vuw.ac.nz\r\n > \r\n > \r\n > nsosversion\r\n > 2.6.32-131.6.1.el6.x86_64\r\n > nshardwareplatform\r\n > x86_64\r\n > \r\n > \r\n > \r\n > > HTTP response code is 401, not 200 > > Joining realm failed because of failing XML-RPC request. > This error may be caused by incompatible server/client major versions. > root : DEBUG args=kdestroy > root : DEBUG stdout= > root : DEBUG stderr= > [root at rhel61-64cl04 ~]# > ========== > > Error log > ========== > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [notice] caught SIGTERM, shutting down > [Wed Aug 03 09:04:58 2011] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 > [Wed Aug 03 09:04:58 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > [Wed Aug 03 09:04:58 2011] [notice] Digest: generating secret for digest authentication ... > [Wed Aug 03 09:04:58 2011] [notice] Digest: done > [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Compiled for Python/2.6.2. > [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Runtime using Python/2.6.6. > [Wed Aug 03 09:04:59 2011] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations > [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** > [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** > ========== > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Wednesday, 3 August 2011 1:48 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Steven Jones wrote: >> >> Yes....enrolement now fails, previous messages I attached show that I think, it used to work. >> >> History, I had to remove all my working IPA clients due to a disk space problem on our SAN (we didnt have any). So I managed to keep the working IPA server and 2 x RHEL5 64 bit servers and the one un-configured template of RHEL6.1 64bit client I had. This I used to make client side clones off previously and connected them to IPA server and they worked. >> >> So lastweek I went back and with a running ipa server, I cloned in the old client/template and got the mis-match, so I put them on the production network and patched, same mismatch problem. >> >> I can do a sosreport of the old template I think and the client to look at the differences if that helps. > > I'm having a hard time following exactly what you are doing, on what > machine. I think we need to be more systematic. > > Can you choose a machine to act as the client and provide the following: > > - distro and architecture (e.g. RHEL 6.1 on x86_64) > - rpm -q curl libcurl > - rpm -q ipa-client > > On the IPA server: > - rpm -q ipa-server > > Start with a client that is not enrolled. If it has previously been > enrolled run: ipa-client-install --uninstall -U > > Now run ipa-client-install and answer the questions as appropriate for > your install. > > If it fails please provide the following: > - any stdout you get from the client install > - attach the full /var/log/ipaclient-install.log > - attach the last 100 lines from /var/log/httpd/error_log from the IPA > server > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Thu Aug 4 21:44:38 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 04 Aug 2011 17:44:38 -0400 Subject: [Freeipa-users] Use of FreeIPA or FreeIPA LDAP server to hold private keys In-Reply-To: <4E3AFD4B.4080408@redhat.com> References: <4E383ED7.1030506@hkl.hms.harvard.edu> <4E385D9B.8010207@redhat.com> <4E387170.5010804@hkl.hms.harvard.edu> <4E38839F.7030608@redhat.com> <4E3956E6.7090103@hkl.hms.harvard.edu> <4E39C7F9.8010706@redhat.com> <4E3AFB8E.5060405@hkl.hms.harvard.edu> <4E3AFD4B.4080408@redhat.com> Message-ID: <4E3B12C6.9070808@redhat.com> On 08/04/2011 04:12 PM, Rich Megginson wrote: > On 08/04/2011 02:05 PM, Ian Stokes-Rees wrote: >> >> >> On 8/3/11 6:13 PM, Dmitri Pal wrote: >>> On 08/03/2011 10:10 AM, Ian Stokes-Rees wrote: >>>> If there were some way to securely embed an arbitrary string in the >>>> user profile, that would go a long way to solving this problem. At >>>> least 4KB to cover a 2048 X.509 public key, but ideally 10 KB or >>>> more. To remove the ACL complexity, just having it accessible only by >>>> the user (token or password based fetch) would be suitable. >>> Do not quite understand how that would work or what you mean. >> >> I've just realized that I think the functionality I'm looking for is >> already available. I want the same system that is used for storing >> passwords. Consider the following trace: >> >> $ ldapsearch -h freeipa -b >> uid=tester,cn=users,cn=portal,dc=nebiogrid,dc=org -Y GSSAPI -LLL -d 0 >> -T ~/.ldapresults/ >> >> SASL/GSSAPI authentication started >> SASL username: ijstokes at NEBIOGRID.ORG >> SASL SSF: 56 >> SASL data security layer installed. >> dn: uid=tester,cn=users,cn=portal,dc=nebiogrid,dc=org >> objectClass: person >> objectClass: posixAccount >> objectClass: account >> objectClass: inetOrgPerson >> objectClass: top >> objectClass: organizationalPerson >> givenName: test >> sn: test >> cn: test test >> mail: meghan at hkl.hms.harvard.edu >> uidNumber: 1031 >> gidNumber: 1031 >> homeDirectory: /p/home//tester >> uid: tester >> userPassword:: e2NyeXB0fXNCb2drN3p4c2lha1E= >> >> [aside: I'd love a tip on how to get rid of the non-LDIF SASL headers] >> >> The userpassword (hash) is stored in base-64 format and is only >> accessible by me because I have permissions to access this. Some >> other user doing the same query would not get the userPassword >> attribute. Even better, I can use the "-tt" option to write the >> base64-decoded content to a file. >> >> The parts of the puzzle that I'd have to work out are: >> >> 1. are there objectClass schemas that have fields that would be >> suitable for a set of common private keys (rsa1, rsa2, dsa, gpg, pgp, >> and x509)? > x509 schema are included with 389 (05rfc4523.ldif et. al.) > I think there is a schema for storage of ssh keys Take a look at this: https://fedorahosted.org/freeipa/ticket/754 http://code.google.com/p/openssh-lpk/ Patches are welcome ;-) >> >> 2. if not, instructions on how to set up such a schema (basically >> with exactly the set of attributes above), with the fields being >> base64 (binary?) > Take a look at the existing schema. For most fields that hold opaque > blob data, you will probably want to use OctetString syntax. >> >> 3. what do I have to do to get the behavior that only certain parties >> can read a particular attribute? > Read up on Access Control (acis): > http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Managing_Access_Control >> >> 4. any way to get ldapsearch to write out particular attributes to >> particular files? > Not really - all you have is -T and -tt > But any non-trivial application is not going to use ldapsearch as the > main interface for getting these values. I suggest using python with > python-ldap. >> >> Thanks, >> >> Ian >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Thu Aug 4 21:58:12 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 4 Aug 2011 21:58:12 +0000 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40369E0FE4@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <4E2EC378.9050401@romal.de>,<4E2EC930.1060501@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E380026.5000707@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E0285@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3A9DAB.30901@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369E0FE4@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <833D8E48405E064EBC54C84EC6B36E40369E1007@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Trying with two rhel61-64bit-clones "04" and "05".... They should give the same failures? but are not?......confused, 04 (the first clone has 1/2 joined as its in IPA, but it doesnt say "enrolled and a date", 05 failed totally. I know Im short on sleep but I really don't understand what's going on here and why its so hard to make basic stuff work. :/ I have included the logs off each, logs off the IPA server and out's from the attempt to join. from each guest. Anything else needed? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Friday, 5 August 2011 8:42 a.m. To: Rob Crittenden Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] version mismatch while joining a client ? Hi, Yes the first is F15. I am halting all the AD machines I will retry without the --force first to test this, when I built IPA originally there was no AD to conflict. However its plain weird because the RHEL6.1 client points to the IPA server for DNS. I will get back to you. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Friday, 5 August 2011 1:24 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] version mismatch while joining a client ? Steven Jones wrote: > Hi, > > I have also done this on a new f15 client and it also fails. > > But its saying, > > 500 and not 401 which is the rhel6.1 failure. > > "HTTP response code is 401, not 200" == RHEL61 > "HTTP response code is 500, not 200" == FED15 Assuming that the Fedora 15 client is 130.195.53.109 that I had seen in a previous log it has a libcurl that does not do ticket delegation. 500 is an HTTP server error, we assume a principal will be there and it isn't and things blow up (this is handled more gracefully in our dev tree). 401 is a HTTP authorization error, the user provide is now allowed to access the server. I'm guessing this is because the client is using the wrong kerberos server. We have this addressed too in the dev tree, we disable dns lookups in krb5.conf. In the meantime --force should make it use the info you provide. rob > > > ============== > more fed15-install-error > [root at fed15-64-ws02 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d > root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz' > , 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw. > ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server' > : None, 'mkhomedir': True, 'unattended': None, 'principal': None} > root : DEBUG missing options might be asked for interactively later > > root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' > root : DEBUG [ipacheckldap] > root : DEBUG args=/usr/bin/wget -O /tmp/tmpsyC9Zx/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > root : DEBUG stdout= > root : DEBUG stderr=--2011-08-03 15:18:07-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 > Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 779 [application/x-x509-ca-cert] > Saving to: ?/tmp/tmpsyC9Zx/ca.crt? > > 0K 100% 111M=0s > > 2011-08-03 15:18:07 (111 MB/s) - ?/tmp/tmpsyC9Zx/ca.crt? saved [779/779] > > > root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 > root : DEBUG Search rootdse > root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) > root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainOb > ject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': [ > 'unix.vuw.ac.nz']})] > root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) > root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vu > w,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hma > c-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScop > e': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special > ', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal' > , 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMax > RenewableAge': ['604800']})] > root : DEBUG will use domain: unix.vuw.ac.nz > > root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz > > Discovery was successful! > root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ > > root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz > > Hostname: fed15-64-ws02.unix.vuw.ac.nz > Realm: UNIX.VUW.AC.NZ > DNS Domain: unix.vuw.ac.nz > IPA Server: vuwunicoipamt01.unix.vuw.ac.nz > BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz > > > Continue to configure the system with these values? [no]: yes > Enrollment principal: admin > root : DEBUG will use principal: admin > > root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > root : DEBUG stdout= > root : DEBUG stderr=--2011-08-03 15:18:12-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 > Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 779 [application/x-x509-ca-cert] > Saving to: ?/etc/ipa/ca.crt? > > 0K 100% 112M=0s > > 2011-08-03 15:18:12 (112 MB/s) - ?/etc/ipa/ca.crt? saved [779/779] > > > root : DEBUG Writing Kerberos configuration to /tmp/tmpiFqnW9: > #File modified by ipa-client-install > > [libdefaults] > default_realm = UNIX.VUW.AC.NZ > dns_lookup_realm = true > dns_lookup_kdc = true > rdns = false > ticket_lifetime = 24h > forwardable = yes > > [realms] > UNIX.VUW.AC.NZ = { > pkinit_anchors = FILE:/etc/ipa/ca.crt > } > > [domain_realm] > .unix.vuw.ac.nz = UNIX.VUW.AC.NZ > unix.vuw.ac.nz = UNIX.VUW.AC.NZ > > [appdefaults] > pam = { > debug = false > ticket_lifetime = 36000 > renew_lifetime = 36000 > forwardable = true > krb4_convert = false > } > > Password for admin at UNIX.VUW.AC.NZ: > root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ > root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: > > root : DEBUG stderr= > > root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d > root : DEBUG stdout= > root : DEBUG stderr=XML-RPC CALL: > > \r\n > \r\n > join\r\n > \r\n > \r\n > fed15-64-ws02.unix.vuw.ac.nz\r\n > \r\n > \r\n > nsosversion\r\n > 2.6.38.6-26.rc1.fc15.x86_64\r\n > nshardwareplatform\r\n > x86_64\r\n > \r\n > \r\n > \r\n > > HTTP response code is 500, not 200 > > Joining realm failed because of failing XML-RPC request. > This error may be caused by incompatible server/client major versions. > root : DEBUG args=kdestroy > root : DEBUG stdout= > root : DEBUG stderr= > [root at fed15-64-ws02 ~]# > ======================= > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] > Sent: Wednesday, 3 August 2011 9:35 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Hi, > > Client > ========== > rhel61-64cl04.unix.vuw.ac.nz > Linux rhel61-64cl04.unix.vuw.ac.nz 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux > ipa-client-2.0.0-23.el6_1.1.x86_64 > libcurl-7.19.7-26.el6.x86_64 > Red Hat Enterprise Linux Client release 6.1 (Santiago) > ========== > > Server > ========== > Linux vuwunicoipamt01 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux > libcurl-7.19.7-26.el6_1.1.x86_64 > ipa-client-2.0.0-23.el6_1.1.x86_64 > ipa-server-2.0.0-23.el6_1.1.x86_64 > Red Hat Enterprise Linux Server release 6.1 (Santiago) > ========== > > install output > ========== > [root at rhel61-64cl04 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d > root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz', 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw.ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server': None, 'mkhomedir': True, 'unattended': None, 'principal': None} > root : DEBUG missing options might be asked for interactively later > > root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' > root : DEBUG [ipacheckldap] > root : DEBUG args=/usr/bin/wget -O /tmp/tmpaaTaqF/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > root : DEBUG stdout= > root : DEBUG stderr=--2011-08-03 09:01:14-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 > Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 779 [application/x-x509-ca-cert] > Saving to: `/tmp/tmpaaTaqF/ca.crt' > > 0K 100% 132M=0s > > 2011-08-03 09:01:14 (132 MB/s) - `/tmp/tmpaaTaqF/ca.crt' saved [779/779] > > > root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 > root : DEBUG Search rootdse > root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) > root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': ['unix.vuw.ac.nz']})] > root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) > root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vuw,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})] > root : DEBUG will use domain: unix.vuw.ac.nz > > root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz > > Discovery was successful! > root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ > > root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz > > Hostname: rhel61-64cl04.unix.vuw.ac.nz > Realm: UNIX.VUW.AC.NZ > DNS Domain: unix.vuw.ac.nz > IPA Server: vuwunicoipamt01.unix.vuw.ac.nz > BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz > > > Continue to configure the system with these values? [no]: yes > Enrollment principal: admin > root : DEBUG will use principal: admin > > root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > root : DEBUG stdout= > root : DEBUG stderr=--2011-08-03 09:01:22-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt > Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 > Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 779 [application/x-x509-ca-cert] > Saving to: `/etc/ipa/ca.crt' > > 0K 100% 96.5M=0s > > 2011-08-03 09:01:22 (96.5 MB/s) - `/etc/ipa/ca.crt' saved [779/779] > > > Password for admin at UNIX.VUW.AC.NZ: > root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ > root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: > > root : DEBUG stderr= > > root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d > root : DEBUG stdout= > root : DEBUG stderr=XML-RPC CALL: > > \r\n > \r\n > join\r\n > \r\n > \r\n > rhel61-64cl04.unix.vuw.ac.nz\r\n > \r\n > \r\n > nsosversion\r\n > 2.6.32-131.6.1.el6.x86_64\r\n > nshardwareplatform\r\n > x86_64\r\n > \r\n > \r\n > \r\n > > HTTP response code is 401, not 200 > > Joining realm failed because of failing XML-RPC request. > This error may be caused by incompatible server/client major versions. > root : DEBUG args=kdestroy > root : DEBUG stdout= > root : DEBUG stderr= > [root at rhel61-64cl04 ~]# > ========== > > Error log > ========== > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored > [Wed Aug 03 09:04:57 2011] [notice] caught SIGTERM, shutting down > [Wed Aug 03 09:04:58 2011] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 > [Wed Aug 03 09:04:58 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) > [Wed Aug 03 09:04:58 2011] [notice] Digest: generating secret for digest authentication ... > [Wed Aug 03 09:04:58 2011] [notice] Digest: done > [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Compiled for Python/2.6.2. > [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Runtime using Python/2.6.6. > [Wed Aug 03 09:04:59 2011] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations > [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** > [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** > ========== > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Wednesday, 3 August 2011 1:48 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Steven Jones wrote: >> >> Yes....enrolement now fails, previous messages I attached show that I think, it used to work. >> >> History, I had to remove all my working IPA clients due to a disk space problem on our SAN (we didnt have any). So I managed to keep the working IPA server and 2 x RHEL5 64 bit servers and the one un-configured template of RHEL6.1 64bit client I had. This I used to make client side clones off previously and connected them to IPA server and they worked. >> >> So lastweek I went back and with a running ipa server, I cloned in the old client/template and got the mis-match, so I put them on the production network and patched, same mismatch problem. >> >> I can do a sosreport of the old template I think and the client to look at the differences if that helps. > > I'm having a hard time following exactly what you are doing, on what > machine. I think we need to be more systematic. > > Can you choose a machine to act as the client and provide the following: > > - distro and architecture (e.g. RHEL 6.1 on x86_64) > - rpm -q curl libcurl > - rpm -q ipa-client > > On the IPA server: > - rpm -q ipa-server > > Start with a client that is not enrolled. If it has previously been > enrolled run: ipa-client-install --uninstall -U > > Now run ipa-client-install and answer the questions as appropriate for > your install. > > If it fails please provide the following: > - any stdout you get from the client install > - attach the full /var/log/ipaclient-install.log > - attach the last 100 lines from /var/log/httpd/error_log from the IPA > server > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- A non-text attachment was scrubbed... Name: cl04-ipaclient-install.log Type: application/octet-stream Size: 6673 bytes Desc: cl04-ipaclient-install.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cl05-ipaclient-install.log Type: application/octet-stream Size: 9807 bytes Desc: cl05-ipaclient-install.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: access_log Type: application/octet-stream Size: 15547 bytes Desc: access_log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: error_log Type: application/octet-stream Size: 41106 bytes Desc: error_log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rhel61-cl04.out Type: application/octet-stream Size: 15250 bytes Desc: rhel61-cl04.out URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rhel61-cl05.out Type: application/octet-stream Size: 10415 bytes Desc: rhel61-cl05.out URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: krb5kdc.log Type: application/octet-stream Size: 86133 bytes Desc: krb5kdc.log URL: From rcritten at redhat.com Thu Aug 4 22:11:23 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 04 Aug 2011 18:11:23 -0400 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40369E1007@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <4E2EC378.9050401@romal.de>, <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E380026.5000707@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E0285@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3A9DAB.30901@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369E0FE4@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E1007@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4E3B190B.9050502@redhat.com> Steven Jones wrote: > Hi, > > Trying with two rhel61-64bit-clones "04" and "05".... > > They should give the same failures? but are not?......confused, 04 (the first clone has 1/2 joined as its in IPA, but it doesnt say "enrolled and a date", 05 failed totally. 04 is failing because it apparently still has an updated libcurl. It is getting a 500 error back. The installation continues because you had the --force flag. This means it proceeds on errors, so it tried to set things up but since it didn't get a keytab sssd can't authenticate. 05 actually enrolled successfully but was unable to retrieve a keytab. You can try running ipa-getkeytab from the command-line again. To do this you'll need to copy a krb5.conf from a working system (say the IPA server. # kinit admin # ipa-getkeytab -s vuwunicoipamt01.unix.vuw.ac.nz -k /etc/krb5.keytab -p host/rhel61-64cl04.unix.vuw.ac.nz at UNIX.VUW.AC.NZ You may also want to look at the krb5kdc.log and the 389-ds access log, they may hold clues as well. > > I know Im short on sleep but I really don't understand what's going on here and why its so hard to make basic stuff work. > > :/ > > I have included the logs off each, logs off the IPA server and out's from the attempt to join. from each guest. Anything else needed? > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] > Sent: Friday, 5 August 2011 8:42 a.m. > To: Rob Crittenden > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Hi, > > Yes the first is F15. > > I am halting all the AD machines I will retry without the --force first to test this, when I built IPA originally there was no AD to conflict. > > However its plain weird because the RHEL6.1 client points to the IPA server for DNS. > > I will get back to you. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Friday, 5 August 2011 1:24 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Steven Jones wrote: >> Hi, >> >> I have also done this on a new f15 client and it also fails. >> >> But its saying, >> >> 500 and not 401 which is the rhel6.1 failure. >> >> "HTTP response code is 401, not 200" == RHEL61 >> "HTTP response code is 500, not 200" == FED15 > > Assuming that the Fedora 15 client is 130.195.53.109 that I had seen in > a previous log it has a libcurl that does not do ticket delegation. > > 500 is an HTTP server error, we assume a principal will be there and it > isn't and things blow up (this is handled more gracefully in our dev tree). > > 401 is a HTTP authorization error, the user provide is now allowed to > access the server. I'm guessing this is because the client is using the > wrong kerberos server. We have this addressed too in the dev tree, we > disable dns lookups in krb5.conf. In the meantime --force should make it > use the info you provide. > > rob > > >> >> >> ============== >> more fed15-install-error >> [root at fed15-64-ws02 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d >> root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz' >> , 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw. >> ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server' >> : None, 'mkhomedir': True, 'unattended': None, 'principal': None} >> root : DEBUG missing options might be asked for interactively later >> >> root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' >> root : DEBUG [ipacheckldap] >> root : DEBUG args=/usr/bin/wget -O /tmp/tmpsyC9Zx/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> root : DEBUG stdout= >> root : DEBUG stderr=--2011-08-03 15:18:07-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 779 [application/x-x509-ca-cert] >> Saving to: ?/tmp/tmpsyC9Zx/ca.crt? >> >> 0K 100% 111M=0s >> >> 2011-08-03 15:18:07 (111 MB/s) - ?/tmp/tmpsyC9Zx/ca.crt? saved [779/779] >> >> >> root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 >> root : DEBUG Search rootdse >> root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) >> root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainOb >> ject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': [ >> 'unix.vuw.ac.nz']})] >> root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) >> root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vu >> w,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hma >> c-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScop >> e': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special >> ', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal' >> , 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMax >> RenewableAge': ['604800']})] >> root : DEBUG will use domain: unix.vuw.ac.nz >> >> root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz >> >> Discovery was successful! >> root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ >> >> root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz >> >> Hostname: fed15-64-ws02.unix.vuw.ac.nz >> Realm: UNIX.VUW.AC.NZ >> DNS Domain: unix.vuw.ac.nz >> IPA Server: vuwunicoipamt01.unix.vuw.ac.nz >> BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz >> >> >> Continue to configure the system with these values? [no]: yes >> Enrollment principal: admin >> root : DEBUG will use principal: admin >> >> root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> root : DEBUG stdout= >> root : DEBUG stderr=--2011-08-03 15:18:12-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 779 [application/x-x509-ca-cert] >> Saving to: ?/etc/ipa/ca.crt? >> >> 0K 100% 112M=0s >> >> 2011-08-03 15:18:12 (112 MB/s) - ?/etc/ipa/ca.crt? saved [779/779] >> >> >> root : DEBUG Writing Kerberos configuration to /tmp/tmpiFqnW9: >> #File modified by ipa-client-install >> >> [libdefaults] >> default_realm = UNIX.VUW.AC.NZ >> dns_lookup_realm = true >> dns_lookup_kdc = true >> rdns = false >> ticket_lifetime = 24h >> forwardable = yes >> >> [realms] >> UNIX.VUW.AC.NZ = { >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> } >> >> [domain_realm] >> .unix.vuw.ac.nz = UNIX.VUW.AC.NZ >> unix.vuw.ac.nz = UNIX.VUW.AC.NZ >> >> [appdefaults] >> pam = { >> debug = false >> ticket_lifetime = 36000 >> renew_lifetime = 36000 >> forwardable = true >> krb4_convert = false >> } >> >> Password for admin at UNIX.VUW.AC.NZ: >> root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ >> root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: >> >> root : DEBUG stderr= >> >> root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d >> root : DEBUG stdout= >> root : DEBUG stderr=XML-RPC CALL: >> >> \r\n >> \r\n >> join\r\n >> \r\n >> \r\n >> fed15-64-ws02.unix.vuw.ac.nz\r\n >> \r\n >> \r\n >> nsosversion\r\n >> 2.6.38.6-26.rc1.fc15.x86_64\r\n >> nshardwareplatform\r\n >> x86_64\r\n >> \r\n >> \r\n >> \r\n >> >> HTTP response code is 500, not 200 >> >> Joining realm failed because of failing XML-RPC request. >> This error may be caused by incompatible server/client major versions. >> root : DEBUG args=kdestroy >> root : DEBUG stdout= >> root : DEBUG stderr= >> [root at fed15-64-ws02 ~]# >> ======================= >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] >> Sent: Wednesday, 3 August 2011 9:35 a.m. >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >> >> Hi, >> >> Client >> ========== >> rhel61-64cl04.unix.vuw.ac.nz >> Linux rhel61-64cl04.unix.vuw.ac.nz 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux >> ipa-client-2.0.0-23.el6_1.1.x86_64 >> libcurl-7.19.7-26.el6.x86_64 >> Red Hat Enterprise Linux Client release 6.1 (Santiago) >> ========== >> >> Server >> ========== >> Linux vuwunicoipamt01 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux >> libcurl-7.19.7-26.el6_1.1.x86_64 >> ipa-client-2.0.0-23.el6_1.1.x86_64 >> ipa-server-2.0.0-23.el6_1.1.x86_64 >> Red Hat Enterprise Linux Server release 6.1 (Santiago) >> ========== >> >> install output >> ========== >> [root at rhel61-64cl04 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d >> root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz', 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw.ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server': None, 'mkhomedir': True, 'unattended': None, 'principal': None} >> root : DEBUG missing options might be asked for interactively later >> >> root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' >> root : DEBUG [ipacheckldap] >> root : DEBUG args=/usr/bin/wget -O /tmp/tmpaaTaqF/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> root : DEBUG stdout= >> root : DEBUG stderr=--2011-08-03 09:01:14-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 779 [application/x-x509-ca-cert] >> Saving to: `/tmp/tmpaaTaqF/ca.crt' >> >> 0K 100% 132M=0s >> >> 2011-08-03 09:01:14 (132 MB/s) - `/tmp/tmpaaTaqF/ca.crt' saved [779/779] >> >> >> root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 >> root : DEBUG Search rootdse >> root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) >> root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': ['unix.vuw.ac.nz']})] >> root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) >> root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vuw,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})] >> root : DEBUG will use domain: unix.vuw.ac.nz >> >> root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz >> >> Discovery was successful! >> root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ >> >> root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz >> >> Hostname: rhel61-64cl04.unix.vuw.ac.nz >> Realm: UNIX.VUW.AC.NZ >> DNS Domain: unix.vuw.ac.nz >> IPA Server: vuwunicoipamt01.unix.vuw.ac.nz >> BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz >> >> >> Continue to configure the system with these values? [no]: yes >> Enrollment principal: admin >> root : DEBUG will use principal: admin >> >> root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> root : DEBUG stdout= >> root : DEBUG stderr=--2011-08-03 09:01:22-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 779 [application/x-x509-ca-cert] >> Saving to: `/etc/ipa/ca.crt' >> >> 0K 100% 96.5M=0s >> >> 2011-08-03 09:01:22 (96.5 MB/s) - `/etc/ipa/ca.crt' saved [779/779] >> >> >> Password for admin at UNIX.VUW.AC.NZ: >> root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ >> root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: >> >> root : DEBUG stderr= >> >> root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d >> root : DEBUG stdout= >> root : DEBUG stderr=XML-RPC CALL: >> >> \r\n >> \r\n >> join\r\n >> \r\n >> \r\n >> rhel61-64cl04.unix.vuw.ac.nz\r\n >> \r\n >> \r\n >> nsosversion\r\n >> 2.6.32-131.6.1.el6.x86_64\r\n >> nshardwareplatform\r\n >> x86_64\r\n >> \r\n >> \r\n >> \r\n >> >> HTTP response code is 401, not 200 >> >> Joining realm failed because of failing XML-RPC request. >> This error may be caused by incompatible server/client major versions. >> root : DEBUG args=kdestroy >> root : DEBUG stdout= >> root : DEBUG stderr= >> [root at rhel61-64cl04 ~]# >> ========== >> >> Error log >> ========== >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [notice] caught SIGTERM, shutting down >> [Wed Aug 03 09:04:58 2011] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 >> [Wed Aug 03 09:04:58 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >> [Wed Aug 03 09:04:58 2011] [notice] Digest: generating secret for digest authentication ... >> [Wed Aug 03 09:04:58 2011] [notice] Digest: done >> [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Compiled for Python/2.6.2. >> [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Runtime using Python/2.6.6. >> [Wed Aug 03 09:04:59 2011] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations >> [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** >> [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** >> ========== >> >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Rob Crittenden [rcritten at redhat.com] >> Sent: Wednesday, 3 August 2011 1:48 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >> >> Steven Jones wrote: >>> >>> Yes....enrolement now fails, previous messages I attached show that I think, it used to work. >>> >>> History, I had to remove all my working IPA clients due to a disk space problem on our SAN (we didnt have any). So I managed to keep the working IPA server and 2 x RHEL5 64 bit servers and the one un-configured template of RHEL6.1 64bit client I had. This I used to make client side clones off previously and connected them to IPA server and they worked. >>> >>> So lastweek I went back and with a running ipa server, I cloned in the old client/template and got the mis-match, so I put them on the production network and patched, same mismatch problem. >>> >>> I can do a sosreport of the old template I think and the client to look at the differences if that helps. >> >> I'm having a hard time following exactly what you are doing, on what >> machine. I think we need to be more systematic. >> >> Can you choose a machine to act as the client and provide the following: >> >> - distro and architecture (e.g. RHEL 6.1 on x86_64) >> - rpm -q curl libcurl >> - rpm -q ipa-client >> >> On the IPA server: >> - rpm -q ipa-server >> >> Start with a client that is not enrolled. If it has previously been >> enrolled run: ipa-client-install --uninstall -U >> >> Now run ipa-client-install and answer the questions as appropriate for >> your install. >> >> If it fails please provide the following: >> - any stdout you get from the client install >> - attach the full /var/log/ipaclient-install.log >> - attach the last 100 lines from /var/log/httpd/error_log from the IPA >> server >> >> rob >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From Steven.Jones at vuw.ac.nz Thu Aug 4 22:24:01 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 4 Aug 2011 22:24:01 +0000 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <4E3B190B.9050502@redhat.com> References: <4E2EC378.9050401@romal.de>, <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E380026.5000707@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E0285@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3A9DAB.30901@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369E0FE4@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E1007@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3B190B.9050502@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40369E1085@STAWINCOX10MBX1.staff.vuw.ac.nz> I already included the krb5kdc log regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Friday, 5 August 2011 10:11 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] version mismatch while joining a client ? Steven Jones wrote: > Hi, > > Trying with two rhel61-64bit-clones "04" and "05".... > > They should give the same failures? but are not?......confused, 04 (the first clone has 1/2 joined as its in IPA, but it doesnt say "enrolled and a date", 05 failed totally. 04 is failing because it apparently still has an updated libcurl. It is getting a 500 error back. The installation continues because you had the --force flag. This means it proceeds on errors, so it tried to set things up but since it didn't get a keytab sssd can't authenticate. 05 actually enrolled successfully but was unable to retrieve a keytab. You can try running ipa-getkeytab from the command-line again. To do this you'll need to copy a krb5.conf from a working system (say the IPA server. # kinit admin # ipa-getkeytab -s vuwunicoipamt01.unix.vuw.ac.nz -k /etc/krb5.keytab -p host/rhel61-64cl04.unix.vuw.ac.nz at UNIX.VUW.AC.NZ You may also want to look at the krb5kdc.log and the 389-ds access log, they may hold clues as well. > > I know Im short on sleep but I really don't understand what's going on here and why its so hard to make basic stuff work. > > :/ > > I have included the logs off each, logs off the IPA server and out's from the attempt to join. from each guest. Anything else needed? > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] > Sent: Friday, 5 August 2011 8:42 a.m. > To: Rob Crittenden > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Hi, > > Yes the first is F15. > > I am halting all the AD machines I will retry without the --force first to test this, when I built IPA originally there was no AD to conflict. > > However its plain weird because the RHEL6.1 client points to the IPA server for DNS. > > I will get back to you. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Friday, 5 August 2011 1:24 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Steven Jones wrote: >> Hi, >> >> I have also done this on a new f15 client and it also fails. >> >> But its saying, >> >> 500 and not 401 which is the rhel6.1 failure. >> >> "HTTP response code is 401, not 200" == RHEL61 >> "HTTP response code is 500, not 200" == FED15 > > Assuming that the Fedora 15 client is 130.195.53.109 that I had seen in > a previous log it has a libcurl that does not do ticket delegation. > > 500 is an HTTP server error, we assume a principal will be there and it > isn't and things blow up (this is handled more gracefully in our dev tree). > > 401 is a HTTP authorization error, the user provide is now allowed to > access the server. I'm guessing this is because the client is using the > wrong kerberos server. We have this addressed too in the dev tree, we > disable dns lookups in krb5.conf. In the meantime --force should make it > use the info you provide. > > rob > > >> >> >> ============== >> more fed15-install-error >> [root at fed15-64-ws02 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d >> root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz' >> , 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw. >> ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server' >> : None, 'mkhomedir': True, 'unattended': None, 'principal': None} >> root : DEBUG missing options might be asked for interactively later >> >> root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' >> root : DEBUG [ipacheckldap] >> root : DEBUG args=/usr/bin/wget -O /tmp/tmpsyC9Zx/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> root : DEBUG stdout= >> root : DEBUG stderr=--2011-08-03 15:18:07-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 779 [application/x-x509-ca-cert] >> Saving to: ?/tmp/tmpsyC9Zx/ca.crt? >> >> 0K 100% 111M=0s >> >> 2011-08-03 15:18:07 (111 MB/s) - ?/tmp/tmpsyC9Zx/ca.crt? saved [779/779] >> >> >> root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 >> root : DEBUG Search rootdse >> root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) >> root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainOb >> ject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': [ >> 'unix.vuw.ac.nz']})] >> root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) >> root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vu >> w,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hma >> c-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScop >> e': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special >> ', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal' >> , 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMax >> RenewableAge': ['604800']})] >> root : DEBUG will use domain: unix.vuw.ac.nz >> >> root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz >> >> Discovery was successful! >> root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ >> >> root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz >> >> Hostname: fed15-64-ws02.unix.vuw.ac.nz >> Realm: UNIX.VUW.AC.NZ >> DNS Domain: unix.vuw.ac.nz >> IPA Server: vuwunicoipamt01.unix.vuw.ac.nz >> BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz >> >> >> Continue to configure the system with these values? [no]: yes >> Enrollment principal: admin >> root : DEBUG will use principal: admin >> >> root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> root : DEBUG stdout= >> root : DEBUG stderr=--2011-08-03 15:18:12-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 779 [application/x-x509-ca-cert] >> Saving to: ?/etc/ipa/ca.crt? >> >> 0K 100% 112M=0s >> >> 2011-08-03 15:18:12 (112 MB/s) - ?/etc/ipa/ca.crt? saved [779/779] >> >> >> root : DEBUG Writing Kerberos configuration to /tmp/tmpiFqnW9: >> #File modified by ipa-client-install >> >> [libdefaults] >> default_realm = UNIX.VUW.AC.NZ >> dns_lookup_realm = true >> dns_lookup_kdc = true >> rdns = false >> ticket_lifetime = 24h >> forwardable = yes >> >> [realms] >> UNIX.VUW.AC.NZ = { >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> } >> >> [domain_realm] >> .unix.vuw.ac.nz = UNIX.VUW.AC.NZ >> unix.vuw.ac.nz = UNIX.VUW.AC.NZ >> >> [appdefaults] >> pam = { >> debug = false >> ticket_lifetime = 36000 >> renew_lifetime = 36000 >> forwardable = true >> krb4_convert = false >> } >> >> Password for admin at UNIX.VUW.AC.NZ: >> root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ >> root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: >> >> root : DEBUG stderr= >> >> root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d >> root : DEBUG stdout= >> root : DEBUG stderr=XML-RPC CALL: >> >> \r\n >> \r\n >> join\r\n >> \r\n >> \r\n >> fed15-64-ws02.unix.vuw.ac.nz\r\n >> \r\n >> \r\n >> nsosversion\r\n >> 2.6.38.6-26.rc1.fc15.x86_64\r\n >> nshardwareplatform\r\n >> x86_64\r\n >> \r\n >> \r\n >> \r\n >> >> HTTP response code is 500, not 200 >> >> Joining realm failed because of failing XML-RPC request. >> This error may be caused by incompatible server/client major versions. >> root : DEBUG args=kdestroy >> root : DEBUG stdout= >> root : DEBUG stderr= >> [root at fed15-64-ws02 ~]# >> ======================= >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] >> Sent: Wednesday, 3 August 2011 9:35 a.m. >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >> >> Hi, >> >> Client >> ========== >> rhel61-64cl04.unix.vuw.ac.nz >> Linux rhel61-64cl04.unix.vuw.ac.nz 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux >> ipa-client-2.0.0-23.el6_1.1.x86_64 >> libcurl-7.19.7-26.el6.x86_64 >> Red Hat Enterprise Linux Client release 6.1 (Santiago) >> ========== >> >> Server >> ========== >> Linux vuwunicoipamt01 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux >> libcurl-7.19.7-26.el6_1.1.x86_64 >> ipa-client-2.0.0-23.el6_1.1.x86_64 >> ipa-server-2.0.0-23.el6_1.1.x86_64 >> Red Hat Enterprise Linux Server release 6.1 (Santiago) >> ========== >> >> install output >> ========== >> [root at rhel61-64cl04 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d >> root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz', 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw.ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server': None, 'mkhomedir': True, 'unattended': None, 'principal': None} >> root : DEBUG missing options might be asked for interactively later >> >> root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' >> root : DEBUG [ipacheckldap] >> root : DEBUG args=/usr/bin/wget -O /tmp/tmpaaTaqF/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> root : DEBUG stdout= >> root : DEBUG stderr=--2011-08-03 09:01:14-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 779 [application/x-x509-ca-cert] >> Saving to: `/tmp/tmpaaTaqF/ca.crt' >> >> 0K 100% 132M=0s >> >> 2011-08-03 09:01:14 (132 MB/s) - `/tmp/tmpaaTaqF/ca.crt' saved [779/779] >> >> >> root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 >> root : DEBUG Search rootdse >> root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) >> root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': ['unix.vuw.ac.nz']})] >> root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) >> root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vuw,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})] >> root : DEBUG will use domain: unix.vuw.ac.nz >> >> root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz >> >> Discovery was successful! >> root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ >> >> root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz >> >> Hostname: rhel61-64cl04.unix.vuw.ac.nz >> Realm: UNIX.VUW.AC.NZ >> DNS Domain: unix.vuw.ac.nz >> IPA Server: vuwunicoipamt01.unix.vuw.ac.nz >> BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz >> >> >> Continue to configure the system with these values? [no]: yes >> Enrollment principal: admin >> root : DEBUG will use principal: admin >> >> root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> root : DEBUG stdout= >> root : DEBUG stderr=--2011-08-03 09:01:22-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 779 [application/x-x509-ca-cert] >> Saving to: `/etc/ipa/ca.crt' >> >> 0K 100% 96.5M=0s >> >> 2011-08-03 09:01:22 (96.5 MB/s) - `/etc/ipa/ca.crt' saved [779/779] >> >> >> Password for admin at UNIX.VUW.AC.NZ: >> root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ >> root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: >> >> root : DEBUG stderr= >> >> root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d >> root : DEBUG stdout= >> root : DEBUG stderr=XML-RPC CALL: >> >> \r\n >> \r\n >> join\r\n >> \r\n >> \r\n >> rhel61-64cl04.unix.vuw.ac.nz\r\n >> \r\n >> \r\n >> nsosversion\r\n >> 2.6.32-131.6.1.el6.x86_64\r\n >> nshardwareplatform\r\n >> x86_64\r\n >> \r\n >> \r\n >> \r\n >> >> HTTP response code is 401, not 200 >> >> Joining realm failed because of failing XML-RPC request. >> This error may be caused by incompatible server/client major versions. >> root : DEBUG args=kdestroy >> root : DEBUG stdout= >> root : DEBUG stderr= >> [root at rhel61-64cl04 ~]# >> ========== >> >> Error log >> ========== >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [notice] caught SIGTERM, shutting down >> [Wed Aug 03 09:04:58 2011] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 >> [Wed Aug 03 09:04:58 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >> [Wed Aug 03 09:04:58 2011] [notice] Digest: generating secret for digest authentication ... >> [Wed Aug 03 09:04:58 2011] [notice] Digest: done >> [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Compiled for Python/2.6.2. >> [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Runtime using Python/2.6.6. >> [Wed Aug 03 09:04:59 2011] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations >> [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** >> [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** >> ========== >> >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Rob Crittenden [rcritten at redhat.com] >> Sent: Wednesday, 3 August 2011 1:48 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >> >> Steven Jones wrote: >>> >>> Yes....enrolement now fails, previous messages I attached show that I think, it used to work. >>> >>> History, I had to remove all my working IPA clients due to a disk space problem on our SAN (we didnt have any). So I managed to keep the working IPA server and 2 x RHEL5 64 bit servers and the one un-configured template of RHEL6.1 64bit client I had. This I used to make client side clones off previously and connected them to IPA server and they worked. >>> >>> So lastweek I went back and with a running ipa server, I cloned in the old client/template and got the mis-match, so I put them on the production network and patched, same mismatch problem. >>> >>> I can do a sosreport of the old template I think and the client to look at the differences if that helps. >> >> I'm having a hard time following exactly what you are doing, on what >> machine. I think we need to be more systematic. >> >> Can you choose a machine to act as the client and provide the following: >> >> - distro and architecture (e.g. RHEL 6.1 on x86_64) >> - rpm -q curl libcurl >> - rpm -q ipa-client >> >> On the IPA server: >> - rpm -q ipa-server >> >> Start with a client that is not enrolled. If it has previously been >> enrolled run: ipa-client-install --uninstall -U >> >> Now run ipa-client-install and answer the questions as appropriate for >> your install. >> >> If it fails please provide the following: >> - any stdout you get from the client install >> - attach the full /var/log/ipaclient-install.log >> - attach the last 100 lines from /var/log/httpd/error_log from the IPA >> server >> >> rob >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From Steven.Jones at vuw.ac.nz Thu Aug 4 23:32:02 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 4 Aug 2011 23:32:02 +0000 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <4E3B190B.9050502@redhat.com> References: <4E2EC378.9050401@romal.de>, <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E307F91.10309@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E380026.5000707@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E0285@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3A9DAB.30901@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369E0FE4@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E1007@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3B190B.9050502@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40369E10C7@STAWINCOX10MBX1.staff.vuw.ac.nz> I think you mean 04? I am getting a sasl failed. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Friday, 5 August 2011 10:11 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] version mismatch while joining a client ? Steven Jones wrote: > Hi, > > Trying with two rhel61-64bit-clones "04" and "05".... > > They should give the same failures? but are not?......confused, 04 (the first clone has 1/2 joined as its in IPA, but it doesnt say "enrolled and a date", 05 failed totally. 04 is failing because it apparently still has an updated libcurl. It is getting a 500 error back. The installation continues because you had the --force flag. This means it proceeds on errors, so it tried to set things up but since it didn't get a keytab sssd can't authenticate. 05 actually enrolled successfully but was unable to retrieve a keytab. You can try running ipa-getkeytab from the command-line again. To do this you'll need to copy a krb5.conf from a working system (say the IPA server. # kinit admin # ipa-getkeytab -s vuwunicoipamt01.unix.vuw.ac.nz -k /etc/krb5.keytab -p host/rhel61-64cl04.unix.vuw.ac.nz at UNIX.VUW.AC.NZ You may also want to look at the krb5kdc.log and the 389-ds access log, they may hold clues as well. > > I know Im short on sleep but I really don't understand what's going on here and why its so hard to make basic stuff work. > > :/ > > I have included the logs off each, logs off the IPA server and out's from the attempt to join. from each guest. Anything else needed? > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] > Sent: Friday, 5 August 2011 8:42 a.m. > To: Rob Crittenden > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Hi, > > Yes the first is F15. > > I am halting all the AD machines I will retry without the --force first to test this, when I built IPA originally there was no AD to conflict. > > However its plain weird because the RHEL6.1 client points to the IPA server for DNS. > > I will get back to you. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Friday, 5 August 2011 1:24 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Steven Jones wrote: >> Hi, >> >> I have also done this on a new f15 client and it also fails. >> >> But its saying, >> >> 500 and not 401 which is the rhel6.1 failure. >> >> "HTTP response code is 401, not 200" == RHEL61 >> "HTTP response code is 500, not 200" == FED15 > > Assuming that the Fedora 15 client is 130.195.53.109 that I had seen in > a previous log it has a libcurl that does not do ticket delegation. > > 500 is an HTTP server error, we assume a principal will be there and it > isn't and things blow up (this is handled more gracefully in our dev tree). > > 401 is a HTTP authorization error, the user provide is now allowed to > access the server. I'm guessing this is because the client is using the > wrong kerberos server. We have this addressed too in the dev tree, we > disable dns lookups in krb5.conf. In the meantime --force should make it > use the info you provide. > > rob > > >> >> >> ============== >> more fed15-install-error >> [root at fed15-64-ws02 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d >> root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz' >> , 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw. >> ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server' >> : None, 'mkhomedir': True, 'unattended': None, 'principal': None} >> root : DEBUG missing options might be asked for interactively later >> >> root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' >> root : DEBUG [ipacheckldap] >> root : DEBUG args=/usr/bin/wget -O /tmp/tmpsyC9Zx/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> root : DEBUG stdout= >> root : DEBUG stderr=--2011-08-03 15:18:07-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 779 [application/x-x509-ca-cert] >> Saving to: ?/tmp/tmpsyC9Zx/ca.crt? >> >> 0K 100% 111M=0s >> >> 2011-08-03 15:18:07 (111 MB/s) - ?/tmp/tmpsyC9Zx/ca.crt? saved [779/779] >> >> >> root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 >> root : DEBUG Search rootdse >> root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) >> root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainOb >> ject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': [ >> 'unix.vuw.ac.nz']})] >> root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) >> root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vu >> w,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hma >> c-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScop >> e': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special >> ', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal' >> , 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMax >> RenewableAge': ['604800']})] >> root : DEBUG will use domain: unix.vuw.ac.nz >> >> root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz >> >> Discovery was successful! >> root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ >> >> root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz >> >> Hostname: fed15-64-ws02.unix.vuw.ac.nz >> Realm: UNIX.VUW.AC.NZ >> DNS Domain: unix.vuw.ac.nz >> IPA Server: vuwunicoipamt01.unix.vuw.ac.nz >> BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz >> >> >> Continue to configure the system with these values? [no]: yes >> Enrollment principal: admin >> root : DEBUG will use principal: admin >> >> root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> root : DEBUG stdout= >> root : DEBUG stderr=--2011-08-03 15:18:12-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 779 [application/x-x509-ca-cert] >> Saving to: ?/etc/ipa/ca.crt? >> >> 0K 100% 112M=0s >> >> 2011-08-03 15:18:12 (112 MB/s) - ?/etc/ipa/ca.crt? saved [779/779] >> >> >> root : DEBUG Writing Kerberos configuration to /tmp/tmpiFqnW9: >> #File modified by ipa-client-install >> >> [libdefaults] >> default_realm = UNIX.VUW.AC.NZ >> dns_lookup_realm = true >> dns_lookup_kdc = true >> rdns = false >> ticket_lifetime = 24h >> forwardable = yes >> >> [realms] >> UNIX.VUW.AC.NZ = { >> pkinit_anchors = FILE:/etc/ipa/ca.crt >> } >> >> [domain_realm] >> .unix.vuw.ac.nz = UNIX.VUW.AC.NZ >> unix.vuw.ac.nz = UNIX.VUW.AC.NZ >> >> [appdefaults] >> pam = { >> debug = false >> ticket_lifetime = 36000 >> renew_lifetime = 36000 >> forwardable = true >> krb4_convert = false >> } >> >> Password for admin at UNIX.VUW.AC.NZ: >> root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ >> root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: >> >> root : DEBUG stderr= >> >> root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d >> root : DEBUG stdout= >> root : DEBUG stderr=XML-RPC CALL: >> >> \r\n >> \r\n >> join\r\n >> \r\n >> \r\n >> fed15-64-ws02.unix.vuw.ac.nz\r\n >> \r\n >> \r\n >> nsosversion\r\n >> 2.6.38.6-26.rc1.fc15.x86_64\r\n >> nshardwareplatform\r\n >> x86_64\r\n >> \r\n >> \r\n >> \r\n >> >> HTTP response code is 500, not 200 >> >> Joining realm failed because of failing XML-RPC request. >> This error may be caused by incompatible server/client major versions. >> root : DEBUG args=kdestroy >> root : DEBUG stdout= >> root : DEBUG stderr= >> [root at fed15-64-ws02 ~]# >> ======================= >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] >> Sent: Wednesday, 3 August 2011 9:35 a.m. >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >> >> Hi, >> >> Client >> ========== >> rhel61-64cl04.unix.vuw.ac.nz >> Linux rhel61-64cl04.unix.vuw.ac.nz 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux >> ipa-client-2.0.0-23.el6_1.1.x86_64 >> libcurl-7.19.7-26.el6.x86_64 >> Red Hat Enterprise Linux Client release 6.1 (Santiago) >> ========== >> >> Server >> ========== >> Linux vuwunicoipamt01 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux >> libcurl-7.19.7-26.el6_1.1.x86_64 >> ipa-client-2.0.0-23.el6_1.1.x86_64 >> ipa-server-2.0.0-23.el6_1.1.x86_64 >> Red Hat Enterprise Linux Server release 6.1 (Santiago) >> ========== >> >> install output >> ========== >> [root at rhel61-64cl04 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d >> root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz', 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw.ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server': None, 'mkhomedir': True, 'unattended': None, 'principal': None} >> root : DEBUG missing options might be asked for interactively later >> >> root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' >> root : DEBUG [ipacheckldap] >> root : DEBUG args=/usr/bin/wget -O /tmp/tmpaaTaqF/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> root : DEBUG stdout= >> root : DEBUG stderr=--2011-08-03 09:01:14-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 779 [application/x-x509-ca-cert] >> Saving to: `/tmp/tmpaaTaqF/ca.crt' >> >> 0K 100% 132M=0s >> >> 2011-08-03 09:01:14 (132 MB/s) - `/tmp/tmpaaTaqF/ca.crt' saved [779/779] >> >> >> root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 >> root : DEBUG Search rootdse >> root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) >> root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': ['unix.vuw.ac.nz']})] >> root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) >> root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vuw,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})] >> root : DEBUG will use domain: unix.vuw.ac.nz >> >> root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz >> >> Discovery was successful! >> root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ >> >> root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz >> >> Hostname: rhel61-64cl04.unix.vuw.ac.nz >> Realm: UNIX.VUW.AC.NZ >> DNS Domain: unix.vuw.ac.nz >> IPA Server: vuwunicoipamt01.unix.vuw.ac.nz >> BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz >> >> >> Continue to configure the system with these values? [no]: yes >> Enrollment principal: admin >> root : DEBUG will use principal: admin >> >> root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> root : DEBUG stdout= >> root : DEBUG stderr=--2011-08-03 09:01:22-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 779 [application/x-x509-ca-cert] >> Saving to: `/etc/ipa/ca.crt' >> >> 0K 100% 96.5M=0s >> >> 2011-08-03 09:01:22 (96.5 MB/s) - `/etc/ipa/ca.crt' saved [779/779] >> >> >> Password for admin at UNIX.VUW.AC.NZ: >> root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ >> root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: >> >> root : DEBUG stderr= >> >> root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d >> root : DEBUG stdout= >> root : DEBUG stderr=XML-RPC CALL: >> >> \r\n >> \r\n >> join\r\n >> \r\n >> \r\n >> rhel61-64cl04.unix.vuw.ac.nz\r\n >> \r\n >> \r\n >> nsosversion\r\n >> 2.6.32-131.6.1.el6.x86_64\r\n >> nshardwareplatform\r\n >> x86_64\r\n >> \r\n >> \r\n >> \r\n >> >> HTTP response code is 401, not 200 >> >> Joining realm failed because of failing XML-RPC request. >> This error may be caused by incompatible server/client major versions. >> root : DEBUG args=kdestroy >> root : DEBUG stdout= >> root : DEBUG stderr= >> [root at rhel61-64cl04 ~]# >> ========== >> >> Error log >> ========== >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >> [Wed Aug 03 09:04:57 2011] [notice] caught SIGTERM, shutting down >> [Wed Aug 03 09:04:58 2011] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 >> [Wed Aug 03 09:04:58 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >> [Wed Aug 03 09:04:58 2011] [notice] Digest: generating secret for digest authentication ... >> [Wed Aug 03 09:04:58 2011] [notice] Digest: done >> [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Compiled for Python/2.6.2. >> [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Runtime using Python/2.6.6. >> [Wed Aug 03 09:04:59 2011] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations >> [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** >> [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** >> ========== >> >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Rob Crittenden [rcritten at redhat.com] >> Sent: Wednesday, 3 August 2011 1:48 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >> >> Steven Jones wrote: >>> >>> Yes....enrolement now fails, previous messages I attached show that I think, it used to work. >>> >>> History, I had to remove all my working IPA clients due to a disk space problem on our SAN (we didnt have any). So I managed to keep the working IPA server and 2 x RHEL5 64 bit servers and the one un-configured template of RHEL6.1 64bit client I had. This I used to make client side clones off previously and connected them to IPA server and they worked. >>> >>> So lastweek I went back and with a running ipa server, I cloned in the old client/template and got the mis-match, so I put them on the production network and patched, same mismatch problem. >>> >>> I can do a sosreport of the old template I think and the client to look at the differences if that helps. >> >> I'm having a hard time following exactly what you are doing, on what >> machine. I think we need to be more systematic. >> >> Can you choose a machine to act as the client and provide the following: >> >> - distro and architecture (e.g. RHEL 6.1 on x86_64) >> - rpm -q curl libcurl >> - rpm -q ipa-client >> >> On the IPA server: >> - rpm -q ipa-server >> >> Start with a client that is not enrolled. If it has previously been >> enrolled run: ipa-client-install --uninstall -U >> >> Now run ipa-client-install and answer the questions as appropriate for >> your install. >> >> If it fails please provide the following: >> - any stdout you get from the client install >> - attach the full /var/log/ipaclient-install.log >> - attach the last 100 lines from /var/log/httpd/error_log from the IPA >> server >> >> rob >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- A non-text attachment was scrubbed... Name: sasl-fail-cl04.jpeg Type: image/jpeg Size: 51780 bytes Desc: sasl-fail-cl04.jpeg URL: From Steven.Jones at vuw.ac.nz Thu Aug 4 23:40:25 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 4 Aug 2011 23:40:25 +0000 Subject: [Freeipa-users] sosreports Message-ID: <833D8E48405E064EBC54C84EC6B36E40369E10DA@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, For official RH support (eventually) would the sosreports get updated to include things like krb files and logs etc? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From Steven.Jones at vuw.ac.nz Thu Aug 4 23:47:06 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 4 Aug 2011 23:47:06 +0000 Subject: [Freeipa-users] sosreports In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40369E10DA@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40369E10DA@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <833D8E48405E064EBC54C84EC6B36E40369E10EF@STAWINCOX10MBX1.staff.vuw.ac.nz> In the meantime, can you list the things you want to see? I can write a wee script that collects and tar.gz's them up.....then my sieve like memory wont matter. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Friday, 5 August 2011 11:40 a.m. Cc: freeipa-users at redhat.com Subject: [Freeipa-users] sosreports Hi, For official RH support (eventually) would the sosreports get updated to include things like krb files and logs etc? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Fri Aug 5 02:49:20 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 04 Aug 2011 22:49:20 -0400 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40369E1085@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <4E2EC378.9050401@romal.de>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E380026.5000707@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E0285@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3A9DAB.30901@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369E0FE4@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E1007@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3B190B.9050502@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369E1085@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4E3B5A30.5010404@redhat.com> Steven Jones wrote: > I already included the krb5kdc log This sticks out. Can you check /etc/hosts on that client. ldap/localhost at UNIX.VUW.AC.NZ, Server not found in Kerberos database > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Friday, 5 August 2011 10:11 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Steven Jones wrote: >> Hi, >> >> Trying with two rhel61-64bit-clones "04" and "05".... >> >> They should give the same failures? but are not?......confused, 04 (the first clone has 1/2 joined as its in IPA, but it doesnt say "enrolled and a date", 05 failed totally. > > 04 is failing because it apparently still has an updated libcurl. It is > getting a 500 error back. The installation continues because you had the > --force flag. This means it proceeds on errors, so it tried to set > things up but since it didn't get a keytab sssd can't authenticate. > > 05 actually enrolled successfully but was unable to retrieve a keytab. > You can try running ipa-getkeytab from the command-line again. To do > this you'll need to copy a krb5.conf from a working system (say the IPA > server. > > # kinit admin > # ipa-getkeytab -s vuwunicoipamt01.unix.vuw.ac.nz -k /etc/krb5.keytab -p > host/rhel61-64cl04.unix.vuw.ac.nz at UNIX.VUW.AC.NZ > > You may also want to look at the krb5kdc.log and the 389-ds access log, > they may hold clues as well. > >> >> I know Im short on sleep but I really don't understand what's going on here and why its so hard to make basic stuff work. >> >> :/ >> >> I have included the logs off each, logs off the IPA server and out's from the attempt to join. from each guest. Anything else needed? >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] >> Sent: Friday, 5 August 2011 8:42 a.m. >> To: Rob Crittenden >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >> >> Hi, >> >> Yes the first is F15. >> >> I am halting all the AD machines I will retry without the --force first to test this, when I built IPA originally there was no AD to conflict. >> >> However its plain weird because the RHEL6.1 client points to the IPA server for DNS. >> >> I will get back to you. >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Rob Crittenden [rcritten at redhat.com] >> Sent: Friday, 5 August 2011 1:24 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >> >> Steven Jones wrote: >>> Hi, >>> >>> I have also done this on a new f15 client and it also fails. >>> >>> But its saying, >>> >>> 500 and not 401 which is the rhel6.1 failure. >>> >>> "HTTP response code is 401, not 200" == RHEL61 >>> "HTTP response code is 500, not 200" == FED15 >> >> Assuming that the Fedora 15 client is 130.195.53.109 that I had seen in >> a previous log it has a libcurl that does not do ticket delegation. >> >> 500 is an HTTP server error, we assume a principal will be there and it >> isn't and things blow up (this is handled more gracefully in our dev tree). >> >> 401 is a HTTP authorization error, the user provide is now allowed to >> access the server. I'm guessing this is because the client is using the >> wrong kerberos server. We have this addressed too in the dev tree, we >> disable dns lookups in krb5.conf. In the meantime --force should make it >> use the info you provide. >> >> rob >> >> >>> >>> >>> ============== >>> more fed15-install-error >>> [root at fed15-64-ws02 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d >>> root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz' >>> , 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw. >>> ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server' >>> : None, 'mkhomedir': True, 'unattended': None, 'principal': None} >>> root : DEBUG missing options might be asked for interactively later >>> >>> root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' >>> root : DEBUG [ipacheckldap] >>> root : DEBUG args=/usr/bin/wget -O /tmp/tmpsyC9Zx/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >>> root : DEBUG stdout= >>> root : DEBUG stderr=--2011-08-03 15:18:07-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >>> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >>> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: 779 [application/x-x509-ca-cert] >>> Saving to: ?/tmp/tmpsyC9Zx/ca.crt? >>> >>> 0K 100% 111M=0s >>> >>> 2011-08-03 15:18:07 (111 MB/s) - ?/tmp/tmpsyC9Zx/ca.crt? saved [779/779] >>> >>> >>> root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 >>> root : DEBUG Search rootdse >>> root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) >>> root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainOb >>> ject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': [ >>> 'unix.vuw.ac.nz']})] >>> root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) >>> root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vu >>> w,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hma >>> c-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScop >>> e': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special >>> ', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal' >>> , 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMax >>> RenewableAge': ['604800']})] >>> root : DEBUG will use domain: unix.vuw.ac.nz >>> >>> root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz >>> >>> Discovery was successful! >>> root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ >>> >>> root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz >>> >>> Hostname: fed15-64-ws02.unix.vuw.ac.nz >>> Realm: UNIX.VUW.AC.NZ >>> DNS Domain: unix.vuw.ac.nz >>> IPA Server: vuwunicoipamt01.unix.vuw.ac.nz >>> BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz >>> >>> >>> Continue to configure the system with these values? [no]: yes >>> Enrollment principal: admin >>> root : DEBUG will use principal: admin >>> >>> root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >>> root : DEBUG stdout= >>> root : DEBUG stderr=--2011-08-03 15:18:12-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >>> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >>> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: 779 [application/x-x509-ca-cert] >>> Saving to: ?/etc/ipa/ca.crt? >>> >>> 0K 100% 112M=0s >>> >>> 2011-08-03 15:18:12 (112 MB/s) - ?/etc/ipa/ca.crt? saved [779/779] >>> >>> >>> root : DEBUG Writing Kerberos configuration to /tmp/tmpiFqnW9: >>> #File modified by ipa-client-install >>> >>> [libdefaults] >>> default_realm = UNIX.VUW.AC.NZ >>> dns_lookup_realm = true >>> dns_lookup_kdc = true >>> rdns = false >>> ticket_lifetime = 24h >>> forwardable = yes >>> >>> [realms] >>> UNIX.VUW.AC.NZ = { >>> pkinit_anchors = FILE:/etc/ipa/ca.crt >>> } >>> >>> [domain_realm] >>> .unix.vuw.ac.nz = UNIX.VUW.AC.NZ >>> unix.vuw.ac.nz = UNIX.VUW.AC.NZ >>> >>> [appdefaults] >>> pam = { >>> debug = false >>> ticket_lifetime = 36000 >>> renew_lifetime = 36000 >>> forwardable = true >>> krb4_convert = false >>> } >>> >>> Password for admin at UNIX.VUW.AC.NZ: >>> root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ >>> root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: >>> >>> root : DEBUG stderr= >>> >>> root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d >>> root : DEBUG stdout= >>> root : DEBUG stderr=XML-RPC CALL: >>> >>> \r\n >>> \r\n >>> join\r\n >>> \r\n >>> \r\n >>> fed15-64-ws02.unix.vuw.ac.nz\r\n >>> \r\n >>> \r\n >>> nsosversion\r\n >>> 2.6.38.6-26.rc1.fc15.x86_64\r\n >>> nshardwareplatform\r\n >>> x86_64\r\n >>> \r\n >>> \r\n >>> \r\n >>> >>> HTTP response code is 500, not 200 >>> >>> Joining realm failed because of failing XML-RPC request. >>> This error may be caused by incompatible server/client major versions. >>> root : DEBUG args=kdestroy >>> root : DEBUG stdout= >>> root : DEBUG stderr= >>> [root at fed15-64-ws02 ~]# >>> ======================= >>> >>> regards >>> >>> Steven Jones >>> >>> Technical Specialist - Linux RHCE >>> >>> Victoria University, Wellington, NZ >>> >>> 0064 4 463 6272 >>> >>> ________________________________________ >>> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] >>> Sent: Wednesday, 3 August 2011 9:35 a.m. >>> To: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >>> >>> Hi, >>> >>> Client >>> ========== >>> rhel61-64cl04.unix.vuw.ac.nz >>> Linux rhel61-64cl04.unix.vuw.ac.nz 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux >>> ipa-client-2.0.0-23.el6_1.1.x86_64 >>> libcurl-7.19.7-26.el6.x86_64 >>> Red Hat Enterprise Linux Client release 6.1 (Santiago) >>> ========== >>> >>> Server >>> ========== >>> Linux vuwunicoipamt01 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux >>> libcurl-7.19.7-26.el6_1.1.x86_64 >>> ipa-client-2.0.0-23.el6_1.1.x86_64 >>> ipa-server-2.0.0-23.el6_1.1.x86_64 >>> Red Hat Enterprise Linux Server release 6.1 (Santiago) >>> ========== >>> >>> install output >>> ========== >>> [root at rhel61-64cl04 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d >>> root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz', 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw.ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server': None, 'mkhomedir': True, 'unattended': None, 'principal': None} >>> root : DEBUG missing options might be asked for interactively later >>> >>> root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' >>> root : DEBUG [ipacheckldap] >>> root : DEBUG args=/usr/bin/wget -O /tmp/tmpaaTaqF/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >>> root : DEBUG stdout= >>> root : DEBUG stderr=--2011-08-03 09:01:14-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >>> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >>> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: 779 [application/x-x509-ca-cert] >>> Saving to: `/tmp/tmpaaTaqF/ca.crt' >>> >>> 0K 100% 132M=0s >>> >>> 2011-08-03 09:01:14 (132 MB/s) - `/tmp/tmpaaTaqF/ca.crt' saved [779/779] >>> >>> >>> root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 >>> root : DEBUG Search rootdse >>> root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) >>> root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': ['unix.vuw.ac.nz']})] >>> root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) >>> root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vuw,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})] >>> root : DEBUG will use domain: unix.vuw.ac.nz >>> >>> root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz >>> >>> Discovery was successful! >>> root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ >>> >>> root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz >>> >>> Hostname: rhel61-64cl04.unix.vuw.ac.nz >>> Realm: UNIX.VUW.AC.NZ >>> DNS Domain: unix.vuw.ac.nz >>> IPA Server: vuwunicoipamt01.unix.vuw.ac.nz >>> BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz >>> >>> >>> Continue to configure the system with these values? [no]: yes >>> Enrollment principal: admin >>> root : DEBUG will use principal: admin >>> >>> root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >>> root : DEBUG stdout= >>> root : DEBUG stderr=--2011-08-03 09:01:22-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >>> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >>> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: 779 [application/x-x509-ca-cert] >>> Saving to: `/etc/ipa/ca.crt' >>> >>> 0K 100% 96.5M=0s >>> >>> 2011-08-03 09:01:22 (96.5 MB/s) - `/etc/ipa/ca.crt' saved [779/779] >>> >>> >>> Password for admin at UNIX.VUW.AC.NZ: >>> root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ >>> root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: >>> >>> root : DEBUG stderr= >>> >>> root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d >>> root : DEBUG stdout= >>> root : DEBUG stderr=XML-RPC CALL: >>> >>> \r\n >>> \r\n >>> join\r\n >>> \r\n >>> \r\n >>> rhel61-64cl04.unix.vuw.ac.nz\r\n >>> \r\n >>> \r\n >>> nsosversion\r\n >>> 2.6.32-131.6.1.el6.x86_64\r\n >>> nshardwareplatform\r\n >>> x86_64\r\n >>> \r\n >>> \r\n >>> \r\n >>> >>> HTTP response code is 401, not 200 >>> >>> Joining realm failed because of failing XML-RPC request. >>> This error may be caused by incompatible server/client major versions. >>> root : DEBUG args=kdestroy >>> root : DEBUG stdout= >>> root : DEBUG stderr= >>> [root at rhel61-64cl04 ~]# >>> ========== >>> >>> Error log >>> ========== >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [notice] caught SIGTERM, shutting down >>> [Wed Aug 03 09:04:58 2011] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 >>> [Wed Aug 03 09:04:58 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >>> [Wed Aug 03 09:04:58 2011] [notice] Digest: generating secret for digest authentication ... >>> [Wed Aug 03 09:04:58 2011] [notice] Digest: done >>> [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Compiled for Python/2.6.2. >>> [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Runtime using Python/2.6.6. >>> [Wed Aug 03 09:04:59 2011] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations >>> [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** >>> [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** >>> ========== >>> >>> >>> regards >>> >>> Steven Jones >>> >>> Technical Specialist - Linux RHCE >>> >>> Victoria University, Wellington, NZ >>> >>> 0064 4 463 6272 >>> >>> ________________________________________ >>> From: Rob Crittenden [rcritten at redhat.com] >>> Sent: Wednesday, 3 August 2011 1:48 a.m. >>> To: Steven Jones >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >>> >>> Steven Jones wrote: >>>> >>>> Yes....enrolement now fails, previous messages I attached show that I think, it used to work. >>>> >>>> History, I had to remove all my working IPA clients due to a disk space problem on our SAN (we didnt have any). So I managed to keep the working IPA server and 2 x RHEL5 64 bit servers and the one un-configured template of RHEL6.1 64bit client I had. This I used to make client side clones off previously and connected them to IPA server and they worked. >>>> >>>> So lastweek I went back and with a running ipa server, I cloned in the old client/template and got the mis-match, so I put them on the production network and patched, same mismatch problem. >>>> >>>> I can do a sosreport of the old template I think and the client to look at the differences if that helps. >>> >>> I'm having a hard time following exactly what you are doing, on what >>> machine. I think we need to be more systematic. >>> >>> Can you choose a machine to act as the client and provide the following: >>> >>> - distro and architecture (e.g. RHEL 6.1 on x86_64) >>> - rpm -q curl libcurl >>> - rpm -q ipa-client >>> >>> On the IPA server: >>> - rpm -q ipa-server >>> >>> Start with a client that is not enrolled. If it has previously been >>> enrolled run: ipa-client-install --uninstall -U >>> >>> Now run ipa-client-install and answer the questions as appropriate for >>> your install. >>> >>> If it fails please provide the following: >>> - any stdout you get from the client install >>> - attach the full /var/log/ipaclient-install.log >>> - attach the last 100 lines from /var/log/httpd/error_log from the IPA >>> server >>> >>> rob >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > From Steven.Jones at vuw.ac.nz Fri Aug 5 03:49:11 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Fri, 5 Aug 2011 03:49:11 +0000 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <4E3B5A30.5010404@redhat.com> References: <4E2EC378.9050401@romal.de>, <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E380026.5000707@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E0285@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3A9DAB.30901@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40369E0FE4@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E1007@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3B190B.9050502@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369E1085@STAWINCOX10MBX1.staff.vuw.ac.nz>, <4E3B5A30.5010404@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40369E1604@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Well the hostname itself isnt there, but thats normal with dhcp'd workstations? I thought it looked at /etc/sysconfig/network ? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Friday, 5 August 2011 2:49 p.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] version mismatch while joining a client ? Steven Jones wrote: > I already included the krb5kdc log This sticks out. Can you check /etc/hosts on that client. ldap/localhost at UNIX.VUW.AC.NZ, Server not found in Kerberos database > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Friday, 5 August 2011 10:11 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] version mismatch while joining a client ? > > Steven Jones wrote: >> Hi, >> >> Trying with two rhel61-64bit-clones "04" and "05".... >> >> They should give the same failures? but are not?......confused, 04 (the first clone has 1/2 joined as its in IPA, but it doesnt say "enrolled and a date", 05 failed totally. > > 04 is failing because it apparently still has an updated libcurl. It is > getting a 500 error back. The installation continues because you had the > --force flag. This means it proceeds on errors, so it tried to set > things up but since it didn't get a keytab sssd can't authenticate. > > 05 actually enrolled successfully but was unable to retrieve a keytab. > You can try running ipa-getkeytab from the command-line again. To do > this you'll need to copy a krb5.conf from a working system (say the IPA > server. > > # kinit admin > # ipa-getkeytab -s vuwunicoipamt01.unix.vuw.ac.nz -k /etc/krb5.keytab -p > host/rhel61-64cl04.unix.vuw.ac.nz at UNIX.VUW.AC.NZ > > You may also want to look at the krb5kdc.log and the 389-ds access log, > they may hold clues as well. > >> >> I know Im short on sleep but I really don't understand what's going on here and why its so hard to make basic stuff work. >> >> :/ >> >> I have included the logs off each, logs off the IPA server and out's from the attempt to join. from each guest. Anything else needed? >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] >> Sent: Friday, 5 August 2011 8:42 a.m. >> To: Rob Crittenden >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >> >> Hi, >> >> Yes the first is F15. >> >> I am halting all the AD machines I will retry without the --force first to test this, when I built IPA originally there was no AD to conflict. >> >> However its plain weird because the RHEL6.1 client points to the IPA server for DNS. >> >> I will get back to you. >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Rob Crittenden [rcritten at redhat.com] >> Sent: Friday, 5 August 2011 1:24 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >> >> Steven Jones wrote: >>> Hi, >>> >>> I have also done this on a new f15 client and it also fails. >>> >>> But its saying, >>> >>> 500 and not 401 which is the rhel6.1 failure. >>> >>> "HTTP response code is 401, not 200" == RHEL61 >>> "HTTP response code is 500, not 200" == FED15 >> >> Assuming that the Fedora 15 client is 130.195.53.109 that I had seen in >> a previous log it has a libcurl that does not do ticket delegation. >> >> 500 is an HTTP server error, we assume a principal will be there and it >> isn't and things blow up (this is handled more gracefully in our dev tree). >> >> 401 is a HTTP authorization error, the user provide is now allowed to >> access the server. I'm guessing this is because the client is using the >> wrong kerberos server. We have this addressed too in the dev tree, we >> disable dns lookups in krb5.conf. In the meantime --force should make it >> use the info you provide. >> >> rob >> >> >>> >>> >>> ============== >>> more fed15-install-error >>> [root at fed15-64-ws02 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d >>> root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz' >>> , 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw. >>> ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server' >>> : None, 'mkhomedir': True, 'unattended': None, 'principal': None} >>> root : DEBUG missing options might be asked for interactively later >>> >>> root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' >>> root : DEBUG [ipacheckldap] >>> root : DEBUG args=/usr/bin/wget -O /tmp/tmpsyC9Zx/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >>> root : DEBUG stdout= >>> root : DEBUG stderr=--2011-08-03 15:18:07-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >>> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >>> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: 779 [application/x-x509-ca-cert] >>> Saving to: ?/tmp/tmpsyC9Zx/ca.crt? >>> >>> 0K 100% 111M=0s >>> >>> 2011-08-03 15:18:07 (111 MB/s) - ?/tmp/tmpsyC9Zx/ca.crt? saved [779/779] >>> >>> >>> root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 >>> root : DEBUG Search rootdse >>> root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) >>> root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainOb >>> ject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': [ >>> 'unix.vuw.ac.nz']})] >>> root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) >>> root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vu >>> w,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hma >>> c-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScop >>> e': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special >>> ', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal' >>> , 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMax >>> RenewableAge': ['604800']})] >>> root : DEBUG will use domain: unix.vuw.ac.nz >>> >>> root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz >>> >>> Discovery was successful! >>> root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ >>> >>> root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz >>> >>> Hostname: fed15-64-ws02.unix.vuw.ac.nz >>> Realm: UNIX.VUW.AC.NZ >>> DNS Domain: unix.vuw.ac.nz >>> IPA Server: vuwunicoipamt01.unix.vuw.ac.nz >>> BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz >>> >>> >>> Continue to configure the system with these values? [no]: yes >>> Enrollment principal: admin >>> root : DEBUG will use principal: admin >>> >>> root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >>> root : DEBUG stdout= >>> root : DEBUG stderr=--2011-08-03 15:18:12-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >>> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >>> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: 779 [application/x-x509-ca-cert] >>> Saving to: ?/etc/ipa/ca.crt? >>> >>> 0K 100% 112M=0s >>> >>> 2011-08-03 15:18:12 (112 MB/s) - ?/etc/ipa/ca.crt? saved [779/779] >>> >>> >>> root : DEBUG Writing Kerberos configuration to /tmp/tmpiFqnW9: >>> #File modified by ipa-client-install >>> >>> [libdefaults] >>> default_realm = UNIX.VUW.AC.NZ >>> dns_lookup_realm = true >>> dns_lookup_kdc = true >>> rdns = false >>> ticket_lifetime = 24h >>> forwardable = yes >>> >>> [realms] >>> UNIX.VUW.AC.NZ = { >>> pkinit_anchors = FILE:/etc/ipa/ca.crt >>> } >>> >>> [domain_realm] >>> .unix.vuw.ac.nz = UNIX.VUW.AC.NZ >>> unix.vuw.ac.nz = UNIX.VUW.AC.NZ >>> >>> [appdefaults] >>> pam = { >>> debug = false >>> ticket_lifetime = 36000 >>> renew_lifetime = 36000 >>> forwardable = true >>> krb4_convert = false >>> } >>> >>> Password for admin at UNIX.VUW.AC.NZ: >>> root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ >>> root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: >>> >>> root : DEBUG stderr= >>> >>> root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d >>> root : DEBUG stdout= >>> root : DEBUG stderr=XML-RPC CALL: >>> >>> \r\n >>> \r\n >>> join\r\n >>> \r\n >>> \r\n >>> fed15-64-ws02.unix.vuw.ac.nz\r\n >>> \r\n >>> \r\n >>> nsosversion\r\n >>> 2.6.38.6-26.rc1.fc15.x86_64\r\n >>> nshardwareplatform\r\n >>> x86_64\r\n >>> \r\n >>> \r\n >>> \r\n >>> >>> HTTP response code is 500, not 200 >>> >>> Joining realm failed because of failing XML-RPC request. >>> This error may be caused by incompatible server/client major versions. >>> root : DEBUG args=kdestroy >>> root : DEBUG stdout= >>> root : DEBUG stderr= >>> [root at fed15-64-ws02 ~]# >>> ======================= >>> >>> regards >>> >>> Steven Jones >>> >>> Technical Specialist - Linux RHCE >>> >>> Victoria University, Wellington, NZ >>> >>> 0064 4 463 6272 >>> >>> ________________________________________ >>> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] >>> Sent: Wednesday, 3 August 2011 9:35 a.m. >>> To: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >>> >>> Hi, >>> >>> Client >>> ========== >>> rhel61-64cl04.unix.vuw.ac.nz >>> Linux rhel61-64cl04.unix.vuw.ac.nz 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux >>> ipa-client-2.0.0-23.el6_1.1.x86_64 >>> libcurl-7.19.7-26.el6.x86_64 >>> Red Hat Enterprise Linux Client release 6.1 (Santiago) >>> ========== >>> >>> Server >>> ========== >>> Linux vuwunicoipamt01 2.6.32-131.6.1.el6.x86_64 #1 SMP Mon Jun 20 14:15:38 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux >>> libcurl-7.19.7-26.el6_1.1.x86_64 >>> ipa-client-2.0.0-23.el6_1.1.x86_64 >>> ipa-server-2.0.0-23.el6_1.1.x86_64 >>> Red Hat Enterprise Linux Server release 6.1 (Santiago) >>> ========== >>> >>> install output >>> ========== >>> [root at rhel61-64cl04 ~]# ipa-client-install --mkhomedir --server vuwunicoipamt01.unix.vuw.ac.nz --domain unix.vuw.ac.nz -d >>> root : DEBUG /usr/sbin/ipa-client-install was invoked with options: {'conf_ntp': True, 'domain': 'unix.vuw.ac.nz', 'uninstall': False, 'force': False, 'sssd': True, 'hostname': None, 'permit': False, 'server': 'vuwunicoipamt01.unix.vuw.ac.nz', 'prompt_password': False, 'realm_name': None, 'dns_updates': False, 'debug': True, 'on_master': False, 'ntp_server': None, 'mkhomedir': True, 'unattended': None, 'principal': None} >>> root : DEBUG missing options might be asked for interactively later >>> >>> root : DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' >>> root : DEBUG [ipacheckldap] >>> root : DEBUG args=/usr/bin/wget -O /tmp/tmpaaTaqF/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >>> root : DEBUG stdout= >>> root : DEBUG stderr=--2011-08-03 09:01:14-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >>> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >>> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: 779 [application/x-x509-ca-cert] >>> Saving to: `/tmp/tmpaaTaqF/ca.crt' >>> >>> 0K 100% 132M=0s >>> >>> 2011-08-03 09:01:14 (132 MB/s) - `/tmp/tmpaaTaqF/ca.crt' saved [779/779] >>> >>> >>> root : DEBUG Init ldap with: ldap://vuwunicoipamt01.unix.vuw.ac.nz:389 >>> root : DEBUG Search rootdse >>> root : DEBUG Search for (info=*) in dc=unix,dc=vuw,dc=ac,dc=nz(base) >>> root : DEBUG Found: [('dc=unix,dc=vuw,dc=ac,dc=nz', {'objectClass': ['top', 'domain', 'pilotObject', 'nisDomainObject', 'domainRelatedObject'], 'info': ['IPA V2.0'], 'associatedDomain': ['unix.vuw.ac.nz'], 'dc': ['unix'], 'nisDomain': ['unix.vuw.ac.nz']})] >>> root : DEBUG Search for (objectClass=krbRealmContainer) in dc=unix,dc=vuw,dc=ac,dc=nz(sub) >>> root : DEBUG Found: [('cn=UNIX.VUW.AC.NZ,cn=kerberos,dc=unix,dc=vuw,dc=ac,dc=nz', {'krbSubTrees': ['dc=unix,dc=vuw,dc=ac,dc=nz'], 'cn': ['UNIX.VUW.AC.NZ'], 'krbDefaultEncSaltTypes': ['aes256-cts:special', 'aes128-cts:special', 'des3-hmac-sha1:special', 'arcfour-hmac:special'], 'objectClass': ['top', 'krbrealmcontainer', 'krbticketpolicyaux'], 'krbSearchScope': ['2'], 'krbSupportedEncSaltTypes': ['aes256-cts:normal', 'aes256-cts:special', 'aes128-cts:normal', 'aes128-cts:special', 'des3-hmac-sha1:normal', 'des3-hmac-sha1:special', 'arcfour-hmac:normal', 'arcfour-hmac:special', 'des-hmac-sha1:normal', 'des-cbc-md5:normal', 'des-cbc-crc:normal', 'des-cbc-crc:v4', 'des-cbc-crc:afs3'], 'krbMaxTicketLife': ['86400'], 'krbMaxRenewableAge': ['604800']})] >>> root : DEBUG will use domain: unix.vuw.ac.nz >>> >>> root : DEBUG will use server: vuwunicoipamt01.unix.vuw.ac.nz >>> >>> Discovery was successful! >>> root : DEBUG will use cli_realm: UNIX.VUW.AC.NZ >>> >>> root : DEBUG will use cli_basedn: dc=unix,dc=vuw,dc=ac,dc=nz >>> >>> Hostname: rhel61-64cl04.unix.vuw.ac.nz >>> Realm: UNIX.VUW.AC.NZ >>> DNS Domain: unix.vuw.ac.nz >>> IPA Server: vuwunicoipamt01.unix.vuw.ac.nz >>> BaseDN: dc=unix,dc=vuw,dc=ac,dc=nz >>> >>> >>> Continue to configure the system with these values? [no]: yes >>> Enrollment principal: admin >>> root : DEBUG will use principal: admin >>> >>> root : DEBUG args=/usr/bin/wget -O /etc/ipa/ca.crt http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >>> root : DEBUG stdout= >>> root : DEBUG stderr=--2011-08-03 09:01:22-- http://vuwunicoipamt01.unix.vuw.ac.nz/ipa/config/ca.crt >>> Resolving vuwunicoipamt01.unix.vuw.ac.nz... 130.195.87.236 >>> Connecting to vuwunicoipamt01.unix.vuw.ac.nz|130.195.87.236|:80... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: 779 [application/x-x509-ca-cert] >>> Saving to: `/etc/ipa/ca.crt' >>> >>> 0K 100% 96.5M=0s >>> >>> 2011-08-03 09:01:22 (96.5 MB/s) - `/etc/ipa/ca.crt' saved [779/779] >>> >>> >>> Password for admin at UNIX.VUW.AC.NZ: >>> root : DEBUG args=kinit admin at UNIX.VUW.AC.NZ >>> root : DEBUG stdout=Password for admin at UNIX.VUW.AC.NZ: >>> >>> root : DEBUG stderr= >>> >>> root : DEBUG args=/usr/sbin/ipa-join -s vuwunicoipamt01.unix.vuw.ac.nz -d >>> root : DEBUG stdout= >>> root : DEBUG stderr=XML-RPC CALL: >>> >>> \r\n >>> \r\n >>> join\r\n >>> \r\n >>> \r\n >>> rhel61-64cl04.unix.vuw.ac.nz\r\n >>> \r\n >>> \r\n >>> nsosversion\r\n >>> 2.6.32-131.6.1.el6.x86_64\r\n >>> nshardwareplatform\r\n >>> x86_64\r\n >>> \r\n >>> \r\n >>> \r\n >>> >>> HTTP response code is 401, not 200 >>> >>> Joining realm failed because of failing XML-RPC request. >>> This error may be caused by incompatible server/client major versions. >>> root : DEBUG args=kdestroy >>> root : DEBUG stdout= >>> root : DEBUG stderr= >>> [root at rhel61-64cl04 ~]# >>> ========== >>> >>> Error log >>> ========== >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [error] Exception KeyError: KeyError(140510308317152,) in ignored >>> [Wed Aug 03 09:04:57 2011] [notice] caught SIGTERM, shutting down >>> [Wed Aug 03 09:04:58 2011] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 >>> [Wed Aug 03 09:04:58 2011] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) >>> [Wed Aug 03 09:04:58 2011] [notice] Digest: generating secret for digest authentication ... >>> [Wed Aug 03 09:04:58 2011] [notice] Digest: done >>> [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Compiled for Python/2.6.2. >>> [Wed Aug 03 09:04:58 2011] [warn] mod_wsgi: Runtime using Python/2.6.6. >>> [Wed Aug 03 09:04:59 2011] [notice] Apache/2.2.15 (Unix) DAV/2 mod_auth_kerb/5.4 mod_nss/2.2.15 NSS/3.12.9.0 mod_wsgi/3.2 Python/2.6.6 configured -- resuming normal operations >>> [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** >>> [Wed Aug 03 09:05:01 2011] [error] ipa: INFO: *** PROCESS START *** >>> ========== >>> >>> >>> regards >>> >>> Steven Jones >>> >>> Technical Specialist - Linux RHCE >>> >>> Victoria University, Wellington, NZ >>> >>> 0064 4 463 6272 >>> >>> ________________________________________ >>> From: Rob Crittenden [rcritten at redhat.com] >>> Sent: Wednesday, 3 August 2011 1:48 a.m. >>> To: Steven Jones >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] version mismatch while joining a client ? >>> >>> Steven Jones wrote: >>>> >>>> Yes....enrolement now fails, previous messages I attached show that I think, it used to work. >>>> >>>> History, I had to remove all my working IPA clients due to a disk space problem on our SAN (we didnt have any). So I managed to keep the working IPA server and 2 x RHEL5 64 bit servers and the one un-configured template of RHEL6.1 64bit client I had. This I used to make client side clones off previously and connected them to IPA server and they worked. >>>> >>>> So lastweek I went back and with a running ipa server, I cloned in the old client/template and got the mis-match, so I put them on the production network and patched, same mismatch problem. >>>> >>>> I can do a sosreport of the old template I think and the client to look at the differences if that helps. >>> >>> I'm having a hard time following exactly what you are doing, on what >>> machine. I think we need to be more systematic. >>> >>> Can you choose a machine to act as the client and provide the following: >>> >>> - distro and architecture (e.g. RHEL 6.1 on x86_64) >>> - rpm -q curl libcurl >>> - rpm -q ipa-client >>> >>> On the IPA server: >>> - rpm -q ipa-server >>> >>> Start with a client that is not enrolled. If it has previously been >>> enrolled run: ipa-client-install --uninstall -U >>> >>> Now run ipa-client-install and answer the questions as appropriate for >>> your install. >>> >>> If it fails please provide the following: >>> - any stdout you get from the client install >>> - attach the full /var/log/ipaclient-install.log >>> - attach the last 100 lines from /var/log/httpd/error_log from the IPA >>> server >>> >>> rob >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > From simo at redhat.com Fri Aug 5 11:59:09 2011 From: simo at redhat.com (Simo Sorce) Date: Fri, 05 Aug 2011 07:59:09 -0400 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40369E10C7@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <4E2EC378.9050401@romal.de> , <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E307F91.10309@redhat.com> , <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E380026.5000707@redhat.com> , <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E0285@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E3A9DAB.30901@redhat.com> , <833D8E48405E064EBC54C84EC6B36E40369E0FE4@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E1007@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E3B190B.9050502@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369E10C7@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <1312545549.11512.31.camel@willson.li.ssimo.org> On Thu, 2011-08-04 at 23:32 +0000, Steven Jones wrote: > I think you mean 04? > > I am getting a sasl failed. Have you installed i686 packages on a x86_64 machine ? -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Aug 5 19:29:16 2011 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 05 Aug 2011 15:29:16 -0400 Subject: [Freeipa-users] Clarification about FreeIPA milestones Message-ID: <4E3C448C.3000605@redhat.com> Hello, IPA 2.1 is getting close to its release so it is time to set some expectations and explain our roadmap moving forward a little bit. First it is planned to have couple bug fixing iterations on top of 2.1. That translates into 2.1.1 and 2.1.2 milestones respectfully. We do not plan to do any point releases after 2.1 on the same code base. We will maintain this code for some time doing fixes and back porting from the tip but we do not plan to have 2.2 release from it. The next release will be a major release. It will be 3.0. There will be two separate parallel teams contributing to this release. One team is focusing on the cross kerberos trust effort and another on the core enhancements effort. There is not much overlap between the two so the tracking purposes it is easier to create independent milestones for the two teams. The milestones are named "Core effort" and "Trust effort" respectfully. Each will have its own backlog - a general pool of things to do and then individual iterations that are more or less aligned by the month boundaries. We will try to deliver some meaningful features every month but there is no guarantee that there will a build to play with every month as a result of the particular iteration. The former 2.2 bucket was renamed into 3.0 Core Effort Backlog bucket. Next step is to select a subset of those tickets to address during the September iteration. Since this iteration will have an overlap with the 2.1.x bug fixing effort we do not expect to accomplish much and yet we expect that the effort would start and some of the initial design and prototyping steps will be complete. Finally, you can take a look at the specific tickets in the IPA trac to read in more details about the features we plan to work on but here is a high level overview: * Trust effort - it is all about cross kerberos trust between AD and IPA and support of different use cases that would allow AD users to access IPA resources and vice verse. * Core effort - is it about incremental improvements to IPA. We will be looking at key management features, SELinux user context assignments, more Dogtag integration, UI improvements and other security and usability enhancements. The driving factor is the Trust effort. As soon as it is ready we will start preparing a release. The features from the Core effort would be included on the as available basis. Hope this helps... -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ayoung at redhat.com Fri Aug 5 21:17:27 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 05 Aug 2011 17:17:27 -0400 Subject: [Freeipa-users] Clarification about FreeIPA milestones In-Reply-To: <4E3C448C.3000605@redhat.com> References: <4E3C448C.3000605@redhat.com> Message-ID: <4E3C5DE7.7000200@redhat.com> On 08/05/2011 03:29 PM, Dmitri Pal wrote: > Hello, > > IPA 2.1 is getting close to its release so it is time to set some > expectations and explain our roadmap moving forward a little bit. > First it is planned to have couple bug fixing iterations on top of 2.1. > That translates into 2.1.1 and 2.1.2 milestones respectfully. > We do not plan to do any point releases after 2.1 on the same code base. > We will maintain this code for some time doing fixes and back porting > from the tip but we do not plan to have 2.2 release from it. > > The next release will be a major release. It will be 3.0. There will be > two separate parallel teams contributing to this release. > One team is focusing on the cross kerberos trust effort and another on > the core enhancements effort. > There is not much overlap between the two so the tracking purposes it is > easier to create independent milestones for the two teams. The > milestones are named "Core effort" and "Trust effort" respectfully. Each > will have its own backlog - a general pool of things to do and then > individual iterations that are more or less aligned by the month > boundaries. We will try to deliver some meaningful features every month > but there is no guarantee that there will a build to play with every > month as a result of the particular iteration. Will either of these efforts include enhanced UI? I can certainly see something for configuring cross domain trusts ending up under the policy tab. I'm not too up to speed on what the Core effort is doing. The one concern I have is that the UI team is going to want to continue to refine what we already have. Should it target either core or trust as the main place to develop against, or will we try to keep the UI base in sync with both trees? From dpal at redhat.com Fri Aug 5 21:38:33 2011 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 05 Aug 2011 17:38:33 -0400 Subject: [Freeipa-users] Clarification about FreeIPA milestones In-Reply-To: <4E3C5DE7.7000200@redhat.com> References: <4E3C448C.3000605@redhat.com> <4E3C5DE7.7000200@redhat.com> Message-ID: <4E3C62D9.7020009@redhat.com> On 08/05/2011 05:17 PM, Adam Young wrote: > On 08/05/2011 03:29 PM, Dmitri Pal wrote: >> Hello, >> >> IPA 2.1 is getting close to its release so it is time to set some >> expectations and explain our roadmap moving forward a little bit. >> First it is planned to have couple bug fixing iterations on top of 2.1. >> That translates into 2.1.1 and 2.1.2 milestones respectfully. >> We do not plan to do any point releases after 2.1 on the same code base. >> We will maintain this code for some time doing fixes and back porting >> from the tip but we do not plan to have 2.2 release from it. >> >> The next release will be a major release. It will be 3.0. There will be >> two separate parallel teams contributing to this release. >> One team is focusing on the cross kerberos trust effort and another on >> the core enhancements effort. >> There is not much overlap between the two so the tracking purposes it is >> easier to create independent milestones for the two teams. The >> milestones are named "Core effort" and "Trust effort" respectfully. Each >> will have its own backlog - a general pool of things to do and then >> individual iterations that are more or less aligned by the month >> boundaries. We will try to deliver some meaningful features every month >> but there is no guarantee that there will a build to play with every >> month as a result of the particular iteration. > > Will either of these efforts include enhanced UI? I can certainly see > something for configuring cross domain trusts ending up under the > policy tab. I'm not too up to speed on what the Core effort is doing. > > The one concern I have is that the UI team is going to want to > continue to refine what we already have. Should it target either core > or trust as the main place to develop against, or will we try to keep > the UI base in sync with both trees? > > There will be new panels in UI for either effort but stylistically and conceptually the existing screens and approaches should act as the guidance. If something drastically new comes up Adam or Endi will be involved. > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ijstokes at hkl.hms.harvard.edu Sat Aug 6 08:43:03 2011 From: ijstokes at hkl.hms.harvard.edu (Ian Stokes-Rees) Date: Sat, 06 Aug 2011 17:43:03 +0900 Subject: [Freeipa-users] Clarification about FreeIPA milestones In-Reply-To: <4E3C448C.3000605@redhat.com> References: <4E3C448C.3000605@redhat.com> Message-ID: <4E3CFE97.1040709@hkl.hms.harvard.edu> On 8/6/11 4:29 AM, Dmitri Pal wrote: > IPA 2.1 is getting close to its release so it is time to set some > expectations and explain our roadmap moving forward a little bit. > First it is planned to have couple bug fixing iterations on top of 2.1. > That translates into 2.1.1 and 2.1.2 milestones respectfully. > We do not plan to do any point releases after 2.1 on the same code base. > We will maintain this code for some time doing fixes and back porting > from the tip but we do not plan to have 2.2 release from it. > > The next release will be a major release. It will be 3.0. Can you clarify from your comments about "not from the same code base" if you mean v3.0 will be yet another re-write as v2.0 was? What is your estimated date for a v3.0 release? Thanks, Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ijstokes.vcf Type: text/x-vcard Size: 380 bytes Desc: not available URL: From sbingram at gmail.com Sat Aug 6 19:18:03 2011 From: sbingram at gmail.com (Stephen Ingram) Date: Sat, 6 Aug 2011 12:18:03 -0700 Subject: [Freeipa-users] extending FreeIPA In-Reply-To: <4DC455F7.5070000@redhat.com> References: <1304686170.14451.25.camel@willson.li.ssimo.org> <4DC455F7.5070000@redhat.com> Message-ID: On Fri, May 6, 2011 at 1:11 PM, Adam Young wrote: > On 05/06/2011 08:49 AM, Simo Sorce wrote: >> >> On Wed, 2011-05-04 at 17:41 -0700, Stephen Ingram wrote: >>> >>> I currently maintain a directory with MTA configuration data in it >>> (among other items). I'm wondering what is the best way to add to the >>> FreeIPA schema without stepping on current and future schema additions >>> that might conflict with what I add. I know at one time you were >>> expecting to add information for Postfix and other common server >>> programs. Was this schema ever prepared and agreed upon, or is it best >>> to use some special branch to put this all under? >> >> Ok it seem we are confusing 2 things here, on one side schema extensions >> (new attributes and objectclasses) and on the other side DIT structure >> (subtrees within the tree where to put your information). >> >> If you use standard schema or schema you made yourself after you got >> assigned a base OID there should be no issue at all. if you do your own >> schema please be careful in trying to use a prefix for attribute and >> objectclass names so that you do not risk future name conflicts). >> >> For the DIT part it really depends on what you need to do. >> If you just need to add attributes to users then you have no other >> option but to attach them to the users and that's fine it shouldn't >> cause any issue. >> >> If you need to add entirely new objects I can suggest to create a >> cn=custom container as a top level subtree (ie at the same level of >> cn=accounts and cn=etc, ... >> >> And within it do what you need to do. This way it will not conflict with >> anything we may add in future. >> >>> Also, although I read Adam Young's blog article about how to extend >>> the WebUI, I'm having difficulty adding attributes within the existing >>> structure. For example, on the user page, is there a prescribed way of >>> adding say, the mailAlternateAddress attribute such that it shows as a >>> field in the WebUI? > > The rule is that ?you need to be able to do it in the CLI first, and then > attempt it in the WebUI. ?The attribute you are attmpeting to access needs > to be added to the user object in freeipa/ipalib/plugins/user.py ?first. > ?Once you have that, you can add it to the ui ?just like email address: > > ?{factory: IPA.multivalued_text_widget, name:'mail'}, > > > However, ?mail is already a multivalued attribute. ?You can store multiple > email addresses there if you want, and that is the intention. ?If you want > to make these both single value fields, change it to: > ?fields: > ? ? ? ? ? ? ? ?[ ?"mail","mailalternateaddress", > ? ? ? ? ? ? ? ? ? {factory: IPA.multivalued_text_widget, > name:'telephonenumber'},... Off on another project for awhile, but I finally had a chance to attack this. Yes, I did have to make mailalternateaddress a separate attribute as I need to be able to search the directory for this and treat it differently than an email address (or multiple email addresses). After a nasty browser caching problem, I got everything to work. This is great! I'm a little weak in the javascript department, but with your instructions above and here (https://www.redhat.com/archives/freeipa-users/2011-June/msg00192.html) I was able to edit everything and make it work! The CLI worked great too. I could not believe it when I saw the command line options change (even in help) to reflect the added attribute. This is so unbelievably cool. The only problem I'm having is that if there is no attribute entry to begin with (I added the first mailalternateaddress with the command line after the changes), there is no "Add" link in the UI next to the attribute like on the Email address. Is there something that has to be done to get this to appear? Note that the "Delete" link and "Add" link does appear if there is already a value for the attribute. Steve From sbingram at gmail.com Sat Aug 6 20:29:51 2011 From: sbingram at gmail.com (Stephen Ingram) Date: Sat, 6 Aug 2011 13:29:51 -0700 Subject: [Freeipa-users] extending FreeIPA In-Reply-To: References: <1304686170.14451.25.camel@willson.li.ssimo.org> <4DC455F7.5070000@redhat.com> Message-ID: On Sat, Aug 6, 2011 at 12:18 PM, Stephen Ingram wrote: > On Fri, May 6, 2011 at 1:11 PM, Adam Young wrote: >> On 05/06/2011 08:49 AM, Simo Sorce wrote: >>> >>> On Wed, 2011-05-04 at 17:41 -0700, Stephen Ingram wrote: >>>> >>>> I currently maintain a directory with MTA configuration data in it >>>> (among other items). I'm wondering what is the best way to add to the >>>> FreeIPA schema without stepping on current and future schema additions >>>> that might conflict with what I add. I know at one time you were >>>> expecting to add information for Postfix and other common server >>>> programs. Was this schema ever prepared and agreed upon, or is it best >>>> to use some special branch to put this all under? >>> >>> Ok it seem we are confusing 2 things here, on one side schema extensions >>> (new attributes and objectclasses) and on the other side DIT structure >>> (subtrees within the tree where to put your information). >>> >>> If you use standard schema or schema you made yourself after you got >>> assigned a base OID there should be no issue at all. if you do your own >>> schema please be careful in trying to use a prefix for attribute and >>> objectclass names so that you do not risk future name conflicts). >>> >>> For the DIT part it really depends on what you need to do. >>> If you just need to add attributes to users then you have no other >>> option but to attach them to the users and that's fine it shouldn't >>> cause any issue. >>> >>> If you need to add entirely new objects I can suggest to create a >>> cn=custom container as a top level subtree (ie at the same level of >>> cn=accounts and cn=etc, ... >>> >>> And within it do what you need to do. This way it will not conflict with >>> anything we may add in future. >>> >>>> Also, although I read Adam Young's blog article about how to extend >>>> the WebUI, I'm having difficulty adding attributes within the existing >>>> structure. For example, on the user page, is there a prescribed way of >>>> adding say, the mailAlternateAddress attribute such that it shows as a >>>> field in the WebUI? >> >> The rule is that ?you need to be able to do it in the CLI first, and then >> attempt it in the WebUI. ?The attribute you are attmpeting to access needs >> to be added to the user object in freeipa/ipalib/plugins/user.py ?first. >> ?Once you have that, you can add it to the ui ?just like email address: >> >> ?{factory: IPA.multivalued_text_widget, name:'mail'}, >> >> >> However, ?mail is already a multivalued attribute. ?You can store multiple >> email addresses there if you want, and that is the intention. ?If you want >> to make these both single value fields, change it to: >> ?fields: >> ? ? ? ? ? ? ? ?[ ?"mail","mailalternateaddress", >> ? ? ? ? ? ? ? ? ? {factory: IPA.multivalued_text_widget, >> name:'telephonenumber'},... > > > Off on another project for awhile, but I finally had a chance to > attack this. Yes, I did have to make mailalternateaddress a separate > attribute as I need to be able to search the directory for this and > treat it differently than an email address (or multiple email > addresses). After a nasty browser caching problem, I got everything to > work. This is great! I'm a little weak in the javascript department, > but with your instructions above and here > (https://www.redhat.com/archives/freeipa-users/2011-June/msg00192.html) > I was able to edit everything and make it work! The CLI worked great > too. I could not believe it when I saw the command line options change > (even in help) to reflect the added attribute. This is so unbelievably > cool. > > The only problem I'm having is that if there is no attribute entry to > begin with (I added the first mailalternateaddress with the command > line after the changes), there is no "Add" link in the UI next to the > attribute like on the Email address. Is there something that has to be > done to get this to appear? Note that the "Delete" link and "Add" link > does appear if there is already a value for the attribute. Please just disregard this last problem. The correct objectclass was missing from the directory entry. It works perfectly now. Steve From jdennis at redhat.com Sat Aug 6 23:05:58 2011 From: jdennis at redhat.com (John Dennis) Date: Sat, 06 Aug 2011 19:05:58 -0400 Subject: [Freeipa-users] Clarification about FreeIPA milestones In-Reply-To: <4E3CFE97.1040709@hkl.hms.harvard.edu> References: <4E3C448C.3000605@redhat.com> <4E3CFE97.1040709@hkl.hms.harvard.edu> Message-ID: <4E3DC8D6.60903@redhat.com> On 08/06/2011 04:43 AM, Ian Stokes-Rees wrote: > > > On 8/6/11 4:29 AM, Dmitri Pal wrote: >> IPA 2.1 is getting close to its release so it is time to set some >> expectations and explain our roadmap moving forward a little bit. >> First it is planned to have couple bug fixing iterations on top of 2.1. >> That translates into 2.1.1 and 2.1.2 milestones respectfully. >> We do not plan to do any point releases after 2.1 on the same code base. >> We will maintain this code for some time doing fixes and back porting >> from the tip but we do not plan to have 2.2 release from it. >> >> The next release will be a major release. It will be 3.0. > > Can you clarify from your comments about "not from the same code base" > if you mean v3.0 will be yet another re-write as v2.0 was? The comment refers to our source code branching, 2.1 is being frozen. There are no plans for a rewrite, just incremental improvements and feature additions. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Sun Aug 7 19:40:23 2011 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 07 Aug 2011 15:40:23 -0400 Subject: [Freeipa-users] Clarification about FreeIPA milestones In-Reply-To: <4E3DC8D6.60903@redhat.com> References: <4E3C448C.3000605@redhat.com> <4E3CFE97.1040709@hkl.hms.harvard.edu> <4E3DC8D6.60903@redhat.com> Message-ID: <4E3EEA27.9070807@redhat.com> On 08/06/2011 07:05 PM, John Dennis wrote: > On 08/06/2011 04:43 AM, Ian Stokes-Rees wrote: >> >> >> On 8/6/11 4:29 AM, Dmitri Pal wrote: >>> IPA 2.1 is getting close to its release so it is time to set some >>> expectations and explain our roadmap moving forward a little bit. >>> First it is planned to have couple bug fixing iterations on top of 2.1. >>> That translates into 2.1.1 and 2.1.2 milestones respectfully. >>> We do not plan to do any point releases after 2.1 on the same code >>> base. >>> We will maintain this code for some time doing fixes and back porting >>> from the tip but we do not plan to have 2.2 release from it. >>> >>> The next release will be a major release. It will be 3.0. >> >> Can you clarify from your comments about "not from the same code base" >> if you mean v3.0 will be yet another re-write as v2.0 was? > > The comment refers to our source code branching, 2.1 is being frozen. > There are no plans for a rewrite, just incremental improvements and > feature additions. > I echo what John said. This means that 2.1 branch will be in the maintenance mode and all the active development will happen on the master which later produce the new 3.0 release. It is not a rewrite, it is just a lot of new functionality. During last 9 months our effort was mostly focused on stabilizing and cleaning the functionality we planned to deliver and we have not done any new major features. Now master branch is going to be open for such features. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Sun Aug 7 20:26:27 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Sun, 7 Aug 2011 20:26:27 +0000 Subject: [Freeipa-users] version mismatch while joining a client ? In-Reply-To: <1312545549.11512.31.camel@willson.li.ssimo.org> References: <4E2EC378.9050401@romal.de> , <833D8E48405E064EBC54C84EC6B36E40369C9545@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E307F91.10309@redhat.com> , <833D8E48405E064EBC54C84EC6B36E40369CA01E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369CA033@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E31DFFE.9040209@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369CAEFB@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E36A5C8.3030401@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DDFD4@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E3711CB.3060604@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369DE4B9@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E380026.5000707@redhat.com> , <833D8E48405E064EBC54C84EC6B36E40369DF7EF@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E0285@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E3A9DAB.30901@redhat.com> , <833D8E48405E064EBC54C84EC6B36E40369E0FE4@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40369E1007@STAWINCOX10MBX1.staff.vuw.ac.nz> , <4E3B190B.9050502@redhat.com> <833D8E48405E064EBC54C84EC6B36E40369E10C7@STAWINCOX10MBX1.staff.vuw.ac.nz>, <1312545549.11512.31.camel@willson.li.ssimo.org> Message-ID: <833D8E48405E064EBC54C84EC6B36E403A437C5E@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Only if yum did it by itself.....I simply do yum -y install regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Simo Sorce [simo at redhat.com] Sent: Friday, 5 August 2011 11:59 p.m. To: Steven Jones Cc: Rob Crittenden; freeipa-users at redhat.com Subject: Re: [Freeipa-users] version mismatch while joining a client ? On Thu, 2011-08-04 at 23:32 +0000, Steven Jones wrote: > I think you mean 04? > > I am getting a sasl failed. Have you installed i686 packages on a x86_64 machine ? -- Simo Sorce * Red Hat, Inc * New York From ayoung at redhat.com Mon Aug 8 00:25:55 2011 From: ayoung at redhat.com (Adam Young) Date: Sun, 07 Aug 2011 20:25:55 -0400 Subject: [Freeipa-users] extending FreeIPA In-Reply-To: References: <1304686170.14451.25.camel@willson.li.ssimo.org> <4DC455F7.5070000@redhat.com> Message-ID: <4E3F2D13.5090403@redhat.com> On 08/06/2011 03:18 PM, Stephen Ingram wrote: > On Fri, May 6, 2011 at 1:11 PM, Adam Young wrote: >> On 05/06/2011 08:49 AM, Simo Sorce wrote: >>> On Wed, 2011-05-04 at 17:41 -0700, Stephen Ingram wrote: >>>> I currently maintain a directory with MTA configuration data in it >>>> (among other items). I'm wondering what is the best way to add to the >>>> FreeIPA schema without stepping on current and future schema additions >>>> that might conflict with what I add. I know at one time you were >>>> expecting to add information for Postfix and other common server >>>> programs. Was this schema ever prepared and agreed upon, or is it best >>>> to use some special branch to put this all under? >>> Ok it seem we are confusing 2 things here, on one side schema extensions >>> (new attributes and objectclasses) and on the other side DIT structure >>> (subtrees within the tree where to put your information). >>> >>> If you use standard schema or schema you made yourself after you got >>> assigned a base OID there should be no issue at all. if you do your own >>> schema please be careful in trying to use a prefix for attribute and >>> objectclass names so that you do not risk future name conflicts). >>> >>> For the DIT part it really depends on what you need to do. >>> If you just need to add attributes to users then you have no other >>> option but to attach them to the users and that's fine it shouldn't >>> cause any issue. >>> >>> If you need to add entirely new objects I can suggest to create a >>> cn=custom container as a top level subtree (ie at the same level of >>> cn=accounts and cn=etc, ... >>> >>> And within it do what you need to do. This way it will not conflict with >>> anything we may add in future. >>> >>>> Also, although I read Adam Young's blog article about how to extend >>>> the WebUI, I'm having difficulty adding attributes within the existing >>>> structure. For example, on the user page, is there a prescribed way of >>>> adding say, the mailAlternateAddress attribute such that it shows as a >>>> field in the WebUI? >> The rule is that you need to be able to do it in the CLI first, and then >> attempt it in the WebUI. The attribute you are attmpeting to access needs >> to be added to the user object in freeipa/ipalib/plugins/user.py first. >> Once you have that, you can add it to the ui just like email address: >> >> {factory: IPA.multivalued_text_widget, name:'mail'}, >> >> >> However, mail is already a multivalued attribute. You can store multiple >> email addresses there if you want, and that is the intention. If you want >> to make these both single value fields, change it to: >> fields: >> [ "mail","mailalternateaddress", >> {factory: IPA.multivalued_text_widget, >> name:'telephonenumber'},... > > Off on another project for awhile, but I finally had a chance to > attack this. Yes, I did have to make mailalternateaddress a separate > attribute as I need to be able to search the directory for this and > treat it differently than an email address (or multiple email > addresses). After a nasty browser caching problem, I got everything to > work. This is great! I'm a little weak in the javascript department, > but with your instructions above and here > (https://www.redhat.com/archives/freeipa-users/2011-June/msg00192.html) > I was able to edit everything and make it work! The CLI worked great > too. I could not believe it when I saw the command line options change > (even in help) to reflect the added attribute. This is so unbelievably > cool. > > The only problem I'm having is that if there is no attribute entry to > begin with (I added the first mailalternateaddress with the command > line after the changes), there is no "Add" link in the UI next to the > attribute like on the Email address. Is there something that has to be > done to get this to appear? Note that the "Delete" link and "Add" link > does appear if there is already a value for the attribute. Sounds like a bug, but to be honest, it is a cod path I haven't gone down. Please file it in trac and we'll investigate. https://fedorahosted.org/freeipa/report/12 > Steve From ayoung at redhat.com Mon Aug 8 00:29:20 2011 From: ayoung at redhat.com (Adam Young) Date: Sun, 07 Aug 2011 20:29:20 -0400 Subject: [Freeipa-users] extending FreeIPA In-Reply-To: References: <1304686170.14451.25.camel@willson.li.ssimo.org> <4DC455F7.5070000@redhat.com> Message-ID: <4E3F2DE0.9000108@redhat.com> On 08/06/2011 04:29 PM, Stephen Ingram wrote: > On Sat, Aug 6, 2011 at 12:18 PM, Stephen Ingram wrote: >> On Fri, May 6, 2011 at 1:11 PM, Adam Young wrote: >>> On 05/06/2011 08:49 AM, Simo Sorce wrote: >>>> On Wed, 2011-05-04 at 17:41 -0700, Stephen Ingram wrote: >>>>> I currently maintain a directory with MTA configuration data in it >>>>> (among other items). I'm wondering what is the best way to add to the >>>>> FreeIPA schema without stepping on current and future schema additions >>>>> that might conflict with what I add. I know at one time you were >>>>> expecting to add information for Postfix and other common server >>>>> programs. Was this schema ever prepared and agreed upon, or is it best >>>>> to use some special branch to put this all under? >>>> Ok it seem we are confusing 2 things here, on one side schema extensions >>>> (new attributes and objectclasses) and on the other side DIT structure >>>> (subtrees within the tree where to put your information). >>>> >>>> If you use standard schema or schema you made yourself after you got >>>> assigned a base OID there should be no issue at all. if you do your own >>>> schema please be careful in trying to use a prefix for attribute and >>>> objectclass names so that you do not risk future name conflicts). >>>> >>>> For the DIT part it really depends on what you need to do. >>>> If you just need to add attributes to users then you have no other >>>> option but to attach them to the users and that's fine it shouldn't >>>> cause any issue. >>>> >>>> If you need to add entirely new objects I can suggest to create a >>>> cn=custom container as a top level subtree (ie at the same level of >>>> cn=accounts and cn=etc, ... >>>> >>>> And within it do what you need to do. This way it will not conflict with >>>> anything we may add in future. >>>> >>>>> Also, although I read Adam Young's blog article about how to extend >>>>> the WebUI, I'm having difficulty adding attributes within the existing >>>>> structure. For example, on the user page, is there a prescribed way of >>>>> adding say, the mailAlternateAddress attribute such that it shows as a >>>>> field in the WebUI? >>> The rule is that you need to be able to do it in the CLI first, and then >>> attempt it in the WebUI. The attribute you are attmpeting to access needs >>> to be added to the user object in freeipa/ipalib/plugins/user.py first. >>> Once you have that, you can add it to the ui just like email address: >>> >>> {factory: IPA.multivalued_text_widget, name:'mail'}, >>> >>> >>> However, mail is already a multivalued attribute. You can store multiple >>> email addresses there if you want, and that is the intention. If you want >>> to make these both single value fields, change it to: >>> fields: >>> [ "mail","mailalternateaddress", >>> {factory: IPA.multivalued_text_widget, >>> name:'telephonenumber'},... >> >> Off on another project for awhile, but I finally had a chance to >> attack this. Yes, I did have to make mailalternateaddress a separate >> attribute as I need to be able to search the directory for this and >> treat it differently than an email address (or multiple email >> addresses). After a nasty browser caching problem, I got everything to >> work. This is great! I'm a little weak in the javascript department, >> but with your instructions above and here >> (https://www.redhat.com/archives/freeipa-users/2011-June/msg00192.html) >> I was able to edit everything and make it work! The CLI worked great >> too. I could not believe it when I saw the command line options change >> (even in help) to reflect the added attribute. This is so unbelievably >> cool. >> >> The only problem I'm having is that if there is no attribute entry to >> begin with (I added the first mailalternateaddress with the command >> line after the changes), there is no "Add" link in the UI next to the >> attribute like on the Email address. Is there something that has to be >> done to get this to appear? Note that the "Delete" link and "Add" link >> does appear if there is already a value for the attribute. > Please just disregard this last problem. The correct objectclass was > missing from the directory entry. It works perfectly now. > > Steve Glad to hear it. Interesting failure case. From sbingram at gmail.com Mon Aug 8 06:07:31 2011 From: sbingram at gmail.com (Stephen Ingram) Date: Sun, 7 Aug 2011 23:07:31 -0700 Subject: [Freeipa-users] extending FreeIPA In-Reply-To: <4E3F2DE0.9000108@redhat.com> References: <1304686170.14451.25.camel@willson.li.ssimo.org> <4DC455F7.5070000@redhat.com> <4E3F2DE0.9000108@redhat.com> Message-ID: Adam- I'm sorry I was less than clear. There is no problem with IPA. I was adding an attribute that was in a non-IPA-included objectclass. Since it was included in the 389 ds schema, it was easy to add it in the cn=ipaConfig,cn=etc,dc=domain,dc=tld ipaUserObjectClasses attribute using a directory browser and it works great now. Question though, is there some reason that you can't browse the rest of the directory tree now like you could some parts in v1? I know it probably takes away from the clean simplicity of the UI, but it would be really neat if you could maybe access through an "Advanced" button or such. You've created such an outstanding interface to the rest of the directory--I would be so excited to be able to browse the hidden parts as well using the same great UI. Steve On Sun, Aug 7, 2011 at 5:29 PM, Adam Young wrote: > On 08/06/2011 04:29 PM, Stephen Ingram wrote: >> >> On Sat, Aug 6, 2011 at 12:18 PM, Stephen Ingram >> ?wrote: >>> >>> On Fri, May 6, 2011 at 1:11 PM, Adam Young ?wrote: >>>> >>>> On 05/06/2011 08:49 AM, Simo Sorce wrote: >>>>> >>>>> On Wed, 2011-05-04 at 17:41 -0700, Stephen Ingram wrote: >>>>>> >>>>>> I currently maintain a directory with MTA configuration data in it >>>>>> (among other items). I'm wondering what is the best way to add to the >>>>>> FreeIPA schema without stepping on current and future schema additions >>>>>> that might conflict with what I add. I know at one time you were >>>>>> expecting to add information for Postfix and other common server >>>>>> programs. Was this schema ever prepared and agreed upon, or is it best >>>>>> to use some special branch to put this all under? >>>>> >>>>> Ok it seem we are confusing 2 things here, on one side schema >>>>> extensions >>>>> (new attributes and objectclasses) and on the other side DIT structure >>>>> (subtrees within the tree where to put your information). >>>>> >>>>> If you use standard schema or schema you made yourself after you got >>>>> assigned a base OID there should be no issue at all. if you do your own >>>>> schema please be careful in trying to use a prefix for attribute and >>>>> objectclass names so that you do not risk future name conflicts). >>>>> >>>>> For the DIT part it really depends on what you need to do. >>>>> If you just need to add attributes to users then you have no other >>>>> option but to attach them to the users and that's fine it shouldn't >>>>> cause any issue. >>>>> >>>>> If you need to add entirely new objects I can suggest to create a >>>>> cn=custom container as a top level subtree (ie at the same level of >>>>> cn=accounts and cn=etc, ... >>>>> >>>>> And within it do what you need to do. This way it will not conflict >>>>> with >>>>> anything we may add in future. >>>>> >>>>>> Also, although I read Adam Young's blog article about how to extend >>>>>> the WebUI, I'm having difficulty adding attributes within the existing >>>>>> structure. For example, on the user page, is there a prescribed way of >>>>>> adding say, the mailAlternateAddress attribute such that it shows as a >>>>>> field in the WebUI? >>>> >>>> The rule is that ?you need to be able to do it in the CLI first, and >>>> then >>>> attempt it in the WebUI. ?The attribute you are attmpeting to access >>>> needs >>>> to be added to the user object in freeipa/ipalib/plugins/user.py ?first. >>>> ?Once you have that, you can add it to the ui ?just like email address: >>>> >>>> ?{factory: IPA.multivalued_text_widget, name:'mail'}, >>>> >>>> >>>> However, ?mail is already a multivalued attribute. ?You can store >>>> multiple >>>> email addresses there if you want, and that is the intention. ?If you >>>> want >>>> to make these both single value fields, change it to: >>>> ?fields: >>>> ? ? ? ? ? ? ? ?[ ?"mail","mailalternateaddress", >>>> ? ? ? ? ? ? ? ? ? {factory: IPA.multivalued_text_widget, >>>> name:'telephonenumber'},... >>> >>> Off on another project for awhile, but I finally had a chance to >>> attack this. Yes, I did have to make mailalternateaddress a separate >>> attribute as I need to be able to search the directory for this and >>> treat it differently than an email address (or multiple email >>> addresses). After a nasty browser caching problem, I got everything to >>> work. This is great! I'm a little weak in the javascript department, >>> but with your instructions above and here >>> (https://www.redhat.com/archives/freeipa-users/2011-June/msg00192.html) >>> I was able to edit everything and make it work! The CLI worked great >>> too. I could not believe it when I saw the command line options change >>> (even in help) to reflect the added attribute. This is so unbelievably >>> cool. >>> >>> The only problem I'm having is that if there is no attribute entry to >>> begin with (I added the first mailalternateaddress with the command >>> line after the changes), there is no "Add" link in the UI next to the >>> attribute like on the Email address. Is there something that has to be >>> done to get this to appear? Note that the "Delete" link and "Add" link >>> does appear if there is already a value for the attribute. >> >> Please just disregard this last problem. The correct objectclass was >> missing from the directory entry. It works perfectly now. >> >> Steve > > Glad to hear it. Interesting failure case. > From dpal at redhat.com Mon Aug 8 16:40:41 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 08 Aug 2011 12:40:41 -0400 Subject: [Freeipa-users] extending FreeIPA In-Reply-To: References: <1304686170.14451.25.camel@willson.li.ssimo.org> <4DC455F7.5070000@redhat.com> <4E3F2DE0.9000108@redhat.com> Message-ID: <4E401189.2070806@redhat.com> On 08/08/2011 02:07 AM, Stephen Ingram wrote: > Adam- > > I'm sorry I was less than clear. There is no problem with IPA. I was > adding an attribute that was in a non-IPA-included objectclass. Since > it was included in the 389 ds schema, it was easy to add it in the > cn=ipaConfig,cn=etc,dc=domain,dc=tld ipaUserObjectClasses attribute > using a directory browser and it works great now. > > Question though, is there some reason that you can't browse the rest > of the directory tree now like you could some parts in v1? I know it > probably takes away from the clean simplicity of the UI, but it would > be really neat if you could maybe access through an "Advanced" button > or such. You've created such an outstanding interface to the rest of > the directory--I would be so excited to be able to browse the hidden > parts as well using the same great UI. We will look at this at some point. https://fedorahosted.org/freeipa/ticket/1588 https://fedorahosted.org/freeipa/ticket/1589 > Steve > > On Sun, Aug 7, 2011 at 5:29 PM, Adam Young wrote: >> On 08/06/2011 04:29 PM, Stephen Ingram wrote: >>> On Sat, Aug 6, 2011 at 12:18 PM, Stephen Ingram >>> wrote: >>>> On Fri, May 6, 2011 at 1:11 PM, Adam Young wrote: >>>>> On 05/06/2011 08:49 AM, Simo Sorce wrote: >>>>>> On Wed, 2011-05-04 at 17:41 -0700, Stephen Ingram wrote: >>>>>>> I currently maintain a directory with MTA configuration data in it >>>>>>> (among other items). I'm wondering what is the best way to add to the >>>>>>> FreeIPA schema without stepping on current and future schema additions >>>>>>> that might conflict with what I add. I know at one time you were >>>>>>> expecting to add information for Postfix and other common server >>>>>>> programs. Was this schema ever prepared and agreed upon, or is it best >>>>>>> to use some special branch to put this all under? >>>>>> Ok it seem we are confusing 2 things here, on one side schema >>>>>> extensions >>>>>> (new attributes and objectclasses) and on the other side DIT structure >>>>>> (subtrees within the tree where to put your information). >>>>>> >>>>>> If you use standard schema or schema you made yourself after you got >>>>>> assigned a base OID there should be no issue at all. if you do your own >>>>>> schema please be careful in trying to use a prefix for attribute and >>>>>> objectclass names so that you do not risk future name conflicts). >>>>>> >>>>>> For the DIT part it really depends on what you need to do. >>>>>> If you just need to add attributes to users then you have no other >>>>>> option but to attach them to the users and that's fine it shouldn't >>>>>> cause any issue. >>>>>> >>>>>> If you need to add entirely new objects I can suggest to create a >>>>>> cn=custom container as a top level subtree (ie at the same level of >>>>>> cn=accounts and cn=etc, ... >>>>>> >>>>>> And within it do what you need to do. This way it will not conflict >>>>>> with >>>>>> anything we may add in future. >>>>>> >>>>>>> Also, although I read Adam Young's blog article about how to extend >>>>>>> the WebUI, I'm having difficulty adding attributes within the existing >>>>>>> structure. For example, on the user page, is there a prescribed way of >>>>>>> adding say, the mailAlternateAddress attribute such that it shows as a >>>>>>> field in the WebUI? >>>>> The rule is that you need to be able to do it in the CLI first, and >>>>> then >>>>> attempt it in the WebUI. The attribute you are attmpeting to access >>>>> needs >>>>> to be added to the user object in freeipa/ipalib/plugins/user.py first. >>>>> Once you have that, you can add it to the ui just like email address: >>>>> >>>>> {factory: IPA.multivalued_text_widget, name:'mail'}, >>>>> >>>>> >>>>> However, mail is already a multivalued attribute. You can store >>>>> multiple >>>>> email addresses there if you want, and that is the intention. If you >>>>> want >>>>> to make these both single value fields, change it to: >>>>> fields: >>>>> [ "mail","mailalternateaddress", >>>>> {factory: IPA.multivalued_text_widget, >>>>> name:'telephonenumber'},... >>>> Off on another project for awhile, but I finally had a chance to >>>> attack this. Yes, I did have to make mailalternateaddress a separate >>>> attribute as I need to be able to search the directory for this and >>>> treat it differently than an email address (or multiple email >>>> addresses). After a nasty browser caching problem, I got everything to >>>> work. This is great! I'm a little weak in the javascript department, >>>> but with your instructions above and here >>>> (https://www.redhat.com/archives/freeipa-users/2011-June/msg00192.html) >>>> I was able to edit everything and make it work! The CLI worked great >>>> too. I could not believe it when I saw the command line options change >>>> (even in help) to reflect the added attribute. This is so unbelievably >>>> cool. >>>> >>>> The only problem I'm having is that if there is no attribute entry to >>>> begin with (I added the first mailalternateaddress with the command >>>> line after the changes), there is no "Add" link in the UI next to the >>>> attribute like on the Email address. Is there something that has to be >>>> done to get this to appear? Note that the "Delete" link and "Add" link >>>> does appear if there is already a value for the attribute. >>> Please just disregard this last problem. The correct objectclass was >>> missing from the directory entry. It works perfectly now. >>> >>> Steve >> Glad to hear it. Interesting failure case. >> > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Tue Aug 9 03:07:17 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 9 Aug 2011 03:07:17 +0000 Subject: [Freeipa-users] ETA on the libcurl fix? Message-ID: <833D8E48405E064EBC54C84EC6B36E403B3D0F53@STAWINCOX10MBX1.staff.vuw.ac.nz> regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From jdennis at redhat.com Tue Aug 9 04:06:07 2011 From: jdennis at redhat.com (John Dennis) Date: Tue, 09 Aug 2011 00:06:07 -0400 Subject: [Freeipa-users] ETA on the libcurl fix? In-Reply-To: <833D8E48405E064EBC54C84EC6B36E403B3D0F53@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E403B3D0F53@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <4E40B22F.4050507@redhat.com> I believe the fix was incorporated into this RPM, curl-7.21.3-9.fc15 and was pushed into the stable update at 2011-08-09 01:29:07 xmlrpc-c is dependent on libcurl and is utilized by IPA. I do not believe there is new version of xmlrpc-c built against the fixed libcurl as of yet but we're expecting it shortly. I would recommend you install the new curl version from F15 updates and I'll appraise you of the status of xmlrpc-c in the morning. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From kirantpatil at gmail.com Tue Aug 9 04:22:42 2011 From: kirantpatil at gmail.com (Kiran Patil) Date: Tue, 9 Aug 2011 09:52:42 +0530 Subject: [Freeipa-users] Is it possible FreeIPA for Web Apps SingleSignOn like CAS? In-Reply-To: <4E3AC94D.1060100@redhat.com> References: <4E3AB031.8010209@redhat.com> <4E3AC94D.1060100@redhat.com> Message-ID: > There was no follow up on this so what I am specifically interested is > how CAS server integrates with external servers. Does it have some sort > of pluggable interface like PAM? Even if it does it is probably > implementation specific. So is it just a configuration issue to > configure the auth sources or auth providers like IPA have to actually > build a special provider module? > If it is a config issue it might be something that we can try and > document as a solution. If it requires development I want to understand > what is the cost and benefits. It is unclear how widely CAS is used in > general and is there one most popular implementation that we should > focus on in future. > I found this article "http://www.computerworld.com/s/article/9218973/5_cool_tools_for_cloud_management?taxonomyId=154&pageNumber=1" http://www.symplified.com/main/what-we-do-for-you/products/SSO/ Thanks, Kiran. From jdennis at redhat.com Tue Aug 9 13:38:55 2011 From: jdennis at redhat.com (John Dennis) Date: Tue, 09 Aug 2011 09:38:55 -0400 Subject: [Freeipa-users] ETA on the libcurl fix? In-Reply-To: <4E40B22F.4050507@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E403B3D0F53@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E40B22F.4050507@redhat.com> Message-ID: <4E41386F.4020008@redhat.com> On 08/09/2011 12:06 AM, John Dennis wrote: > I believe the fix was incorporated into this RPM, curl-7.21.3-9.fc15 and > was pushed into the stable update at 2011-08-09 01:29:07 > > xmlrpc-c is dependent on libcurl and is utilized by IPA. I do not > believe there is new version of xmlrpc-c built against the fixed libcurl > as of yet but we're expecting it shortly. It looks like the fix for xmlrpc was applied and built in version xmlrpc-c-1.25.1-1501.svn2077.fc15 built in Koji at 2011-02-08 07:52:36. However that build has not been pushed to Bohdi yet so it's not in an update channel yet, I'll investigate why. > I would recommend you install the new curl version from F15 updates and > I'll appraise you of the status of xmlrpc-c in the morning. I perhaps may have spoken too hastily by recommending you upgrade curl. I'm trying to remember your exact situation, if you downgraded the offending packages and regained a working system via the downgrade you should kept that configuration until both curl and xmlrpc-c are available since they are co-dependent. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Tue Aug 9 20:03:57 2011 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 9 Aug 2011 20:03:57 +0000 Subject: [Freeipa-users] ETA on the libcurl fix? In-Reply-To: <4E41386F.4020008@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E403B3D0F53@STAWINCOX10MBX1.staff.vuw.ac.nz> <4E40B22F.4050507@redhat.com>,<4E41386F.4020008@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E403B3D39A9@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Sorry I meant in the RHEL tree. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: John Dennis [jdennis at redhat.com] Sent: Wednesday, 10 August 2011 1:38 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] ETA on the libcurl fix? On 08/09/2011 12:06 AM, John Dennis wrote: > I believe the fix was incorporated into this RPM, curl-7.21.3-9.fc15 and > was pushed into the stable update at 2011-08-09 01:29:07 > > xmlrpc-c is dependent on libcurl and is utilized by IPA. I do not > believe there is new version of xmlrpc-c built against the fixed libcurl > as of yet but we're expecting it shortly. It looks like the fix for xmlrpc was applied and built in version xmlrpc-c-1.25.1-1501.svn2077.fc15 built in Koji at 2011-02-08 07:52:36. However that build has not been pushed to Bohdi yet so it's not in an update channel yet, I'll investigate why. > I would recommend you install the new curl version from F15 updates and > I'll appraise you of the status of xmlrpc-c in the morning. I perhaps may have spoken too hastily by recommending you upgrade curl. I'm trying to remember your exact situation, if you downgraded the offending packages and regained a working system via the downgrade you should kept that configuration until both curl and xmlrpc-c are available since they are co-dependent. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From niemueller at kbsg.rwth-aachen.de Thu Aug 11 08:14:09 2011 From: niemueller at kbsg.rwth-aachen.de (Tim Niemueller) Date: Thu, 11 Aug 2011 10:14:09 +0200 Subject: [Freeipa-users] Kerberos kew renewal not working Message-ID: <4E438F51.3090700@kbsg.rwth-aachen.de> Hi all. We have setup FreeIPA on a F-15 virtual machine. I'm currently testing with a F-14 client. We would like to keep F-14, as F-15 seems not generally stable enough for wide deployment (graphics issues etc.). I have described the setup a bit at http://www.niemueller.de/blog/id/245, which was possible only through numerous IRC sessions on #freeipa. This issue here seems a little more long-standing, hence the mail this time. I'm having a hard time getting the setup running reliably. Initial login and desktop use works fine. But a typical use case is leaving the desktop running overnight with just the screen locked (there might be stuff running in the background). Now, if I return the next day and try to use the machine the machine is frozen and cannot be used. Tickets have not been renewed, in particular the one for the NFSv4 server protected by Kerbero (sec=krb5). It just expired after 24h. The problem can be recreated quickly with a shorter 5 minute lifetime with the following modifications (on the client). This assumes that you have /home mounted via Kerberos-protected NFSv4 share! In /etc/sssd/sssd.conf: [domain/somedomain] krb5_renewable_lifetime = 14d krb5_renew_interval = 60 krb5_lifetime = 5m [domain/default] krb5_renewable_lifetime = 14d krb5_renew_interval = 60 krb5_lifetime = 5m Then reboot (just restarting sssd does not always show the problem, especially if you had been logged in before). Then login and wait five minutes, the machine freezes, as the NFS key has expired. If you do a klist just before the timeout expires, you see that the keys have not been renewed as expected (but the renewable end time is still way in the future, even if the FreeIPA server default of 7d was not increased). Maybe I need to set some magic flag for rpc.gssd, but I couldn't find it. Is there something I can do on my side to get this working? Or is it a FreeIPA or sssd shortcoming, or even "intended not to work by design"? Ideally, I want to make it possible for users to just keep logged in all the time, so even acquiring new tickets automatically by requesting an intermediate user authentication or just doing it from the screensaver would be great, but I guess with /home mounted I'm pretty much out of luck? Is there alternatively a way to only authenticate the host via krb5, but not the user? In the old days we would simply use IP addresses to allow access. Well, that's bad, but having just the host authenticate to prevent laptop road warriors from snooping around could be just enough for us and avoid user ticket renewal, any idea? Thanks for your input. Tim -- KBSG - Knowledge-Based Systems Group AllemaniACs RoboCup Team ======================================================================== http://robocup.rwth-aachen.de RWTH Aachen University http://kbsg.rwth-aachen.de Ahornstrasse 55 http://www.fawkesrobotics.org D-52056 Aachen From sbose at redhat.com Thu Aug 11 09:19:51 2011 From: sbose at redhat.com (Sumit Bose) Date: Thu, 11 Aug 2011 11:19:51 +0200 Subject: [Freeipa-users] Kerberos kew renewal not working In-Reply-To: <4E438F51.3090700@kbsg.rwth-aachen.de> References: <4E438F51.3090700@kbsg.rwth-aachen.de> Message-ID: <20110811091951.GG2191@localhost.localdomain> adding sssd-devel On Thu, Aug 11, 2011 at 10:14:09AM +0200, Tim Niemueller wrote: > Hi all. > > We have setup FreeIPA on a F-15 virtual machine. I'm currently > testing with a F-14 client. We would like to keep F-14, as F-15 > seems not generally stable enough for wide deployment (graphics > issues etc.). I have described the setup a bit at > http://www.niemueller.de/blog/id/245, which was possible only > through numerous IRC sessions on #freeipa. This issue here seems a > little more long-standing, hence the mail this time. > > I'm having a hard time getting the setup running reliably. Initial > login and desktop use works fine. But a typical use case is leaving > the desktop running overnight with just the screen locked (there > might be stuff running in the background). Now, if I return the next > day and try to use the machine the machine is frozen and cannot be > used. Tickets have not been renewed, in particular the one for the > NFSv4 server protected by Kerbero (sec=krb5). It just expired after > 24h. > > The problem can be recreated quickly with a shorter 5 minute > lifetime with the following modifications (on the client). > > This assumes that you have /home mounted via Kerberos-protected NFSv4 share! > > In /etc/sssd/sssd.conf: > [domain/somedomain] > krb5_renewable_lifetime = 14d > krb5_renew_interval = 60 > krb5_lifetime = 5m > > [domain/default] > krb5_renewable_lifetime = 14d > krb5_renew_interval = 60 > krb5_lifetime = 5m > > Then reboot (just restarting sssd does not always show the problem, > especially if you had been logged in before). > Then login and wait five minutes, the machine freezes, as the NFS > key has expired. If you do a klist just before the timeout expires, > you see that the keys have not been renewed as expected (but the > renewable end time is still way in the future, even if the FreeIPA > server default of 7d was not increased). Maybe I need to set some > magic flag for rpc.gssd, but I couldn't find it. Which version of sssd are you using? Does it work is you manually call 'kinit -R' before the ticket expires? Can you send a sanitized version of the sssd log files with debug_level=9? bye, Sumit > > Is there something I can do on my side to get this working? Or is it > a FreeIPA or sssd shortcoming, or even "intended not to work by > design"? > > Ideally, I want to make it possible for users to just keep logged in > all the time, so even acquiring new tickets automatically by > requesting an intermediate user authentication or just doing it from > the screensaver would be great, but I guess with /home mounted I'm > pretty much out of luck? Is there alternatively a way to only > authenticate the host via krb5, but not the user? In the old days we > would simply use IP addresses to allow access. Well, that's bad, but > having just the host authenticate to prevent laptop road warriors > from snooping around could be just enough for us and avoid user > ticket renewal, any idea? > > Thanks for your input. > Tim > > -- > KBSG - Knowledge-Based Systems Group AllemaniACs RoboCup Team > ======================================================================== > http://robocup.rwth-aachen.de RWTH Aachen University > http://kbsg.rwth-aachen.de Ahornstrasse 55 > http://www.fawkesrobotics.org D-52056 Aachen > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From nock at nocko.org Fri Aug 12 18:06:35 2011 From: nock at nocko.org (Shawn Nock) Date: Fri, 12 Aug 2011 14:06:35 -0400 Subject: [Freeipa-users] Replica Creation hang at "configuring certificate server instance" Message-ID: I am trying to create a replica of my working FreeIPA 2.0.1 installation. Both the server and would-be replica are F15 minimal installs dedicated to FreeIPA. Both hosts are in DNS (forward and reverse) with iptables and selinux temporarily disabled. ipa-replica-install fails at: 2011-08-12 13:48:14,768 DEBUG [3/11]: restarting certificate server 2011-08-12 13:48:17,882 DEBUG args=/sbin/service pki-cad restart 2011-08-12 13:48:17,882 DEBUG stdout=Stopping pki-ca: [FAILED] Starting pki-ca: [ OK ] 'pki-ca' must still be CONFIGURED! (see /var/log/pki-ca-install.log) 2011-08-12 13:48:17,882 DEBUG stderr= 2011-08-12 13:48:17,905 DEBUG duration: 3 seconds 2011-08-12 13:48:17,906 DEBUG [4/11]: configuring certificate server instance The IPA-PKI instance access log on the replica is full of: SRCH base="ou=people,o=ipaca" scope=0 filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL The IPA-PKI instance error log on the replica contains: [12/Aug/2011:13:49:09 -0400] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-ipa-slave.cfmi.georgetown.edu-pki-ca" (ipa:7389): Replica has a different generation ID than the local data. [12/Aug/2011:13:49:10 -0400] NSMMReplicationPlugin - multimaster_be_state_change: replica o=ipaca is going offline; disabling replication [12/Aug/2011:13:49:11 -0400] - entrycache_clear_int: there are still 2 entries in the entry cache. [12/Aug/2011:13:49:11 -0400] - dncache_clear_int: there are still 2 dn's in the dn cache. :/ [12/Aug/2011:13:49:11 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [12/Aug/2011:13:49:15 -0400] - import ipaca: Workers finished; cleaning up... [12/Aug/2011:13:49:15 -0400] - import ipaca: Workers cleaned up. [12/Aug/2011:13:49:15 -0400] - import ipaca: Indexing complete. Post-processing... [12/Aug/2011:13:49:15 -0400] - import ipaca: Flushing caches... [12/Aug/2011:13:49:15 -0400] - import ipaca: Closing files... [12/Aug/2011:13:49:15 -0400] - entrycache_clear_int: there are still 12 entries in the entry cache. [12/Aug/2011:13:49:15 -0400] - dncache_clear_int: there are still 82 dn's in the dn cache. :/ [12/Aug/2011:13:49:15 -0400] - import ipaca: Import complete. Processed 82 entries in 4 seconds. (20.50 entries/sec) [12/Aug/2011:13:49:15 -0400] NSMMReplicationPlugin - multimaster_be_state_change: replica o=ipaca is coming online; enabling replication [12/Aug/2011:13:49:15 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 [12/Aug/2011:13:49:15 -0400] NSMMReplicationPlugin - replica_enable_replication: reloading ruv failed [12/Aug/2011:13:49:17 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 [12/Aug/2011:13:49:47 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 [12/Aug/2011:13:50:17 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 [12/Aug/2011:13:50:47 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 [12/Aug/2011:13:51:17 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 [12/Aug/2011:13:51:47 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 [12/Aug/2011:13:51:55 -0400] - Error: ldbm_txn_ruv_modify_context failed to retrieve and lock RUV entry [12/Aug/2011:13:51:55 -0400] - ldbm_back_modify: ldbm_txn_ruv_modify_context failed to construct RUV modify context [12/Aug/2011:13:52:17 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 [12/Aug/2011:13:52:47 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 [12/Aug/2011:13:53:17 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 [12/Aug/2011:13:53:47 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 /var/log/pki-ca/debug on the replica is full of: DatabasePanel comparetAndWaitEntries ou=people,o=ipaca not found, let's wait! This seems to be the problem described in the docs under troubleshooting (https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Setting_up_IPA_Replicas.html) when port 7389 is unavailable on the replica. This server is running nothing else, however, and lsof and netstat confirm that 7389 is available. The only other problem is a message about 7389 already existing in selinux policy, which (from reading the bug report) seems harmless. Please advise what may be done to further troubleshoot this issue. -- Shawn Nock (OpenPGP: 0x8132E623) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From rmeggins at redhat.com Fri Aug 12 18:26:06 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 12 Aug 2011 12:26:06 -0600 Subject: [Freeipa-users] Replica Creation hang at "configuring certificate server instance" In-Reply-To: References: Message-ID: <4E45703E.5050902@redhat.com> On 08/12/2011 12:06 PM, Shawn Nock wrote: > I am trying to create a replica of my working FreeIPA 2.0.1 > installation. Both the server and would-be replica are F15 minimal > installs dedicated to FreeIPA. > > Both hosts are in DNS (forward and reverse) with iptables and > selinux temporarily disabled. > > ipa-replica-install fails at: > 2011-08-12 13:48:14,768 DEBUG [3/11]: restarting certificate server > 2011-08-12 13:48:17,882 DEBUG args=/sbin/service pki-cad restart > 2011-08-12 13:48:17,882 DEBUG stdout=Stopping pki-ca: [FAILED] > Starting pki-ca: [ OK ] > 'pki-ca' must still be CONFIGURED! > (see /var/log/pki-ca-install.log) > > 2011-08-12 13:48:17,882 DEBUG stderr= > 2011-08-12 13:48:17,905 DEBUG duration: 3 seconds > 2011-08-12 13:48:17,906 DEBUG [4/11]: configuring certificate server instance > > The IPA-PKI instance access log on the replica is full of: > > SRCH base="ou=people,o=ipaca" scope=0 > filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL > > The IPA-PKI instance error log on the replica contains: > > [12/Aug/2011:13:49:09 -0400] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-ipa-slave.cfmi.georgetown.edu-pki-ca" (ipa:7389): Replica has a different generation ID than the local data. > [12/Aug/2011:13:49:10 -0400] NSMMReplicationPlugin - multimaster_be_state_change: replica o=ipaca is going offline; disabling replication > [12/Aug/2011:13:49:11 -0400] - entrycache_clear_int: there are still 2 entries in the entry cache. > [12/Aug/2011:13:49:11 -0400] - dncache_clear_int: there are still 2 dn's in the dn cache. :/ > [12/Aug/2011:13:49:11 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database > [12/Aug/2011:13:49:15 -0400] - import ipaca: Workers finished; cleaning up... > [12/Aug/2011:13:49:15 -0400] - import ipaca: Workers cleaned up. > [12/Aug/2011:13:49:15 -0400] - import ipaca: Indexing complete. Post-processing... > [12/Aug/2011:13:49:15 -0400] - import ipaca: Flushing caches... > [12/Aug/2011:13:49:15 -0400] - import ipaca: Closing files... > [12/Aug/2011:13:49:15 -0400] - entrycache_clear_int: there are still 12 entries in the entry cache. > [12/Aug/2011:13:49:15 -0400] - dncache_clear_int: there are still 82 dn's in the dn cache. :/ > [12/Aug/2011:13:49:15 -0400] - import ipaca: Import complete. Processed 82 entries in 4 seconds. (20.50 entries/sec) > [12/Aug/2011:13:49:15 -0400] NSMMReplicationPlugin - multimaster_be_state_change: replica o=ipaca is coming online; enabling replication > [12/Aug/2011:13:49:15 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > [12/Aug/2011:13:49:15 -0400] NSMMReplicationPlugin - replica_enable_replication: reloading ruv failed > [12/Aug/2011:13:49:17 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > [12/Aug/2011:13:49:47 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > [12/Aug/2011:13:50:17 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > [12/Aug/2011:13:50:47 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > [12/Aug/2011:13:51:17 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > [12/Aug/2011:13:51:47 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > [12/Aug/2011:13:51:55 -0400] - Error: ldbm_txn_ruv_modify_context failed to retrieve and lock RUV entry > [12/Aug/2011:13:51:55 -0400] - ldbm_back_modify: ldbm_txn_ruv_modify_context failed to construct RUV modify context > [12/Aug/2011:13:52:17 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > [12/Aug/2011:13:52:47 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > [12/Aug/2011:13:53:17 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > [12/Aug/2011:13:53:47 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > > /var/log/pki-ca/debug on the replica is full of: > > DatabasePanel comparetAndWaitEntries ou=people,o=ipaca not found, let's wait! > > This seems to be the problem described in the docs under troubleshooting > (https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Setting_up_IPA_Replicas.html) > when port 7389 is unavailable on the replica. This server is running > nothing else, however, and lsof and netstat confirm that 7389 is > available. > > The only other problem is a message about 7389 already existing in > selinux policy, which (from reading the bug report) seems harmless. > > Please advise what may be done to further troubleshoot this issue. what version of 389-ds-base? rpm -qi 389-ds-base this is supposed to be fixed in 389-ds-base-1.2.9.6 available from updates-testing > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From alee at redhat.com Fri Aug 12 18:34:47 2011 From: alee at redhat.com (Ade Lee) Date: Fri, 12 Aug 2011 14:34:47 -0400 Subject: [Freeipa-users] Replica Creation hang at "configuring certificate server instance" In-Reply-To: <4E45703E.5050902@redhat.com> References: <4E45703E.5050902@redhat.com> Message-ID: <1313174087.17431.100.camel@localhost.localdomain> This is also not running the latest available pki-common code. This code has been changed recently to make it more robust. Check updates-testing for pki-common Actually, you'll want to update : pki-common, pki-setup, pki-selinux, pki-ca, pki-silent. Ade On Fri, 2011-08-12 at 12:26 -0600, Rich Megginson wrote: > On 08/12/2011 12:06 PM, Shawn Nock wrote: > > I am trying to create a replica of my working FreeIPA 2.0.1 > > installation. Both the server and would-be replica are F15 minimal > > installs dedicated to FreeIPA. > > > > Both hosts are in DNS (forward and reverse) with iptables and > > selinux temporarily disabled. > > > > ipa-replica-install fails at: > > 2011-08-12 13:48:14,768 DEBUG [3/11]: restarting certificate server > > 2011-08-12 13:48:17,882 DEBUG args=/sbin/service pki-cad restart > > 2011-08-12 13:48:17,882 DEBUG stdout=Stopping pki-ca: [FAILED] > > Starting pki-ca: [ OK ] > > 'pki-ca' must still be CONFIGURED! > > (see /var/log/pki-ca-install.log) > > > > 2011-08-12 13:48:17,882 DEBUG stderr= > > 2011-08-12 13:48:17,905 DEBUG duration: 3 seconds > > 2011-08-12 13:48:17,906 DEBUG [4/11]: configuring certificate server instance > > > > The IPA-PKI instance access log on the replica is full of: > > > > SRCH base="ou=people,o=ipaca" scope=0 > > filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL > > > > The IPA-PKI instance error log on the replica contains: > > > > [12/Aug/2011:13:49:09 -0400] NSMMReplicationPlugin - agmt="cn=cloneAgreement1-ipa-slave.cfmi.georgetown.edu-pki-ca" (ipa:7389): Replica has a different generation ID than the local data. > > [12/Aug/2011:13:49:10 -0400] NSMMReplicationPlugin - multimaster_be_state_change: replica o=ipaca is going offline; disabling replication > > [12/Aug/2011:13:49:11 -0400] - entrycache_clear_int: there are still 2 entries in the entry cache. > > [12/Aug/2011:13:49:11 -0400] - dncache_clear_int: there are still 2 dn's in the dn cache. :/ > > [12/Aug/2011:13:49:11 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database > > [12/Aug/2011:13:49:15 -0400] - import ipaca: Workers finished; cleaning up... > > [12/Aug/2011:13:49:15 -0400] - import ipaca: Workers cleaned up. > > [12/Aug/2011:13:49:15 -0400] - import ipaca: Indexing complete. Post-processing... > > [12/Aug/2011:13:49:15 -0400] - import ipaca: Flushing caches... > > [12/Aug/2011:13:49:15 -0400] - import ipaca: Closing files... > > [12/Aug/2011:13:49:15 -0400] - entrycache_clear_int: there are still 12 entries in the entry cache. > > [12/Aug/2011:13:49:15 -0400] - dncache_clear_int: there are still 82 dn's in the dn cache. :/ > > [12/Aug/2011:13:49:15 -0400] - import ipaca: Import complete. Processed 82 entries in 4 seconds. (20.50 entries/sec) > > [12/Aug/2011:13:49:15 -0400] NSMMReplicationPlugin - multimaster_be_state_change: replica o=ipaca is coming online; enabling replication > > [12/Aug/2011:13:49:15 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > > [12/Aug/2011:13:49:15 -0400] NSMMReplicationPlugin - replica_enable_replication: reloading ruv failed > > [12/Aug/2011:13:49:17 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > > [12/Aug/2011:13:49:47 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > > [12/Aug/2011:13:50:17 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > > [12/Aug/2011:13:50:47 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > > [12/Aug/2011:13:51:17 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > > [12/Aug/2011:13:51:47 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > > [12/Aug/2011:13:51:55 -0400] - Error: ldbm_txn_ruv_modify_context failed to retrieve and lock RUV entry > > [12/Aug/2011:13:51:55 -0400] - ldbm_back_modify: ldbm_txn_ruv_modify_context failed to construct RUV modify context > > [12/Aug/2011:13:52:17 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > > [12/Aug/2011:13:52:47 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > > [12/Aug/2011:13:53:17 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > > [12/Aug/2011:13:53:47 -0400] NSMMReplicationPlugin - _replica_configure_ruv: failed to create replica ruv tombstone entry (o=ipaca); LDAP error - 68 > > > > /var/log/pki-ca/debug on the replica is full of: > > > > DatabasePanel comparetAndWaitEntries ou=people,o=ipaca not found, let's wait! > > > > This seems to be the problem described in the docs under troubleshooting > > (https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/Setting_up_IPA_Replicas.html) > > when port 7389 is unavailable on the replica. This server is running > > nothing else, however, and lsof and netstat confirm that 7389 is > > available. > > > > The only other problem is a message about 7389 already existing in > > selinux policy, which (from reading the bug report) seems harmless. > > > > Please advise what may be done to further troubleshoot this issue. > what version of 389-ds-base? rpm -qi 389-ds-base > this is supposed to be fixed in 389-ds-base-1.2.9.6 available from > updates-testing > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From nock at nocko.org Fri Aug 12 18:46:33 2011 From: nock at nocko.org (Shawn Nock) Date: Fri, 12 Aug 2011 14:46:33 -0400 Subject: [Freeipa-users] Replica Creation hang at "configuring certificate server instance" In-Reply-To: <1313174087.17431.100.camel@localhost.localdomain> (Ade Lee's message of "Fri, 12 Aug 2011 14:34:47 -0400") References: <4E45703E.5050902@redhat.com> <1313174087.17431.100.camel@localhost.localdomain> Message-ID: Ade Lee writes: > This is also not running the latest available pki-common code. This > code has been changed recently to make it more robust. > > Check updates-testing for pki-common > > Actually, you'll want to update : pki-common, pki-setup, pki-selinux, > pki-ca, pki-silent. Updating the pki-* to 9.0.11-1 and 389-ds-base to 1.2.9.6-1 (available in updates-testing) resolved this problem. Thanks -- Shawn Nock (OpenPGP: 0x8132E623) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From brad at codeprogrammers.net Sun Aug 14 04:06:31 2011 From: brad at codeprogrammers.net (Bradley Clemetson) Date: Sat, 13 Aug 2011 21:06:31 -0700 (PDT) Subject: [Freeipa-users] Could not update ICEauthority file /home/brad/.ICEauthority FreeIPA In-Reply-To: Message-ID: Hi, I am setting up a freeipa2 server (both fedora 15), and I was able to get the ipa-client-install to work perfectly (as far as I know) by yum excluding libcurl and curl. If I run kinit brad, I can authenticate and that works aswell. But when I want to login as me through gdm, I get "Could not update ICEauthority file /home/brad/.ICEauthority" granted the home folders do not exist as this would be my first ever login. Any and all help is GREATLY appreciated, as I am currently replacing a windows computer lab to fedora, and have got eveything else ready to go. Thanks You for a great product. From thing.thing at gmail.com Sun Aug 14 04:11:53 2011 From: thing.thing at gmail.com (Thing) Date: Sun, 14 Aug 2011 16:11:53 +1200 Subject: [Freeipa-users] Could not update ICEauthority file /home/brad/.ICEauthority FreeIPA In-Reply-To: References: Message-ID: Hi, For the client I suspect you need to set the mkhomedir flag when doing the install, I dont know how to set it afterward so I suggest a quick fix is un-install the client and re-install with that flag. regards Steven On Sun, Aug 14, 2011 at 4:06 PM, Bradley Clemetson wrote: > Hi, > I am setting up a freeipa2 server (both fedora 15), and I was able to get > the ipa-client-install to work perfectly (as far as I know) by yum excluding > libcurl and curl. If I run kinit brad, I can authenticate and that works > aswell. > > But when I want to login as me through gdm, I get "Could not update > ICEauthority file /home/brad/.ICEauthority" granted the home folders do not > exist as this would be my first ever login. > > Any and all help is GREATLY appreciated, as I am currently replacing a > windows computer lab to fedora, and have got eveything else ready to go. > > Thanks You for a great product. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kollathodi at yahoo.com Sun Aug 14 07:09:29 2011 From: kollathodi at yahoo.com (nasir nasir) Date: Sun, 14 Aug 2011 00:09:29 -0700 (PDT) Subject: [Freeipa-users] Could not update ICEauthority file /home/brad/.ICEauthority FreeIPA In-Reply-To: Message-ID: <1313305769.40036.YahooMailClassic@web161304.mail.bf1.yahoo.com> While I don't know much about the issue you mentioned, you can add the mkhomedir switch to the necessary pam files later also. If you don't know the exact files and switches, compare it with an identical machine where you have mkhomedir switch enabled at the time of IPA client installation. I think you can even copy the same pam files and put it inside your /etc/pam.d Regards,Nidal --- On Sat, 8/13/11, Thing wrote: From: Thing Subject: Re: [Freeipa-users] Could not update ICEauthority file /home/brad/.ICEauthority FreeIPA To: "Bradley Clemetson" Cc: freeipa-users at redhat.com Date: Saturday, August 13, 2011, 9:11 PM Hi, For the client I suspect you need to set the mkhomedir flag when doing the install, I dont know how to set it afterward so I suggest a quick fix is un-install the client and re-install with that flag. regards Steven On Sun, Aug 14, 2011 at 4:06 PM, Bradley Clemetson wrote: Hi, I am setting up a freeipa2 server (both fedora 15), and I was able to get the ipa-client-install to work perfectly (as far as I know) by yum excluding libcurl and curl. If I run kinit brad, I can authenticate and that works aswell. But when I want to login as me through gdm, I get "Could not update ICEauthority file /home/brad/.ICEauthority" granted the home folders do not exist as this would be my first ever login. Any and all help is GREATLY appreciated, as I am currently replacing a windows computer lab to fedora, and have got eveything else ready to go. Thanks You for a great product. _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -----Inline Attachment Follows----- _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From geerten at schram.name Sun Aug 14 20:46:26 2011 From: geerten at schram.name (Geerten Schram) Date: Sun, 14 Aug 2011 22:46:26 +0200 (CEST) Subject: [Freeipa-users] Could not update ICEauthority file /home/brad/.ICEauthority FreeIPA Message-ID: <39354.10.1.128.127.1313354786.squirrel@www.schram.name> > Hi, > I am setting up a freeipa2 server (both fedora 15), and I was able to get the ipa-client-install to work perfectly (as far as I know) by yum excluding libcurl and curl. If I run kinit brad, I can authenticate and that works aswell. > > But when I want to login as me through gdm, I get "Could not update ICEauthority file /home/brad/.ICEauthority" granted the home folders do not exist as this would be my first ever login. You either don't have a home directory (/home/brad) or you've got a SeLinux problem. Last week I've made a little F15 freeipa setup with the default mkhomedir feature. The I had Selinux problems with ~/.Xautority for remote X sessions. After some Googling and reading I found out that there is another pam mkhomedit module (oddjob-mkhomedir). After installing this package, removing users, removing machine out of freeipa realm and reinstalling with $ ipa-client-install --mkhomedir everthing worked just fine. It seems that the default pam_makehomedit module is not able to set correct SELinux permissions. regards, Geerten From sgallagh at redhat.com Mon Aug 15 11:42:09 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 15 Aug 2011 07:42:09 -0400 Subject: [Freeipa-users] Could not update ICEauthority file /home/brad/.ICEauthority FreeIPA In-Reply-To: References: Message-ID: <1313408530.2540.8.camel@sgallagh520.bos.redhat.com> On Sun, 2011-08-14 at 16:11 +1200, Thing wrote: > Hi, > > For the client I suspect you need to set the mkhomedir flag when doing > the install, I dont know how to set it afterward so I suggest a quick > fix is un-install the client and re-install with that flag. Far easier would be to run (as root): 'yum install oddjob-mkhomedir' 'authconfig --update --enablemkhomedir' Then you should be all set. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From ondrejv at s3group.cz Tue Aug 16 10:47:19 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Tue, 16 Aug 2011 12:47:19 +0200 Subject: [Freeipa-users] authconfig-gtk & sssd Message-ID: <4E4A4AB7.4020107@s3group.cz> Hi List, Quick question - is there any plan to enable system-config-authentication to enable/configure sssd on RH-5/6 systems? Thanks, Ondrej The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Aug 16 12:32:13 2011 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 16 Aug 2011 14:32:13 +0200 Subject: [Freeipa-users] authconfig-gtk & sssd In-Reply-To: <4E4A4AB7.4020107@s3group.cz> References: <4E4A4AB7.4020107@s3group.cz> Message-ID: <20110816123213.GB22822@zeppelin.brq.redhat.com> On Tue, Aug 16, 2011 at 12:47:19PM +0200, Ondrej Valousek wrote: > Hi List, > > Quick question - is there any plan to enable system-config-authentication to enable/configure sssd on RH-5/6 systems? > Thanks, > > Ondrej > > I should be already possible in RHEL6 provided you tell authconfig to use only the features SSSD supports. As man authconfig(1) states: ----- When the configuration settings allow use of SSSD for user information services and authentication, SSSD will be automatically used instead of the legacy services and the SSSD configuration will be set up so there is a default domain populated with the settings required to connect the services. ----- You may end up with using nss-ldap if you told authconfig to use netgroups with an SSSD release that does not support it yet, for example. There are currently no plans to expand the support in RHEL5 beyond what is there now (--enablesssd and --enablesssdauth that enable the NSS and PAM modules). From ondrejv at s3group.cz Tue Aug 16 13:06:01 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Tue, 16 Aug 2011 15:06:01 +0200 Subject: [Freeipa-users] authconfig-gtk & sssd In-Reply-To: <20110816123213.GB22822@zeppelin.brq.redhat.com> References: <4E4A4AB7.4020107@s3group.cz> <20110816123213.GB22822@zeppelin.brq.redhat.com> Message-ID: <4E4A6B39.6020208@s3group.cz> Hi Jakub, Ok, I have already found out - sorry for the noise. Still I have a few questions about sssd-ldap plugin (strange DNS SRV usage, inability to detect krb5 realm automatically) - which forum is the best for this type of questions? sssd-devel? Thanks, Ondrej On 16.08.2011 14:32, Jakub Hrozek wrote: > On Tue, Aug 16, 2011 at 12:47:19PM +0200, Ondrej Valousek wrote: >> Hi List, >> >> Quick question - is there any plan to enable system-config-authentication to enable/configure sssd on RH-5/6 systems? >> Thanks, >> >> Ondrej >> >> > I should be already possible in RHEL6 provided you tell authconfig to use > only the features SSSD supports. As man authconfig(1) states: > > ----- > When the configuration settings allow use of SSSD for user information > services and authentication, SSSD will be automatically used instead of > the legacy services and the SSSD configuration will be set up so there is a > default domain populated with the settings required to connect the services. > ----- > > You may end up with using nss-ldap if you told authconfig to use netgroups > with an SSSD release that does not support it yet, for example. > > There are currently no plans to expand the support in RHEL5 beyond what > is there now (--enablesssd and --enablesssdauth that enable the NSS and > PAM modules). > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrejv at s3group.cz Tue Aug 16 13:10:01 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Tue, 16 Aug 2011 15:10:01 +0200 Subject: [Freeipa-users] authconfig-gtk & sssd In-Reply-To: <20110816123213.GB22822@zeppelin.brq.redhat.com> References: <4E4A4AB7.4020107@s3group.cz> <20110816123213.GB22822@zeppelin.brq.redhat.com> Message-ID: <4E4A6C29.5000202@s3group.cz> ....and one more thing: authconfig-gtk seems to be only able to configure sssd-ldap plugin and not the IPA backend. This is quite unfortunate, I think - are there any plans to add support for IPA? Thanks, Ondrej On 16.08.2011 14:32, Jakub Hrozek wrote: > On Tue, Aug 16, 2011 at 12:47:19PM +0200, Ondrej Valousek wrote: >> Hi List, >> >> Quick question - is there any plan to enable system-config-authentication to enable/configure sssd on RH-5/6 systems? >> Thanks, >> >> Ondrej >> >> > I should be already possible in RHEL6 provided you tell authconfig to use > only the features SSSD supports. As man authconfig(1) states: > > ----- > When the configuration settings allow use of SSSD for user information > services and authentication, SSSD will be automatically used instead of > the legacy services and the SSSD configuration will be set up so there is a > default domain populated with the settings required to connect the services. > ----- > > You may end up with using nss-ldap if you told authconfig to use netgroups > with an SSSD release that does not support it yet, for example. > > There are currently no plans to expand the support in RHEL5 beyond what > is there now (--enablesssd and --enablesssdauth that enable the NSS and > PAM modules). > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Aug 16 13:21:46 2011 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 16 Aug 2011 15:21:46 +0200 Subject: [Freeipa-users] authconfig-gtk & sssd In-Reply-To: <4E4A6B39.6020208@s3group.cz> References: <4E4A4AB7.4020107@s3group.cz> <20110816123213.GB22822@zeppelin.brq.redhat.com> <4E4A6B39.6020208@s3group.cz> Message-ID: <20110816132146.GC22822@zeppelin.brq.redhat.com> On Tue, Aug 16, 2011 at 03:06:01PM +0200, Ondrej Valousek wrote: > Hi Jakub, > > Ok, I have already found out - sorry for the noise. > Still I have a few questions about sssd-ldap plugin (strange DNS SRV > usage, inability to detect krb5 realm automatically) - which forum > is the best for this type of questions? sssd-devel? > Either here or sssd-devel, both are fine. We might start sssd-users at some point in future, but we haven't. The ability to detect Kerberos realm automatically using TXT DNS records is scheduled for 1.7 - https://fedorahosted.org/sssd/ticket/481 I'm quite curious about the DNS SRV issue, we haven't had a real problem there (expcept for some misleading error messages) for some time. From ondrejv at s3group.cz Tue Aug 16 13:56:48 2011 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Tue, 16 Aug 2011 15:56:48 +0200 Subject: [Freeipa-users] sssd issues In-Reply-To: <20110816132146.GC22822@zeppelin.brq.redhat.com> References: <4E4A4AB7.4020107@s3group.cz> <20110816123213.GB22822@zeppelin.brq.redhat.com> <4E4A6B39.6020208@s3group.cz> <20110816132146.GC22822@zeppelin.brq.redhat.com> Message-ID: <4E4A7720.9050401@s3group.cz> Hi list, Ok here is the list of issues I discovered while configuring sssd against Win2008 AD & rfc2307bis schema: 1. If I specify both dns_discovery_domain and ldap_uri parameters then what happens is that dns srv discovery returns a list of ldap servers. Now if the first one found is not working, others are not tried. I have to comment out the 'ldap_uri' parameter to make it working correctly. 2. SSSD is unable to detect default Kerberos realm as per /etc/krb5.conf - I have to configure it manually 3. Why do we actually need to specify Kerberos realm and KDC? Isn't /etc/krb5.conf supposed to record these kind of parameters? 4. authconfig is unable to configure sssd to use IPA backend provider Thanks, Ondrej The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications at s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Aug 16 14:29:30 2011 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 16 Aug 2011 16:29:30 +0200 Subject: [Freeipa-users] sssd issues In-Reply-To: <4E4A7720.9050401@s3group.cz> References: <4E4A4AB7.4020107@s3group.cz> <20110816123213.GB22822@zeppelin.brq.redhat.com> <4E4A6B39.6020208@s3group.cz> <20110816132146.GC22822@zeppelin.brq.redhat.com> <4E4A7720.9050401@s3group.cz> Message-ID: <20110816142930.GE22822@zeppelin.brq.redhat.com> On Tue, Aug 16, 2011 at 03:56:48PM +0200, Ondrej Valousek wrote: > Hi list, > Ok here is the list of issues I discovered while configuring sssd against Win2008 AD & rfc2307bis schema: > 1. If I specify both dns_discovery_domain and ldap_uri parameters > then what happens is that dns srv discovery returns a list of ldap > servers. Now if the first one found is not working, others are not > tried. I have to comment out the 'ldap_uri' parameter to make it > working correctly. Can you paste how exactly the ldap_uri line looks? I presume you would like to try the service discovery first and if that fails, fall back to a hardcoded hostname. In that case, ldap_uri should say: ldap_uri = _srv_, adserver.example.com That should work. > > 2. SSSD is unable to detect default Kerberos realm as per /etc/krb5.conf - I have to configure it manually > > 3. Why do we actually need to specify Kerberos realm and KDC? Isn't /etc/krb5.conf supposed to record these kind of parameters? I think this has both historical (we used to say you don't need /etc/krb5.conf at all with SSSD) and practical reasons - there can be more SSSD domains with different realms and KDCs at the same time. > 4. authconfig is unable to configure sssd to use IPA backend provider > This was supposedly done to avoid people using authconfig-gtk to configure clients against IPAv1, but I don't remember the exact reason. Maybe someone else does? From dpal at redhat.com Tue Aug 16 16:34:20 2011 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 16 Aug 2011 12:34:20 -0400 Subject: [Freeipa-users] sssd issues In-Reply-To: <20110816142930.GE22822@zeppelin.brq.redhat.com> References: <4E4A4AB7.4020107@s3group.cz> <20110816123213.GB22822@zeppelin.brq.redhat.com> <4E4A6B39.6020208@s3group.cz> <20110816132146.GC22822@zeppelin.brq.redhat.com> <4E4A7720.9050401@s3group.cz> <20110816142930.GE22822@zeppelin.brq.redhat.com> Message-ID: <4E4A9C0C.4010804@redhat.com> On 08/16/2011 10:29 AM, Jakub Hrozek wrote: > On Tue, Aug 16, 2011 at 03:56:48PM +0200, Ondrej Valousek wrote: >> Hi list, >> Ok here is the list of issues I discovered while configuring sssd against Win2008 AD & rfc2307bis schema: >> 1. If I specify both dns_discovery_domain and ldap_uri parameters >> then what happens is that dns srv discovery returns a list of ldap >> servers. Now if the first one found is not working, others are not >> tried. I have to comment out the 'ldap_uri' parameter to make it >> working correctly. > Can you paste how exactly the ldap_uri line looks? I presume you would > like to try the service discovery first and if that fails, fall back to > a hardcoded hostname. In that case, ldap_uri should say: > > ldap_uri = _srv_, adserver.example.com > > That should work. > >> 2. SSSD is unable to detect default Kerberos realm as per /etc/krb5.conf - I have to configure it manually >> >> 3. Why do we actually need to specify Kerberos realm and KDC? Isn't /etc/krb5.conf supposed to record these kind of parameters? > I think this has both historical (we used to say you don't need > /etc/krb5.conf at all with SSSD) and practical reasons - there can be more > SSSD domains with different realms and KDCs at the same time. > >> 4. authconfig is unable to configure sssd to use IPA backend provider >> > This was supposedly done to avoid people using authconfig-gtk to > configure clients against IPAv1, but I don't remember the exact reason. Historically when the authconfig design was done there was no released IPA product of the v2 level in Fedora or RHEL. I thought 6.1 authconfig was enhance to configure sssd but AFAIR Kerberos and LDAP not IPA. If this is the case we need to file an ER. > Maybe someone else does? > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Tue Aug 16 16:43:10 2011 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 16 Aug 2011 12:43:10 -0400 Subject: [Freeipa-users] sssd issues In-Reply-To: <4E4A9C0C.4010804@redhat.com> References: <4E4A4AB7.4020107@s3group.cz> <20110816123213.GB22822@zeppelin.brq.redhat.com> <4E4A6B39.6020208@s3group.cz> <20110816132146.GC22822@zeppelin.brq.redhat.com> <4E4A7720.9050401@s3group.cz> <20110816142930.GE22822@zeppelin.brq.redhat.com> <4E4A9C0C.4010804@redhat.com> Message-ID: <4E4A9E1E.4000208@redhat.com> On 08/16/2011 12:34 PM, Dmitri Pal wrote: > On 08/16/2011 10:29 AM, Jakub Hrozek wrote: >> On Tue, Aug 16, 2011 at 03:56:48PM +0200, Ondrej Valousek wrote: >>> Hi list, >>> Ok here is the list of issues I discovered while configuring sssd against Win2008 AD & rfc2307bis schema: >>> 1. If I specify both dns_discovery_domain and ldap_uri parameters >>> then what happens is that dns srv discovery returns a list of ldap >>> servers. Now if the first one found is not working, others are not >>> tried. I have to comment out the 'ldap_uri' parameter to make it >>> working correctly. >> Can you paste how exactly the ldap_uri line looks? I presume you would >> like to try the service discovery first and if that fails, fall back to >> a hardcoded hostname. In that case, ldap_uri should say: >> >> ldap_uri = _srv_, adserver.example.com >> >> That should work. >> >>> 2. SSSD is unable to detect default Kerberos realm as per /etc/krb5.conf - I have to configure it manually >>> >>> 3. Why do we actually need to specify Kerberos realm and KDC? Isn't /etc/krb5.conf supposed to record these kind of parameters? >> I think this has both historical (we used to say you don't need >> /etc/krb5.conf at all with SSSD) and practical reasons - there can be more >> SSSD domains with different realms and KDCs at the same time. >> >>> 4. authconfig is unable to configure sssd to use IPA backend provider >>> >> This was supposedly done to avoid people using authconfig-gtk to >> configure clients against IPAv1, but I don't remember the exact reason. > Historically when the authconfig design was done there was no released > IPA product of the v2 level in Fedora or RHEL. > I thought 6.1 authconfig was enhance to configure sssd but AFAIR > Kerberos and LDAP not IPA. If this is the case we need to file an ER. Checked... I do not see any ERs for authconfig to support IPA back end. I have opened one: https://bugzilla.redhat.com/show_bug.cgi?id=731094 and also added a tracking ticket on our side: https://fedorahosted.org/sssd/ticket/969 >> Maybe someone else does? >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ryan at pet.ubc.ca Tue Aug 16 19:50:19 2011 From: ryan at pet.ubc.ca (Ryan Thomson) Date: Tue, 16 Aug 2011 12:50:19 -0700 Subject: [Freeipa-users] Extending Schema, CLI and Web UI for use with Samba 3 (groups!) Message-ID: <4E4AC9FB.9050602@pet.ubc.ca> Hello, I'm trying to follow various steps and instructions I've found online for extending FreeIPA v2 for use with Samba 3 as the LDAP backend. Things have mostly gone well but I've hit a road block that I can't quite figure out. Basically, I'm trying to get every new group added to FreeIPA (either via CLI or Web UI) to automagically become a valid samba group with sambaGroupMapping (and thus sambaSid and sambaGroupType). Here's what I've done this far: 1. Added an ipaUserObjectClasses attribute with value sambaSAMAccount to cn=ipaConfig,cn=etc,$SUFFIX. This works as expected for generating Samba hashes for users on password changes. 2. Configured the DNA plugin to automatically add a sambaSid attribute to every user with a sambaSAMAccount objectClass and group with sambaGroupMapping objectClass: # SambaSid, Distributed Numeric Assignment Plugin, plugins, config dn: cn=SambaSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config objectClass: top objectClass: extensibleObject dnatype: sambaSID dnaprefix: S-1-5-21-3180075094-3347106287-3821849995- dnainterval: 1 dnamagicregen: assign dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping)) dnascope: dc=fmri,dc=ubc,dc=ca cn: SambaSid dnanextvalue: 15289 This works as expected. 3. Added an ipaGroupObjectClasses attribute with value sambaGroupMapping to cn=ipaConfig,cn=etc,$SUFFIX. This works as expected, adding the objectClass sambaGroupMapping to every new group (and thus requiring sambaSid and sambaGroupType attributes). 4. Extended the schema (correct terminology?) using ipaCustomFields with (unquoted) value "Samba Group Type,sambagrouptype,true". 5. Extended the CLI in group.py (.../site-packages/ipalib/plugins/group.py) like so: --- group.py.orig 2011-08-15 14:59:48.570715207 -0700 +++ group.py 2011-08-16 12:43:43.493236507 -0700 @@ -118,6 +118,13 @@ label=_('GID'), doc=_('GID (use this option to set it manually)'), ), + Int('sambagrouptype', + cli_name='sgt', + label=_('Samba Group Type'), + doc=_('Samba Group Type (default is 4)'), + default=4, + autofill=True, + ), ) api.register(group) However, when I try to add a group with "ipa group-add groupname --desc="Group desc" I get the following output: ipa: ERROR: missing attribute "sambaGroupType" required by object class "sambaGroupMapping" and if I turn on the debugging, I see the following lines: ipa: DEBUG: raw: group_add(u'groupname', description=u'Group desc', sambagrouptype=4, nonposix=False, all=False, raw=False, version=u'2.1') ipa: DEBUG: group_add(u'groupname', description=u'Group desc', sambagrouptype=4, nonposix=False, all=False, raw=False, version=u'2.1') Which looks like my edit of group.py is doing what I expected it to do... but the IPA server is still returning the missing attribute error. However, if I use --addatr="sambagrouptype=4" as an argument to ipa group-add, it works fine and the attribute is added and the group is created. What am I missing? Thank you, -- Ryan Thomson Systems Administrator, UBC PET From rcritten at redhat.com Tue Aug 16 20:23:17 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 16 Aug 2011 16:23:17 -0400 Subject: [Freeipa-users] Extending Schema, CLI and Web UI for use with Samba 3 (groups!) In-Reply-To: <4E4AC9FB.9050602@pet.ubc.ca> References: <4E4AC9FB.9050602@pet.ubc.ca> Message-ID: <4E4AD1B5.8070409@redhat.com> Ryan Thomson wrote: > Hello, > > I'm trying to follow various steps and instructions I've found online for extending FreeIPA v2 for use with Samba 3 as the LDAP backend. Things have mostly gone well but I've hit a road block that I can't quite figure out. > > Basically, I'm trying to get every new group added to FreeIPA (either via CLI or Web UI) to automagically become a valid samba group with sambaGroupMapping (and thus sambaSid and sambaGroupType). > > Here's what I've done this far: > > 1. Added an ipaUserObjectClasses attribute with value sambaSAMAccount to cn=ipaConfig,cn=etc,$SUFFIX. This works as expected for generating Samba hashes for users on password changes. > > 2. Configured the DNA plugin to automatically add a sambaSid attribute to every user with a sambaSAMAccount objectClass and group with sambaGroupMapping objectClass: > > # SambaSid, Distributed Numeric Assignment Plugin, plugins, config > dn: cn=SambaSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config > objectClass: top > objectClass: extensibleObject > dnatype: sambaSID > dnaprefix: S-1-5-21-3180075094-3347106287-3821849995- > dnainterval: 1 > dnamagicregen: assign > dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping)) > dnascope: dc=fmri,dc=ubc,dc=ca > cn: SambaSid > dnanextvalue: 15289 > > This works as expected. > > 3. Added an ipaGroupObjectClasses attribute with value sambaGroupMapping to cn=ipaConfig,cn=etc,$SUFFIX. This works as expected, adding the objectClass sambaGroupMapping to every new group (and thus requiring sambaSid and sambaGroupType attributes). > > 4. Extended the schema (correct terminology?) using ipaCustomFields with (unquoted) value "Samba Group Type,sambagrouptype,true". > > 5. Extended the CLI in group.py (.../site-packages/ipalib/plugins/group.py) like so: > > --- group.py.orig 2011-08-15 14:59:48.570715207 -0700 > +++ group.py 2011-08-16 12:43:43.493236507 -0700 > @@ -118,6 +118,13 @@ > label=_('GID'), > doc=_('GID (use this option to set it manually)'), > ), > + Int('sambagrouptype', > + cli_name='sgt', > + label=_('Samba Group Type'), > + doc=_('Samba Group Type (default is 4)'), > + default=4, > + autofill=True, > + ), > ) > > api.register(group) > > > However, when I try to add a group with "ipa group-add groupname --desc="Group desc" I get the following output: > > ipa: ERROR: missing attribute "sambaGroupType" required by object class "sambaGroupMapping" > > and if I turn on the debugging, I see the following lines: > > ipa: DEBUG: raw: group_add(u'groupname', description=u'Group desc', sambagrouptype=4, nonposix=False, all=False, raw=False, version=u'2.1') > ipa: DEBUG: group_add(u'groupname', description=u'Group desc', sambagrouptype=4, nonposix=False, all=False, raw=False, version=u'2.1') > > Which looks like my edit of group.py is doing what I expected it to do... but the IPA server is still returning the missing attribute error. > > However, if I use --addatr="sambagrouptype=4" as an argument to ipa group-add, it works fine and the attribute is added and the group is created. > > What am I missing? > > Thank you, > This all looks fine. Did you restart the httpd process after making the changes to group.py? rob From ryan at pet.ubc.ca Tue Aug 16 20:36:33 2011 From: ryan at pet.ubc.ca (Ryan Thomson) Date: Tue, 16 Aug 2011 13:36:33 -0700 Subject: [Freeipa-users] Extending Schema, CLI and Web UI for use with Samba 3 (groups!) In-Reply-To: <4E4AD1B5.8070409@redhat.com> References: <4E4AC9FB.9050602@pet.ubc.ca> <4E4AD1B5.8070409@redhat.com> Message-ID: <4E4AD4D1.7010203@pet.ubc.ca> Hi Rob, No, I did not restart httpd *sigh*... And now that I have it works, of course! :D Thank you for the quick and precise help, Rob. FreeIPA is awesome. Keep up the great work. -- Ryan Thomson Systems Administrator, UBC PET On 08/16/2011 01:23 PM, Rob Crittenden wrote: > This all looks fine. Did you restart the httpd process after making the > changes to group.py? > > rob From dpal at redhat.com Tue Aug 16 20:50:56 2011 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 16 Aug 2011 16:50:56 -0400 Subject: [Freeipa-users] Extending Schema, CLI and Web UI for use with Samba 3 (groups!) In-Reply-To: <4E4AC9FB.9050602@pet.ubc.ca> References: <4E4AC9FB.9050602@pet.ubc.ca> Message-ID: <4E4AD830.7070005@redhat.com> On 08/16/2011 03:50 PM, Ryan Thomson wrote: > Hello, > > I'm trying to follow various steps and instructions I've found online for extending FreeIPA v2 for use with Samba 3 as the LDAP backend. Things have mostly gone well but I've hit a road block that I can't quite figure out. > > Basically, I'm trying to get every new group added to FreeIPA (either via CLI or Web UI) to automagically become a valid samba group with sambaGroupMapping (and thus sambaSid and sambaGroupType). > > Here's what I've done this far: > > 1. Added an ipaUserObjectClasses attribute with value sambaSAMAccount to cn=ipaConfig,cn=etc,$SUFFIX. This works as expected for generating Samba hashes for users on password changes. > > 2. Configured the DNA plugin to automatically add a sambaSid attribute to every user with a sambaSAMAccount objectClass and group with sambaGroupMapping objectClass: > > # SambaSid, Distributed Numeric Assignment Plugin, plugins, config > dn: cn=SambaSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config > objectClass: top > objectClass: extensibleObject > dnatype: sambaSID > dnaprefix: S-1-5-21-3180075094-3347106287-3821849995- > dnainterval: 1 > dnamagicregen: assign > dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping)) > dnascope: dc=fmri,dc=ubc,dc=ca > cn: SambaSid > dnanextvalue: 15289 > > This works as expected. > > 3. Added an ipaGroupObjectClasses attribute with value sambaGroupMapping to cn=ipaConfig,cn=etc,$SUFFIX. This works as expected, adding the objectClass sambaGroupMapping to every new group (and thus requiring sambaSid and sambaGroupType attributes). > > 4. Extended the schema (correct terminology?) using ipaCustomFields with (unquoted) value "Samba Group Type,sambagrouptype,true". > > 5. Extended the CLI in group.py (.../site-packages/ipalib/plugins/group.py) like so: > > --- group.py.orig 2011-08-15 14:59:48.570715207 -0700 > +++ group.py 2011-08-16 12:43:43.493236507 -0700 > @@ -118,6 +118,13 @@ > label=_('GID'), > doc=_('GID (use this option to set it manually)'), > ), > + Int('sambagrouptype', > + cli_name='sgt', > + label=_('Samba Group Type'), > + doc=_('Samba Group Type (default is 4)'), > + default=4, > + autofill=True, > + ), > ) > > api.register(group) > > > However, when I try to add a group with "ipa group-add groupname --desc="Group desc" I get the following output: > > ipa: ERROR: missing attribute "sambaGroupType" required by object class "sambaGroupMapping" > > and if I turn on the debugging, I see the following lines: > > ipa: DEBUG: raw: group_add(u'groupname', description=u'Group desc', sambagrouptype=4, nonposix=False, all=False, raw=False, version=u'2.1') > ipa: DEBUG: group_add(u'groupname', description=u'Group desc', sambagrouptype=4, nonposix=False, all=False, raw=False, version=u'2.1') > > Which looks like my edit of group.py is doing what I expected it to do... but the IPA server is still returning the missing attribute error. > > However, if I use --addatr="sambagrouptype=4" as an argument to ipa group-add, it works fine and the attribute is added and the group is created. > > What am I missing? > > Thank you, > Should we open a ticket and have a way to just turn this integration on? Something like ipa-server-install install flag --samba-integration. Then it will translate into enabling all of the above at the install time or after. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Tue Aug 16 21:11:22 2011 From: simo at redhat.com (Simo Sorce) Date: Tue, 16 Aug 2011 17:11:22 -0400 Subject: [Freeipa-users] Extending Schema, CLI and Web UI for use with Samba 3 (groups!) In-Reply-To: <4E4AD830.7070005@redhat.com> References: <4E4AC9FB.9050602@pet.ubc.ca> <4E4AD830.7070005@redhat.com> Message-ID: <1313529082.11512.179.camel@willson.li.ssimo.org> On Tue, 2011-08-16 at 16:50 -0400, Dmitri Pal wrote: > Should we open a ticket and have a way to just turn this integration > on? > Something like ipa-server-install install flag --samba-integration. > Then > it will translate into enabling all of the above at the install time > or > after. > It may conflict with the adtrust work if not done right, so I would prefer to do this as part of the 3.0-Trust work. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Aug 16 22:01:16 2011 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 16 Aug 2011 18:01:16 -0400 Subject: [Freeipa-users] Extending Schema, CLI and Web UI for use with Samba 3 (groups!) In-Reply-To: <1313529082.11512.179.camel@willson.li.ssimo.org> References: <4E4AC9FB.9050602@pet.ubc.ca> <4E4AD830.7070005@redhat.com> <1313529082.11512.179.camel@willson.li.ssimo.org> Message-ID: <4E4AE8AC.4040209@redhat.com> On 08/16/2011 05:11 PM, Simo Sorce wrote: > On Tue, 2011-08-16 at 16:50 -0400, Dmitri Pal wrote: >> Should we open a ticket and have a way to just turn this integration >> on? >> Something like ipa-server-install install flag --samba-integration. >> Then >> it will translate into enabling all of the above at the install time >> or >> after. >> > It may conflict with the adtrust work if not done right, so I would > prefer to do this as part of the 3.0-Trust work. > > Simo. > I am not suggesting to do it earlier. Can you please create a ticket to track it as a part of the trust effort? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sbose at redhat.com Wed Aug 17 07:54:15 2011 From: sbose at redhat.com (Sumit Bose) Date: Wed, 17 Aug 2011 09:54:15 +0200 Subject: [Freeipa-users] Extending Schema, CLI and Web UI for use with Samba 3 (groups!) In-Reply-To: <4E4AD830.7070005@redhat.com> References: <4E4AC9FB.9050602@pet.ubc.ca> <4E4AD830.7070005@redhat.com> Message-ID: <20110817075415.GE22225@localhost.localdomain> On Tue, Aug 16, 2011 at 04:50:56PM -0400, Dmitri Pal wrote: > On 08/16/2011 03:50 PM, Ryan Thomson wrote: > > Hello, > > > > I'm trying to follow various steps and instructions I've found online for extending FreeIPA v2 for use with Samba 3 as the LDAP backend. Things have mostly gone well but I've hit a road block that I can't quite figure out. > > > > Basically, I'm trying to get every new group added to FreeIPA (either via CLI or Web UI) to automagically become a valid samba group with sambaGroupMapping (and thus sambaSid and sambaGroupType). > > > > Here's what I've done this far: > > > > 1. Added an ipaUserObjectClasses attribute with value sambaSAMAccount to cn=ipaConfig,cn=etc,$SUFFIX. This works as expected for generating Samba hashes for users on password changes. > > > > 2. Configured the DNA plugin to automatically add a sambaSid attribute to every user with a sambaSAMAccount objectClass and group with sambaGroupMapping objectClass: > > > > # SambaSid, Distributed Numeric Assignment Plugin, plugins, config > > dn: cn=SambaSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config > > objectClass: top > > objectClass: extensibleObject > > dnatype: sambaSID > > dnaprefix: S-1-5-21-3180075094-3347106287-3821849995- > > dnainterval: 1 > > dnamagicregen: assign > > dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping)) > > dnascope: dc=fmri,dc=ubc,dc=ca > > cn: SambaSid > > dnanextvalue: 15289 > > > > This works as expected. > > > > 3. Added an ipaGroupObjectClasses attribute with value sambaGroupMapping to cn=ipaConfig,cn=etc,$SUFFIX. This works as expected, adding the objectClass sambaGroupMapping to every new group (and thus requiring sambaSid and sambaGroupType attributes). > > > > 4. Extended the schema (correct terminology?) using ipaCustomFields with (unquoted) value "Samba Group Type,sambagrouptype,true". > > > > 5. Extended the CLI in group.py (.../site-packages/ipalib/plugins/group.py) like so: > > > > --- group.py.orig 2011-08-15 14:59:48.570715207 -0700 > > +++ group.py 2011-08-16 12:43:43.493236507 -0700 > > @@ -118,6 +118,13 @@ > > label=_('GID'), > > doc=_('GID (use this option to set it manually)'), > > ), > > + Int('sambagrouptype', > > + cli_name='sgt', > > + label=_('Samba Group Type'), > > + doc=_('Samba Group Type (default is 4)'), > > + default=4, > > + autofill=True, > > + ), > > ) > > > > api.register(group) > > > > > > However, when I try to add a group with "ipa group-add groupname --desc="Group desc" I get the following output: > > > > ipa: ERROR: missing attribute "sambaGroupType" required by object class "sambaGroupMapping" > > > > and if I turn on the debugging, I see the following lines: > > > > ipa: DEBUG: raw: group_add(u'groupname', description=u'Group desc', sambagrouptype=4, nonposix=False, all=False, raw=False, version=u'2.1') > > ipa: DEBUG: group_add(u'groupname', description=u'Group desc', sambagrouptype=4, nonposix=False, all=False, raw=False, version=u'2.1') > > > > Which looks like my edit of group.py is doing what I expected it to do... but the IPA server is still returning the missing attribute error. > > > > However, if I use --addatr="sambagrouptype=4" as an argument to ipa group-add, it works fine and the attribute is added and the group is created. > > > > What am I missing? > > > > Thank you, > > > > Should we open a ticket and have a way to just turn this integration on? > Something like ipa-server-install install flag --samba-integration. Then > it will translate into enabling all of the above at the install time or > after. There are already tickets: - https://fedorahosted.org/freeipa/ticket/1614 to enhance the DNA plugin to handle SIDs - https://fedorahosted.org/freeipa/ticket/1619 to create a utility which prepares FreeIPA for AD trust and general Samba usage Ryan, please feel free to add comments to the tickets if you think we have missed features which you would like to see in here. bye, Sumit > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Wed Aug 17 15:00:58 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Aug 2011 11:00:58 -0400 Subject: [Freeipa-users] Announcing FreeIPA 2.1.0 Message-ID: <4E4BD7AA.6030606@redhat.com> The FreeIPA Project is proud to announce the latest release of the FreeIPA. As always, the latest tarball can be found at http://freeipa.org/ FreeIPA 2.1 is available in Fedora 15. It is currently in the updates-testing repository along with a number of its dependencies. Fedora 16 and rawhide builds will be coming soon. == Highlights == * General client and server installation improvements. Server installation is significantly faster. * Improved support for IPv6. * General UI improvements related to navigation and work flow. * Added UI for automount. * A Host-based Access Control (HBAC) test tool * Deprecation of HBAC deny rules * A CA is no longer required on every replica and may be added post-install to a replica (see ipa-ca-install). * A new replication tool for dogtag has been added (ipa-cs-manage). This allows you to control the replication topology of your CA. == Upgrading == === Server === To upgrade a 2.0.0 or 2.0.1 server do the following: # yum update freeipa-server --enablerepo=updates-testing This will pull in updated freeIPA, 389-ds, dogtag, libcurl and xmlrpc-c packages (and perhaps some others). A script will be executed in the rpm postinstall phase to update the IPA LDAP server with any required changes. There is a bug reported against 389-ds, https://bugzilla.redhat.com/show_bug.cgi?id=730387, related to read-write locks. The NSPR RW lock implementation does not safely allow re-entrant use of reader locks. This is a timing issue so it is difficult to predict. During testing one user experienced this and the upgrade hung. To break the hang kill the ns-slapd process for your realm, wait for the yum transaction to complete, then restart 389-ds and manually run the update process: # service dirsrv start # ipa-ldap-updater === Client === The ipa-client-install tool in the ipa-client package is just a configuration tool. There should be no need to re-run this on every client already enrolled. == Detailed Changelog == Adam Young (62): * Fixed labels for sudo and hbac rules * update metadata with label changes * define entities using builder and more declarative syntax * default all false no longer default to all: true for searches, only specify it for user searches * code review fixes * make use of new user-find columns. * fix JSL error * Upgrade to jquery 1.5.2 * action panel to top tabs * remove jquery-cookie library * update ipa init a simple script to update the metatdate et alles that come s from the ipa_init batch call * whitespace and -x removal * create entities on demand. fixed changes from code review * automount UI * redirect on show error. * redirect on error Code for redirecting on error has been moved to IPA.face t so it can be called from both details and assocaiton facets. * automount delete key indirect automount maps * scrollable content areas * dialog scrolling table * JSON marshalling list * dns multiple records show multiple records that share the same dnsname * no redirect on search * test for dirty * test dirty textarea runs the testdirty check before setting the undo tag for a textarea * test dirty multivalue test the multivalue widgets for changes before showing the undo link. * test dirty onchange * entity select widget for manager * hide automount tabs. * service host entity select Use the entity select widget for add service * entity select undo * no redirect on unknown error If the error name is indicates a server wide error, do not attempt to redirect. * editable entity_select * ipaddress for host add * entity select for password policy * tooltips for host add * automountkey details * identify target as section for permissions * optional uid * validate required fields * Generate record type list from metadata * shorten url cache state in a javascript variable, and leave on information about the current entity in the URL hash params * containing entity pkeys * undefined pkeys * config fields * ipadefaultemaildomain * config widgets entity select default group checkbox for migration * entity link for password policy * validate ints * password expiration label * HBAC deny warning * check required on add * clear errors on reset * indirect admins * entity_select naming * remove HBAC warning from static UI * dnsrecord-mod ui * no dns * remove hardcoded DNS label for record name. * move dns to identity tab * removing setters setup and init * dns section header i18n. * use other_entity for adder columns Alexander Bokovoy (10): * Convert Bool to TRUE/FALSE when working with LDAP backend * Minor typos in the examples * Convert nsaccountlock to always work as bool towards Python code * Rearrange logging for NSCD daemon. * Fix sssd.conf to always have IPA certificate for the domain. * Add hbactest command. * Modify /etc/sysconfig/network on a client when IPA manages hostname * Make proper LDAP configuration reporting for ipa-client-install * Ensure network configuration file has proper permissions * Pass empty options as empty arrays for supported dns record types. Endi S. Dewata (114): * Fixed undefined label in permission adder dialog box. * Initial Selenium test cases. * Added functional test runner. * Refactored action panel and client area. * Refactored builder interface. * Refactored search facet. * Entitlements. * Updated Selenium tests. * Merged IPA.cmd() into IPA.command(). * Entitlement registration. * Entitlement import. * Entitlement download. * Moved adder dialog box into entity. * Standardized action panel buttons creation. * Entitlement quantity validation. * Refactored navigation. * Use entity names for tab state. * Moved entity contents outside navigation. * Added facet container. * Fixed self-service UI. * Updated Selenium tests. * Updated Selenium tests. * Updated DNS interface. * Added Selenium tests for DNS. * Added UUID field for entitlement registration. * Added Self-Service and Delegation tests. * Customizable facet groups. * Read-only association facet. * jQuery ordered map. * Fixed problem disabling HBAC and SUDO rules. * Fixed Ajax error handling. * Fixed details tests. * Fixed adder dialog title. * Fixed Add and Edit without primary key. * Fixed Selenium tests. * Fixed URL parameter parsing. * Added Update and Reset buttons into Dirty dialog. * Fixed problem deleting value in text field. * Added pagination for associations. * Fixed pagination problem. * Temporary fix for indirect member tabs. * Fixed blank dialog box on internal error. * Fixed resizing issues. * Added selectable option for table widget. * Entitlement status. * Fixed tab navigation. * Fixed build break. * Fixed paging for indirect members. * Renamed associate.js to association.js. * Fixed self-service links. * Merged direct and indirect association facets * Storing page number in URL. * Removed FreeWay font files. * Fixed problem with navigation tabs on reload. * Converted entity header into facet header. * Added navigation breadcrumb. * Added record count into association facet tabs. * Added singular entity labels. * Fixed entity labels. * Fixed DNS records page title. * Fixed undo all problem. * Removed unused images. * Fixed hard-coded messages. * Added confirmation dialog for user activation. * Fixed button style in Entitlements * Removed invalid associations. * Added arrow icons for details sections. * Fixed object_name usage. * Fixed HBAC/Sudo rules associations. * Fixed blank self-service page. * Fixed dirty dialog problems in HBAC/Sudo rules. * Fixed test fixture file name. * Fixed missing entitlement import button label * Added sudo options. * Fixed collapsed table in Chrome. * Fixed object_name and object_name_plural internationalization * Fixed label capitalization * Entity select widget improvements * Removed reverse zones from host adder dialog. * Fixed host details fields. * Added checkbox to remove hosts from DNS. * Creating reverse zones from IP address. * Removed entitlement registration UUID field. * Fixed problem loading data in HBAC/sudo details page. * Removed HBAC access time code. * Removed custom layouts using HTML templates. * Refactored IPA.current_facet(). * Fixed problem with navigation state loading. * Fixed navigation problems. * Fixed navigation unit test. * Fixed click handlers on certificate buttons. * New icons for entitlement buttons * Fixed problem bookmarking Policy/IPA Server tabs * Fixed problem setting host OTP. * Fixed hard-coded labels in sudo rules. * Fixed hard-coded label in Find button. * Fixed missing section header in sudo command group. * Fixed problem unprovisioning service. * Fixed missing memberof definition in HBAC service. * Added association facets for HBAC and sudo. * Fixed certificate buttons. * Fixed missing icons. * Fixed misaligned search icon. * Resizable adder dialog box. * Linked entries in HBAC/sudo details page. * Fixed 3rd level tab style. * Fixed facet group labels. * Fixed error after login on IE * Fixed host adder dialog. * Fixed DNS zone adder dialog. * Fixed broken links in ipa_error.css and ipa_migration.css. * Fixed problem clicking 3rd level tabs. * Fixed link style in dialog box. * Fixed problem with buttons in enrollment dialog. Jakub Hrozek (1): * Remove wrong kpasswd sysconfig Jan Cholasta (34): * Fix wording of error message. * Add note about ipa-dns-install to ipa-server-install man page. * Fix typo in ipa-server-install. * Fix uninitialized variables. * Fix double definition of output_for_cli. * Add lint script for static code analysis. * Fix lint false positives. * Remove unused classes. * Fix some minor issues uncovered by pylint. * Fix uninitialized attributes. * Run lint during each build. * Several improvements of the lint script. * Fix issues found by Coverity. * Fix regressions introduced by pylint false positive fixes. * Assume ipa help for plugins. * Parse netmasks in IP addresses passed to server install. * Honor netmask in DNS reverse zone setup. * Do stricter checking of IP addressed passed to server install. * Fix directory manager password validation in ipa-nis-manage. * Improve IP address handling in the host-add command. * Verify that the hostname is fully-qualified before accessing the service information in ipactl. * Remove redundant configuration values from krb5.conf. * Replace the 'private' option in netgroup-find with 'managed'. * Configure SSSD to store user password if offline. * Fix creation of reverse DNS zones. * Add ability to specify DNS reverse zone name by IP network address. * Fix exit status of ipa-nis-manage enable. * Update minimum required version of python-netaddr. * Clean up of IP address checks in install scripts. * Don't delete NIS netgroup compat suffix on 'ipa-nis-manage disable'. * Fix ipa-compat-manage not working after recent ipa-nis-manage change. * Make sure that hostname specified by user is not an IP address. * Fix external CA install. * Ask for reverse DNS zone information in attended install right after asking for DNS forwarders, so that DNS configuration is done in one place. John Dennis (9): * Module for DN objects plus unit test * assert_deepequal supports callback for equality testing * Add backslash escape support for cvs reader * Use DN class in get_primary_key_from_dn to return decoded value * Update test_role_plugin test to include a comma in a privilege * Ticket 1485 - DN pairwise grouping * Make AVA, RDN & DN comparison case insensitive. No need for lowercase normalization. * Clean up existing DN object usage * transifex translation adjustment Jr Aquino (15): * Escape LDAP characters in member and memberof searches * Add memberHost and memberUser to default indexes * Optimize and dynamically verify group membership * Delete the sudoers entry when disabling Schema Compat * Return copy of config from ipa_get_config() * Typo in host_nis_groups has been creating 2 CN's * Add sudorule and hbacrule to memberof and indirectmemberof attributes * Display remaining external hosts when removing from sudorule * Raise DuplicateEntry Error when adding a duplicate sudo option * Don't add empty tuple to entry_attrs['externalhost'] * oneliner correct typo in ipasudorunas_group * Return correct "RunAs External Group" when removing members * remove escapes from the cvs parser in ipaserver/install/ldapupdate * Correct behavior for sudorunasgroup vs sudorunasuser * Correct sudo runasuser and runasgroup attributes in schema Martin Kosek (68): * Inconsistent error message for duplicate user * Replica installation fails for self-signed server * Remove doc from API.txt * Revert "Remove doc from API.txt" * Password policy commands do not include cospriority * Improve DNS PTR record validation * Remove unwanted trimming in text fields * Need force option in DNS zone adder dialog * IPA replica is not started after the reboot * Improve Directory Service open port checker * Log temporary files in ipa-client-install * Prevent uninstalling client on the IPA server * pwpolicy-mod doesn't accept old attribute values * Forbid reinstallation in ipa-client-install * ipa-client-install uninstall does not work on IPA server * LDAP Updater may crash IPA installer * NS records not updated by replica * Bad return values for ipa-rmkeytab command * Update spec with missing BuildRequires for pylint check * Let selinux-policy handle port 7390 * Limit passwd plugin to user container * Consolidate man pages and IPA tools help * Remove doc from API.txt * Improve service manipulation in client install * Running ipa-replica-manage as non-root cause errors * KDC autodiscovery may fail when domain is not realm * A new flag to disable creation of UPG * Fix reverse zone creation in ipa-replica-prepare * Improve interactive mode for DNS plugin * Localization fails for MaxArgumentError * Fix forward zone creation in ipa-replica-prepare * Connection check program for replica installation * Fix support for nss-pam-ldapd * Skip know_host check for ipa-replica-conncheck * IPA installation with --no-host-dns fails * Handle LDAP search references * Add ignore lists to migrate-ds command * Improve DNS zone creation * Add a list of managed hosts * Missing krbprincipalname when uid is not set * Add port 9443 to replica port checking * Fix doc for sudorule runasuser commands * Improve IP address handling in IPA option parser * Multi-process build problems * DNS installation fails when domain and host domain mismatch * Fix IPA install for secure umask * Allow recursion by default * Add DNS record modification command * Filter reverse zones in dnszone-find * Remove sensitive information from logs * Fix ipa-dns-install * Fix self-signed replica installation * Check IPA configuration in install tools * Add new dnszone-find test * Fix typo in ipa-replica-prepare * Improve long integer type validation * Fix sudorule-remove-user * Add missing automount summaries * Fix man page ipa-csreplica-manage * Fix automountkey commands summary * Fix invalid issuer in unit tests * Hide continue option from automountkey-del * Improve error message in ipactl * Improve dnszone-add error message * Fix idnsUpdatePolicy for reverse zone record * Fix client enrollment * Update 389-ds-base version * Update pki-ca version Nalin Dahyabhai (1): * Select a server with a CA on it when submitting signing requests. Pavel Zuna (1): * Fix gidnumber option of user-add command. Petr Vobornik (3): * fixed empty dns record update * Fixed adding host without DNS reverse zone * Redirection after changing browser configuration Rich Megginson (3): * winsync enables disabled users in AD * modify user deleted in AD crashes winsync * memory leak in ipa_winsync_get_new_ds_user_dn_cb Rob Crittenden (90): * Allow a client to enroll using principal when the host has a OTP * Make retrieval of the CA during DNS discovery non-fatal. * Cache the value of get_ipa_config() in the request context. * Change default gecos from uid to first and last name. * Fix ORDERING in some attributetypes and remove other unnecessary elements. * postalCode should be a string not an integer. * Fix traceback in ipa-nis-manage. * Suppress --on-master from ipa-client-install command-line and man page. * Sort entries returned by *-find by the primary key (if any). * The default groups we create should have ipaUniqueId set * Always ask members in LDAP*ReverseMember commands. * Provide attributelevelrights for the aci components in permission_show. * Wait for memberof task and DS to start before proceeding in installation. * Convert manager from userid to dn for storage and back for displaying. * Modify the default attributes shown in user-find to match the UI design. * Ensure that the zonemgr passed to the installer conforms to IA5String. * Handle principal not found errors when converting replication a greements * Bump version to 2.0.90 to distinguish between 2.0.x * Properly handle --no-reverse being passed on the CLI in interactive mode * Update min nvr for selinux-policy and pki-ca for F-15+ * Test for forwarded Kerberos credentials cache in wsgi code. * Properly configure nsswitch.conf when using the --no-sssd option. * Enable 389-ds SSL host checking by defauilt * Configure Managed Entries on replicas. * Document that deleting and re-adding a replica requires a dirsrv restart. * Fix migration to work between v2 servers and remove search/size limits. * Add option to limit the attributes allowed in an entry. * Include the word 'member' with autogenerated optional member labels. * Do a lazy retrieval of the LDAP schema rather than at module load. * Add UID, GID and e-mail to the user default attributes. * Fix external CA installation * Remove root autobind search restriction, fix upgrade logging & error handling * Support initializing memberof during replication re-init using GSSAPI * Do better detection on status of CA DS instance when installing. * Fix indirect member calculation * Remove automountinformation as part of the DN for automount. * Don't let a JSON error get lost in cascading errors. * Add message output summary to sudorule del, mod and find. * Return an error message when revocation reason 7 is used * Require an imported certificate's issuer to match our issuer. * On a master configure sssd to only talk to the local master. * The IP address provided to ipa-server-install must be local * Do lazy LDAP schema retrieval in json handler. * Make data type of certificates more obvious/predictable internally. * Update translation files * Let the framework be able to override the hostname. * Make dogtag an optional (and default un-) installed component in a replica. * Slight performance improvement by not doing some checking in production mode * Set the client auth callback after creating the SSL connection. * Add pwd expiration notif (ipapwdexpadvnotify) to config plugin def attr list * Enforce class rules when query=True, continue to not run validators. * find_entry_by_attr() should fail if multiple entries are found * Fix error in AttrValueNotFound exception example * Fix test failure in updater when adding values to a single-value attr * Reset failed login count to 0 when admin resets password. * Disallow direct modifications to enrolledBy. * Document registering to an entitlement server with a UUID as not implemented. * In sudo labels we should use RunAs and not Run As. * Remove the ability to create new HBAC deny rules. * Validate that the certificate subject base is in valid DN format. * Use information from the certificate subject when setting the NSS nickname. * Create tool to manage dogtag replication agreements * Fix failing tests due to object name changes * Set nickname of the RA to 'IPA RA' to avoid confusion with dogtag RA * Set the ipa-modrdn plugin precedence to 60 so it runs last * Generate a database password by default in all cases. * Specify the package name when the replication plugin is missing. * Change client enrollment principal prompt to hopefully be clearer. * Optionally wait for 389-ds postop plugins to complete * A removed external host is shown in output when removing external hosts. * Don't set krbLastPwdChange when setting a host OTP password. * Fix regression when calculating external groups. * With the external user/group management fixed, correct the unit tests. * Set a default minimum value for class Int, handle long values better. * Make ipa-client-install error messages more understandable and relevant. * Add Alexander Bokovoy and Jan Cholasta to contributors file * Only call entry_from_entry() after waiting for the new entry. * Hide the HBAC access type attribute now that deny is deprecated. * Autofill the default revocation reason * Don't check for leading/trailing spaces in a File parameter * Add an arch-specific Requires on cyrus-sasl-gssapi * Revert use of 'can be at least' to 'must be at least' in minvalue validator * Don't leave dangling map if adding an indirect map fails * Fix message in test case for checking minimum values * When setting a host password don't set krbPasswordExpiration. * Set minimum version of pki-ca to 9.0.10 to pick up new ipa cert profile * Deprecated managing users and runas user/group in sudorule add/mod * Fix date order in changelog. * Re-arrange CA configuration code to reduce the number of restarts. Simo Sorce (4): * Fix resource leaks. * ipautil: Preserve environment unless explicitly overridden by caller. * install-scripts: avoid using --list with chkconfig * Don't set the password expiration to the current time Yuri Chornoivan (1): * Typos in freeIPA messages and man page Kyle Baker (5): * Background images and tab hover * Search bar style and positioning changes * List page spacing changes * Tab and spacing on list * Facet icon swap and tab sizing From sigbjorn at nixtra.com Fri Aug 19 16:54:54 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Fri, 19 Aug 2011 18:54:54 +0200 Subject: [Freeipa-users] FreeIPA 2.1.0 - SELinux Message-ID: <4E4E955E.9070803@nixtra.com> Hi, I've just updated to FreeIPA 2.1.0. I disabled SELinux on this machine (Fedora 15) when I installed IPA, as there was a bug with IPA's SELinux ruleset, which made the ipa-server-install script fail. That decision seem to be biting my ass now, I get the following error message: "/usr/bin/runcon: /usr/bin/runcon may be used only on a SELinux kernel" whenever I attempt to start IPA. See below for output. After configuring SELinux to be permissive the error disappears, and IPA starts normally. I have opened a bug here: https://bugzilla.redhat.com/show_bug.cgi?id=732064 Other than that - thank you for an excellent product! I've been waiting for the automount option in the GUI, makes editing automount rules a whole lot easier!! :) Regards, Siggi [root at ipa03 ~]# ipactl restart Restarting Directory Service Shutting down dirsrv: IX-TEST-COM... server already stopped [FAILED] PKI-IPA... server already stopped [FAILED] *** Error: 2 instance(s) unsuccessfully stopped [FAILED] Starting dirsrv: IX-TEST-COM... [ OK ] PKI-IPA... [ OK ] Restarting KDC Service Restarting krb5kdc (via systemctl): [ OK ] Restarting KPASSWD Service Restarting ipa_kpasswd (via systemctl): [ OK ] Restarting HTTP Service Restarting httpd (via systemctl): [ OK ] Restarting CA Service Stopping pki-ca: [ OK ] /usr/bin/runcon: /usr/bin/runcon may be used only on a SELinux kernel Failed to restart CA Service Shutting down Stopping krb5kdc (via systemctl): [ OK ] Stopping ipa_kpasswd (via systemctl): [ OK ] Stopping httpd (via systemctl): [ OK ] Stopping pki-ca: [ OK ] Shutting down dirsrv: IX-TEST-COM... [ OK ] PKI-IPA... [ OK ] Aborting ipactl [root at ipa03 ~]# getenforce Disabled From rcritten at redhat.com Fri Aug 19 16:57:28 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Aug 2011 12:57:28 -0400 Subject: [Freeipa-users] FreeIPA 2.1.0 - SELinux In-Reply-To: <4E4E955E.9070803@nixtra.com> References: <4E4E955E.9070803@nixtra.com> Message-ID: <4E4E95F8.1090603@redhat.com> Sigbjorn Lie wrote: > Hi, > > I've just updated to FreeIPA 2.1.0. I disabled SELinux on this machine > (Fedora 15) when I installed IPA, as there was a bug with IPA's SELinux > ruleset, which made the ipa-server-install script fail. > > That decision seem to be biting my ass now, I get the following error > message: "/usr/bin/runcon: /usr/bin/runcon may be used only on a SELinux > kernel" whenever I attempt to start IPA. See below for output. > > After configuring SELinux to be permissive the error disappears, and IPA > starts normally. > > I have opened a bug here: > https://bugzilla.redhat.com/show_bug.cgi?id=732064 > > Other than that - thank you for an excellent product! I've been waiting > for the automount option in the GUI, makes editing automount rules a > whole lot easier!! :) > > > > > Regards, > Siggi > > > > > > [root at ipa03 ~]# ipactl restart > Restarting Directory Service > Shutting down dirsrv: > IX-TEST-COM... server already stopped [FAILED] > PKI-IPA... server already stopped [FAILED] > *** Error: 2 instance(s) unsuccessfully stopped [FAILED] > Starting dirsrv: > IX-TEST-COM... [ OK ] > PKI-IPA... [ OK ] > Restarting KDC Service > Restarting krb5kdc (via systemctl): [ OK ] > Restarting KPASSWD Service > Restarting ipa_kpasswd (via systemctl): [ OK ] > Restarting HTTP Service > Restarting httpd (via systemctl): [ OK ] > Restarting CA Service > Stopping pki-ca: [ OK ] > /usr/bin/runcon: /usr/bin/runcon may be used only on a SELinux kernel > Failed to restart CA Service > Shutting down > Stopping krb5kdc (via systemctl): [ OK ] > Stopping ipa_kpasswd (via systemctl): [ OK ] > Stopping httpd (via systemctl): [ OK ] > Stopping pki-ca: [ OK ] > Shutting down dirsrv: > IX-TEST-COM... [ OK ] > PKI-IPA... [ OK ] > Aborting ipactl > [root at ipa03 ~]# getenforce > Disabled > What is/was the bug in the SELinux ruleset that caused you to disable SELinux in the first place? rob From alee at redhat.com Fri Aug 19 17:17:51 2011 From: alee at redhat.com (Ade Lee) Date: Fri, 19 Aug 2011 13:17:51 -0400 Subject: [Freeipa-users] FreeIPA 2.1.0 - SELinux In-Reply-To: <4E4E95F8.1090603@redhat.com> References: <4E4E955E.9070803@nixtra.com> <4E4E95F8.1090603@redhat.com> Message-ID: <1313774272.10402.118.camel@localhost.localdomain> Siggi, The fix for this has already been checked into the dogtag code. We'll have a new build out (for pki-ca) probably sometime next week. Ade On Fri, 2011-08-19 at 12:57 -0400, Rob Crittenden wrote: > Sigbjorn Lie wrote: > > Hi, > > > > I've just updated to FreeIPA 2.1.0. I disabled SELinux on this machine > > (Fedora 15) when I installed IPA, as there was a bug with IPA's SELinux > > ruleset, which made the ipa-server-install script fail. > > > > That decision seem to be biting my ass now, I get the following error > > message: "/usr/bin/runcon: /usr/bin/runcon may be used only on a SELinux > > kernel" whenever I attempt to start IPA. See below for output. > > > > After configuring SELinux to be permissive the error disappears, and IPA > > starts normally. > > > > I have opened a bug here: > > https://bugzilla.redhat.com/show_bug.cgi?id=732064 > > > > Other than that - thank you for an excellent product! I've been waiting > > for the automount option in the GUI, makes editing automount rules a > > whole lot easier!! :) > > > > > > > > > > Regards, > > Siggi > > > > > > > > > > > > [root at ipa03 ~]# ipactl restart > > Restarting Directory Service > > Shutting down dirsrv: > > IX-TEST-COM... server already stopped [FAILED] > > PKI-IPA... server already stopped [FAILED] > > *** Error: 2 instance(s) unsuccessfully stopped [FAILED] > > Starting dirsrv: > > IX-TEST-COM... [ OK ] > > PKI-IPA... [ OK ] > > Restarting KDC Service > > Restarting krb5kdc (via systemctl): [ OK ] > > Restarting KPASSWD Service > > Restarting ipa_kpasswd (via systemctl): [ OK ] > > Restarting HTTP Service > > Restarting httpd (via systemctl): [ OK ] > > Restarting CA Service > > Stopping pki-ca: [ OK ] > > /usr/bin/runcon: /usr/bin/runcon may be used only on a SELinux kernel > > Failed to restart CA Service > > Shutting down > > Stopping krb5kdc (via systemctl): [ OK ] > > Stopping ipa_kpasswd (via systemctl): [ OK ] > > Stopping httpd (via systemctl): [ OK ] > > Stopping pki-ca: [ OK ] > > Shutting down dirsrv: > > IX-TEST-COM... [ OK ] > > PKI-IPA... [ OK ] > > Aborting ipactl > > [root at ipa03 ~]# getenforce > > Disabled > > > > What is/was the bug in the SELinux ruleset that caused you to disable > SELinux in the first place? > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From brad at codeprogrammers.net Sun Aug 21 13:25:46 2011 From: brad at codeprogrammers.net (Bradley Clemetson) Date: Sun, 21 Aug 2011 06:25:46 -0700 (PDT) Subject: [Freeipa-users] Failed to load session 'gnome' In-Reply-To: <94446af5-0309-41fd-b4f3-a66e8a0de47a@mail.mlhstech.local> Message-ID: <973dc0d9-eaa6-49af-bdee-2e26f67d283e@mail.mlhstech.local> I have setup a freeipa server that works and run authentication to Fedora 15 clients. Fedora clients that support Gnome3 default work great. But I also have clients that can only run gnome-fallback.So on these computers I can login but then am greeted with "Failed to load session "gnome"" Thank you Brad From simo at redhat.com Mon Aug 22 01:39:14 2011 From: simo at redhat.com (Simo Sorce) Date: Sun, 21 Aug 2011 21:39:14 -0400 Subject: [Freeipa-users] Failed to load session 'gnome' In-Reply-To: <973dc0d9-eaa6-49af-bdee-2e26f67d283e@mail.mlhstech.local> References: <973dc0d9-eaa6-49af-bdee-2e26f67d283e@mail.mlhstech.local> Message-ID: <1313977154.20296.15.camel@willson.li.ssimo.org> On Sun, 2011-08-21 at 06:25 -0700, Bradley Clemetson wrote: > I have setup a freeipa server that works and run authentication to Fedora 15 clients. Fedora clients that support Gnome3 default work great. But I also have clients that can only run gnome-fallback.So on these computers I can login but then am greeted with "Failed to load session "gnome"" > > Thank you > Brad As far as I know there is no difference in the pam stacks between normal and fallback mode. Do you have any logging in /var/log/secure or elsewhere that makes you think this is a FreeIPA related issue ? Simo. -- Simo Sorce * Red Hat, Inc * New York From sigbjorn at nixtra.com Mon Aug 22 16:01:42 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 22 Aug 2011 18:01:42 +0200 Subject: [Freeipa-users] FreeIPA 2.1.0 - SELinux In-Reply-To: <1313774272.10402.118.camel@localhost.localdomain> References: <4E4E955E.9070803@nixtra.com> <4E4E95F8.1090603@redhat.com> <1313774272.10402.118.camel@localhost.localdomain> Message-ID: <4E527D66.5020403@nixtra.com> Ah, excellent. Thanks. :) Rgds, Siggi On 08/19/2011 07:17 PM, Ade Lee wrote: > Siggi, > > The fix for this has already been checked into the dogtag code. We'll > have a new build out (for pki-ca) probably sometime next week. > > Ade > > On Fri, 2011-08-19 at 12:57 -0400, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >>> Hi, >>> >>> I've just updated to FreeIPA 2.1.0. I disabled SELinux on this machine >>> (Fedora 15) when I installed IPA, as there was a bug with IPA's SELinux >>> ruleset, which made the ipa-server-install script fail. >>> >>> That decision seem to be biting my ass now, I get the following error >>> message: "/usr/bin/runcon: /usr/bin/runcon may be used only on a SELinux >>> kernel" whenever I attempt to start IPA. See below for output. >>> >>> After configuring SELinux to be permissive the error disappears, and IPA >>> starts normally. >>> >>> I have opened a bug here: >>> https://bugzilla.redhat.com/show_bug.cgi?id=732064 >>> >>> Other than that - thank you for an excellent product! I've been waiting >>> for the automount option in the GUI, makes editing automount rules a >>> whole lot easier!! :) >>> >>> >>> >>> >>> Regards, >>> Siggi >>> >>> >>> >>> >>> >>> [root at ipa03 ~]# ipactl restart >>> Restarting Directory Service >>> Shutting down dirsrv: >>> IX-TEST-COM... server already stopped [FAILED] >>> PKI-IPA... server already stopped [FAILED] >>> *** Error: 2 instance(s) unsuccessfully stopped [FAILED] >>> Starting dirsrv: >>> IX-TEST-COM... [ OK ] >>> PKI-IPA... [ OK ] >>> Restarting KDC Service >>> Restarting krb5kdc (via systemctl): [ OK ] >>> Restarting KPASSWD Service >>> Restarting ipa_kpasswd (via systemctl): [ OK ] >>> Restarting HTTP Service >>> Restarting httpd (via systemctl): [ OK ] >>> Restarting CA Service >>> Stopping pki-ca: [ OK ] >>> /usr/bin/runcon: /usr/bin/runcon may be used only on a SELinux kernel >>> Failed to restart CA Service >>> Shutting down >>> Stopping krb5kdc (via systemctl): [ OK ] >>> Stopping ipa_kpasswd (via systemctl): [ OK ] >>> Stopping httpd (via systemctl): [ OK ] >>> Stopping pki-ca: [ OK ] >>> Shutting down dirsrv: >>> IX-TEST-COM... [ OK ] >>> PKI-IPA... [ OK ] >>> Aborting ipactl >>> [root at ipa03 ~]# getenforce >>> Disabled >>> >> What is/was the bug in the SELinux ruleset that caused you to disable >> SELinux in the first place? >> >> rob >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users From sigbjorn at nixtra.com Mon Aug 22 19:44:57 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 22 Aug 2011 21:44:57 +0200 Subject: [Freeipa-users] IPA Automount cross-location support Message-ID: <4E52B1B9.6040504@nixtra.com> Hi, IPA Automount configuration: Is it possible to reference an automount map from another location? E.g. under Policy -> Automount -> Add map -> Parent Map: .auto.data Example: Let's say you have the following automount locations defined in IPA: NewYork, Washington, Miami. Each location has it's own auto.data map mounted under /data. Then making a common automount map in all the locations called auto.global, mounted at /global, each referencing the auto.data maps from the different IPA locations? /global/washington -> Washington's auto.data map /global/newyork -> NewYork's auto.data map /global/miami -> Miami's auto.data map I'm not looking for the configuration of the /global map to be automatic, a manual configuration for pointing to each locations auto.data map would do just fine. Any suggestions? Regards, Siggi From sigbjorn at nixtra.com Mon Aug 22 19:51:12 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 22 Aug 2011 21:51:12 +0200 Subject: [Freeipa-users] Updating automount location name Message-ID: <4E52B330.20504@nixtra.com> Hi, I receive an error when I attempt to go to Policy -> Automount -> custom_location -> Settings -> Update: IPA Error 905 unknown command u'automountlocation_mod' Indeed the command is not available using the CLI either. A known issue? Also, when choosing "Add" to add a map, the "Indirect" map type is selected by default, however I need to click on "Direct", then "Indirect" to see the "Mount point" and "Parent map" options. A known issue? Rgds, Siggi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Aug 22 20:02:40 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 22 Aug 2011 16:02:40 -0400 Subject: [Freeipa-users] Updating automount location name In-Reply-To: <4E52B330.20504@nixtra.com> References: <4E52B330.20504@nixtra.com> Message-ID: <4E52B5E0.2050900@redhat.com> Sigbjorn Lie wrote: > Hi, > > I receive an error when I attempt to go to Policy -> Automount -> > custom_location -> Settings -> Update: > > IPA Error 905 > > unknown command u'automountlocation_mod' > > Indeed the command is not available using the CLI either. A known issue? Right, there is currently not a way to rename a location (no plans for one either unless requested). > > > Also, when choosing "Add" to add a map, the "Indirect" map type is > selected by default, however I need to click on "Direct", then > "Indirect" to see the "Mount point" and "Parent map" options. > > A known issue? > I didn't find an open ticket on it, can you open one describing what you are seeing? (https://fedorahosted.org/freeipa/newticket) thanks rob From sigbjorn at nixtra.com Mon Aug 22 20:48:52 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 22 Aug 2011 22:48:52 +0200 Subject: [Freeipa-users] Updating automount location name In-Reply-To: <4E52B5E0.2050900@redhat.com> References: <4E52B330.20504@nixtra.com> <4E52B5E0.2050900@redhat.com> Message-ID: <4E52C0B4.4010803@nixtra.com> On 08/22/2011 10:02 PM, Rob Crittenden wrote: > Sigbjorn Lie wrote: >> Hi, >> >> I receive an error when I attempt to go to Policy -> Automount -> >> custom_location -> Settings -> Update: >> >> IPA Error 905 >> >> unknown command u'automountlocation_mod' >> >> Indeed the command is not available using the CLI either. A known issue? > > Right, there is currently not a way to rename a location (no plans for > one either unless requested). > Ok, I don't need it. I suggest the update button in the web interface should be removed to avoid confusion. >> >> >> Also, when choosing "Add" to add a map, the "Indirect" map type is >> selected by default, however I need to click on "Direct", then >> "Indirect" to see the "Mount point" and "Parent map" options. >> >> A known issue? >> > > I didn't find an open ticket on it, can you open one describing what > you are seeing? (https://fedorahosted.org/freeipa/newticket) > > thanks > > rob I don't think I have access to create new tickets here: "TICKET_CREATE privileges are required to perform this operation" I usually open them on bugzilla... That's not the right place? Rgds, Siggi From dpal at redhat.com Mon Aug 22 22:03:20 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 22 Aug 2011 18:03:20 -0400 Subject: [Freeipa-users] Updating automount location name In-Reply-To: <4E52C0B4.4010803@nixtra.com> References: <4E52B330.20504@nixtra.com> <4E52B5E0.2050900@redhat.com> <4E52C0B4.4010803@nixtra.com> Message-ID: <4E52D228.7010803@redhat.com> On 08/22/2011 04:48 PM, Sigbjorn Lie wrote: > On 08/22/2011 10:02 PM, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >>> Hi, >>> >>> I receive an error when I attempt to go to Policy -> Automount -> >>> custom_location -> Settings -> Update: >>> >>> IPA Error 905 >>> >>> unknown command u'automountlocation_mod' >>> >>> Indeed the command is not available using the CLI either. A known >>> issue? >> >> Right, there is currently not a way to rename a location (no plans >> for one either unless requested). >> > Ok, I don't need it. I suggest the update button in the web interface > should be removed to avoid confusion. > > >>> >>> >>> Also, when choosing "Add" to add a map, the "Indirect" map type is >>> selected by default, however I need to click on "Direct", then >>> "Indirect" to see the "Mount point" and "Parent map" options. >>> >>> A known issue? >>> >> >> I didn't find an open ticket on it, can you open one describing what >> you are seeing? (https://fedorahosted.org/freeipa/newticket) >> >> thanks >> >> rob > > I don't think I have access to create new tickets here: > > "TICKET_CREATE privileges are required to perform this operation" > > > I usually open them on bugzilla... That's not the right place? You can do it in BZ. We will copy it over. > > Rgds, > Siggi > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Mon Aug 22 22:04:28 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 22 Aug 2011 18:04:28 -0400 Subject: [Freeipa-users] Updating automount location name In-Reply-To: <4E52C0B4.4010803@nixtra.com> References: <4E52B330.20504@nixtra.com> <4E52B5E0.2050900@redhat.com> <4E52C0B4.4010803@nixtra.com> Message-ID: <4E52D26C.8070808@redhat.com> On 08/22/2011 04:48 PM, Sigbjorn Lie wrote: > On 08/22/2011 10:02 PM, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >>> Hi, >>> >>> I receive an error when I attempt to go to Policy -> Automount -> >>> custom_location -> Settings -> Update: >>> >>> IPA Error 905 >>> >>> unknown command u'automountlocation_mod' >>> >>> Indeed the command is not available using the CLI either. A known >>> issue? >> >> Right, there is currently not a way to rename a location (no plans >> for one either unless requested). >> > Ok, I don't need it. I suggest the update button in the web interface > should be removed to avoid confusion. > And please log a bug on this one too. > >>> >>> >>> Also, when choosing "Add" to add a map, the "Indirect" map type is >>> selected by default, however I need to click on "Direct", then >>> "Indirect" to see the "Mount point" and "Parent map" options. >>> >>> A known issue? >>> >> >> I didn't find an open ticket on it, can you open one describing what >> you are seeing? (https://fedorahosted.org/freeipa/newticket) >> >> thanks >> >> rob > > I don't think I have access to create new tickets here: > > "TICKET_CREATE privileges are required to perform this operation" > > > I usually open them on bugzilla... That's not the right place? > > Rgds, > Siggi > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Mon Aug 22 22:06:49 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 22 Aug 2011 18:06:49 -0400 Subject: [Freeipa-users] IPA Automount cross-location support In-Reply-To: <4E52B1B9.6040504@nixtra.com> References: <4E52B1B9.6040504@nixtra.com> Message-ID: <4E52D2F9.8090002@redhat.com> On 08/22/2011 03:44 PM, Sigbjorn Lie wrote: > Hi, > > IPA Automount configuration: Is it possible to reference an automount > map from another location? E.g. under Policy -> Automount -> Add map > -> Parent Map: .auto.data > > Example: Let's say you have the following automount locations defined > in IPA: NewYork, Washington, Miami. Each location has it's own > auto.data map mounted under /data. > > Then making a common automount map in all the locations called > auto.global, mounted at /global, each referencing the auto.data maps > from the different IPA locations? > > /global/washington -> Washington's auto.data map > /global/newyork -> NewYork's auto.data map > /global/miami -> Miami's auto.data map > > I'm not looking for the configuration of the /global map to be > automatic, a manual configuration for pointing to each locations > auto.data map would do just fine. > > Any suggestions? > Please file an RFE. We will see what we can do down the road. > > > Regards, > Siggi > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sigbjorn at nixtra.com Tue Aug 23 15:34:15 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 23 Aug 2011 17:34:15 +0200 Subject: [Freeipa-users] Updating automount location name In-Reply-To: <4E52D26C.8070808@redhat.com> References: <4E52B330.20504@nixtra.com> <4E52B5E0.2050900@redhat.com> <4E52C0B4.4010803@nixtra.com> <4E52D26C.8070808@redhat.com> Message-ID: <4E53C877.4020500@nixtra.com> On 08/23/2011 12:04 AM, Dmitri Pal wrote: > On 08/22/2011 04:48 PM, Sigbjorn Lie wrote: >> On 08/22/2011 10:02 PM, Rob Crittenden wrote: >>> Sigbjorn Lie wrote: >>>> Hi, >>>> >>>> I receive an error when I attempt to go to Policy -> Automount -> >>>> custom_location -> Settings -> Update: >>>> >>>> IPA Error 905 >>>> >>>> unknown command u'automountlocation_mod' >>>> >>>> Indeed the command is not available using the CLI either. A known >>>> issue? >>> Right, there is currently not a way to rename a location (no plans >>> for one either unless requested). >>> >> Ok, I don't need it. I suggest the update button in the web interface >> should be removed to avoid confusion. >> > And please log a bug on this one too. > https://bugzilla.redhat.com/show_bug.cgi?id=732785 >>>> >>>> Also, when choosing "Add" to add a map, the "Indirect" map type is >>>> selected by default, however I need to click on "Direct", then >>>> "Indirect" to see the "Mount point" and "Parent map" options. >>>> >>>> A known issue? >>>> >>> I didn't find an open ticket on it, can you open one describing what >>> you are seeing? (https://fedorahosted.org/freeipa/newticket) >>> https://bugzilla.redhat.com/show_bug.cgi?id=732787 >>> thanks >>> >>> rob >> I don't think I have access to create new tickets here: >> >> "TICKET_CREATE privileges are required to perform this operation" >> >> >> I usually open them on bugzilla... That's not the right place? >> >> Rgds, >> Siggi >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > From sigbjorn at nixtra.com Tue Aug 23 15:37:28 2011 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 23 Aug 2011 17:37:28 +0200 Subject: [Freeipa-users] IPA Automount cross-location support In-Reply-To: <4E52D2F9.8090002@redhat.com> References: <4E52B1B9.6040504@nixtra.com> <4E52D2F9.8090002@redhat.com> Message-ID: <4E53C938.8090605@nixtra.com> On 08/23/2011 12:06 AM, Dmitri Pal wrote: > On 08/22/2011 03:44 PM, Sigbjorn Lie wrote: >> Hi, >> >> IPA Automount configuration: Is it possible to reference an automount >> map from another location? E.g. under Policy -> Automount -> Add map >> -> Parent Map:.auto.data >> >> Example: Let's say you have the following automount locations defined >> in IPA: NewYork, Washington, Miami. Each location has it's own >> auto.data map mounted under /data. >> >> Then making a common automount map in all the locations called >> auto.global, mounted at /global, each referencing the auto.data maps >> from the different IPA locations? >> >> /global/washington -> Washington's auto.data map >> /global/newyork -> NewYork's auto.data map >> /global/miami -> Miami's auto.data map >> >> I'm not looking for the configuration of the /global map to be >> automatic, a manual configuration for pointing to each locations >> auto.data map would do just fine. >> >> Any suggestions? >> > Please file an RFE. We will see what we can do down the road. > https://bugzilla.redhat.com/show_bug.cgi?id=732791 Thanks. From atkac at redhat.com Wed Aug 31 12:13:54 2011 From: atkac at redhat.com (Adam Tkac) Date: Wed, 31 Aug 2011 14:13:54 +0200 Subject: [Freeipa-users] bind-dyndb-ldap 1.0.0b1 has been released Message-ID: <4E5E2582.2000103@redhat.com> Hello, bind-dyndb-ldap 1.0.0b1 has been released. The most notable change is new "psearch (yes/no)" option. When set to "yes" then the plugin is able to immediately propagate addition/modification/deletion of zones, without need of the `rndc reload` command. Tarball: https://fedorahosted.org/released/bind-dyndb-ldap/bind-dyndb-ldap-1.0.0b1.tar.gz Links to Fedora updates: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-1.0.0-0.1.b1.fc16 https://admin.fedoraproject.org/updates/bind-dyndb-ldap-1.0.0-0.1.b1.fc15 Please report any bugs to https://bugzilla.redhat.com Check the NEWS file for other notable changes. Regards, Adam From simo at redhat.com Wed Aug 31 14:57:29 2011 From: simo at redhat.com (Simo Sorce) Date: Wed, 31 Aug 2011 10:57:29 -0400 Subject: [Freeipa-users] [Freeipa-devel] bind-dyndb-ldap 1.0.0b1 has been released In-Reply-To: <4E5E2582.2000103@redhat.com> References: <4E5E2582.2000103@redhat.com> Message-ID: <1314802649.20296.338.camel@willson.li.ssimo.org> On Wed, 2011-08-31 at 14:13 +0200, Adam Tkac wrote: > Hello, > > bind-dyndb-ldap 1.0.0b1 has been released. The most notable change is > new "psearch (yes/no)" option. When set to "yes" then the plugin is able > to immediately propagate addition/modification/deletion of zones, > without need of the `rndc reload` command. > > Tarball: > https://fedorahosted.org/released/bind-dyndb-ldap/bind-dyndb-ldap-1.0.0b1.tar.gz > > Links to Fedora updates: > https://admin.fedoraproject.org/updates/bind-dyndb-ldap-1.0.0-0.1.b1.fc16 > https://admin.fedoraproject.org/updates/bind-dyndb-ldap-1.0.0-0.1.b1.fc15 > > Please report any bugs to https://bugzilla.redhat.com > > Check the NEWS file for other notable changes. > > Regards, Adam Thanks Adam, this feature is really useful! Simo. -- Simo Sorce * Red Hat, Inc * New York