From email.marc at gmail.com Mon Aug 2 19:52:53 2010 From: email.marc at gmail.com (Marc Richards) Date: Mon, 02 Aug 2010 14:52:53 -0500 Subject: [Freeipa-users] Penrose and Velo Message-ID: <4C572215.8040906@gmail.com> Hi, I was wondering if somebody could shed some light on what's going on with Penrose and Velo. I see cursory mentions of it here and there in some RedHat documentation or on Bugzilla, but judging from the Fedora Hosted pages the products seem to be abandoned: https://fedorahosted.org/penrose/ and https://fedorahosted.org/velo/ The technologies seem very interesting and complimentary to FreeIPA, but the information out there is outdated at best. Is development still being done? Is there an active mainling list? Where can I download the latest versions? Is there a rough roadmap/plan? Marc From dpal at redhat.com Mon Aug 2 21:09:02 2010 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 02 Aug 2010 17:09:02 -0400 Subject: [Freeipa-users] Penrose and Velo In-Reply-To: <4C572215.8040906@gmail.com> References: <4C572215.8040906@gmail.com> Message-ID: <4C5733EE.9050605@redhat.com> Marc Richards wrote: > Hi, > > I was wondering if somebody could shed some light on what's going on > with Penrose and Velo. I see cursory mentions of it here and there in > some RedHat documentation or on Bugzilla, but judging from the Fedora > Hosted pages the products seem to be abandoned: > https://fedorahosted.org/penrose/ and https://fedorahosted.org/velo/ Both products are on a life support just not to die until we need them in the future. There are some ideas about how they can be useful in conjunction with IPA but they are a much lower level priority than letting IPA v2 out of the door. > > The technologies seem very interesting and complimentary to FreeIPA, > but the information out there is outdated at best. Is development > still being done? No development is done at the moment. > Is there an active mainling list? You are talking on the right list to change anything about the current situation. > Where can I download the latest versions? Is there a rough roadmap/plan? I think I can dig you the pointer to the source code if you are interested. As for the plan... Let us release IPA v2 first. Penrose will be very handy in some use cases but we just do not have resources to invest into this project at the moment. Velo is user provisioning. The demand for it in conjunction with IPA is yet another thing that we would to address in couple years when this demand actually materializes. But if you have any ideas or suggestions we can definitely discuss them here. > > > Marc -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From email.marc at gmail.com Mon Aug 2 21:58:22 2010 From: email.marc at gmail.com (Marc Richards) Date: Mon, 02 Aug 2010 16:58:22 -0500 Subject: [Freeipa-users] Penrose and Velo In-Reply-To: <4C5733EE.9050605@redhat.com> References: <4C572215.8040906@gmail.com> <4C5733EE.9050605@redhat.com> Message-ID: <4C573F7E.7050201@gmail.com> Well its a shame that development has ceased but I guess you guys aren't seeing the customer demand you had anticipated when you bought Identyx. I think it would be good if you at least updated those fedorahosted.org pages with the current state of things. Perhaps their is someone out there that might want to contribute or even just for curious onlookers like myself. I was able to track down these binary releases. Are these the latest versions? Penrose 2.0 - http://v1.safehaus.org:8080/display/PENROSE20/Penrose+2.0+Release Velo 1.4 - http://sourceforge.net/projects/velo/ On 08/02/2010 04:09 PM, Dmitri Pal wrote: > Marc Richards wrote: > >> Hi, >> >> I was wondering if somebody could shed some light on what's going on >> with Penrose and Velo. I see cursory mentions of it here and there in >> some RedHat documentation or on Bugzilla, but judging from the Fedora >> Hosted pages the products seem to be abandoned: >> https://fedorahosted.org/penrose/ and https://fedorahosted.org/velo/ >> > Both products are on a life support just not to die until we need them > in the future. > There are some ideas about how they can be useful in conjunction with > IPA but they are a much lower level priority than letting IPA v2 out of > the door. > > > >> The technologies seem very interesting and complimentary to FreeIPA, >> but the information out there is outdated at best. Is development >> still being done? >> > No development is done at the moment. > > >> Is there an active mainling list? >> > You are talking on the right list to change anything about the current > situation. > > >> Where can I download the latest versions? Is there a rough roadmap/plan? >> > I think I can dig you the pointer to the source code if you are interested. > As for the plan... Let us release IPA v2 first. Penrose will be very > handy in some use cases but we just do not have resources to invest into > this project at the moment. > Velo is user provisioning. The demand for it in conjunction with IPA is > yet another thing that we would to address in couple years when this > demand actually materializes. > > But if you have any ideas or suggestions we can definitely discuss them > here. > > >> >> Marc >> > > From dpal at redhat.com Tue Aug 3 13:51:20 2010 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 03 Aug 2010 09:51:20 -0400 Subject: [Freeipa-users] Penrose and Velo In-Reply-To: <4C573F7E.7050201@gmail.com> References: <4C572215.8040906@gmail.com> <4C5733EE.9050605@redhat.com> <4C573F7E.7050201@gmail.com> Message-ID: <4C581ED8.5080105@redhat.com> Marc Richards wrote: > Well its a shame that development has ceased but I guess you guys > aren't seeing the customer demand you had anticipated when you bought > Identyx. Things are complicated... I can't say more than that. One needs to learn to walk before he can run. > I think it would be good if you at least updated those > fedorahosted.org pages with the current state of things. I will see what I can do. > Perhaps their is someone out there that might want to contribute or > even just for curious onlookers like myself. Until very recently there was no interest at all... > > I was able to track down these binary releases. Are these the latest > versions? > > Penrose 2.0 - > http://v1.safehaus.org:8080/display/PENROSE20/Penrose+2.0+Release > Velo 1.4 - http://sourceforge.net/projects/velo/ > Yes. > > > On 08/02/2010 04:09 PM, Dmitri Pal wrote: >> Marc Richards wrote: >> >>> Hi, >>> >>> I was wondering if somebody could shed some light on what's going on >>> with Penrose and Velo. I see cursory mentions of it here and there in >>> some RedHat documentation or on Bugzilla, but judging from the Fedora >>> Hosted pages the products seem to be abandoned: >>> https://fedorahosted.org/penrose/ and https://fedorahosted.org/velo/ >>> >> Both products are on a life support just not to die until we need them >> in the future. >> There are some ideas about how they can be useful in conjunction with >> IPA but they are a much lower level priority than letting IPA v2 out of >> the door. >> >> >> >>> The technologies seem very interesting and complimentary to FreeIPA, >>> but the information out there is outdated at best. Is development >>> still being done? >>> >> No development is done at the moment. >> >> >>> Is there an active mainling list? >>> >> You are talking on the right list to change anything about the current >> situation. >> >> >>> Where can I download the latest versions? Is there a rough >>> roadmap/plan? >>> >> I think I can dig you the pointer to the source code if you are >> interested. >> As for the plan... Let us release IPA v2 first. Penrose will be very >> handy in some use cases but we just do not have resources to invest into >> this project at the moment. >> Velo is user provisioning. The demand for it in conjunction with IPA is >> yet another thing that we would to address in couple years when this >> demand actually materializes. >> >> But if you have any ideas or suggestions we can definitely discuss them >> here. >> >> >>> >>> Marc >>> >> >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From shan.sysadm at gmail.com Wed Aug 11 14:29:47 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Wed, 11 Aug 2010 17:29:47 +0300 Subject: [Freeipa-users] FreeIPA V2 build error Message-ID: Hi Rob, I am trying to rebuild the free IPA V2 against RHEL 6.0 beta and I installed all the build requirements as per the ipa.spec file. When I start the build it ends with bad error: ipa_repl_version.o ipa_repl_version.c:39:33: error: repl-session-plugin.h: No such file or directory ipa_repl_version.c: In function 'repl_version_plugin_start': ipa_repl_version.c:152: warning: format '%llu' expects type 'long long unsigned int', but argument 2 has type 'long int' ipa_repl_version.c: In function 'repl_version_plugin_close': ipa_repl_version.c:165: error: 'REPL_SESSION_v1_0_GUID' undeclared (first use in this function) ipa_repl_version.c:165: error: (Each undeclared identifier is reported only once ipa_repl_version.c:165: error: for each function it appears in.) ipa_repl_version.c: In function 'repl_version_plugin_init': ipa_repl_version.c:193: error: 'REPL_SESSION_v1_0_GUID' undeclared (first use in this function) make[4]: *** [ipa_repl_version.lo] Error 1 make[4]: Leaving directory `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins/ipa-version' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' make[1]: *** [all] Error 2 make[1]: Leaving directory `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' make: *** [all] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.3IIIgS (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.3IIIgS (%build) Please advice me what went worng? -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Aug 11 14:31:59 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Aug 2010 10:31:59 -0400 Subject: [Freeipa-users] FreeIPA V2 build error In-Reply-To: References: Message-ID: <4C62B45F.6070206@redhat.com> Shan Kumaraswamy wrote: > Hi Rob, > I am trying to rebuild the free IPA V2 against RHEL 6.0 beta and I > installed all the build requirements as per the ipa.spec file. When I > start the build it ends with bad error: > ipa_repl_version.o > ipa_repl_version.c:39:33: error: repl-session-plugin.h: No such file or > directory > ipa_repl_version.c: In function 'repl_version_plugin_start': > ipa_repl_version.c:152: warning: format '%llu' expects type 'long long > unsigned int', but argument 2 has type 'long int' > ipa_repl_version.c: In function 'repl_version_plugin_close': > ipa_repl_version.c:165: error: 'REPL_SESSION_v1_0_GUID' undeclared > (first use in this function) > ipa_repl_version.c:165: error: (Each undeclared identifier is reported > only once > ipa_repl_version.c:165: error: for each function it appears in.) > ipa_repl_version.c: In function 'repl_version_plugin_init': > ipa_repl_version.c:193: error: 'REPL_SESSION_v1_0_GUID' undeclared > (first use in this function) > make[4]: *** [ipa_repl_version.lo] Error 1 > make[4]: Leaving directory > `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins/ipa-version' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory > `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' > make: *** [all] Error 1 > error: Bad exit status from /var/tmp/rpm-tmp.3IIIgS (%build) > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.3IIIgS (%build) > Please advice me what went worng? > You need a newer version of 389-ds. A release candidate to be exact. 389-ds-base 1.2.6.rc7 is the latest. rob From shan.sysadm at gmail.com Wed Aug 11 14:34:42 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Wed, 11 Aug 2010 17:34:42 +0300 Subject: [Freeipa-users] FreeIPA V2 build error In-Reply-To: <4C62B45F.6070206@redhat.com> References: <4C62B45F.6070206@redhat.com> Message-ID: Rob, I am using RHDS (redhat-ds-base-devel >= 8.1.0) On Wed, Aug 11, 2010 at 5:31 PM, Rob Crittenden wrote: > Shan Kumaraswamy wrote: > >> Hi Rob, >> I am trying to rebuild the free IPA V2 against RHEL 6.0 beta and I >> installed all the build requirements as per the ipa.spec file. When I >> start the build it ends with bad error: >> ipa_repl_version.o >> ipa_repl_version.c:39:33: error: repl-session-plugin.h: No such file or >> directory >> ipa_repl_version.c: In function 'repl_version_plugin_start': >> ipa_repl_version.c:152: warning: format '%llu' expects type 'long long >> unsigned int', but argument 2 has type 'long int' >> ipa_repl_version.c: In function 'repl_version_plugin_close': >> ipa_repl_version.c:165: error: 'REPL_SESSION_v1_0_GUID' undeclared >> (first use in this function) >> ipa_repl_version.c:165: error: (Each undeclared identifier is reported >> only once >> ipa_repl_version.c:165: error: for each function it appears in.) >> ipa_repl_version.c: In function 'repl_version_plugin_init': >> ipa_repl_version.c:193: error: 'REPL_SESSION_v1_0_GUID' undeclared >> (first use in this function) >> make[4]: *** [ipa_repl_version.lo] Error 1 >> make[4]: Leaving directory >> >> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins/ipa-version' >> make[3]: *** [all-recursive] Error 1 >> make[3]: Leaving directory >> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins' >> make[2]: *** [all-recursive] Error 1 >> make[2]: Leaving directory >> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' >> make[1]: *** [all] Error 2 >> make[1]: Leaving directory >> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' >> make: *** [all] Error 1 >> error: Bad exit status from /var/tmp/rpm-tmp.3IIIgS (%build) >> >> RPM build errors: >> Bad exit status from /var/tmp/rpm-tmp.3IIIgS (%build) >> Please advice me what went worng? >> >> > You need a newer version of 389-ds. A release candidate to be exact. > 389-ds-base 1.2.6.rc7 is the latest. > > rob > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Aug 11 14:38:26 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 11 Aug 2010 08:38:26 -0600 Subject: [Freeipa-users] FreeIPA V2 build error In-Reply-To: <4C62B45F.6070206@redhat.com> References: <4C62B45F.6070206@redhat.com> Message-ID: <4C62B5E2.6070006@redhat.com> Rob Crittenden wrote: > Shan Kumaraswamy wrote: >> Hi Rob, >> I am trying to rebuild the free IPA V2 against RHEL 6.0 beta and I >> installed all the build requirements as per the ipa.spec file. When I >> start the build it ends with bad error: >> ipa_repl_version.o >> ipa_repl_version.c:39:33: error: repl-session-plugin.h: No such file or >> directory >> ipa_repl_version.c: In function 'repl_version_plugin_start': >> ipa_repl_version.c:152: warning: format '%llu' expects type 'long long >> unsigned int', but argument 2 has type 'long int' >> ipa_repl_version.c: In function 'repl_version_plugin_close': >> ipa_repl_version.c:165: error: 'REPL_SESSION_v1_0_GUID' undeclared >> (first use in this function) >> ipa_repl_version.c:165: error: (Each undeclared identifier is reported >> only once >> ipa_repl_version.c:165: error: for each function it appears in.) >> ipa_repl_version.c: In function 'repl_version_plugin_init': >> ipa_repl_version.c:193: error: 'REPL_SESSION_v1_0_GUID' undeclared >> (first use in this function) >> make[4]: *** [ipa_repl_version.lo] Error 1 >> make[4]: Leaving directory >> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins/ipa-version' >> >> make[3]: *** [all-recursive] Error 1 >> make[3]: Leaving directory >> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins' >> make[2]: *** [all-recursive] Error 1 >> make[2]: Leaving directory >> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' >> make[1]: *** [all] Error 2 >> make[1]: Leaving directory >> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' >> make: *** [all] Error 1 >> error: Bad exit status from /var/tmp/rpm-tmp.3IIIgS (%build) >> >> RPM build errors: >> Bad exit status from /var/tmp/rpm-tmp.3IIIgS (%build) >> Please advice me what went worng? >> > > You need a newer version of 389-ds. A release candidate to be exact. > 389-ds-base 1.2.6.rc7 is the latest. And there is a problem building 389-ds-base on el6 with epel - the svrcore-devel package is missing - not sure where/how this was removed because it was there at some point . . . > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rmeggins at redhat.com Wed Aug 11 14:38:58 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 11 Aug 2010 08:38:58 -0600 Subject: [Freeipa-users] FreeIPA V2 build error In-Reply-To: References: <4C62B45F.6070206@redhat.com> Message-ID: <4C62B602.3020006@redhat.com> Shan Kumaraswamy wrote: > Rob, > I am using RHDS (redhat-ds-base-devel >= 8.1.0) It will definitely not work with RHDS. > > > > > > On Wed, Aug 11, 2010 at 5:31 PM, Rob Crittenden > wrote: > > Shan Kumaraswamy wrote: > > Hi Rob, > I am trying to rebuild the free IPA V2 against RHEL 6.0 beta and I > installed all the build requirements as per the ipa.spec file. > When I > start the build it ends with bad error: > ipa_repl_version.o > ipa_repl_version.c:39:33: error: repl-session-plugin.h: No > such file or > directory > ipa_repl_version.c: In function 'repl_version_plugin_start': > ipa_repl_version.c:152: warning: format '%llu' expects type > 'long long > unsigned int', but argument 2 has type 'long int' > ipa_repl_version.c: In function 'repl_version_plugin_close': > ipa_repl_version.c:165: error: 'REPL_SESSION_v1_0_GUID' undeclared > (first use in this function) > ipa_repl_version.c:165: error: (Each undeclared identifier is > reported > only once > ipa_repl_version.c:165: error: for each function it appears in.) > ipa_repl_version.c: In function 'repl_version_plugin_init': > ipa_repl_version.c:193: error: 'REPL_SESSION_v1_0_GUID' undeclared > (first use in this function) > make[4]: *** [ipa_repl_version.lo] Error 1 > make[4]: Leaving directory > `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins/ipa-version' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory > `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' > make[1]: *** [all] Error 2 > make[1]: Leaving directory > `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' > make: *** [all] Error 1 > error: Bad exit status from /var/tmp/rpm-tmp.3IIIgS (%build) > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.3IIIgS (%build) > Please advice me what went worng? > > > You need a newer version of 389-ds. A release candidate to be > exact. 389-ds-base 1.2.6.rc7 is the latest. > > rob > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From shan.sysadm at gmail.com Wed Aug 11 14:56:00 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Wed, 11 Aug 2010 17:56:00 +0300 Subject: [Freeipa-users] FreeIPA V2 build error In-Reply-To: <4C62B602.3020006@redhat.com> References: <4C62B45F.6070206@redhat.com> <4C62B602.3020006@redhat.com> Message-ID: Rob, How about RHDS 8.2? or I have to rebuild 389-ds against RHEL 6.0 beta? On Wed, Aug 11, 2010 at 5:38 PM, Rich Megginson wrote: > Shan Kumaraswamy wrote: > >> Rob, >> I am using RHDS (redhat-ds-base-devel >= 8.1.0) >> > It will definitely not work with RHDS. > >> >> >> On Wed, Aug 11, 2010 at 5:31 PM, Rob Crittenden > rcritten at redhat.com>> wrote: >> >> Shan Kumaraswamy wrote: >> >> Hi Rob, >> I am trying to rebuild the free IPA V2 against RHEL 6.0 beta and I >> installed all the build requirements as per the ipa.spec file. >> When I >> start the build it ends with bad error: >> ipa_repl_version.o >> ipa_repl_version.c:39:33: error: repl-session-plugin.h: No >> such file or >> directory >> ipa_repl_version.c: In function 'repl_version_plugin_start': >> ipa_repl_version.c:152: warning: format '%llu' expects type >> 'long long >> unsigned int', but argument 2 has type 'long int' >> ipa_repl_version.c: In function 'repl_version_plugin_close': >> ipa_repl_version.c:165: error: 'REPL_SESSION_v1_0_GUID' undeclared >> (first use in this function) >> ipa_repl_version.c:165: error: (Each undeclared identifier is >> reported >> only once >> ipa_repl_version.c:165: error: for each function it appears in.) >> ipa_repl_version.c: In function 'repl_version_plugin_init': >> ipa_repl_version.c:193: error: 'REPL_SESSION_v1_0_GUID' undeclared >> (first use in this function) >> make[4]: *** [ipa_repl_version.lo] Error 1 >> make[4]: Leaving directory >> >> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins/ipa-version' >> make[3]: *** [all-recursive] Error 1 >> make[3]: Leaving directory >> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins' >> make[2]: *** [all-recursive] Error 1 >> make[2]: Leaving directory >> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' >> make[1]: *** [all] Error 2 >> make[1]: Leaving directory >> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' >> make: *** [all] Error 1 >> error: Bad exit status from /var/tmp/rpm-tmp.3IIIgS (%build) >> >> RPM build errors: >> Bad exit status from /var/tmp/rpm-tmp.3IIIgS (%build) >> Please advice me what went worng? >> >> >> You need a newer version of 389-ds. A release candidate to be >> exact. 389-ds-base 1.2.6.rc7 is the latest. >> >> rob >> >> >> >> >> -- >> Thanks & Regards >> Shan Kumaraswamy >> >> ------------------------------------------------------------------------ >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Aug 11 15:08:49 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 11 Aug 2010 09:08:49 -0600 Subject: [Freeipa-users] FreeIPA V2 build error In-Reply-To: References: <4C62B45F.6070206@redhat.com> <4C62B602.3020006@redhat.com> Message-ID: <4C62BD01.5060706@redhat.com> Shan Kumaraswamy wrote: > Rob, > How about RHDS 8.2? or I have to rebuild 389-ds against RHEL 6.0 beta? RHDS 8.2 won't work either. You'll have to use 389-ds-base 1.2.6 or later. > > On Wed, Aug 11, 2010 at 5:38 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > Rob, > I am using RHDS (redhat-ds-base-devel >= 8.1.0) > > It will definitely not work with RHDS. > > > > On Wed, Aug 11, 2010 at 5:31 PM, Rob Crittenden > > >> wrote: > > Shan Kumaraswamy wrote: > > Hi Rob, > I am trying to rebuild the free IPA V2 against RHEL 6.0 > beta and I > installed all the build requirements as per the > ipa.spec file. > When I > start the build it ends with bad error: > ipa_repl_version.o > ipa_repl_version.c:39:33: error: repl-session-plugin.h: No > such file or > directory > ipa_repl_version.c: In function > 'repl_version_plugin_start': > ipa_repl_version.c:152: warning: format '%llu' expects type > 'long long > unsigned int', but argument 2 has type 'long int' > ipa_repl_version.c: In function > 'repl_version_plugin_close': > ipa_repl_version.c:165: error: 'REPL_SESSION_v1_0_GUID' > undeclared > (first use in this function) > ipa_repl_version.c:165: error: (Each undeclared > identifier is > reported > only once > ipa_repl_version.c:165: error: for each function it > appears in.) > ipa_repl_version.c: In function 'repl_version_plugin_init': > ipa_repl_version.c:193: error: 'REPL_SESSION_v1_0_GUID' > undeclared > (first use in this function) > make[4]: *** [ipa_repl_version.lo] Error 1 > make[4]: Leaving directory > > `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins/ipa-version' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory > > `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' > make[1]: *** [all] Error 2 > make[1]: Leaving directory > `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' > make: *** [all] Error 1 > error: Bad exit status from /var/tmp/rpm-tmp.3IIIgS > (%build) > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.3IIIgS (%build) > Please advice me what went worng? > > > You need a newer version of 389-ds. A release candidate to be > exact. 389-ds-base 1.2.6.rc7 is the latest. > > rob > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > ------------------------------------------------------------------------ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From shan.sysadm at gmail.com Wed Aug 11 15:09:39 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Wed, 11 Aug 2010 18:09:39 +0300 Subject: [Freeipa-users] FreeIPA V2 build error In-Reply-To: <4C62BD01.5060706@redhat.com> References: <4C62B45F.6070206@redhat.com> <4C62B602.3020006@redhat.com> <4C62BD01.5060706@redhat.com> Message-ID: Thanks Rob. On Wed, Aug 11, 2010 at 6:08 PM, Rich Megginson wrote: > Shan Kumaraswamy wrote: > >> Rob, >> How about RHDS 8.2? or I have to rebuild 389-ds against RHEL 6.0 beta? >> > RHDS 8.2 won't work either. You'll have to use 389-ds-base 1.2.6 or later. > >> >> On Wed, Aug 11, 2010 at 5:38 PM, Rich Megginson > rmeggins at redhat.com>> wrote: >> >> Shan Kumaraswamy wrote: >> >> Rob, >> I am using RHDS (redhat-ds-base-devel >= 8.1.0) >> >> It will definitely not work with RHDS. >> >> >> On Wed, Aug 11, 2010 at 5:31 PM, Rob Crittenden >> >> >> wrote: >> >> Shan Kumaraswamy wrote: >> >> Hi Rob, >> I am trying to rebuild the free IPA V2 against RHEL 6.0 >> beta and I >> installed all the build requirements as per the >> ipa.spec file. >> When I >> start the build it ends with bad error: >> ipa_repl_version.o >> ipa_repl_version.c:39:33: error: repl-session-plugin.h: No >> such file or >> directory >> ipa_repl_version.c: In function >> 'repl_version_plugin_start': >> ipa_repl_version.c:152: warning: format '%llu' expects type >> 'long long >> unsigned int', but argument 2 has type 'long int' >> ipa_repl_version.c: In function >> 'repl_version_plugin_close': >> ipa_repl_version.c:165: error: 'REPL_SESSION_v1_0_GUID' >> undeclared >> (first use in this function) >> ipa_repl_version.c:165: error: (Each undeclared >> identifier is >> reported >> only once >> ipa_repl_version.c:165: error: for each function it >> appears in.) >> ipa_repl_version.c: In function 'repl_version_plugin_init': >> ipa_repl_version.c:193: error: 'REPL_SESSION_v1_0_GUID' >> undeclared >> (first use in this function) >> make[4]: *** [ipa_repl_version.lo] Error 1 >> make[4]: Leaving directory >> >> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins/ipa-version' >> make[3]: *** [all-recursive] Error 1 >> make[3]: Leaving directory >> >> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins' >> make[2]: *** [all-recursive] Error 1 >> make[2]: Leaving directory >> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' >> make[1]: *** [all] Error 2 >> make[1]: Leaving directory >> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' >> make: *** [all] Error 1 >> error: Bad exit status from /var/tmp/rpm-tmp.3IIIgS >> (%build) >> >> RPM build errors: >> Bad exit status from /var/tmp/rpm-tmp.3IIIgS (%build) >> Please advice me what went worng? >> >> >> You need a newer version of 389-ds. A release candidate to be >> exact. 389-ds-base 1.2.6.rc7 is the latest. >> >> rob >> >> >> >> >> -- Thanks & Regards >> Shan Kumaraswamy >> >> >> ------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> >> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> >> >> -- >> Thanks & Regards >> Shan Kumaraswamy >> >> > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From shan.sysadm at gmail.com Wed Aug 11 15:23:29 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Wed, 11 Aug 2010 18:23:29 +0300 Subject: [Freeipa-users] FreeIPA V2 build error In-Reply-To: References: <4C62B45F.6070206@redhat.com> <4C62B602.3020006@redhat.com> <4C62BD01.5060706@redhat.com> Message-ID: Rob, I have installed 389-ds and again I started FreeIPA build, but again some error: Provides: config(ipa-python) = 1.9.0.pre4-0.el6 Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Requires: python(abi) = 2.6 Processing files: ipa-debuginfo-1.9.0.pre4-0.el6.x86_64 Checking for unpackaged file(s): /usr/lib/rpm/check-files /root/rpmbuild/BUILDROOT/ipa-1.9.0.pre4-0.el6.x86_64 error: Installed (but unpackaged) file(s) found: /usr/lib/python2.6/site-packages/freeipa-2.0.0.alpha.0-py2.6.egg-info /usr/lib/python2.6/site-packages/ipapython-1.9.0.pre4-py2.6.egg-info RPM build errors: Installed (but unpackaged) file(s) found: /usr/lib/python2.6/site-packages/freeipa-2.0.0.alpha.0-py2.6.egg-info /usr/lib/python2.6/site-packages/ipapython-1.9.0.pre4-py2.6.egg-info On Wed, Aug 11, 2010 at 6:09 PM, Shan Kumaraswamy wrote: > Thanks Rob. > > > On Wed, Aug 11, 2010 at 6:08 PM, Rich Megginson wrote: > >> Shan Kumaraswamy wrote: >> >>> Rob, >>> How about RHDS 8.2? or I have to rebuild 389-ds against RHEL 6.0 beta? >>> >> RHDS 8.2 won't work either. You'll have to use 389-ds-base 1.2.6 or >> later. >> >>> >>> On Wed, Aug 11, 2010 at 5:38 PM, Rich Megginson >> rmeggins at redhat.com>> wrote: >>> >>> Shan Kumaraswamy wrote: >>> >>> Rob, >>> I am using RHDS (redhat-ds-base-devel >= 8.1.0) >>> >>> It will definitely not work with RHDS. >>> >>> >>> On Wed, Aug 11, 2010 at 5:31 PM, Rob Crittenden >>> >>> >> >>> wrote: >>> >>> Shan Kumaraswamy wrote: >>> >>> Hi Rob, >>> I am trying to rebuild the free IPA V2 against RHEL 6.0 >>> beta and I >>> installed all the build requirements as per the >>> ipa.spec file. >>> When I >>> start the build it ends with bad error: >>> ipa_repl_version.o >>> ipa_repl_version.c:39:33: error: repl-session-plugin.h: No >>> such file or >>> directory >>> ipa_repl_version.c: In function >>> 'repl_version_plugin_start': >>> ipa_repl_version.c:152: warning: format '%llu' expects type >>> 'long long >>> unsigned int', but argument 2 has type 'long int' >>> ipa_repl_version.c: In function >>> 'repl_version_plugin_close': >>> ipa_repl_version.c:165: error: 'REPL_SESSION_v1_0_GUID' >>> undeclared >>> (first use in this function) >>> ipa_repl_version.c:165: error: (Each undeclared >>> identifier is >>> reported >>> only once >>> ipa_repl_version.c:165: error: for each function it >>> appears in.) >>> ipa_repl_version.c: In function 'repl_version_plugin_init': >>> ipa_repl_version.c:193: error: 'REPL_SESSION_v1_0_GUID' >>> undeclared >>> (first use in this function) >>> make[4]: *** [ipa_repl_version.lo] Error 1 >>> make[4]: Leaving directory >>> >>> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins/ipa-version' >>> make[3]: *** [all-recursive] Error 1 >>> make[3]: Leaving directory >>> >>> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons/ipa-slapi-plugins' >>> make[2]: *** [all-recursive] Error 1 >>> make[2]: Leaving directory >>> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' >>> make[1]: *** [all] Error 2 >>> make[1]: Leaving directory >>> `/root/rpmbuild/BUILD/freeipa-1.9.0.pre4/daemons' >>> make: *** [all] Error 1 >>> error: Bad exit status from /var/tmp/rpm-tmp.3IIIgS >>> (%build) >>> >>> RPM build errors: >>> Bad exit status from /var/tmp/rpm-tmp.3IIIgS (%build) >>> Please advice me what went worng? >>> >>> >>> You need a newer version of 389-ds. A release candidate to be >>> exact. 389-ds-base 1.2.6.rc7 is the latest. >>> >>> rob >>> >>> >>> >>> >>> -- Thanks & Regards >>> Shan Kumaraswamy >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> >>> >>> >>> -- >>> Thanks & Regards >>> Shan Kumaraswamy >>> >>> >> > > > -- > Thanks & Regards > Shan Kumaraswamy > > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Aug 11 16:18:59 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Aug 2010 12:18:59 -0400 Subject: [Freeipa-users] FreeIPA V2 build error In-Reply-To: References: <4C62B45F.6070206@redhat.com> <4C62B602.3020006@redhat.com> <4C62BD01.5060706@redhat.com> Message-ID: <4C62CD73.1000700@redhat.com> Shan Kumaraswamy wrote: > Rob, > I have installed 389-ds and again I started FreeIPA build, but again > some error: > Provides: config(ipa-python) = 1.9.0.pre4-0.el6 > Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > Requires: python(abi) = 2.6 > Processing files: ipa-debuginfo-1.9.0.pre4-0.el6.x86_64 > Checking for unpackaged file(s): /usr/lib/rpm/check-files > /root/rpmbuild/BUILDROOT/ipa-1.9.0.pre4-0.el6.x86_64 > error: Installed (but unpackaged) file(s) found: > /usr/lib/python2.6/site-packages/freeipa-2.0.0.alpha.0-py2.6.egg-info > /usr/lib/python2.6/site-packages/ipapython-1.9.0.pre4-py2.6.egg-info > > RPM build errors: > Installed (but unpackaged) file(s) found: > /usr/lib/python2.6/site-packages/freeipa-2.0.0.alpha.0-py2.6.egg-info > /usr/lib/python2.6/site-packages/ipapython-1.9.0.pre4-py2.6.egg-info If you look in the spec file you'll see where we install the egg-info files on for Fedora > 9. Make it look like this: %if (0%{?fedora} >= 9|| 0%{?rhel} > 5) rob From danieljamesscott at gmail.com Wed Aug 11 15:32:10 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 11 Aug 2010 11:32:10 -0400 Subject: [Freeipa-users] Upgraded replication slave server - dirsrv process dying Message-ID: Hi, I have a FreeIPA slave server which used to be running Fedora 11 and has recently been upgraded to Fedora 13. It is replicating from a server which is still running Fedora 11. Twice over the last week, the process providing LDAP (dirsrv?) has died. I receive these errors in /var/log/messages: Aug 11 11:12:43 fileserver1 nscd: nss_ldap: failed to bind to LDAP server ldap://localhost: Can't contact LDAP server Aug 11 11:12:43 fileserver1 nscd: nss_ldap: could not search LDAP server - Server is unavailable This could well just be an artifact of the upgrade, since the upgrade process does not install the sssd package by default. I have no idea how nscd/sssd should be configured on a FreeIPA server. And these lines in /var/log/dirsrv/slapd-EXAMPLE-COM/errors. Around the time that LDAP requests started failing. [10/Aug/2010:10:04:41 -0400] entryrdn-index - entryrdn_index_entry: Param error: Empty entry [10/Aug/2010:10:04:42 -0400] NSMMReplicationPlugin - _delete_tombstone: unable to delete tombstone nsuniqueid=894ebf01-1dd211b2-a588d452-a70f0000,uid=djscott,cn=users,cn=accounts,dc=example,dc=com, uniqueid 894ebf01-1dd211b2-a588d452-a70f0000: Operations error. [11/Aug/2010:00:00:00 -0400] NSMMReplicationPlugin - agmt="cn=meTofileserver2.example.com636" (fileserver2:636): Incremental protocol: event update_window_opened should not occur in state wait_for_changes [11/Aug/2010:09:37:35 -0400] - slapd shutting down - signaling operation threads [11/Aug/2010:09:37:35 -0400] - slapd shutting down - waiting for 30 threads to terminate Restarting dirsrv does not appear to help, the 'stop' process fails. However, rebooting the PC does work, and the server processes LDAP requests, until the replication occurs again. With a little googling, I found this: http://directory.fedoraproject.org/wiki/Subtree_Rename#warning:_upgrade_from_389_v1.2.6_.28a.3F.2C_rc1_.7E_rc6.29_to_v1.2.6_rc6_or_newer Which could well apply in my case, but I wanted to check to ensure that this would apply to FreeIPA. Does anyone have any comments suggestions about this? Thanks, Dan Scott From rcritten at redhat.com Wed Aug 11 16:26:42 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Aug 2010 12:26:42 -0400 Subject: [Freeipa-users] Upgraded replication slave server - dirsrv process dying In-Reply-To: References: Message-ID: <4C62CF42.1040002@redhat.com> Dan Scott wrote: > Hi, > > I have a FreeIPA slave server which used to be running Fedora 11 and > has recently been upgraded to Fedora 13. It is replicating from a > server which is still running Fedora 11. > > Twice over the last week, the process providing LDAP (dirsrv?) has > died. I receive these errors in /var/log/messages: > > Aug 11 11:12:43 fileserver1 nscd: nss_ldap: failed to bind to LDAP > server ldap://localhost: Can't contact LDAP server > Aug 11 11:12:43 fileserver1 nscd: nss_ldap: could not search LDAP > server - Server is unavailable > > This could well just be an artifact of the upgrade, since the upgrade > process does not install the sssd package by default. I have no idea > how nscd/sssd should be configured on a FreeIPA server. > > And these lines in /var/log/dirsrv/slapd-EXAMPLE-COM/errors. Around > the time that LDAP requests started failing. > > [10/Aug/2010:10:04:41 -0400] entryrdn-index - entryrdn_index_entry: > Param error: Empty entry > [10/Aug/2010:10:04:42 -0400] NSMMReplicationPlugin - > _delete_tombstone: unable to delete tombstone > nsuniqueid=894ebf01-1dd211b2-a588d452-a70f0000,uid=djscott,cn=users,cn=accounts,dc=example,dc=com, > uniqueid 894ebf01-1dd211b2-a588d452-a70f0000: Operations error. > [11/Aug/2010:00:00:00 -0400] NSMMReplicationPlugin - > agmt="cn=meTofileserver2.example.com636" (fileserver2:636): > Incremental protocol: event update_window_opened should not occur in > state wait_for_changes > [11/Aug/2010:09:37:35 -0400] - slapd shutting down - signaling operation threads > [11/Aug/2010:09:37:35 -0400] - slapd shutting down - waiting for 30 > threads to terminate > > Restarting dirsrv does not appear to help, the 'stop' process fails. > However, rebooting the PC does work, and the server processes LDAP > requests, until the replication occurs again. > > With a little googling, I found this: > > http://directory.fedoraproject.org/wiki/Subtree_Rename#warning:_upgrade_from_389_v1.2.6_.28a.3F.2C_rc1_.7E_rc6.29_to_v1.2.6_rc6_or_newer > > Which could well apply in my case, but I wanted to check to ensure > that this would apply to FreeIPA. > > Does anyone have any comments suggestions about this? > > Thanks, > > Dan Scott What version of 389-ds are you running on both sides? rob From rmeggins at redhat.com Wed Aug 11 16:34:28 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 11 Aug 2010 10:34:28 -0600 Subject: [Freeipa-users] Upgraded replication slave server - dirsrv process dying In-Reply-To: References: Message-ID: <4C62D114.2020106@redhat.com> Dan Scott wrote: > Hi, > > I have a FreeIPA slave server which used to be running Fedora 11 and > has recently been upgraded to Fedora 13. It is replicating from a > server which is still running Fedora 11. > > Twice over the last week, the process providing LDAP (dirsrv?) has > died. I receive these errors in /var/log/messages: > > Aug 11 11:12:43 fileserver1 nscd: nss_ldap: failed to bind to LDAP > server ldap://localhost: Can't contact LDAP server > Aug 11 11:12:43 fileserver1 nscd: nss_ldap: could not search LDAP > server - Server is unavailable > > This could well just be an artifact of the upgrade, since the upgrade > process does not install the sssd package by default. I have no idea > how nscd/sssd should be configured on a FreeIPA server. > > And these lines in /var/log/dirsrv/slapd-EXAMPLE-COM/errors. Around > the time that LDAP requests started failing. > > [10/Aug/2010:10:04:41 -0400] entryrdn-index - entryrdn_index_entry: > Param error: Empty entry > [10/Aug/2010:10:04:42 -0400] NSMMReplicationPlugin - > _delete_tombstone: unable to delete tombstone > nsuniqueid=894ebf01-1dd211b2-a588d452-a70f0000,uid=djscott,cn=users,cn=accounts,dc=example,dc=com, > uniqueid 894ebf01-1dd211b2-a588d452-a70f0000: Operations error. > [11/Aug/2010:00:00:00 -0400] NSMMReplicationPlugin - > agmt="cn=meTofileserver2.example.com636" (fileserver2:636): > Incremental protocol: event update_window_opened should not occur in > state wait_for_changes > [11/Aug/2010:09:37:35 -0400] - slapd shutting down - signaling operation threads > [11/Aug/2010:09:37:35 -0400] - slapd shutting down - waiting for 30 > threads to terminate > > Restarting dirsrv does not appear to help, the 'stop' process fails. > However, rebooting the PC does work, and the server processes LDAP > requests, until the replication occurs again. > > With a little googling, I found this: > > http://directory.fedoraproject.org/wiki/Subtree_Rename#warning:_upgrade_from_389_v1.2.6_.28a.3F.2C_rc1_.7E_rc6.29_to_v1.2.6_rc6_or_newer > > Which could well apply in my case, but I wanted to check to ensure > that this would apply to FreeIPA. > > Does anyone have any comments suggestions about this? > The errors ""entryrdn_index_entry: Param error: Empty entry" and "_delete_tombstone: unable to delete tombstone" are bugs fixed in 389-ds-base-1.2.6.rc7. > Thanks, > > Dan Scott > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From shan.sysadm at gmail.com Wed Aug 11 16:36:38 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Wed, 11 Aug 2010 19:36:38 +0300 Subject: [Freeipa-users] FreeIPA V2 build error In-Reply-To: <4C62CD73.1000700@redhat.com> References: <4C62B45F.6070206@redhat.com> <4C62B602.3020006@redhat.com> <4C62BD01.5060706@redhat.com> <4C62CD73.1000700@redhat.com> Message-ID: Thanks Rob, the build is done successfully? :) On Wed, Aug 11, 2010 at 7:18 PM, Rob Crittenden wrote: > Shan Kumaraswamy wrote: > >> Rob, >> >> I have installed 389-ds and again I started FreeIPA build, but again >> some error: >> Provides: config(ipa-python) = 1.9.0.pre4-0.el6 >> Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 >> rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 >> rpmlib(PayloadFilesHavePrefix) <= 4.0-1 >> Requires: python(abi) = 2.6 >> Processing files: ipa-debuginfo-1.9.0.pre4-0.el6.x86_64 >> Checking for unpackaged file(s): /usr/lib/rpm/check-files >> /root/rpmbuild/BUILDROOT/ipa-1.9.0.pre4-0.el6.x86_64 >> error: Installed (but unpackaged) file(s) found: >> /usr/lib/python2.6/site-packages/freeipa-2.0.0.alpha.0-py2.6.egg-info >> /usr/lib/python2.6/site-packages/ipapython-1.9.0.pre4-py2.6.egg-info >> >> RPM build errors: >> Installed (but unpackaged) file(s) found: >> /usr/lib/python2.6/site-packages/freeipa-2.0.0.alpha.0-py2.6.egg-info >> /usr/lib/python2.6/site-packages/ipapython-1.9.0.pre4-py2.6.egg-info >> > > If you look in the spec file you'll see where we install the egg-info files > on for Fedora > 9. Make it look like this: > > %if (0%{?fedora} >= 9|| 0%{?rhel} > 5) > > rob > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.bogar at linguamatics.com Wed Aug 11 16:58:05 2010 From: attila.bogar at linguamatics.com (=?ISO-8859-1?Q?Attila_Bog=E1r?=) Date: Wed, 11 Aug 2010 17:58:05 +0100 Subject: [Freeipa-users] FreeIPA-Samba4 integration? Message-ID: <4C62D69D.1070909@linguamatics.com> Hi, I would like to deploy an integrated Samba4 / FreeIPA environment. I would like to enquire, what's the current status of FreeIPA 1.9.0.pre4 and Samba4 integration. I've tried http://freeipa.org/page/Samba_4_Configuration a month ago, though the ldap provision didn't seem to work. I've even raised a bug at Samba https://bugzilla.samba.org/show_bug.cgi?id=7530 - which is still open. If the Fedora-DS backed Samba4 isn't ready for production at this time, I would be interested in the pro/contra views of - deploying a separate Samba4 instance with filesystem backend - writing a password syncing plugin for Samba4 vs. 389-ds based on the docs at http://directory.fedoraproject.org/wiki/Plugins - other paths achieving integration? Thanks, Attila From danieljamesscott at gmail.com Wed Aug 11 17:17:14 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Wed, 11 Aug 2010 13:17:14 -0400 Subject: [Freeipa-users] Upgraded replication slave server - dirsrv process dying In-Reply-To: <4C62CF42.1040002@redhat.com> References: <4C62CF42.1040002@redhat.com> Message-ID: Hi, [root at fileserver1 ~]# rpm -qa|grep 389 389-ds-base-1.2.6-0.1.a1.fc13.i686 [djscott at fileserver2 ~]$ rpm -qa|grep 389 389-ds-base-1.2.5-1.fc11.i586 fileserver1 is the server with the problem, fileserver2 is the master. Rich Megginson's post indicates that the errors in the log are fixed in 389-ds-base-1.2.6.rc7 (I'm not sure whether that's earlier or later than 389-ds-base-1.2.6-0.1.a1 - an alpha?). Hopefully there will be an update soon, and this will resolve the problem. Thanks, Dan On Wed, Aug 11, 2010 at 12:26, Rob Crittenden wrote: > Dan Scott wrote: >> >> Hi, >> >> I have a FreeIPA slave server which used to be running Fedora 11 and >> has recently been upgraded to Fedora 13. It is replicating from a >> server which is still running Fedora 11. >> >> Twice over the last week, the process providing LDAP (dirsrv?) has >> died. I receive these errors in /var/log/messages: >> >> Aug 11 11:12:43 fileserver1 nscd: nss_ldap: failed to bind to LDAP >> server ldap://localhost: Can't contact LDAP server >> Aug 11 11:12:43 fileserver1 nscd: nss_ldap: could not search LDAP >> server - Server is unavailable >> >> This could well just be an artifact of the upgrade, since the upgrade >> process does not install the sssd package by default. I have no idea >> how nscd/sssd should be configured on a FreeIPA server. >> >> And these lines in /var/log/dirsrv/slapd-EXAMPLE-COM/errors. Around >> the time that LDAP requests started failing. >> >> [10/Aug/2010:10:04:41 -0400] entryrdn-index - entryrdn_index_entry: >> Param error: Empty entry >> [10/Aug/2010:10:04:42 -0400] NSMMReplicationPlugin - >> _delete_tombstone: unable to delete tombstone >> >> nsuniqueid=894ebf01-1dd211b2-a588d452-a70f0000,uid=djscott,cn=users,cn=accounts,dc=example,dc=com, >> uniqueid 894ebf01-1dd211b2-a588d452-a70f0000: Operations error. >> [11/Aug/2010:00:00:00 -0400] NSMMReplicationPlugin - >> agmt="cn=meTofileserver2.example.com636" (fileserver2:636): >> Incremental protocol: event update_window_opened should not occur in >> state wait_for_changes >> [11/Aug/2010:09:37:35 -0400] - slapd shutting down - signaling operation >> threads >> [11/Aug/2010:09:37:35 -0400] - slapd shutting down - waiting for 30 >> threads to terminate >> >> Restarting dirsrv does not appear to help, the 'stop' process fails. >> However, rebooting the PC does work, and the server processes LDAP >> requests, until the replication occurs again. >> >> With a little googling, I found this: >> >> >> http://directory.fedoraproject.org/wiki/Subtree_Rename#warning:_upgrade_from_389_v1.2.6_.28a.3F.2C_rc1_.7E_rc6.29_to_v1.2.6_rc6_or_newer >> >> Which could well apply in my case, but I wanted to check to ensure >> that this would apply to FreeIPA. >> >> Does anyone have any comments suggestions about this? >> >> Thanks, >> >> Dan Scott > > What version of 389-ds are you running on both sides? > > rob > From rcritten at redhat.com Wed Aug 11 19:28:30 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Aug 2010 15:28:30 -0400 Subject: [Freeipa-users] [PATCH] 510 enable compat plugin by default Message-ID: <4C62F9DE.7010307@redhat.com> This enables the compat plugin by default and moves the netgroup configuration to the standard schema compat configuration so it is enabled by default. Also add a status option to ipa-compat-manage so you can figure out what the current state is. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-510-compat.patch Type: application/mbox Size: 8146 bytes Desc: not available URL: From rmeggins at redhat.com Wed Aug 11 20:47:48 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 11 Aug 2010 14:47:48 -0600 Subject: [Freeipa-users] Upgraded replication slave server - dirsrv process dying In-Reply-To: References: <4C62CF42.1040002@redhat.com> Message-ID: <4C630C74.2010605@redhat.com> Dan Scott wrote: > Hi, > > [root at fileserver1 ~]# rpm -qa|grep 389 > 389-ds-base-1.2.6-0.1.a1.fc13.i686 > > [djscott at fileserver2 ~]$ rpm -qa|grep 389 > 389-ds-base-1.2.5-1.fc11.i586 > > fileserver1 is the server with the problem, fileserver2 is the master. > > Rich Megginson's post indicates that the errors in the log are fixed > in 389-ds-base-1.2.6.rc7 (I'm not sure whether that's earlier or later > later > than 389-ds-base-1.2.6-0.1.a1 - an alpha?). Yes, an alpha > Hopefully there will be an > update soon, and this will resolve the problem. > The update is in updates-testing now, and we would really appreciate some testing and some feedback (hint, hint). The more positive feedback we get, the faster we can move the packages to stable and out of testing (as per Fedora policy). yum update --enablerepo=updates-testing 389-ds-base See also http://directory.fedoraproject.org/wiki/Release_Notes > Thanks, > > Dan > > On Wed, Aug 11, 2010 at 12:26, Rob Crittenden wrote: > >> Dan Scott wrote: >> >>> Hi, >>> >>> I have a FreeIPA slave server which used to be running Fedora 11 and >>> has recently been upgraded to Fedora 13. It is replicating from a >>> server which is still running Fedora 11. >>> >>> Twice over the last week, the process providing LDAP (dirsrv?) has >>> died. I receive these errors in /var/log/messages: >>> >>> Aug 11 11:12:43 fileserver1 nscd: nss_ldap: failed to bind to LDAP >>> server ldap://localhost: Can't contact LDAP server >>> Aug 11 11:12:43 fileserver1 nscd: nss_ldap: could not search LDAP >>> server - Server is unavailable >>> >>> This could well just be an artifact of the upgrade, since the upgrade >>> process does not install the sssd package by default. I have no idea >>> how nscd/sssd should be configured on a FreeIPA server. >>> >>> And these lines in /var/log/dirsrv/slapd-EXAMPLE-COM/errors. Around >>> the time that LDAP requests started failing. >>> >>> [10/Aug/2010:10:04:41 -0400] entryrdn-index - entryrdn_index_entry: >>> Param error: Empty entry >>> [10/Aug/2010:10:04:42 -0400] NSMMReplicationPlugin - >>> _delete_tombstone: unable to delete tombstone >>> >>> nsuniqueid=894ebf01-1dd211b2-a588d452-a70f0000,uid=djscott,cn=users,cn=accounts,dc=example,dc=com, >>> uniqueid 894ebf01-1dd211b2-a588d452-a70f0000: Operations error. >>> [11/Aug/2010:00:00:00 -0400] NSMMReplicationPlugin - >>> agmt="cn=meTofileserver2.example.com636" (fileserver2:636): >>> Incremental protocol: event update_window_opened should not occur in >>> state wait_for_changes >>> [11/Aug/2010:09:37:35 -0400] - slapd shutting down - signaling operation >>> threads >>> [11/Aug/2010:09:37:35 -0400] - slapd shutting down - waiting for 30 >>> threads to terminate >>> >>> Restarting dirsrv does not appear to help, the 'stop' process fails. >>> However, rebooting the PC does work, and the server processes LDAP >>> requests, until the replication occurs again. >>> >>> With a little googling, I found this: >>> >>> >>> http://directory.fedoraproject.org/wiki/Subtree_Rename#warning:_upgrade_from_389_v1.2.6_.28a.3F.2C_rc1_.7E_rc6.29_to_v1.2.6_rc6_or_newer >>> >>> Which could well apply in my case, but I wanted to check to ensure >>> that this would apply to FreeIPA. >>> >>> Does anyone have any comments suggestions about this? >>> >>> Thanks, >>> >>> Dan Scott >>> >> What version of 389-ds are you running on both sides? >> >> rob >> >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From edewata at redhat.com Wed Aug 11 21:29:31 2010 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 11 Aug 2010 17:29:31 -0400 (EDT) Subject: [Freeipa-users] FreeIPA-Samba4 integration? In-Reply-To: <1411676563.1848631281561623968.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> Message-ID: <2111036143.1849291281562171864.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> Hi Attila, Attila Bog?r wrote: > I would like to deploy an integrated Samba4 / FreeIPA environment. > I would like to enquire, what's the current status of FreeIPA 1.9.0.pre4 and Samba4 integration. The integration plan that I was involved with was between IPA v3 and Samba 4. But this plan has been deferred in favor of an alternative design using Samba 3. > I've tried http://freeipa.org/page/Samba_4_Configuration a month ago, though the ldap provision > didn't seem to work. I've even raised a bug at Samba https://bugzilla.samba.org/show_bug.cgi?id=7530 > - which is still open. Yes, this is taking too long to resolve. Unfortunately the last time I tested this there was a problem in Samba 4 that was affecting other LDAP backends as well, not just specific to 389 DS. Samba 4 code is changing a lot so it's rather difficult for me to keep up with the changes especially if it happens in the core code. I plan to continue the investigation as soon as I get the chance. I'll let the others respond to the following questions: > If the Fedora-DS backed Samba4 isn't ready for production at this time, > I would be interested in the pro/contra views of > - deploying a separate Samba4 instance with filesystem backend > - writing a password syncing plugin for Samba4 vs. 389-ds > based on the docs at http://directory.fedoraproject.org/wiki/Plugins > - other paths achieving integration? Thanks. -- Endi S. Dewata From danieljamesscott at gmail.com Thu Aug 12 13:57:22 2010 From: danieljamesscott at gmail.com (Dan Scott) Date: Thu, 12 Aug 2010 09:57:22 -0400 Subject: [Freeipa-users] Upgraded replication slave server - dirsrv process dying In-Reply-To: <4C630C74.2010605@redhat.com> References: <4C62CF42.1040002@redhat.com> <4C630C74.2010605@redhat.com> Message-ID: On Wed, Aug 11, 2010 at 16:47, Rich Megginson wrote: >> Hopefully there will be an >> update soon, and this will resolve the problem. >> > > The update is in updates-testing now, and we would really appreciate some > testing and some feedback (hint, hint). ?The more positive feedback we get, > the faster we can move the packages to stable and out of testing (as per > Fedora policy). > yum update --enablerepo=updates-testing 389-ds-base > See also http://directory.fedoraproject.org/wiki/Release_Notes OK, OK, I get the hint! :) Since it's 'only' a replicated slave, I installed the package from testing. I started receiving: dn2entry: the dn "dc=example,dc=com" was in the entryrdn index, but it did not exist in id2entry of instance userRoot Which I then fixed by following: http://directory.fedoraproject.org/wiki/Subtree_Rename#warning:_upgrade_from_389_v1.2.6_.28a.3F.2C_rc1_.7E_rc6.29_to_v1.2.6_rc6_or_newer The dirsrv process started correctly and started answering requests. Looking good so far. I guess it's time to consider upgrading the master from Fedora 11. :) At least I'll be prepared if this happens again. Thanks for the help, Dan From rmeggins at redhat.com Thu Aug 12 14:05:31 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 12 Aug 2010 08:05:31 -0600 Subject: [Freeipa-users] Upgraded replication slave server - dirsrv process dying In-Reply-To: References: <4C62CF42.1040002@redhat.com> <4C630C74.2010605@redhat.com> Message-ID: <4C63FFAB.9060102@redhat.com> Dan Scott wrote: > On Wed, Aug 11, 2010 at 16:47, Rich Megginson wrote: > >>> Hopefully there will be an >>> update soon, and this will resolve the problem. >>> >>> >> The update is in updates-testing now, and we would really appreciate some >> testing and some feedback (hint, hint). The more positive feedback we get, >> the faster we can move the packages to stable and out of testing (as per >> Fedora policy). >> yum update --enablerepo=updates-testing 389-ds-base >> See also http://directory.fedoraproject.org/wiki/Release_Notes >> > > OK, OK, I get the hint! :) > > Since it's 'only' a replicated slave, I installed the package from > testing. I started receiving: > > dn2entry: the dn "dc=example,dc=com" was in the entryrdn index, but it > did not exist in id2entry of instance userRoot > > Which I then fixed by following: > > http://directory.fedoraproject.org/wiki/Subtree_Rename#warning:_upgrade_from_389_v1.2.6_.28a.3F.2C_rc1_.7E_rc6.29_to_v1.2.6_rc6_or_newer > > The dirsrv process started correctly and started answering requests. > Looking good so far. > Excellent. Thanks for the feedback. > I guess it's time to consider upgrading the master from Fedora 11. :) > At least I'll be prepared if this happens again. > > Thanks for the help, > > Dan > From rcritten at redhat.com Fri Aug 13 20:03:50 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Aug 2010 16:03:50 -0400 Subject: [Freeipa-users] [PATCH] 511 improve dogtag install feedback and add arg to pkisilent Message-ID: <4C65A526.70101@redhat.com> Break out install into more steps, add -key_algorithm to pkisilent. Installing dogtag is quite slow and it isn't always clear that things are working. This breaks out some restart calls into separate steps to show some amount of progress. There are still some steps that take more than a minute (pkicreate and pkisilent). Add new argument to pkisilent, -key_algorithm Update a bunch of minimum required versions in the spec file. tickets 139 (time) and 144 (key_algorithm) rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-511-dogtag.patch Type: application/mbox Size: 5253 bytes Desc: not available URL: From rcritten at redhat.com Fri Aug 13 20:03:55 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Aug 2010 16:03:55 -0400 Subject: [Freeipa-users] [PATCH] 512 track server certs with certmonger Message-ID: <4C65A52B.7070603@redhat.com> Have certmonger track the initial Apache and 389-ds server certs. We don't use certmonger to get certificates during installation because of the chicken-and-egg problem. This means that the IPA web and ldap certs aren't being tracked for renewal. This requires some manual changes to the certmonger request files once tracking has begun because it doesn't store a subject or principal template when a cert is added via start-tracking. This also required some changes to the cert command plugin to allow a host to execute calls against its own service certs. ticket 67 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-512-cert.patch Type: application/mbox Size: 20565 bytes Desc: not available URL: From shan.sysadm at gmail.com Sun Aug 15 12:54:04 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Sun, 15 Aug 2010 15:54:04 +0300 Subject: [Freeipa-users] FreeIPA V2 build error In-Reply-To: References: <4C62B45F.6070206@redhat.com> <4C62B602.3020006@redhat.com> <4C62BD01.5060706@redhat.com> <4C62CD73.1000700@redhat.com> Message-ID: Rob, While installing the ipa rpm's after build, I am getting this error: Preparing... ########################################### [100%] 1:ipa-server-selinux ########################################### [100%] libsepol.print_missing_requirements: ipa_dogtag's global requirements were not met: type/attribute pki_ca_t (No such file or directory). libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). semodule: Failed! Please help me to fix this issue. On Wed, Aug 11, 2010 at 7:36 PM, Shan Kumaraswamy wrote: > Thanks Rob, the build is done successfully? :) > > > > On Wed, Aug 11, 2010 at 7:18 PM, Rob Crittenden wrote: > >> Shan Kumaraswamy wrote: >> >>> Rob, >>> >>> I have installed 389-ds and again I started FreeIPA build, but again >>> some error: >>> Provides: config(ipa-python) = 1.9.0.pre4-0.el6 >>> Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 >>> rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 >>> rpmlib(PayloadFilesHavePrefix) <= 4.0-1 >>> Requires: python(abi) = 2.6 >>> Processing files: ipa-debuginfo-1.9.0.pre4-0.el6.x86_64 >>> Checking for unpackaged file(s): /usr/lib/rpm/check-files >>> /root/rpmbuild/BUILDROOT/ipa-1.9.0.pre4-0.el6.x86_64 >>> error: Installed (but unpackaged) file(s) found: >>> /usr/lib/python2.6/site-packages/freeipa-2.0.0.alpha.0-py2.6.egg-info >>> /usr/lib/python2.6/site-packages/ipapython-1.9.0.pre4-py2.6.egg-info >>> >>> RPM build errors: >>> Installed (but unpackaged) file(s) found: >>> /usr/lib/python2.6/site-packages/freeipa-2.0.0.alpha.0-py2.6.egg-info >>> /usr/lib/python2.6/site-packages/ipapython-1.9.0.pre4-py2.6.egg-info >>> >> >> If you look in the spec file you'll see where we install the egg-info >> files on for Fedora > 9. Make it look like this: >> >> %if (0%{?fedora} >= 9|| 0%{?rhel} > 5) >> >> rob >> > > > > -- > Thanks & Regards > Shan Kumaraswamy > > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Aug 16 13:18:12 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Aug 2010 09:18:12 -0400 Subject: [Freeipa-users] FreeIPA V2 build error In-Reply-To: References: <4C62B45F.6070206@redhat.com> <4C62B602.3020006@redhat.com> <4C62BD01.5060706@redhat.com> <4C62CD73.1000700@redhat.com> Message-ID: <4C693A94.8040908@redhat.com> Shan Kumaraswamy wrote: > Rob, > While installing the ipa rpm's after build, I am getting this error: > Preparing... ########################################### > [100%] > 1:ipa-server-selinux ########################################### > [100%] > libsepol.print_missing_requirements: ipa_dogtag's global requirements > were not met: type/attribute pki_ca_t (No such file or directory). > libsemanage.semanage_link_sandbox: Link packages failed (No such file or > directory). > semodule: Failed! > Please help me to fix this issue. You need dogtag installed. One of the dogtag packages provides an SELinux policy which defines pki_ca_t and we rely on that to provide our own policy. rob > > On Wed, Aug 11, 2010 at 7:36 PM, Shan Kumaraswamy > wrote: > > Thanks Rob, the build is done successfully? :) > > > On Wed, Aug 11, 2010 at 7:18 PM, Rob Crittenden > wrote: > > Shan Kumaraswamy wrote: > > Rob, > > I have installed 389-ds and again I started FreeIPA build, > but again > some error: > Provides: config(ipa-python) = 1.9.0.pre4-0.el6 > Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) > <= 4.0.4-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > Requires: python(abi) = 2.6 > Processing files: ipa-debuginfo-1.9.0.pre4-0.el6.x86_64 > Checking for unpackaged file(s): /usr/lib/rpm/check-files > /root/rpmbuild/BUILDROOT/ipa-1.9.0.pre4-0.el6.x86_64 > error: Installed (but unpackaged) file(s) found: > > /usr/lib/python2.6/site-packages/freeipa-2.0.0.alpha.0-py2.6.egg-info > > /usr/lib/python2.6/site-packages/ipapython-1.9.0.pre4-py2.6.egg-info > > RPM build errors: > Installed (but unpackaged) file(s) found: > > /usr/lib/python2.6/site-packages/freeipa-2.0.0.alpha.0-py2.6.egg-info > > /usr/lib/python2.6/site-packages/ipapython-1.9.0.pre4-py2.6.egg-info > > > If you look in the spec file you'll see where we install the > egg-info files on for Fedora > 9. Make it look like this: > > %if (0%{?fedora} >= 9|| 0%{?rhel} > 5) > > rob > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From shan.sysadm at gmail.com Mon Aug 16 13:41:31 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Mon, 16 Aug 2010 16:41:31 +0300 Subject: [Freeipa-users] IPA+AD sync error Message-ID: Hi, I have deployed FreeIPA 1.2.1 in RHEL 5.5 and I want to sync with Active Directory (windows 2008 R2). Can please anyone have step-by-step configuration doc and share to me? Previously I have done the same exercise, but now that is not working for me and I am facing lot of challenges to make this happen. Please find the steps what exactly I done so for: 1. Installed RHDS 8.1 and FreeIPA 1.2.1 and configured properly and tested its working fine 2. In AD side, installed Active Directory certificate Server as a Enterprise Root 3. Copy the ?cacert.p12? file and imported under Certificates ?Service (Active Directory Domain service) on Local Computer using MMC. 4. Installed PasSync.msi file and given all the required information 5. Run the command ?certutil -d . -L -n "CA certificate" -a > dsca.crt? from IPA server and copied the .crt file in to AD server and ran this command from ?cd "C:\Program Files\Red Hat Directory Password Synchronization" 6. certutil.exe -d . -N 7. certutil.exe -d . -A -n "DS CA cert" -t CT,, -a -i \path\to\dsca.crt 8. certutil.exe -d . -L -n "DS CA cert" and rebooted the AD server. After this steps, when try to create sync agreement from IPA server I am getting this error: ldap_simple_bind: Can't contact LDAP server SSL error -8179 (Peer's Certificate issuer is not recognized.) Please share the steps to configure AD Sync with IPA server. -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From shan.sysadm at gmail.com Mon Aug 16 13:51:45 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Mon, 16 Aug 2010 16:51:45 +0300 Subject: [Freeipa-users] FreeIPA V2 build error In-Reply-To: <4C693A94.8040908@redhat.com> References: <4C62B45F.6070206@redhat.com> <4C62B602.3020006@redhat.com> <4C62BD01.5060706@redhat.com> <4C62CD73.1000700@redhat.com> <4C693A94.8040908@redhat.com> Message-ID: Rob, After install the dogtag rpm also some error, and my SElinux policy is "Enforcing" mode: Preparing... ########################################### [100%] 1:ipa-python ########################################### [ 17%] 2:ipa-client ########################################### [ 33%] 3:ipa-admintools ########################################### [ 50%] 4:ipa-server-selinux ########################################### [ 67%] libsepol.print_missing_requirements: ipa_dogtag's global requirements were not met: type/attribute pki_ca_t (No such file or directory). libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). semodule: Failed! 5:ipa-server ########################################### [ 83%] 6:ipa-debuginfo ########################################### [100%] Please advice to fix this. On Mon, Aug 16, 2010 at 4:18 PM, Rob Crittenden wrote: > Shan Kumaraswamy wrote: > >> Rob, >> While installing the ipa rpm's after build, I am getting this error: >> Preparing... ########################################### >> [100%] >> 1:ipa-server-selinux ########################################### >> [100%] >> libsepol.print_missing_requirements: ipa_dogtag's global requirements >> were not met: type/attribute pki_ca_t (No such file or directory). >> libsemanage.semanage_link_sandbox: Link packages failed (No such file or >> directory). >> semodule: Failed! >> Please help me to fix this issue. >> > > You need dogtag installed. One of the dogtag packages provides an SELinux > policy which defines pki_ca_t and we rely on that to provide our own policy. > > rob > > >> On Wed, Aug 11, 2010 at 7:36 PM, Shan Kumaraswamy > > wrote: >> >> Thanks Rob, the build is done successfully? :) >> >> >> On Wed, Aug 11, 2010 at 7:18 PM, Rob Crittenden > > wrote: >> >> Shan Kumaraswamy wrote: >> >> Rob, >> >> I have installed 389-ds and again I started FreeIPA build, >> but again >> some error: >> Provides: config(ipa-python) = 1.9.0.pre4-0.el6 >> Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 >> rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) >> <= 4.0.4-1 >> rpmlib(PayloadFilesHavePrefix) <= 4.0-1 >> Requires: python(abi) = 2.6 >> Processing files: ipa-debuginfo-1.9.0.pre4-0.el6.x86_64 >> Checking for unpackaged file(s): /usr/lib/rpm/check-files >> /root/rpmbuild/BUILDROOT/ipa-1.9.0.pre4-0.el6.x86_64 >> error: Installed (but unpackaged) file(s) found: >> >> >> /usr/lib/python2.6/site-packages/freeipa-2.0.0.alpha.0-py2.6.egg-info >> >> >> /usr/lib/python2.6/site-packages/ipapython-1.9.0.pre4-py2.6.egg-info >> >> RPM build errors: >> Installed (but unpackaged) file(s) found: >> >> >> /usr/lib/python2.6/site-packages/freeipa-2.0.0.alpha.0-py2.6.egg-info >> >> >> /usr/lib/python2.6/site-packages/ipapython-1.9.0.pre4-py2.6.egg-info >> >> >> If you look in the spec file you'll see where we install the >> egg-info files on for Fedora > 9. Make it look like this: >> >> %if (0%{?fedora} >= 9|| 0%{?rhel} > 5) >> >> rob >> >> >> >> >> -- >> Thanks & Regards >> Shan Kumaraswamy >> >> >> >> >> -- >> Thanks & Regards >> Shan Kumaraswamy >> >> > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From kambiz at mcnc.org Mon Aug 16 13:51:56 2010 From: kambiz at mcnc.org (Kambiz Aghaiepour) Date: Mon, 16 Aug 2010 09:51:56 -0400 Subject: [Freeipa-users] IPA+AD sync error In-Reply-To: References: Message-ID: <4C69427C.6080706@mcnc.org> Do you have the correct version of the passsync.msi installed? The version I've installed that works with windows 2008 R2 installs the service under: C:\Program Files\389 Directory Password Synchronization\ The download for version 1.1.4 is located here: http://directory.fedoraproject.org/wiki/Download Also, since you are using the Certificate Server, you probably need to install the CA Cert from your AD server on the FreeIPA servers as well, so that they will trust the SSL certs on your AD servers. Kambiz Shan Kumaraswamy wrote: > Hi, > > I have deployed FreeIPA 1.2.1 in RHEL 5.5 and I want to sync with Active > Directory (windows 2008 R2). Can please anyone have step-by-step > configuration doc and share to me? Previously I have done the same exercise, > but now that is not working for me and I am facing lot of challenges to make > this happen. > > Please find the steps what exactly I done so for: > > 1. Installed RHDS 8.1 and FreeIPA 1.2.1 and configured properly and > tested its working fine > > 2. In AD side, installed Active Directory certificate Server as a > Enterprise Root > > 3. Copy the ?cacert.p12? file and imported under Certificates ?Service > (Active Directory Domain service) on Local Computer using MMC. > > 4. Installed PasSync.msi file and given all the required information > > 5. Run the command ?certutil -d . -L -n "CA certificate" -a > > dsca.crt? from IPA server and copied the .crt file in to AD server and ran > this command from ?cd "C:\Program Files\Red Hat Directory Password > Synchronization" > > 6. certutil.exe -d . -N > > 7. certutil.exe -d . -A -n "DS CA cert" -t CT,, -a -i > \path\to\dsca.crt > > 8. certutil.exe -d . -L -n "DS CA cert" and rebooted the AD server. > > After this steps, when try to create sync agreement from IPA server I am > getting this error: > > > > ldap_simple_bind: Can't contact LDAP server > > SSL error -8179 (Peer's Certificate issuer is not recognized.) > > Please share the steps to configure AD Sync with IPA server. > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- "All tyranny needs to gain a foothold is for people of good conscience to remain silent." --Thomas Jefferson From rcritten at redhat.com Mon Aug 16 14:12:10 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Aug 2010 10:12:10 -0400 Subject: [Freeipa-users] FreeIPA V2 build error In-Reply-To: References: <4C62B45F.6070206@redhat.com> <4C62B602.3020006@redhat.com> <4C62BD01.5060706@redhat.com> <4C62CD73.1000700@redhat.com> <4C693A94.8040908@redhat.com> Message-ID: <4C69473A.1020800@redhat.com> Shan Kumaraswamy wrote: > Rob, > After install the dogtag rpm also some error, and my SElinux policy is > "Enforcing" mode: > Preparing... ########################################### > [100%] > 1:ipa-python ########################################### > [ 17%] > 2:ipa-client ########################################### > [ 33%] > 3:ipa-admintools ########################################### > [ 50%] > 4:ipa-server-selinux ########################################### > [ 67%] > libsepol.print_missing_requirements: ipa_dogtag's global requirements > were not met: type/attribute pki_ca_t (No such file or directory). > libsemanage.semanage_link_sandbox: Link packages failed (No such file or > directory). > semodule: Failed! > 5:ipa-server ########################################### > [ 83%] > 6:ipa-debuginfo ########################################### > [100%] > Please advice to fix this. You need pki-selinux installed. rob > > On Mon, Aug 16, 2010 at 4:18 PM, Rob Crittenden > wrote: > > Shan Kumaraswamy wrote: > > Rob, > While installing the ipa rpm's after build, I am getting this error: > Preparing... > ########################################### > [100%] > 1:ipa-server-selinux > ########################################### > [100%] > libsepol.print_missing_requirements: ipa_dogtag's global > requirements > were not met: type/attribute pki_ca_t (No such file or directory). > libsemanage.semanage_link_sandbox: Link packages failed (No such > file or > directory). > semodule: Failed! > Please help me to fix this issue. > > > You need dogtag installed. One of the dogtag packages provides an > SELinux policy which defines pki_ca_t and we rely on that to provide > our own policy. > > rob > > > On Wed, Aug 11, 2010 at 7:36 PM, Shan Kumaraswamy > > >> > wrote: > > Thanks Rob, the build is done successfully? :) > > > On Wed, Aug 11, 2010 at 7:18 PM, Rob Crittenden > > >> wrote: > > Shan Kumaraswamy wrote: > > Rob, > > I have installed 389-ds and again I started FreeIPA > build, > but again > some error: > Provides: config(ipa-python) = 1.9.0.pre4-0.el6 > Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 > rpmlib(FileDigests) <= 4.6.0-1 > rpmlib(PartialHardlinkSets) > <= 4.0.4-1 > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > Requires: python(abi) = 2.6 > Processing files: ipa-debuginfo-1.9.0.pre4-0.el6.x86_64 > Checking for unpackaged file(s): > /usr/lib/rpm/check-files > /root/rpmbuild/BUILDROOT/ipa-1.9.0.pre4-0.el6.x86_64 > error: Installed (but unpackaged) file(s) found: > > > /usr/lib/python2.6/site-packages/freeipa-2.0.0.alpha.0-py2.6.egg-info > > > /usr/lib/python2.6/site-packages/ipapython-1.9.0.pre4-py2.6.egg-info > > RPM build errors: > Installed (but unpackaged) file(s) found: > > > /usr/lib/python2.6/site-packages/freeipa-2.0.0.alpha.0-py2.6.egg-info > > > /usr/lib/python2.6/site-packages/ipapython-1.9.0.pre4-py2.6.egg-info > > > If you look in the spec file you'll see where we install the > egg-info files on for Fedora > 9. Make it look like this: > > %if (0%{?fedora} >= 9|| 0%{?rhel} > 5) > > rob > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From shan.sysadm at gmail.com Mon Aug 16 14:34:50 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Mon, 16 Aug 2010 17:34:50 +0300 Subject: [Freeipa-users] FreeIPA V2 build error In-Reply-To: <4C69473A.1020800@redhat.com> References: <4C62B45F.6070206@redhat.com> <4C62B602.3020006@redhat.com> <4C62BD01.5060706@redhat.com> <4C62CD73.1000700@redhat.com> <4C693A94.8040908@redhat.com> <4C69473A.1020800@redhat.com> Message-ID: Rob, Again no luck... :-( Preparing... ########################################### [100%] 1:ipa-python ########################################### [ 17%] 2:ipa-client ########################################### [ 33%] 3:ipa-admintools ########################################### [ 50%] 4:ipa-server-selinux ########################################### [ 67%] libsepol.print_missing_requirements: ipa_dogtag's global requirements were not met: type/attribute pki_ca_t (No such file or directory). libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). semodule: Failed! 5:ipa-server ########################################### [ 83%] 6:ipa-debuginfo ########################################### [100%] [root at sbdipa001 x86_64]# rpm -qa pki-selinux pki-selinux-1.3.5-1.el5.noarch [root at sbdipa001 x86_64]# rpm -qa pki-* pki-util-javadoc-8.0.1-2.el6.noarch pki-setup-1.3.4-1.el5.noarch pki-silent-1.3.3-1.el5.noarch pki-ocsp-1.3.2-2.el5.noarch pki-java-tools-javadoc-1.3.1-1.el5.noarch pki-console-1.3.2-1.el5.noarch pki-ca-1.3.5-1.el6.noarch pki-tps-1.3.1-1.el5.x86_64 pki-util-8.0.1-2.el6.noarch pki-java-tools-1.3.1-1.el5.noarch pki-common-javadoc-1.3.7-1.el5.noarch pki-common-1.3.7-1.el5.noarch pki-ra-1.3.1-1.el5.noarch pki-selinux-1.3.5-1.el5.noarch pki-tks-1.3.2-1.el5.noarch pki-kra-1.3.3-1.el5.noarch pki-native-tools-1.3.0-5.el5.x86_64 On Mon, Aug 16, 2010 at 5:12 PM, Rob Crittenden wrote: > Shan Kumaraswamy wrote: > >> Rob, >> After install the dogtag rpm also some error, and my SElinux policy is >> "Enforcing" mode: >> Preparing... ########################################### >> [100%] >> 1:ipa-python ########################################### >> [ 17%] >> 2:ipa-client ########################################### >> [ 33%] >> 3:ipa-admintools ########################################### >> [ 50%] >> 4:ipa-server-selinux ########################################### >> [ 67%] >> libsepol.print_missing_requirements: ipa_dogtag's global requirements >> were not met: type/attribute pki_ca_t (No such file or directory). >> libsemanage.semanage_link_sandbox: Link packages failed (No such file or >> directory). >> semodule: Failed! >> 5:ipa-server ########################################### >> [ 83%] >> 6:ipa-debuginfo ########################################### >> [100%] >> Please advice to fix this. >> > > You need pki-selinux installed. > > rob > > >> On Mon, Aug 16, 2010 at 4:18 PM, Rob Crittenden > > wrote: >> >> Shan Kumaraswamy wrote: >> >> Rob, >> While installing the ipa rpm's after build, I am getting this >> error: >> Preparing... >> ########################################### >> [100%] >> 1:ipa-server-selinux >> ########################################### >> [100%] >> libsepol.print_missing_requirements: ipa_dogtag's global >> requirements >> were not met: type/attribute pki_ca_t (No such file or directory). >> libsemanage.semanage_link_sandbox: Link packages failed (No such >> file or >> directory). >> semodule: Failed! >> Please help me to fix this issue. >> >> >> You need dogtag installed. One of the dogtag packages provides an >> SELinux policy which defines pki_ca_t and we rely on that to provide >> our own policy. >> >> rob >> >> >> On Wed, Aug 11, 2010 at 7:36 PM, Shan Kumaraswamy >> >> >> >> >> wrote: >> >> Thanks Rob, the build is done successfully? :) >> >> >> On Wed, Aug 11, 2010 at 7:18 PM, Rob Crittenden >> >> >> wrote: >> >> Shan Kumaraswamy wrote: >> >> Rob, >> >> I have installed 389-ds and again I started FreeIPA >> build, >> but again >> some error: >> Provides: config(ipa-python) = 1.9.0.pre4-0.el6 >> Requires(rpmlib): rpmlib(CompressedFileNames) <= >> 3.0.4-1 >> rpmlib(FileDigests) <= 4.6.0-1 >> rpmlib(PartialHardlinkSets) >> <= 4.0.4-1 >> rpmlib(PayloadFilesHavePrefix) <= 4.0-1 >> Requires: python(abi) = 2.6 >> Processing files: ipa-debuginfo-1.9.0.pre4-0.el6.x86_64 >> Checking for unpackaged file(s): >> /usr/lib/rpm/check-files >> /root/rpmbuild/BUILDROOT/ipa-1.9.0.pre4-0.el6.x86_64 >> error: Installed (but unpackaged) file(s) found: >> >> >> >> /usr/lib/python2.6/site-packages/freeipa-2.0.0.alpha.0-py2.6.egg-info >> >> >> >> /usr/lib/python2.6/site-packages/ipapython-1.9.0.pre4-py2.6.egg-info >> >> RPM build errors: >> Installed (but unpackaged) file(s) found: >> >> >> >> /usr/lib/python2.6/site-packages/freeipa-2.0.0.alpha.0-py2.6.egg-info >> >> >> >> /usr/lib/python2.6/site-packages/ipapython-1.9.0.pre4-py2.6.egg-info >> >> >> If you look in the spec file you'll see where we install >> the >> egg-info files on for Fedora > 9. Make it look like this: >> >> %if (0%{?fedora} >= 9|| 0%{?rhel} > 5) >> >> rob >> >> >> >> >> -- >> Thanks & Regards >> Shan Kumaraswamy >> >> >> >> >> -- >> Thanks & Regards >> Shan Kumaraswamy >> >> >> >> >> >> -- >> Thanks & Regards >> Shan Kumaraswamy >> >> > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Aug 16 14:41:01 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 16 Aug 2010 08:41:01 -0600 Subject: [Freeipa-users] IPA+AD sync error In-Reply-To: References: Message-ID: <4C694DFD.5010006@redhat.com> Shan Kumaraswamy wrote: > > Hi, > > I have deployed FreeIPA 1.2.1 in RHEL 5.5 and I want to sync with > Active Directory (windows 2008 R2). Can please anyone have > step-by-step configuration doc and share to me? Previously I have done > the same exercise, but now that is not working for me and I am facing > lot of challenges to make this happen. > > Please find the steps what exactly I done so for: > > 1. Installed RHDS 8.1 and FreeIPA 1.2.1 and configured properly > and tested its working fine > > 2. In AD side, installed Active Directory certificate Server as > a Enterprise Root > > 3. Copy the ?cacert.p12? file and imported under Certificates > ?Service (Active Directory Domain service) on Local Computer using MMC. > > 4. Installed PasSync.msi file and given all the required information > > 5. Run the command ?certutil -d . -L -n "CA certificate" -a > > dsca.crt? from IPA server and copied the .crt file in to AD server and > ran this command from ?cd "C:\Program Files\Red Hat Directory Password > Synchronization" > > 6. certutil.exe -d . -N > > 7. certutil.exe -d . -A -n "DS CA cert" -t CT,, -a -i > \path\to\dsca.crt > > 8. certutil.exe -d . -L -n "DS CA cert" and rebooted the AD server. > > After this steps, when try to create sync agreement from IPA server I > am getting this error: > > > > ldap_simple_bind: Can't contact LDAP server > > SSL error -8179 (Peer's Certificate issuer is not recognized.) > > Please share the steps to configure AD Sync with IPA server. > http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Windows_Sync-Configuring_Windows_Sync.html But it looks as though there is a step missing. If you use MS AD CA to generate the AD cert, and use IPA to generate the IPA CA and server cert, then you have to import the MS AD CA cert into IPA. > > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From shan.sysadm at gmail.com Mon Aug 16 14:46:59 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Mon, 16 Aug 2010 17:46:59 +0300 Subject: [Freeipa-users] IPA+AD sync error In-Reply-To: <4C694DFD.5010006@redhat.com> References: <4C694DFD.5010006@redhat.com> Message-ID: Rich, While installing IPA its creates its won CA cert right? (cacert.p12), and also I done the setep of export this CA file as dsca.crt. Please let me know steps to generate the IPA CA and server cert? On Mon, Aug 16, 2010 at 5:41 PM, Rich Megginson wrote: > Shan Kumaraswamy wrote: > >> >> Hi, >> >> I have deployed FreeIPA 1.2.1 in RHEL 5.5 and I want to sync with Active >> Directory (windows 2008 R2). Can please anyone have step-by-step >> configuration doc and share to me? Previously I have done the same exercise, >> but now that is not working for me and I am facing lot of challenges to make >> this happen. >> >> Please find the steps what exactly I done so for: >> >> 1. Installed RHDS 8.1 and FreeIPA 1.2.1 and configured properly and >> tested its working fine >> >> 2. In AD side, installed Active Directory certificate Server as a >> Enterprise Root >> >> 3. Copy the ?cacert.p12? file and imported under Certificates >> ?Service (Active Directory Domain service) on Local Computer using MMC. >> >> 4. Installed PasSync.msi file and given all the required information >> >> 5. Run the command ?certutil -d . -L -n "CA certificate" -a > >> dsca.crt? from IPA server and copied the .crt file in to AD server and ran >> this command from ?cd "C:\Program Files\Red Hat Directory Password >> Synchronization" >> >> 6. certutil.exe -d . -N >> >> 7. certutil.exe -d . -A -n "DS CA cert" -t CT,, -a -i >> \path\to\dsca.crt >> >> 8. certutil.exe -d . -L -n "DS CA cert" and rebooted the AD server. >> >> After this steps, when try to create sync agreement from IPA server I am >> getting this error: >> >> >> ldap_simple_bind: Can't contact LDAP server >> >> SSL error -8179 (Peer's Certificate issuer is not recognized.) >> >> Please share the steps to configure AD Sync with IPA server. >> >> > http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Windows_Sync-Configuring_Windows_Sync.html > > But it looks as though there is a step missing. If you use MS AD CA to > generate the AD cert, and use IPA to generate the IPA CA and server cert, > then you have to import the MS AD CA cert into IPA. > >> >> >> >> >> -- >> Thanks & Regards >> Shan Kumaraswamy >> >> > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Aug 16 15:06:14 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 16 Aug 2010 09:06:14 -0600 Subject: [Freeipa-users] IPA+AD sync error In-Reply-To: References: <4C694DFD.5010006@redhat.com> Message-ID: <4C6953E6.4030500@redhat.com> Shan Kumaraswamy wrote: > Rich, > > While installing IPA its creates its won CA cert right? (cacert.p12), Right. > and also I done the setep of export this CA file as dsca.crt. Right. You have to do that so that AD can be an SSL client to the IPA SSL server. > Please let me know steps to generate the IPA CA and server cert? The other part is that you have to install the AD CA cert in IPA so that IPA can be the SSL client to the AD SSL server. > > > > > On Mon, Aug 16, 2010 at 5:41 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > > Hi, > > I have deployed FreeIPA 1.2.1 in RHEL 5.5 and I want to sync > with Active Directory (windows 2008 R2). Can please anyone > have step-by-step configuration doc and share to me? > Previously I have done the same exercise, but now that is not > working for me and I am facing lot of challenges to make this > happen. > > Please find the steps what exactly I done so for: > > 1. Installed RHDS 8.1 and FreeIPA 1.2.1 and configured > properly and tested its working fine > > 2. In AD side, installed Active Directory certificate > Server as a Enterprise Root > > 3. Copy the ?cacert.p12? file and imported under > Certificates ?Service (Active Directory Domain service) on > Local Computer using MMC. > > 4. Installed PasSync.msi file and given all the required > information > > 5. Run the command ?certutil -d . -L -n "CA certificate" > -a > dsca.crt? from IPA server and copied the .crt file in to > AD server and ran this command from ?cd "C:\Program Files\Red > Hat Directory Password Synchronization" > > 6. certutil.exe -d . -N > > 7. certutil.exe -d . -A -n "DS CA cert" -t CT,, -a -i > \path\to\dsca.crt > > 8. certutil.exe -d . -L -n "DS CA cert" and rebooted the > AD server. > > After this steps, when try to create sync agreement from IPA > server I am getting this error: > > > ldap_simple_bind: Can't contact LDAP server > > SSL error -8179 (Peer's Certificate issuer is not > recognized.) > > Please share the steps to configure AD Sync with IPA server. > > http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Windows_Sync-Configuring_Windows_Sync.html > > But it looks as though there is a step missing. If you use MS AD > CA to generate the AD cert, and use IPA to generate the IPA CA and > server cert, then you have to import the MS AD CA cert into IPA. > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From heco0701 at stcloudstate.edu Mon Aug 16 15:32:14 2010 From: heco0701 at stcloudstate.edu (Hemminger, Corey Lee. [heco0701@stcloudstate.edu]) Date: Mon, 16 Aug 2010 10:32:14 -0500 Subject: [Freeipa-users] FreeIPA v2.0 alpha4 replica installation problems Message-ID: <28D2327D43A0C84D89CF661F17B0D3A016660CC1A9@SCSU81.campus.stcloudstate.edu> Hi, I'm a student admin for St. Cloud State University's Business Computing Research Lab, and we run our own seperate network inside the campus network with dedicated internet feeds and hardware for professors research as well as masters and bachelors student research and labs. We have many computers setup for workstations, clusters, clouds, etc... and I'm trying to set up a redundant FreeIPA v2.0 in virtual box to help manage the systems and control access to machines. I have setup the master with no problems, but when creating the replica I run the command "ipa-replica-install -N --setup-dns /var/lib/ipa/replica-file-from-master" and I get this error output. It created the directory fine but is having trouble with the certs. I have disabled the firewalls on both and selinux hoping they would help but still same problem. [root at earth bcrl]# ipa-replica-install /var/lib/ipa/replica-info-earth.bcrl.stcloudstate.edu.gpg -N --setup-dns --no-forwarders An existing Directory Server has been detected. Do you wish to remove it and create a new one? [no]: yes Directory Manager (existing master) password: Warning: Hostname (earth.bcrl.stcloudstate.edu) not found in DNS Configuring directory server for the CA: [1/4]: creating directory server user [2/4]: creating directory server instance [3/4]: configuring directory to start on boot [4/4]: restarting directory server done configuring pkids. Configuring certificate server: [1/9]: creating certificate server user [2/9]: configuring certificate server instance root : CRITICAL failed to restart ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname earth.bcrl.stcloudstate.edu -cs_port 9445 -client_certdb_dir /tmp/tmp-vemQSV -client_certdb_pwd XXXXXXXX -preop_pin yhiJojW06gxaPrkvOJOK -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject "CN=ipa-ca-agent,O=IPA" -ldap_host earth.bcrl.stcloudstate.edu -ldap_port 7389 -bind_dn "cn=Directory Manager" -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name "CN=CA Subsystem,O=IPA" -ca_ocsp_cert_subject_name "CN=OCSP Subsystem,O=IPA" -ca_server_cert_subject_name "CN=earth.bcrl.stcloudstate.edu,O=IPA" -ca_audit_signing_cert_subject_name "CN=CA Audit,O=IPA" -ca_sign_cert_subject_name "CN=Certificate Authority,O=IPA" -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname zeus.bcrl.stcloudstate.edu -sd_admin_port 9445 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_uri https://zeus.bcrl.stcloudstate.edu:9444' returned non-zero exit status 255 [3/9]: creating RA agent certificate database [4/9]: importing CA chain to RA certificate database creation of replica failed: Unable to retrieve CA chain: Retrieving CA cert chain failed: Error: Failed to get certificate chain. Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Thanks for any help, Corey From rcritten at redhat.com Mon Aug 16 17:31:44 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Aug 2010 13:31:44 -0400 Subject: [Freeipa-users] FreeIPA v2.0 alpha4 replica installation problems Message-ID: <4C697600.7060703@redhat.com> I fat-fingered this moderated message and it went into the bit bucket, here it is revived. Subject: FreeIPA v2.0 alpha4 replica installation problems From: "Hemminger, Corey Lee. [heco0701 at stcloudstate.edu]" Date: Mon, 16 Aug 2010 10:32:14 -0500 To: "freeipa-users at redhat.com" Hi, I'm a student admin for St. Cloud State University's Business Computing Research Lab, and we run our own seperate network inside the campus network with dedicated internet feeds and hardware for professors research as well as masters and bachelors student research and labs. We have many computers setup for workstations, clusters, clouds, etc... and I'm trying to set up a redundant FreeIPA v2.0 in virtual box to help manage the systems and control access to machines. I have setup the master with no problems, but when creating the replica I run the command "ipa-replica-install -N --setup-dns /var/lib/ipa/replica-file-from-master" and I get this error output. It created the directory fine but is having trouble with the certs. I have disabled the firewalls on both and selinux hoping they would help but still same problem. [root at earth bcrl]# ipa-replica-install /var/lib/ipa/replica-info-earth.bcrl.stcloudstate.edu.gpg -N --setup-dns --no-forwarders An existing Directory Server has been detected. Do you wish to remove it and create a new one? [no]: yes Directory Manager (existing master) password: Warning: Hostname (earth.bcrl.stcloudstate.edu) not found in DNS Configuring directory server for the CA: [1/4]: creating directory server user [2/4]: creating directory server instance [3/4]: configuring directory to start on boot [4/4]: restarting directory server done configuring pkids. Configuring certificate server: [1/9]: creating certificate server user [2/9]: configuring certificate server instance root : CRITICAL failed to restart ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname earth.bcrl.stcloudstate.edu -cs_port 9445 -client_certdb_dir /tmp/tmp-vemQSV -client_certdb_pwd XXXXXXXX -preop_pin yhiJojW06gxaPrkvOJOK -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject "CN=ipa-ca-agent,O=IPA" -ldap_host earth.bcrl.stcloudstate.edu -ldap_port 7389 -bind_dn "cn=Directory Manager" -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name "CN=CA Subsystem,O=IPA" -ca_ocsp_cert_subject_name "CN=OCSP Subsystem,O=IPA" -ca_server_cert_subject_name "CN=earth.bcrl.stcloudstate.edu,O=IPA" -ca_audit_signing_cert_subject_name "CN=CA Audit,O=IPA" -ca_sign_cert_subject_name "CN=Certificate Autho! rity,O=IPA" -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname zeus.bcrl.stcloudstate.edu -sd_admin_port 9445 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_uri https://zeus.bcrl.stcloudstate.edu:9444' returned non-zero exit status 255 [3/9]: creating RA agent certificate database [4/9]: importing CA chain to RA certificate database creation of replica failed: Unable to retrieve CA chain: Retrieving CA cert chain failed: Error: Failed to get certificate chain. Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Thanks for any help, Corey From rcritten at redhat.com Mon Aug 16 17:35:33 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Aug 2010 13:35:33 -0400 Subject: [Freeipa-users] FreeIPA v2.0 alpha4 replica installation problems In-Reply-To: <28D2327D43A0C84D89CF661F17B0D3A016660CC1A9@SCSU81.campus.stcloudstate.edu> References: <28D2327D43A0C84D89CF661F17B0D3A016660CC1A9@SCSU81.campus.stcloudstate.edu> Message-ID: <4C6976E5.2030709@redhat.com> Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: > Hi, > I'm a student admin for St. Cloud State University's Business Computing Research Lab, and we run our own seperate network inside the campus network with dedicated internet feeds and hardware for professors research as well as masters and bachelors student research and labs. We have many computers setup for workstations, clusters, clouds, etc... and I'm trying to set up a redundant FreeIPA v2.0 in virtual box to help manage the systems and control access to machines. I have setup the master with no problems, but when creating the replica I run the command "ipa-replica-install -N --setup-dns /var/lib/ipa/replica-file-from-master" and I get this error output. It created the directory fine but is having trouble with the certs. I have disabled the firewalls on both and selinux hoping they would help but still same problem. > > [root at earth bcrl]# ipa-replica-install /var/lib/ipa/replica-info-earth.bcrl.stcloudstate.edu.gpg -N --setup-dns --no-forwarders > > An existing Directory Server has been detected. > Do you wish to remove it and create a new one? [no]: yes > Directory Manager (existing master) password: > > Warning: Hostname (earth.bcrl.stcloudstate.edu) not found in DNS > Configuring directory server for the CA: > [1/4]: creating directory server user > [2/4]: creating directory server instance > [3/4]: configuring directory to start on boot > [4/4]: restarting directory server > done configuring pkids. > Configuring certificate server: > [1/9]: creating certificate server user > [2/9]: configuring certificate server instance > root : CRITICAL failed to restart ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname earth.bcrl.stcloudstate.edu -cs_port 9445 -client_certdb_dir /tmp/tmp-vemQSV -client_certdb_pwd XXXXXXXX -preop_pin yhiJojW06gxaPrkvOJOK -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject "CN=ipa-ca-agent,O=IPA" -ldap_host earth.bcrl.stcloudstate.edu -ldap_port 7389 -bind_dn "cn=Directory Manager" -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name "CN=CA Subsystem,O=IPA" -ca_ocsp_cert_subject_name "CN=OCSP Subsystem,O=IPA" -ca_server_cert_subject_name "CN=earth.bcrl.stcloudstate.edu,O=IPA" -ca_audit_signing_cert_subject_name "CN=CA Audit,O=IPA" -ca_sign_cert_subject_name "CN=Certificate Auth o! > rity,O=IPA" -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname zeus.bcrl.stcloudstate.edu -sd_admin_port 9445 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_uri https://zeus.bcrl.stcloudstate.edu:9444' returned non-zero exit status 255 > [3/9]: creating RA agent certificate database > [4/9]: importing CA chain to RA certificate database > creation of replica failed: Unable to retrieve CA chain: Retrieving CA cert chain failed: Error: Failed to get certificate chain. > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Thanks for any help, > Corey Heh, I guess I didn't fat-finger this after all... What distro is this? What version of pki-* and dogtag-* do you have installed? Can you look at /var/log/ipareplica-install.log to see if there are any more details on the failure? /var/log/pki-ca/debug would also be a place to look though be forewarned, it is quite verbose and daunting (and has a number of red herrings, particularly warnings about cipher failures). We had some problems creating dogtag clones while creating IPA replicas in the recent pas and it would fail in the pkisilent step. This may be another case of that or it may be that our current requires don't pull in the right set of of dogtag packages. rob From rcritten at redhat.com Mon Aug 16 19:49:51 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Aug 2010 15:49:51 -0400 Subject: [Freeipa-users] FreeIPA v2.0 alpha4 replica installation problems In-Reply-To: <28D2327D43A0C84D89CF661F17B0D3A016660CC1AA@SCSU81.campus.stcloudstate.edu> References: <28D2327D43A0C84D89CF661F17B0D3A016660CC1A9@SCSU81.campus.stcloudstate.edu>, <4C6976E5.2030709@redhat.com> <28D2327D43A0C84D89CF661F17B0D3A016660CC1AA@SCSU81.campus.stcloudstate.edu> Message-ID: <4C69965F.7070301@redhat.com> Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: > I'm using fedora 13 amd-64 version. I added the developers repo from freeIPA.com for V2.0 and then did a yum install ipa-server so which ever version it installed. I'm looking at dogtag and one of the packages says 1.3.1-2.fc13 and the other 2 packages for dogtag say 1.3.2-2.fc13 for the pki dogtag package it says 1.3.7-1.fc13 all the packages read 1.3.something the pki-silent-1.3.3-1.fc13 package if that helps. I also attached the two files you asked to check. I attached the ipa-serv_deplist that i created from running "yum deplist ipa-server" and it has all the packages and version numbers. Sorry for the choppy e-mail I'm writing and looking up the stuff in pieces. Can you update the pki-* and dogtag-* packages from the updates-testing repo? There are a number of important fixes there. It is also going to break your replica install because a new required option has been added to pkisilent. You'll need to modify /usr/lib/python*/site-packages/ipaserver/install/cainstance.py Search for pkisilent. We create a python list of the command to execute. You want to patch it like this (the numbers might not exactly line up): @@ -535,6 +524,7 @@ class CAInstance(service.Service): "-db_name", "ipaca", "-key_size", "2048", "-key_type", "rsa", + "-key_algorithm", "SHA256withRSA", "-save_p12", "true", "-backup_pwd", self.admin_password, "-subsystem_name", self.service_name, You *might* be able to get away with just updating dogtag on the replica, I'm not sure. rob > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Monday, August 16, 2010 12:35 PM > To: Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FreeIPA v2.0 alpha4 replica installation problems > > Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: >> Hi, >> I'm a student admin for St. Cloud State University's Business Computing Research Lab, and we run our own seperate network inside the campus network with dedicated internet feeds and hardware for professors research as well as masters and bachelors student research and labs. We have many computers setup for workstations, clusters, clouds, etc... and I'm trying to set up a redundant FreeIPA v2.0 in virtual box to help manage the systems and control access to machines. I have setup the master with no problems, but when creating the replica I run the command "ipa-replica-install -N --setup-dns /var/lib/ipa/replica-file-from-master" and I get this error output. It created the directory fine but is having trouble with the certs. I have disabled the firewalls on both and selinux hoping they would help but still same problem. >> >> [root at earth bcrl]# ipa-replica-install /var/lib/ipa/replica-info-earth.bcrl.stcloudstate.edu.gpg -N --setup-dns --no-forwarders >> >> An existing Directory Server has been detected. >> Do you wish to remove it and create a new one? [no]: yes >> Directory Manager (existing master) password: >> >> Warning: Hostname (earth.bcrl.stcloudstate.edu) not found in DNS >> Configuring directory server for the CA: >> [1/4]: creating directory server user >> [2/4]: creating directory server instance >> [3/4]: configuring directory to start on boot >> [4/4]: restarting directory server >> done configuring pkids. >> Configuring certificate server: >> [1/9]: creating certificate server user >> [2/9]: configuring certificate server instance >> root : CRITICAL failed to restart ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname earth.bcrl.stcloudstate.edu -cs_port 9445 -client_certdb_dir /tmp/tmp-vemQSV -client_certdb_pwd XXXXXXXX -preop_pin yhiJojW06gxaPrkvOJOK -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject "CN=ipa-ca-agent,O=IPA" -ldap_host earth.bcrl.stcloudstate.edu -ldap_port 7389 -bind_dn "cn=Directory Manager" -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name "CN=CA Subsystem,O=IPA" -ca_ocsp_cert_subject_name "CN=OCSP Subsystem,O=IPA" -ca_server_cert_subject_name "CN=earth.bcrl.stcloudstate.edu,O=IPA" -ca_audit_signing_cert_subject_name "CN=CA Audit,O=IPA" -ca_sign_cert_subject_name "CN=Certificate Aut h > o! >> rity,O=IPA" -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname zeus.bcrl.stcloudstate.edu -sd_admin_port 9445 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_uri https://zeus.bcrl.stcloudstate.edu:9444' returned non-zero exit status 255 >> [3/9]: creating RA agent certificate database >> [4/9]: importing CA chain to RA certificate database >> creation of replica failed: Unable to retrieve CA chain: Retrieving CA cert chain failed: Error: Failed to get certificate chain. >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> Thanks for any help, >> Corey > > Heh, I guess I didn't fat-finger this after all... > > What distro is this? > > What version of pki-* and dogtag-* do you have installed? Can you look > at /var/log/ipareplica-install.log to see if there are any more details > on the failure? /var/log/pki-ca/debug would also be a place to look > though be forewarned, it is quite verbose and daunting (and has a number > of red herrings, particularly warnings about cipher failures). > > We had some problems creating dogtag clones while creating IPA replicas > in the recent pas and it would fail in the pkisilent step. This may be > another case of that or it may be that our current requires don't pull > in the right set of of dogtag packages. > > rob From heco0701 at stcloudstate.edu Mon Aug 16 19:13:33 2010 From: heco0701 at stcloudstate.edu (Hemminger, Corey Lee. [heco0701@stcloudstate.edu]) Date: Mon, 16 Aug 2010 14:13:33 -0500 Subject: [Freeipa-users] FreeIPA v2.0 alpha4 replica installation problems In-Reply-To: <4C6976E5.2030709@redhat.com> References: <28D2327D43A0C84D89CF661F17B0D3A016660CC1A9@SCSU81.campus.stcloudstate.edu>, <4C6976E5.2030709@redhat.com> Message-ID: <28D2327D43A0C84D89CF661F17B0D3A016660CC1AA@SCSU81.campus.stcloudstate.edu> I'm using fedora 13 amd-64 version. I added the developers repo from freeIPA.com for V2.0 and then did a yum install ipa-server so which ever version it installed. I'm looking at dogtag and one of the packages says 1.3.1-2.fc13 and the other 2 packages for dogtag say 1.3.2-2.fc13 for the pki dogtag package it says 1.3.7-1.fc13 all the packages read 1.3.something the pki-silent-1.3.3-1.fc13 package if that helps. I also attached the two files you asked to check. I attached the ipa-serv_deplist that i created from running "yum deplist ipa-server" and it has all the packages and version numbers. Sorry for the choppy e-mail I'm writing and looking up the stuff in pieces. ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Monday, August 16, 2010 12:35 PM To: Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FreeIPA v2.0 alpha4 replica installation problems Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: > Hi, > I'm a student admin for St. Cloud State University's Business Computing Research Lab, and we run our own seperate network inside the campus network with dedicated internet feeds and hardware for professors research as well as masters and bachelors student research and labs. We have many computers setup for workstations, clusters, clouds, etc... and I'm trying to set up a redundant FreeIPA v2.0 in virtual box to help manage the systems and control access to machines. I have setup the master with no problems, but when creating the replica I run the command "ipa-replica-install -N --setup-dns /var/lib/ipa/replica-file-from-master" and I get this error output. It created the directory fine but is having trouble with the certs. I have disabled the firewalls on both and selinux hoping they would help but still same problem. > > [root at earth bcrl]# ipa-replica-install /var/lib/ipa/replica-info-earth.bcrl.stcloudstate.edu.gpg -N --setup-dns --no-forwarders > > An existing Directory Server has been detected. > Do you wish to remove it and create a new one? [no]: yes > Directory Manager (existing master) password: > > Warning: Hostname (earth.bcrl.stcloudstate.edu) not found in DNS > Configuring directory server for the CA: > [1/4]: creating directory server user > [2/4]: creating directory server instance > [3/4]: configuring directory to start on boot > [4/4]: restarting directory server > done configuring pkids. > Configuring certificate server: > [1/9]: creating certificate server user > [2/9]: configuring certificate server instance > root : CRITICAL failed to restart ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname earth.bcrl.stcloudstate.edu -cs_port 9445 -client_certdb_dir /tmp/tmp-vemQSV -client_certdb_pwd XXXXXXXX -preop_pin yhiJojW06gxaPrkvOJOK -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject "CN=ipa-ca-agent,O=IPA" -ldap_host earth.bcrl.stcloudstate.edu -ldap_port 7389 -bind_dn "cn=Directory Manager" -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name "CN=CA Subsystem,O=IPA" -ca_ocsp_cert_subject_name "CN=OCSP Subsystem,O=IPA" -ca_server_cert_subject_name "CN=earth.bcrl.stcloudstate.edu,O=IPA" -ca_audit_signing_cert_subject_name "CN=CA Audit,O=IPA" -ca_sign_cert_subject_name "CN=Certificate Auth o! > rity,O=IPA" -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname zeus.bcrl.stcloudstate.edu -sd_admin_port 9445 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_uri https://zeus.bcrl.stcloudstate.edu:9444' returned non-zero exit status 255 > [3/9]: creating RA agent certificate database > [4/9]: importing CA chain to RA certificate database > creation of replica failed: Unable to retrieve CA chain: Retrieving CA cert chain failed: Error: Failed to get certificate chain. > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Thanks for any help, > Corey Heh, I guess I didn't fat-finger this after all... What distro is this? What version of pki-* and dogtag-* do you have installed? Can you look at /var/log/ipareplica-install.log to see if there are any more details on the failure? /var/log/pki-ca/debug would also be a place to look though be forewarned, it is quite verbose and daunting (and has a number of red herrings, particularly warnings about cipher failures). We had some problems creating dogtag clones while creating IPA replicas in the recent pas and it would fail in the pkisilent step. This may be another case of that or it may be that our current requires don't pull in the right set of of dogtag packages. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: debug Type: application/octet-stream Size: 1181292 bytes Desc: debug URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipareplica-install.log Type: text/x-log Size: 66642 bytes Desc: ipareplica-install.log URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa-server_deplist Type: application/octet-stream Size: 6850 bytes Desc: ipa-server_deplist URL: From heco0701 at stcloudstate.edu Mon Aug 16 21:05:16 2010 From: heco0701 at stcloudstate.edu (Hemminger, Corey Lee. [heco0701@stcloudstate.edu]) Date: Mon, 16 Aug 2010 16:05:16 -0500 Subject: [Freeipa-users] FreeIPA v2.0 alpha4 replica installation problems In-Reply-To: <4C69965F.7070301@redhat.com> References: <28D2327D43A0C84D89CF661F17B0D3A016660CC1A9@SCSU81.campus.stcloudstate.edu>, <4C6976E5.2030709@redhat.com> <28D2327D43A0C84D89CF661F17B0D3A016660CC1AA@SCSU81.campus.stcloudstate.edu>, <4C69965F.7070301@redhat.com> Message-ID: <28D2327D43A0C84D89CF661F17B0D3A016660CC1AB@SCSU81.campus.stcloudstate.edu> ok I did the updates, and edited the python files. Now when I try to run the replica install I get: [root at earth bcrl]# ipa-replica-install /var/lib/ipa/replica-info-earth.bcrl.stcloudstate.edu.gpg -N --setup-dns --no-forwarder Directory Manager (existing master) password: root : ERROR Cannot find Reverse Address for earth.bcrl.stcloudstate.edu (3.2.0.10.in-addr.arpa.) I had this when installing the ipa-server and there was a --no-dns-lookup option but not with the replica. Before the testing updates, i did get a warning about the server not working for DNS lookup but still went ahead with install. I'm looking to set these two up and make them the DNS servers and currently have a simple dns setup that will get replaced by this setup. How do I get around the reverse address lookup on the replica install side. Thanks again for all the help. Corey- ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Monday, August 16, 2010 2:49 PM To: Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] FreeIPA v2.0 alpha4 replica installation problems Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: > I'm using fedora 13 amd-64 version. I added the developers repo from freeIPA.com for V2.0 and then did a yum install ipa-server so which ever version it installed. I'm looking at dogtag and one of the packages says 1.3.1-2.fc13 and the other 2 packages for dogtag say 1.3.2-2.fc13 for the pki dogtag package it says 1.3.7-1.fc13 all the packages read 1.3.something the pki-silent-1.3.3-1.fc13 package if that helps. I also attached the two files you asked to check. I attached the ipa-serv_deplist that i created from running "yum deplist ipa-server" and it has all the packages and version numbers. Sorry for the choppy e-mail I'm writing and looking up the stuff in pieces. Can you update the pki-* and dogtag-* packages from the updates-testing repo? There are a number of important fixes there. It is also going to break your replica install because a new required option has been added to pkisilent. You'll need to modify /usr/lib/python*/site-packages/ipaserver/install/cainstance.py Search for pkisilent. We create a python list of the command to execute. You want to patch it like this (the numbers might not exactly line up): @@ -535,6 +524,7 @@ class CAInstance(service.Service): "-db_name", "ipaca", "-key_size", "2048", "-key_type", "rsa", + "-key_algorithm", "SHA256withRSA", "-save_p12", "true", "-backup_pwd", self.admin_password, "-subsystem_name", self.service_name, You *might* be able to get away with just updating dogtag on the replica, I'm not sure. rob > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Monday, August 16, 2010 12:35 PM > To: Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FreeIPA v2.0 alpha4 replica installation problems > > Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: >> Hi, >> I'm a student admin for St. Cloud State University's Business Computing Research Lab, and we run our own seperate network inside the campus network with dedicated internet feeds and hardware for professors research as well as masters and bachelors student research and labs. We have many computers setup for workstations, clusters, clouds, etc... and I'm trying to set up a redundant FreeIPA v2.0 in virtual box to help manage the systems and control access to machines. I have setup the master with no problems, but when creating the replica I run the command "ipa-replica-install -N --setup-dns /var/lib/ipa/replica-file-from-master" and I get this error output. It created the directory fine but is having trouble with the certs. I have disabled the firewalls on both and selinux hoping they would help but still same problem. >> >> [root at earth bcrl]# ipa-replica-install /var/lib/ipa/replica-info-earth.bcrl.stcloudstate.edu.gpg -N --setup-dns --no-forwarders >> >> An existing Directory Server has been detected. >> Do you wish to remove it and create a new one? [no]: yes >> Directory Manager (existing master) password: >> >> Warning: Hostname (earth.bcrl.stcloudstate.edu) not found in DNS >> Configuring directory server for the CA: >> [1/4]: creating directory server user >> [2/4]: creating directory server instance >> [3/4]: configuring directory to start on boot >> [4/4]: restarting directory server >> done configuring pkids. >> Configuring certificate server: >> [1/9]: creating certificate server user >> [2/9]: configuring certificate server instance >> root : CRITICAL failed to restart ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname earth.bcrl.stcloudstate.edu -cs_port 9445 -client_certdb_dir /tmp/tmp-vemQSV -client_certdb_pwd XXXXXXXX -preop_pin yhiJojW06gxaPrkvOJOK -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject "CN=ipa-ca-agent,O=IPA" -ldap_host earth.bcrl.stcloudstate.edu -ldap_port 7389 -bind_dn "cn=Directory Manager" -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name "CN=CA Subsystem,O=IPA" -ca_ocsp_cert_subject_name "CN=OCSP Subsystem,O=IPA" -ca_server_cert_subject_name "CN=earth.bcrl.stcloudstate.edu,O=IPA" -ca_audit_signing_cert_subject_name "CN=CA Audit,O=IPA" -ca_sign_cert_subject_name "CN=Certificate Aut h > o! >> rity,O=IPA" -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname zeus.bcrl.stcloudstate.edu -sd_admin_port 9445 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_uri https://zeus.bcrl.stcloudstate.edu:9444' returned non-zero exit status 255 >> [3/9]: creating RA agent certificate database >> [4/9]: importing CA chain to RA certificate database >> creation of replica failed: Unable to retrieve CA chain: Retrieving CA cert chain failed: Error: Failed to get certificate chain. >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> Thanks for any help, >> Corey > > Heh, I guess I didn't fat-finger this after all... > > What distro is this? > > What version of pki-* and dogtag-* do you have installed? Can you look > at /var/log/ipareplica-install.log to see if there are any more details > on the failure? /var/log/pki-ca/debug would also be a place to look > though be forewarned, it is quite verbose and daunting (and has a number > of red herrings, particularly warnings about cipher failures). > > We had some problems creating dogtag clones while creating IPA replicas > in the recent pas and it would fail in the pkisilent step. This may be > another case of that or it may be that our current requires don't pull > in the right set of of dogtag packages. > > rob From shan.sysadm at gmail.com Tue Aug 17 11:02:58 2010 From: shan.sysadm at gmail.com (Shan Kumaraswamy) Date: Tue, 17 Aug 2010 14:02:58 +0300 Subject: [Freeipa-users] IPA+AD sync error In-Reply-To: <4C6953E6.4030500@redhat.com> References: <4C694DFD.5010006@redhat.com> <4C6953E6.4030500@redhat.com> Message-ID: Hi Rich, After I did all the steps, I am getting this error: INFO:root:Added CA certificate /etc/dirsrv/slapd-XXXX-COM/adcert.cer to certificate database for tesipa001.test.com INFO:root:Restarted directory server tesipa001.test.com INFO:root:Could not validate connection to remote server windows.test.ad:636- continuing INFO:root:The error was: {'info': 'error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', 'desc': "Can't contact LDAP server"} The user for the Windows PassSync service is uid=passsync,cn=sysaccounts,cn=etc,dc=bmibank,dc=com Windows PassSync entry exists, not resetting password INFO:root:Added new sync agreement, waiting for it to become ready . . . INFO:root:Replication Update in progress: FALSE: status: 81 - LDAP error: Can't contact LDAP server: start: 0: end: 0 INFO:root:Agreement is ready, starting replication . . . Starting replication, please wait until this has completed. [saprhds001.bmibank.com] reports: Update failed! Status: [81 - LDAP error: Can't contact LDAP server] INFO:root:Added agreement for other host windows.test.ad Please help me to fix this issue. The syntex I used: ipa-replica-manage add --winsync --binddn CN=Administrator,CN=Users,DC=test,DC=com --bindpw "password" --cacert /etc/dirsrv/slapd-TEST-COM/adcert.cer windows.test.ad -v --passsync "password" On Mon, Aug 16, 2010 at 6:06 PM, Rich Megginson wrote: > Shan Kumaraswamy wrote: > >> Rich, >> While installing IPA its creates its won CA cert right? (cacert.p12), >> > Right. > > and also I done the setep of export this CA file as dsca.crt. >> > Right. You have to do that so that AD can be an SSL client to the IPA SSL > server. > > Please let me know steps to generate the IPA CA and server cert? >> > The other part is that you have to install the AD CA cert in IPA so that > IPA can be the SSL client to the AD SSL server. > > >> >> On Mon, Aug 16, 2010 at 5:41 PM, Rich Megginson > rmeggins at redhat.com>> wrote: >> >> Shan Kumaraswamy wrote: >> >> >> Hi, >> >> I have deployed FreeIPA 1.2.1 in RHEL 5.5 and I want to sync >> with Active Directory (windows 2008 R2). Can please anyone >> have step-by-step configuration doc and share to me? >> Previously I have done the same exercise, but now that is not >> working for me and I am facing lot of challenges to make this >> happen. >> >> Please find the steps what exactly I done so for: >> >> 1. Installed RHDS 8.1 and FreeIPA 1.2.1 and configured >> properly and tested its working fine >> >> 2. In AD side, installed Active Directory certificate >> Server as a Enterprise Root >> >> 3. Copy the ?cacert.p12? file and imported under >> Certificates ?Service (Active Directory Domain service) on >> Local Computer using MMC. >> >> 4. Installed PasSync.msi file and given all the required >> information >> >> 5. Run the command ?certutil -d . -L -n "CA certificate" >> -a > dsca.crt? from IPA server and copied the .crt file in to >> AD server and ran this command from ?cd "C:\Program Files\Red >> Hat Directory Password Synchronization" >> >> 6. certutil.exe -d . -N >> >> 7. certutil.exe -d . -A -n "DS CA cert" -t CT,, -a -i >> \path\to\dsca.crt >> >> 8. certutil.exe -d . -L -n "DS CA cert" and rebooted the >> AD server. >> >> After this steps, when try to create sync agreement from IPA >> server I am getting this error: >> >> ldap_simple_bind: Can't contact LDAP server >> >> SSL error -8179 (Peer's Certificate issuer is not >> recognized.) >> >> Please share the steps to configure AD Sync with IPA server. >> >> >> http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Windows_Sync-Configuring_Windows_Sync.html >> >> But it looks as though there is a step missing. If you use MS AD >> CA to generate the AD cert, and use IPA to generate the IPA CA and >> server cert, then you have to import the MS AD CA cert into IPA. >> >> >> >> -- Thanks & Regards >> Shan Kumaraswamy >> >> >> >> >> >> -- >> Thanks & Regards >> Shan Kumaraswamy >> >> > -- Thanks & Regards Shan Kumaraswamy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Aug 17 15:35:36 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 17 Aug 2010 09:35:36 -0600 Subject: [Freeipa-users] IPA+AD sync error In-Reply-To: References: <4C694DFD.5010006@redhat.com> <4C6953E6.4030500@redhat.com> Message-ID: <4C6AAC48.1050006@redhat.com> Shan Kumaraswamy wrote: > After this error, I have triyed your the following steps: > > /usr/lib64/mozldap/ldapsearch -h windows.test.ad > -D "CN=administrator,CN=users,DC=test,DC=ad" > -w "xxxx" -s base -b "" "objectclass=*" > > Then I got output like this: > > > version: 1 > dn: > currentTime: 20100817220245.0Z > subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=test,DC=ad > dsServiceName: CN=NTDS > Settings,CN=WINDOWS,CN=Servers,CN=Default-First-Site-Na > me,CN=Sites,CN=Configuration,DC=test,DC=ad > namingContexts: DC=test,DC=ad > namingContexts: CN=Configuration,DC=test,DC=ad > namingContexts: CN=Schema,CN=Configuration,DC=test,DC=ad > namingContexts: DC=DomainDnsZones,DC=test,DC=ad > namingContexts: DC=ForestDnsZones,DC=test,DC=ad > defaultNamingContext: DC=test,DC=ad > schemaNamingContext: CN=Schema,CN=Configuration,DC=test,DC=ad > configurationNamingContext: CN=Configuration,DC=test,DC=ad > rootDomainNamingContext: DC=test,DC=ad > supportedControl: 1.2.840.113556.1.4.319 > supportedControl: 1.2.840.113556.1.4.801 > supportedControl: 1.2.840.113556.1.4.473 > supportedControl: 1.2.840.113556.1.4.528 > supportedControl: 1.2.840.113556.1.4.417 > supportedControl: 1.2.840.113556.1.4.619 > supportedControl: 1.2.840.113556.1.4.841 > supportedControl: 1.2.840.113556.1.4.529 > supportedControl: 1.2.840.113556.1.4.805 > supportedControl: 1.2.840.113556.1.4.521 > supportedControl: 1.2.840.113556.1.4.970 > supportedControl: 1.2.840.113556.1.4.1338 > supportedControl: 1.2.840.113556.1.4.474 > supportedControl: 1.2.840.113556.1.4.1339 > supportedControl: 1.2.840.113556.1.4.1340 > supportedControl: 1.2.840.113556.1.4.1413 > supportedControl: 2.16.840.1.113730.3.4.9 > supportedControl: 2.16.840.1.113730.3.4.10 > supportedControl: 1.2.840.113556.1.4.1504 > supportedControl: 1.2.840.113556.1.4.1852 > supportedControl: 1.2.840.113556.1.4.802 > supportedControl: 1.2.840.113556.1.4.1907 > supportedControl: 1.2.840.113556.1.4.1948 > supportedControl: 1.2.840.113556.1.4.1974 > supportedControl: 1.2.840.113556.1.4.1341 > supportedControl: 1.2.840.113556.1.4.2026 > supportedControl: 1.2.840.113556.1.4.2064 > supportedControl: 1.2.840.113556.1.4.2065 > supportedLDAPVersion: 3 > supportedLDAPVersion: 2 > supportedLDAPPolicies: MaxPoolThreads > supportedLDAPPolicies: MaxDatagramRecv > supportedLDAPPolicies: MaxReceiveBuffer > supportedLDAPPolicies: InitRecvTimeout > supportedLDAPPolicies: MaxConnections > supportedLDAPPolicies: MaxConnIdleTime > supportedLDAPPolicies: MaxPageSize > supportedLDAPPolicies: MaxQueryDuration > supportedLDAPPolicies: MaxTempTableSize > supportedLDAPPolicies: MaxResultSetSize > supportedLDAPPolicies: MinResultSets > supportedLDAPPolicies: MaxResultSetsPerConn > supportedLDAPPolicies: MaxNotificationPerConn > supportedLDAPPolicies: MaxValRange > highestCommittedUSN: 73772 > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: GSS-SPNEGO > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: DIGEST-MD5 > dnsHostName: Windows.test.ad > ldapServiceName: test.ad:windows$@TEST.AD > serverName: > CN=WINDOWS,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Confi > guration,DC=test,DC=ad > supportedCapabilities: 1.2.840.113556.1.4.800 > supportedCapabilities: 1.2.840.113556.1.4.1670 > supportedCapabilities: 1.2.840.113556.1.4.1791 > supportedCapabilities: 1.2.840.113556.1.4.1935 > supportedCapabilities: 1.2.840.113556.1.4.2080 > isSynchronized: TRUE > isGlobalCatalogReady: TRUE > domainFunctionality: 4 > forestFunctionality: 4 > domainControllerFunctionality: 4 > > Then I tried next step: > > /usr/lib64/mozldap/ldapsearch -ZZ -P > /etc/dirsrv/slapd-XXXX-COM/cert8.db -h windows.test.ad > -D "CN=administrator,CN=users,DC=test,DC=ad" > -w "xxxxx" -s base -b "" "objectclass=*" > ldap_simple_bind: Can't contact LDAP server > TLS/SSL error -8179 (Peer's Certificate issuer is not recognized.) > > Please help me to fix this..... This usually means the SSL server's CA cert is not recognized. What does this say: certutil -d /etc/dirsrv/slapd-XXXX-COM -L ? > > > On Tue, Aug 17, 2010 at 2:02 PM, Shan Kumaraswamy > > wrote: > > Hi Rich, > After I did all the steps, I am getting this error: > > > INFO:root:Added CA certificate > /etc/dirsrv/slapd-XXXX-COM/adcert.cer to certificate database for > tesipa001.test.com > INFO:root:Restarted directory server tesipa001.test.com > > INFO:root:Could not validate connection to remote server > windows.test.ad:636 - continuing > INFO:root:The error was: {'info': 'error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed', > 'desc': "Can't contact LDAP server"} > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=bmibank,dc=com > Windows PassSync entry exists, not resetting password > INFO:root:Added new sync agreement, waiting for it to become ready > . . . > INFO:root:Replication Update in progress: FALSE: status: 81 - > LDAP error: Can't contact LDAP server: start: 0: end: 0 > INFO:root:Agreement is ready, starting replication . . . > Starting replication, please wait until this has completed. > [saprhds001.bmibank.com ] reports: > Update failed! Status: [81 - LDAP error: Can't contact LDAP server] > INFO:root:Added agreement for other host windows.test.ad > > > Please help me to fix this issue. > > The syntex I used: ipa-replica-manage add --winsync --binddn > CN=Administrator,CN=Users,DC=test,DC=com --bindpw "password" > --cacert /etc/dirsrv/slapd-TEST-COM/adcert.cer windows.test.ad > -v --passsync "password" > > > > On Mon, Aug 16, 2010 at 6:06 PM, Rich Megginson > > wrote: > > Shan Kumaraswamy wrote: > > Rich, > While installing IPA its creates its won CA cert right? > (cacert.p12), > > Right. > > and also I done the setep of export this CA file as dsca.crt. > > Right. You have to do that so that AD can be an SSL client to > the IPA SSL server. > > Please let me know steps to generate the IPA CA and server > cert? > > The other part is that you have to install the AD CA cert in > IPA so that IPA can be the SSL client to the AD SSL server. > > > > On Mon, Aug 16, 2010 at 5:41 PM, Rich Megginson > > >> > wrote: > > Shan Kumaraswamy wrote: > > > Hi, > > I have deployed FreeIPA 1.2.1 in RHEL 5.5 and I > want to sync > with Active Directory (windows 2008 R2). Can please > anyone > have step-by-step configuration doc and share to me? > Previously I have done the same exercise, but now > that is not > working for me and I am facing lot of challenges to > make this > happen. > > Please find the steps what exactly I done so for: > > 1. Installed RHDS 8.1 and FreeIPA 1.2.1 and > configured > properly and tested its working fine > > 2. In AD side, installed Active Directory > certificate > Server as a Enterprise Root > > 3. Copy the ?cacert.p12? file and imported under > Certificates ?Service (Active Directory Domain > service) on > Local Computer using MMC. > > 4. Installed PasSync.msi file and given all > the required > information > > 5. Run the command ?certutil -d . -L -n "CA > certificate" > -a > dsca.crt? from IPA server and copied the .crt > file in to > AD server and ran this command from ?cd "C:\Program > Files\Red > Hat Directory Password Synchronization" > > 6. certutil.exe -d . -N > > 7. certutil.exe -d . -A -n "DS CA cert" -t > CT,, -a -i > \path\to\dsca.crt > > 8. certutil.exe -d . -L -n "DS CA cert" and > rebooted the > AD server. > > After this steps, when try to create sync agreement > from IPA > server I am getting this error: > > ldap_simple_bind: Can't contact LDAP server > > SSL error -8179 (Peer's Certificate issuer > is not > recognized.) > > Please share the steps to configure AD Sync with > IPA server. > > > http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Windows_Sync-Configuring_Windows_Sync.html > > But it looks as though there is a step missing. If you > use MS AD > CA to generate the AD cert, and use IPA to generate the > IPA CA and > server cert, then you have to import the MS AD CA cert > into IPA. > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From rmeggins at redhat.com Tue Aug 17 16:00:14 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 17 Aug 2010 10:00:14 -0600 Subject: [Freeipa-users] IPA+AD sync error In-Reply-To: References: <4C694DFD.5010006@redhat.com> <4C6953E6.4030500@redhat.com> <4C6AAC48.1050006@redhat.com> Message-ID: <4C6AB20E.5000305@redhat.com> Shan Kumaraswamy wrote: > Rich, > Please find the below out put of the command: > > [root at saprhds001 ~]# certutil -d /etc/dirsrv/slapd-XXXX-COM -L > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > Imported CA CT,,C > CA certificate CTu,u,Cu > Server-Cert u,u,u I'm assuming "Imported CA" is the MS AD CA. Do this: certutil -d /etc/dirsrv/slapd-XXXX-COM -L -n "Imported CA" > > > On Tue, Aug 17, 2010 at 6:35 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > After this error, I have triyed your the following steps: > /usr/lib64/mozldap/ldapsearch -h windows.test.ad > > -D > "CN=administrator,CN=users,DC=test,DC=ad" -w "xxxx" -s base -b > "" "objectclass=*" > > Then I got output like this: > > version: 1 > dn: > currentTime: 20100817220245.0Z > subschemaSubentry: > CN=Aggregate,CN=Schema,CN=Configuration,DC=test,DC=ad > dsServiceName: CN=NTDS > Settings,CN=WINDOWS,CN=Servers,CN=Default-First-Site-Na > me,CN=Sites,CN=Configuration,DC=test,DC=ad > namingContexts: DC=test,DC=ad > namingContexts: CN=Configuration,DC=test,DC=ad > namingContexts: CN=Schema,CN=Configuration,DC=test,DC=ad > namingContexts: DC=DomainDnsZones,DC=test,DC=ad > namingContexts: DC=ForestDnsZones,DC=test,DC=ad > defaultNamingContext: DC=test,DC=ad > schemaNamingContext: CN=Schema,CN=Configuration,DC=test,DC=ad > configurationNamingContext: CN=Configuration,DC=test,DC=ad > rootDomainNamingContext: DC=test,DC=ad > supportedControl: 1.2.840.113556.1.4.319 > supportedControl: 1.2.840.113556.1.4.801 > supportedControl: 1.2.840.113556.1.4.473 > supportedControl: 1.2.840.113556.1.4.528 > supportedControl: 1.2.840.113556.1.4.417 > supportedControl: 1.2.840.113556.1.4.619 > supportedControl: 1.2.840.113556.1.4.841 > supportedControl: 1.2.840.113556.1.4.529 > supportedControl: 1.2.840.113556.1.4.805 > supportedControl: 1.2.840.113556.1.4.521 > supportedControl: 1.2.840.113556.1.4.970 > supportedControl: 1.2.840.113556.1.4.1338 > supportedControl: 1.2.840.113556.1.4.474 > supportedControl: 1.2.840.113556.1.4.1339 > supportedControl: 1.2.840.113556.1.4.1340 > supportedControl: 1.2.840.113556.1.4.1413 > supportedControl: 2.16.840.1.113730.3.4.9 > supportedControl: 2.16.840.1.113730.3.4.10 > supportedControl: 1.2.840.113556.1.4.1504 > supportedControl: 1.2.840.113556.1.4.1852 > supportedControl: 1.2.840.113556.1.4.802 > supportedControl: 1.2.840.113556.1.4.1907 > supportedControl: 1.2.840.113556.1.4.1948 > supportedControl: 1.2.840.113556.1.4.1974 > supportedControl: 1.2.840.113556.1.4.1341 > supportedControl: 1.2.840.113556.1.4.2026 > supportedControl: 1.2.840.113556.1.4.2064 > supportedControl: 1.2.840.113556.1.4.2065 > supportedLDAPVersion: 3 > supportedLDAPVersion: 2 > supportedLDAPPolicies: MaxPoolThreads > supportedLDAPPolicies: MaxDatagramRecv > supportedLDAPPolicies: MaxReceiveBuffer > supportedLDAPPolicies: InitRecvTimeout > supportedLDAPPolicies: MaxConnections > supportedLDAPPolicies: MaxConnIdleTime > supportedLDAPPolicies: MaxPageSize > supportedLDAPPolicies: MaxQueryDuration > supportedLDAPPolicies: MaxTempTableSize > supportedLDAPPolicies: MaxResultSetSize > supportedLDAPPolicies: MinResultSets > supportedLDAPPolicies: MaxResultSetsPerConn > supportedLDAPPolicies: MaxNotificationPerConn > supportedLDAPPolicies: MaxValRange > highestCommittedUSN: 73772 > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: GSS-SPNEGO > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: DIGEST-MD5 > dnsHostName: Windows.test.ad > > > ldapServiceName: test.ad:windows$@TEST.AD > > > > serverName: > CN=WINDOWS,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Confi > guration,DC=test,DC=ad > supportedCapabilities: 1.2.840.113556.1.4.800 > supportedCapabilities: 1.2.840.113556.1.4.1670 > supportedCapabilities: 1.2.840.113556.1.4.1791 > supportedCapabilities: 1.2.840.113556.1.4.1935 > supportedCapabilities: 1.2.840.113556.1.4.2080 > isSynchronized: TRUE > isGlobalCatalogReady: TRUE > domainFunctionality: 4 > forestFunctionality: 4 > domainControllerFunctionality: 4 > > Then I tried next step: > /usr/lib64/mozldap/ldapsearch -ZZ -P > /etc/dirsrv/slapd-XXXX-COM/cert8.db -h windows.test.ad > > -D > "CN=administrator,CN=users,DC=test,DC=ad" -w "xxxxx" -s base > -b "" "objectclass=*" > > ldap_simple_bind: Can't contact LDAP server > TLS/SSL error -8179 (Peer's Certificate issuer is not > recognized.) > Please help me to fix this..... > > This usually means the SSL server's CA cert is not recognized. > What does this say: > certutil -d /etc/dirsrv/slapd-XXXX-COM -L > ? > > > On Tue, Aug 17, 2010 at 2:02 PM, Shan Kumaraswamy > > >> > wrote: > > Hi Rich, > After I did all the steps, I am getting this error: > INFO:root:Added CA certificate > /etc/dirsrv/slapd-XXXX-COM/adcert.cer to certificate > database for > tesipa001.test.com > > > INFO:root:Restarted directory server tesipa001.test.com > > > > INFO:root:Could not validate connection to remote server > windows.test.ad:636 > - continuing > > INFO:root:The error was: {'info': 'error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify > failed', > 'desc': "Can't contact LDAP server"} > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=bmibank,dc=com > Windows PassSync entry exists, not resetting password > INFO:root:Added new sync agreement, waiting for it to > become ready > . . . > INFO:root:Replication Update in progress: FALSE: status: 81 - > LDAP error: Can't contact LDAP server: start: 0: end: 0 > INFO:root:Agreement is ready, starting replication . . . > Starting replication, please wait until this has completed. > [saprhds001.bmibank.com > ] reports: > > Update failed! Status: [81 - LDAP error: Can't contact > LDAP server] > INFO:root:Added agreement for other host windows.test.ad > > > > > Please help me to fix this issue. > The syntex I used: ipa-replica-manage add --winsync > --binddn > CN=Administrator,CN=Users,DC=test,DC=com --bindpw "password" > --cacert /etc/dirsrv/slapd-TEST-COM/adcert.cer > windows.test.ad > -v --passsync "password" > > > On Mon, Aug 16, 2010 at 6:06 PM, Rich Megginson > > >> wrote: > > Shan Kumaraswamy wrote: > > Rich, > While installing IPA its creates its won CA cert > right? > (cacert.p12), > > Right. > > and also I done the setep of export this CA file as > dsca.crt. > > Right. You have to do that so that AD can be an SSL > client to > the IPA SSL server. > > Please let me know steps to generate the IPA CA and > server > cert? > > The other part is that you have to install the AD CA > cert in > IPA so that IPA can be the SSL client to the AD SSL server. > > > On Mon, Aug 16, 2010 at 5:41 PM, Rich Megginson > > > > >>> > > wrote: > > Shan Kumaraswamy wrote: > > > Hi, > > I have deployed FreeIPA 1.2.1 in RHEL 5.5 and I > want to sync > with Active Directory (windows 2008 R2). Can > please > anyone > have step-by-step configuration doc and > share to me? > Previously I have done the same exercise, > but now > that is not > working for me and I am facing lot of > challenges to > make this > happen. > > Please find the steps what exactly I done so > for: > > 1. Installed RHDS 8.1 and FreeIPA > 1.2.1 and > configured > properly and tested its working fine > > 2. In AD side, installed Active Directory > certificate > Server as a Enterprise Root > > 3. Copy the ?cacert.p12? file and > imported under > Certificates ?Service (Active Directory Domain > service) on > Local Computer using MMC. > > 4. Installed PasSync.msi file and > given all > the required > information > > 5. Run the command ?certutil -d . -L > -n "CA > certificate" > -a > dsca.crt? from IPA server and copied > the .crt > file in to > AD server and ran this command from ?cd > "C:\Program > Files\Red > Hat Directory Password Synchronization" > > 6. certutil.exe -d . -N > > 7. certutil.exe -d . -A -n "DS CA cert" -t > CT,, -a -i > \path\to\dsca.crt > > 8. certutil.exe -d . -L -n "DS CA > cert" and > rebooted the > AD server. > > After this steps, when try to create sync > agreement > from IPA > server I am getting this error: > > ldap_simple_bind: Can't contact > LDAP server > > SSL error -8179 (Peer's Certificate > issuer > is not > recognized.) > > Please share the steps to configure AD Sync with > IPA server. > > > http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Windows_Sync-Configuring_Windows_Sync.html > > But it looks as though there is a step missing. > If you > use MS AD > CA to generate the AD cert, and use IPA to > generate the > IPA CA and > server cert, then you have to import the MS AD > CA cert > into IPA. > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From rmeggins at redhat.com Tue Aug 17 16:07:39 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 17 Aug 2010 10:07:39 -0600 Subject: [Freeipa-users] IPA+AD sync error In-Reply-To: References: <4C694DFD.5010006@redhat.com> <4C6953E6.4030500@redhat.com> <4C6AAC48.1050006@redhat.com> <4C6AB20E.5000305@redhat.com> Message-ID: <4C6AB3CB.4030206@redhat.com> Shan Kumaraswamy wrote: > done, and it came the output also, can plz let me know the next step. Can you post the output? > > On Tue, Aug 17, 2010 at 7:00 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > Rich, > Please find the below out put of the command: > [root at saprhds001 ~]# certutil -d /etc/dirsrv/slapd-XXXX-COM -L > Certificate Nickname > Trust Attributes > > SSL,S/MIME,JAR/XPI > Imported CA CT,,C > CA certificate > CTu,u,Cu > Server-Cert u,u,u > > I'm assuming "Imported CA" is the MS AD CA. Do this: > certutil -d /etc/dirsrv/slapd-XXXX-COM -L -n "Imported CA" > > > > On Tue, Aug 17, 2010 at 6:35 PM, Rich Megginson > > >> wrote: > > Shan Kumaraswamy wrote: > > After this error, I have triyed your the following steps: > /usr/lib64/mozldap/ldapsearch -h windows.test.ad > > > > > -D > "CN=administrator,CN=users,DC=test,DC=ad" -w "xxxx" -s > base -b > "" "objectclass=*" > > Then I got output like this: > version: 1 > dn: > currentTime: 20100817220245.0Z > subschemaSubentry: > CN=Aggregate,CN=Schema,CN=Configuration,DC=test,DC=ad > dsServiceName: CN=NTDS > Settings,CN=WINDOWS,CN=Servers,CN=Default-First-Site-Na > me,CN=Sites,CN=Configuration,DC=test,DC=ad > namingContexts: DC=test,DC=ad > namingContexts: CN=Configuration,DC=test,DC=ad > namingContexts: CN=Schema,CN=Configuration,DC=test,DC=ad > namingContexts: DC=DomainDnsZones,DC=test,DC=ad > namingContexts: DC=ForestDnsZones,DC=test,DC=ad > defaultNamingContext: DC=test,DC=ad > schemaNamingContext: > CN=Schema,CN=Configuration,DC=test,DC=ad > configurationNamingContext: CN=Configuration,DC=test,DC=ad > rootDomainNamingContext: DC=test,DC=ad > supportedControl: 1.2.840.113556.1.4.319 > supportedControl: 1.2.840.113556.1.4.801 > supportedControl: 1.2.840.113556.1.4.473 > supportedControl: 1.2.840.113556.1.4.528 > supportedControl: 1.2.840.113556.1.4.417 > supportedControl: 1.2.840.113556.1.4.619 > supportedControl: 1.2.840.113556.1.4.841 > supportedControl: 1.2.840.113556.1.4.529 > supportedControl: 1.2.840.113556.1.4.805 > supportedControl: 1.2.840.113556.1.4.521 > supportedControl: 1.2.840.113556.1.4.970 > supportedControl: 1.2.840.113556.1.4.1338 > supportedControl: 1.2.840.113556.1.4.474 > supportedControl: 1.2.840.113556.1.4.1339 > supportedControl: 1.2.840.113556.1.4.1340 > supportedControl: 1.2.840.113556.1.4.1413 > supportedControl: 2.16.840.1.113730.3.4.9 > supportedControl: 2.16.840.1.113730.3.4.10 > supportedControl: 1.2.840.113556.1.4.1504 > supportedControl: 1.2.840.113556.1.4.1852 > supportedControl: 1.2.840.113556.1.4.802 > supportedControl: 1.2.840.113556.1.4.1907 > supportedControl: 1.2.840.113556.1.4.1948 > supportedControl: 1.2.840.113556.1.4.1974 > supportedControl: 1.2.840.113556.1.4.1341 > supportedControl: 1.2.840.113556.1.4.2026 > supportedControl: 1.2.840.113556.1.4.2064 > supportedControl: 1.2.840.113556.1.4.2065 > supportedLDAPVersion: 3 > supportedLDAPVersion: 2 > supportedLDAPPolicies: MaxPoolThreads > supportedLDAPPolicies: MaxDatagramRecv > supportedLDAPPolicies: MaxReceiveBuffer > supportedLDAPPolicies: InitRecvTimeout > supportedLDAPPolicies: MaxConnections > supportedLDAPPolicies: MaxConnIdleTime > supportedLDAPPolicies: MaxPageSize > supportedLDAPPolicies: MaxQueryDuration > supportedLDAPPolicies: MaxTempTableSize > supportedLDAPPolicies: MaxResultSetSize > supportedLDAPPolicies: MinResultSets > supportedLDAPPolicies: MaxResultSetsPerConn > supportedLDAPPolicies: MaxNotificationPerConn > supportedLDAPPolicies: MaxValRange > highestCommittedUSN: 73772 > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: GSS-SPNEGO > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: DIGEST-MD5 > dnsHostName: Windows.test.ad > > > > > ldapServiceName: test.ad:windows$@TEST.AD > > > > > > serverName: > > CN=WINDOWS,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Confi > guration,DC=test,DC=ad > supportedCapabilities: 1.2.840.113556.1.4.800 > supportedCapabilities: 1.2.840.113556.1.4.1670 > supportedCapabilities: 1.2.840.113556.1.4.1791 > supportedCapabilities: 1.2.840.113556.1.4.1935 > supportedCapabilities: 1.2.840.113556.1.4.2080 > isSynchronized: TRUE > isGlobalCatalogReady: TRUE > domainFunctionality: 4 > forestFunctionality: 4 > domainControllerFunctionality: 4 > > Then I tried next step: > /usr/lib64/mozldap/ldapsearch -ZZ -P > /etc/dirsrv/slapd-XXXX-COM/cert8.db -h windows.test.ad > > > > > -D > "CN=administrator,CN=users,DC=test,DC=ad" -w "xxxxx" -s > base > -b "" "objectclass=*" > > ldap_simple_bind: Can't contact LDAP server > TLS/SSL error -8179 (Peer's Certificate issuer > is not > recognized.) > Please help me to fix this..... > > This usually means the SSL server's CA cert is not recognized. > What does this say: > certutil -d /etc/dirsrv/slapd-XXXX-COM -L > ? > > > On Tue, Aug 17, 2010 at 2:02 PM, Shan Kumaraswamy > > > > >>> > > wrote: > > Hi Rich, > After I did all the steps, I am getting this error: > INFO:root:Added CA certificate > /etc/dirsrv/slapd-XXXX-COM/adcert.cer to certificate > database for > tesipa001.test.com > > > > INFO:root:Restarted directory server > tesipa001.test.com > > > > INFO:root:Could not validate connection to remote server > windows.test.ad:636 > > - continuing > > INFO:root:The error was: {'info': 'error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify > failed', > 'desc': "Can't contact LDAP server"} > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=bmibank,dc=com > Windows PassSync entry exists, not resetting password > INFO:root:Added new sync agreement, waiting for it to > become ready > . . . > INFO:root:Replication Update in progress: FALSE: > status: 81 - > LDAP error: Can't contact LDAP server: start: 0: end: 0 > INFO:root:Agreement is ready, starting replication . . . > Starting replication, please wait until this has > completed. > [saprhds001.bmibank.com > > ] reports: > > Update failed! Status: [81 - LDAP error: Can't contact > LDAP server] > INFO:root:Added agreement for other host > windows.test.ad > > > > > Please help me to fix this issue. > The syntex I used: ipa-replica-manage add --winsync > --binddn > CN=Administrator,CN=Users,DC=test,DC=com --bindpw > "password" > --cacert /etc/dirsrv/slapd-TEST-COM/adcert.cer > windows.test.ad > > -v --passsync "password" > > On Mon, Aug 16, 2010 at 6:06 PM, > Rich Megginson > > > > >>> wrote: > > Shan Kumaraswamy wrote: > > Rich, > While installing IPA its creates its won CA > cert > right? > (cacert.p12), > > Right. > > and also I done the setep of export this CA > file as > dsca.crt. > > Right. You have to do that so that AD can be an SSL > client to > the IPA SSL server. > > Please let me know steps to generate the IPA > CA and > server > cert? > > The other part is that you have to install the AD CA > cert in > IPA so that IPA can be the SSL client to the AD > SSL server. > > On Mon, Aug 16, 2010 at > 5:41 PM, Rich Megginson > > > >> > > > > >>>> > > wrote: > > Shan Kumaraswamy wrote: > > > Hi, > > I have deployed FreeIPA 1.2.1 in RHEL > 5.5 and I > want to sync > with Active Directory (windows 2008 > R2). Can > please > anyone > have step-by-step configuration doc and > share to me? > Previously I have done the same exercise, > but now > that is not > working for me and I am facing lot of > challenges to > make this > happen. > > Please find the steps what exactly I > done so > for: > > 1. Installed RHDS 8.1 and FreeIPA > 1.2.1 and > configured > properly and tested its working fine > > 2. In AD side, installed Active > Directory > certificate > Server as a Enterprise Root > > 3. Copy the ?cacert.p12? file and > imported under > Certificates ?Service (Active > Directory Domain > service) on > Local Computer using MMC. > > 4. Installed PasSync.msi file and > given all > the required > information > > 5. Run the command ?certutil -d > . -L > -n "CA > certificate" > -a > dsca.crt? from IPA server and copied > the .crt > file in to > AD server and ran this command from ?cd > "C:\Program > Files\Red > Hat Directory Password Synchronization" > > 6. certutil.exe -d . -N > > 7. certutil.exe -d . -A -n "DS > CA cert" -t > CT,, -a -i > \path\to\dsca.crt > > 8. certutil.exe -d . -L -n "DS CA > cert" and > rebooted the > AD server. > > After this steps, when try to create sync > agreement > from IPA > server I am getting this error: > > ldap_simple_bind: Can't contact > LDAP server > > SSL error -8179 (Peer's > Certificate > issuer > is not > recognized.) > > Please share the steps to configure > AD Sync with > IPA server. > > > http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Windows_Sync-Configuring_Windows_Sync.html > > But it looks as though there is a step > missing. > If you > use MS AD > CA to generate the AD cert, and use IPA to > generate the > IPA CA and > server cert, then you have to import the > MS AD > CA cert > into IPA. > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From rmeggins at redhat.com Tue Aug 17 16:26:58 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 17 Aug 2010 10:26:58 -0600 Subject: [Freeipa-users] IPA+AD sync error In-Reply-To: References: <4C694DFD.5010006@redhat.com> <4C6953E6.4030500@redhat.com> <4C6AAC48.1050006@redhat.com> <4C6AB20E.5000305@redhat.com> Message-ID: <4C6AB852.1060608@redhat.com> Shan Kumaraswamy wrote: > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > 46:90:cd:94:c6:53:d4:ae:44:a6:df:e2:6b:24:15:56 > Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption > Issuer: "CN=test-WINDOWS-CA,DC=test,DC=ad" > Validity: > Not Before: Tue Aug 17 01:39:07 2010 > Not After : Mon Aug 17 01:49:05 2015 > Subject: "CN=test-WINDOWS-CA,DC=test,DC=ad" > Subject Public Key Info: > Public Key Algorithm: PKCS #1 RSA Encryption > RSA Public Key: > Modulus: > a9:6e:1a:54:c2:70:1c:d7:dc:06:b4:d3:09:0f:8d:25: > e5:8f:9f:1f:f6:f9:ee:fb:9c:6b:9c:84:c3:01:f7:45: > f1:8e:43:d3:ed:ad:01:e6:92:6c:52:f4:d7:03:03:19: > 0a:93:84:18:42:92:2b:6b:74:3d:77:8c:31:b9:bf:75: > 84:cb:a0:8c:a5:df:c2:5a:d6:cb:a3:78:a2:1a:6d:a6: > e1:b4:81:ea:22:e7:83:bb:1f:0d:70:f8:44:29:24:96: > f3:f0:01:12:49:7a:59:b8:f7:1a:84:e4:e4:a4:0d:60: > 58:db:d9:9c:b4:51:7a:21:f2:a2:f9:ed:ee:92:6f:c0: > 00:39:dc:26:9f:c5:0b:e3:e1:72:62:5d:9f:8e:4a:79: > f3:95:56:a0:37:63:9a:d1:53:af:74:0b:c9:88:b7:43: > ff:11:cb:91:02:4a:5c:8c:35:41:cb:39:4e:fb:8c:a4: > 2d:a6:88:7b:dc:29:04:7a:f0:0a:89:25:24:76:b1:34: > 57:1e:c2:3f:48:79:21:47:f0:f1:1a:70:15:d8:b5:9b: > cb:bc:a2:3c:42:f6:da:91:a7:24:5b:fa:08:ec:41:8b: > c5:82:7c:81:76:3c:ef:84:58:93:cd:92:36:5d:96:55: > 40:72:21:5e:14:7c:fe:78:cf:35:69:97:4a:49:35:81 > Exponent: 65537 (0x10001) > Signed Extensions: > Name: Microsoft Enrollment Cert Type Extension > Data: "CA" > > Name: Certificate Key Usage > Critical: True > Usages: Digital Signature > Certificate Signing > CRL Signing > > Name: Certificate Basic Constraints > Critical: True > Data: Is a CA with no maximum path length. > > Name: Certificate Subject Key ID > Data: > a9:7a:6e:7c:dd:dd:4f:9e:75:78:86:6a:ff:f1:b4:06: > e6:fb:3a:6d > > Name: Microsoft CertServ CA version > Data: 0 (0x0) > > Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption > Signature: > 02:50:bd:c6:3a:80:85:9d:46:16:94:8c:e2:e8:2f:0d: > 35:09:d7:af:e1:ce:c0:23:94:19:ef:a7:df:de:56:17: > c8:9e:d5:a0:80:7e:31:46:1d:c0:c1:5a:e9:7d:fe:c3: > bb:08:c0:6d:35:3a:f2:43:c2:b7:2f:44:2b:89:7f:f1: > ad:e8:9e:51:fa:98:12:d9:2b:2d:08:00:80:c3:78:93: > e7:bc:ee:17:ae:a3:07:81:6b:63:ac:bf:65:d5:e9:a8: > e9:81:42:56:24:fc:2f:b8:d1:76:5b:72:c0:8f:62:66: > cc:4d:5b:84:85:fb:63:06:6c:0a:54:a0:55:08:bf:11: > 4b:30:ab:ba:49:19:39:ee:4f:57:3c:7b:0b:d3:8d:fe: > 10:d8:18:63:ee:86:e9:cb:89:1e:ea:7e:0a:68:8c:f8: > da:40:69:ca:2c:bc:5d:24:18:bc:2b:d7:ce:08:ca:d7: > e8:aa:4b:d8:cb:ee:17:f3:4f:18:29:fc:48:59:ae:98: > 18:37:f0:a7:cd:42:1f:5d:79:cd:a1:0f:30:41:7f:97: > 81:43:68:8b:74:0c:d8:21:b6:eb:76:14:bf:44:14:13: > dd:07:ee:ce:68:95:29:b1:14:f6:93:81:90:b5:e6:6a: > 2b:38:6a:f0:4c:20:3f:fc:88:84:3f:43:5e:5f:6e:ed > Fingerprint (MD5): > 4B:AE:EB:7D:D0:B6:C8:D3:15:1B:08:ED:39:A0:68:6C > Fingerprint (SHA1): > 84:17:7E:EE:93:B2:A3:4F:D9:7B:72:C6:ED:D6:61:9E:0E:82:51:BC > > Certificate Trust Flags: > SSL Flags: > Valid CA > Trusted CA > Trusted Client CA > Email Flags: > Object Signing Flags: > Valid CA > Trusted CA > This looks ok. So is it possible the AD server cert was not issued by this CA? I suppose you could use an SSL test program like /usr/bin/ssltap or openssl s_client like this: openssl s_client -connect windows.test.ad:636 -CAfile /path/to/msadcacert.asc You can also add -verify 3 and -showcerts and -debug see "man s_client" for more information > > > > On Tue, Aug 17, 2010 at 7:04 PM, Shan Kumaraswamy > > wrote: > > done, and it came the output also, can plz let me know the next step. > > > On Tue, Aug 17, 2010 at 7:00 PM, Rich Megginson > > wrote: > > Shan Kumaraswamy wrote: > > Rich, > Please find the below out put of the command: > [root at saprhds001 ~]# certutil -d > /etc/dirsrv/slapd-XXXX-COM -L > Certificate Nickname > Trust Attributes > > SSL,S/MIME,JAR/XPI > Imported CA > CT,,C > CA certificate > CTu,u,Cu > Server-Cert > u,u,u > > I'm assuming "Imported CA" is the MS AD CA. Do this: > certutil -d /etc/dirsrv/slapd-XXXX-COM -L -n "Imported CA" > > > > On Tue, Aug 17, 2010 at 6:35 PM, Rich Megginson > > >> > wrote: > > Shan Kumaraswamy wrote: > > After this error, I have triyed your the following > steps: > /usr/lib64/mozldap/ldapsearch -h windows.test.ad > > > > > -D > "CN=administrator,CN=users,DC=test,DC=ad" -w "xxxx" > -s base -b > "" "objectclass=*" > > Then I got output like this: > version: 1 > dn: > currentTime: 20100817220245.0Z > subschemaSubentry: > CN=Aggregate,CN=Schema,CN=Configuration,DC=test,DC=ad > dsServiceName: CN=NTDS > Settings,CN=WINDOWS,CN=Servers,CN=Default-First-Site-Na > me,CN=Sites,CN=Configuration,DC=test,DC=ad > namingContexts: DC=test,DC=ad > namingContexts: CN=Configuration,DC=test,DC=ad > namingContexts: > CN=Schema,CN=Configuration,DC=test,DC=ad > namingContexts: DC=DomainDnsZones,DC=test,DC=ad > namingContexts: DC=ForestDnsZones,DC=test,DC=ad > defaultNamingContext: DC=test,DC=ad > schemaNamingContext: > CN=Schema,CN=Configuration,DC=test,DC=ad > configurationNamingContext: > CN=Configuration,DC=test,DC=ad > rootDomainNamingContext: DC=test,DC=ad > supportedControl: 1.2.840.113556.1.4.319 > supportedControl: 1.2.840.113556.1.4.801 > supportedControl: 1.2.840.113556.1.4.473 > supportedControl: 1.2.840.113556.1.4.528 > supportedControl: 1.2.840.113556.1.4.417 > supportedControl: 1.2.840.113556.1.4.619 > supportedControl: 1.2.840.113556.1.4.841 > supportedControl: 1.2.840.113556.1.4.529 > supportedControl: 1.2.840.113556.1.4.805 > supportedControl: 1.2.840.113556.1.4.521 > supportedControl: 1.2.840.113556.1.4.970 > supportedControl: 1.2.840.113556.1.4.1338 > supportedControl: 1.2.840.113556.1.4.474 > supportedControl: 1.2.840.113556.1.4.1339 > supportedControl: 1.2.840.113556.1.4.1340 > supportedControl: 1.2.840.113556.1.4.1413 > supportedControl: 2.16.840.1.113730.3.4.9 > supportedControl: 2.16.840.1.113730.3.4.10 > supportedControl: 1.2.840.113556.1.4.1504 > supportedControl: 1.2.840.113556.1.4.1852 > supportedControl: 1.2.840.113556.1.4.802 > supportedControl: 1.2.840.113556.1.4.1907 > supportedControl: 1.2.840.113556.1.4.1948 > supportedControl: 1.2.840.113556.1.4.1974 > supportedControl: 1.2.840.113556.1.4.1341 > supportedControl: 1.2.840.113556.1.4.2026 > supportedControl: 1.2.840.113556.1.4.2064 > supportedControl: 1.2.840.113556.1.4.2065 > supportedLDAPVersion: 3 > supportedLDAPVersion: 2 > supportedLDAPPolicies: MaxPoolThreads > supportedLDAPPolicies: MaxDatagramRecv > supportedLDAPPolicies: MaxReceiveBuffer > supportedLDAPPolicies: InitRecvTimeout > supportedLDAPPolicies: MaxConnections > supportedLDAPPolicies: MaxConnIdleTime > supportedLDAPPolicies: MaxPageSize > supportedLDAPPolicies: MaxQueryDuration > supportedLDAPPolicies: MaxTempTableSize > supportedLDAPPolicies: MaxResultSetSize > supportedLDAPPolicies: MinResultSets > supportedLDAPPolicies: MaxResultSetsPerConn > supportedLDAPPolicies: MaxNotificationPerConn > supportedLDAPPolicies: MaxValRange > highestCommittedUSN: 73772 > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: GSS-SPNEGO > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: DIGEST-MD5 > dnsHostName: Windows.test.ad > > > > > ldapServiceName: test.ad:windows$@TEST.AD > > > > > > serverName: > > CN=WINDOWS,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Confi > guration,DC=test,DC=ad > supportedCapabilities: 1.2.840.113556.1.4.800 > supportedCapabilities: 1.2.840.113556.1.4.1670 > supportedCapabilities: 1.2.840.113556.1.4.1791 > supportedCapabilities: 1.2.840.113556.1.4.1935 > supportedCapabilities: 1.2.840.113556.1.4.2080 > isSynchronized: TRUE > isGlobalCatalogReady: TRUE > domainFunctionality: 4 > forestFunctionality: 4 > domainControllerFunctionality: 4 > > Then I tried next step: > /usr/lib64/mozldap/ldapsearch -ZZ -P > /etc/dirsrv/slapd-XXXX-COM/cert8.db -h > windows.test.ad > > > > -D > "CN=administrator,CN=users,DC=test,DC=ad" -w > "xxxxx" -s base > -b "" "objectclass=*" > > ldap_simple_bind: Can't contact LDAP server > TLS/SSL error -8179 (Peer's Certificate > issuer is not > recognized.) > Please help me to fix this..... > > This usually means the SSL server's CA cert is not > recognized. > What does this say: > certutil -d /etc/dirsrv/slapd-XXXX-COM -L > ? > > > On Tue, Aug 17, 2010 at 2:02 PM, Shan Kumaraswamy > > > > > >>> > > wrote: > > Hi Rich, > After I did all the steps, I am getting this error: > INFO:root:Added CA certificate > /etc/dirsrv/slapd-XXXX-COM/adcert.cer to certificate > database for > tesipa001.test.com > > > > INFO:root:Restarted directory server > tesipa001.test.com > > > > INFO:root:Could not validate connection to > remote server > windows.test.ad:636 > > - continuing > > INFO:root:The error was: {'info': > 'error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify > failed', > 'desc': "Can't contact LDAP server"} > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=bmibank,dc=com > Windows PassSync entry exists, not resetting > password > INFO:root:Added new sync agreement, waiting for > it to > become ready > . . . > INFO:root:Replication Update in progress: FALSE: > status: 81 - > LDAP error: Can't contact LDAP server: start: 0: > end: 0 > INFO:root:Agreement is ready, starting > replication . . . > Starting replication, please wait until this has > completed. > [saprhds001.bmibank.com > > > ] reports: > > Update failed! Status: [81 - LDAP error: Can't > contact > LDAP server] > INFO:root:Added agreement for other host > windows.test.ad > > > > > Please help me to fix this issue. > The syntex I used: ipa-replica-manage add > --winsync > --binddn > CN=Administrator,CN=Users,DC=test,DC=com > --bindpw "password" > --cacert /etc/dirsrv/slapd-TEST-COM/adcert.cer > windows.test.ad > > -v --passsync "password" > > On Mon, Aug 16, 2010 at 6:06 PM, > Rich Megginson > > > >>> wrote: > > Shan Kumaraswamy wrote: > > Rich, > While installing IPA its creates its > won CA cert > right? > (cacert.p12), > > Right. > > and also I done the setep of export this > CA file as > dsca.crt. > > Right. You have to do that so that AD can > be an SSL > client to > the IPA SSL server. > > Please let me know steps to generate the > IPA CA and > server > cert? > > The other part is that you have to install > the AD CA > cert in > IPA so that IPA can be the SSL client to the > AD SSL server. > > On Mon, Aug 16, 2010 > at 5:41 PM, Rich Megginson > > > >> > > > > >>>> > > wrote: > > Shan Kumaraswamy wrote: > > > Hi, > > I have deployed FreeIPA 1.2.1 in > RHEL 5.5 and I > want to sync > with Active Directory (windows > 2008 R2). Can > please > anyone > have step-by-step configuration > doc and > share to me? > Previously I have done the same > exercise, > but now > that is not > working for me and I am facing lot of > challenges to > make this > happen. > > Please find the steps what > exactly I done so > for: > > 1. Installed RHDS 8.1 and > FreeIPA > 1.2.1 and > configured > properly and tested its working fine > > 2. In AD side, installed > Active Directory > certificate > Server as a Enterprise Root > > 3. Copy the ?cacert.p12? > file and > imported under > Certificates ?Service (Active > Directory Domain > service) on > Local Computer using MMC. > > 4. Installed PasSync.msi > file and > given all > the required > information > > 5. Run the command > ?certutil -d . -L > -n "CA > certificate" > -a > dsca.crt? from IPA server > and copied > the .crt > file in to > AD server and ran this command > from ?cd > "C:\Program > Files\Red > Hat Directory Password > Synchronization" > > 6. certutil.exe -d . -N > > 7. certutil.exe -d . -A -n > "DS CA cert" -t > CT,, -a -i > \path\to\dsca.crt > > 8. certutil.exe -d . -L -n > "DS CA > cert" and > rebooted the > AD server. > > After this steps, when try to > create sync > agreement > from IPA > server I am getting this error: > > ldap_simple_bind: Can't > contact > LDAP server > > SSL error -8179 (Peer's > Certificate > issuer > is not > recognized.) > > Please share the steps to > configure AD Sync with > IPA server. > > > http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Windows_Sync-Configuring_Windows_Sync.html > > But it looks as though there is a > step missing. > If you > use MS AD > CA to generate the AD cert, and use > IPA to > generate the > IPA CA and > server cert, then you have to import > the MS AD > CA cert > into IPA. > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From rcritten at redhat.com Tue Aug 17 20:06:02 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Aug 2010 16:06:02 -0400 Subject: [Freeipa-users] FreeIPA v2.0 alpha4 replica installation problems In-Reply-To: <28D2327D43A0C84D89CF661F17B0D3A016660CC1AB@SCSU81.campus.stcloudstate.edu> References: <28D2327D43A0C84D89CF661F17B0D3A016660CC1A9@SCSU81.campus.stcloudstate.edu>, <4C6976E5.2030709@redhat.com> <28D2327D43A0C84D89CF661F17B0D3A016660CC1AA@SCSU81.campus.stcloudstate.edu>, <4C69965F.7070301@redhat.com> <28D2327D43A0C84D89CF661F17B0D3A016660CC1AB@SCSU81.campus.stcloudstate.edu> Message-ID: <4C6AEBAA.1010209@redhat.com> Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: > ok I did the updates, and edited the python files. Now when I try to run the replica install I get: > > [root at earth bcrl]# ipa-replica-install /var/lib/ipa/replica-info-earth.bcrl.stcloudstate.edu.gpg -N --setup-dns --no-forwarder > Directory Manager (existing master) password: > > root : ERROR Cannot find Reverse Address for earth.bcrl.stcloudstate.edu (3.2.0.10.in-addr.arpa.) > > I had this when installing the ipa-server and there was a --no-dns-lookup option but not with the replica. Before the testing updates, i did get a warning about the server not working for DNS lookup but still went ahead with install. I'm looking to set these two up and make them the DNS servers and currently have a simple dns setup that will get replaced by this setup. How do I get around the reverse address lookup on the replica install side. Thanks again for all the help. You'll need to modify /usr/sbin/ipa-replica-install. Look for the function get_host_name(). You'll want to comment out the 5 lines starting with try:. The comment character in python is the hash #. This will cause it to skip the call to verify_fqdn() and your install should proceed. I've opened a ticket to add this functionality to ipa-replica-install: https://fedorahosted.org/freeipa/ticket/146 rob > > Corey- > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Monday, August 16, 2010 2:49 PM > To: Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FreeIPA v2.0 alpha4 replica installation problems > > Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: >> I'm using fedora 13 amd-64 version. I added the developers repo from freeIPA.com for V2.0 and then did a yum install ipa-server so which ever version it installed. I'm looking at dogtag and one of the packages says 1.3.1-2.fc13 and the other 2 packages for dogtag say 1.3.2-2.fc13 for the pki dogtag package it says 1.3.7-1.fc13 all the packages read 1.3.something the pki-silent-1.3.3-1.fc13 package if that helps. I also attached the two files you asked to check. I attached the ipa-serv_deplist that i created from running "yum deplist ipa-server" and it has all the packages and version numbers. Sorry for the choppy e-mail I'm writing and looking up the stuff in pieces. > > Can you update the pki-* and dogtag-* packages from the updates-testing > repo? There are a number of important fixes there. > > It is also going to break your replica install because a new required > option has been added to pkisilent. You'll need to modify > /usr/lib/python*/site-packages/ipaserver/install/cainstance.py > > Search for pkisilent. We create a python list of the command to execute. > You want to patch it like this (the numbers might not exactly line up): > > @@ -535,6 +524,7 @@ class CAInstance(service.Service): > "-db_name", "ipaca", > "-key_size", "2048", > "-key_type", "rsa", > + "-key_algorithm", "SHA256withRSA", > "-save_p12", "true", > "-backup_pwd", self.admin_password, > "-subsystem_name", self.service_name, > > You *might* be able to get away with just updating dogtag on the > replica, I'm not sure. > > rob > >> ________________________________________ >> From: Rob Crittenden [rcritten at redhat.com] >> Sent: Monday, August 16, 2010 12:35 PM >> To: Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] FreeIPA v2.0 alpha4 replica installation problems >> >> Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: >>> Hi, >>> I'm a student admin for St. Cloud State University's Business Computing Research Lab, and we run our own seperate network inside the campus network with dedicated internet feeds and hardware for professors research as well as masters and bachelors student research and labs. We have many computers setup for workstations, clusters, clouds, etc... and I'm trying to set up a redundant FreeIPA v2.0 in virtual box to help manage the systems and control access to machines. I have setup the master with no problems, but when creating the replica I run the command "ipa-replica-install -N --setup-dns /var/lib/ipa/replica-file-from-master" and I get this error output. It created the directory fine but is having trouble with the certs. I have disabled the firewalls on both and selinux hoping they would help but still same problem. >>> >>> [root at earth bcrl]# ipa-replica-install /var/lib/ipa/replica-info-earth.bcrl.stcloudstate.edu.gpg -N --setup-dns --no-forwarders >>> >>> An existing Directory Server has been detected. >>> Do you wish to remove it and create a new one? [no]: yes >>> Directory Manager (existing master) password: >>> >>> Warning: Hostname (earth.bcrl.stcloudstate.edu) not found in DNS >>> Configuring directory server for the CA: >>> [1/4]: creating directory server user >>> [2/4]: creating directory server instance >>> [3/4]: configuring directory to start on boot >>> [4/4]: restarting directory server >>> done configuring pkids. >>> Configuring certificate server: >>> [1/9]: creating certificate server user >>> [2/9]: configuring certificate server instance >>> root : CRITICAL failed to restart ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname earth.bcrl.stcloudstate.edu -cs_port 9445 -client_certdb_dir /tmp/tmp-vemQSV -client_certdb_pwd XXXXXXXX -preop_pin yhiJojW06gxaPrkvOJOK -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject "CN=ipa-ca-agent,O=IPA" -ldap_host earth.bcrl.stcloudstate.edu -ldap_port 7389 -bind_dn "cn=Directory Manager" -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name "CN=CA Subsystem,O=IPA" -ca_ocsp_cert_subject_name "CN=OCSP Subsystem,O=IPA" -ca_server_cert_subject_name "CN=earth.bcrl.stcloudstate.edu,O=IPA" -ca_audit_signing_cert_subject_name "CN=CA Audit,O=IPA" -ca_sign_cert_subject_name "CN=Certificate Au t > h >> o! >>> rity,O=IPA" -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname zeus.bcrl.stcloudstate.edu -sd_admin_port 9445 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_uri https://zeus.bcrl.stcloudstate.edu:9444' returned non-zero exit status 255 >>> [3/9]: creating RA agent certificate database >>> [4/9]: importing CA chain to RA certificate database >>> creation of replica failed: Unable to retrieve CA chain: Retrieving CA cert chain failed: Error: Failed to get certificate chain. >>> >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> Thanks for any help, >>> Corey >> >> Heh, I guess I didn't fat-finger this after all... >> >> What distro is this? >> >> What version of pki-* and dogtag-* do you have installed? Can you look >> at /var/log/ipareplica-install.log to see if there are any more details >> on the failure? /var/log/pki-ca/debug would also be a place to look >> though be forewarned, it is quite verbose and daunting (and has a number >> of red herrings, particularly warnings about cipher failures). >> >> We had some problems creating dogtag clones while creating IPA replicas >> in the recent pas and it would fail in the pkisilent step. This may be >> another case of that or it may be that our current requires don't pull >> in the right set of of dogtag packages. >> >> rob > From heco0701 at stcloudstate.edu Wed Aug 18 03:00:17 2010 From: heco0701 at stcloudstate.edu (Corey Hemminger) Date: Tue, 17 Aug 2010 22:00:17 -0500 Subject: [Freeipa-users] FreeIPA v2.0 alpha4 replica installation problems In-Reply-To: <4C6AEBAA.1010209@redhat.com> References: <28D2327D43A0C84D89CF661F17B0D3A016660CC1A9@SCSU81.campus.stcloudstate.edu> <4C6976E5.2030709@redhat.com> <28D2327D43A0C84D89CF661F17B0D3A016660CC1AA@SCSU81.campus.stcloudstate.edu> <4C69965F.7070301@redhat.com> <28D2327D43A0C84D89CF661F17B0D3A016660CC1AB@SCSU81.campus.stcloudstate.edu> <4C6AEBAA.1010209@redhat.com> Message-ID: <0867A90A-9C49-4349-BF9F-AF42AC964E45@stcloudstate.edu> Thanks so much you've been a big help. I'll give it a whack tomorrow morning. Thanks again. Corey On Aug 17, 2010, at 3:06 PM, Rob Crittenden wrote: > Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: >> ok I did the updates, and edited the python files. Now when I try to run the replica install I get: >> >> [root at earth bcrl]# ipa-replica-install /var/lib/ipa/replica-info-earth.bcrl.stcloudstate.edu.gpg -N --setup-dns --no-forwarder >> Directory Manager (existing master) password: >> >> root : ERROR Cannot find Reverse Address for earth.bcrl.stcloudstate.edu (3.2.0.10.in-addr.arpa.) >> >> I had this when installing the ipa-server and there was a --no-dns-lookup option but not with the replica. Before the testing updates, i did get a warning about the server not working for DNS lookup but still went ahead with install. I'm looking to set these two up and make them the DNS servers and currently have a simple dns setup that will get replaced by this setup. How do I get around the reverse address lookup on the replica install side. Thanks again for all the help. > > You'll need to modify /usr/sbin/ipa-replica-install. Look for the > function get_host_name(). You'll want to comment out the 5 lines > starting with try:. The comment character in python is the hash #. This > will cause it to skip the call to verify_fqdn() and your install should > proceed. > > I've opened a ticket to add this functionality to ipa-replica-install: > https://fedorahosted.org/freeipa/ticket/146 > > rob > >> >> Corey- >> ________________________________________ >> From: Rob Crittenden [rcritten at redhat.com] >> Sent: Monday, August 16, 2010 2:49 PM >> To: Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] FreeIPA v2.0 alpha4 replica installation problems >> >> Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: >>> I'm using fedora 13 amd-64 version. I added the developers repo from freeIPA.com for V2.0 and then did a yum install ipa-server so which ever version it installed. I'm looking at dogtag and one of the packages says 1.3.1-2.fc13 and the other 2 packages for dogtag say 1.3.2-2.fc13 for the pki dogtag package it says 1.3.7-1.fc13 all the packages read 1.3.something the pki-silent-1.3.3-1.fc13 package if that helps. I also attached the two files you asked to check. I attached the ipa-serv_deplist that i created from running "yum deplist ipa-server" and it has all the packages and version numbers. Sorry for the choppy e-mail I'm writing and looking up the stuff in pieces. >> >> Can you update the pki-* and dogtag-* packages from the updates-testing >> repo? There are a number of important fixes there. >> >> It is also going to break your replica install because a new required >> option has been added to pkisilent. You'll need to modify >> /usr/lib/python*/site-packages/ipaserver/install/cainstance.py >> >> Search for pkisilent. We create a python list of the command to execute. >> You want to patch it like this (the numbers might not exactly line up): >> >> @@ -535,6 +524,7 @@ class CAInstance(service.Service): >> "-db_name", "ipaca", >> "-key_size", "2048", >> "-key_type", "rsa", >> + "-key_algorithm", "SHA256withRSA", >> "-save_p12", "true", >> "-backup_pwd", self.admin_password, >> "-subsystem_name", self.service_name, >> >> You *might* be able to get away with just updating dogtag on the >> replica, I'm not sure. >> >> rob >> >>> ________________________________________ >>> From: Rob Crittenden [rcritten at redhat.com] >>> Sent: Monday, August 16, 2010 12:35 PM >>> To: Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] FreeIPA v2.0 alpha4 replica installation problems >>> >>> Hemminger, Corey Lee. [heco0701 at stcloudstate.edu] wrote: >>>> Hi, >>>> I'm a student admin for St. Cloud State University's Business Computing Research Lab, and we run our own seperate network inside the campus network with dedicated internet feeds and hardware for professors research as well as masters and bachelors student research and labs. We have many computers setup for workstations, clusters, clouds, etc... and I'm trying to set up a redundant FreeIPA v2.0 in virtual box to help manage the systems and control access to machines. I have setup the master with no problems, but when creating the replica I run the command "ipa-replica-install -N --setup-dns /var/lib/ipa/replica-file-from-master" and I get this error output. It created the directory fine but is having trouble with the certs. I have disabled the firewalls on both and selinux hoping they would help but still same problem. >>>> >>>> [root at earth bcrl]# ipa-replica-install /var/lib/ipa/replica-info-earth.bcrl.stcloudstate.edu.gpg -N --setup-dns --no-forwarders >>>> >>>> An existing Directory Server has been detected. >>>> Do you wish to remove it and create a new one? [no]: yes >>>> Directory Manager (existing master) password: >>>> >>>> Warning: Hostname (earth.bcrl.stcloudstate.edu) not found in DNS >>>> Configuring directory server for the CA: >>>> [1/4]: creating directory server user >>>> [2/4]: creating directory server instance >>>> [3/4]: configuring directory to start on boot >>>> [4/4]: restarting directory server >>>> done configuring pkids. >>>> Configuring certificate server: >>>> [1/9]: creating certificate server user >>>> [2/9]: configuring certificate server instance >>>> root : CRITICAL failed to restart ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname earth.bcrl.stcloudstate.edu -cs_port 9445 -client_certdb_dir /tmp/tmp-vemQSV -client_certdb_pwd XXXXXXXX -preop_pin yhiJojW06gxaPrkvOJOK -domain_name IPA -admin_user admin -admin_email root at localhost -admin_password XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject "CN=ipa-ca-agent,O=IPA" -ldap_host earth.bcrl.stcloudstate.edu -ldap_port 7389 -bind_dn "cn=Directory Manager" -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name "CN=CA Subsystem,O=IPA" -ca_ocsp_cert_subject_name "CN=OCSP Subsystem,O=IPA" -ca_server_cert_subject_name "CN=earth.bcrl.stcloudstate.edu,O=IPA" -ca_audit_signing_cert_subject_name "CN=CA Audit,O=IPA" -ca_sign_cert_subject_name "CN=Certificate Au > t >> h >>> o! >>>> rity,O=IPA" -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname zeus.bcrl.stcloudstate.edu -sd_admin_port 9445 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_uri https://zeus.bcrl.stcloudstate.edu:9444' returned non-zero exit status 255 >>>> [3/9]: creating RA agent certificate database >>>> [4/9]: importing CA chain to RA certificate database >>>> creation of replica failed: Unable to retrieve CA chain: Retrieving CA cert chain failed: Error: Failed to get certificate chain. >>>> >>>> Your system may be partly configured. >>>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>>> >>>> Thanks for any help, >>>> Corey >>> >>> Heh, I guess I didn't fat-finger this after all... >>> >>> What distro is this? >>> >>> What version of pki-* and dogtag-* do you have installed? Can you look >>> at /var/log/ipareplica-install.log to see if there are any more details >>> on the failure? /var/log/pki-ca/debug would also be a place to look >>> though be forewarned, it is quite verbose and daunting (and has a number >>> of red herrings, particularly warnings about cipher failures). >>> >>> We had some problems creating dogtag clones while creating IPA replicas >>> in the recent pas and it would fail in the pkisilent step. This may be >>> another case of that or it may be that our current requires don't pull >>> in the right set of of dogtag packages. >>> >>> rob >> > From rmeggins at redhat.com Wed Aug 18 13:44:15 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 18 Aug 2010 07:44:15 -0600 Subject: [Freeipa-users] IPA+AD sync error In-Reply-To: References: <4C694DFD.5010006@redhat.com> <4C6953E6.4030500@redhat.com> <4C6AAC48.1050006@redhat.com> <4C6AB20E.5000305@redhat.com> <4C6AB852.1060608@redhat.com> Message-ID: <4C6BE3AF.4010205@redhat.com> Shan Kumaraswamy wrote: > Rich, > Can I know command to trust IPA genearated CA cert file? See below So I don't think that is the problem here. If that were the problem, I would expect a different error message. I think you're just going to have to use something like openssl s_client to examine the server cert used by AD. > > > > > On Tue, Aug 17, 2010 at 7:26 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > 46:90:cd:94:c6:53:d4:ae:44:a6:df:e2:6b:24:15:56 > Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption > Issuer: "CN=test-WINDOWS-CA,DC=test,DC=ad" > Validity: > Not Before: Tue Aug 17 01:39:07 2010 > Not After : Mon Aug 17 01:49:05 2015 > Subject: "CN=test-WINDOWS-CA,DC=test,DC=ad" > Subject Public Key Info: > Public Key Algorithm: PKCS #1 RSA Encryption > RSA Public Key: > Modulus: > > a9:6e:1a:54:c2:70:1c:d7:dc:06:b4:d3:09:0f:8d:25: > > e5:8f:9f:1f:f6:f9:ee:fb:9c:6b:9c:84:c3:01:f7:45: > > f1:8e:43:d3:ed:ad:01:e6:92:6c:52:f4:d7:03:03:19: > > 0a:93:84:18:42:92:2b:6b:74:3d:77:8c:31:b9:bf:75: > > 84:cb:a0:8c:a5:df:c2:5a:d6:cb:a3:78:a2:1a:6d:a6: > > e1:b4:81:ea:22:e7:83:bb:1f:0d:70:f8:44:29:24:96: > > f3:f0:01:12:49:7a:59:b8:f7:1a:84:e4:e4:a4:0d:60: > > 58:db:d9:9c:b4:51:7a:21:f2:a2:f9:ed:ee:92:6f:c0: > > 00:39:dc:26:9f:c5:0b:e3:e1:72:62:5d:9f:8e:4a:79: > > f3:95:56:a0:37:63:9a:d1:53:af:74:0b:c9:88:b7:43: > > ff:11:cb:91:02:4a:5c:8c:35:41:cb:39:4e:fb:8c:a4: > > 2d:a6:88:7b:dc:29:04:7a:f0:0a:89:25:24:76:b1:34: > > 57:1e:c2:3f:48:79:21:47:f0:f1:1a:70:15:d8:b5:9b: > > cb:bc:a2:3c:42:f6:da:91:a7:24:5b:fa:08:ec:41:8b: > > c5:82:7c:81:76:3c:ef:84:58:93:cd:92:36:5d:96:55: > 40:72:21:5e:14:7c:fe:78:cf:35:69:97:4a:49:35:81 > Exponent: 65537 (0x10001) > Signed Extensions: > Name: Microsoft Enrollment Cert Type Extension > Data: "CA" > > Name: Certificate Key Usage > Critical: True > Usages: Digital Signature > Certificate Signing > CRL Signing > > Name: Certificate Basic Constraints > Critical: True > Data: Is a CA with no maximum path length. > > Name: Certificate Subject Key ID > Data: > a9:7a:6e:7c:dd:dd:4f:9e:75:78:86:6a:ff:f1:b4:06: > e6:fb:3a:6d > > Name: Microsoft CertServ CA version > Data: 0 (0x0) > > Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption > Signature: > 02:50:bd:c6:3a:80:85:9d:46:16:94:8c:e2:e8:2f:0d: > 35:09:d7:af:e1:ce:c0:23:94:19:ef:a7:df:de:56:17: > c8:9e:d5:a0:80:7e:31:46:1d:c0:c1:5a:e9:7d:fe:c3: > bb:08:c0:6d:35:3a:f2:43:c2:b7:2f:44:2b:89:7f:f1: > ad:e8:9e:51:fa:98:12:d9:2b:2d:08:00:80:c3:78:93: > e7:bc:ee:17:ae:a3:07:81:6b:63:ac:bf:65:d5:e9:a8: > e9:81:42:56:24:fc:2f:b8:d1:76:5b:72:c0:8f:62:66: > cc:4d:5b:84:85:fb:63:06:6c:0a:54:a0:55:08:bf:11: > 4b:30:ab:ba:49:19:39:ee:4f:57:3c:7b:0b:d3:8d:fe: > 10:d8:18:63:ee:86:e9:cb:89:1e:ea:7e:0a:68:8c:f8: > da:40:69:ca:2c:bc:5d:24:18:bc:2b:d7:ce:08:ca:d7: > e8:aa:4b:d8:cb:ee:17:f3:4f:18:29:fc:48:59:ae:98: > 18:37:f0:a7:cd:42:1f:5d:79:cd:a1:0f:30:41:7f:97: > 81:43:68:8b:74:0c:d8:21:b6:eb:76:14:bf:44:14:13: > dd:07:ee:ce:68:95:29:b1:14:f6:93:81:90:b5:e6:6a: > 2b:38:6a:f0:4c:20:3f:fc:88:84:3f:43:5e:5f:6e:ed > Fingerprint (MD5): > 4B:AE:EB:7D:D0:B6:C8:D3:15:1B:08:ED:39:A0:68:6C > Fingerprint (SHA1): > 84:17:7E:EE:93:B2:A3:4F:D9:7B:72:C6:ED:D6:61:9E:0E:82:51:BC > > Certificate Trust Flags: > SSL Flags: > Valid CA > Trusted CA > Trusted Client CA > Email Flags: > Object Signing Flags: > Valid CA > Trusted CA > > This looks ok. So is it possible the AD server cert was not > issued by this CA? I suppose you could use an SSL test program > like /usr/bin/ssltap > or openssl s_client like this: > openssl s_client -connect windows.test.ad:636 > -CAfile /path/to/msadcacert.asc > You can also add -verify 3 and -showcerts and -debug > see "man s_client" for more information > > > > > On Tue, Aug 17, 2010 at 7:04 PM, Shan Kumaraswamy > > >> > wrote: > > done, and it came the output also, can plz let me know the > next step. > > > On Tue, Aug 17, 2010 at 7:00 PM, Rich Megginson > > >> wrote: > > Shan Kumaraswamy wrote: > > Rich, > Please find the below out put of the command: > [root at saprhds001 ~]# certutil -d > /etc/dirsrv/slapd-XXXX-COM -L > Certificate Nickname > Trust Attributes > > SSL,S/MIME,JAR/XPI > Imported CA > CT,,C > CA certificate > CTu,u,Cu > The CT means the CA is trusted for SSL client and server certs. certutil -H ... trustargs is of the form x,y,z where x is for SSL, y is for S/MIME, ... c valid CA T trusted CA to issue client certs (implies c) C trusted CA to issue server certs (implies c) > Server-Cert > u,u,u > > I'm assuming "Imported CA" is the MS AD CA. Do this: > certutil -d /etc/dirsrv/slapd-XXXX-COM -L -n "Imported CA" > > > > On Tue, Aug 17, 2010 at 6:35 PM, Rich Megginson > > > > >>> > wrote: > > Shan Kumaraswamy wrote: > > After this error, I have triyed your the > following > steps: > /usr/lib64/mozldap/ldapsearch -h > windows.test.ad > > > > > > > -D > "CN=administrator,CN=users,DC=test,DC=ad" -w > "xxxx" > -s base -b > "" "objectclass=*" > > Then I got output like this: > version: 1 > dn: > currentTime: 20100817220245.0Z > subschemaSubentry: > > CN=Aggregate,CN=Schema,CN=Configuration,DC=test,DC=ad > dsServiceName: CN=NTDS > > Settings,CN=WINDOWS,CN=Servers,CN=Default-First-Site-Na > me,CN=Sites,CN=Configuration,DC=test,DC=ad > namingContexts: DC=test,DC=ad > namingContexts: CN=Configuration,DC=test,DC=ad > namingContexts: > CN=Schema,CN=Configuration,DC=test,DC=ad > namingContexts: DC=DomainDnsZones,DC=test,DC=ad > namingContexts: DC=ForestDnsZones,DC=test,DC=ad > defaultNamingContext: DC=test,DC=ad > schemaNamingContext: > CN=Schema,CN=Configuration,DC=test,DC=ad > configurationNamingContext: > CN=Configuration,DC=test,DC=ad > rootDomainNamingContext: DC=test,DC=ad > supportedControl: 1.2.840.113556.1.4.319 > supportedControl: 1.2.840.113556.1.4.801 > supportedControl: 1.2.840.113556.1.4.473 > supportedControl: 1.2.840.113556.1.4.528 > supportedControl: 1.2.840.113556.1.4.417 > supportedControl: 1.2.840.113556.1.4.619 > supportedControl: 1.2.840.113556.1.4.841 > supportedControl: 1.2.840.113556.1.4.529 > supportedControl: 1.2.840.113556.1.4.805 > supportedControl: 1.2.840.113556.1.4.521 > supportedControl: 1.2.840.113556.1.4.970 > supportedControl: 1.2.840.113556.1.4.1338 > supportedControl: 1.2.840.113556.1.4.474 > supportedControl: 1.2.840.113556.1.4.1339 > supportedControl: 1.2.840.113556.1.4.1340 > supportedControl: 1.2.840.113556.1.4.1413 > supportedControl: 2.16.840.1.113730.3.4.9 > supportedControl: 2.16.840.1.113730.3.4.10 > supportedControl: 1.2.840.113556.1.4.1504 > supportedControl: 1.2.840.113556.1.4.1852 > supportedControl: 1.2.840.113556.1.4.802 > supportedControl: 1.2.840.113556.1.4.1907 > supportedControl: 1.2.840.113556.1.4.1948 > supportedControl: 1.2.840.113556.1.4.1974 > supportedControl: 1.2.840.113556.1.4.1341 > supportedControl: 1.2.840.113556.1.4.2026 > supportedControl: 1.2.840.113556.1.4.2064 > supportedControl: 1.2.840.113556.1.4.2065 > supportedLDAPVersion: 3 > supportedLDAPVersion: 2 > supportedLDAPPolicies: MaxPoolThreads > supportedLDAPPolicies: MaxDatagramRecv > supportedLDAPPolicies: MaxReceiveBuffer > supportedLDAPPolicies: InitRecvTimeout > supportedLDAPPolicies: MaxConnections > supportedLDAPPolicies: MaxConnIdleTime > supportedLDAPPolicies: MaxPageSize > supportedLDAPPolicies: MaxQueryDuration > supportedLDAPPolicies: MaxTempTableSize > supportedLDAPPolicies: MaxResultSetSize > supportedLDAPPolicies: MinResultSets > supportedLDAPPolicies: MaxResultSetsPerConn > supportedLDAPPolicies: MaxNotificationPerConn > supportedLDAPPolicies: MaxValRange > highestCommittedUSN: 73772 > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: GSS-SPNEGO > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: DIGEST-MD5 > dnsHostName: Windows.test.ad > > > > > > > ldapServiceName: test.ad:windows$@TEST.AD > > > > > > > > > serverName: > > CN=WINDOWS,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Confi > guration,DC=test,DC=ad > supportedCapabilities: 1.2.840.113556.1.4.800 > supportedCapabilities: 1.2.840.113556.1.4.1670 > supportedCapabilities: 1.2.840.113556.1.4.1791 > supportedCapabilities: 1.2.840.113556.1.4.1935 > supportedCapabilities: 1.2.840.113556.1.4.2080 > isSynchronized: TRUE > isGlobalCatalogReady: TRUE > domainFunctionality: 4 > forestFunctionality: 4 > domainControllerFunctionality: 4 > > Then I tried next step: > /usr/lib64/mozldap/ldapsearch -ZZ -P > /etc/dirsrv/slapd-XXXX-COM/cert8.db -h > windows.test.ad > > > > > > > -D > "CN=administrator,CN=users,DC=test,DC=ad" -w > "xxxxx" -s base > -b "" "objectclass=*" > > ldap_simple_bind: Can't contact LDAP server > TLS/SSL error -8179 (Peer's Certificate > issuer is not > recognized.) > Please help me to fix this..... > > This usually means the SSL server's CA cert is not > recognized. > What does this say: > certutil -d /etc/dirsrv/slapd-XXXX-COM -L > ? > > > On Tue, Aug 17, 2010 at 2:02 PM, Shan > Kumaraswamy > > > > >> > > > > > >>>> > > wrote: > > Hi Rich, > After I did all the steps, I am getting > this error: > INFO:root:Added CA certificate > /etc/dirsrv/slapd-XXXX-COM/adcert.cer to > certificate > database for > tesipa001.test.com > > > > > INFO:root:Restarted directory server > tesipa001.test.com > > > > > INFO:root:Could not validate connection to > remote server > windows.test.ad:636 > > > > - continuing > > INFO:root:The error was: {'info': > 'error:14090086:SSL > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify > failed', > 'desc': "Can't contact LDAP server"} > The user for the Windows PassSync service is > > uid=passsync,cn=sysaccounts,cn=etc,dc=bmibank,dc=com > Windows PassSync entry exists, not resetting > password > INFO:root:Added new sync agreement, > waiting for > it to > become ready > . . . > INFO:root:Replication Update in progress: > FALSE: > status: 81 - > LDAP error: Can't contact LDAP server: > start: 0: > end: 0 > INFO:root:Agreement is ready, starting > replication . . . > Starting replication, please wait until > this has > completed. > [saprhds001.bmibank.com > > > > ] reports: > > Update failed! Status: [81 - LDAP error: > Can't > contact > LDAP server] > INFO:root:Added agreement for other host > windows.test.ad > > > > > > Please help me to fix this issue. > The syntex I used: > ipa-replica-manage add > --winsync > --binddn > CN=Administrator,CN=Users,DC=test,DC=com > --bindpw "password" > --cacert > /etc/dirsrv/slapd-TEST-COM/adcert.cer > windows.test.ad > > > -v --passsync > "password" > > On Mon, Aug 16, 2010 at > 6:06 PM, > Rich Megginson > > > > >> > > > > >>>> wrote: > > Shan Kumaraswamy wrote: > > Rich, > While installing IPA its creates its > won CA cert > right? > (cacert.p12), > > Right. > > and also I done the setep of > export this > CA file as > dsca.crt. > > Right. You have to do that so that > AD can > be an SSL > client to > the IPA SSL server. > > Please let me know steps to > generate the > IPA CA and > server > cert? > > The other part is that you have to > install > the AD CA > cert in > IPA so that IPA can be the SSL client > to the > AD SSL server. > > On Mon, Aug > 16, 2010 > at 5:41 PM, Rich Megginson > > > > >> > > > > >>> > > > > > >> > > > > >>>>> > > wrote: > > Shan Kumaraswamy wrote: > > > Hi, > > I have deployed FreeIPA > 1.2.1 in > RHEL 5.5 and I > want to sync > with Active Directory (windows > 2008 R2). Can > please > anyone > have step-by-step > configuration > doc and > share to me? > Previously I have done the > same > exercise, > but now > that is not > working for me and I am > facing lot of > challenges to > make this > happen. > > Please find the steps what > exactly I done so > for: > > 1. Installed RHDS > 8.1 and > FreeIPA > 1.2.1 and > configured > properly and tested its > working fine > > 2. In AD side, installed > Active Directory > certificate > Server as a Enterprise Root > > 3. Copy the ?cacert.p12? > file and > imported under > Certificates ?Service (Active > Directory Domain > service) on > Local Computer using MMC. > > 4. Installed PasSync.msi > file and > given all > the required > information > > 5. Run the command > ?certutil -d . -L > -n "CA > certificate" > -a > dsca.crt? from IPA server > and copied > the .crt > file in to > AD server and ran this command > from ?cd > "C:\Program > Files\Red > Hat Directory Password > Synchronization" > > 6. certutil.exe -d . -N > > 7. certutil.exe -d . > -A -n > "DS CA cert" -t > CT,, -a -i > \path\to\dsca.crt > > 8. certutil.exe -d . > -L -n > "DS CA > cert" and > rebooted the > AD server. > > After this steps, when try to > create sync > agreement > from IPA > server I am getting this > error: > > ldap_simple_bind: > Can't > contact > LDAP server > > SSL error -8179 (Peer's > Certificate > issuer > is not > recognized.) > > Please share the steps to > configure AD Sync with > IPA server. > > > http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Windows_Sync-Configuring_Windows_Sync.html > > But it looks as though there is a > step missing. > If you > use MS AD > CA to generate the AD cert, > and use > IPA to > generate the > IPA CA and > server cert, then you have to > import > the MS AD > CA cert > into IPA. > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From rmeggins at redhat.com Wed Aug 18 14:09:04 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 18 Aug 2010 08:09:04 -0600 Subject: [Freeipa-users] IPA+AD sync error In-Reply-To: References: <4C694DFD.5010006@redhat.com> <4C6953E6.4030500@redhat.com> <4C6AAC48.1050006@redhat.com> <4C6AB20E.5000305@redhat.com> <4C6AB852.1060608@redhat.com> <4C6BE3AF.4010205@redhat.com> Message-ID: <4C6BE980.40302@redhat.com> Shan Kumaraswamy wrote: > Ok sure, I will do the test and can please let me know command to > import AD CA in to dirsrv cert db? It is already in there? This is the certificate called "Imported CA" with Subject: "CN=test-WINDOWS-CA,DC=test,DC=ad" and Issuer: "CN=test-WINDOWS-CA,DC=test,DC=ad" Or are you asking because you don't know how it got in there in the first place, or forgot? > > > > > On Wed, Aug 18, 2010 at 4:44 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > Rich, > Can I know command to trust IPA genearated CA cert file? > > See below > > So I don't think that is the problem here. If that were the > problem, I would expect a different error message. I think you're > just going to have to use something like openssl s_client to > examine the server cert used by AD. > > > > On Tue, Aug 17, 2010 at 7:26 PM, Rich Megginson > > >> wrote: > > Shan Kumaraswamy wrote: > > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > 46:90:cd:94:c6:53:d4:ae:44:a6:df:e2:6b:24:15:56 > Signature Algorithm: PKCS #1 SHA-1 With RSA > Encryption > Issuer: "CN=test-WINDOWS-CA,DC=test,DC=ad" > Validity: > Not Before: Tue Aug 17 01:39:07 2010 > Not After : Mon Aug 17 01:49:05 2015 > Subject: "CN=test-WINDOWS-CA,DC=test,DC=ad" > Subject Public Key Info: > Public Key Algorithm: PKCS #1 RSA Encryption > RSA Public Key: > Modulus: > > a9:6e:1a:54:c2:70:1c:d7:dc:06:b4:d3:09:0f:8d:25: > > e5:8f:9f:1f:f6:f9:ee:fb:9c:6b:9c:84:c3:01:f7:45: > > f1:8e:43:d3:ed:ad:01:e6:92:6c:52:f4:d7:03:03:19: > > 0a:93:84:18:42:92:2b:6b:74:3d:77:8c:31:b9:bf:75: > > 84:cb:a0:8c:a5:df:c2:5a:d6:cb:a3:78:a2:1a:6d:a6: > > e1:b4:81:ea:22:e7:83:bb:1f:0d:70:f8:44:29:24:96: > > f3:f0:01:12:49:7a:59:b8:f7:1a:84:e4:e4:a4:0d:60: > > 58:db:d9:9c:b4:51:7a:21:f2:a2:f9:ed:ee:92:6f:c0: > > 00:39:dc:26:9f:c5:0b:e3:e1:72:62:5d:9f:8e:4a:79: > > f3:95:56:a0:37:63:9a:d1:53:af:74:0b:c9:88:b7:43: > > ff:11:cb:91:02:4a:5c:8c:35:41:cb:39:4e:fb:8c:a4: > > 2d:a6:88:7b:dc:29:04:7a:f0:0a:89:25:24:76:b1:34: > > 57:1e:c2:3f:48:79:21:47:f0:f1:1a:70:15:d8:b5:9b: > > cb:bc:a2:3c:42:f6:da:91:a7:24:5b:fa:08:ec:41:8b: > > c5:82:7c:81:76:3c:ef:84:58:93:cd:92:36:5d:96:55: > > 40:72:21:5e:14:7c:fe:78:cf:35:69:97:4a:49:35:81 > Exponent: 65537 (0x10001) > Signed Extensions: > Name: Microsoft Enrollment Cert Type Extension > Data: "CA" > > Name: Certificate Key Usage > Critical: True > Usages: Digital Signature > Certificate Signing > CRL Signing > > Name: Certificate Basic Constraints > Critical: True > Data: Is a CA with no maximum path length. > > Name: Certificate Subject Key ID > Data: > > a9:7a:6e:7c:dd:dd:4f:9e:75:78:86:6a:ff:f1:b4:06: > e6:fb:3a:6d > > Name: Microsoft CertServ CA version > Data: 0 (0x0) > > Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption > Signature: > 02:50:bd:c6:3a:80:85:9d:46:16:94:8c:e2:e8:2f:0d: > 35:09:d7:af:e1:ce:c0:23:94:19:ef:a7:df:de:56:17: > c8:9e:d5:a0:80:7e:31:46:1d:c0:c1:5a:e9:7d:fe:c3: > bb:08:c0:6d:35:3a:f2:43:c2:b7:2f:44:2b:89:7f:f1: > ad:e8:9e:51:fa:98:12:d9:2b:2d:08:00:80:c3:78:93: > e7:bc:ee:17:ae:a3:07:81:6b:63:ac:bf:65:d5:e9:a8: > e9:81:42:56:24:fc:2f:b8:d1:76:5b:72:c0:8f:62:66: > cc:4d:5b:84:85:fb:63:06:6c:0a:54:a0:55:08:bf:11: > 4b:30:ab:ba:49:19:39:ee:4f:57:3c:7b:0b:d3:8d:fe: > 10:d8:18:63:ee:86:e9:cb:89:1e:ea:7e:0a:68:8c:f8: > da:40:69:ca:2c:bc:5d:24:18:bc:2b:d7:ce:08:ca:d7: > e8:aa:4b:d8:cb:ee:17:f3:4f:18:29:fc:48:59:ae:98: > 18:37:f0:a7:cd:42:1f:5d:79:cd:a1:0f:30:41:7f:97: > 81:43:68:8b:74:0c:d8:21:b6:eb:76:14:bf:44:14:13: > dd:07:ee:ce:68:95:29:b1:14:f6:93:81:90:b5:e6:6a: > 2b:38:6a:f0:4c:20:3f:fc:88:84:3f:43:5e:5f:6e:ed > Fingerprint (MD5): > 4B:AE:EB:7D:D0:B6:C8:D3:15:1B:08:ED:39:A0:68:6C > Fingerprint (SHA1): > > 84:17:7E:EE:93:B2:A3:4F:D9:7B:72:C6:ED:D6:61:9E:0E:82:51:BC > > Certificate Trust Flags: > SSL Flags: > Valid CA > Trusted CA > Trusted Client CA > Email Flags: > Object Signing Flags: > Valid CA > Trusted CA > > This looks ok. So is it possible the AD server cert was not > issued by this CA? I suppose you could use an SSL test program > like /usr/bin/ssltap > or openssl s_client like this: > openssl s_client -connect windows.test.ad:636 > > -CAfile /path/to/msadcacert.asc > > You can also add -verify 3 and -showcerts and -debug > see "man s_client" for more information > > > > > On Tue, Aug 17, 2010 at 7:04 PM, Shan Kumaraswamy > > > > >>> > wrote: > > done, and it came the output also, can plz let me > know the > next step. > > > On Tue, Aug 17, 2010 at 7:00 PM, Rich Megginson > > > > >>> wrote: > > Shan Kumaraswamy wrote: > > Rich, > Please find the below out put of the command: > [root at saprhds001 ~]# certutil -d > /etc/dirsrv/slapd-XXXX-COM -L > Certificate Nickname > Trust Attributes > > SSL,S/MIME,JAR/XPI > Imported CA > CT,,C > CA certificate > CTu,u,Cu > > The CT means the CA is trusted for SSL client and server certs. > certutil -H > ... > trustargs is of the form x,y,z where x is > for SSL, y is for S/MIME, > ... > c valid CA > T trusted CA to issue client certs > (implies c) > C trusted CA to issue server certs > (implies c) > > Server-Cert > u,u,u > > I'm assuming "Imported CA" is the MS AD CA. Do > this: > certutil -d /etc/dirsrv/slapd-XXXX-COM -L -n > "Imported CA" > > > > On Tue, Aug 17, 2010 at 6:35 PM, Rich Megginson > > > >> > > > > >>>> > wrote: > > Shan Kumaraswamy wrote: > > After this error, I have triyed your the > following > steps: > /usr/lib64/mozldap/ldapsearch -h > windows.test.ad > > > > > > > > > -D > > "CN=administrator,CN=users,DC=test,DC=ad" -w > "xxxx" > -s base -b > "" "objectclass=*" > > Then I got output like this: > version: 1 > dn: > currentTime: 20100817220245.0Z > subschemaSubentry: > > CN=Aggregate,CN=Schema,CN=Configuration,DC=test,DC=ad > dsServiceName: CN=NTDS > > Settings,CN=WINDOWS,CN=Servers,CN=Default-First-Site-Na > > me,CN=Sites,CN=Configuration,DC=test,DC=ad > namingContexts: DC=test,DC=ad > namingContexts: > CN=Configuration,DC=test,DC=ad > namingContexts: > CN=Schema,CN=Configuration,DC=test,DC=ad > namingContexts: > DC=DomainDnsZones,DC=test,DC=ad > namingContexts: > DC=ForestDnsZones,DC=test,DC=ad > defaultNamingContext: DC=test,DC=ad > schemaNamingContext: > CN=Schema,CN=Configuration,DC=test,DC=ad > configurationNamingContext: > CN=Configuration,DC=test,DC=ad > rootDomainNamingContext: DC=test,DC=ad > supportedControl: 1.2.840.113556.1.4.319 > supportedControl: 1.2.840.113556.1.4.801 > supportedControl: 1.2.840.113556.1.4.473 > supportedControl: 1.2.840.113556.1.4.528 > supportedControl: 1.2.840.113556.1.4.417 > supportedControl: 1.2.840.113556.1.4.619 > supportedControl: 1.2.840.113556.1.4.841 > supportedControl: 1.2.840.113556.1.4.529 > supportedControl: 1.2.840.113556.1.4.805 > supportedControl: 1.2.840.113556.1.4.521 > supportedControl: 1.2.840.113556.1.4.970 > supportedControl: 1.2.840.113556.1.4.1338 > supportedControl: 1.2.840.113556.1.4.474 > supportedControl: 1.2.840.113556.1.4.1339 > supportedControl: 1.2.840.113556.1.4.1340 > supportedControl: 1.2.840.113556.1.4.1413 > supportedControl: 2.16.840.1.113730.3.4.9 > supportedControl: > 2.16.840.1.113730.3.4.10 > supportedControl: 1.2.840.113556.1.4.1504 > supportedControl: 1.2.840.113556.1.4.1852 > supportedControl: 1.2.840.113556.1.4.802 > supportedControl: 1.2.840.113556.1.4.1907 > supportedControl: 1.2.840.113556.1.4.1948 > supportedControl: 1.2.840.113556.1.4.1974 > supportedControl: 1.2.840.113556.1.4.1341 > supportedControl: 1.2.840.113556.1.4.2026 > supportedControl: 1.2.840.113556.1.4.2064 > supportedControl: 1.2.840.113556.1.4.2065 > supportedLDAPVersion: 3 > supportedLDAPVersion: 2 > supportedLDAPPolicies: MaxPoolThreads > supportedLDAPPolicies: MaxDatagramRecv > supportedLDAPPolicies: MaxReceiveBuffer > supportedLDAPPolicies: InitRecvTimeout > supportedLDAPPolicies: MaxConnections > supportedLDAPPolicies: MaxConnIdleTime > supportedLDAPPolicies: MaxPageSize > supportedLDAPPolicies: MaxQueryDuration > supportedLDAPPolicies: MaxTempTableSize > supportedLDAPPolicies: MaxResultSetSize > supportedLDAPPolicies: MinResultSets > supportedLDAPPolicies: > MaxResultSetsPerConn > supportedLDAPPolicies: > MaxNotificationPerConn > supportedLDAPPolicies: MaxValRange > highestCommittedUSN: 73772 > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: GSS-SPNEGO > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: DIGEST-MD5 > dnsHostName: Windows.test.ad > > > > > > > > > > ldapServiceName: > test.ad:windows$@TEST.AD > > > > > > > > > > serverName: > > CN=WINDOWS,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Confi > guration,DC=test,DC=ad > supportedCapabilities: > 1.2.840.113556.1.4.800 > supportedCapabilities: > 1.2.840.113556.1.4.1670 > supportedCapabilities: > 1.2.840.113556.1.4.1791 > supportedCapabilities: > 1.2.840.113556.1.4.1935 > supportedCapabilities: > 1.2.840.113556.1.4.2080 > isSynchronized: TRUE > isGlobalCatalogReady: TRUE > domainFunctionality: 4 > forestFunctionality: 4 > domainControllerFunctionality: 4 > > Then I tried next step: > /usr/lib64/mozldap/ldapsearch -ZZ -P > /etc/dirsrv/slapd-XXXX-COM/cert8.db -h > windows.test.ad > > > > > > > > > -D > > "CN=administrator,CN=users,DC=test,DC=ad" -w > "xxxxx" -s base > -b "" "objectclass=*" > > ldap_simple_bind: Can't contact LDAP > server > TLS/SSL error -8179 (Peer's > Certificate > issuer is not > recognized.) > Please help me to fix this..... > > This usually means the SSL server's CA > cert is not > recognized. > What does this say: > certutil -d /etc/dirsrv/slapd-XXXX-COM -L > ? > > > On Tue, Aug 17, 2010 at 2:02 PM, Shan > Kumaraswamy > > > > > >> > > > > >>> > > > > > >> > > > > > >>>>> > > wrote: > > Hi Rich, > After I did all the steps, I am > getting > this error: > INFO:root:Added CA > certificate > > /etc/dirsrv/slapd-XXXX-COM/adcert.cer to > certificate > database for > tesipa001.test.com > > > > > > INFO:root:Restarted directory server > tesipa001.test.com > > > > > > INFO:root:Could not validate > connection to > remote server > windows.test.ad:636 > > > > > - > continuing > > INFO:root:The error was: {'info': > 'error:14090086:SSL > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify > failed', > 'desc': "Can't contact LDAP server"} > The user for the Windows PassSync > service is > > uid=passsync,cn=sysaccounts,cn=etc,dc=bmibank,dc=com > Windows PassSync entry exists, not > resetting > password > INFO:root:Added new sync agreement, > waiting for > it to > become ready > . . . > INFO:root:Replication Update in > progress: > FALSE: > status: 81 - > LDAP error: Can't contact LDAP server: > start: 0: > end: 0 > INFO:root:Agreement is ready, starting > replication . . . > Starting replication, please wait > until > this has > completed. > [saprhds001.bmibank.com > > > > > ] > reports: > > Update failed! Status: [81 - LDAP > error: > Can't > contact > LDAP server] > INFO:root:Added agreement for > other host > windows.test.ad > > > > > > > Please help me to fix this issue. > The syntex I used: > ipa-replica-manage add > --winsync > --binddn > > CN=Administrator,CN=Users,DC=test,DC=com > --bindpw "password" > --cacert > /etc/dirsrv/slapd-TEST-COM/adcert.cer > windows.test.ad > > > > -v > --passsync > "password" > > On Mon, Aug 16, > 2010 at > 6:06 PM, > Rich Megginson > > > > > >> > > > > >>> > > > > > >> > > > > >>>>> wrote: > > Shan Kumaraswamy wrote: > > Rich, > While installing IPA its > creates its > won CA cert > right? > (cacert.p12), > > Right. > > and also I done the setep of > export this > CA file as > dsca.crt. > > Right. You have to do that so > that > AD can > be an SSL > client to > the IPA SSL server. > > Please let me know steps to > generate the > IPA CA and > server > cert? > > The other part is that you have to > install > the AD CA > cert in > IPA so that IPA can be the SSL > client > to the > AD SSL server. > > On > Mon, Aug > 16, 2010 > at 5:41 PM, Rich Megginson > > > > > >> > > > > >>> > > > > > >> > > > > >>>> > > > > > > >> > > > > > >>> > > > > >> > > > > > >>>>>> > > wrote: > > Shan Kumaraswamy wrote: > > > Hi, > > I have deployed FreeIPA > 1.2.1 in > RHEL 5.5 and I > want to sync > with Active > Directory (windows > 2008 R2). Can > please > anyone > have step-by-step > configuration > doc and > share to me? > Previously I have > done the > same > exercise, > but now > that is not > working for me and I am > facing lot of > challenges to > make this > happen. > > Please find the > steps what > exactly I done so > for: > > 1. Installed RHDS > 8.1 and > FreeIPA > 1.2.1 and > configured > properly and tested its > working fine > > 2. In AD > side, installed > Active Directory > certificate > Server as a > Enterprise Root > > 3. Copy the > ?cacert.p12? > file and > imported under > Certificates > ?Service (Active > Directory Domain > service) on > Local Computer > using MMC. > > 4. Installed > PasSync.msi > file and > given all > the required > information > > 5. Run the > command > ?certutil -d . -L > -n "CA > certificate" > -a > dsca.crt? from > IPA server > and copied > the .crt > file in to > AD server and ran > this command > from ?cd > "C:\Program > Files\Red > Hat Directory Password > Synchronization" > > 6. > certutil.exe -d . -N > > 7. > certutil.exe -d . > -A -n > "DS CA cert" -t > CT,, -a -i > \path\to\dsca.crt > > 8. > certutil.exe -d . > -L -n > "DS CA > cert" and > rebooted the > AD server. > > After this steps, > when try to > create sync > agreement > from IPA > server I am getting > this > error: > > > ldap_simple_bind: > Can't > contact > LDAP server > > SSL error > -8179 (Peer's > Certificate > issuer > is not > recognized.) > > Please share the > steps to > configure AD Sync with > IPA server. > > > > http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Windows_Sync-Configuring_Windows_Sync.html > > But it looks as though > there is a > step missing. > If you > use MS AD > CA to generate the AD cert, > and use > IPA to > generate the > IPA CA and > server cert, then you > have to > import > the MS AD > CA cert > into IPA. > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & > Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From rmeggins at redhat.com Wed Aug 18 14:28:03 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 18 Aug 2010 08:28:03 -0600 Subject: [Freeipa-users] IPA+AD sync error In-Reply-To: References: <4C694DFD.5010006@redhat.com> <4C6953E6.4030500@redhat.com> <4C6AAC48.1050006@redhat.com> <4C6AB20E.5000305@redhat.com> <4C6AB852.1060608@redhat.com> <4C6BE3AF.4010205@redhat.com> <4C6BE980.40302@redhat.com> Message-ID: <4C6BEDF3.4020106@redhat.com> Shan Kumaraswamy wrote: > Sorry, I was deleted the copyied cert file.... :( If you want to get the CA cert out of the certdb and into ascii/pem format: certutil -d /etc/dirsrv/slapd-instancename -L -n "Imported CA" -a > msadca.crt If you want to get the CA cert directly from MS CA: on your AD box, open a web browser go to http:///certsrv There should be an option there to view or download the CA cert. You want to download it in ascii/pem/base64 format (I think Windows uses the term Base64 encoded cert for PEM). Then you'll have to copy that file to your IPA box. > > > > On Wed, Aug 18, 2010 at 5:09 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > Ok sure, I will do the test and can please let me know command > to import AD CA in to dirsrv cert db? > > It is already in there? This is the certificate called "Imported > CA" with Subject: "CN=test-WINDOWS-CA,DC=test,DC=ad" and Issuer: > "CN=test-WINDOWS-CA,DC=test,DC=ad" > > Or are you asking because you don't know how it got in there in > the first place, or forgot? > > > > On Wed, Aug 18, 2010 at 4:44 PM, Rich Megginson > > >> wrote: > > Shan Kumaraswamy wrote: > > Rich, > Can I know command to trust IPA genearated CA cert file? > > See below > > So I don't think that is the problem here. If that were the > problem, I would expect a different error message. I think > you're > just going to have to use something like openssl s_client to > examine the server cert used by AD. > > > On Tue, Aug 17, 2010 at 7:26 PM, Rich Megginson > > > > >>> wrote: > > Shan Kumaraswamy wrote: > > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > > 46:90:cd:94:c6:53:d4:ae:44:a6:df:e2:6b:24:15:56 > Signature Algorithm: PKCS #1 SHA-1 With RSA > Encryption > Issuer: "CN=test-WINDOWS-CA,DC=test,DC=ad" > Validity: > Not Before: Tue Aug 17 01:39:07 2010 > Not After : Mon Aug 17 01:49:05 2015 > Subject: "CN=test-WINDOWS-CA,DC=test,DC=ad" > Subject Public Key Info: > Public Key Algorithm: PKCS #1 RSA > Encryption > RSA Public Key: > Modulus: > > a9:6e:1a:54:c2:70:1c:d7:dc:06:b4:d3:09:0f:8d:25: > > e5:8f:9f:1f:f6:f9:ee:fb:9c:6b:9c:84:c3:01:f7:45: > > f1:8e:43:d3:ed:ad:01:e6:92:6c:52:f4:d7:03:03:19: > > 0a:93:84:18:42:92:2b:6b:74:3d:77:8c:31:b9:bf:75: > > 84:cb:a0:8c:a5:df:c2:5a:d6:cb:a3:78:a2:1a:6d:a6: > > e1:b4:81:ea:22:e7:83:bb:1f:0d:70:f8:44:29:24:96: > > f3:f0:01:12:49:7a:59:b8:f7:1a:84:e4:e4:a4:0d:60: > > 58:db:d9:9c:b4:51:7a:21:f2:a2:f9:ed:ee:92:6f:c0: > > 00:39:dc:26:9f:c5:0b:e3:e1:72:62:5d:9f:8e:4a:79: > > f3:95:56:a0:37:63:9a:d1:53:af:74:0b:c9:88:b7:43: > > ff:11:cb:91:02:4a:5c:8c:35:41:cb:39:4e:fb:8c:a4: > > 2d:a6:88:7b:dc:29:04:7a:f0:0a:89:25:24:76:b1:34: > > 57:1e:c2:3f:48:79:21:47:f0:f1:1a:70:15:d8:b5:9b: > > cb:bc:a2:3c:42:f6:da:91:a7:24:5b:fa:08:ec:41:8b: > > c5:82:7c:81:76:3c:ef:84:58:93:cd:92:36:5d:96:55: > > 40:72:21:5e:14:7c:fe:78:cf:35:69:97:4a:49:35:81 > Exponent: 65537 (0x10001) > Signed Extensions: > Name: Microsoft Enrollment Cert Type > Extension > Data: "CA" > > Name: Certificate Key Usage > Critical: True > Usages: Digital Signature > Certificate Signing > CRL Signing > > Name: Certificate Basic Constraints > Critical: True > Data: Is a CA with no maximum path > length. > > Name: Certificate Subject Key ID > Data: > > a9:7a:6e:7c:dd:dd:4f:9e:75:78:86:6a:ff:f1:b4:06: > e6:fb:3a:6d > > Name: Microsoft CertServ CA version > Data: 0 (0x0) > > Signature Algorithm: PKCS #1 SHA-1 With RSA > Encryption > Signature: > > 02:50:bd:c6:3a:80:85:9d:46:16:94:8c:e2:e8:2f:0d: > > 35:09:d7:af:e1:ce:c0:23:94:19:ef:a7:df:de:56:17: > > c8:9e:d5:a0:80:7e:31:46:1d:c0:c1:5a:e9:7d:fe:c3: > > bb:08:c0:6d:35:3a:f2:43:c2:b7:2f:44:2b:89:7f:f1: > > ad:e8:9e:51:fa:98:12:d9:2b:2d:08:00:80:c3:78:93: > > e7:bc:ee:17:ae:a3:07:81:6b:63:ac:bf:65:d5:e9:a8: > > e9:81:42:56:24:fc:2f:b8:d1:76:5b:72:c0:8f:62:66: > > cc:4d:5b:84:85:fb:63:06:6c:0a:54:a0:55:08:bf:11: > > 4b:30:ab:ba:49:19:39:ee:4f:57:3c:7b:0b:d3:8d:fe: > > 10:d8:18:63:ee:86:e9:cb:89:1e:ea:7e:0a:68:8c:f8: > > da:40:69:ca:2c:bc:5d:24:18:bc:2b:d7:ce:08:ca:d7: > > e8:aa:4b:d8:cb:ee:17:f3:4f:18:29:fc:48:59:ae:98: > > 18:37:f0:a7:cd:42:1f:5d:79:cd:a1:0f:30:41:7f:97: > > 81:43:68:8b:74:0c:d8:21:b6:eb:76:14:bf:44:14:13: > > dd:07:ee:ce:68:95:29:b1:14:f6:93:81:90:b5:e6:6a: > > 2b:38:6a:f0:4c:20:3f:fc:88:84:3f:43:5e:5f:6e:ed > Fingerprint (MD5): > > 4B:AE:EB:7D:D0:B6:C8:D3:15:1B:08:ED:39:A0:68:6C > Fingerprint (SHA1): > > 84:17:7E:EE:93:B2:A3:4F:D9:7B:72:C6:ED:D6:61:9E:0E:82:51:BC > > Certificate Trust Flags: > SSL Flags: > Valid CA > Trusted CA > Trusted Client CA > Email Flags: > Object Signing Flags: > Valid CA > Trusted CA > > This looks ok. So is it possible the AD server cert > was not > issued by this CA? I suppose you could use an SSL > test program > like /usr/bin/ssltap > or openssl s_client like this: > openssl s_client -connect windows.test.ad:636 > > > -CAfile > /path/to/msadcacert.asc > > You can also add -verify 3 and -showcerts and -debug > see "man s_client" for more information > > > > > On Tue, Aug 17, 2010 at 7:04 PM, Shan Kumaraswamy > > > >> > > > > >>>> > wrote: > > done, and it came the output also, can plz let me > know the > next step. > > > On Tue, Aug 17, 2010 at 7:00 PM, Rich Megginson > > > >> > > > > >>>> wrote: > > Shan Kumaraswamy wrote: > > Rich, > Please find the below out put of the > command: > [root at saprhds001 ~]# certutil -d > /etc/dirsrv/slapd-XXXX-COM -L > Certificate Nickname > Trust Attributes > > SSL,S/MIME,JAR/XPI > Imported CA > CT,,C > CA certificate > CTu,u,Cu > > The CT means the CA is trusted for SSL client and server certs. > certutil -H > ... > trustargs is of the form x,y,z > where x is > for SSL, y is for S/MIME, > ... > c valid CA > T trusted CA to issue client certs > (implies c) > C trusted CA to issue server certs > (implies c) > > Server-Cert > u,u,u > > I'm assuming "Imported CA" is the MS AD > CA. Do > this: > certutil -d /etc/dirsrv/slapd-XXXX-COM -L -n > "Imported CA" > > > > On Tue, Aug 17, 2010 at 6:35 PM, Rich > Megginson > > > > >> > > > > >>> > > > > > >> > > > > >>>>> > wrote: > > Shan Kumaraswamy wrote: > > After this error, I have > triyed your the > following > steps: > /usr/lib64/mozldap/ldapsearch -h > windows.test.ad > > > > > > > > > > -D > > "CN=administrator,CN=users,DC=test,DC=ad" -w > "xxxx" > -s base -b > "" "objectclass=*" > > Then I got output like this: > version: 1 > dn: > currentTime: 20100817220245.0Z > subschemaSubentry: > > CN=Aggregate,CN=Schema,CN=Configuration,DC=test,DC=ad > dsServiceName: CN=NTDS > > Settings,CN=WINDOWS,CN=Servers,CN=Default-First-Site-Na > > me,CN=Sites,CN=Configuration,DC=test,DC=ad > namingContexts: DC=test,DC=ad > namingContexts: > CN=Configuration,DC=test,DC=ad > namingContexts: > CN=Schema,CN=Configuration,DC=test,DC=ad > namingContexts: > DC=DomainDnsZones,DC=test,DC=ad > namingContexts: > DC=ForestDnsZones,DC=test,DC=ad > defaultNamingContext: > DC=test,DC=ad > schemaNamingContext: > CN=Schema,CN=Configuration,DC=test,DC=ad > configurationNamingContext: > CN=Configuration,DC=test,DC=ad > rootDomainNamingContext: > DC=test,DC=ad > supportedControl: > 1.2.840.113556.1.4.319 > supportedControl: > 1.2.840.113556.1.4.801 > supportedControl: > 1.2.840.113556.1.4.473 > supportedControl: > 1.2.840.113556.1.4.528 > supportedControl: > 1.2.840.113556.1.4.417 > supportedControl: > 1.2.840.113556.1.4.619 > supportedControl: > 1.2.840.113556.1.4.841 > supportedControl: > 1.2.840.113556.1.4.529 > supportedControl: > 1.2.840.113556.1.4.805 > supportedControl: > 1.2.840.113556.1.4.521 > supportedControl: > 1.2.840.113556.1.4.970 > supportedControl: > 1.2.840.113556.1.4.1338 > supportedControl: > 1.2.840.113556.1.4.474 > supportedControl: > 1.2.840.113556.1.4.1339 > supportedControl: > 1.2.840.113556.1.4.1340 > supportedControl: > 1.2.840.113556.1.4.1413 > supportedControl: > 2.16.840.1.113730.3.4.9 > supportedControl: > 2.16.840.1.113730.3.4.10 > supportedControl: > 1.2.840.113556.1.4.1504 > supportedControl: > 1.2.840.113556.1.4.1852 > supportedControl: > 1.2.840.113556.1.4.802 > supportedControl: > 1.2.840.113556.1.4.1907 > supportedControl: > 1.2.840.113556.1.4.1948 > supportedControl: > 1.2.840.113556.1.4.1974 > supportedControl: > 1.2.840.113556.1.4.1341 > supportedControl: > 1.2.840.113556.1.4.2026 > supportedControl: > 1.2.840.113556.1.4.2064 > supportedControl: > 1.2.840.113556.1.4.2065 > supportedLDAPVersion: 3 > supportedLDAPVersion: 2 > supportedLDAPPolicies: > MaxPoolThreads > supportedLDAPPolicies: > MaxDatagramRecv > supportedLDAPPolicies: > MaxReceiveBuffer > supportedLDAPPolicies: > InitRecvTimeout > supportedLDAPPolicies: > MaxConnections > supportedLDAPPolicies: > MaxConnIdleTime > supportedLDAPPolicies: MaxPageSize > supportedLDAPPolicies: > MaxQueryDuration > supportedLDAPPolicies: > MaxTempTableSize > supportedLDAPPolicies: > MaxResultSetSize > supportedLDAPPolicies: > MinResultSets > supportedLDAPPolicies: > MaxResultSetsPerConn > supportedLDAPPolicies: > MaxNotificationPerConn > supportedLDAPPolicies: MaxValRange > highestCommittedUSN: 73772 > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: > GSS-SPNEGO > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: > DIGEST-MD5 > dnsHostName: Windows.test.ad > > > > > > > > > > > > ldapServiceName: > test.ad:windows$@TEST.AD > > > > > > > > > > > serverName: > > CN=WINDOWS,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Confi > guration,DC=test,DC=ad > supportedCapabilities: > 1.2.840.113556.1.4.800 > supportedCapabilities: > 1.2.840.113556.1.4.1670 > supportedCapabilities: > 1.2.840.113556.1.4.1791 > supportedCapabilities: > 1.2.840.113556.1.4.1935 > supportedCapabilities: > 1.2.840.113556.1.4.2080 > isSynchronized: TRUE > isGlobalCatalogReady: TRUE > domainFunctionality: 4 > forestFunctionality: 4 > domainControllerFunctionality: 4 > > Then I tried next step: > /usr/lib64/mozldap/ldapsearch > -ZZ -P > > /etc/dirsrv/slapd-XXXX-COM/cert8.db -h > windows.test.ad > > > > > > > > > > -D > > "CN=administrator,CN=users,DC=test,DC=ad" -w > "xxxxx" -s base > -b "" "objectclass=*" > > ldap_simple_bind: Can't > contact LDAP > server > TLS/SSL error -8179 (Peer's > Certificate > issuer is not > recognized.) > Please help me to fix this..... > > This usually means the SSL server's CA > cert is not > recognized. > What does this say: > certutil -d > /etc/dirsrv/slapd-XXXX-COM -L > ? > > > On Tue, Aug 17, 2010 at 2:02 > PM, Shan > Kumaraswamy > > > > > >> > > > > > >>> > > > > > >> > > > > >>>> > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>>> > > wrote: > > Hi Rich, > After I did all the steps, I am > getting > this error: > INFO:root:Added CA > certificate > > /etc/dirsrv/slapd-XXXX-COM/adcert.cer to > certificate > database for > tesipa001.test.com > > > > > > > > INFO:root:Restarted > directory server > tesipa001.test.com > > > > > > > INFO:root:Could not validate > connection to > remote server > windows.test.ad:636 > > > > > > - > continuing > > INFO:root:The error was: > {'info': > 'error:14090086:SSL > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify > failed', > 'desc': "Can't contact LDAP > server"} > The user for the Windows > PassSync > service is > > uid=passsync,cn=sysaccounts,cn=etc,dc=bmibank,dc=com > Windows PassSync entry > exists, not > resetting > password > INFO:root:Added new sync > agreement, > waiting for > it to > become ready > . . . > INFO:root:Replication Update in > progress: > FALSE: > status: 81 - > LDAP error: Can't contact > LDAP server: > start: 0: > end: 0 > INFO:root:Agreement is > ready, starting > replication . . . > Starting replication, > please wait > until > this has > completed. > [saprhds001.bmibank.com > > > > > > ] > reports: > > Update failed! Status: [81 > - LDAP > error: > Can't > contact > LDAP server] > INFO:root:Added agreement for > other host > windows.test.ad > > > > > > > > Please help me to fix this > issue. > The syntex I used: > ipa-replica-manage add > --winsync > --binddn > > CN=Administrator,CN=Users,DC=test,DC=com > --bindpw "password" > --cacert > /etc/dirsrv/slapd-TEST-COM/adcert.cer > windows.test.ad > > > > > -v > --passsync > "password" > > On Mon, Aug 16, > 2010 at > 6:06 PM, > Rich Megginson > > > > >> > > > > > >>> > > > >> > > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > > >>>>>> wrote: > > Shan Kumaraswamy wrote: > > Rich, > While installing > IPA its > creates its > won CA cert > right? > (cacert.p12), > > Right. > > and also I done the > setep of > export this > CA file as > dsca.crt. > > Right. You have to do > that so > that > AD can > be an SSL > client to > the IPA SSL server. > > Please let me know > steps to > generate the > IPA CA and > server > cert? > > The other part is that > you have to > install > the AD CA > cert in > IPA so that IPA can be > the SSL > client > to the > AD SSL server. > > On > Mon, Aug > 16, 2010 > at 5:41 PM, Rich Megginson > > > > > >> > > > > > >>> > > > >> > > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > > >>>>> > > > > > >> > > > > >>> > > > > >> > > > > > >>>> > > > >> > > > > >>> > > > > >> > > > > > >>>>>>> > > wrote: > > Shan Kumaraswamy > wrote: > > > Hi, > > I have > deployed FreeIPA > 1.2.1 in > RHEL 5.5 and I > want to sync > with Active > Directory (windows > 2008 R2). Can > please > anyone > have > step-by-step > configuration > doc and > share to me? > Previously I > have > done the > same > exercise, > but now > that is not > working for > me and I am > facing lot of > challenges to > make this > happen. > > Please find the > steps what > exactly I done so > for: > > 1. > Installed RHDS > 8.1 and > FreeIPA > 1.2.1 and > configured > properly and > tested its > working fine > > 2. In AD > side, installed > Active Directory > certificate > Server as a > Enterprise Root > > 3. > Copy the > ?cacert.p12? > file and > imported under > Certificates > ?Service (Active > Directory Domain > service) on > Local Computer > using MMC. > > 4. > Installed > PasSync.msi > file and > given all > the required > information > > 5. Run the > command > ?certutil -d . -L > -n "CA > certificate" > -a > > dsca.crt? from > IPA server > and copied > the .crt > file in to > AD server > and ran > this command > from ?cd > "C:\Program > Files\Red > Hat > Directory Password > Synchronization" > > 6. > certutil.exe -d . -N > > 7. > certutil.exe -d . > -A -n > "DS CA cert" -t > CT,, -a -i > > \path\to\dsca.crt > > 8. > certutil.exe -d . > -L -n > "DS CA > cert" and > rebooted the > AD server. > > After this > steps, > when try to > create sync > agreement > from IPA > server I am > getting > this > error: > > > ldap_simple_bind: > Can't > contact > LDAP server > > SSL error > -8179 (Peer's > Certificate > issuer > is not > recognized.) > > Please share the > steps to > configure AD Sync with > IPA server. > > > > http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Windows_Sync-Configuring_Windows_Sync.html > > But it looks as > though > there is a > step missing. > If you > use MS AD > CA to generate > the AD cert, > and use > IPA to > generate the > IPA CA and > server cert, > then you > have to > import > the MS AD > CA cert > into IPA. > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & > Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From rmeggins at redhat.com Wed Aug 18 16:53:19 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 18 Aug 2010 10:53:19 -0600 Subject: [Freeipa-users] IPA+AD sync error In-Reply-To: References: <4C694DFD.5010006@redhat.com> <4C6953E6.4030500@redhat.com> <4C6AAC48.1050006@redhat.com> <4C6AB20E.5000305@redhat.com> <4C6AB852.1060608@redhat.com> <4C6BE3AF.4010205@redhat.com> <4C6BE980.40302@redhat.com> <4C6BEDF3.4020106@redhat.com> Message-ID: <4C6C0FFF.50301@redhat.com> Shan Kumaraswamy wrote: > Rich, > When I try to open redhat-idm-console using directory server, I am > getting this error: > > The certificate this server present is either untrusted or unkown. The > server only communicate through a secure connection involving a > certivicate. Do you wihs to accept this certificate anyway? > > As per this message even I say yes to proceed, but fail to open. > Please advice. The use of the console is not supported with IPA. The console keeps its cert database in ~/.redhat-idm-console - unless you have previously installed the CA cert there, the console will prompt you if you want to trust the server. I'm not sure why the console will not open, except that the console does not generally work with IPA. You can use redhat-idm-console -D 9 -f console.log to get detailed trace information from the console. > > On Wed, Aug 18, 2010 at 5:28 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > Sorry, I was deleted the copyied cert file.... :( > > If you want to get the CA cert out of the certdb and into > ascii/pem format: > certutil -d /etc/dirsrv/slapd-instancename -L -n "Imported CA" -a > > msadca.crt > > If you want to get the CA cert directly from MS CA: > on your AD box, open a web browser > go to http:///certsrv > There should be an option there to view or download the CA cert. > You want to download it in ascii/pem/base64 format (I think > Windows uses the term Base64 encoded cert for PEM). Then you'll > have to copy that file to your IPA box. > > > > On Wed, Aug 18, 2010 at 5:09 PM, Rich Megginson > > >> wrote: > > Shan Kumaraswamy wrote: > > Ok sure, I will do the test and can please let me know > command > to import AD CA in to dirsrv cert db? > > It is already in there? This is the certificate called > "Imported > CA" with Subject: "CN=test-WINDOWS-CA,DC=test,DC=ad" and > Issuer: > "CN=test-WINDOWS-CA,DC=test,DC=ad" > > Or are you asking because you don't know how it got in there in > the first place, or forgot? > > > On Wed, Aug 18, 2010 at 4:44 PM, Rich Megginson > > > > >>> wrote: > > Shan Kumaraswamy wrote: > > Rich, > Can I know command to trust IPA genearated CA > cert file? > > See below > > So I don't think that is the problem here. If that > were the > problem, I would expect a different error message. > I think > you're > just going to have to use something like openssl > s_client to > examine the server cert used by AD. > > On Tue, Aug 17, 2010 at 7:26 PM, > Rich Megginson > > > >> > > > > >>>> wrote: > > Shan Kumaraswamy wrote: > > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > > 46:90:cd:94:c6:53:d4:ae:44:a6:df:e2:6b:24:15:56 > Signature Algorithm: PKCS #1 SHA-1 > With RSA > Encryption > Issuer: > "CN=test-WINDOWS-CA,DC=test,DC=ad" > Validity: > Not Before: Tue Aug 17 > 01:39:07 2010 > Not After : Mon Aug 17 > 01:49:05 2015 > Subject: > "CN=test-WINDOWS-CA,DC=test,DC=ad" > Subject Public Key Info: > Public Key Algorithm: PKCS #1 RSA > Encryption > RSA Public Key: > Modulus: > > a9:6e:1a:54:c2:70:1c:d7:dc:06:b4:d3:09:0f:8d:25: > > e5:8f:9f:1f:f6:f9:ee:fb:9c:6b:9c:84:c3:01:f7:45: > > f1:8e:43:d3:ed:ad:01:e6:92:6c:52:f4:d7:03:03:19: > > 0a:93:84:18:42:92:2b:6b:74:3d:77:8c:31:b9:bf:75: > > 84:cb:a0:8c:a5:df:c2:5a:d6:cb:a3:78:a2:1a:6d:a6: > > e1:b4:81:ea:22:e7:83:bb:1f:0d:70:f8:44:29:24:96: > > f3:f0:01:12:49:7a:59:b8:f7:1a:84:e4:e4:a4:0d:60: > > 58:db:d9:9c:b4:51:7a:21:f2:a2:f9:ed:ee:92:6f:c0: > > 00:39:dc:26:9f:c5:0b:e3:e1:72:62:5d:9f:8e:4a:79: > > f3:95:56:a0:37:63:9a:d1:53:af:74:0b:c9:88:b7:43: > > ff:11:cb:91:02:4a:5c:8c:35:41:cb:39:4e:fb:8c:a4: > > 2d:a6:88:7b:dc:29:04:7a:f0:0a:89:25:24:76:b1:34: > > 57:1e:c2:3f:48:79:21:47:f0:f1:1a:70:15:d8:b5:9b: > > cb:bc:a2:3c:42:f6:da:91:a7:24:5b:fa:08:ec:41:8b: > > c5:82:7c:81:76:3c:ef:84:58:93:cd:92:36:5d:96:55: > > 40:72:21:5e:14:7c:fe:78:cf:35:69:97:4a:49:35:81 > Exponent: 65537 (0x10001) > Signed Extensions: > Name: Microsoft Enrollment > Cert Type > Extension > Data: "CA" > > Name: Certificate Key Usage > Critical: True > Usages: Digital Signature > Certificate Signing > CRL Signing > > Name: Certificate Basic > Constraints > Critical: True > Data: Is a CA with no maximum path > length. > > Name: Certificate Subject Key ID > Data: > > a9:7a:6e:7c:dd:dd:4f:9e:75:78:86:6a:ff:f1:b4:06: > e6:fb:3a:6d > > Name: Microsoft CertServ CA > version > Data: 0 (0x0) > > Signature Algorithm: PKCS #1 SHA-1 > With RSA > Encryption > Signature: > > 02:50:bd:c6:3a:80:85:9d:46:16:94:8c:e2:e8:2f:0d: > > 35:09:d7:af:e1:ce:c0:23:94:19:ef:a7:df:de:56:17: > > c8:9e:d5:a0:80:7e:31:46:1d:c0:c1:5a:e9:7d:fe:c3: > > bb:08:c0:6d:35:3a:f2:43:c2:b7:2f:44:2b:89:7f:f1: > > ad:e8:9e:51:fa:98:12:d9:2b:2d:08:00:80:c3:78:93: > > e7:bc:ee:17:ae:a3:07:81:6b:63:ac:bf:65:d5:e9:a8: > > e9:81:42:56:24:fc:2f:b8:d1:76:5b:72:c0:8f:62:66: > > cc:4d:5b:84:85:fb:63:06:6c:0a:54:a0:55:08:bf:11: > > 4b:30:ab:ba:49:19:39:ee:4f:57:3c:7b:0b:d3:8d:fe: > > 10:d8:18:63:ee:86:e9:cb:89:1e:ea:7e:0a:68:8c:f8: > > da:40:69:ca:2c:bc:5d:24:18:bc:2b:d7:ce:08:ca:d7: > > e8:aa:4b:d8:cb:ee:17:f3:4f:18:29:fc:48:59:ae:98: > > 18:37:f0:a7:cd:42:1f:5d:79:cd:a1:0f:30:41:7f:97: > > 81:43:68:8b:74:0c:d8:21:b6:eb:76:14:bf:44:14:13: > > dd:07:ee:ce:68:95:29:b1:14:f6:93:81:90:b5:e6:6a: > > 2b:38:6a:f0:4c:20:3f:fc:88:84:3f:43:5e:5f:6e:ed > Fingerprint (MD5): > > 4B:AE:EB:7D:D0:B6:C8:D3:15:1B:08:ED:39:A0:68:6C > Fingerprint (SHA1): > > 84:17:7E:EE:93:B2:A3:4F:D9:7B:72:C6:ED:D6:61:9E:0E:82:51:BC > > Certificate Trust Flags: > SSL Flags: > Valid CA > Trusted CA > Trusted Client CA > Email Flags: > Object Signing Flags: > Valid CA > Trusted CA > > This looks ok. So is it possible the AD > server cert > was not > issued by this CA? I suppose you could use > an SSL > test program > like /usr/bin/ssltap > or openssl s_client like this: > openssl s_client -connect windows.test.ad:636 > > > > -CAfile > /path/to/msadcacert.asc > > You can also add -verify 3 and -showcerts and > -debug > see "man s_client" for more information > > > > > On Tue, Aug 17, 2010 at 7:04 PM, Shan > Kumaraswamy > > > > >> > > > > >>> > > > > > >> > > > > >>>>> > wrote: > > done, and it came the output also, can > plz let me > know the > next step. > > > On Tue, Aug 17, 2010 at 7:00 PM, Rich > Megginson > > > > >> > > > > >>> > > > > > >> > > > > >>>>> wrote: > > Shan Kumaraswamy wrote: > > Rich, > Please find the below out put > of the > command: > [root at saprhds001 ~]# certutil -d > /etc/dirsrv/slapd-XXXX-COM -L > Certificate Nickname > > Trust Attributes > > > SSL,S/MIME,JAR/XPI > Imported CA > > CT,,C > CA certificate > > CTu,u,Cu > > The CT means the CA is trusted for SSL client and > server certs. > certutil -H > ... > trustargs is of the form x,y,z > where x is > for SSL, y is for S/MIME, > ... > c valid CA > T trusted CA to issue > client certs > (implies c) > C trusted CA to issue > server certs > (implies c) > > Server-Cert > > u,u,u > > I'm assuming "Imported CA" is the > MS AD > CA. Do > this: > certutil -d > /etc/dirsrv/slapd-XXXX-COM -L -n > "Imported CA" > > > > On Tue, Aug 17, 2010 at 6:35 > PM, Rich > Megginson > > > > > >> > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > > >>>>>> > wrote: > > Shan Kumaraswamy wrote: > > After this error, I have > triyed your the > following > steps: > > /usr/lib64/mozldap/ldapsearch -h > windows.test.ad > > > > > > > > > > > > > -D > > "CN=administrator,CN=users,DC=test,DC=ad" -w > "xxxx" > -s base -b > "" "objectclass=*" > > Then I got output like > this: > version: 1 > dn: > currentTime: > 20100817220245.0Z > subschemaSubentry: > > CN=Aggregate,CN=Schema,CN=Configuration,DC=test,DC=ad > dsServiceName: CN=NTDS > > Settings,CN=WINDOWS,CN=Servers,CN=Default-First-Site-Na > > me,CN=Sites,CN=Configuration,DC=test,DC=ad > namingContexts: > DC=test,DC=ad > namingContexts: > CN=Configuration,DC=test,DC=ad > namingContexts: > > CN=Schema,CN=Configuration,DC=test,DC=ad > namingContexts: > DC=DomainDnsZones,DC=test,DC=ad > namingContexts: > DC=ForestDnsZones,DC=test,DC=ad > defaultNamingContext: > DC=test,DC=ad > schemaNamingContext: > > CN=Schema,CN=Configuration,DC=test,DC=ad > configurationNamingContext: > CN=Configuration,DC=test,DC=ad > rootDomainNamingContext: > DC=test,DC=ad > supportedControl: > 1.2.840.113556.1.4.319 > supportedControl: > 1.2.840.113556.1.4.801 > supportedControl: > 1.2.840.113556.1.4.473 > supportedControl: > 1.2.840.113556.1.4.528 > supportedControl: > 1.2.840.113556.1.4.417 > supportedControl: > 1.2.840.113556.1.4.619 > supportedControl: > 1.2.840.113556.1.4.841 > supportedControl: > 1.2.840.113556.1.4.529 > supportedControl: > 1.2.840.113556.1.4.805 > supportedControl: > 1.2.840.113556.1.4.521 > supportedControl: > 1.2.840.113556.1.4.970 > supportedControl: > 1.2.840.113556.1.4.1338 > supportedControl: > 1.2.840.113556.1.4.474 > supportedControl: > 1.2.840.113556.1.4.1339 > supportedControl: > 1.2.840.113556.1.4.1340 > supportedControl: > 1.2.840.113556.1.4.1413 > supportedControl: > 2.16.840.1.113730.3.4.9 > supportedControl: > 2.16.840.1.113730.3.4.10 > supportedControl: > 1.2.840.113556.1.4.1504 > supportedControl: > 1.2.840.113556.1.4.1852 > supportedControl: > 1.2.840.113556.1.4.802 > supportedControl: > 1.2.840.113556.1.4.1907 > supportedControl: > 1.2.840.113556.1.4.1948 > supportedControl: > 1.2.840.113556.1.4.1974 > supportedControl: > 1.2.840.113556.1.4.1341 > supportedControl: > 1.2.840.113556.1.4.2026 > supportedControl: > 1.2.840.113556.1.4.2064 > supportedControl: > 1.2.840.113556.1.4.2065 > supportedLDAPVersion: 3 > supportedLDAPVersion: 2 > supportedLDAPPolicies: > MaxPoolThreads > supportedLDAPPolicies: > MaxDatagramRecv > supportedLDAPPolicies: > MaxReceiveBuffer > supportedLDAPPolicies: > InitRecvTimeout > supportedLDAPPolicies: > MaxConnections > supportedLDAPPolicies: > MaxConnIdleTime > supportedLDAPPolicies: > MaxPageSize > supportedLDAPPolicies: > MaxQueryDuration > supportedLDAPPolicies: > MaxTempTableSize > supportedLDAPPolicies: > MaxResultSetSize > supportedLDAPPolicies: > MinResultSets > supportedLDAPPolicies: > MaxResultSetsPerConn > supportedLDAPPolicies: > MaxNotificationPerConn > supportedLDAPPolicies: > MaxValRange > highestCommittedUSN: 73772 > > supportedSASLMechanisms: GSSAPI > supportedSASLMechanisms: > GSS-SPNEGO > > supportedSASLMechanisms: EXTERNAL > supportedSASLMechanisms: > DIGEST-MD5 > dnsHostName: > Windows.test.ad > > > > > > > > > > > > > > ldapServiceName: > test.ad:windows$@TEST.AD > > > > > > > > > > > > > > serverName: > > > CN=WINDOWS,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Confi > guration,DC=test,DC=ad > supportedCapabilities: > 1.2.840.113556.1.4.800 > supportedCapabilities: > 1.2.840.113556.1.4.1670 > supportedCapabilities: > 1.2.840.113556.1.4.1791 > supportedCapabilities: > 1.2.840.113556.1.4.1935 > supportedCapabilities: > 1.2.840.113556.1.4.2080 > isSynchronized: TRUE > isGlobalCatalogReady: TRUE > domainFunctionality: 4 > forestFunctionality: 4 > > domainControllerFunctionality: 4 > > Then I tried next step: > > /usr/lib64/mozldap/ldapsearch > -ZZ -P > > /etc/dirsrv/slapd-XXXX-COM/cert8.db -h > windows.test.ad > > > > > > > > > > > > > -D > > "CN=administrator,CN=users,DC=test,DC=ad" -w > "xxxxx" -s base > -b "" "objectclass=*" > > ldap_simple_bind: Can't > contact LDAP > server > TLS/SSL error > -8179 (Peer's > Certificate > issuer is not > recognized.) > Please help me to fix > this..... > > This usually means the SSL > server's CA > cert is not > recognized. > What does this say: > certutil -d > /etc/dirsrv/slapd-XXXX-COM -L > ? > > > On Tue, Aug 17, 2010 > at 2:02 > PM, Shan > Kumaraswamy > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>>>> > > wrote: > > Hi Rich, > After I did all the > steps, I am > getting > this error: > > INFO:root:Added CA > certificate > > /etc/dirsrv/slapd-XXXX-COM/adcert.cer to > certificate > database for > tesipa001.test.com > > > > > > > > > > INFO:root:Restarted > directory server > tesipa001.test.com > > > > > > > > > > > INFO:root:Could not > validate > connection to > remote server > windows.test.ad:636 > > > > > > > > - > continuing > > INFO:root:The error was: > {'info': > 'error:14090086:SSL > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify > failed', > 'desc': "Can't > contact LDAP > server"} > The user for the Windows > PassSync > service is > > uid=passsync,cn=sysaccounts,cn=etc,dc=bmibank,dc=com > Windows PassSync entry > exists, not > resetting > password > INFO:root:Added new sync > agreement, > waiting for > it to > become ready > . . . > > INFO:root:Replication Update in > progress: > FALSE: > status: 81 - > LDAP error: Can't > contact > LDAP server: > start: 0: > end: 0 > INFO:root:Agreement is > ready, starting > replication . . . > Starting replication, > please wait > until > this has > completed. > > [saprhds001.bmibank.com > > > > > > > ] > reports: > > Update failed! > Status: [81 > - LDAP > error: > Can't > contact > LDAP server] > INFO:root:Added > agreement for > other host > windows.test.ad > > > > > > > > > > Please help me to > fix this > issue. > The syntex I used: > ipa-replica-manage add > --winsync > --binddn > > CN=Administrator,CN=Users,DC=test,DC=com > --bindpw "password" > --cacert > /etc/dirsrv/slapd-TEST-COM/adcert.cer > windows.test.ad > > > > > > > -v > --passsync > "password" > > On > Mon, Aug 16, > 2010 at > 6:06 PM, > Rich Megginson > > > > >> > > > > >>> > > > > >> > > > > > >>>> > > > >> > > > > >>> > > > > >> > > > > >>>>> > > > > > >> > > > > >>> > > > > >> > > > > > >>>> > > > >> > > > > >>> > > > > >> > > > > > >>>>>>> wrote: > > Shan Kumaraswamy > wrote: > > Rich, > While > installing > IPA its > creates its > won CA cert > right? > (cacert.p12), > > Right. > > and also I > done the > setep of > export this > CA file as > dsca.crt. > > Right. You have > to do > that so > that > AD can > be an SSL > client to > the IPA SSL server. > > Please let > me know > steps to > generate the > IPA CA and > server > cert? > > The other part > is that > you have to > install > the AD CA > cert in > IPA so that IPA > can be > the SSL > client > to the > AD SSL server. > > > On > Mon, Aug > 16, 2010 > at 5:41 PM, Rich Megginson > > > > > >> > > > > >>> > > > > >> > > > > > >>>> > > > >> > > > > >>> > > > > >> > > > > >>>>> > > > > > >> > > > > >>> > > > > >> > > > > > >>>> > > > >> > > > > >>> > > > > >> > > > > > >>>>>> > > > > > >> > > > > >>> > > > > >> > > > > >>>> > > > > > >> > > > > >>> > > > > >> > > > > > >>>>> > > > >> > > > > >>> > > > > >> > > > > >>>> > > > > > >> > > > > >>> > > > > >> > > > > > >>>>>>>> > > wrote: > > Shan > Kumaraswamy > wrote: > > > Hi, > > I have > deployed FreeIPA > 1.2.1 in > RHEL 5.5 and I > want to sync > with > Active > Directory (windows > 2008 R2). Can > please > anyone > have > step-by-step > configuration > doc and > share to me? > > Previously I > have > done the > same > exercise, > but now > that is not > > working for > me and I am > facing lot of > challenges to > make this > happen. > > > Please find the > steps what > exactly I done so > for: > > 1. > Installed RHDS > 8.1 and > FreeIPA > 1.2.1 and > configured > > properly and > tested its > working fine > > 2. > In AD > side, installed > Active Directory > certificate > > Server as a > Enterprise Root > > 3. > Copy the > ?cacert.p12? > file and > imported under > > Certificates > ?Service (Active > Directory Domain > service) on > Local > Computer > using MMC. > > 4. > Installed > PasSync.msi > file and > given all > the required > > information > > 5. > Run the > command > ?certutil -d . -L > -n "CA > certificate" > -a > > dsca.crt? from > IPA server > and copied > the .crt > file in to > AD server > and ran > this command > from ?cd > "C:\Program > Files\Red > Hat > Directory Password > Synchronization" > > 6. > certutil.exe -d . -N > > 7. > certutil.exe -d . > -A -n > "DS CA cert" -t > CT,, -a -i > > \path\to\dsca.crt > > 8. > certutil.exe -d . > -L -n > "DS CA > cert" and > rebooted the > AD > server. > > After > this > steps, > when try to > create sync > agreement > from IPA > > server I am > getting > this > error: > > > ldap_simple_bind: > Can't > contact > LDAP server > > > SSL error > -8179 (Peer's > Certificate > issuer > is not > > recognized.) > > > Please share the > steps to > configure AD Sync with > IPA server. > > > > http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Windows_Sync-Configuring_Windows_Sync.html > > But it > looks as > though > there is a > step missing. > If you > use MS AD > CA to > generate > the AD cert, > and use > IPA to > generate the > IPA CA and > server cert, > then you > have to > import > the MS AD > CA cert > into IPA. > > > > -- > Thanks & Regards > Shan > Kumaraswamy > > > > > > -- > Thanks & > Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From rmeggins at redhat.com Tue Aug 24 14:16:47 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 24 Aug 2010 08:16:47 -0600 Subject: [Freeipa-users] IPA+AD sync error In-Reply-To: References: <4C6953E6.4030500@redhat.com> <4C6AAC48.1050006@redhat.com> <4C6AB20E.5000305@redhat.com> <4C6AB852.1060608@redhat.com> <4C6BE3AF.4010205@redhat.com> <4C6BE980.40302@redhat.com> <4C6BEDF3.4020106@redhat.com> <4C6C0FFF.50301@redhat.com> Message-ID: <4C73D44F.4090202@redhat.com> Shan Kumaraswamy wrote: > > Hi Rich, > > After export and import CA cert at both AD and IPA box, finally I am > getting this error while creating "winsync" agreement: > > > [root at saprhds001 ~]# ipa-replica-manage add --winsync --binddn > "CN=Administrator,CN=Users,DC=test,DC=ad" --bindpw "xxx" --cacert > /etc/dirsrv/slapd-XXXX-COM/adca.cer windows.test.ad > -v --passsync "xxxxx" > Directory Manager password: > INFO:root:Shutting down dirsrv: > BMIBANK-COM... [ OK ] > INFO:root: > INFO:root: > INFO:root: > INFO:root:Starting dirsrv: > BMIBANK-COM... [ OK ] > INFO:root: > INFO:root:Added CA certificate /etc/dirsrv/slapd-XXXXX-COM/adca.cer to > certificate database for saprhds001.xxxx.com > INFO:root:Restarted directory server saprhds001.xxxx.com > > INFO:root:Could not validate connection to remote server > windows.test.ad:636 - continuing > INFO:root:The error was: A database error occurred > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=xxxx,dc=com > Windows PassSync entry exists, not resetting password > INFO:root:Added new sync agreement, waiting for it to become ready . . . > INFO:root:Replication Update in progress: FALSE: status: 0 Incremental > update started: start: 20100824120022Z: end: 20100824120022Z > INFO:root:Agreement is ready, starting replication . . . > Starting replication, please wait until this has completed. > Update succeeded > INFO:root:Added agreement for other host windows.test.ad > > > > Please advice to fix this issue. What issue? The problem about "Could not validate connection" is normal - just ignore that. > > > > > > On Wed, Aug 18, 2010 at 7:53 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > Rich, > When I try to open redhat-idm-console using directory server, > I am getting this error: > The certificate this server present is either untrusted or > unkown. The server only communicate through a secure > connection involving a certivicate. Do you wihs to accept this > certificate anyway? > As per this message even I say yes to proceed, but fail to > open. Please advice. > > The use of the console is not supported with IPA. > > The console keeps its cert database in ~/.redhat-idm-console - > unless you have previously installed the CA cert there, the > console will prompt you if you want to trust the server. > > I'm not sure why the console will not open, except that the > console does not generally work with IPA. You can use > redhat-idm-console -D 9 -f console.log to get detailed trace > information from the console. > > > On Wed, Aug 18, 2010 at 5:28 PM, Rich Megginson > > >> wrote: > > Shan Kumaraswamy wrote: > > Sorry, I was deleted the copyied cert file.... :( > > If you want to get the CA cert out of the certdb and into > ascii/pem format: > certutil -d /etc/dirsrv/slapd-instancename -L -n "Imported > CA" -a > > msadca.crt > > If you want to get the CA cert directly from MS CA: > on your AD box, open a web browser > go to http:///certsrv > There should be an option there to view or download the CA > cert. > You want to download it in ascii/pem/base64 format (I think > Windows uses the term Base64 encoded cert for PEM). Then > you'll > have to copy that file to your IPA box. > > > > On Wed, Aug 18, 2010 at 5:09 PM, Rich Megginson > > > > >>> wrote: > > Shan Kumaraswamy wrote: > > Ok sure, I will do the test and can please let > me know > command > to import AD CA in to dirsrv cert db? > > It is already in there? This is the certificate called > "Imported > CA" with Subject: "CN=test-WINDOWS-CA,DC=test,DC=ad" and > Issuer: > "CN=test-WINDOWS-CA,DC=test,DC=ad" > > Or are you asking because you don't know how it got > in there in > the first place, or forgot? > > On Wed, Aug 18, 2010 at 4:44 PM, > Rich Megginson > > > >> > > > > >>>> wrote: > > Shan Kumaraswamy wrote: > > Rich, > Can I know command to trust IPA genearated CA > cert file? > > See below > > So I don't think that is the problem here. > If that > were the > problem, I would expect a different error > message. > I think > you're > just going to have to use something like openssl > s_client to > examine the server cert used by AD. > > On Tue, Aug 17, 2010 at > 7:26 PM, > Rich Megginson > > > > >> > > > > >>> > > > > > >> > > > > >>>>> wrote: > > Shan Kumaraswamy wrote: > > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > > 46:90:cd:94:c6:53:d4:ae:44:a6:df:e2:6b:24:15:56 > Signature Algorithm: PKCS > #1 SHA-1 > With RSA > Encryption > Issuer: > "CN=test-WINDOWS-CA,DC=test,DC=ad" > Validity: > Not Before: Tue Aug 17 > 01:39:07 2010 > Not After : Mon Aug 17 > 01:49:05 2015 > Subject: > "CN=test-WINDOWS-CA,DC=test,DC=ad" > Subject Public Key Info: > Public Key Algorithm: > PKCS #1 RSA > Encryption > RSA Public Key: > Modulus: > > a9:6e:1a:54:c2:70:1c:d7:dc:06:b4:d3:09:0f:8d:25: > > e5:8f:9f:1f:f6:f9:ee:fb:9c:6b:9c:84:c3:01:f7:45: > > f1:8e:43:d3:ed:ad:01:e6:92:6c:52:f4:d7:03:03:19: > > 0a:93:84:18:42:92:2b:6b:74:3d:77:8c:31:b9:bf:75: > > 84:cb:a0:8c:a5:df:c2:5a:d6:cb:a3:78:a2:1a:6d:a6: > > e1:b4:81:ea:22:e7:83:bb:1f:0d:70:f8:44:29:24:96: > > f3:f0:01:12:49:7a:59:b8:f7:1a:84:e4:e4:a4:0d:60: > > 58:db:d9:9c:b4:51:7a:21:f2:a2:f9:ed:ee:92:6f:c0: > > 00:39:dc:26:9f:c5:0b:e3:e1:72:62:5d:9f:8e:4a:79: > > f3:95:56:a0:37:63:9a:d1:53:af:74:0b:c9:88:b7:43: > > ff:11:cb:91:02:4a:5c:8c:35:41:cb:39:4e:fb:8c:a4: > > 2d:a6:88:7b:dc:29:04:7a:f0:0a:89:25:24:76:b1:34: > > 57:1e:c2:3f:48:79:21:47:f0:f1:1a:70:15:d8:b5:9b: > > cb:bc:a2:3c:42:f6:da:91:a7:24:5b:fa:08:ec:41:8b: > > c5:82:7c:81:76:3c:ef:84:58:93:cd:92:36:5d:96:55: > > 40:72:21:5e:14:7c:fe:78:cf:35:69:97:4a:49:35:81 > Exponent: 65537 > (0x10001) > Signed Extensions: > Name: Microsoft Enrollment > Cert Type > Extension > Data: "CA" > > Name: Certificate Key Usage > Critical: True > Usages: Digital Signature > Certificate Signing > CRL Signing > > Name: Certificate Basic > Constraints > Critical: True > Data: Is a CA with no > maximum path > length. > > Name: Certificate > Subject Key ID > Data: > > a9:7a:6e:7c:dd:dd:4f:9e:75:78:86:6a:ff:f1:b4:06: > e6:fb:3a:6d > > Name: Microsoft CertServ CA > version > Data: 0 (0x0) > > Signature Algorithm: PKCS #1 SHA-1 > With RSA > Encryption > Signature: > > 02:50:bd:c6:3a:80:85:9d:46:16:94:8c:e2:e8:2f:0d: > > 35:09:d7:af:e1:ce:c0:23:94:19:ef:a7:df:de:56:17: > > c8:9e:d5:a0:80:7e:31:46:1d:c0:c1:5a:e9:7d:fe:c3: > > bb:08:c0:6d:35:3a:f2:43:c2:b7:2f:44:2b:89:7f:f1: > > ad:e8:9e:51:fa:98:12:d9:2b:2d:08:00:80:c3:78:93: > > e7:bc:ee:17:ae:a3:07:81:6b:63:ac:bf:65:d5:e9:a8: > > e9:81:42:56:24:fc:2f:b8:d1:76:5b:72:c0:8f:62:66: > > cc:4d:5b:84:85:fb:63:06:6c:0a:54:a0:55:08:bf:11: > > 4b:30:ab:ba:49:19:39:ee:4f:57:3c:7b:0b:d3:8d:fe: > > 10:d8:18:63:ee:86:e9:cb:89:1e:ea:7e:0a:68:8c:f8: > > da:40:69:ca:2c:bc:5d:24:18:bc:2b:d7:ce:08:ca:d7: > > e8:aa:4b:d8:cb:ee:17:f3:4f:18:29:fc:48:59:ae:98: > > 18:37:f0:a7:cd:42:1f:5d:79:cd:a1:0f:30:41:7f:97: > > 81:43:68:8b:74:0c:d8:21:b6:eb:76:14:bf:44:14:13: > > dd:07:ee:ce:68:95:29:b1:14:f6:93:81:90:b5:e6:6a: > > 2b:38:6a:f0:4c:20:3f:fc:88:84:3f:43:5e:5f:6e:ed > Fingerprint (MD5): > > 4B:AE:EB:7D:D0:B6:C8:D3:15:1B:08:ED:39:A0:68:6C > Fingerprint (SHA1): > > 84:17:7E:EE:93:B2:A3:4F:D9:7B:72:C6:ED:D6:61:9E:0E:82:51:BC > > Certificate Trust Flags: > SSL Flags: > Valid CA > Trusted CA > Trusted Client CA > Email Flags: > Object Signing Flags: > Valid CA > Trusted CA > > This looks ok. So is it possible the AD > server cert > was not > issued by this CA? I suppose you > could use > an SSL > test program > like /usr/bin/ssltap > or openssl s_client like this: > openssl s_client -connect > windows.test.ad:636 > > > > -CAfile > /path/to/msadcacert.asc > > You can also add -verify 3 and > -showcerts and > -debug > see "man s_client" for more information > > > > > On Tue, Aug 17, 2010 at 7:04 PM, Shan > Kumaraswamy > > > > > >> > > > > >>> > > > > > >> > > > > >>>> > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>>> > wrote: > > done, and it came the output > also, can > plz let me > know the > next step. > > > On Tue, Aug 17, 2010 at 7:00 > PM, Rich > Megginson > > > > > >> > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > > >>>>>> wrote: > > Shan Kumaraswamy wrote: > > Rich, > Please find the below > out put > of the > command: > [root at saprhds001 ~]# > certutil -d > > /etc/dirsrv/slapd-XXXX-COM -L > Certificate Nickname > > Trust Attributes > > > SSL,S/MIME,JAR/XPI > Imported CA > > CT,,C > CA certificate > > CTu,u,Cu > > The CT means the CA is trusted for SSL client and > server certs. > certutil -H > ... > trustargs is of the > form x,y,z > where x is > for SSL, y is for S/MIME, > ... > c valid CA > T trusted CA to > issue > client certs > (implies c) > C trusted CA to > issue > server certs > (implies c) > > Server-Cert > > u,u,u > > I'm assuming "Imported CA" > is the > MS AD > CA. Do > this: > certutil -d > /etc/dirsrv/slapd-XXXX-COM -L -n > "Imported CA" > > > > On Tue, Aug 17, 2010 at > 6:35 > PM, Rich > Megginson > > > > >> > > > > > >>> > > > >> > > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > >>>>> > > > > > >> > > > > >>> > > > > >> > > > > > >>>> > > > >> > > > > >>> > > > > >> > > > > > >>>>>>> > wrote: > > Shan Kumaraswamy wrote: > > After this > error, I have > triyed your the > following > steps: > > /usr/lib64/mozldap/ldapsearch -h > windows.test.ad > > > > > > > > > > > > > > > > -D > > "CN=administrator,CN=users,DC=test,DC=ad" -w > "xxxx" > -s base -b > "" "objectclass=*" > > Then I got > output like > this: > version: 1 > dn: > currentTime: > 20100817220245.0Z > subschemaSubentry: > > CN=Aggregate,CN=Schema,CN=Configuration,DC=test,DC=ad > dsServiceName: > CN=NTDS > > > Settings,CN=WINDOWS,CN=Servers,CN=Default-First-Site-Na > > me,CN=Sites,CN=Configuration,DC=test,DC=ad > namingContexts: > DC=test,DC=ad > namingContexts: > CN=Configuration,DC=test,DC=ad > namingContexts: > > CN=Schema,CN=Configuration,DC=test,DC=ad > namingContexts: > DC=DomainDnsZones,DC=test,DC=ad > namingContexts: > DC=ForestDnsZones,DC=test,DC=ad > > defaultNamingContext: > DC=test,DC=ad > schemaNamingContext: > > CN=Schema,CN=Configuration,DC=test,DC=ad > > configurationNamingContext: > > CN=Configuration,DC=test,DC=ad > > rootDomainNamingContext: > DC=test,DC=ad > supportedControl: > 1.2.840.113556.1.4.319 > supportedControl: > 1.2.840.113556.1.4.801 > supportedControl: > 1.2.840.113556.1.4.473 > supportedControl: > 1.2.840.113556.1.4.528 > supportedControl: > 1.2.840.113556.1.4.417 > supportedControl: > 1.2.840.113556.1.4.619 > supportedControl: > 1.2.840.113556.1.4.841 > supportedControl: > 1.2.840.113556.1.4.529 > supportedControl: > 1.2.840.113556.1.4.805 > supportedControl: > 1.2.840.113556.1.4.521 > supportedControl: > 1.2.840.113556.1.4.970 > supportedControl: > 1.2.840.113556.1.4.1338 > supportedControl: > 1.2.840.113556.1.4.474 > supportedControl: > 1.2.840.113556.1.4.1339 > supportedControl: > 1.2.840.113556.1.4.1340 > supportedControl: > 1.2.840.113556.1.4.1413 > supportedControl: > 2.16.840.1.113730.3.4.9 > supportedControl: > 2.16.840.1.113730.3.4.10 > supportedControl: > 1.2.840.113556.1.4.1504 > supportedControl: > 1.2.840.113556.1.4.1852 > supportedControl: > 1.2.840.113556.1.4.802 > supportedControl: > 1.2.840.113556.1.4.1907 > supportedControl: > 1.2.840.113556.1.4.1948 > supportedControl: > 1.2.840.113556.1.4.1974 > supportedControl: > 1.2.840.113556.1.4.1341 > supportedControl: > 1.2.840.113556.1.4.2026 > supportedControl: > 1.2.840.113556.1.4.2064 > supportedControl: > 1.2.840.113556.1.4.2065 > > supportedLDAPVersion: 3 > > supportedLDAPVersion: 2 > > supportedLDAPPolicies: > MaxPoolThreads > > supportedLDAPPolicies: > MaxDatagramRecv > > supportedLDAPPolicies: > MaxReceiveBuffer > > supportedLDAPPolicies: > InitRecvTimeout > > supportedLDAPPolicies: > MaxConnections > > supportedLDAPPolicies: > MaxConnIdleTime > > supportedLDAPPolicies: > MaxPageSize > > supportedLDAPPolicies: > MaxQueryDuration > > supportedLDAPPolicies: > MaxTempTableSize > > supportedLDAPPolicies: > MaxResultSetSize > > supportedLDAPPolicies: > MinResultSets > > supportedLDAPPolicies: > MaxResultSetsPerConn > > supportedLDAPPolicies: > MaxNotificationPerConn > > supportedLDAPPolicies: > MaxValRange > > highestCommittedUSN: 73772 > > supportedSASLMechanisms: GSSAPI > > supportedSASLMechanisms: > GSS-SPNEGO > > supportedSASLMechanisms: EXTERNAL > > supportedSASLMechanisms: > DIGEST-MD5 > dnsHostName: > Windows.test.ad > > > > > > > > > > > > > > > > > ldapServiceName: > test.ad:windows$@TEST.AD > > > > > > > > > > > > > > > > serverName: > > > CN=WINDOWS,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Confi > > guration,DC=test,DC=ad > > supportedCapabilities: > 1.2.840.113556.1.4.800 > > supportedCapabilities: > 1.2.840.113556.1.4.1670 > > supportedCapabilities: > 1.2.840.113556.1.4.1791 > > supportedCapabilities: > 1.2.840.113556.1.4.1935 > > supportedCapabilities: > 1.2.840.113556.1.4.2080 > isSynchronized: TRUE > > isGlobalCatalogReady: TRUE > > domainFunctionality: 4 > > forestFunctionality: 4 > > domainControllerFunctionality: 4 > > Then I tried > next step: > > /usr/lib64/mozldap/ldapsearch > -ZZ -P > > /etc/dirsrv/slapd-XXXX-COM/cert8.db -h > windows.test.ad > > > > > > > > > > > > > > > > -D > > "CN=administrator,CN=users,DC=test,DC=ad" -w > "xxxxx" -s base > -b "" > "objectclass=*" > > > ldap_simple_bind: Can't > contact LDAP > server > TLS/SSL error > -8179 (Peer's > Certificate > issuer is not > recognized.) > Please help me > to fix > this..... > > This usually means > the SSL > server's CA > cert is not > recognized. > What does this say: > certutil -d > /etc/dirsrv/slapd-XXXX-COM -L > ? > > > On Tue, Aug 17, > 2010 > at 2:02 > PM, Shan > Kumaraswamy > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>>>>> > > wrote: > > Hi Rich, > After I did > all the > steps, I am > getting > this error: > > INFO:root:Added CA > certificate > > /etc/dirsrv/slapd-XXXX-COM/adcert.cer to > certificate > database for > > tesipa001.test.com > > > > > > > > > > > > INFO:root:Restarted > directory server > tesipa001.test.com > > > > > > > > > > > > > INFO:root:Could not > validate > connection to > remote server > > windows.test.ad:636 > > > > > > > > > - > continuing > > INFO:root:The > error was: > {'info': > 'error:14090086:SSL > > routines:SSL3_GET_SERVER_CERTIFICATE:certificate > verify > failed', > 'desc': "Can't > contact LDAP > server"} > The user for > the Windows > PassSync > service is > > > uid=passsync,cn=sysaccounts,cn=etc,dc=bmibank,dc=com > Windows > PassSync entry > exists, not > resetting > password > > INFO:root:Added new sync > agreement, > waiting for > it to > become ready > . . . > > INFO:root:Replication Update in > progress: > FALSE: > status: 81 - > LDAP error: Can't > contact > LDAP server: > start: 0: > end: 0 > > INFO:root:Agreement is > ready, starting > replication . . . > Starting > replication, > please wait > until > this has > completed. > > [saprhds001.bmibank.com > > > > > > > > > > ] > reports: > > Update failed! > Status: [81 > - LDAP > error: > Can't > contact > LDAP server] > INFO:root:Added > agreement for > other host > windows.test.ad > > > > > > > > > > > > Please help me to > fix this > issue. > The > syntex I used: > ipa-replica-manage add > --winsync > --binddn > > CN=Administrator,CN=Users,DC=test,DC=com > --bindpw "password" > --cacert > /etc/dirsrv/slapd-TEST-COM/adcert.cer > windows.test.ad > > > > > > > > > -v > --passsync > "password" > > > On > Mon, Aug 16, > 2010 at > 6:06 PM, > Rich Megginson > > > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > > >> > > > > >>> > > > > >> > > > > > >>>>> > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > > >> > > > > >>> > > > > > >> > > > > >>>>>> > > > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > > >> > > > > >>> > > > > >> > > > > > >>>>> > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > > >> > > > > >>> > > > > >> > > > > > >>>>>>>> wrote: > > Shan > Kumaraswamy > wrote: > > Rich, > While > installing > IPA its > creates its > won CA cert > right? > > (cacert.p12), > > Right. > > and > also I > done the > setep of > export this > CA file as > dsca.crt. > > Right. > You have > to do > that so > that > AD can > be an SSL > client to > the IPA > SSL server. > > > Please let > me know > steps to > generate the > IPA CA and > server > cert? > > The other > part > is that > you have to > install > the AD CA > cert in > IPA so > that IPA > can be > the SSL > client > to the > AD SSL server. > > > On > Mon, Aug > 16, 2010 > at 5:41 PM, Rich Megginson > > > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > > >> > > > > >>> > > > > >> > > > > > >>>>> > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > > >> > > > > >>> > > > > > >> > > > > >>>>>> > > > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > > >> > > > > >>> > > > > >> > > > > > >>>>> > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > > >> > > > > >>> > > > > >> > > > > > >>>>>>> > > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > > >> > > > > >>> > > > > > >> > > > > >>>>> > > > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > > >> > > > > >>> > > > > >> > > > > > >>>>>> > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > > >> > > > > >>> > > > > > >> > > > > >>>>> > > > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > > >> > > > > >>> > > > > >> > > > > > >>>>>>>>> > > wrote: > > Shan > Kumaraswamy > wrote: > > > > Hi, > > > I have > deployed FreeIPA > 1.2.1 in > RHEL 5.5 and I > want > to sync > > with > Active > Directory (windows > 2008 R2). Can > please > anyone > > have > step-by-step > configuration > doc and > share to me? > > Previously I > have > done the > same > exercise, > but now > that > is not > > working for > me and I am > facing lot of > challenges to > make this > > happen. > > > Please find the > steps what > exactly I done so > for: > > > 1. Installed RHDS > 8.1 and > FreeIPA > 1.2.1 and > > configured > > properly and > tested its > working fine > > > 2. In AD > side, installed > Active Directory > > certificate > > Server as a > Enterprise Root > > > 3. Copy the > ?cacert.p12? > file and > imported under > > Certificates > ?Service (Active > Directory Domain > > service) on > > Local > Computer > using MMC. > > > 4. Installed > PasSync.msi > file and > given all > the > required > > information > > > 5. Run the > command > ?certutil -d . -L > -n "CA > > certificate" > > -a > > dsca.crt? from > IPA server > and copied > the .crt > file > in to > > AD server > and ran > this command > from ?cd > "C:\Program > Files\Red > > Hat > Directory Password > Synchronization" > > > 6. certutil.exe -d . -N > > > 7. certutil.exe -d . > -A -n > "DS CA cert" -t > CT,, > -a -i > > \path\to\dsca.crt > > > 8. certutil.exe -d . > -L -n > "DS CA > cert" and > > rebooted the > AD > server. > > > After > this > steps, > when try to > create sync > agreement > from IPA > > server I am > getting > this > error: > > > ldap_simple_bind: > Can't > contact > LDAP server > > > SSL error > -8179 (Peer's > Certificate > issuer > is not > > recognized.) > > > Please share the > steps to > configure AD Sync with > IPA > server. > > > > > http://www.redhat.com/docs/manuals/dir-server/8.2/admin/html/Windows_Sync-Configuring_Windows_Sync.html > > But it > looks as > though > there is a > step missing. > If you > use MS AD > CA to > generate > the AD cert, > and use > IPA to > generate the > IPA > CA and > > server cert, > then you > have to > import > the MS AD > CA cert > into IPA. > > > > -- > Thanks & Regards > > Shan > Kumaraswamy > > > > > > -- > Thanks & > Regards > Shan > Kumaraswamy > > > > > > -- Thanks > & Regards > Shan Kumaraswamy > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & > Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > > > > > > -- > Thanks & Regards > Shan Kumaraswamy > From rcritten at redhat.com Tue Aug 24 17:09:16 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Aug 2010 13:09:16 -0400 Subject: [Freeipa-users] fine-grained access control feedback Message-ID: <4C73FCBC.4070603@redhat.com> In v2 we are adding more fine-grained access control per the many requests we had in v1. v1 only provided the ability to grant permission to write a fixed set of user attributes from group A to group B. We're looking for feedback on the types of access control that the IPA users require in order to create some use-cases and help us design a workable GUI for managing access control: Things like: - I want to control who can add users - I want to set the list of attributes for self-service - I want hosts to be able to manage the certificates of its services We're particularly interested in the details, such as how you want to differentiate user A from user B when determining who can write what. thanks rob From brian at cukerinteractive.com Tue Aug 24 22:38:44 2010 From: brian at cukerinteractive.com (Brian LaMere) Date: Tue, 24 Aug 2010 15:38:44 -0700 Subject: [Freeipa-users] 389-ds to free-ipa transition; transparent? Message-ID: I have a multimaster 389-ds installation, and am considering migrating to ipa-server. http://freeipa.org/page/IPAv2_alpha2#Migration seems to be pretty clear that I'm out of luck, and that I need to do a completely clean install. Am I reading that correctly? Secondly, is multi-master on ipa as easy as it was for 389-ds? thanks, Brian LaMere -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Aug 25 01:16:48 2010 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Aug 2010 21:16:48 -0400 Subject: [Freeipa-users] 389-ds to free-ipa transition; transparent? In-Reply-To: References: Message-ID: <4C746F00.5090102@redhat.com> Brian LaMere wrote: > I have a multimaster 389-ds installation, and am considering migrating > to ipa-server. > > http://freeipa.org/page/IPAv2_alpha2#Migration seems to be pretty clear > that I'm out of luck, and that I need to do a completely clean install. > Am I reading that correctly? That's right. We have to configure a whole slew of services to work in concert so using an existing install would be extremely difficult at best, even if the DIT was the same. > Secondly, is multi-master on ipa as easy as it was for 389-ds? Yes, if not easier. It is just 389-ds under the hood, we have some simple management tools that create the agreements for you. Since we use our own CA SSL is easy as well. What I would recommend is to set up a test IPA instance to get a feel for how the data is stored, see how migrating users and groups would work, etc. If you want to get really fancy you can add a master or two to the mix. Depending on your configuration the data migration should be relatively straightforward but know that the IPA DIT is completely flat. All users are in one container, groups in another, etc. Once the migration is done there is a simple form to set up user kerberos keys, then you should be off to the races. The basic idea is that you authenticate using your migrated LDAP password and this will automatically generate a kerberos key for the user. regards rob From root at nachtmaus.us Wed Aug 25 03:22:26 2010 From: root at nachtmaus.us (david klein) Date: Tue, 24 Aug 2010 22:22:26 -0500 Subject: [Freeipa-users] Feature request: TACACS+ integration Message-ID: Sorry to those who have already seen this; I posted to the wrong mailing list (the -interest mailing list instead of the -users list). As an NMS engineer, I have a use for integrated TACACS+ with a unified identity solution, so that the same account name and password can grant access for managing network infrastructure devices as well as UNIX and Linux servers, and so that network rights can be assigned and delegated through the same GUI as systems rights. There is an open source TACACS+ service called "tac_plus", which used to be maintained by Cisco, and which is now maintained by Shrubbery Networks, Inc (http://www.shrubbery.net/tac_plus/). It appears that under Shrubbery's guidance and development, the tac_plus daemon can use LDAP by way of PAM to handle authentication, according to http://www.shrubbery.net/tac_plus/PAM_guide.txt. At this point, only authentication appears to have been externalized, but it does prove the concept. How does Redhat currently measure the degree of interest in possible features for inclusion in the FreeIPA/EnterpriseIPA product, and would it be worthwhile to gather statements from other systems administrators to help demonstrate the desirability and usefulness of this feature request? This would be a very helpful capability, as it would remove dependence on ACS, which is expensive and complex (and complicated) TACACS+ server. Thank you, -DTK -- david t. klein Cisco Certified Network Associate (CSCO11281885) Linux Professional Institute Certification (LPI000165615) Redhat Certified Engineer (805009745938860) Quis custodiet ipsos custodes? From jdennis at redhat.com Wed Aug 25 11:50:46 2010 From: jdennis at redhat.com (John Dennis) Date: Wed, 25 Aug 2010 07:50:46 -0400 Subject: [Freeipa-users] Feature request: TACACS+ integration In-Reply-To: References: Message-ID: <4C750396.7020604@redhat.com> On 08/24/2010 11:22 PM, david klein wrote: > Sorry to those who have already seen this; I posted to the wrong > mailing list (the -interest mailing list instead of the -users list). > > As an NMS engineer, I have a use for integrated TACACS+ with a unified > identity solution, so that the same account name and password can > grant access for managing network infrastructure devices as well as > UNIX and Linux servers, and so that network rights can be assigned and > delegated through the same GUI as systems rights. > > There is an open source TACACS+ service called "tac_plus", which used > to be maintained by Cisco, and which is now maintained by Shrubbery > Networks, Inc (http://www.shrubbery.net/tac_plus/). It appears that > under Shrubbery's guidance and development, the tac_plus daemon can > use LDAP by way of PAM to handle authentication, according to > http://www.shrubbery.net/tac_plus/PAM_guide.txt. At this point, only > authentication appears to have been externalized, but it does prove > the concept. > > How does Redhat currently measure the degree of interest in possible > features for inclusion in the FreeIPA/EnterpriseIPA product, and would > it be worthwhile to gather statements from other systems > administrators to help demonstrate the desirability and usefulness of > this feature request? This would be a very helpful capability, as it > would remove dependence on ACS, which is expensive and complex (and > complicated) TACACS+ server. This is the first request I've seen for TACAS support. Since IPA is a unified identity solution at it's core it's not clear to me at the moment what advantage there would be to TACAS other than as emulating a TACAS server for legacy and/or 3rd party products which depend on the TACAS protocol. If one wants to set up a TACAS daemon there is a reasonable chance it could validate against IPA (more investigation would be needed) and this would give you something which provide TACAS protocol but be backed by IPA and it's management tools. We do have plans on our roadmap to support RADIUS which is often used as an alternative to TACAS. But perhaps I haven't fully understood your request. So let me rephrase it and see if I have it correct. You want something on your network which speaks the TACAS+ protocol but whose identity management is backed by our IPA server. Is that correct? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From root at nachtmaus.us Wed Aug 25 12:21:22 2010 From: root at nachtmaus.us (david klein) Date: Wed, 25 Aug 2010 07:21:22 -0500 Subject: [Freeipa-users] Feature request: TACACS+ integration In-Reply-To: <4C750396.7020604@redhat.com> References: <4C750396.7020604@redhat.com> Message-ID: On Wed, Aug 25, 2010 at 6:50 AM, John Dennis wrote: > On 08/24/2010 11:22 PM, david klein wrote: >> >> Sorry to those who have already seen this; I posted to the wrong >> mailing list (the -interest mailing list instead of the -users list). >> >> As an NMS engineer, I have a use for integrated TACACS+ with a unified >> identity solution, so that the same account name and password can >> grant access for managing network infrastructure devices as well as >> UNIX and Linux servers, and so that network rights can be assigned and >> delegated through the same GUI as systems rights. >> >> There is an open source TACACS+ service called "tac_plus", which used >> to be maintained by Cisco, and which is now maintained by Shrubbery >> Networks, Inc (http://www.shrubbery.net/tac_plus/). It appears that >> under Shrubbery's guidance and development, the tac_plus daemon can >> use LDAP by way of PAM to handle authentication, according to >> http://www.shrubbery.net/tac_plus/PAM_guide.txt. At this point, only >> authentication appears to have been externalized, but it does prove >> the concept. >> >> How does Redhat currently measure the degree of interest in possible >> features for inclusion in the FreeIPA/EnterpriseIPA product, and would >> it be worthwhile to gather statements from other systems >> administrators to help demonstrate the desirability and usefulness of >> this feature request? This would be a very helpful capability, as it >> would remove dependence on ACS, which is expensive and complex (and >> complicated) TACACS+ server. > > This is the first request I've seen for TACAS support. Since IPA is a > unified identity solution at it's core it's not clear to me at the moment > what advantage there would be to TACAS other than as emulating a TACAS > server for legacy and/or 3rd party products which depend on the TACAS > protocol. If one wants to set up a TACAS daemon there is a reasonable chance > it could validate against IPA (more investigation would be needed) and this > would give you something which provide TACAS protocol but be backed by IPA > and it's management tools. > > We do have plans on our roadmap to support RADIUS which is often used as an > alternative to TACAS. > > But perhaps I haven't fully understood your request. So let me rephrase it > and see if I have it correct. You want something on your network which > speaks the TACAS+ protocol but whose identity management is backed by our > IPA server. Is that correct? > > -- > John Dennis > > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > >From both a network and a security point of view, TACACS+ is considered preferable to RADIUS; among other benefits, it enciphers the entire conversation, rather than just portions of it, and can provide more fine-grain authorization than RADIUS. Most Cisco shops I've encountered consider RADIUS to be an unacceptable solution for AAA. Cisco considers use of TACACS+ a best practice for AAA. What I am looking for is a device on the network which provides AAA facilities to network infrastructure devices, and which allows provisioning of network infrastructure credentials through the same interface and at the same time as systems credentials, and which keeps those credentials synchronized. -- david t. klein Cisco Certified Network Associate (CSCO11281885) Linux Professional Institute Certification (LPI000165615) Redhat Certified Engineer (805009745938860) Quis custodiet ipsos custodes? From jdennis at redhat.com Wed Aug 25 12:58:29 2010 From: jdennis at redhat.com (John Dennis) Date: Wed, 25 Aug 2010 08:58:29 -0400 Subject: [Freeipa-users] Feature request: TACACS+ integration In-Reply-To: References: <4C750396.7020604@redhat.com> Message-ID: <4C751375.3040608@redhat.com> On 08/25/2010 08:21 AM, david klein wrote: > On Wed, Aug 25, 2010 at 6:50 AM, John Dennis wrote: >> On 08/24/2010 11:22 PM, david klein wrote: >>> >>> Sorry to those who have already seen this; I posted to the wrong >>> mailing list (the -interest mailing list instead of the -users list). >>> >>> As an NMS engineer, I have a use for integrated TACACS+ with a unified >>> identity solution, so that the same account name and password can >>> grant access for managing network infrastructure devices as well as >>> UNIX and Linux servers, and so that network rights can be assigned and >>> delegated through the same GUI as systems rights. >>> >>> There is an open source TACACS+ service called "tac_plus", which used >>> to be maintained by Cisco, and which is now maintained by Shrubbery >>> Networks, Inc (http://www.shrubbery.net/tac_plus/). It appears that >>> under Shrubbery's guidance and development, the tac_plus daemon can >>> use LDAP by way of PAM to handle authentication, according to >>> http://www.shrubbery.net/tac_plus/PAM_guide.txt. At this point, only >>> authentication appears to have been externalized, but it does prove >>> the concept. >>> >>> How does Redhat currently measure the degree of interest in possible >>> features for inclusion in the FreeIPA/EnterpriseIPA product, and would >>> it be worthwhile to gather statements from other systems >>> administrators to help demonstrate the desirability and usefulness of >>> this feature request? This would be a very helpful capability, as it >>> would remove dependence on ACS, which is expensive and complex (and >>> complicated) TACACS+ server. >> >> This is the first request I've seen for TACAS support. Since IPA is a >> unified identity solution at it's core it's not clear to me at the moment >> what advantage there would be to TACAS other than as emulating a TACAS >> server for legacy and/or 3rd party products which depend on the TACAS >> protocol. If one wants to set up a TACAS daemon there is a reasonable chance >> it could validate against IPA (more investigation would be needed) and this >> would give you something which provide TACAS protocol but be backed by IPA >> and it's management tools. >> >> We do have plans on our roadmap to support RADIUS which is often used as an >> alternative to TACAS. >> >> But perhaps I haven't fully understood your request. So let me rephrase it >> and see if I have it correct. You want something on your network which >> speaks the TACAS+ protocol but whose identity management is backed by our >> IPA server. Is that correct? >> >> -- >> John Dennis >> >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> > > From both a network and a security point of view, TACACS+ is > considered preferable to RADIUS; among other benefits, it enciphers > the entire conversation, rather than just portions of it, and can > provide more fine-grain authorization than RADIUS. Most Cisco shops > I've encountered consider RADIUS to be an unacceptable solution for > AAA. Cisco considers use of TACACS+ a best practice for AAA. > > What I am looking for is a device on the network which provides AAA > facilities to network infrastructure devices, and which allows > provisioning of network infrastructure credentials through the same > interface and at the same time as systems credentials, and which keeps > those credentials synchronized. > O.K. fair enough. However TACACS is not on our roadmap. If you can demonstrate strong need by enterprise customers for TACACS it would be taken into consideration for a future version of the product. The more practical solution which may be available to you would be to avail yourself of the PAM integration in the tac_plus project (but to be honest I don't see how that would give you any of the sophisticated features you cite as being a prime motivator for utilization of TACACS). FreeIPA is an open source project and from what you say so is tac_plus. I would imagine patches would be welcomed by both projects which would allow the tac_plus daemon to utilize IPA as it's back end. We would be happy to answer any questions for the person(s) who wanted to undertake this and contribute their work. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From james.roman at ssaihq.com Wed Aug 25 15:22:22 2010 From: james.roman at ssaihq.com (James Roman) Date: Wed, 25 Aug 2010 11:22:22 -0400 Subject: [Freeipa-users] Feature request: TACACS+ integration In-Reply-To: <4C751375.3040608@redhat.com> References: <4C750396.7020604@redhat.com> <4C751375.3040608@redhat.com> Message-ID: <4C75352E.5090302@ssaihq.com> >> >> From both a network and a security point of view, TACACS+ is >> considered preferable to RADIUS; among other benefits, it enciphers >> the entire conversation, rather than just portions of it, and can >> provide more fine-grain authorization than RADIUS. Most Cisco shops >> I've encountered consider RADIUS to be an unacceptable solution for >> AAA. Cisco considers use of TACACS+ a best practice for AAA. >> >> What I am looking for is a device on the network which provides AAA >> facilities to network infrastructure devices, and which allows >> provisioning of network infrastructure credentials through the same >> interface and at the same time as systems credentials, and which keeps >> those credentials synchronized. >> > > O.K. fair enough. However TACACS is not on our roadmap. If you can > demonstrate strong need by enterprise customers for TACACS it would be > taken into consideration for a future version of the product. > > The more practical solution which may be available to you would be to > avail yourself of the PAM integration in the tac_plus project (but to > be honest I don't see how that would give you any of the sophisticated > features you cite as being a prime motivator for utilization of > TACACS). FreeIPA is an open source project and from what you say so is > tac_plus. I would imagine patches would be welcomed by both projects > which would allow the tac_plus daemon to utilize IPA as it's back end. > We would be happy to answer any questions for the person(s) who wanted > to undertake this and contribute their work. > From what I can see it looks like the missing piece would be the ability to look up tac_plus user->group assignments from the FreeIPA/389 LDAP server. It looks like tac_plus has ""integrated"" the authentication with LDAP via PAM, but not the authorization. When building an authentication solution for network devices with FreeIPA, providing authentication via TACACS+ would be secondary, since you could have your Cisco device directly authenticate the user against FreeIPA using Kerberos. TACACS+ primary benefit is in the granular control of Authorization to network device services. If you can get tac_plus to reference an LDAP server for group membership, then you might have a reasonable solution. You would still need to assign the group's network permissions in the tac_plus configuration file, but that would be done once. Once the group access was defined, you could assign LDAP users to groups that match what's in the tac_plus config file. This really requires the tac_plus team to code direct LDAP integration into their application similar to the way Freeradius can rely on an LDAP server as a back-end. The local PAM stack was not really intended to be a service that can be farmed out for other systems to use. It was meant as a way to provide access to local services running on that system. To use PAM for group membership (I.E. through the pam_listfile ACL) would require a separate tac_plus daemon and PAM configuration for each network device. From dpal at redhat.com Wed Aug 25 16:24:20 2010 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 25 Aug 2010 12:24:20 -0400 Subject: [Freeipa-users] FreeIPA-Samba4 integration? In-Reply-To: <4C62D69D.1070909@linguamatics.com> References: <4C62D69D.1070909@linguamatics.com> Message-ID: <4C7543B4.4070906@redhat.com> Attila Bog?r wrote: > Hi, > > I would like to deploy an integrated Samba4 / FreeIPA environment. > > I would like to enquire, what's the current status of FreeIPA > 1.9.0.pre4 and Samba4 integration. > > I've tried http://freeipa.org/page/Samba_4_Configuration a month ago, > though the ldap provision didn't seem to work. I've even raised a bug > at Samba https://bugzilla.samba.org/show_bug.cgi?id=7530 - which is > still open. > > If the Fedora-DS backed Samba4 isn't ready for production at this time, > I would be interested in the pro/contra views of > - deploying a separate Samba4 instance with filesystem backend > - writing a password syncing plugin for Samba4 vs. 389-ds > based on the docs at http://directory.fedoraproject.org/wiki/Plugins > - other paths achieving integration? > What is the use case you are trying to solve by the IPA & Samba 4 integration? > Thanks, > Attila > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rmeggins at redhat.com Wed Aug 25 16:46:35 2010 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 25 Aug 2010 10:46:35 -0600 Subject: [Freeipa-users] IPA+AD sync error In-Reply-To: References: <4C6AAC48.1050006@redhat.com> <4C6AB20E.5000305@redhat.com> <4C6AB852.1060608@redhat.com> <4C6BE3AF.4010205@redhat.com> <4C6BE980.40302@redhat.com> <4C6BEDF3.4020106@redhat.com> <4C6C0FFF.50301@redhat.com> <4C73D44F.4090202@redhat.com> Message-ID: <4C7548EB.3000009@redhat.com> Shan Kumaraswamy wrote: > I can't find any AD users from IPA box Note that IPA winsync will only send new users from AD to IPA - it will not add new IPA users to AD. Try enabling the replication log level - http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting > > On Tue, Aug 24, 2010 at 5:16 PM, Rich Megginson > wrote: > > Shan Kumaraswamy wrote: > > > Hi Rich, > > After export and import CA cert at both AD and IPA box, > finally I am getting this error while creating "winsync" > agreement: > > [root at saprhds001 ~]# ipa-replica-manage add --winsync > --binddn "CN=Administrator,CN=Users,DC=test,DC=ad" --bindpw > "xxx" --cacert /etc/dirsrv/slapd-XXXX-COM/adca.cer > windows.test.ad > > -v > --passsync "xxxxx" > Directory Manager password: > INFO:root:Shutting down dirsrv: > BMIBANK-COM... [ OK ] > INFO:root: > INFO:root: > INFO:root: > INFO:root:Starting dirsrv: > BMIBANK-COM... [ OK ] > INFO:root: > INFO:root:Added CA certificate > /etc/dirsrv/slapd-XXXXX-COM/adca.cer to certificate database > for saprhds001.xxxx.com > > > INFO:root:Restarted directory server saprhds001.xxxx.com > > > INFO:root:Could not validate connection to remote server > windows.test.ad:636 > > - > continuing > INFO:root:The error was: A database error occurred > The user for the Windows PassSync service is > uid=passsync,cn=sysaccounts,cn=etc,dc=xxxx,dc=com > Windows PassSync entry exists, not resetting password > INFO:root:Added new sync agreement, waiting for it to become > ready . . . > INFO:root:Replication Update in progress: FALSE: status: 0 > Incremental update started: start: 20100824120022Z: end: > 20100824120022Z > INFO:root:Agreement is ready, starting replication . . . > Starting replication, please wait until this has completed. > Update succeeded > INFO:root:Added agreement for other host windows.test.ad > > > Please advice to fix this issue. > > What issue? The problem about "Could not validate connection" is > normal - just ignore that. > > > > On Wed, Aug 18, 2010 at 7:53 PM, Rich Megginson > > >> wrote: > > Shan Kumaraswamy wrote: > > Rich, > When I try to open redhat-idm-console using directory > server, > I am getting this error: > The certificate this server present is either untrusted or > unkown. The server only communicate through a secure > connection involving a certivicate. Do you wihs to > accept this > certificate anyway? > As per this message even I say yes to proceed, but > fail to > open. Please advice. > > The use of the console is not supported with IPA. > > The console keeps its cert database in ~/.redhat-idm-console - > unless you have previously installed the CA cert there, the > console will prompt you if you want to trust the server. > > I'm not sure why the console will not open, except that the > console does not generally work with IPA. You can use > redhat-idm-console -D 9 -f console.log to get detailed trace > information from the console. > > > On Wed, Aug 18, 2010 at 5:28 PM, Rich Megginson > > > > >>> wrote: > > Shan Kumaraswamy wrote: > > Sorry, I was deleted the copyied cert file.... :( > > If you want to get the CA cert out of the certdb and > into > ascii/pem format: > certutil -d /etc/dirsrv/slapd-instancename -L -n > "Imported > CA" -a > > msadca.crt > > If you want to get the CA cert directly from MS CA: > on your AD box, open a web browser > go to http:///certsrv > There should be an option there to view or download > the CA > cert. > You want to download it in ascii/pem/base64 format > (I think > Windows uses the term Base64 encoded cert for PEM). > Then > you'll > have to copy that file to your IPA box. > > > > On Wed, Aug 18, 2010 at 5:09 PM, Rich Megginson > > > >> > > > > >>>> wrote: > > Shan Kumaraswamy wrote: > > Ok sure, I will do the test and can > please let > me know > command > to import AD CA in to dirsrv cert db? > > It is already in there? This is the > certificate called > "Imported > CA" with Subject: > "CN=test-WINDOWS-CA,DC=test,DC=ad" and > Issuer: > "CN=test-WINDOWS-CA,DC=test,DC=ad" > > Or are you asking because you don't know how > it got > in there in > the first place, or forgot? > > On Wed, Aug 18, 2010 at > 4:44 PM, > Rich Megginson > > > > >> > > > > >>> > > > > > >> > > > > >>>>> wrote: > > Shan Kumaraswamy wrote: > > Rich, > Can I know command to trust IPA > genearated CA > cert file? > > See below > > So I don't think that is the problem here. > If that > were the > problem, I would expect a different error > message. > I think > you're > just going to have to use something > like openssl > s_client to > examine the server cert used by AD. > > On Tue, Aug 17, > 2010 at > 7:26 PM, > Rich Megginson > > > > > >> > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > > >>>>>> wrote: > > Shan Kumaraswamy wrote: > > > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > > 46:90:cd:94:c6:53:d4:ae:44:a6:df:e2:6b:24:15:56 > Signature Algorithm: > PKCS > #1 SHA-1 > With RSA > Encryption > Issuer: > "CN=test-WINDOWS-CA,DC=test,DC=ad" > Validity: > Not Before: Tue > Aug 17 > 01:39:07 2010 > Not After : Mon > Aug 17 > 01:49:05 2015 > Subject: > "CN=test-WINDOWS-CA,DC=test,DC=ad" > Subject Public Key Info: > Public Key > Algorithm: > PKCS #1 RSA > Encryption > RSA Public Key: > Modulus: > > > a9:6e:1a:54:c2:70:1c:d7:dc:06:b4:d3:09:0f:8d:25: > > > e5:8f:9f:1f:f6:f9:ee:fb:9c:6b:9c:84:c3:01:f7:45: > > > f1:8e:43:d3:ed:ad:01:e6:92:6c:52:f4:d7:03:03:19: > > > 0a:93:84:18:42:92:2b:6b:74:3d:77:8c:31:b9:bf:75: > > > 84:cb:a0:8c:a5:df:c2:5a:d6:cb:a3:78:a2:1a:6d:a6: > > > e1:b4:81:ea:22:e7:83:bb:1f:0d:70:f8:44:29:24:96: > > > f3:f0:01:12:49:7a:59:b8:f7:1a:84:e4:e4:a4:0d:60: > > > 58:db:d9:9c:b4:51:7a:21:f2:a2:f9:ed:ee:92:6f:c0: > > > 00:39:dc:26:9f:c5:0b:e3:e1:72:62:5d:9f:8e:4a:79: > > > f3:95:56:a0:37:63:9a:d1:53:af:74:0b:c9:88:b7:43: > > > ff:11:cb:91:02:4a:5c:8c:35:41:cb:39:4e:fb:8c:a4: > > > 2d:a6:88:7b:dc:29:04:7a:f0:0a:89:25:24:76:b1:34: > > > 57:1e:c2:3f:48:79:21:47:f0:f1:1a:70:15:d8:b5:9b: > > > cb:bc:a2:3c:42:f6:da:91:a7:24:5b:fa:08:ec:41:8b: > > > c5:82:7c:81:76:3c:ef:84:58:93:cd:92:36:5d:96:55: > > > 40:72:21:5e:14:7c:fe:78:cf:35:69:97:4a:49:35:81 > Exponent: 65537 > (0x10001) > Signed Extensions: > Name: Microsoft > Enrollment > Cert Type > Extension > Data: "CA" > > Name: > Certificate Key Usage > Critical: True > Usages: Digital > Signature > > Certificate Signing > CRL Signing > > Name: > Certificate Basic > Constraints > Critical: True > Data: Is a CA > with no > maximum path > length. > > Name: Certificate > Subject Key ID > Data: > > a9:7a:6e:7c:dd:dd:4f:9e:75:78:86:6a:ff:f1:b4:06: > e6:fb:3a:6d > > Name: Microsoft > CertServ CA > version > Data: 0 (0x0) > > Signature Algorithm: > PKCS #1 SHA-1 > With RSA > Encryption > Signature: > > 02:50:bd:c6:3a:80:85:9d:46:16:94:8c:e2:e8:2f:0d: > > 35:09:d7:af:e1:ce:c0:23:94:19:ef:a7:df:de:56:17: > > c8:9e:d5:a0:80:7e:31:46:1d:c0:c1:5a:e9:7d:fe:c3: > > bb:08:c0:6d:35:3a:f2:43:c2:b7:2f:44:2b:89:7f:f1: > > ad:e8:9e:51:fa:98:12:d9:2b:2d:08:00:80:c3:78:93: > > e7:bc:ee:17:ae:a3:07:81:6b:63:ac:bf:65:d5:e9:a8: > > e9:81:42:56:24:fc:2f:b8:d1:76:5b:72:c0:8f:62:66: > > cc:4d:5b:84:85:fb:63:06:6c:0a:54:a0:55:08:bf:11: > > 4b:30:ab:ba:49:19:39:ee:4f:57:3c:7b:0b:d3:8d:fe: > > 10:d8:18:63:ee:86:e9:cb:89:1e:ea:7e:0a:68:8c:f8: > > da:40:69:ca:2c:bc:5d:24:18:bc:2b:d7:ce:08:ca:d7: > > e8:aa:4b:d8:cb:ee:17:f3:4f:18:29:fc:48:59:ae:98: > > 18:37:f0:a7:cd:42:1f:5d:79:cd:a1:0f:30:41:7f:97: > > 81:43:68:8b:74:0c:d8:21:b6:eb:76:14:bf:44:14:13: > > dd:07:ee:ce:68:95:29:b1:14:f6:93:81:90:b5:e6:6a: > > 2b:38:6a:f0:4c:20:3f:fc:88:84:3f:43:5e:5f:6e:ed > Fingerprint (MD5): > > 4B:AE:EB:7D:D0:B6:C8:D3:15:1B:08:ED:39:A0:68:6C > Fingerprint (SHA1): > > > 84:17:7E:EE:93:B2:A3:4F:D9:7B:72:C6:ED:D6:61:9E:0E:82:51:BC > > Certificate Trust Flags: > SSL Flags: > Valid CA > Trusted CA > Trusted Client CA > Email Flags: > Object Signing Flags: > Valid CA > Trusted CA > > This looks ok. So is it > possible the AD > server cert > was not > issued by this CA? I suppose you > could use > an SSL > test program > like /usr/bin/ssltap > or openssl s_client like this: > openssl s_client -connect > windows.test.ad:636 > > > > > > -CAfile > /path/to/msadcacert.asc > > You can also add -verify 3 and > -showcerts and > -debug > see "man s_client" for more > information > > > > > On Tue, Aug 17, 2010 at > 7:04 PM, Shan > Kumaraswamy > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>>>> > wrote: > > done, and it came the output > also, can > plz let me > know the > next step. > > > On Tue, Aug 17, 2010 at 7:00 > PM, Rich > Megginson > > > > >> > > > > > >>> > > > >> > > > > >>>> > > > > >> > > > > > >>> > > > >> > > > > >>>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>> > > > >> > > > > >>> > > > > >> > > > > > >>>>>>> wrote: > > Shan Kumaraswamy wrote: > > Rich, > Please find the > below > out put > of the > command: > > [root at saprhds001 ~]# > certutil -d > > /etc/dirsrv/slapd-XXXX-COM -L > Certificate > Nickname > Trust Attributes > > > SSL,S/MIME,JAR/XPI > Imported CA > > CT,,C > CA certificate > > CTu,u,Cu > > The CT means the CA is trusted for SSL > client and > server certs. > certutil -H > ... > trustargs is > of the > form x,y,z > where x is > for SSL, y is for S/MIME, > ... > c valid CA > T trusted > CA to > issue > client certs > (implies c) > C trusted > CA to > issue > server certs > (implies c) > > Server-Cert > > u,u,u > > I'm assuming > "Imported CA" > is the > MS AD > CA. Do > this: > certutil -d > /etc/dirsrv/slapd-XXXX-COM -L -n > "Imported CA" > > > > On Tue, Aug 17, > 2010 at > 6:35 > PM, Rich > Megginson > > > > > >> > > > > >>> > > > > >> > > > > > >>>> > > > >> > > > > >>> > > > > > >> > > > > >>>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>> > > > >> > > > > >>> > > > > > >> > > > > >>>>>> > > > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>>> > > > >> > > > > >>> > > > > > >> > > > >>>> > > > > >> > > > > >>> > > > > >> > > > > > >>>>>>>> > wrote: > > Shan > Kumaraswamy wrote: > > After this > error, I have > triyed your the > following > steps: > > /usr/lib64/mozldap/ldapsearch -h > windows.test.ad > > > > > > > > > > > > > > > > > > > > > -D > > "CN=administrator,CN=users,DC=test,DC=ad" -w > "xxxx" > -s base -b > "" > "objectclass=*" > > Then I got > output like > this: > > version: 1 > dn: > currentTime: > 20100817220245.0Z > > subschemaSubentry: > > > CN=Aggregate,CN=Schema,CN=Configuration,DC=test,DC=ad > > dsServiceName: > CN=NTDS > > > Settings,CN=WINDOWS,CN=Servers,CN=Default-First-Site-Na > > me,CN=Sites,CN=Configuration,DC=test,DC=ad > > namingContexts: > DC=test,DC=ad > > namingContexts: > CN=Configuration,DC=test,DC=ad > > namingContexts: > > CN=Schema,CN=Configuration,DC=test,DC=ad > > namingContexts: > DC=DomainDnsZones,DC=test,DC=ad > > namingContexts: > DC=ForestDnsZones,DC=test,DC=ad > > defaultNamingContext: > DC=test,DC=ad > > schemaNamingContext: > > CN=Schema,CN=Configuration,DC=test,DC=ad > > configurationNamingContext: > > CN=Configuration,DC=test,DC=ad > > rootDomainNamingContext: > DC=test,DC=ad > > supportedControl: > 1.2.840.113556.1.4.319 > > supportedControl: > 1.2.840.113556.1.4.801 > > supportedControl: > 1.2.840.113556.1.4.473 > > supportedControl: > 1.2.840.113556.1.4.528 > > supportedControl: > 1.2.840.113556.1.4.417 > > supportedControl: > 1.2.840.113556.1.4.619 > > supportedControl: > 1.2.840.113556.1.4.841 > > supportedControl: > 1.2.840.113556.1.4.529 > > supportedControl: > 1.2.840.113556.1.4.805 > > supportedControl: > 1.2.840.113556.1.4.521 > > supportedControl: > 1.2.840.113556.1.4.970 > > supportedControl: > 1.2.840.113556.1.4.1338 > > supportedControl: > 1.2.840.113556.1.4.474 > > supportedControl: > 1.2.840.113556.1.4.1339 > > supportedControl: > 1.2.840.113556.1.4.1340 > > supportedControl: > 1.2.840.113556.1.4.1413 > > supportedControl: > 2.16.840.1.113730.3.4.9 > > supportedControl: > 2.16.840.1.113730.3.4.10 > > supportedControl: > 1.2.840.113556.1.4.1504 > > supportedControl: > 1.2.840.113556.1.4.1852 > > supportedControl: > 1.2.840.113556.1.4.802 > > supportedControl: > 1.2.840.113556.1.4.1907 > > supportedControl: > 1.2.840.113556.1.4.1948 > > supportedControl: > 1.2.840.113556.1.4.1974 > > supportedControl: > 1.2.840.113556.1.4.1341 > > supportedControl: > 1.2.840.113556.1.4.2026 > > supportedControl: > 1.2.840.113556.1.4.2064 > > supportedControl: > 1.2.840.113556.1.4.2065 > > supportedLDAPVersion: 3 > > supportedLDAPVersion: 2 > > supportedLDAPPolicies: > MaxPoolThreads > > supportedLDAPPolicies: > MaxDatagramRecv > > supportedLDAPPolicies: > MaxReceiveBuffer > > supportedLDAPPolicies: > InitRecvTimeout > > supportedLDAPPolicies: > MaxConnections > > supportedLDAPPolicies: > MaxConnIdleTime > > supportedLDAPPolicies: > MaxPageSize > > supportedLDAPPolicies: > MaxQueryDuration > > supportedLDAPPolicies: > MaxTempTableSize > > supportedLDAPPolicies: > MaxResultSetSize > > supportedLDAPPolicies: > MinResultSets > > supportedLDAPPolicies: > MaxResultSetsPerConn > > supportedLDAPPolicies: > MaxNotificationPerConn > > supportedLDAPPolicies: > MaxValRange > > highestCommittedUSN: 73772 > > supportedSASLMechanisms: GSSAPI > > supportedSASLMechanisms: > GSS-SPNEGO > > supportedSASLMechanisms: EXTERNAL > > supportedSASLMechanisms: > DIGEST-MD5 > dnsHostName: > Windows.test.ad > > > > > > > > > > > > > > > > > > > > > > ldapServiceName: > test.ad:windows$@TEST.AD > > > > > > > > > > > > > > > > > > > > serverName: > > > CN=WINDOWS,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Confi > > guration,DC=test,DC=ad > > supportedCapabilities: > 1.2.840.113556.1.4.800 > > supportedCapabilities: > 1.2.840.113556.1.4.1670 > > supportedCapabilities: > 1.2.840.113556.1.4.1791 > > supportedCapabilities: > 1.2.840.113556.1.4.1935 > > supportedCapabilities: > 1.2.840.113556.1.4.2080 > > isSynchronized: TRUE > > isGlobalCatalogReady: TRUE > > domainFunctionality: 4 > > forestFunctionality: 4 > > domainControllerFunctionality: 4 > > Then I tried > next step: > > /usr/lib64/mozldap/ldapsearch > -ZZ -P > > /etc/dirsrv/slapd-XXXX-COM/cert8.db -h > windows.test.ad > > > > > > > > > > > > > > > > > > > > > -D > > "CN=administrator,CN=users,DC=test,DC=ad" -w > "xxxxx" -s base > -b "" > "objectclass=*" > > > ldap_simple_bind: Can't > contact LDAP > server > > TLS/SSL error > -8179 (Peer's > Certificate > issuer is not > recognized.) > Please > help me > to fix > this..... > > This usually > means > the SSL > server's CA > cert is not > recognized. > What does > this say: > certutil -d > /etc/dirsrv/slapd-XXXX-COM -L > ? > > > On Tue, > Aug 17, > 2010 > at 2:02 > PM, Shan > Kumaraswamy > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>> > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>>>> > > > > >> > > > > > >>> > > > > > >> > > > > > >>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > >>>>> > > > > > > >> > > > > > >>> > > > > > >> > > > > > From jdennis at redhat.com Wed Aug 25 17:06:51 2010 From: jdennis at redhat.com (John Dennis) Date: Wed, 25 Aug 2010 13:06:51 -0400 Subject: [Freeipa-users] Feature request: TACACS+ integration In-Reply-To: <4C75352E.5090302@ssaihq.com> References: <4C750396.7020604@redhat.com> <4C751375.3040608@redhat.com> <4C75352E.5090302@ssaihq.com> Message-ID: <4C754DAB.6050705@redhat.com> On 08/25/2010 11:22 AM, James Roman wrote: >> The more practical solution which may be available to you would be to >> avail yourself of the PAM integration in the tac_plus project (but to >> be honest I don't see how that would give you any of the sophisticated >> features you cite as being a prime motivator for utilization of >> TACACS). FreeIPA is an open source project and from what you say so is >> tac_plus. I would imagine patches would be welcomed by both projects >> which would allow the tac_plus daemon to utilize IPA as it's back end. >> We would be happy to answer any questions for the person(s) who wanted >> to undertake this and contribute their work. >> > From what I can see it looks like the missing piece would be the > ability to look up tac_plus user->group assignments from the FreeIPA/389 > LDAP server. It looks like tac_plus has ""integrated"" the > authentication with LDAP via PAM, but not the authorization. When > building an authentication solution for network devices with FreeIPA, > providing authentication via TACACS+ would be secondary, since you could > have your Cisco device directly authenticate the user against FreeIPA > using Kerberos. TACACS+ primary benefit is in the granular control of > Authorization to network device services. If you can get tac_plus to > reference an LDAP server for group membership, then you might have a > reasonable solution. You would still need to assign the group's network > permissions in the tac_plus configuration file, but that would be done > once. Once the group access was defined, you could assign LDAP users to > groups that match what's in the tac_plus config file. > > This really requires the tac_plus team to code direct LDAP integration > into their application similar to the way Freeradius can rely on an LDAP > server as a back-end. The local PAM stack was not really intended to be > a service that can be farmed out for other systems to use. It was meant > as a way to provide access to local services running on that system. To > use PAM for group membership (I.E. through the pam_listfile ACL) would > require a separate tac_plus daemon and PAM configuration for each > network device. Adding ldap queries to tac_plus would be the most general solution in which case this would have little direct relevance to IPA. However the schema we use, ACL's and internal "business logic" applied on top of LDAP queries might not map easily to a generic LDAP interface in tac_plus. I really don't know. All of this is to say there is another way to use IPA as a backend service besides connecting to our LDAP server. We do support an XML-RPC interface that is fully authenticated and encrypted. So another options would be for tac_plus to make RPC calls. Just a thought. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Aug 25 17:21:41 2010 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 25 Aug 2010 13:21:41 -0400 Subject: [Freeipa-users] Feature request: TACACS+ integration In-Reply-To: <4C75352E.5090302@ssaihq.com> References: <4C750396.7020604@redhat.com> <4C751375.3040608@redhat.com> <4C75352E.5090302@ssaihq.com> Message-ID: <4C755125.60608@redhat.com> James Roman wrote: > >>> >>> From both a network and a security point of view, TACACS+ is >>> considered preferable to RADIUS; among other benefits, it enciphers >>> the entire conversation, rather than just portions of it, and can >>> provide more fine-grain authorization than RADIUS. Most Cisco shops >>> I've encountered consider RADIUS to be an unacceptable solution for >>> AAA. Cisco considers use of TACACS+ a best practice for AAA. >>> >>> What I am looking for is a device on the network which provides AAA >>> facilities to network infrastructure devices, and which allows >>> provisioning of network infrastructure credentials through the same >>> interface and at the same time as systems credentials, and which keeps >>> those credentials synchronized. >>> >> >> O.K. fair enough. However TACACS is not on our roadmap. If you can >> demonstrate strong need by enterprise customers for TACACS it would >> be taken into consideration for a future version of the product. >> >> The more practical solution which may be available to you would be to >> avail yourself of the PAM integration in the tac_plus project (but to >> be honest I don't see how that would give you any of the >> sophisticated features you cite as being a prime motivator for >> utilization of TACACS). FreeIPA is an open source project and from >> what you say so is tac_plus. I would imagine patches would be >> welcomed by both projects which would allow the tac_plus daemon to >> utilize IPA as it's back end. We would be happy to answer any >> questions for the person(s) who wanted to undertake this and >> contribute their work. >> > From what I can see it looks like the missing piece would be the > ability to look up tac_plus user->group assignments from the > FreeIPA/389 LDAP server. It looks like tac_plus has ""integrated"" the > authentication with LDAP via PAM, but not the authorization. When > building an authentication solution for network devices with FreeIPA, > providing authentication via TACACS+ would be secondary, since you > could have your Cisco device directly authenticate the user against > FreeIPA using Kerberos. TACACS+ primary benefit is in the granular > control of Authorization to network device services. If you can get > tac_plus to reference an LDAP server for group membership, then you > might have a reasonable solution. You would still need to assign the > group's network permissions in the tac_plus configuration file, but > that would be done once. Once the group access was defined, you could > assign LDAP users to groups that match what's in the tac_plus config > file. > > This really requires the tac_plus team to code direct LDAP integration > into their application similar to the way Freeradius can rely on an > LDAP server as a back-end. The local PAM stack was not really intended > to be a service that can be farmed out for other systems to use. It > was meant as a way to provide access to local services running on that > system. To use PAM for group membership (I.E. through the pam_listfile > ACL) would require a separate tac_plus daemon and PAM configuration > for each network device. I generally agree with John and James. Just want to add a bit about the roadmap and plans. With the open source whatever makes sense and is needed gets implemented. The TACACS support is not on the roadmap now but it can be if there is a real need in the community. There is no need to make it fully integrated day one. It can be a gradual process. The first step would be to set up TACACS server and use IPA for authentication via PAM proxy on the TACACS server or via PAM auth on the device itself. The full integration would be for the TACACS server to read all its identity and configuration information from LDAP . It will take time and a lot of effort for this to happen. There are gradual interim solutions in between. If someone wants to drive it with the TACACS community we are all open to assist and guide on the IPA/SSSD side. Regarding the groups mentioned above. I am not familiar with the TACACS code but I would assume that it uses the libc functions to get user and group entries. If this is the case than nsswitch can be configured to use identities provided by IPA via nss_ldap or better via SSSD. So the identities and authentication would come from the same identity server. The TACACS server will still hold the policies but those can be moved to LDAP back end gradually with collaboration with the TACACS community if there is more need than the basic integration described here can provide. Thanks Dmitri > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From kambiz at mcnc.org Wed Aug 25 17:58:47 2010 From: kambiz at mcnc.org (Kambiz Aghaiepour) Date: Wed, 25 Aug 2010 13:58:47 -0400 Subject: [Freeipa-users] Feature request: TACACS+ integration In-Reply-To: <4C75352E.5090302@ssaihq.com> References: <4C750396.7020604@redhat.com> <4C751375.3040608@redhat.com> <4C75352E.5090302@ssaihq.com> Message-ID: <4C7559D7.7030308@mcnc.org> James Roman wrote: > > From what I can see it looks like the missing piece would be the ability > to look up tac_plus user->group assignments from the FreeIPA/389 LDAP > server. It looks like tac_plus has ""integrated"" the authentication > with LDAP via PAM, but not the authorization. When building an > authentication solution for network devices with FreeIPA, providing > authentication via TACACS+ would be secondary, since you could have your > Cisco device directly authenticate the user against FreeIPA using > Kerberos. TACACS+ primary benefit is in the granular control of > Authorization to network device services. If you can get tac_plus to > reference an LDAP server for group membership, then you might have a > reasonable solution. You would still need to assign the group's network > permissions in the tac_plus configuration file, but that would be done > once. Once the group access was defined, you could assign LDAP users to > groups that match what's in the tac_plus config file. > > This really requires the tac_plus team to code direct LDAP integration > into their application similar to the way Freeradius can rely on an LDAP > server as a back-end. The local PAM stack was not really intended to be > a service that can be farmed out for other systems to use. It was meant > as a way to provide access to local services running on that system. To > use PAM for group membership (I.E. through the pam_listfile ACL) would > require a separate tac_plus daemon and PAM configuration for each > network device. Yep. We're using tac_plus from shrubbery and have configured it for pam auth for login (they've intentionally not allowed pam auth for enable access). It would be nice to not have to worry about enumerating users in the tac_plus configuration and pull data out of LDAP though that seems more to be a feature request against tac_plus than IPA. We're also using freeradius2 with LDAP auth (via pam) mostly to support a Cisco NCM installation because the Tacacs+ support in the current version of NCM is broken and fails to authenticate users if their password is >15 characters, but I digress. Some future integration of tacacs+ configuration with freeipa would be nice allowing for management via the web management interface, though I think as has been stated, the first step may be more to get the tac_plus code to look for particular group memberships. Our current user definitions are simply in the form: user = someuser { member = some_group } with the one time effort of setting up the groups. Kambiz -- "All tyranny needs to gain a foothold is for people of good conscience to remain silent." --Thomas Jefferson