From dpal at redhat.com Sun Sep 1 00:52:19 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 31 Aug 2013 20:52:19 -0400 Subject: [Freeipa-users] FreeIPA on Debian In-Reply-To: References: <522108CF.8040707@redhat.com> Message-ID: <52228FC3.7030108@redhat.com> On 08/31/2013 03:50 PM, Micha? Dwu?nik wrote: > Hi guys, > > > I do not know whether it will reach ALL the lists Dmitri put in, but anyway: > > I do am interested heavily in getting a nice inter distro product (and > if sth works both on RH-like and Deb-like distros that's quite some > bases covered...) > I'm afraid I'm not able to take the responsibility of building the deb > support myself (no skills, no time), but feel like I do need it and I > can spent some considerable time testing > (I'm still having a production NIS around and I would like to test the > interoperability when it stops being 'production'...) builds if they > appear... > > I feel like IPA is getting the well established components and builds > an added value ON them and not AGAINST them, making life easier (and > hiding the not so beatiful guts under a nice interface, too...): > Integrating KRB5 and LDAP is something people do every now and then, > but it comes with cnsiderable pain of reading contradictory guides not > updated for 10 years, > dealing with examples using crypto mechanism that should be long forgotten... > ('first, before configuring LDAP set up KRB5, having a test principal > get back to this LDAP guide' > and some two links away: > 'first, get the your LDAP feet wet, when you're able to do ldapsearch > get back and construct those ldifs to build krb5 database in ldap' > followed by 'make a new realm, but don't use krb5_newrealm'...). > > Freeipa gives hope of NOT having to deal with cn=config manually, > (it's a really nice thing, but ldifs are sth that should be hidden > from view, and most guides > for ldap/krb5 integration require creating LOTS of those 'by hand', > which makes quite a steep learning curve...). > The abundance of PAM modules for ldap/krb5 does not make it any easier > (shishi? heimdall? MIT?; libpam-ldap or libpam-ldapd?), nor the > multitude of different caching tools. > (to mention only nslcd, nsscache, libpam-ccreds, nss_updatedb...). > > Having something solid to start with todays hordes of products > requiring some auth integration thingie would be really nice > > OTOH that would be nice to have some documentation without EXAMPLE.COM inside :> > > I think getting freeipa working on Debian would be a great 'social' > move, sure to be valued among the Linux community (ok, at least the > part of community not centered on their own personal computers...), > but the transition to 'Freeipa is wideely adopted product for ...' > would surely need more people than a couple of guys in RH raising the > Debian cause and a few Debian users like me. > > Thanks to work by Alexandre Ellert it's possible to get freeipa > working with wheezy with relatively no hassle, but I'm afraid the > world needs more than him :> > > Trying that I haven't seen any obvious 'fedorisms' inside... > > As for 'let's have a dream' part -> I would like to see sth similar to > nsscache included with the freeipa suite for some really lightweight > clients, > for more than one reason... > > Dmitri, thanks for raising the flag! > > Micha? > > PS:Any idea for some advertisement on Debian side? I have no idea but where and how this effort can be advertised but any ideas are welcome! I think it would be great if someone passes it on to other lists that might be interested in joining the effort. > > On Fri, Aug 30, 2013 at 11:04 PM, Dmitri Pal wrote: >> Hello, >> >> Sorry for cross posting to 4 different lists but it seems that this is >> the best way to include most of people who might be interested in this >> discussion. >> >> The question of "When FreeIPA will be available on Debian?" has been >> coming up periodically on the list(s) without any resolution. However it >> is clear that it would be beneficial for the community and the project. >> >> May be it is time to try again? >> Let us see why it yet has not happened? >> >> 1) Some components need to be ported to Debian especially Dogtag and a >> slew of its new RESTEasy dependencies. This requires time and quite an >> effort from someone familiar with the domain. >> 2) The code needs to be changed in installer and potentially in other >> places as it might have had some Fedorizms blended in >> 3) Someone needs to own packages in Debian and maintain them, someone >> with good knowledge of the distro and time to take ownership of about 50 >> packages. >> >> Can we pull it off together this time? >> Say we plan for some Dogtag and IPA domain experts to work on the port >> during Nov 13 - Feb 14 and address 1) and 2). Would there be any >> interest to join forces with them? Would there be anyone to take on item >> 3) from the list above? >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From tjaalton at ubuntu.com Sun Sep 1 18:20:30 2013 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Sun, 01 Sep 2013 21:20:30 +0300 Subject: [Freeipa-users] [SSSD] FreeIPA on Debian In-Reply-To: <522108CF.8040707@redhat.com> References: <522108CF.8040707@redhat.com> Message-ID: <5223856E.5050408@ubuntu.com> On 31.08.2013 00:04, Dmitri Pal wrote: > Hello, > > Sorry for cross posting to 4 different lists but it seems that this is > the best way to include most of people who might be interested in this > discussion. > > The question of "When FreeIPA will be available on Debian?" has been > coming up periodically on the list(s) without any resolution. However it > is clear that it would be beneficial for the community and the project. Hi, As you know, I've been packaging stuff for the past two years with the goal of eventually having FreeIPA server on Debian/Ubuntu. A lot has been accomplished, but quite a bit is still missing too.. > May be it is time to try again? > Let us see why it yet has not happened? > > 1) Some components need to be ported to Debian especially Dogtag and a > slew of its new RESTEasy dependencies. This requires time and quite an > effort from someone familiar with the domain. Yes, this is the biggest blocker. Dogtag 9 is packaged in git and working, but I'm not going to push that to the distro. It can be used for testing the IPA server though, before we have Dogtag 10. Once the prereqs are in place the Dogtag git should be easy to rebase with 10.x. I did start packaging some of the dependencies, but hit a wall when some maven component needed a different release than another one.. AIUI this is a known issue with maven based projects.. Other blockers off the top of my head include: - support for shared certificate database in NSS * patches sent to the Debian bug (#537866), maintainer isn't too responsive - dyndb support in bind * haven't asked the maintainer to add it to bind9, it might happen - porting the IPA server installer for Debian * this has been discussed on the list at some point, and I guess upstream knows best how the code needs to be organized to make it happen.. > 2) The code needs to be changed in installer and potentially in other > places as it might have had some Fedorizms blended in yep, and I need to send the platform module for the client soon, the latest version seems to be working fine. > 3) Someone needs to own packages in Debian and maintain them, someone > with good knowledge of the distro and time to take ownership of about 50 > packages. I'm doing this on my spare time, which has meant obvious delays in shipping something. Would be great to have more skillful people (pun intended) on the pkg-freeipa team.. > Can we pull it off together this time? > Say we plan for some Dogtag and IPA domain experts to work on the port > during Nov 13 - Feb 14 and address 1) and 2). Would there be any > interest to join forces with them? Would there be anyone to take on item > 3) from the list above? I could send an email to debian-devel@ asking if someone is interested in helping us out. And maybe blog about it too (on planet.ubuntu.com).. -- t From dpal at redhat.com Sun Sep 1 18:43:05 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 01 Sep 2013 14:43:05 -0400 Subject: [Freeipa-users] [SSSD] FreeIPA on Debian In-Reply-To: <5223856E.5050408@ubuntu.com> References: <522108CF.8040707@redhat.com> <5223856E.5050408@ubuntu.com> Message-ID: <52238AB9.60707@redhat.com> On 09/01/2013 02:20 PM, Timo Aaltonen wrote: > On 31.08.2013 00:04, Dmitri Pal wrote: >> Hello, >> >> Sorry for cross posting to 4 different lists but it seems that this is >> the best way to include most of people who might be interested in this >> discussion. >> >> The question of "When FreeIPA will be available on Debian?" has been >> coming up periodically on the list(s) without any resolution. However it >> is clear that it would be beneficial for the community and the project. > Hi, > > As you know, I've been packaging stuff for the past two years with the > goal of eventually having FreeIPA server on Debian/Ubuntu. A lot has > been accomplished, but quite a bit is still missing too.. > >> May be it is time to try again? >> Let us see why it yet has not happened? >> >> 1) Some components need to be ported to Debian especially Dogtag and a >> slew of its new RESTEasy dependencies. This requires time and quite an >> effort from someone familiar with the domain. > Yes, this is the biggest blocker. Dogtag 9 is packaged in git and > working, but I'm not going to push that to the distro. It can be used > for testing the IPA server though, before we have Dogtag 10. Once the > prereqs are in place the Dogtag git should be easy to rebase with 10.x. > > I did start packaging some of the dependencies, but hit a wall when some > maven component needed a different release than another one.. AIUI this > is a known issue with maven based projects.. > > Other blockers off the top of my head include: > > - support for shared certificate database in NSS > * patches sent to the Debian bug (#537866), maintainer isn't too > responsive How can we help? > - dyndb support in bind > * haven't asked the maintainer to add it to bind9, it might happen Are you talking about byndb maintainer or bind9 Debian maintainer? May be we should connect the two? > - porting the IPA server installer for Debian > * this has been discussed on the list at some point, and I guess > upstream knows best how the code needs to be organized to make it > happen.. Yes I how so too. > >> 2) The code needs to be changed in installer and potentially in other >> places as it might have had some Fedorizms blended in > yep, and I need to send the platform module for the client soon, the > latest version seems to be working fine. This is great. > >> 3) Someone needs to own packages in Debian and maintain them, someone >> with good knowledge of the distro and time to take ownership of about 50 >> packages. > I'm doing this on my spare time, which has meant obvious delays in > shipping something. Would be great to have more skillful people (pun > intended) on the pkg-freeipa team.. Are you the only person there so far? > >> Can we pull it off together this time? >> Say we plan for some Dogtag and IPA domain experts to work on the port >> during Nov 13 - Feb 14 and address 1) and 2). Would there be any >> interest to join forces with them? Would there be anyone to take on item >> 3) from the list above? > I could send an email to debian-devel@ asking if someone is interested > in helping us out. And maybe blog about it too (on planet.ubuntu.com).. > > Yes that would help. Thank you very much for your efforts! -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From tjaalton at ubuntu.com Sun Sep 1 20:35:06 2013 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Sun, 01 Sep 2013 23:35:06 +0300 Subject: [Freeipa-users] [SSSD] FreeIPA on Debian In-Reply-To: <52238AB9.60707@redhat.com> References: <522108CF.8040707@redhat.com> <5223856E.5050408@ubuntu.com> <52238AB9.60707@redhat.com> Message-ID: <5223A4FA.5020701@ubuntu.com> On 01.09.2013 21:43, Dmitri Pal wrote: > On 09/01/2013 02:20 PM, Timo Aaltonen wrote: >> On 31.08.2013 00:04, Dmitri Pal wrote: >>> Hello, >>> >>> Sorry for cross posting to 4 different lists but it seems that this is >>> the best way to include most of people who might be interested in this >>> discussion. >>> >>> The question of "When FreeIPA will be available on Debian?" has been >>> coming up periodically on the list(s) without any resolution. However it >>> is clear that it would be beneficial for the community and the project. >> Hi, >> >> As you know, I've been packaging stuff for the past two years with the >> goal of eventually having FreeIPA server on Debian/Ubuntu. A lot has >> been accomplished, but quite a bit is still missing too.. >> >>> May be it is time to try again? >>> Let us see why it yet has not happened? >>> >>> 1) Some components need to be ported to Debian especially Dogtag and a >>> slew of its new RESTEasy dependencies. This requires time and quite an >>> effort from someone familiar with the domain. >> Yes, this is the biggest blocker. Dogtag 9 is packaged in git and >> working, but I'm not going to push that to the distro. It can be used >> for testing the IPA server though, before we have Dogtag 10. Once the >> prereqs are in place the Dogtag git should be easy to rebase with 10.x. >> >> I did start packaging some of the dependencies, but hit a wall when some >> maven component needed a different release than another one.. AIUI this >> is a known issue with maven based projects.. >> >> Other blockers off the top of my head include: >> >> - support for shared certificate database in NSS >> * patches sent to the Debian bug (#537866), maintainer isn't too >> responsive > > How can we help? I don't think you can, guess it just needs some perseverance on my side.. >> - dyndb support in bind >> * haven't asked the maintainer to add it to bind9, it might happen > > Are you talking about byndb maintainer or bind9 Debian maintainer? > May be we should connect the two? the debian bind maintainer, I heard from the dyndb maintainer that bind10 might support it natively, but getting that in Debian might still be further in the future, so if we'd need dyndb by early next year it's probably needed to have it via bind9 first. >>> 3) Someone needs to own packages in Debian and maintain them, someone >>> with good knowledge of the distro and time to take ownership of about 50 >>> packages. >> I'm doing this on my spare time, which has meant obvious delays in >> shipping something. Would be great to have more skillful people (pun >> intended) on the pkg-freeipa team.. > > Are you the only person there so far? pretty much, there have been some debian developers sponsoring packages to the distro (I'm not a DD yet), but they've all fled before too long :) -- t From jhrozek at redhat.com Mon Sep 2 08:51:11 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 2 Sep 2013 10:51:11 +0200 Subject: [Freeipa-users] [Freeipa-devel] [SSSD] FreeIPA on Debian In-Reply-To: <5223856E.5050408@ubuntu.com> References: <522108CF.8040707@redhat.com> <5223856E.5050408@ubuntu.com> Message-ID: <20130902085111.GC4721@hendrix.brq.redhat.com> On Sun, Sep 01, 2013 at 09:20:30PM +0300, Timo Aaltonen wrote: > > 3) Someone needs to own packages in Debian and maintain them, someone > > with good knowledge of the distro and time to take ownership of about 50 > > packages. > > I'm doing this on my spare time, which has meant obvious delays in > shipping something. Would be great to have more skillful people (pun > intended) on the pkg-freeipa team.. Let me just say that I was always amazed at the level of quality bug reports and collaboration that came from Ubuntu community via your packages. This Friday we received several bug reports that will be important to fix in 1.11. Please keep up the good work! From jprouty at cctus.com Tue Sep 3 04:51:16 2013 From: jprouty at cctus.com (Jason Prouty) Date: Mon, 2 Sep 2013 22:51:16 -0600 (MDT) Subject: [Freeipa-users] free radiuse Message-ID: <1b429ffe.00001afc.00000001@CCTJPROUTY01.JCIGROUP.local> I have IPA-server installed and working for my linux servers I have several cisco Routers 2821 and juniper FW that I would like to authenticate against IPA. I have a free radius .schema file. Or is there a better way? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Duncan.Innes at virginmoney.com Tue Sep 3 08:21:37 2013 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Tue, 3 Sep 2013 09:21:37 +0100 Subject: [Freeipa-users] Automated Kickstart Enrollment Message-ID: <56343345B145C043AE990701E3D1939501D56C0B@EXVS2.nrplc.localnet> Hi folks, I've got a question about kickstart enrollment with a one-time password. Namely, is there any way that it can be done *without* the one-time password. We're comfortable with the pre-creation of the host in IPA, but just wonder if there's a way to enrol without the one-time password. The estate is Red Hat (mostly 6) and we deploy systems via kickstart from the Satellite. Can the Satellite push out a certificate from the IPA system that would allow client to enrol without the OTP? Our enrollment script runs as part of the kickstart postinstall with the OTP effectively sitting in plain text in the script. Removing the OTP would remove the plain text authentication from this script, but I may be opening other security holes as a result. Cheers Duncan Innes This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Discovery House, Whiting Road, Norwich NR4 6EJ: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Tue Sep 3 14:07:14 2013 From: jdennis at redhat.com (John Dennis) Date: Tue, 03 Sep 2013 10:07:14 -0400 Subject: [Freeipa-users] free radiuse In-Reply-To: <1b429ffe.00001afc.00000001@CCTJPROUTY01.JCIGROUP.local> References: <1b429ffe.00001afc.00000001@CCTJPROUTY01.JCIGROUP.local> Message-ID: <5225ED12.7070207@redhat.com> On 09/03/2013 12:51 AM, Jason Prouty wrote: > I have IPA-server installed and working for my linux servers > > I have several cisco Routers 2821 and juniper FW that I would like to > authenticate against IPA. > > I have a free radius .schema file. First you have to tell us what authentication protocols these devices support. Then we can tell you the best approach. FWIW adding radius schema to freeipa LDAP is *not* likely to be a viable option because many of the radius schema elements conflict with how IPA manages things. You're better off using the IPA schema and configuring FreeRADIUS to use it. -- John From dpal at redhat.com Tue Sep 3 15:50:14 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 03 Sep 2013 11:50:14 -0400 Subject: [Freeipa-users] Automated Kickstart Enrollment In-Reply-To: <56343345B145C043AE990701E3D1939501D56C0B@EXVS2.nrplc.localnet> References: <56343345B145C043AE990701E3D1939501D56C0B@EXVS2.nrplc.localnet> Message-ID: <52260536.5070309@redhat.com> On 09/03/2013 04:21 AM, Innes, Duncan wrote: > Hi folks, > > I've got a question about kickstart enrollment with a one-time > password. Namely, is there any way that it can be done *without* the > one-time password. We're comfortable with the pre-creation of the > host in IPA, but just wonder if there's a way to enrol without the > one-time password. > > The estate is Red Hat (mostly 6) and we deploy systems via kickstart > from the Satellite. Can the Satellite push out a certificate from the > IPA system that would allow client to enrol without the OTP? Our > enrollment script runs as part of the kickstart postinstall with the > OTP effectively sitting in plain text in the script. Removing the OTP > would remove the plain text authentication from this script, but I may > be opening other security holes as a result. > Hello, There have been 3 ways about how the host can be enrolled: a) High level admin using his credential (no need to have a pre-created host) b) Lower level admin using his credential (requires a pre-created host) c) OTP based (requires a pre-created host) All provisioning methods that use static kickstart files would have to have something injected into the kickstart. OTP is the safest and if leaked can be used to only provision this specific system. The fact that OTP was stolen can be detected easily by having a failed enrollment of the valid system combined with IPA logs indicating that there was a successful enrollment of the new host with the same name. The fact that intruder was able to join a machine into IPA domain does not escalate his privileges against other systems and since it can be easily caught it is a risk but not a huge one. The right approach of cause is not to have the OTP stored in kickstart but rather parameterized in some way. In Satellite 6 (that we are looking at) this will be done via Foreman and its smart proxies. The design is not polished yet but we hope that we would be able to limit the exposure of the OTPs there. Also a new provisioning method has been added in FreeIPA 3.2 mostly for re-provisioning - ability to provision if you already have a keytab. This method will be sort of equivalent to what you are asking with a cert. But instead of the cert you would need to get keytab first by creating a host and then using ipa-getkeytab command and passing keytab to the kickstart. That can be done now and would address the issue you are concerned about. HTH Thanks, Dmitri > Cheers > > Duncan Innes > > > This message has been checked for viruses and spam by the Virgin Money > email scanning system powered by Messagelabs. > > > > This e-mail is intended to be confidential to the recipient. If you > receive a copy in error, please inform the sender and then delete this > message. > > Virgin Money plc - Registered in England and Wales (Company no. > 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon > Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential > Regulation Authority and regulated by the Financial Conduct Authority > and the Prudential Regulation Authority. > > The following companies also trade as Virgin Money. They are both > authorised and regulated by the Financial Conduct Authority, are > registered in England and Wales and have their registered office at > Discovery House, Whiting Road, Norwich NR4 6EJ: Virgin Money Personal > Financial Service Limited (Company no. 3072766) and Virgin Money Unit > Trust Managers Limited (Company no. 3000482). > > For further details of Virgin Money group companies please visit our > website at virginmoney.com > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Duncan.Innes at virginmoney.com Tue Sep 3 16:03:08 2013 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Tue, 3 Sep 2013 17:03:08 +0100 Subject: [Freeipa-users] Automated Kickstart Enrollment In-Reply-To: <52260536.5070309@redhat.com> References: <56343345B145C043AE990701E3D1939501D56C0B@EXVS2.nrplc.localnet> <52260536.5070309@redhat.com> Message-ID: <56343345B145C043AE990701E3D1939501D56C19@EXVS2.nrplc.localnet> Sounds like future work and integrating with Satellite 6 when it comes. We delete the post-install scripts before reboot at the moment, so we're not in a bad way. Thanks Dmitri ________________________________ From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: 03 September 2013 16:50 To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Automated Kickstart Enrollment On 09/03/2013 04:21 AM, Innes, Duncan wrote: Hi folks, I've got a question about kickstart enrollment with a one-time password. Namely, is there any way that it can be done *without* the one-time password. We're comfortable with the pre-creation of the host in IPA, but just wonder if there's a way to enrol without the one-time password. The estate is Red Hat (mostly 6) and we deploy systems via kickstart from the Satellite. Can the Satellite push out a certificate from the IPA system that would allow client to enrol without the OTP? Our enrollment script runs as part of the kickstart postinstall with the OTP effectively sitting in plain text in the script. Removing the OTP would remove the plain text authentication from this script, but I may be opening other security holes as a result. Hello, There have been 3 ways about how the host can be enrolled: a) High level admin using his credential (no need to have a pre-created host) b) Lower level admin using his credential (requires a pre-created host) c) OTP based (requires a pre-created host) All provisioning methods that use static kickstart files would have to have something injected into the kickstart. OTP is the safest and if leaked can be used to only provision this specific system. The fact that OTP was stolen can be detected easily by having a failed enrollment of the valid system combined with IPA logs indicating that there was a successful enrollment of the new host with the same name. The fact that intruder was able to join a machine into IPA domain does not escalate his privileges against other systems and since it can be easily caught it is a risk but not a huge one. The right approach of cause is not to have the OTP stored in kickstart but rather parameterized in some way. In Satellite 6 (that we are looking at) this will be done via Foreman and its smart proxies. The design is not polished yet but we hope that we would be able to limit the exposure of the OTPs there. Also a new provisioning method has been added in FreeIPA 3.2 mostly for re-provisioning - ability to provision if you already have a keytab. This method will be sort of equivalent to what you are asking with a cert. But instead of the cert you would need to get keytab first by creating a host and then using ipa-getkeytab command and passing keytab to the kickstart. That can be done now and would address the issue you are concerned about. HTH Thanks, Dmitri Cheers Duncan Innes _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Discovery House, Whiting Road, Norwich NR4 6EJ: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Tue Sep 3 20:30:48 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 03 Sep 2013 13:30:48 -0700 Subject: [Freeipa-users] [Freeipa-devel] [SSSD] FreeIPA on Debian In-Reply-To: <5223A4FA.5020701@ubuntu.com> References: <522108CF.8040707@redhat.com> <5223856E.5050408@ubuntu.com> <52238AB9.60707@redhat.com> <5223A4FA.5020701@ubuntu.com> Message-ID: <522646F8.2040608@redhat.com> On 09/01/2013 01:35 PM, Timo Aaltonen wrote: > On 01.09.2013 21:43, Dmitri Pal wrote: >> On 09/01/2013 02:20 PM, Timo Aaltonen wrote: >>> On 31.08.2013 00:04, Dmitri Pal wrote: >>>> Hello, >>>> >>>> Sorry for cross posting to 4 different lists but it seems that this is >>>> the best way to include most of people who might be interested in this >>>> discussion. >>>> >>>> The question of "When FreeIPA will be available on Debian?" has been >>>> coming up periodically on the list(s) without any resolution. However it >>>> is clear that it would be beneficial for the community and the project. >>> Hi, >>> >>> As you know, I've been packaging stuff for the past two years with the >>> goal of eventually having FreeIPA server on Debian/Ubuntu. A lot has >>> been accomplished, but quite a bit is still missing too.. >>> >>>> May be it is time to try again? >>>> Let us see why it yet has not happened? >>>> >>>> 1) Some components need to be ported to Debian especially Dogtag and a >>>> slew of its new RESTEasy dependencies. This requires time and quite an >>>> effort from someone familiar with the domain. >>> Yes, this is the biggest blocker. Dogtag 9 is packaged in git and >>> working, but I'm not going to push that to the distro. It can be used >>> for testing the IPA server though, before we have Dogtag 10. Once the >>> prereqs are in place the Dogtag git should be easy to rebase with 10.x. >>> >>> I did start packaging some of the dependencies, but hit a wall when some >>> maven component needed a different release than another one.. AIUI this >>> is a known issue with maven based projects.. I would like to organize the effort to get Dogtag 10 ported to Debian. I know that there are a lot of dependencies needed for this to happen. I can create and maintain a wiki page to track all of the work that is needed to get this porting done. Do you have a list of Dogtag 10 dependencies that are not currently packaged for Debian that I can use as a starting point? Once we have a clear outline of what is needed, we can start trying to divide up and schedule the work. Do you have more details on the maven issue you were running up against? Thanks, -NGK >>> >>> Other blockers off the top of my head include: >>> >>> - support for shared certificate database in NSS >>> * patches sent to the Debian bug (#537866), maintainer isn't too >>> responsive >> How can we help? > I don't think you can, guess it just needs some perseverance on my side.. > >>> - dyndb support in bind >>> * haven't asked the maintainer to add it to bind9, it might happen >> Are you talking about byndb maintainer or bind9 Debian maintainer? >> May be we should connect the two? > the debian bind maintainer, I heard from the dyndb maintainer that > bind10 might support it natively, but getting that in Debian might still > be further in the future, so if we'd need dyndb by early next year it's > probably needed to have it via bind9 first. > >>>> 3) Someone needs to own packages in Debian and maintain them, someone >>>> with good knowledge of the distro and time to take ownership of about 50 >>>> packages. >>> I'm doing this on my spare time, which has meant obvious delays in >>> shipping something. Would be great to have more skillful people (pun >>> intended) on the pkg-freeipa team.. >> Are you the only person there so far? > pretty much, there have been some debian developers sponsoring packages > to the distro (I'm not a DD yet), but they've all fled before too long :) > From tjaalton at ubuntu.com Tue Sep 3 20:50:25 2013 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Tue, 03 Sep 2013 23:50:25 +0300 Subject: [Freeipa-users] [Freeipa-devel] [SSSD] FreeIPA on Debian In-Reply-To: <522646F8.2040608@redhat.com> References: <522108CF.8040707@redhat.com> <5223856E.5050408@ubuntu.com> <52238AB9.60707@redhat.com> <5223A4FA.5020701@ubuntu.com> <522646F8.2040608@redhat.com> Message-ID: <52264B91.9080603@ubuntu.com> On 03.09.2013 23:30, Nathan Kinder wrote: > On 09/01/2013 01:35 PM, Timo Aaltonen wrote: >> On 01.09.2013 21:43, Dmitri Pal wrote: >>> On 09/01/2013 02:20 PM, Timo Aaltonen wrote: >>>> On 31.08.2013 00:04, Dmitri Pal wrote: >>>>> Hello, >>>>> >>>>> Sorry for cross posting to 4 different lists but it seems that this is >>>>> the best way to include most of people who might be interested in this >>>>> discussion. >>>>> >>>>> The question of "When FreeIPA will be available on Debian?" has been >>>>> coming up periodically on the list(s) without any resolution. >>>>> However it >>>>> is clear that it would be beneficial for the community and the >>>>> project. >>>> Hi, >>>> >>>> As you know, I've been packaging stuff for the past two years with the >>>> goal of eventually having FreeIPA server on Debian/Ubuntu. A lot has >>>> been accomplished, but quite a bit is still missing too.. >>>> >>>>> May be it is time to try again? >>>>> Let us see why it yet has not happened? >>>>> >>>>> 1) Some components need to be ported to Debian especially Dogtag and a >>>>> slew of its new RESTEasy dependencies. This requires time and quite an >>>>> effort from someone familiar with the domain. >>>> Yes, this is the biggest blocker. Dogtag 9 is packaged in git and >>>> working, but I'm not going to push that to the distro. It can be used >>>> for testing the IPA server though, before we have Dogtag 10. Once the >>>> prereqs are in place the Dogtag git should be easy to rebase with 10.x. >>>> >>>> I did start packaging some of the dependencies, but hit a wall when >>>> some >>>> maven component needed a different release than another one.. AIUI this >>>> is a known issue with maven based projects.. > I would like to organize the effort to get Dogtag 10 ported to Debian. > I know that there are a lot of dependencies needed for this to happen. > I can create and maintain a wiki page to track all of the work that is > needed to get this porting done. Do you have a list of Dogtag 10 > dependencies that are not currently packaged for Debian that I can use > as a starting point? Once we have a clear outline of what is needed, we > can start trying to divide up and schedule the work. Alright, nice! This is the list I sent to debian-java a year ago, roughly in dependency order: codehaus-parent keytool-maven-plugin maven-help-plugin maven-idea-plugin maven-jarsigner-plugin maven-jxr maven-source-plugin geronimo-parent-poms geronimo-annotation plexus-mail-sender maven-release plexus-resources maven-checkstyle-plugin maven-pmd-plugin maven-anno-plugin maven-reporting-api maven-changes-plugin maven-deploy-plugin apache-james-project javamail base64coder gdata-java sonatype-oss-parent forge-parent mojo-parent maven-plugin-build-helper relaxngcc xsom glassfish-fastinfoset jvnet-parent glassfish-jaxb-api glassfish-dtd-parser stax-ex istack-commons rngom glassfish-jaxb maven-jaxb2-plugin jboss-parent jandex jboss-specs-parent jboss-annotations jetty-parent jetty-toolchain jetty-version-maven-plugin scannotation snakeyml resteasy There might be errors, now that I know that the fedora package of resteasy doesn't built everything to make the deps a bit easier? And at least codehaus-parent, mojo-parent and jetty-parent are packaged and pushed to git.debian.org but since I'm not a DD (yet) I can't upload them. The debian java policy means that the actual package names are like 'libmojo-parent-java' etc., in case you try to find a package. > Do you have more details on the maven issue you were running up against? if my notes are to be trusted, it was that keytool-maven-plugin wants v16 of mojo-parent, and not v30 that is in git now.. -- t From nkinder at redhat.com Tue Sep 3 20:55:40 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 03 Sep 2013 13:55:40 -0700 Subject: [Freeipa-users] [Freeipa-devel] [SSSD] FreeIPA on Debian In-Reply-To: <52264B91.9080603@ubuntu.com> References: <522108CF.8040707@redhat.com> <5223856E.5050408@ubuntu.com> <52238AB9.60707@redhat.com> <5223A4FA.5020701@ubuntu.com> <522646F8.2040608@redhat.com> <52264B91.9080603@ubuntu.com> Message-ID: <52264CCC.7090509@redhat.com> On 09/03/2013 01:50 PM, Timo Aaltonen wrote: > On 03.09.2013 23:30, Nathan Kinder wrote: >> On 09/01/2013 01:35 PM, Timo Aaltonen wrote: >>> On 01.09.2013 21:43, Dmitri Pal wrote: >>>> On 09/01/2013 02:20 PM, Timo Aaltonen wrote: >>>>> On 31.08.2013 00:04, Dmitri Pal wrote: >>>>>> Hello, >>>>>> >>>>>> Sorry for cross posting to 4 different lists but it seems that this is >>>>>> the best way to include most of people who might be interested in this >>>>>> discussion. >>>>>> >>>>>> The question of "When FreeIPA will be available on Debian?" has been >>>>>> coming up periodically on the list(s) without any resolution. >>>>>> However it >>>>>> is clear that it would be beneficial for the community and the >>>>>> project. >>>>> Hi, >>>>> >>>>> As you know, I've been packaging stuff for the past two years with the >>>>> goal of eventually having FreeIPA server on Debian/Ubuntu. A lot has >>>>> been accomplished, but quite a bit is still missing too.. >>>>> >>>>>> May be it is time to try again? >>>>>> Let us see why it yet has not happened? >>>>>> >>>>>> 1) Some components need to be ported to Debian especially Dogtag and a >>>>>> slew of its new RESTEasy dependencies. This requires time and quite an >>>>>> effort from someone familiar with the domain. >>>>> Yes, this is the biggest blocker. Dogtag 9 is packaged in git and >>>>> working, but I'm not going to push that to the distro. It can be used >>>>> for testing the IPA server though, before we have Dogtag 10. Once the >>>>> prereqs are in place the Dogtag git should be easy to rebase with 10.x. >>>>> >>>>> I did start packaging some of the dependencies, but hit a wall when >>>>> some >>>>> maven component needed a different release than another one.. AIUI this >>>>> is a known issue with maven based projects.. >> I would like to organize the effort to get Dogtag 10 ported to Debian. >> I know that there are a lot of dependencies needed for this to happen. >> I can create and maintain a wiki page to track all of the work that is >> needed to get this porting done. Do you have a list of Dogtag 10 >> dependencies that are not currently packaged for Debian that I can use >> as a starting point? Once we have a clear outline of what is needed, we >> can start trying to divide up and schedule the work. > Alright, nice! This is the list I sent to debian-java a year ago, > roughly in dependency order: Great, this will help me get started. It might be a bit out of date, as I know that we worked on reducing the number of dependencies within the last year. I'll start with this and cross-reference with the current dependencies. > > codehaus-parent > keytool-maven-plugin > maven-help-plugin > maven-idea-plugin > maven-jarsigner-plugin > maven-jxr > maven-source-plugin > geronimo-parent-poms > geronimo-annotation > plexus-mail-sender > maven-release > plexus-resources > maven-checkstyle-plugin > maven-pmd-plugin > maven-anno-plugin > maven-reporting-api > maven-changes-plugin > maven-deploy-plugin > apache-james-project > javamail > base64coder > gdata-java > sonatype-oss-parent > forge-parent > mojo-parent > maven-plugin-build-helper > relaxngcc > xsom > glassfish-fastinfoset > jvnet-parent > glassfish-jaxb-api > glassfish-dtd-parser > stax-ex > istack-commons > rngom > glassfish-jaxb > maven-jaxb2-plugin > jboss-parent > jandex > jboss-specs-parent > jboss-annotations > jetty-parent > jetty-toolchain > jetty-version-maven-plugin > scannotation > snakeyml > resteasy > > There might be errors, now that I know that the fedora package of > resteasy doesn't built everything to make the deps a bit easier? Yes, resteasy was "trimmed" to make things easier. > And at > least codehaus-parent, mojo-parent and jetty-parent are packaged and > pushed to git.debian.org but since I'm not a DD (yet) I can't upload them. > > The debian java policy means that the actual package names are like > 'libmojo-parent-java' etc., in case you try to find a package. > >> Do you have more details on the maven issue you were running up against? > if my notes are to be trusted, it was that keytool-maven-plugin wants > v16 of mojo-parent, and not v30 that is in git now.. Ok, I'll note it down and we can figure out the details when we try it again. Thanks, -NGK > > > From purpleidea at gmail.com Tue Sep 3 20:59:22 2013 From: purpleidea at gmail.com (James) Date: Tue, 3 Sep 2013 16:59:22 -0400 Subject: [Freeipa-users] [Freeipa-devel] [SSSD] FreeIPA on Debian In-Reply-To: <522646F8.2040608@redhat.com> References: <522108CF.8040707@redhat.com> <5223856E.5050408@ubuntu.com> <52238AB9.60707@redhat.com> <5223A4FA.5020701@ubuntu.com> <522646F8.2040608@redhat.com> Message-ID: Jumping in here, if someone is organizing a TODO list to get freeipa on debian, feel free to add "porting/testing puppet-ipa" to this. I'm the puppet-ipa [1] guy. I'm happy to work on that part whenever someone has a working debian freeipa install for me to use. Once it "works" or at least mostly, feel free to ping me somehow. HTH, James [1] https://github.com/purpleidea/puppet-ipa From mkosek at redhat.com Wed Sep 4 07:44:41 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 04 Sep 2013 09:44:41 +0200 Subject: [Freeipa-users] IPA Load Problems? In-Reply-To: References: <70FAFDC6-AC64-4B42-AB75-ABECDE7B350E@digitalreasoning.com> <521CB43A.40104@redhat.com> <521CDE4F.50307@redhat.com> <3D595AA0-9168-45C3-AB29-602567EAC5E4@digitalreasoning.com> <521D0FCE.3080800@redhat.com> <3B676396-41CB-40BA-A7D2-0E1CB8800C30@digitalreasoning.com> <521E1A03.1060904@redhat.com> <5220F587.6000808@redhat.com> <414556BA-3DDF-4259-AC40-D0778BF474DC@digitalreasoning.com> <5220FFC2.90207@redhat.com> <2C999C19-A8A2-435E-B54F-E6F9F7F964AF@digitalreasoning.com> <52210523.7030403@redhat.com> <6D4BA0C3-5003-46AD-842A-E95194B865E2@digitalreasonin! ! g.com> <522108C9.7030506@redhat.com> Message-ID: <5226E4E9.8090903@redhat.com> On 08/30/2013 11:08 PM, John Moyer wrote: > Well IPA has machine entries on some test clusters that I'm rolling IPA > out on (20 machines maybe) but the user base is the same (about 80 ~ 100) > accounts with maybe 40 to 50 groups? > > I've stood up a clone of the jira server along with IPA. I cleared my > logs and then did the sync and ran the log analyzer on it. These stats > are pretty much ONLY for that jira sync I don't have any other connections > pointed to it. > > > Start of Log: 30/Aug/2013:15:57:13 End of Log: > 30/Aug/2013:16:01:14 > > Processed Log Time: Hours, 4 Minutes, 1 Seconds > > Restarts: 1 Total Connections: 824 SSL > Connections: 824 Peak Concurrent Connections: 6 Total > Operations: 1806 Total Results: 1805 Overall > Performance: 99.9% > > Searches: 968 (4.02/sec) (241.00/min) > Modifications: 5 (0.02/sec) (1.24/min) Adds: > 0 (0.00/sec) (0.00/min) Deletes: 0 > (0.00/sec) (0.00/min) Mod RDNs: 0 (0.00/sec) > (0.00/min) Compares: 0 (0.00/sec) > (0.00/min) Binds: 833 (3.46/sec) > (207.39/min) > > Proxied Auth Operations: 0 Persistent Searches: 1 Internal > Operations: 0 Entry Operations: 0 Extended > Operations: 0 Abandoned Requests: 0 Smart Referrals > Received: 0 > > VLV Operations: 0 VLV Unindexed Searches: 0 SORT > Operations: 0 > > Entire Search Base Queries: 0 Unindexed Searches: 1 > This looks like a promising way to find out the reason, thanks John. However, I see just one unindexed search. Is the access log complete? Previously I see that the sync takes 900 seconds/15 minutes, but there is only 4 minutes the access log. Note that it it may take some time until the log is dumped. I think it would be also useful to run the analyzer with "-ula" flags as Rob suggested earlier to find out the unindexed searches (if any). What I find interesting is that JIRA does a lot of LDAP BINDs. Can the problem be in longer BINDs than with than expected (compared to for example plain LDAP servers)? Performance-wise, it would be I think better if JIRA does just one BIND and run all the LDAP searches the established connection. But I do not know if it can be configured this way. Rich, Rob, I am wondering if the slow up is not really caused by the binds, we have several DS plugins tied to the BIND operation, it may be useful to analyze if they do not take too long. Martin From john.moyer at digitalreasoning.com Wed Sep 4 12:01:35 2013 From: john.moyer at digitalreasoning.com (John Moyer) Date: Wed, 4 Sep 2013 08:01:35 -0400 Subject: [Freeipa-users] IPA Load Problems? In-Reply-To: <5226E4E9.8090903@redhat.com> References: <70FAFDC6-AC64-4B42-AB75-ABECDE7B350E@digitalreasoning.com> <521CB43A.40104@redhat.com> <521CDE4F.50307@redhat.com> <3D595AA0-9168-45C3-AB29-602567EAC5E4@digitalreasoning.com> <521D0FCE.3080800@redhat.com> <3B676396-41CB-40BA-A7D2-0E1CB8800C30@digitalreasoning.com> <521E1A03.1060904@redhat.com> <5220F587.6000808@redhat.com> <414556BA-3DDF-4259-AC40-D0778BF474DC@digitalreasoning.com> <5220FFC2.90207@redhat.com> <2C999C19-A8A2-435E-B54F-E6F9F7F964AF@digitalreasoning.com> <52210523.7030403@redhat.com> <6D4BA0C3-5003-46AD-842A-E95194B865E2@digitalreasonin! ! g.com> <522108C9.7030506@redhat.com> <5226E4E9.8090903@r! edhat.com> Message-ID: <52822038-F299-46D2-8BD1-D45DA0D99EA6@digitalreasoning.com> Martin, I apologize there was a large offline conversation between Rich and myself. Rich was kind enough to help me through some of my issues. We did a lot more tests and poking and prodding. We discovered that IPA is not as efficient when dealing with large number of connections. Most of my load inefficiently reconnect to IPA over and over and over and though LDAP can deal with this fairly efficiently, IPA apparently drops to it's knees. A ticket was opened to addressed this issue. https://fedorahosted.org/freeipa/ticket/3892 Thanks, _____________________________________________________ John Moyer Director, IT Operations Digital Reasoning Systems, Inc. John.Moyer at digitalreasoning.com Office: 703.678.2311 Mobile: 240.460.0023 Fax: 703.678.2312 www.digitalreasoning.com On Sep 4, 2013, at 3:44 AM, Martin Kosek wrote: > On 08/30/2013 11:08 PM, John Moyer wrote: >> Well IPA has machine entries on some test clusters that I'm rolling IPA >> out on (20 machines maybe) but the user base is the same (about 80 ~ 100) >> accounts with maybe 40 to 50 groups? >> >> I've stood up a clone of the jira server along with IPA. I cleared my >> logs and then did the sync and ran the log analyzer on it. These stats >> are pretty much ONLY for that jira sync I don't have any other connections >> pointed to it. >> >> >> Start of Log: 30/Aug/2013:15:57:13 End of Log: >> 30/Aug/2013:16:01:14 >> >> Processed Log Time: Hours, 4 Minutes, 1 Seconds >> >> Restarts: 1 Total Connections: 824 SSL >> Connections: 824 Peak Concurrent Connections: 6 Total >> Operations: 1806 Total Results: 1805 Overall >> Performance: 99.9% >> >> Searches: 968 (4.02/sec) (241.00/min) >> Modifications: 5 (0.02/sec) (1.24/min) Adds: >> 0 (0.00/sec) (0.00/min) Deletes: 0 >> (0.00/sec) (0.00/min) Mod RDNs: 0 (0.00/sec) >> (0.00/min) Compares: 0 (0.00/sec) >> (0.00/min) Binds: 833 (3.46/sec) >> (207.39/min) >> >> Proxied Auth Operations: 0 Persistent Searches: 1 Internal >> Operations: 0 Entry Operations: 0 Extended >> Operations: 0 Abandoned Requests: 0 Smart Referrals >> Received: 0 >> >> VLV Operations: 0 VLV Unindexed Searches: 0 SORT >> Operations: 0 >> >> Entire Search Base Queries: 0 Unindexed Searches: 1 >> > > This looks like a promising way to find out the reason, thanks John. However, > I see just one unindexed search. Is the access log complete? Previously I see > that the sync takes 900 seconds/15 minutes, but there is only 4 minutes the > access log. Note that it it may take some time until the log is dumped. > > I think it would be also useful to run the analyzer with "-ula" flags as Rob > suggested earlier to find out the unindexed searches (if any). > > What I find interesting is that JIRA does a lot of LDAP BINDs. Can the > problem be in longer BINDs than with than expected (compared to for example > plain LDAP servers)? Performance-wise, it would be I think better if JIRA > does just one BIND and run all the LDAP searches the established connection. > But I do not know if it can be configured this way. > > Rich, Rob, I am wondering if the slow up is not really caused by the binds, > we have several DS plugins tied to the BIND operation, it may be useful to > analyze if they do not take too long. > > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dpal at redhat.com Wed Sep 4 12:32:32 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Sep 2013 08:32:32 -0400 Subject: [Freeipa-users] IPA Load Problems? In-Reply-To: <52822038-F299-46D2-8BD1-D45DA0D99EA6@digitalreasoning.com> References: <70FAFDC6-AC64-4B42-AB75-ABECDE7B350E@digitalreasoning.com> <521CDE4F.50307@redhat.com> <3D595AA0-9168-45C3-AB29-602567EAC5E4@digitalreasoning.com> <521D0FCE.3080800@redhat.com> <3B676396-41CB-40BA-A7D2-0E1CB8800C30@digitalreasoning.com> <521E1A03.1060904@redhat.com> <5220F587.6000808@redhat.com> <414556BA-3DDF-4259-AC40-D0778BF474DC@digitalreasoning.com> <5220FFC2.90207@redhat.com> <2C999C19-A8A2-435E-B54F-E6F9F7F964AF@digitalreasoning.com> <52210523.7030403@redhat.com> <6D4BA0C3-5003-46AD-842A-E95194B865E2@digitalreasonin! ! g.com> <522108C9.7030506@redhat.com> <5226E4E9.8090903@r! edhat.com> <52822038-F299-46D2-8BD1-D45DA0D99EA6@digitalreasoning.com> Message-ID: <52272860.7040601@redhat.com> On 09/04/2013 08:01 AM, John Moyer wrote: > Martin, > > I apologize there was a large offline conversation between Rich and > myself. Rich was kind enough to help me through some of my issues. > We did a lot more tests and poking and prodding. We discovered that > IPA is not as efficient when dealing with large number of connections. > Most of my load inefficiently reconnect to IPA over and over and over > and though LDAP can deal with this fairly efficiently, IPA apparently > drops to it's knees. > > A ticket was opened to addressed this issue. > > https://fedorahosted.org/freeipa/ticket/3892 > > Thank you for reporting this ticket. Martin is investigating it and trying to see what is the cause. The information mentioned above is missing from the the ticket, thus the question. So to summarize: you identified that the cause of the performance issue is that JIRA makes a lot of parallel connections to LDAP server and IPA is slow processing bind operations thus clients that do a lot of connections can experience a low performance. Martin, I wonder if we can have a test that would just do a lot of binds. There are a lot of plugins and one of the recent ones is the OTP one. I wonder if we do too much during bind when OTP is not enabled (by default). > Thanks, > _____________________________________________________ > John Moyer > Director, IT Operations > *Digital Reasoning Systems, Inc.* > John.Moyer at digitalreasoning.com > Office:703.678.2311 > Mobile:240.460.0023 > Fax:703.678.2312 > www.digitalreasoning.com > > On Sep 4, 2013, at 3:44 AM, Martin Kosek > wrote: > >> On 08/30/2013 11:08 PM, John Moyer wrote: >>> Well IPA has machine entries on some test clusters that I'm rolling IPA >>> out on (20 machines maybe) but the user base is the same (about 80 ~ >>> 100) >>> accounts with maybe 40 to 50 groups? >>> >>> I've stood up a clone of the jira server along with IPA. I cleared my >>> logs and then did the sync and ran the log analyzer on it. These stats >>> are pretty much ONLY for that jira sync I don't have any other >>> connections >>> pointed to it. >>> >>> >>> Start of Log: 30/Aug/2013:15:57:13 End of Log: >>> 30/Aug/2013:16:01:14 >>> >>> Processed Log Time: Hours, 4 Minutes, 1 Seconds >>> >>> Restarts: 1 Total Connections: 824 SSL >>> Connections: 824 Peak Concurrent Connections: 6 Total >>> Operations: 1806 Total Results: 1805 Overall >>> Performance: 99.9% >>> >>> Searches: 968 (4.02/sec) (241.00/min) >>> Modifications: 5 (0.02/sec) (1.24/min) Adds: >>> 0 (0.00/sec) (0.00/min) Deletes: 0 >>> (0.00/sec) (0.00/min) Mod RDNs: 0 >>> (0.00/sec) >>> (0.00/min) Compares: 0 (0.00/sec) >>> (0.00/min) Binds: 833 (3.46/sec) >>> (207.39/min) >>> >>> Proxied Auth Operations: 0 Persistent Searches: 1 Internal >>> Operations: 0 Entry Operations: 0 Extended >>> Operations: 0 Abandoned Requests: 0 Smart Referrals >>> Received: 0 >>> >>> VLV Operations: 0 VLV Unindexed Searches: 0 SORT >>> Operations: 0 >>> >>> Entire Search Base Queries: 0 Unindexed Searches: 1 >>> >> >> This looks like a promising way to find out the reason, thanks John. >> However, >> I see just one unindexed search. Is the access log complete? >> Previously I see >> that the sync takes 900 seconds/15 minutes, but there is only 4 >> minutes the >> access log. Note that it it may take some time until the log is dumped. >> >> I think it would be also useful to run the analyzer with "-ula" flags >> as Rob >> suggested earlier to find out the unindexed searches (if any). >> >> What I find interesting is that JIRA does a lot of LDAP BINDs. Can the >> problem be in longer BINDs than with than expected (compared to for >> example >> plain LDAP servers)? Performance-wise, it would be I think better if JIRA >> does just one BIND and run all the LDAP searches the established >> connection. >> But I do not know if it can be configured this way. >> >> Rich, Rob, I am wondering if the slow up is not really caused by the >> binds, >> we have several DS plugins tied to the BIND operation, it may be >> useful to >> analyze if they do not take too long. >> >> Martin > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.moyer at digitalreasoning.com Wed Sep 4 12:53:29 2013 From: john.moyer at digitalreasoning.com (John Moyer) Date: Wed, 4 Sep 2013 08:53:29 -0400 Subject: [Freeipa-users] IPA Load Problems? In-Reply-To: <52272860.7040601@redhat.com> References: <70FAFDC6-AC64-4B42-AB75-ABECDE7B350E@digitalreasoning.com> <521CDE4F.50307@redhat.com> <3D595AA0-9168-45C3-AB29-602567EAC5E4@digitalreasoning.com> <521D0FCE.3080800@redhat.com> <3B676396-41CB-40BA-A7D2-0E1CB8800C30@digitalreasoning.com> <521E1A03.1060904@redhat.com> <5220F587.6000808@redhat.com> <414556BA-3DDF-4259-AC40-D0778BF474DC@digitalreasoning.com> <5220FFC2.90207@redhat.com> <2C999C19-A8A2-435E-B54F-E6F9F7F964AF@digitalreasoning.com> <52210523.7030403@redhat.com> <6D4BA0C3-5003-46AD-842A-E95194B865E2@digitalreasonin! ! g.com> <522108C9.7030506@redhat.com> <5226E4E9.8090903@r! edhat.com> <52822038-F299-46D2-8BD1-D45DA0D99EA6@digitalreasoning.com> <52272860.70406! 01@redhat.com> Message-ID: That summary is correct. The only thing I would add is that other applications could easily bring the IPA server to it's knees as well. Our artifact server also did many connections per sec when used, and one person doing a build could bring IPA to it's knees as well. Also, not only would IPA be maxed at 100%, but users would complain that their builds were taking longer than normal (with or without the JIRA sync going, however, it was obviously worse when JIRA was running). Also, my IPA server was a larger/faster server than my LDAP server. So my LDAP server would run circles around IPA even though it was on a smaller machine. LDAP would run at about 10% maybe 15% CPU when the JIRA sync ran. IF you need any other information let me know. Thanks, _____________________________________________________ John Moyer Director, IT Operations On Sep 4, 2013, at 8:32 AM, Dmitri Pal wrote: > On 09/04/2013 08:01 AM, John Moyer wrote: >> >> Martin, >> >> I apologize there was a large offline conversation between Rich and myself. Rich was kind enough to help me through some of my issues. We did a lot more tests and poking and prodding. We discovered that IPA is not as efficient when dealing with large number of connections. Most of my load inefficiently reconnect to IPA over and over and over and though LDAP can deal with this fairly efficiently, IPA apparently drops to it's knees. >> >> A ticket was opened to addressed this issue. >> >> https://fedorahosted.org/freeipa/ticket/3892 >> >> > > Thank you for reporting this ticket. > Martin is investigating it and trying to see what is the cause. The information mentioned above is missing from the the ticket, thus the question. > > So to summarize: you identified that the cause of the performance issue is that JIRA makes a lot of parallel connections to LDAP server and IPA is slow processing bind operations thus clients that do a lot of connections can experience a low performance. > > Martin, I wonder if we can have a test that would just do a lot of binds. > There are a lot of plugins and one of the recent ones is the OTP one. I wonder if we do too much during bind when OTP is not enabled (by default). > >> Thanks, >> _____________________________________________________ >> John Moyer >> Director, IT Operations >> Digital Reasoning Systems, Inc. >> John.Moyer at digitalreasoning.com >> Office: 703.678.2311 >> Mobile: 240.460.0023 >> Fax: 703.678.2312 >> www.digitalreasoning.com >> >> On Sep 4, 2013, at 3:44 AM, Martin Kosek wrote: >> >>> On 08/30/2013 11:08 PM, John Moyer wrote: >>>> Well IPA has machine entries on some test clusters that I'm rolling IPA >>>> out on (20 machines maybe) but the user base is the same (about 80 ~ 100) >>>> accounts with maybe 40 to 50 groups? >>>> >>>> I've stood up a clone of the jira server along with IPA. I cleared my >>>> logs and then did the sync and ran the log analyzer on it. These stats >>>> are pretty much ONLY for that jira sync I don't have any other connections >>>> pointed to it. >>>> >>>> >>>> Start of Log: 30/Aug/2013:15:57:13 End of Log: >>>> 30/Aug/2013:16:01:14 >>>> >>>> Processed Log Time: Hours, 4 Minutes, 1 Seconds >>>> >>>> Restarts: 1 Total Connections: 824 SSL >>>> Connections: 824 Peak Concurrent Connections: 6 Total >>>> Operations: 1806 Total Results: 1805 Overall >>>> Performance: 99.9% >>>> >>>> Searches: 968 (4.02/sec) (241.00/min) >>>> Modifications: 5 (0.02/sec) (1.24/min) Adds: >>>> 0 (0.00/sec) (0.00/min) Deletes: 0 >>>> (0.00/sec) (0.00/min) Mod RDNs: 0 (0.00/sec) >>>> (0.00/min) Compares: 0 (0.00/sec) >>>> (0.00/min) Binds: 833 (3.46/sec) >>>> (207.39/min) >>>> >>>> Proxied Auth Operations: 0 Persistent Searches: 1 Internal >>>> Operations: 0 Entry Operations: 0 Extended >>>> Operations: 0 Abandoned Requests: 0 Smart Referrals >>>> Received: 0 >>>> >>>> VLV Operations: 0 VLV Unindexed Searches: 0 SORT >>>> Operations: 0 >>>> >>>> Entire Search Base Queries: 0 Unindexed Searches: 1 >>>> >>> >>> This looks like a promising way to find out the reason, thanks John. However, >>> I see just one unindexed search. Is the access log complete? Previously I see >>> that the sync takes 900 seconds/15 minutes, but there is only 4 minutes the >>> access log. Note that it it may take some time until the log is dumped. >>> >>> I think it would be also useful to run the analyzer with "-ula" flags as Rob >>> suggested earlier to find out the unindexed searches (if any). >>> >>> What I find interesting is that JIRA does a lot of LDAP BINDs. Can the >>> problem be in longer BINDs than with than expected (compared to for example >>> plain LDAP servers)? Performance-wise, it would be I think better if JIRA >>> does just one BIND and run all the LDAP searches the established connection. >>> But I do not know if it can be configured this way. >>> >>> Rich, Rob, I am wondering if the slow up is not really caused by the binds, >>> we have several DS plugins tied to the BIND operation, it may be useful to >>> analyze if they do not take too long. >>> >>> Martin >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bret.wortman at damascusgrp.com Wed Sep 4 13:04:14 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 4 Sep 2013 09:04:14 -0400 Subject: [Freeipa-users] Exporting data? Message-ID: What's the right venue for making a suggestion? In particular, I'd like to toss out there that it would be really nice to be able to export, at a minimum, DNS and user data from IPA in the form of a zone file and a passwd/shadow file pair. I realize there might be security implications to the latter, and masking out passwords might be advisiable. And there's no easy way, necessarily, to get out sudo information. But having DNS and user details would at least permit a sysadmin having major issues (like I have been for the past two weeks) to get up and running in some form, using puppet or some other tool to distribute flat files with named running against a static zone file, or even to migrate off IPA if absolutely necessary. * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Sep 4 13:12:59 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Sep 2013 09:12:59 -0400 Subject: [Freeipa-users] IPA Load Problems? In-Reply-To: References: <70FAFDC6-AC64-4B42-AB75-ABECDE7B350E@digitalreasoning.com> <3D595AA0-9168-45C3-AB29-602567EAC5E4@digitalreasoning.com> <521D0FCE.3080800@redhat.com> <3B676396-41CB-40BA-A7D2-0E1CB8800C30@digitalreasoning.com> <521E1A03.1060904@redhat.com> <5220F587.6000808@redhat.com> <414556BA-3DDF-4259-AC40-D0778BF474DC@digitalreasoning.com> <5220FFC2.90207@redhat.com> <2C999C19-A8A2-435E-B54F-E6F9F7F964AF@digitalreasoning.com> <52210523.7030403@redhat.com> <6D4BA0C3-5003-46AD-842A-E95194B865E2@digitalreasonin! ! g.com> <522108C9.7030506@redhat.com> <5226E4E9.8090903@r! edhat.com> <52822038-F299-46D2-8BD1-D45DA0D99EA6@digitalreasoning.com> <52272860.70406! 01@redhat.com> Message-ID: <522731DB.4000205@redhat.com> On 09/04/2013 08:53 AM, John Moyer wrote: > That summary is correct. The only thing I would add is that other > applications could easily bring the IPA server to it's knees as well. Yes this is what I meant. It is not only JIRA. Any client that creates a lot of connections can cause problems. > Our artifact server also did many connections per sec when used, and > one person doing a build could bring IPA to it's knees as well. Also, > not only would IPA be maxed at 100%, but users would complain that > their builds were taking longer than normal (with or without the JIRA > sync going, however, it was obviously worse when JIRA was running). > > Also, my IPA server was a larger/faster server than my LDAP server. > So my LDAP server would run circles around IPA even though it was on a > smaller machine. LDAP would run at about 10% maybe 15% CPU when the > JIRA sync ran. > > IF you need any other information let me know. No this seems to be enough. Thank you. Would you be willing to test a fix if one is provided? Thanks Dmitri > > Thanks, > _____________________________________________________ > John Moyer > Director, IT Operations > > > On Sep 4, 2013, at 8:32 AM, Dmitri Pal > wrote: > >> On 09/04/2013 08:01 AM, John Moyer wrote: >>> Martin, >>> >>> I apologize there was a large offline conversation between Rich and >>> myself. Rich was kind enough to help me through some of my issues. >>> We did a lot more tests and poking and prodding. We discovered >>> that IPA is not as efficient when dealing with large number of >>> connections. Most of my load inefficiently reconnect to IPA over >>> and over and over and though LDAP can deal with this fairly >>> efficiently, IPA apparently drops to it's knees. >>> >>> A ticket was opened to addressed this issue. >>> >>> https://fedorahosted.org/freeipa/ticket/3892 >>> >>> >> >> Thank you for reporting this ticket. >> Martin is investigating it and trying to see what is the cause. The >> information mentioned above is missing from the the ticket, thus the >> question. >> >> So to summarize: you identified that the cause of the performance >> issue is that JIRA makes a lot of parallel connections to LDAP server >> and IPA is slow processing bind operations thus clients that do a lot >> of connections can experience a low performance. >> >> Martin, I wonder if we can have a test that would just do a lot of binds. >> There are a lot of plugins and one of the recent ones is the OTP one. >> I wonder if we do too much during bind when OTP is not enabled (by >> default). >> >>> Thanks, >>> _____________________________________________________ >>> John Moyer >>> Director, IT Operations >>> *Digital Reasoning Systems, Inc.* >>> John.Moyer at digitalreasoning.com >>> Office:703.678.2311 >>> Mobile:240.460.0023 >>> Fax:703.678.2312 >>> www.digitalreasoning.com >>> >>> On Sep 4, 2013, at 3:44 AM, Martin Kosek >> > wrote: >>> >>>> On 08/30/2013 11:08 PM, John Moyer wrote: >>>>> Well IPA has machine entries on some test clusters that I'm >>>>> rolling IPA >>>>> out on (20 machines maybe) but the user base is the same (about 80 >>>>> ~ 100) >>>>> accounts with maybe 40 to 50 groups? >>>>> >>>>> I've stood up a clone of the jira server along with IPA. I >>>>> cleared my >>>>> logs and then did the sync and ran the log analyzer on it. These >>>>> stats >>>>> are pretty much ONLY for that jira sync I don't have any other >>>>> connections >>>>> pointed to it. >>>>> >>>>> >>>>> Start of Log: 30/Aug/2013:15:57:13 End of Log: >>>>> 30/Aug/2013:16:01:14 >>>>> >>>>> Processed Log Time: Hours, 4 Minutes, 1 Seconds >>>>> >>>>> Restarts: 1 Total Connections: 824 SSL >>>>> Connections: 824 Peak Concurrent Connections: 6 Total >>>>> Operations: 1806 Total Results: 1805 >>>>> Overall >>>>> Performance: 99.9% >>>>> >>>>> Searches: 968 (4.02/sec) (241.00/min) >>>>> Modifications: 5 (0.02/sec) (1.24/min) Adds: >>>>> 0 (0.00/sec) (0.00/min) Deletes: 0 >>>>> (0.00/sec) (0.00/min) Mod RDNs: 0 >>>>> (0.00/sec) >>>>> (0.00/min) Compares: 0 (0.00/sec) >>>>> (0.00/min) Binds: 833 (3.46/sec) >>>>> (207.39/min) >>>>> >>>>> Proxied Auth Operations: 0 Persistent Searches: 1 >>>>> Internal >>>>> Operations: 0 Entry Operations: 0 Extended >>>>> Operations: 0 Abandoned Requests: 0 Smart Referrals >>>>> Received: 0 >>>>> >>>>> VLV Operations: 0 VLV Unindexed Searches: 0 SORT >>>>> Operations: 0 >>>>> >>>>> Entire Search Base Queries: 0 Unindexed Searches: 1 >>>>> >>>> >>>> This looks like a promising way to find out the reason, thanks >>>> John. However, >>>> I see just one unindexed search. Is the access log complete? >>>> Previously I see >>>> that the sync takes 900 seconds/15 minutes, but there is only 4 >>>> minutes the >>>> access log. Note that it it may take some time until the log is dumped. >>>> >>>> I think it would be also useful to run the analyzer with "-ula" >>>> flags as Rob >>>> suggested earlier to find out the unindexed searches (if any). >>>> >>>> What I find interesting is that JIRA does a lot of LDAP BINDs. Can the >>>> problem be in longer BINDs than with than expected (compared to for >>>> example >>>> plain LDAP servers)? Performance-wise, it would be I think better >>>> if JIRA >>>> does just one BIND and run all the LDAP searches the established >>>> connection. >>>> But I do not know if it can be configured this way. >>>> >>>> Rich, Rob, I am wondering if the slow up is not really caused by >>>> the binds, >>>> we have several DS plugins tied to the BIND operation, it may be >>>> useful to >>>> analyze if they do not take too long. >>>> >>>> Martin >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Sep 4 13:19:00 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 4 Sep 2013 16:19:00 +0300 Subject: [Freeipa-users] IPA Load Problems? In-Reply-To: <52272860.7040601@redhat.com> References: <414556BA-3DDF-4259-AC40-D0778BF474DC@digitalreasoning.com> <5220FFC2.90207@redhat.com> <2C999C19-A8A2-435E-B54F-E6F9F7F964AF@digitalreasoning.com> <52210523.7030403@redhat.com> <522108C9.7030506@redhat.com> <5226E4E9.8090903@r!edhat.com> <52822038-F299-46D2-8BD1-D45DA0D99EA6@digitalreasoning.com> <52272860.7040601@redhat.com> Message-ID: <20130904131900.GI21212@redhat.com> On Wed, 04 Sep 2013, Dmitri Pal wrote: >On 09/04/2013 08:01 AM, John Moyer wrote: >> Martin, >> >> I apologize there was a large offline conversation between Rich and >> myself. Rich was kind enough to help me through some of my issues. >> We did a lot more tests and poking and prodding. We discovered that >> IPA is not as efficient when dealing with large number of connections. >> Most of my load inefficiently reconnect to IPA over and over and over >> and though LDAP can deal with this fairly efficiently, IPA apparently >> drops to it's knees. >> >> A ticket was opened to addressed this issue. >> >> https://fedorahosted.org/freeipa/ticket/3892 >> >> > >Thank you for reporting this ticket. >Martin is investigating it and trying to see what is the cause. The >information mentioned above is missing from the the ticket, thus the >question. > >So to summarize: you identified that the cause of the performance issue >is that JIRA makes a lot of parallel connections to LDAP server and IPA >is slow processing bind operations thus clients that do a lot of >connections can experience a low performance. > >Martin, I wonder if we can have a test that would just do a lot of binds. >There are a lot of plugins and one of the recent ones is the OTP one. I >wonder if we do too much during bind when OTP is not enabled (by default). This should be unrelated to OTP work as John is using CentOS with older FreeIPA build, equivalent to what is in RHEL 6.4. -- / Alexander Bokovoy From john.moyer at digitalreasoning.com Wed Sep 4 13:20:01 2013 From: john.moyer at digitalreasoning.com (John Moyer) Date: Wed, 4 Sep 2013 09:20:01 -0400 Subject: [Freeipa-users] IPA Load Problems? In-Reply-To: <522731DB.4000205@redhat.com> References: <70FAFDC6-AC64-4B42-AB75-ABECDE7B350E@digitalreasoning.com> <3D595AA0-9168-45C3-AB29-602567EAC5E4@digitalreasoning.com> <521D0FCE.3080800@redhat.com> <3B676396-41CB-40BA-A7D2-0E1CB8800C30@digitalreasoning.com> <521E1A03.1060904@redhat.com> <5220F587.6000808@redhat.com> <414556BA-3DDF-4259-AC40-D0778BF474DC@digitalreasoning.com> <5220FFC2.90207@redhat.com> <2C999C19-A8A2-435E-B54F-E6F9F7F964AF@digitalreasoning.com> <52210523.7030403@redhat.com> <6D4BA0C3-5003-46AD-842A-E95194B865E2@digitalreasonin! ! g.com> <522108C9.7030506@redhat.com> <5226E4E9.8090903@r! edhat.com> <52822038-F299-46D2-8BD1-D45DA0D99EA6@digitalreasoning.com> <52272860.70406! 01@redhat.com> <522731DB.4! 000205@redhat.com> Message-ID: <14ADEE78-AEAA-4900-94D3-C06447FDC795@digitalreasoning.com> Sure, just let me know what needs to be run/applied. I've already rolled back to LDAP, so if the fix looks like it works I can then roll it out again. Thanks, _____________________________________________________ John Moyer Director, IT Operations On Sep 4, 2013, at 9:12 AM, Dmitri Pal wrote: > On 09/04/2013 08:53 AM, John Moyer wrote: >> >> That summary is correct. The only thing I would add is that other applications could easily bring the IPA server to it's knees as well. > > Yes this is what I meant. It is not only JIRA. Any client that creates a lot of connections can cause problems. > >> Our artifact server also did many connections per sec when used, and one person doing a build could bring IPA to it's knees as well. Also, not only would IPA be maxed at 100%, but users would complain that their builds were taking longer than normal (with or without the JIRA sync going, however, it was obviously worse when JIRA was running). >> >> Also, my IPA server was a larger/faster server than my LDAP server. So my LDAP server would run circles around IPA even though it was on a smaller machine. LDAP would run at about 10% maybe 15% CPU when the JIRA sync ran. >> >> IF you need any other information let me know. > > No this seems to be enough. > Thank you. > > Would you be willing to test a fix if one is provided? > > Thanks > Dmitri > >> >> Thanks, >> _____________________________________________________ >> John Moyer >> Director, IT Operations >> >> >> On Sep 4, 2013, at 8:32 AM, Dmitri Pal wrote: >> >>> On 09/04/2013 08:01 AM, John Moyer wrote: >>>> >>>> Martin, >>>> >>>> I apologize there was a large offline conversation between Rich and myself. Rich was kind enough to help me through some of my issues. We did a lot more tests and poking and prodding. We discovered that IPA is not as efficient when dealing with large number of connections. Most of my load inefficiently reconnect to IPA over and over and over and though LDAP can deal with this fairly efficiently, IPA apparently drops to it's knees. >>>> >>>> A ticket was opened to addressed this issue. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3892 >>>> >>>> >>> >>> Thank you for reporting this ticket. >>> Martin is investigating it and trying to see what is the cause. The information mentioned above is missing from the the ticket, thus the question. >>> >>> So to summarize: you identified that the cause of the performance issue is that JIRA makes a lot of parallel connections to LDAP server and IPA is slow processing bind operations thus clients that do a lot of connections can experience a low performance. >>> >>> Martin, I wonder if we can have a test that would just do a lot of binds. >>> There are a lot of plugins and one of the recent ones is the OTP one. I wonder if we do too much during bind when OTP is not enabled (by default). >>> >>>> Thanks, >>>> _____________________________________________________ >>>> John Moyer >>>> Director, IT Operations >>>> Digital Reasoning Systems, Inc. >>>> John.Moyer at digitalreasoning.com >>>> Office: 703.678.2311 >>>> Mobile: 240.460.0023 >>>> Fax: 703.678.2312 >>>> www.digitalreasoning.com >>>> >>>> On Sep 4, 2013, at 3:44 AM, Martin Kosek wrote: >>>> >>>>> On 08/30/2013 11:08 PM, John Moyer wrote: >>>>>> Well IPA has machine entries on some test clusters that I'm rolling IPA >>>>>> out on (20 machines maybe) but the user base is the same (about 80 ~ 100) >>>>>> accounts with maybe 40 to 50 groups? >>>>>> >>>>>> I've stood up a clone of the jira server along with IPA. I cleared my >>>>>> logs and then did the sync and ran the log analyzer on it. These stats >>>>>> are pretty much ONLY for that jira sync I don't have any other connections >>>>>> pointed to it. >>>>>> >>>>>> >>>>>> Start of Log: 30/Aug/2013:15:57:13 End of Log: >>>>>> 30/Aug/2013:16:01:14 >>>>>> >>>>>> Processed Log Time: Hours, 4 Minutes, 1 Seconds >>>>>> >>>>>> Restarts: 1 Total Connections: 824 SSL >>>>>> Connections: 824 Peak Concurrent Connections: 6 Total >>>>>> Operations: 1806 Total Results: 1805 Overall >>>>>> Performance: 99.9% >>>>>> >>>>>> Searches: 968 (4.02/sec) (241.00/min) >>>>>> Modifications: 5 (0.02/sec) (1.24/min) Adds: >>>>>> 0 (0.00/sec) (0.00/min) Deletes: 0 >>>>>> (0.00/sec) (0.00/min) Mod RDNs: 0 (0.00/sec) >>>>>> (0.00/min) Compares: 0 (0.00/sec) >>>>>> (0.00/min) Binds: 833 (3.46/sec) >>>>>> (207.39/min) >>>>>> >>>>>> Proxied Auth Operations: 0 Persistent Searches: 1 Internal >>>>>> Operations: 0 Entry Operations: 0 Extended >>>>>> Operations: 0 Abandoned Requests: 0 Smart Referrals >>>>>> Received: 0 >>>>>> >>>>>> VLV Operations: 0 VLV Unindexed Searches: 0 SORT >>>>>> Operations: 0 >>>>>> >>>>>> Entire Search Base Queries: 0 Unindexed Searches: 1 >>>>>> >>>>> >>>>> This looks like a promising way to find out the reason, thanks John. However, >>>>> I see just one unindexed search. Is the access log complete? Previously I see >>>>> that the sync takes 900 seconds/15 minutes, but there is only 4 minutes the >>>>> access log. Note that it it may take some time until the log is dumped. >>>>> >>>>> I think it would be also useful to run the analyzer with "-ula" flags as Rob >>>>> suggested earlier to find out the unindexed searches (if any). >>>>> >>>>> What I find interesting is that JIRA does a lot of LDAP BINDs. Can the >>>>> problem be in longer BINDs than with than expected (compared to for example >>>>> plain LDAP servers)? Performance-wise, it would be I think better if JIRA >>>>> does just one BIND and run all the LDAP searches the established connection. >>>>> But I do not know if it can be configured this way. >>>>> >>>>> Rich, Rob, I am wondering if the slow up is not really caused by the binds, >>>>> we have several DS plugins tied to the BIND operation, it may be useful to >>>>> analyze if they do not take too long. >>>>> >>>>> Martin >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager for IdM portfolio >>> Red Hat Inc. >>> >>> >>> ------------------------------- >>> Looking to carve out IT costs? >>> www.redhat.com/carveoutcosts/ >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pspacek at redhat.com Wed Sep 4 13:26:31 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 04 Sep 2013 15:26:31 +0200 Subject: [Freeipa-users] Exporting data? In-Reply-To: References: Message-ID: <52273507.8020606@redhat.com> On 4.9.2013 15:04, Bret Wortman wrote: > What's the right venue for making a suggestion? In particular, I'd like to > toss out there that it would be really nice to be able to export, at a > minimum, DNS and user data from IPA in the form of a zone file and a > passwd/shadow file pair. > > I realize there might be security implications to the latter, and masking > out passwords might be advisiable. And there's no easy way, necessarily, to > get out sudo information. But having DNS and user details would at least > permit a sysadmin having major issues (like I have been for the past two > weeks) to get up and running in some form, using puppet or some other tool > to distribute flat files with named running against a static zone file, or > even to migrate off IPA if absolutely necessary. Hello, for DNS you can use normal zone transfer. Just configure IPA zone to allow zone transfer to an IP address (localhost means 'localy to IPA server') and use standard DNS tools, e.g. dig: $ ipa dnszone-mod example.com --allow-transfer='localhost;' $ dig +onesoa -t AXFR example.com > /root/example.com.db That is all you need for DNS, you have the standard zone file. I believe that you can use SSSD (with enumeration enabled) to run "getent passwd > /root/passwd.bck". I have no idea how it works with shadow map/password. Try to ask sssd-users at lists.fedorahosted.org. -- Petr^2 Spacek From bret.wortman at damascusgrp.com Wed Sep 4 13:36:15 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 4 Sep 2013 09:36:15 -0400 Subject: [Freeipa-users] Exporting data? In-Reply-To: <52273507.8020606@redhat.com> References: <52273507.8020606@redhat.com> Message-ID: I guess what I was looking for was something really easy -- like a pushbutton in the UI. I've got 20+ zones, so even doing this means scripting to keep from missing something. * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Wed, Sep 4, 2013 at 9:26 AM, Petr Spacek wrote: > On 4.9.2013 15:04, Bret Wortman wrote: > >> What's the right venue for making a suggestion? In particular, I'd like to >> toss out there that it would be really nice to be able to export, at a >> minimum, DNS and user data from IPA in the form of a zone file and a >> passwd/shadow file pair. >> >> I realize there might be security implications to the latter, and masking >> out passwords might be advisiable. And there's no easy way, necessarily, >> to >> get out sudo information. But having DNS and user details would at least >> permit a sysadmin having major issues (like I have been for the past two >> weeks) to get up and running in some form, using puppet or some other tool >> to distribute flat files with named running against a static zone file, or >> even to migrate off IPA if absolutely necessary. >> > > Hello, > > for DNS you can use normal zone transfer. Just configure IPA zone to allow > zone transfer to an IP address (localhost means 'localy to IPA server') and > use standard DNS tools, e.g. dig: > > $ ipa dnszone-mod example.com --allow-transfer='localhost;' > $ dig +onesoa -t AXFR example.com > /root/example.com.db > > That is all you need for DNS, you have the standard zone file. > > > I believe that you can use SSSD (with enumeration enabled) to run "getent > passwd > /root/passwd.bck". I have no idea how it works with shadow > map/password. Try to ask sssd-users at lists.fedorahosted.**org > . > > -- > Petr^2 Spacek > > ______________________________**_________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/**mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Sep 4 13:40:10 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Sep 2013 09:40:10 -0400 Subject: [Freeipa-users] Exporting data? In-Reply-To: <52273507.8020606@redhat.com> References: <52273507.8020606@redhat.com> Message-ID: <5227383A.2090207@redhat.com> On 09/04/2013 09:26 AM, Petr Spacek wrote: > On 4.9.2013 15:04, Bret Wortman wrote: >> What's the right venue for making a suggestion? In particular, I'd >> like to >> toss out there that it would be really nice to be able to export, at a >> minimum, DNS and user data from IPA in the form of a zone file and a >> passwd/shadow file pair. >> >> I realize there might be security implications to the latter, and >> masking >> out passwords might be advisiable. And there's no easy way, >> necessarily, to >> get out sudo information. But having DNS and user details would at least >> permit a sysadmin having major issues (like I have been for the past two >> weeks) to get up and running in some form, using puppet or some other >> tool >> to distribute flat files with named running against a static zone >> file, or >> even to migrate off IPA if absolutely necessary. > > Hello, > > for DNS you can use normal zone transfer. Just configure IPA zone to > allow zone transfer to an IP address (localhost means 'localy to IPA > server') and use standard DNS tools, e.g. dig: > > $ ipa dnszone-mod example.com --allow-transfer='localhost;' > $ dig +onesoa -t AXFR example.com > /root/example.com.db > > That is all you need for DNS, you have the standard zone file. > > > I believe that you can use SSSD (with enumeration enabled) to run > "getent passwd > /root/passwd.bck". I have no idea how it works with > shadow map/password. Try to ask sssd-users at lists.fedorahosted.org. > And to add to it: IPA does not keep password in clear or the hashes that are used in passwd and shadow files for security reasons so it can't generate these files as you suggest. It is unclear what the problems are that you are facing and what made you get back to local files. I agree with Petr that SSSD has a lot of bells and whistles to make your client experience smooth and help you recover from any server side problems you might have. But may be we are missing something and there is something we can do. If you can describe the problem you are facing we might be able to suggest a solution. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Wed Sep 4 13:51:31 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 04 Sep 2013 15:51:31 +0200 Subject: [Freeipa-users] IPA Load Problems? In-Reply-To: <52822038-F299-46D2-8BD1-D45DA0D99EA6@digitalreasoning.com> References: <70FAFDC6-AC64-4B42-AB75-ABECDE7B350E@digitalreasoning.com> <521CDE4F.50307@redhat.com> <3D595AA0-9168-45C3-AB29-602567EAC5E4@digitalreasoning.com> <521D0FCE.3080800@redhat.com> <3B676396-41CB-40BA-A7D2-0E1CB8800C30@digitalreasoning.com> <521E1A03.1060904@redhat.com> <5220F587.6000808@redhat.com> <414556BA-3DDF-4259-AC40-D0778BF474DC@digitalreasoning.com> <5220FFC2.90207@redhat.com> <2C999C19-A8A2-435E-B54F-E6F9F7F964AF@digitalreasoning.com> <52210523.7030403@redhat.com> <6D4BA0C3-5003-46AD-842A-E95194B865E2@digitalreasonin! ! g.com> <522108C9.7030506@redhat.com> <5226E4E9.8090903@r! edhat.com> <52822038-F299-46D2-8BD1-D45DA0D99EA6@digitalreasoning.com> Message-ID: <52273AE3.3080806@redhat.com> Ah, ok. One of the reasons why I was poking to this thread is exactly this ticket. It does not contain much information _what exactly_ is making IPA performance poor - whether it is missing indices (which ones?) or some issue in IPA plugins during binds, etc. Without more information, we do not know what to fix, what to improve. Martin On 09/04/2013 02:01 PM, John Moyer wrote: > Martin, > > I apologize there was a large offline conversation between Rich and > myself. Rich was kind enough to help me through some of my issues. We > did a lot more tests and poking and prodding. We discovered that IPA is > not as efficient when dealing with large number of connections. Most of > my load inefficiently reconnect to IPA over and over and over and though > LDAP can deal with this fairly efficiently, IPA apparently drops to it's > knees. > > A ticket was opened to addressed this issue. > > https://fedorahosted.org/freeipa/ticket/3892 > > > Thanks, _____________________________________________________ John Moyer > Director, IT Operations Digital Reasoning Systems, Inc. > John.Moyer at digitalreasoning.com Office: 703.678.2311 Mobile: 240.460.0023 > Fax: 703.678.2312 www.digitalreasoning.com > > On Sep 4, 2013, at 3:44 AM, Martin Kosek wrote: > >> On 08/30/2013 11:08 PM, John Moyer wrote: >>> Well IPA has machine entries on some test clusters that I'm rolling >>> IPA out on (20 machines maybe) but the user base is the same (about 80 >>> ~ 100) accounts with maybe 40 to 50 groups? >>> >>> I've stood up a clone of the jira server along with IPA. I cleared >>> my logs and then did the sync and ran the log analyzer on it. These >>> stats are pretty much ONLY for that jira sync I don't have any other >>> connections pointed to it. >>> >>> >>> Start of Log: 30/Aug/2013:15:57:13 End of Log: >>> 30/Aug/2013:16:01:14 >>> >>> Processed Log Time: Hours, 4 Minutes, 1 Seconds >>> >>> Restarts: 1 Total Connections: 824 SSL >>> Connections: 824 Peak Concurrent Connections: 6 Total >>> Operations: 1806 Total Results: 1805 >>> Overall Performance: 99.9% >>> >>> Searches: 968 (4.02/sec) (241.00/min) >>> Modifications: 5 (0.02/sec) (1.24/min) Adds: >>> 0 (0.00/sec) (0.00/min) Deletes: 0 >>> (0.00/sec) (0.00/min) Mod RDNs: 0 >>> (0.00/sec) (0.00/min) Compares: 0 >>> (0.00/sec) (0.00/min) Binds: 833 >>> (3.46/sec) (207.39/min) >>> >>> Proxied Auth Operations: 0 Persistent Searches: 1 >>> Internal Operations: 0 Entry Operations: 0 >>> Extended Operations: 0 Abandoned Requests: 0 Smart >>> Referrals Received: 0 >>> >>> VLV Operations: 0 VLV Unindexed Searches: 0 SORT >>> Operations: 0 >>> >>> Entire Search Base Queries: 0 Unindexed Searches: 1 >>> >> >> This looks like a promising way to find out the reason, thanks John. >> However, I see just one unindexed search. Is the access log complete? >> Previously I see that the sync takes 900 seconds/15 minutes, but there >> is only 4 minutes the access log. Note that it it may take some time >> until the log is dumped. >> >> I think it would be also useful to run the analyzer with "-ula" flags as >> Rob suggested earlier to find out the unindexed searches (if any). >> >> What I find interesting is that JIRA does a lot of LDAP BINDs. Can the >> problem be in longer BINDs than with than expected (compared to for >> example plain LDAP servers)? Performance-wise, it would be I think >> better if JIRA does just one BIND and run all the LDAP searches the >> established connection. But I do not know if it can be configured this >> way. >> >> Rich, Rob, I am wondering if the slow up is not really caused by the >> binds, we have several DS plugins tied to the BIND operation, it may be >> useful to analyze if they do not take too long. >> >> Martin > > From bret.wortman at damascusgrp.com Wed Sep 4 13:51:33 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 4 Sep 2013 09:51:33 -0400 Subject: [Freeipa-users] Exporting data? In-Reply-To: <5227383A.2090207@redhat.com> References: <52273507.8020606@redhat.com> <5227383A.2090207@redhat.com> Message-ID: My problems all seem to be with replication (see the threads with subjects "Scorched earth" and "Replication woes"), and Rob has found an engineer willing to look at log files for me. My problem is in getting the log files over to you for analysis. The system I'm working with is on a private network, so getting the logs off isn't trivial. In my case I'm looking for a way to basically start over with as little heartache as possible, and so far, after two weeks of trial and error, we're no closer to being restarted than we were, well, two weeks ago. My customer is getting antsy and I need to return our network to fully operational within the next 24-48 hours or I'm going to have to nuke it and start all over, which I know involves re-registering every single system with the new master (because it'll be a new CA) and entering the new users again, and setting up DNS over again. Which is why I was looking for a way to export as much as possible right now so I can re-import in case the worst happens and I have to nuke all my IPA servers and start over from scratch. I realize that no one can debug without logs and detailed information. It's just taken a long time to get to where I am, and it takes a full 24 hours or more for me to respond to any request for more detail. In other words, I'm trying to leave my system as it is so we can try to solve the problem it has and minimize the recovery effort, but I have to balance that against my need to get my network operational again, and we're having many, many problems with SSH, SSSD and other services since we don't have a single IPA server in the mix that's fully functional right now. My master is crippled with replication requests and the one good copy I made couldn't get the CA transfer to work. Frustrating for you because I can't always give quick data. Frustrating all around. But we'll get through it one way or the other. I hope to have the latest batch of logs over for analysis later this morning. * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Wed, Sep 4, 2013 at 9:40 AM, Dmitri Pal wrote: > On 09/04/2013 09:26 AM, Petr Spacek wrote: > > On 4.9.2013 15:04, Bret Wortman wrote: > >> What's the right venue for making a suggestion? In particular, I'd > >> like to > >> toss out there that it would be really nice to be able to export, at a > >> minimum, DNS and user data from IPA in the form of a zone file and a > >> passwd/shadow file pair. > >> > >> I realize there might be security implications to the latter, and > >> masking > >> out passwords might be advisiable. And there's no easy way, > >> necessarily, to > >> get out sudo information. But having DNS and user details would at least > >> permit a sysadmin having major issues (like I have been for the past two > >> weeks) to get up and running in some form, using puppet or some other > >> tool > >> to distribute flat files with named running against a static zone > >> file, or > >> even to migrate off IPA if absolutely necessary. > > > > Hello, > > > > for DNS you can use normal zone transfer. Just configure IPA zone to > > allow zone transfer to an IP address (localhost means 'localy to IPA > > server') and use standard DNS tools, e.g. dig: > > > > $ ipa dnszone-mod example.com --allow-transfer='localhost;' > > $ dig +onesoa -t AXFR example.com > /root/example.com.db > > > > That is all you need for DNS, you have the standard zone file. > > > > > > I believe that you can use SSSD (with enumeration enabled) to run > > "getent passwd > /root/passwd.bck". I have no idea how it works with > > shadow map/password. Try to ask sssd-users at lists.fedorahosted.org. > > > And to add to it: > IPA does not keep password in clear or the hashes that are used in > passwd and shadow files for security reasons so it can't generate these > files as you suggest. > > It is unclear what the problems are that you are facing and what made > you get back to local files. > I agree with Petr that SSSD has a lot of bells and whistles to make your > client experience smooth and help you recover from any server side > problems you might have. > > But may be we are missing something and there is something we can do. > If you can describe the problem you are facing we might be able to > suggest a solution. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Sep 4 13:53:34 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 04 Sep 2013 07:53:34 -0600 Subject: [Freeipa-users] IPA Load Problems? In-Reply-To: <52273AE3.3080806@redhat.com> References: <70FAFDC6-AC64-4B42-AB75-ABECDE7B350E@digitalreasoning.com> <521CDE4F.50307@redhat.com> <3D595AA0-9168-45C3-AB29-602567EAC5E4@digitalreasoning.com> <521D0FCE.3080800@redhat.com> <3B676396-41CB-40BA-A7D2-0E1CB8800C30@digitalreasoning.com> <521E1A03.1060904@redhat.com> <5220F587.6000808@redhat.com> <414556BA-3DDF-4259-AC40-D0778BF474DC@digitalreasoning.com> <5220FFC2.90207@redhat.com> <2C999C19-A8A2-435E-B54F-E6F9F7F964AF@digitalreasoning.com> <52210523.7030403@redhat.com> <6D4BA0C3-5003-46AD-842A-E95194B865E2@digitalreasonin! ! g.com> <522108C9.7030506@redhat.com> <5226E4E9.8090903@r! edhat.com> <52822038-F299-46D2-8BD1-D45DA0D99EA6@digitalreasoning.com> <52273AE3.3080806@redhat.com> Message-ID: <52273B5E.4030906@redhat.com> On 09/04/2013 07:51 AM, Martin Kosek wrote: > Ah, ok. One of the reasons why I was poking to this thread is exactly this > ticket. It does not contain much information _what exactly_ is making IPA > performance poor - whether it is missing indices (which ones?) or some issue > in IPA plugins during binds, etc. > > Without more information, we do not know what to fix, what to improve. Right. It's a big, complicated problem. So we start with what we know - the JIRA LDAP sync with IPA is much, much too slow. We don't know why it's too slow. But we can at least set it up and begin profiling it. > > Martin > > On 09/04/2013 02:01 PM, John Moyer wrote: >> Martin, >> >> I apologize there was a large offline conversation between Rich and >> myself. Rich was kind enough to help me through some of my issues. We >> did a lot more tests and poking and prodding. We discovered that IPA is >> not as efficient when dealing with large number of connections. Most of >> my load inefficiently reconnect to IPA over and over and over and though >> LDAP can deal with this fairly efficiently, IPA apparently drops to it's >> knees. >> >> A ticket was opened to addressed this issue. >> >> https://fedorahosted.org/freeipa/ticket/3892 >> >> >> Thanks, _____________________________________________________ John Moyer >> Director, IT Operations Digital Reasoning Systems, Inc. >> John.Moyer at digitalreasoning.com Office: 703.678.2311 Mobile: 240.460.0023 >> Fax: 703.678.2312 www.digitalreasoning.com >> >> On Sep 4, 2013, at 3:44 AM, Martin Kosek wrote: >> >>> On 08/30/2013 11:08 PM, John Moyer wrote: >>>> Well IPA has machine entries on some test clusters that I'm rolling >>>> IPA out on (20 machines maybe) but the user base is the same (about 80 >>>> ~ 100) accounts with maybe 40 to 50 groups? >>>> >>>> I've stood up a clone of the jira server along with IPA. I cleared >>>> my logs and then did the sync and ran the log analyzer on it. These >>>> stats are pretty much ONLY for that jira sync I don't have any other >>>> connections pointed to it. >>>> >>>> >>>> Start of Log: 30/Aug/2013:15:57:13 End of Log: >>>> 30/Aug/2013:16:01:14 >>>> >>>> Processed Log Time: Hours, 4 Minutes, 1 Seconds >>>> >>>> Restarts: 1 Total Connections: 824 SSL >>>> Connections: 824 Peak Concurrent Connections: 6 Total >>>> Operations: 1806 Total Results: 1805 >>>> Overall Performance: 99.9% >>>> >>>> Searches: 968 (4.02/sec) (241.00/min) >>>> Modifications: 5 (0.02/sec) (1.24/min) Adds: >>>> 0 (0.00/sec) (0.00/min) Deletes: 0 >>>> (0.00/sec) (0.00/min) Mod RDNs: 0 >>>> (0.00/sec) (0.00/min) Compares: 0 >>>> (0.00/sec) (0.00/min) Binds: 833 >>>> (3.46/sec) (207.39/min) >>>> >>>> Proxied Auth Operations: 0 Persistent Searches: 1 >>>> Internal Operations: 0 Entry Operations: 0 >>>> Extended Operations: 0 Abandoned Requests: 0 Smart >>>> Referrals Received: 0 >>>> >>>> VLV Operations: 0 VLV Unindexed Searches: 0 SORT >>>> Operations: 0 >>>> >>>> Entire Search Base Queries: 0 Unindexed Searches: 1 >>>> >>> This looks like a promising way to find out the reason, thanks John. >>> However, I see just one unindexed search. Is the access log complete? >>> Previously I see that the sync takes 900 seconds/15 minutes, but there >>> is only 4 minutes the access log. Note that it it may take some time >>> until the log is dumped. >>> >>> I think it would be also useful to run the analyzer with "-ula" flags as >>> Rob suggested earlier to find out the unindexed searches (if any). >>> >>> What I find interesting is that JIRA does a lot of LDAP BINDs. Can the >>> problem be in longer BINDs than with than expected (compared to for >>> example plain LDAP servers)? Performance-wise, it would be I think >>> better if JIRA does just one BIND and run all the LDAP searches the >>> established connection. But I do not know if it can be configured this >>> way. >>> >>> Rich, Rob, I am wondering if the slow up is not really caused by the >>> binds, we have several DS plugins tied to the BIND operation, it may be >>> useful to analyze if they do not take too long. >>> >>> Martin >> From john.moyer at digitalreasoning.com Wed Sep 4 13:58:20 2013 From: john.moyer at digitalreasoning.com (John Moyer) Date: Wed, 4 Sep 2013 09:58:20 -0400 Subject: [Freeipa-users] IPA Load Problems? In-Reply-To: <52273AE3.3080806@redhat.com> References: <70FAFDC6-AC64-4B42-AB75-ABECDE7B350E@digitalreasoning.com> <521CDE4F.50307@redhat.com> <3D595AA0-9168-45C3-AB29-602567EAC5E4@digitalreasoning.com> <521D0FCE.3080800@redhat.com> <3B676396-41CB-40BA-A7D2-0E1CB8800C30@digitalreasoning.com> <521E1A03.1060904@redhat.com> <5220F587.6000808@redhat.com> <414556BA-3DDF-4259-AC40-D0778BF474DC@digitalreasoning.com> <5220FFC2.90207@redhat.com> <2C999C19-A8A2-435E-B54F-E6F9F7F964AF@digitalreasoning.com> <52210523.7030403@redhat.com> <6D4BA0C3-5003-46AD-842A-E95194B865E2@digitalreasonin! ! g.com> <522108C9.7030506@redhat.com> <5226E4E9.8090903@r! edhat.com> <52822038-F299-46D2-8BD1-D45DA0D99EA6@digitalreasoning.com> <52273AE3.30808! 06@redhat.com> Message-ID: <8EF44D2E-1F0D-481C-B189-7319248B67A7@digitalreasoning.com> It was our opinion that it wasn't an index issue. I cleared the logs from the IPA server, and then just ran a JIRA sync with the server. I gave Rich the log file from my IPA for that sync. I can't find the exact conversation, but we determined that JIRA was connecting to LDAP some 1000 times or so to do the sync. The logs didn't show but one search done that didn't have an index which is why we concluded it wasn't an index issue. Thanks, _____________________________________________________ John Moyer Director, IT Operations On Sep 4, 2013, at 9:51 AM, Martin Kosek wrote: > Ah, ok. One of the reasons why I was poking to this thread is exactly this > ticket. It does not contain much information _what exactly_ is making IPA > performance poor - whether it is missing indices (which ones?) or some issue > in IPA plugins during binds, etc. > > Without more information, we do not know what to fix, what to improve. > > Martin > > On 09/04/2013 02:01 PM, John Moyer wrote: >> Martin, >> >> I apologize there was a large offline conversation between Rich and >> myself. Rich was kind enough to help me through some of my issues. We >> did a lot more tests and poking and prodding. We discovered that IPA is >> not as efficient when dealing with large number of connections. Most of >> my load inefficiently reconnect to IPA over and over and over and though >> LDAP can deal with this fairly efficiently, IPA apparently drops to it's >> knees. >> >> A ticket was opened to addressed this issue. >> >> https://fedorahosted.org/freeipa/ticket/3892 >> >> >> Thanks, _____________________________________________________ John Moyer >> Director, IT Operations Digital Reasoning Systems, Inc. >> John.Moyer at digitalreasoning.com Office: 703.678.2311 Mobile: 240.460.0023 >> Fax: 703.678.2312 www.digitalreasoning.com >> >> On Sep 4, 2013, at 3:44 AM, Martin Kosek wrote: >> >>> On 08/30/2013 11:08 PM, John Moyer wrote: >>>> Well IPA has machine entries on some test clusters that I'm rolling >>>> IPA out on (20 machines maybe) but the user base is the same (about 80 >>>> ~ 100) accounts with maybe 40 to 50 groups? >>>> >>>> I've stood up a clone of the jira server along with IPA. I cleared >>>> my logs and then did the sync and ran the log analyzer on it. These >>>> stats are pretty much ONLY for that jira sync I don't have any other >>>> connections pointed to it. >>>> >>>> >>>> Start of Log: 30/Aug/2013:15:57:13 End of Log: >>>> 30/Aug/2013:16:01:14 >>>> >>>> Processed Log Time: Hours, 4 Minutes, 1 Seconds >>>> >>>> Restarts: 1 Total Connections: 824 SSL >>>> Connections: 824 Peak Concurrent Connections: 6 Total >>>> Operations: 1806 Total Results: 1805 >>>> Overall Performance: 99.9% >>>> >>>> Searches: 968 (4.02/sec) (241.00/min) >>>> Modifications: 5 (0.02/sec) (1.24/min) Adds: >>>> 0 (0.00/sec) (0.00/min) Deletes: 0 >>>> (0.00/sec) (0.00/min) Mod RDNs: 0 >>>> (0.00/sec) (0.00/min) Compares: 0 >>>> (0.00/sec) (0.00/min) Binds: 833 >>>> (3.46/sec) (207.39/min) >>>> >>>> Proxied Auth Operations: 0 Persistent Searches: 1 >>>> Internal Operations: 0 Entry Operations: 0 >>>> Extended Operations: 0 Abandoned Requests: 0 Smart >>>> Referrals Received: 0 >>>> >>>> VLV Operations: 0 VLV Unindexed Searches: 0 SORT >>>> Operations: 0 >>>> >>>> Entire Search Base Queries: 0 Unindexed Searches: 1 >>>> >>> >>> This looks like a promising way to find out the reason, thanks John. >>> However, I see just one unindexed search. Is the access log complete? >>> Previously I see that the sync takes 900 seconds/15 minutes, but there >>> is only 4 minutes the access log. Note that it it may take some time >>> until the log is dumped. >>> >>> I think it would be also useful to run the analyzer with "-ula" flags as >>> Rob suggested earlier to find out the unindexed searches (if any). >>> >>> What I find interesting is that JIRA does a lot of LDAP BINDs. Can the >>> problem be in longer BINDs than with than expected (compared to for >>> example plain LDAP servers)? Performance-wise, it would be I think >>> better if JIRA does just one BIND and run all the LDAP searches the >>> established connection. But I do not know if it can be configured this >>> way. >>> >>> Rich, Rob, I am wondering if the slow up is not really caused by the >>> binds, we have several DS plugins tied to the BIND operation, it may be >>> useful to analyze if they do not take too long. >>> >>> Martin >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rmeggins at redhat.com Wed Sep 4 14:02:47 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 04 Sep 2013 08:02:47 -0600 Subject: [Freeipa-users] IPA Load Problems? In-Reply-To: <8EF44D2E-1F0D-481C-B189-7319248B67A7@digitalreasoning.com> References: <70FAFDC6-AC64-4B42-AB75-ABECDE7B350E@digitalreasoning.com> <3D595AA0-9168-45C3-AB29-602567EAC5E4@digitalreasoning.com> <521D0FCE.3080800@redhat.com> <3B676396-41CB-40BA-A7D2-0E1CB8800C30@digitalreasoning.com> <521E1A03.1060904@redhat.com> <5220F587.6000808@redhat.com> <414556BA-3DDF-4259-AC40-D0778BF474DC@digitalreasoning.com> <5220FFC2.90207@redhat.com> <2C999C19-A8A2-435E-B54F-E6F9F7F964AF@digitalreasoning.com> <52210523.7030403@redhat.com> <6D4BA0C3-5003-46AD-842A-E95194B865E2@digitalreasonin! ! g.com> <522108C9.7030506@redhat.com> <5226E4E9.8090903@r! edhat.com> <52822038-F299-46D2-8BD1-D45DA0D99EA6@digitalreasoning.com> <52273AE3.30808! 06@redhat.com> <8EF44D2E-1F0D-481C-B189-7319248B67A7@digitalreasoning.com> Message-ID: <52273D87.6010805@redhat.com> On 09/04/2013 07:58 AM, John Moyer wrote: > It was our opinion that it wasn't an index issue. I cleared the logs > from the IPA server, and then just ran a JIRA sync with the server. I > gave Rich the log file from my IPA for that sync. I can't find the > exact conversation, but we determined that JIRA was connecting to LDAP > some 1000 times or so to do the sync. Right. For every single entry in IPA (user and group), JIRA LDAP sync does - connect/bind/search/unbind/disconnect. This is horribly inefficient, but it is what it is, and apparently other apps work the same way (nexus? svn?), so this would be a good avenue to investigate performance. > The logs didn't show but one search done that didn't have an index > which is why we concluded it wasn't an index issue. Adding indexing did help, but not much, and not nearly enough to make the performance acceptable. > > Thanks, > _____________________________________________________ > John Moyer > Director, IT Operations > > On Sep 4, 2013, at 9:51 AM, Martin Kosek > wrote: > >> Ah, ok. One of the reasons why I was poking to this thread is exactly >> this >> ticket. It does not contain much information _what exactly_ is making IPA >> performance poor - whether it is missing indices (which ones?) or >> some issue >> in IPA plugins during binds, etc. >> >> Without more information, we do not know what to fix, what to improve. >> >> Martin >> >> On 09/04/2013 02:01 PM, John Moyer wrote: >>> Martin, >>> >>> I apologize there was a large offline conversation between Rich and >>> myself. Rich was kind enough to help me through some of my issues. We >>> did a lot more tests and poking and prodding. We discovered that >>> IPA is >>> not as efficient when dealing with large number of connections. Most of >>> my load inefficiently reconnect to IPA over and over and over and though >>> LDAP can deal with this fairly efficiently, IPA apparently drops to it's >>> knees. >>> >>> A ticket was opened to addressed this issue. >>> >>> https://fedorahosted.org/freeipa/ticket/3892 >>> >>> >>> Thanks, _____________________________________________________ John >>> Moyer >>> Director, IT Operations Digital Reasoning Systems, Inc. >>> John.Moyer at digitalreasoning.com Office:703.678.2311 Mobile:240.460.0023 >>> Fax:703.678.2312 www.digitalreasoning.com >>> >>> On Sep 4, 2013, at 3:44 AM, Martin Kosek wrote: >>> >>>> On 08/30/2013 11:08 PM, John Moyer wrote: >>>>> Well IPA has machine entries on some test clusters that I'm rolling >>>>> IPA out on (20 machines maybe) but the user base is the same (about 80 >>>>> ~ 100) accounts with maybe 40 to 50 groups? >>>>> >>>>> I've stood up a clone of the jira server along with IPA. I cleared >>>>> my logs and then did the sync and ran the log analyzer on it. These >>>>> stats are pretty much ONLY for that jira sync I don't have any other >>>>> connections pointed to it. >>>>> >>>>> >>>>> Start of Log: 30/Aug/2013:15:57:13 End of Log: >>>>> 30/Aug/2013:16:01:14 >>>>> >>>>> Processed Log Time: Hours, 4 Minutes, 1 Seconds >>>>> >>>>> Restarts: 1 Total Connections: 824 SSL >>>>> Connections: 824 Peak Concurrent Connections: 6 Total >>>>> Operations: 1806 Total Results: 1805 >>>>> Overall Performance: 99.9% >>>>> >>>>> Searches: 968 (4.02/sec) (241.00/min) >>>>> Modifications: 5 (0.02/sec) (1.24/min) Adds: >>>>> 0 (0.00/sec) (0.00/min) Deletes: 0 >>>>> (0.00/sec) (0.00/min) Mod RDNs: 0 >>>>> (0.00/sec) (0.00/min) Compares: 0 >>>>> (0.00/sec) (0.00/min) Binds: 833 >>>>> (3.46/sec) (207.39/min) >>>>> >>>>> Proxied Auth Operations: 0 Persistent Searches: 1 >>>>> Internal Operations: 0 Entry Operations: 0 >>>>> Extended Operations: 0 Abandoned Requests: 0 Smart >>>>> Referrals Received: 0 >>>>> >>>>> VLV Operations: 0 VLV Unindexed Searches: 0 SORT >>>>> Operations: 0 >>>>> >>>>> Entire Search Base Queries: 0 Unindexed Searches: 1 >>>>> >>>> >>>> This looks like a promising way to find out the reason, thanks John. >>>> However, I see just one unindexed search. Is the access log complete? >>>> Previously I see that the sync takes 900 seconds/15 minutes, but there >>>> is only 4 minutes the access log. Note that it it may take some time >>>> until the log is dumped. >>>> >>>> I think it would be also useful to run the analyzer with "-ula" >>>> flags as >>>> Rob suggested earlier to find out the unindexed searches (if any). >>>> >>>> What I find interesting is that JIRA does a lot of LDAP BINDs. Can the >>>> problem be in longer BINDs than with than expected (compared to for >>>> example plain LDAP servers)? Performance-wise, it would be I think >>>> better if JIRA does just one BIND and run all the LDAP searches the >>>> established connection. But I do not know if it can be configured this >>>> way. >>>> >>>> Rich, Rob, I am wondering if the slow up is not really caused by the >>>> binds, we have several DS plugins tied to the BIND operation, it may be >>>> useful to analyze if they do not take too long. >>>> >>>> Martin >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbulist at gmail.com Wed Sep 4 14:40:29 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Wed, 04 Sep 2013 09:40:29 -0500 Subject: [Freeipa-users] Incorrect user information Message-ID: <5227465D.7020308@gmail.com> Hi, We have a freeipa server (RedHat 6.3, freeipa:3.0.0-26) and freeipa client (RedHat 5.9, freeipa client 2.1.3.-5) working in our test testing scenario without further problems. We are able to use SUDO, HBAC etc. Our problem is when we change a user info (Name or Last Name) and check it using the command: getent passwd id_user it showed us the older user information. We set entry_cache_user_timeout = 0 in sssd.conf file in order to clear the cache data but it did not work. Also we tried with: use_fully_qualified_domains attribute as recommend in: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html#idp26289072 but it was not helpful. If we check the user info using ldapsearch command we can see the right user info information. Changing the uid or gid we see the new change right away. Any clue about this problem? Thanks! CBU -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at redhat.com Wed Sep 4 14:47:49 2013 From: chris at redhat.com (Chris Hudson) Date: Wed, 4 Sep 2013 10:47:49 -0400 (EDT) Subject: [Freeipa-users] Incorrect user information In-Reply-To: <5227465D.7020308@gmail.com> References: <5227465D.7020308@gmail.com> Message-ID: <841815955.7935136.1378306069557.JavaMail.root@redhat.com> You may want to check out the sss_cache package in the sssd-tools package. It looks to be in the base channel for RHEL5 Server and optional channel for RHEL6 Server. This tool will allow you to invalidate/manipulate the sssd cache. -Chris ----- Original Message ----- > From: cbulist at gmail.com > To: freeipa-users at redhat.com > Sent: Wednesday, September 4, 2013 10:40:29 AM > Subject: [Freeipa-users] Incorrect user information > Hi, > We have a freeipa server (RedHat 6.3, freeipa:3.0.0-26) and freeipa client > (RedHat 5.9, freeipa client 2.1.3.-5) working in our test testing scenario > without further problems. We are able to use SUDO, HBAC etc. > Our problem is when we change a user info (Name or Last Name) and check it > using the command: getent passwd id_user it showed us the older user > information. > We set entry_cache_user_timeout = 0 in sssd.conf file in order to clear the > cache data but it did not work. Also we tried with: > use_fully_qualified_domains attribute as recommend in: > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html#idp26289072 > but it was not helpful. > If we check the user info using ldapsearch command we can see the right user > info information. Changing the uid or gid we see the new change right away. > Any clue about this problem? > Thanks! > CBU > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at redhat.com Wed Sep 4 14:49:20 2013 From: chris at redhat.com (Chris Hudson) Date: Wed, 4 Sep 2013 10:49:20 -0400 (EDT) Subject: [Freeipa-users] Incorrect user information In-Reply-To: <841815955.7935136.1378306069557.JavaMail.root@redhat.com> References: <5227465D.7020308@gmail.com> <841815955.7935136.1378306069557.JavaMail.root@redhat.com> Message-ID: <237193263.7936259.1378306160770.JavaMail.root@redhat.com> s/"sss_cache package"/"sss_cache tool" :) ----- Original Message ----- > From: "Chris Hudson" > To: cbulist at gmail.com > Cc: freeipa-users at redhat.com > Sent: Wednesday, September 4, 2013 10:47:49 AM > Subject: Re: [Freeipa-users] Incorrect user information > You may want to check out the sss_cache package in the sssd-tools package. It > looks to be in the base channel for RHEL5 Server and optional channel for > RHEL6 Server. This tool will allow you to invalidate/manipulate the sssd > cache. > -Chris > ----- Original Message ----- > > From: cbulist at gmail.com > > > To: freeipa-users at redhat.com > > > Sent: Wednesday, September 4, 2013 10:40:29 AM > > > Subject: [Freeipa-users] Incorrect user information > > > Hi, > > > We have a freeipa server (RedHat 6.3, freeipa:3.0.0-26) and freeipa client > > (RedHat 5.9, freeipa client 2.1.3.-5) working in our test testing scenario > > without further problems. We are able to use SUDO, HBAC etc. > > > Our problem is when we change a user info (Name or Last Name) and check it > > using the command: getent passwd id_user it showed us the older user > > information. > > > We set entry_cache_user_timeout = 0 in sssd.conf file in order to clear the > > cache data but it did not work. Also we tried with: > > use_fully_qualified_domains attribute as recommend in: > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html#idp26289072 > > but it was not helpful. > > > If we check the user info using ldapsearch command we can see the right > > user > > info information. Changing the uid or gid we see the new change right away. > > > Any clue about this problem? > > > Thanks! > > > CBU > > > _______________________________________________ > > > Freeipa-users mailing list > > > Freeipa-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Sep 4 15:18:03 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 4 Sep 2013 17:18:03 +0200 Subject: [Freeipa-users] Incorrect user information In-Reply-To: <841815955.7935136.1378306069557.JavaMail.root@redhat.com> References: <5227465D.7020308@gmail.com> <841815955.7935136.1378306069557.JavaMail.root@redhat.com> Message-ID: <20130904151803.GG22590@hendrix.brq.redhat.com> On Wed, Sep 04, 2013 at 10:47:49AM -0400, Chris Hudson wrote: > You may want to check out the sss_cache package in the sssd-tools package. It looks to be in the base channel for RHEL5 Server and optional channel for RHEL6 Server. This tool will allow you to invalidate/manipulate the sssd cache. > > -Chris > Exactly. To invalidate user and group information and force a refresh on the next query, run "sss_cache -UG". We realized that including sss_cache in the sssd-tools subpackage hid the tool from many users, so in recent versions it's included back in sssd proper. From cbulist at gmail.com Wed Sep 4 15:18:13 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Wed, 04 Sep 2013 10:18:13 -0500 Subject: [Freeipa-users] Incorrect user information In-Reply-To: <237193263.7936259.1378306160770.JavaMail.root@redhat.com> References: <5227465D.7020308@gmail.com> <841815955.7935136.1378306069557.JavaMail.root@redhat.com> <237193263.7936259.1378306160770.JavaMail.root@redhat.com> Message-ID: <52274F35.5090508@gmail.com> Hi Chris, Thanks for your reply!....I forgot to mention that we tried sss_cache (sss_cache -u user_id and sss_cache -U) in other RH6 ipa client and it did not work...If we delete manually all /var/lib/sss/db we can see the change but it is not going to be a nice solution. On 09/04/2013 09:49 AM, Chris Hudson wrote: > > s/"sss_cache package"/"sss_cache tool" > > :) > > ------------------------------------------------------------------------ > > *From: *"Chris Hudson" > *To: *cbulist at gmail.com > *Cc: *freeipa-users at redhat.com > *Sent: *Wednesday, September 4, 2013 10:47:49 AM > *Subject: *Re: [Freeipa-users] Incorrect user information > > You may want to check out the sss_cache package in the sssd-tools > package. It looks to be in the base channel for RHEL5 Server and > optional channel for RHEL6 Server. This tool will allow you to > invalidate/manipulate the sssd cache. > > -Chris > > ------------------------------------------------------------------------ > > *From: *cbulist at gmail.com > *To: *freeipa-users at redhat.com > *Sent: *Wednesday, September 4, 2013 10:40:29 AM > *Subject: *[Freeipa-users] Incorrect user information > > Hi, > > We have a freeipa server (RedHat 6.3, freeipa:3.0.0-26) and > freeipa client (RedHat 5.9, freeipa client 2.1.3.-5) working > in our test testing scenario without further problems. We are > able to use SUDO, HBAC etc. > Our problem is when we change a user info (Name or Last Name) > and check it using the command: getent passwd id_user it > showed us the older user information. > We set entry_cache_user_timeout = 0 in sssd.conf file in order > to clear the cache data but it did not work. Also we tried > with: use_fully_qualified_domains attribute as recommend in: > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html#idp26289072 > but it was not helpful. > > If we check the user info using ldapsearch command we can see > the right user info information. Changing the uid or gid we > see the new change right away. > Any clue about this problem? > > Thanks! > > CBU > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Sep 4 15:31:34 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 4 Sep 2013 17:31:34 +0200 Subject: [Freeipa-users] Incorrect user information In-Reply-To: <52274F35.5090508@gmail.com> References: <5227465D.7020308@gmail.com> <841815955.7935136.1378306069557.JavaMail.root@redhat.com> <237193263.7936259.1378306160770.JavaMail.root@redhat.com> <52274F35.5090508@gmail.com> Message-ID: <20130904153134.GH22590@hendrix.brq.redhat.com> On Wed, Sep 04, 2013 at 10:18:13AM -0500, cbulist at gmail.com wrote: > Hi Chris, > > Thanks for your reply!....I forgot to mention that we tried sss_cache > (sss_cache -u user_id and sss_cache -U) in other RH6 ipa client and it > did not work...If we delete manually all /var/lib/sss/db we can see the > change but it is not going to be a nice solution. This sounds really strange. Can you run a little experiment for me? Can you install the ldb-tools package and then run: 1) getent passwd $username 2) ldbsearch -H /var/lib/sss/db/cache_$domain.ldb name=$username 3) modify the entry 4) sss_cache -U 5) ldbsearch -H /var/lib/sss/db/cache_$domain.ldb name=$username 6) getent passwd $username 7) ldbsearch -H /var/lib/sss/db/cache_$domain.ldb name=$username after you run 2) you should see how the entry looks in the cache with the old attributes. After running 5) you should see the same attributes, except for dataExpireTimestamp that should be set to "1". After running 6), getent should yield the updated data and 7) should reflect From jhrozek at redhat.com Wed Sep 4 15:31:43 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 4 Sep 2013 17:31:43 +0200 Subject: [Freeipa-users] Incorrect user information In-Reply-To: <5227465D.7020308@gmail.com> References: <5227465D.7020308@gmail.com> Message-ID: <20130904153143.GI22590@hendrix.brq.redhat.com> On Wed, Sep 04, 2013 at 09:40:29AM -0500, cbulist at gmail.com wrote: > Hi, > > We have a freeipa server (RedHat 6.3, freeipa:3.0.0-26) and freeipa > client (RedHat 5.9, freeipa client 2.1.3.-5) working in our test testing > scenario without further problems. We are able to use SUDO, HBAC etc. > Our problem is when we change a user info (Name or Last Name) and check > it using the command: getent passwd id_user it showed us the older user > information. > We set entry_cache_user_timeout = 0 in sssd.conf file in order to clear > the cache data but it did not work. Also we tried with: > use_fully_qualified_domains attribute as recommend in: > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html#idp26289072 > but it was not helpful. > > If we check the user info using ldapsearch command we can see the right > user info information. Changing the uid or gid we see the new change > right away. > Any clue about this problem? One more additional point about why changing the timestamp might not have had the effect you wanted..the cache validity that controls when the entry is refreshed from the cache is stored in the cache as a UNIX timestamp. So whenever you change the timeout, you also need to invalidate the cache using the sss_cache tool. Running the sss_cache tool sets the cache expiration timestamp to 1 (beginning of the Epoch) to force refresh on next query. Arguably this is not documented well in the sssd.conf manual page, so I've sent a patch to the upstream development list to document this behaviour better. From jhrozek at redhat.com Wed Sep 4 15:37:41 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 4 Sep 2013 17:37:41 +0200 Subject: [Freeipa-users] Incorrect user information In-Reply-To: <20130904153134.GH22590@hendrix.brq.redhat.com> References: <5227465D.7020308@gmail.com> <841815955.7935136.1378306069557.JavaMail.root@redhat.com> <237193263.7936259.1378306160770.JavaMail.root@redhat.com> <52274F35.5090508@gmail.com> <20130904153134.GH22590@hendrix.brq.redhat.com> Message-ID: <20130904153741.GK22590@hendrix.brq.redhat.com> On Wed, Sep 04, 2013 at 05:31:34PM +0200, Jakub Hrozek wrote: > On Wed, Sep 04, 2013 at 10:18:13AM -0500, cbulist at gmail.com wrote: > > Hi Chris, > > > > Thanks for your reply!....I forgot to mention that we tried sss_cache > > (sss_cache -u user_id and sss_cache -U) in other RH6 ipa client and it > > did not work...If we delete manually all /var/lib/sss/db we can see the > > change but it is not going to be a nice solution. > > This sounds really strange. Can you run a little experiment for me? Also are you running nscd? From cbulist at gmail.com Wed Sep 4 16:14:50 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Wed, 04 Sep 2013 11:14:50 -0500 Subject: [Freeipa-users] Incorrect user information In-Reply-To: <20130904153134.GH22590@hendrix.brq.redhat.com> References: <5227465D.7020308@gmail.com> <841815955.7935136.1378306069557.JavaMail.root@redhat.com> <237193263.7936259.1378306160770.JavaMail.root@redhat.com> <52274F35.5090508@gmail.com> <20130904153134.GH22590@hendrix.brq.redhat.com> Message-ID: <52275C7A.3020800@gmail.com> Hi Jakub, Thanks for your time and tips about sssd cache! I did the test and let me explain what I got: - After step 4 I can see dataExpireTimestamp to 1 for the user. - After step 7 dataExpireTimestamp is back to 0 but the user data have not changed. The first line after the command ldbsearch is: asq: Unable to register control with rootdse! Is it a problem? We are not using nscd service. Please let me know if you need to do some other tests. Thanks in advance! On 09/04/2013 10:31 AM, Jakub Hrozek wrote: > On Wed, Sep 04, 2013 at 10:18:13AM -0500, cbulist at gmail.com wrote: >> Hi Chris, >> >> Thanks for your reply!....I forgot to mention that we tried sss_cache >> (sss_cache -u user_id and sss_cache -U) in other RH6 ipa client and it >> did not work...If we delete manually all /var/lib/sss/db we can see the >> change but it is not going to be a nice solution. > This sounds really strange. Can you run a little experiment for me? > > Can you install the ldb-tools package and then run: > > 1) getent passwd $username > 2) ldbsearch -H /var/lib/sss/db/cache_$domain.ldb name=$username > 3) modify the entry > 4) sss_cache -U > 5) ldbsearch -H /var/lib/sss/db/cache_$domain.ldb name=$username > 6) getent passwd $username > 7) ldbsearch -H /var/lib/sss/db/cache_$domain.ldb name=$username > > after you run 2) you should see how the entry looks in the cache with > the old attributes. After running 5) you should see the same attributes, > except for dataExpireTimestamp that should be set to "1". > > After running 6), getent should yield the updated data and 7) should reflect > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From simo at redhat.com Wed Sep 4 17:32:25 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 04 Sep 2013 13:32:25 -0400 Subject: [Freeipa-users] Exporting data? In-Reply-To: <5227383A.2090207@redhat.com> References: <52273507.8020606@redhat.com> <5227383A.2090207@redhat.com> Message-ID: <1378315945.13768.114.camel@willson.li.ssimo.org> On Wed, 2013-09-04 at 09:40 -0400, Dmitri Pal wrote: > On 09/04/2013 09:26 AM, Petr Spacek wrote: > > On 4.9.2013 15:04, Bret Wortman wrote: > >> What's the right venue for making a suggestion? In particular, I'd > >> like to > >> toss out there that it would be really nice to be able to export, at a > >> minimum, DNS and user data from IPA in the form of a zone file and a > >> passwd/shadow file pair. > >> > >> I realize there might be security implications to the latter, and > >> masking > >> out passwords might be advisiable. And there's no easy way, > >> necessarily, to > >> get out sudo information. But having DNS and user details would at least > >> permit a sysadmin having major issues (like I have been for the past two > >> weeks) to get up and running in some form, using puppet or some other > >> tool > >> to distribute flat files with named running against a static zone > >> file, or > >> even to migrate off IPA if absolutely necessary. > > > > Hello, > > > > for DNS you can use normal zone transfer. Just configure IPA zone to > > allow zone transfer to an IP address (localhost means 'localy to IPA > > server') and use standard DNS tools, e.g. dig: > > > > $ ipa dnszone-mod example.com --allow-transfer='localhost;' > > $ dig +onesoa -t AXFR example.com > /root/example.com.db > > > > That is all you need for DNS, you have the standard zone file. > > > > > > I believe that you can use SSSD (with enumeration enabled) to run > > "getent passwd > /root/passwd.bck". I have no idea how it works with > > shadow map/password. Try to ask sssd-users at lists.fedorahosted.org. > > > And to add to it: > IPA does not keep password in clear or the hashes that are used in > passwd and shadow files for security reasons so it can't generate these > files as you suggest. We do have hashes, the default is SHA256, it is stored in userPassword and is used to validate LDAP binds, however we never let it out of LDAP, neither SSSD not the integrate NIS server expose the password hash to clients. You need Directory Manager privileges to read it. Simo. -- Simo Sorce * Red Hat, Inc * New York From tsoucy at salesforce.com Wed Sep 4 18:18:10 2013 From: tsoucy at salesforce.com (Terry Soucy) Date: Wed, 4 Sep 2013 15:18:10 -0300 Subject: [Freeipa-users] Replication causing long etimes Message-ID: I am experiencing some long execution times, and I'm wondering if anyone can give me some insight. We are running FreeIPA 3.0.0-26 on Redhat 6.1. We have multimaster replication running among 4 hosts. We have approv 100 users, 25 usergroups and hostgroups, and approx 2000 hosts in a single domain. We noticed that some DNS queries were timing out periodically. When I investigated further, I found several of the DNS requests in the access log [04/Sep/2013:13:42:24 -0300] conn=122491 op=3888679 SRCH base="idnsName=compute- 1.amazonaws.com,idnsname=prod.ca2.example.com,cn=dns,dc=example,dc=com" scope=0 filter=" (objectClass=idnsRecord)" attrs=ALL [04/Sep/2013:13:42:44 -0300] conn=122491 op=3888679 RESULT err=32 tag=101 nentri es=0 etime=20 There are a lot of those, as expected, since we first noticed this issue with DNS. Then I found this ... [04/Sep/2013:13:42:23 -0300] conn=368561 op=9 EXT oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End Session" [04/Sep/2013:13:42:44 -0300] conn=368561 op=9 RESULT err=0 tag=120 nentries=0 etime=22 and lots of this ... [04/Sep/2013:13:42:26 -0300] conn=368604 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [04/Sep/2013:13:42:44 -0300] conn=368604 op=0 RESULT err=14 tag=97 nentries=0 etime=18, SASL bind in progress So, is my SASL bind causing the replication to go long, or is the replication taking a long time and causing the hang? Is there a way I can see the details of the replication? There is not a lot of changes going on that require replication with regards to dns, users, hosts, etc, so I'm not sure why it would take so long. Also, can I remove the SASL bind and just add a replication user to the dse.ldif to remove the requirement for kerberos for replication? Terry -- Terry Soucy - Systems Engineer Salesforce MarketingCloud - http://www.salesforce.com (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Wed Sep 4 18:23:50 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 4 Sep 2013 14:23:50 -0400 Subject: [Freeipa-users] Exporting data? In-Reply-To: <1378315945.13768.114.camel@willson.li.ssimo.org> References: <52273507.8020606@redhat.com> <5227383A.2090207@redhat.com> <1378315945.13768.114.camel@willson.li.ssimo.org> Message-ID: ...and I tried exporting the DNS data but ended up with a bunch of files that looked liket his: # cat foo.net.db ; <<>> DiG 9.9.3-rl.156.01.P1-RedHat-9.9.3-3.P1.fc18 <<>> +onesoa -t AXFR foo.net ;; global options: +cmd ; Transfer failed. # The logs showed: ipamaster named[31633]: client 1.2.3.4#39992 (foo.net) : zone transfer 'foo.net/AXFR/IN' denied * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Wed, Sep 4, 2013 at 1:32 PM, Simo Sorce wrote: > On Wed, 2013-09-04 at 09:40 -0400, Dmitri Pal wrote: > > On 09/04/2013 09:26 AM, Petr Spacek wrote: > > > On 4.9.2013 15:04, Bret Wortman wrote: > > >> What's the right venue for making a suggestion? In particular, I'd > > >> like to > > >> toss out there that it would be really nice to be able to export, at a > > >> minimum, DNS and user data from IPA in the form of a zone file and a > > >> passwd/shadow file pair. > > >> > > >> I realize there might be security implications to the latter, and > > >> masking > > >> out passwords might be advisiable. And there's no easy way, > > >> necessarily, to > > >> get out sudo information. But having DNS and user details would at > least > > >> permit a sysadmin having major issues (like I have been for the past > two > > >> weeks) to get up and running in some form, using puppet or some other > > >> tool > > >> to distribute flat files with named running against a static zone > > >> file, or > > >> even to migrate off IPA if absolutely necessary. > > > > > > Hello, > > > > > > for DNS you can use normal zone transfer. Just configure IPA zone to > > > allow zone transfer to an IP address (localhost means 'localy to IPA > > > server') and use standard DNS tools, e.g. dig: > > > > > > $ ipa dnszone-mod example.com --allow-transfer='localhost;' > > > $ dig +onesoa -t AXFR example.com > /root/example.com.db > > > > > > That is all you need for DNS, you have the standard zone file. > > > > > > > > > I believe that you can use SSSD (with enumeration enabled) to run > > > "getent passwd > /root/passwd.bck". I have no idea how it works with > > > shadow map/password. Try to ask sssd-users at lists.fedorahosted.org. > > > > > And to add to it: > > IPA does not keep password in clear or the hashes that are used in > > passwd and shadow files for security reasons so it can't generate these > > files as you suggest. > > We do have hashes, the default is SHA256, it is stored in userPassword > and is used to validate LDAP binds, however we never let it out of LDAP, > neither SSSD not the integrate NIS server expose the password hash to > clients. You need Directory Manager privileges to read it. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Sep 4 18:28:45 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 04 Sep 2013 12:28:45 -0600 Subject: [Freeipa-users] Replication causing long etimes In-Reply-To: References: Message-ID: <52277BDD.5050800@redhat.com> On 09/04/2013 12:18 PM, Terry Soucy wrote: > I am experiencing some long execution times, and I'm wondering if > anyone can give me some insight. > > We are running FreeIPA 3.0.0-26 on Redhat 6.1. We have multimaster > replication running among 4 hosts. We have approv 100 users, 25 > usergroups and hostgroups, and approx 2000 hosts in a single domain. > We noticed that some DNS queries were timing out periodically. When I > investigated further, I found several of the DNS requests in the > access log > > [04/Sep/2013:13:42:24 -0300] conn=122491 op=3888679 SRCH > base="idnsName=compute- > 1.amazonaws.com ,idnsname=prod.ca2.example.com > ,cn=dns,dc=example,dc=com" scope=0 filter=" > (objectClass=idnsRecord)" attrs=ALL > [04/Sep/2013:13:42:44 -0300] conn=122491 op=3888679 RESULT err=32 > tag=101 nentri > es=0 etime=20 > > There are a lot of those, as expected, since we first noticed this > issue with DNS. > > Then I found this ... > > [04/Sep/2013:13:42:23 -0300] conn=368561 op=9 EXT > oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End Session" > [04/Sep/2013:13:42:44 -0300] conn=368561 op=9 RESULT err=0 tag=120 > nentries=0 etime=22 > > and lots of this ... > > [04/Sep/2013:13:42:26 -0300] conn=368604 op=0 BIND dn="" method=sasl > version=3 mech=GSSAPI > [04/Sep/2013:13:42:44 -0300] conn=368604 op=0 RESULT err=14 tag=97 > nentries=0 etime=18, SASL bind in progress > > > So, is my SASL bind causing the replication to go long, or is the > replication taking a long time and causing the hang? I don't know. DNS could also be related. If you can, please try to get a stack trace of the ns-slapd process during the time interval during which nothing appears to be happening. http://port389.org/wiki/FAQ#Debugging_Hangs > Is there a way I can see the details of the replication? You can use the replication logging level http://port389.org/wiki/FAQ#Troubleshooting But I don't know if the problem is specifically replication related > There is not a lot of changes going on that require replication with > regards to dns, users, hosts, etc, so I'm not sure why it would take > so long. Also, can I remove the SASL bind and just add a replication > user to the dse.ldif to remove the requirement for kerberos for > replication? You technically could with 389, but I don't know if that is supported with IPA. > > Terry > -- > Terry Soucy - Systems Engineer > Salesforce MarketingCloud - http://www.salesforce.com > (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jprouty at cctus.com Wed Sep 4 21:41:51 2013 From: jprouty at cctus.com (Jason Prouty) Date: Wed, 4 Sep 2013 15:41:51 -0600 (MDT) Subject: [Freeipa-users] Ldap schema Message-ID: <24d47e92.00005b94.0000004d@JPROUTY-WIN7.cctus.com> I have the radius.schema file how do I add that into my ldap schema on IPA server. I see several ldif files /etc/dirsrv//schema but they are ldif files If I can extend my schema integration to free radius should be easy. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: radius.schema Type: application/octet-stream Size: 13259 bytes Desc: not available URL: From jdennis at redhat.com Wed Sep 4 22:25:52 2013 From: jdennis at redhat.com (John Dennis) Date: Wed, 04 Sep 2013 18:25:52 -0400 Subject: [Freeipa-users] Ldap schema In-Reply-To: <24d47e92.00005b94.0000004d@JPROUTY-WIN7.cctus.com> References: <24d47e92.00005b94.0000004d@JPROUTY-WIN7.cctus.com> Message-ID: <5227B370.7040408@redhat.com> On 09/04/2013 05:41 PM, Jason Prouty wrote: > I have the radius.schema file how do I add that into my ldap schema on > IPA server. > > I see several ldif files /etc/dirsrv//schema but they are ldif > files > > > > If I can extend my schema integration to free radius should be easy. Is there a reason you ignored the prior response? -- John From jprouty at cctus.com Thu Sep 5 04:38:11 2013 From: jprouty at cctus.com (Jason Prouty) Date: Wed, 4 Sep 2013 22:38:11 -0600 (MDT) Subject: [Freeipa-users] Ldap schema In-Reply-To: <5227B370.7040408@redhat.com> References: <24d47e92.00005b94.0000004d@JPROUTY-WIN7.cctus.com> <5227B370.7040408@redhat.com> Message-ID: This is the AV-Pair I would like to implement to pass back to radius. dn: cn=priv-15,ou=cisco,ou=radius,dc=example,dc=com objectClass: radiusObjectProfile objectClass: radiusprofile cn: priv-15 radiusReplyItem: cisco-avpair = "shell:priv-lvl=15" -----Original Message----- From: John Dennis [mailto:jdennis at redhat.com] Sent: Wednesday, September 04, 2013 4:26 PM To: Jason Prouty Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Ldap schema On 09/04/2013 05:41 PM, Jason Prouty wrote: > I have the radius.schema file how do I add that into my ldap schema on > IPA server. > > I see several ldif files /etc/dirsrv//schema but they are > ldif files > > > > If I can extend my schema integration to free radius should be easy. Is there a reason you ignored the prior response? -- John From dpal at redhat.com Thu Sep 5 06:29:14 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Sep 2013 02:29:14 -0400 Subject: [Freeipa-users] Ldap schema In-Reply-To: References: <24d47e92.00005b94.0000004d@JPROUTY-WIN7.cctus.com> <5227B370.7040408@redhat.com> Message-ID: <522824BA.3090206@redhat.com> On 09/05/2013 12:38 AM, Jason Prouty wrote: > This is the AV-Pair I would like to implement to pass back to radius. > > > dn: cn=priv-15,ou=cisco,ou=radius,dc=example,dc=com > objectClass: radiusObjectProfile > objectClass: radiusprofile > cn: priv-15 > radiusReplyItem: cisco-avpair = "shell:priv-lvl=15" The question was why you need to use IPA as a storage for profiles? It looks like you are not using FreeRADIUS. Is this the case? > > -----Original Message----- > From: John Dennis [mailto:jdennis at redhat.com] > Sent: Wednesday, September 04, 2013 4:26 PM > To: Jason Prouty > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Ldap schema > > On 09/04/2013 05:41 PM, Jason Prouty wrote: >> I have the radius.schema file how do I add that into my ldap schema on >> IPA server. >> >> I see several ldif files /etc/dirsrv//schema but they are >> ldif files >> >> >> >> If I can extend my schema integration to free radius should be easy. > Is there a reason you ignored the prior response? > > > -- > John > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pspacek at redhat.com Thu Sep 5 06:33:24 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 05 Sep 2013 08:33:24 +0200 Subject: [Freeipa-users] Exporting data? In-Reply-To: References: <52273507.8020606@redhat.com> <5227383A.2090207@redhat.com> <1378315945.13768.114.camel@willson.li.ssimo.org> Message-ID: <522825B4.2010800@redhat.com> On 4.9.2013 20:23, Bret Wortman wrote: > ...and I tried exporting the DNS data but ended up with a bunch of files > that looked liket his: > > # cat foo.net.db > > ; <<>> DiG 9.9.3-rl.156.01.P1-RedHat-9.9.3-3.P1.fc18 <<>> +onesoa -t AXFR > foo.net > ;; global options: +cmd > ; Transfer failed. > # > > The logs showed: > > ipamaster named[31633]: client 1.2.3.4#39992 (foo.net) : zone > transfer 'foo.net/AXFR/IN' denied You have to add IP '1.2.3.4' to the allow-transfer Address List Match. $ ipa dnszone-mod --allow-transfer='localhost; 1.2.3.4;' See http://www.zytrax.com/books/dns/ch7/address_match_list.html for further details. Petr^2 Spacek > On Wed, Sep 4, 2013 at 1:32 PM, Simo Sorce wrote: > >> On Wed, 2013-09-04 at 09:40 -0400, Dmitri Pal wrote: >>> On 09/04/2013 09:26 AM, Petr Spacek wrote: >>>> On 4.9.2013 15:04, Bret Wortman wrote: >>>>> What's the right venue for making a suggestion? In particular, I'd >>>>> like to >>>>> toss out there that it would be really nice to be able to export, at a >>>>> minimum, DNS and user data from IPA in the form of a zone file and a >>>>> passwd/shadow file pair. >>>>> >>>>> I realize there might be security implications to the latter, and >>>>> masking >>>>> out passwords might be advisiable. And there's no easy way, >>>>> necessarily, to >>>>> get out sudo information. But having DNS and user details would at >> least >>>>> permit a sysadmin having major issues (like I have been for the past >> two >>>>> weeks) to get up and running in some form, using puppet or some other >>>>> tool >>>>> to distribute flat files with named running against a static zone >>>>> file, or >>>>> even to migrate off IPA if absolutely necessary. >>>> >>>> Hello, >>>> >>>> for DNS you can use normal zone transfer. Just configure IPA zone to >>>> allow zone transfer to an IP address (localhost means 'localy to IPA >>>> server') and use standard DNS tools, e.g. dig: >>>> >>>> $ ipa dnszone-mod example.com --allow-transfer='localhost;' >>>> $ dig +onesoa -t AXFR example.com > /root/example.com.db >>>> >>>> That is all you need for DNS, you have the standard zone file. >>>> >>>> >>>> I believe that you can use SSSD (with enumeration enabled) to run >>>> "getent passwd > /root/passwd.bck". I have no idea how it works with >>>> shadow map/password. Try to ask sssd-users at lists.fedorahosted.org. >>>> >>> And to add to it: >>> IPA does not keep password in clear or the hashes that are used in >>> passwd and shadow files for security reasons so it can't generate these >>> files as you suggest. >> >> We do have hashes, the default is SHA256, it is stored in userPassword >> and is used to validate LDAP binds, however we never let it out of LDAP, >> neither SSSD not the integrate NIS server expose the password hash to >> clients. You need Directory Manager privileges to read it. From bret.wortman at damascusgrp.com Thu Sep 5 11:48:34 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Thu, 5 Sep 2013 07:48:34 -0400 Subject: [Freeipa-users] Exporting data? In-Reply-To: <522825B4.2010800@redhat.com> References: <52273507.8020606@redhat.com> <5227383A.2090207@redhat.com> <1378315945.13768.114.camel@willson.li.ssimo.org> <522825B4.2010800@redhat.com> Message-ID: D'Oh! Thanks, Petr. * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Thu, Sep 5, 2013 at 2:33 AM, Petr Spacek wrote: > On 4.9.2013 20:23, Bret Wortman wrote: > >> ...and I tried exporting the DNS data but ended up with a bunch of files >> that looked liket his: >> >> # cat foo.net.db >> >> ; <<>> DiG 9.9.3-rl.156.01.P1-RedHat-9.9.**3-3.P1.fc18 <<>> +onesoa -t >> AXFR >> foo.net >> ;; global options: +cmd >> ; Transfer failed. >> # >> >> The logs showed: >> >> ipamaster named[31633]: client 1.2.3.4#39992 (foo.net) : zone >> transfer 'foo.net/AXFR/IN' denied >> > > You have to add IP '1.2.3.4' to the allow-transfer Address List Match. > > $ ipa dnszone-mod --allow-transfer='localhost; 1.2.3.4;' > > See > http://www.zytrax.com/books/**dns/ch7/address_match_list.**html > for further details. > > Petr^2 Spacek > > > On Wed, Sep 4, 2013 at 1:32 PM, Simo Sorce wrote: >> >> On Wed, 2013-09-04 at 09:40 -0400, Dmitri Pal wrote: >>> >>>> On 09/04/2013 09:26 AM, Petr Spacek wrote: >>>> >>>>> On 4.9.2013 15:04, Bret Wortman wrote: >>>>> >>>>>> What's the right venue for making a suggestion? In particular, I'd >>>>>> like to >>>>>> toss out there that it would be really nice to be able to export, at a >>>>>> minimum, DNS and user data from IPA in the form of a zone file and a >>>>>> passwd/shadow file pair. >>>>>> >>>>>> I realize there might be security implications to the latter, and >>>>>> masking >>>>>> out passwords might be advisiable. And there's no easy way, >>>>>> necessarily, to >>>>>> get out sudo information. But having DNS and user details would at >>>>>> >>>>> least >>> >>>> permit a sysadmin having major issues (like I have been for the past >>>>>> >>>>> two >>> >>>> weeks) to get up and running in some form, using puppet or some other >>>>>> tool >>>>>> to distribute flat files with named running against a static zone >>>>>> file, or >>>>>> even to migrate off IPA if absolutely necessary. >>>>>> >>>>> >>>>> Hello, >>>>> >>>>> for DNS you can use normal zone transfer. Just configure IPA zone to >>>>> allow zone transfer to an IP address (localhost means 'localy to IPA >>>>> server') and use standard DNS tools, e.g. dig: >>>>> >>>>> $ ipa dnszone-mod example.com --allow-transfer='localhost;' >>>>> $ dig +onesoa -t AXFR example.com > /root/example.com.db >>>>> >>>>> That is all you need for DNS, you have the standard zone file. >>>>> >>>>> >>>>> I believe that you can use SSSD (with enumeration enabled) to run >>>>> "getent passwd > /root/passwd.bck". I have no idea how it works with >>>>> shadow map/password. Try to ask sssd-users at lists.fedorahosted.**org >>>>> . >>>>> >>>>> And to add to it: >>>> IPA does not keep password in clear or the hashes that are used in >>>> passwd and shadow files for security reasons so it can't generate these >>>> files as you suggest. >>>> >>> >>> We do have hashes, the default is SHA256, it is stored in userPassword >>> and is used to validate LDAP binds, however we never let it out of LDAP, >>> neither SSSD not the integrate NIS server expose the password hash to >>> clients. You need Directory Manager privileges to read it. >>> >> > ______________________________**_________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/**mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbulist at gmail.com Thu Sep 5 14:17:36 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Thu, 05 Sep 2013 09:17:36 -0500 Subject: [Freeipa-users] slapi-nis user password error Message-ID: <52289280.1030703@gmail.com> Hi, I have some services that need to work with a NIS server and I would like to use slapi-nis plugin in order to use just FreeIPA as our Directory Server. The users were imported from a openldap server and the password encryption is MD5. I installed slapi-nis in the server and configure a NIS client(Red Hat 5.9) with FreeIPA server (Red Hat 6.3, FreeIPA: 3.0.0-26). I'm able to get info of the users from NIS client (getent passwd user_id) but when the user try to log in to the NIS client the authentication fails. Slapi-nis was installed and configured using the default options. Any clue about this problem or How can I debug this? Thanks!! CBU From abokovoy at redhat.com Thu Sep 5 14:47:34 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Sep 2013 17:47:34 +0300 Subject: [Freeipa-users] slapi-nis user password error In-Reply-To: <52289280.1030703@gmail.com> References: <52289280.1030703@gmail.com> Message-ID: <20130905144734.GP21212@redhat.com> On Thu, 05 Sep 2013, cbulist at gmail.com wrote: >Hi, > >I have some services that need to work with a NIS server and I would >like to use slapi-nis plugin in order to use just FreeIPA as our >Directory Server. >The users were imported from a openldap server and the password >encryption is MD5. >I installed slapi-nis in the server and configure a NIS client(Red Hat >5.9) with FreeIPA server (Red Hat 6.3, FreeIPA: 3.0.0-26). >I'm able to get info of the users from NIS client (getent passwd >user_id) but when the user try to log in to the NIS client the >authentication fails. >Slapi-nis was installed and configured using the default options. >Any clue about this problem or How can I debug this? From what you are describing, it looks like what I have fixed recently in slapi-nis as side-effect of adding support for trusted domains. Not sure if Nalin has backported this fix to older versions (slapi-nis 0.48 is in Fedora 19 at this point) but filing a bug against RHEL 6.3 would help in promoting the fix to stable packages. -- / Alexander Bokovoy From bret.wortman at damascusgrp.com Thu Sep 5 14:49:20 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Thu, 5 Sep 2013 10:49:20 -0400 Subject: [Freeipa-users] Exporting data? In-Reply-To: References: <52273507.8020606@redhat.com> <5227383A.2090207@redhat.com> <1378315945.13768.114.camel@willson.li.ssimo.org> <522825B4.2010800@redhat.com> Message-ID: That worked for one out of 24 zones. Dig gave the same error on the rest: # dig +onesoa -t AXFR foo.net ; <<>> DiG 99.3-rl.156.01-P1-RedHat-9.9.3-3.P1.fc18 <<>> +onesoa -t AXFR foo.net ;; global options: +cmd ; Transfer failed. # /var/log/messages errors at the same time with: named[925]: LDAP error: Size limit exceeded named[925]: connection to the LDAP server was lost named[925]: successfully reconnected to LDAP server I think my master has, to stick with technical terminology, "completely lost the plot". And I'm equally certain it's because of something I did to it.... * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Thu, Sep 5, 2013 at 7:48 AM, Bret Wortman wrote: > D'Oh! Thanks, Petr. > > > * > * > *Bret Wortman* > > http://damascusgrp.com/ > http://about.me/wortmanbret > > > On Thu, Sep 5, 2013 at 2:33 AM, Petr Spacek wrote: > >> On 4.9.2013 20:23, Bret Wortman wrote: >> >>> ...and I tried exporting the DNS data but ended up with a bunch of files >>> that looked liket his: >>> >>> # cat foo.net.db >>> >>> ; <<>> DiG 9.9.3-rl.156.01.P1-RedHat-9.9.**3-3.P1.fc18 <<>> +onesoa -t >>> AXFR >>> foo.net >>> ;; global options: +cmd >>> ; Transfer failed. >>> # >>> >>> The logs showed: >>> >>> ipamaster named[31633]: client 1.2.3.4#39992 (foo.net) : >>> zone >>> transfer 'foo.net/AXFR/IN' denied >>> >> >> You have to add IP '1.2.3.4' to the allow-transfer Address List Match. >> >> $ ipa dnszone-mod --allow-transfer='localhost; 1.2.3.4;' >> >> See >> http://www.zytrax.com/books/**dns/ch7/address_match_list.**html >> for further details. >> >> Petr^2 Spacek >> >> >> On Wed, Sep 4, 2013 at 1:32 PM, Simo Sorce wrote: >>> >>> On Wed, 2013-09-04 at 09:40 -0400, Dmitri Pal wrote: >>>> >>>>> On 09/04/2013 09:26 AM, Petr Spacek wrote: >>>>> >>>>>> On 4.9.2013 15:04, Bret Wortman wrote: >>>>>> >>>>>>> What's the right venue for making a suggestion? In particular, I'd >>>>>>> like to >>>>>>> toss out there that it would be really nice to be able to export, at >>>>>>> a >>>>>>> minimum, DNS and user data from IPA in the form of a zone file and a >>>>>>> passwd/shadow file pair. >>>>>>> >>>>>>> I realize there might be security implications to the latter, and >>>>>>> masking >>>>>>> out passwords might be advisiable. And there's no easy way, >>>>>>> necessarily, to >>>>>>> get out sudo information. But having DNS and user details would at >>>>>>> >>>>>> least >>>> >>>>> permit a sysadmin having major issues (like I have been for the past >>>>>>> >>>>>> two >>>> >>>>> weeks) to get up and running in some form, using puppet or some other >>>>>>> tool >>>>>>> to distribute flat files with named running against a static zone >>>>>>> file, or >>>>>>> even to migrate off IPA if absolutely necessary. >>>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> for DNS you can use normal zone transfer. Just configure IPA zone to >>>>>> allow zone transfer to an IP address (localhost means 'localy to IPA >>>>>> server') and use standard DNS tools, e.g. dig: >>>>>> >>>>>> $ ipa dnszone-mod example.com --allow-transfer='localhost;' >>>>>> $ dig +onesoa -t AXFR example.com > /root/example.com.db >>>>>> >>>>>> That is all you need for DNS, you have the standard zone file. >>>>>> >>>>>> >>>>>> I believe that you can use SSSD (with enumeration enabled) to run >>>>>> "getent passwd > /root/passwd.bck". I have no idea how it works with >>>>>> shadow map/password. Try to ask sssd-users at lists.fedorahosted.**org >>>>>> . >>>>>> >>>>>> And to add to it: >>>>> IPA does not keep password in clear or the hashes that are used in >>>>> passwd and shadow files for security reasons so it can't generate these >>>>> files as you suggest. >>>>> >>>> >>>> We do have hashes, the default is SHA256, it is stored in userPassword >>>> and is used to validate LDAP binds, however we never let it out of LDAP, >>>> neither SSSD not the integrate NIS server expose the password hash to >>>> clients. You need Directory Manager privileges to read it. >>>> >>> >> ______________________________**_________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/**mailman/listinfo/freeipa-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Sep 5 14:59:19 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Sep 2013 10:59:19 -0400 Subject: [Freeipa-users] slapi-nis user password error In-Reply-To: <20130905144734.GP21212@redhat.com> References: <52289280.1030703@gmail.com> <20130905144734.GP21212@redhat.com> Message-ID: <52289C47.1090806@redhat.com> On 09/05/2013 10:47 AM, Alexander Bokovoy wrote: > On Thu, 05 Sep 2013, cbulist at gmail.com wrote: >> Hi, >> >> I have some services that need to work with a NIS server and I would >> like to use slapi-nis plugin in order to use just FreeIPA as our >> Directory Server. >> The users were imported from a openldap server and the password >> encryption is MD5. >> I installed slapi-nis in the server and configure a NIS client(Red Hat >> 5.9) with FreeIPA server (Red Hat 6.3, FreeIPA: 3.0.0-26). >> I'm able to get info of the users from NIS client (getent passwd >> user_id) but when the user try to log in to the NIS client the >> authentication fails. >> Slapi-nis was installed and configured using the default options. >> Any clue about this problem or How can I debug this? > From what you are describing, it looks like what I have fixed recently > in slapi-nis as side-effect of adding support for trusted domains. > > Not sure if Nalin has backported this fix to older versions (slapi-nis > 0.48 is in Fedora 19 at this point) but filing a bug against RHEL 6.3 > would help in promoting the fix to stable packages. > Well... I should say that originally slapi-nis did not support binding. And it was not intended to support binding. We had to add binding to slapi-nis for other reasons not related to the use case at hand. I doubt that the change would be backported. Is there any other authentication method that you can use from those boxes? pam_krb5 or pam_ldap or may be something along those lines? What OS/version they are running? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pspacek at redhat.com Thu Sep 5 15:02:55 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 05 Sep 2013 17:02:55 +0200 Subject: [Freeipa-users] Exporting data? In-Reply-To: References: <52273507.8020606@redhat.com> <5227383A.2090207@redhat.com> <1378315945.13768.114.camel@willson.li.ssimo.org> <522825B4.2010800@redhat.com> Message-ID: <52289D1F.3090900@redhat.com> On 5.9.2013 16:49, Bret Wortman wrote: > That worked for one out of 24 zones. Dig gave the same error on the rest: > > # dig +onesoa -t AXFR foo.net > > ; <<>> DiG 99.3-rl.156.01-P1-RedHat-9.9.3-3.P1.fc18 <<>> +onesoa -t AXFR > foo.net > ;; global options: +cmd > ; Transfer failed. > # > > /var/log/messages errors at the same time with: > > named[925]: LDAP error: Size limit exceeded > named[925]: connection to the LDAP server was lost > named[925]: successfully reconnected to LDAP server > > I think my master has, to stick with technical terminology, "completely > lost the plot". And I'm equally certain it's because of something I did to > it.... Do you use Kerberos authentication for connection from named to LDAP? Did you change connection settings/credentials after installation? (in /etc/named.conf?) I guess that you need to disable size limits for the account used for connection between LDAP and named. Each object in LDAP has operational attributes nsIdleTimeout, nsLookThroughLimit, nsSizeLimit and nsTimeLimit. All of them should be set to "-1". Use your favorite LDAP browser to check the values. You can use attached LDIF as inspiration if you need to change values. Don't forget to change service (DNS) and host name (your_name_server_name.example.com), REALM NAME (EXAMPLE.COM) and domain name (example.com) before you try to import the LDIF. Just for the case, normal user accounts are stored under cn=users,cn=accounts,dc=example,dc=com but service accounts are stored under cn=services,cn=accounts,dc=example,dc=com. Petr^2 Spacek > On Thu, Sep 5, 2013 at 7:48 AM, Bret Wortman > wrote: > >> D'Oh! Thanks, Petr. >> >> >> * >> * >> *Bret Wortman* >> >> http://damascusgrp.com/ >> http://about.me/wortmanbret >> >> >> On Thu, Sep 5, 2013 at 2:33 AM, Petr Spacek wrote: >> >>> On 4.9.2013 20:23, Bret Wortman wrote: >>> >>>> ...and I tried exporting the DNS data but ended up with a bunch of files >>>> that looked liket his: >>>> >>>> # cat foo.net.db >>>> >>>> ; <<>> DiG 9.9.3-rl.156.01.P1-RedHat-9.9.**3-3.P1.fc18 <<>> +onesoa -t >>>> AXFR >>>> foo.net >>>> ;; global options: +cmd >>>> ; Transfer failed. >>>> # >>>> >>>> The logs showed: >>>> >>>> ipamaster named[31633]: client 1.2.3.4#39992 (foo.net) : >>>> zone >>>> transfer 'foo.net/AXFR/IN' denied >>>> >>> >>> You have to add IP '1.2.3.4' to the allow-transfer Address List Match. >>> >>> $ ipa dnszone-mod --allow-transfer='localhost; 1.2.3.4;' >>> >>> See >>> http://www.zytrax.com/books/**dns/ch7/address_match_list.**html >>> for further details. >>> >>> Petr^2 Spacek >>> >>> >>> On Wed, Sep 4, 2013 at 1:32 PM, Simo Sorce wrote: >>>> >>>> On Wed, 2013-09-04 at 09:40 -0400, Dmitri Pal wrote: >>>>> >>>>>> On 09/04/2013 09:26 AM, Petr Spacek wrote: >>>>>> >>>>>>> On 4.9.2013 15:04, Bret Wortman wrote: >>>>>>> >>>>>>>> What's the right venue for making a suggestion? In particular, I'd >>>>>>>> like to >>>>>>>> toss out there that it would be really nice to be able to export, at >>>>>>>> a >>>>>>>> minimum, DNS and user data from IPA in the form of a zone file and a >>>>>>>> passwd/shadow file pair. >>>>>>>> >>>>>>>> I realize there might be security implications to the latter, and >>>>>>>> masking >>>>>>>> out passwords might be advisiable. And there's no easy way, >>>>>>>> necessarily, to >>>>>>>> get out sudo information. But having DNS and user details would at >>>>>>>> >>>>>>> least >>>>> >>>>>> permit a sysadmin having major issues (like I have been for the past >>>>>>>> >>>>>>> two >>>>> >>>>>> weeks) to get up and running in some form, using puppet or some other >>>>>>>> tool >>>>>>>> to distribute flat files with named running against a static zone >>>>>>>> file, or >>>>>>>> even to migrate off IPA if absolutely necessary. >>>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> for DNS you can use normal zone transfer. Just configure IPA zone to >>>>>>> allow zone transfer to an IP address (localhost means 'localy to IPA >>>>>>> server') and use standard DNS tools, e.g. dig: >>>>>>> >>>>>>> $ ipa dnszone-mod example.com --allow-transfer='localhost;' >>>>>>> $ dig +onesoa -t AXFR example.com > /root/example.com.db >>>>>>> >>>>>>> That is all you need for DNS, you have the standard zone file. >>>>>>> >>>>>>> >>>>>>> I believe that you can use SSSD (with enumeration enabled) to run >>>>>>> "getent passwd > /root/passwd.bck". I have no idea how it works with >>>>>>> shadow map/password. Try to ask sssd-users at lists.fedorahosted.**org >>>>>>> . >>>>>>> >>>>>>> And to add to it: >>>>>> IPA does not keep password in clear or the hashes that are used in >>>>>> passwd and shadow files for security reasons so it can't generate these >>>>>> files as you suggest. >>>>>> >>>>> >>>>> We do have hashes, the default is SHA256, it is stored in userPassword >>>>> and is used to validate LDAP binds, however we never let it out of LDAP, >>>>> neither SSSD not the integrate NIS server expose the password hash to >>>>> clients. You need Directory Manager privileges to read it. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: dns-principal.ldif Type: text/x-ldif Size: 199 bytes Desc: not available URL: From cbulist at gmail.com Thu Sep 5 15:01:58 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Thu, 05 Sep 2013 10:01:58 -0500 Subject: [Freeipa-users] slapi-nis user password error In-Reply-To: <20130905144734.GP21212@redhat.com> References: <52289280.1030703@gmail.com> <20130905144734.GP21212@redhat.com> Message-ID: <52289CE6.3080601@gmail.com> Hi Alexander, Thanks so much for you reply. Do you know if there is a patch available for RH 6.3 that I can use?... Thanks again, On 09/05/2013 09:47 AM, Alexander Bokovoy wrote: > On Thu, 05 Sep 2013, cbulist at gmail.com wrote: >> Hi, >> >> I have some services that need to work with a NIS server and I would >> like to use slapi-nis plugin in order to use just FreeIPA as our >> Directory Server. >> The users were imported from a openldap server and the password >> encryption is MD5. >> I installed slapi-nis in the server and configure a NIS client(Red Hat >> 5.9) with FreeIPA server (Red Hat 6.3, FreeIPA: 3.0.0-26). >> I'm able to get info of the users from NIS client (getent passwd >> user_id) but when the user try to log in to the NIS client the >> authentication fails. >> Slapi-nis was installed and configured using the default options. >> Any clue about this problem or How can I debug this? > From what you are describing, it looks like what I have fixed recently > in slapi-nis as side-effect of adding support for trusted domains. > > Not sure if Nalin has backported this fix to older versions (slapi-nis > 0.48 is in Fedora 19 at this point) but filing a bug against RHEL 6.3 > would help in promoting the fix to stable packages. > From abokovoy at redhat.com Thu Sep 5 15:09:08 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Sep 2013 18:09:08 +0300 Subject: [Freeipa-users] slapi-nis user password error In-Reply-To: <52289CE6.3080601@gmail.com> References: <52289280.1030703@gmail.com> <20130905144734.GP21212@redhat.com> <52289CE6.3080601@gmail.com> Message-ID: <20130905150908.GQ21212@redhat.com> On Thu, 05 Sep 2013, cbulist at gmail.com wrote: >Hi Alexander, > >Thanks so much for you reply. > >Do you know if there is a patch available for RH 6.3 that I can use?... There is no backport available. Look at the Dmitri's answer as well. You can authenticate these boxes through pam_krb5 in combination with slapi-nis identity source, for example. -- / Alexander Bokovoy From nalin at redhat.com Thu Sep 5 15:11:32 2013 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 5 Sep 2013 11:11:32 -0400 Subject: [Freeipa-users] slapi-nis user password error In-Reply-To: <52289280.1030703@gmail.com> References: <52289280.1030703@gmail.com> Message-ID: <20130905151132.GA15310@redhat.com> On Thu, Sep 05, 2013 at 09:17:36AM -0500, cbulist at gmail.com wrote: > The users were imported from a openldap server and the password > encryption is MD5. Is that {CRYPT} using an md5-based crypt, or {MD5} or {SMD5}? A client that's trying to check passwords using hashes which it reads via NIS is usually only compatible with hashes that are identified with {CRYPT}. > I installed slapi-nis in the server and configure a NIS client(Red Hat > 5.9) with FreeIPA server (Red Hat 6.3, FreeIPA: 3.0.0-26). > I'm able to get info of the users from NIS client (getent passwd > user_id) but when the user try to log in to the NIS client the > authentication fails. Which authentication mechanism did you configure in combination with NIS for user information? > Slapi-nis was installed and configured using the default options. > Any clue about this problem or How can I debug this? If you're using pam_unix (which you probably are, if you're using neither LDAP nor Kerberos for authenticating users), then you need to have {CRYPT} hashes in your user entries. If you don't have those, you'll need to remedy that first, by configuring the server to use the CRYPT password storage scheme (IIRC the default is SSHA), and then forcing some password changes. After that, the default configuration for the version of slapi-nis you have should cause them to start showing up when you use getent (or ypmatch) to read the user's entry from the passwd map. Then you can double-check that a password is correct by taking a hashed value and a candidate password and running them through something like python -c 'import crypt; print crypt.crypt("password","hash")' to check if hashing the password using the salt that's part of the hashed value reproduces the hashed value, which is more or less what pam_unix does to check the password. That all said, I'd recommend using SSSD's support for reading identity information via LDAP, or better still its IPA provider, which can interact with the IPA server when it's in migration mode, and start moving you toward being able to switch over to using Kerberos. HTH, Nalin From cbulist at gmail.com Thu Sep 5 16:50:08 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Thu, 05 Sep 2013 11:50:08 -0500 Subject: [Freeipa-users] slapi-nis user password error In-Reply-To: <20130905151132.GA15310@redhat.com> References: <52289280.1030703@gmail.com> <20130905151132.GA15310@redhat.com> Message-ID: <5228B640.3040506@gmail.com> Nalin, Alexander and Dmitri, Thanks so much for help and clarified me some points. Yes, we are using {CRYPT} and after configure Kerberos for authentication we are able to log in. Again, thank so much! On 09/05/2013 10:11 AM, Nalin Dahyabhai wrote: > On Thu, Sep 05, 2013 at 09:17:36AM -0500, cbulist at gmail.com wrote: >> The users were imported from a openldap server and the password >> encryption is MD5. > Is that {CRYPT} using an md5-based crypt, or {MD5} or {SMD5}? A client > that's trying to check passwords using hashes which it reads via NIS is > usually only compatible with hashes that are identified with {CRYPT}. > >> I installed slapi-nis in the server and configure a NIS client(Red Hat >> 5.9) with FreeIPA server (Red Hat 6.3, FreeIPA: 3.0.0-26). >> I'm able to get info of the users from NIS client (getent passwd >> user_id) but when the user try to log in to the NIS client the >> authentication fails. > Which authentication mechanism did you configure in combination with NIS > for user information? > >> Slapi-nis was installed and configured using the default options. >> Any clue about this problem or How can I debug this? > If you're using pam_unix (which you probably are, if you're using > neither LDAP nor Kerberos for authenticating users), then you need to > have {CRYPT} hashes in your user entries. If you don't have those, > you'll need to remedy that first, by configuring the server to use the > CRYPT password storage scheme (IIRC the default is SSHA), and then > forcing some password changes. After that, the default configuration > for the version of slapi-nis you have should cause them to start showing > up when you use getent (or ypmatch) to read the user's entry from the > passwd map. > > Then you can double-check that a password is correct by taking a hashed > value and a candidate password and running them through something like > > python -c 'import crypt; print crypt.crypt("password","hash")' > > to check if hashing the password using the salt that's part of the > hashed value reproduces the hashed value, which is more or less what > pam_unix does to check the password. > > That all said, I'd recommend using SSSD's support for reading identity > information via LDAP, or better still its IPA provider, which can > interact with the IPA server when it's in migration mode, and start > moving you toward being able to switch over to using Kerberos. > > HTH, > > Nalin From jdennis at redhat.com Thu Sep 5 16:59:22 2013 From: jdennis at redhat.com (John Dennis) Date: Thu, 05 Sep 2013 12:59:22 -0400 Subject: [Freeipa-users] Ldap schema In-Reply-To: <522824BA.3090206@redhat.com> References: <24d47e92.00005b94.0000004d@JPROUTY-WIN7.cctus.com> <5227B370.7040408@redhat.com> <522824BA.3090206@redhat.com> Message-ID: <5228B86A.7030808@redhat.com> On 09/05/2013 02:29 AM, Dmitri Pal wrote: > On 09/05/2013 12:38 AM, Jason Prouty wrote: >> This is the AV-Pair I would like to implement to pass back to radius. >> >> >> dn: cn=priv-15,ou=cisco,ou=radius,dc=example,dc=com >> objectClass: radiusObjectProfile >> objectClass: radiusprofile >> cn: priv-15 >> radiusReplyItem: cisco-avpair = "shell:priv-lvl=15" > > The question was why you need to use IPA as a storage for profiles? > It looks like you are not using FreeRADIUS. Is this the case? I already answered him privately. He is using FreeRADIUS and wants to use IPA's ldap for performing lookup's inside radiusd in order to add an attribute to the AccessAccept reply. Radius profiles in LDAP are one way to do this, but it means adding schema to 389ds. My suggestion is to use IPA's ability to put users into groups. Then in FreeRADIUS's unlang policy language use the group to add the attribute to the reply. Something along the lines of this in the post-auth section should do the trick (not 100% sure it's correct syntax): post-auth { if(Ldap-Group == "xxx") { update reply { cisco-avpair = "shell:priv-lvl=15" } } } You'll need to lookup the group in the authorize section with a search crafted for IPA. If there are a lot of different reply attributes this becomes cumbersome and some type of extra schema would be needed, but if there are only a handful of attributes putting it in the radius config is reasonable. -- John From bwellsnc at gmail.com Sat Sep 7 00:12:48 2013 From: bwellsnc at gmail.com (bwellsnc) Date: Fri, 6 Sep 2013 20:12:48 -0400 Subject: [Freeipa-users] IPA, Named and DHCP Message-ID: Hello. I am working on implementing several new things at my company, IPA, a new DHCP server, and a new named server. The problem is that I am running an infrastructure with Windows, Linux, and Mac. This means that DNS entries cannot be kept up to date using the windows/mac side because they are not part of IPA. The current DHCP/Named instance I am replacing does named updates from DHCP. I am wondering, can the named instance used by IPA be updated using DHCP. The ideal situation would be for DHCP to be allowed to automatically make additions to IPA's DNS server, even if there is no entry for that host. Can something like this be implemented with ipa: http://edmann.com/Computers-Technology/2008/01/08/ISC-DHCP-and-Ldap-Backend Thanks! Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Sat Sep 7 16:36:51 2013 From: simo at redhat.com (Simo Sorce) Date: Sat, 07 Sep 2013 12:36:51 -0400 Subject: [Freeipa-users] IPA, Named and DHCP In-Reply-To: References: Message-ID: <1378571811.2804.1249.camel@willson.li.ssimo.org> On Fri, 2013-09-06 at 20:12 -0400, bwellsnc wrote: > Hello. I am working on implementing several new things at my > company, IPA, a new DHCP server, and a new named server. The problem > is that I am running an infrastructure with Windows, Linux, and Mac. > This means that DNS entries cannot be kept up to date using the > windows/mac side because they are not part of IPA. The current > DHCP/Named instance I am replacing does named updates from DHCP. I am > wondering, can the named instance used by IPA be updated using DHCP. > The ideal situation would be for DHCP to be allowed to automatically > make additions to IPA's DNS server, even if there is no entry for that > host. Can something like this be implemented with ipa: > > > http://edmann.com/Computers-Technology/2008/01/08/ISC-DHCP-and-Ldap-Backend > The LDAP backend for ISC DHCP is used to store dhcp data, but wouldn't be very useful for your purpose. If you can run a script from the DHCP server when a machine registers, then what you can do is to create a user/service allowed to modify DNS entries (aadding a named ACI to the relative zone) and then simply use the script to call 'nsupdate' and issue GSS-TSIG signed dns update requests. Simo. -- Simo Sorce * Red Hat, Inc * New York From deanhunter at comcast.net Sat Sep 7 17:06:37 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Sat, 07 Sep 2013 12:06:37 -0500 Subject: [Freeipa-users] freeipa and sudo Message-ID: <1378573597.16595.5.camel@host.hunter.org> Are [1] and[2] still the current and best sources of information for configuring sudo for use with the current release of FreeIPA on Fedora 19? 1. http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html 2. http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf Is there anything missing from these documents or anything that bears special note as I start adding sudo to my configuration? -------------- next part -------------- An HTML attachment was scrubbed... URL: From chorn at fluxcoil.net Sat Sep 7 18:11:29 2013 From: chorn at fluxcoil.net (Christian Horn) Date: Sat, 7 Sep 2013 20:11:29 +0200 Subject: [Freeipa-users] freeipa and sudo In-Reply-To: <1378573597.16595.5.camel@host.hunter.org> References: <1378573597.16595.5.camel@host.hunter.org> Message-ID: <20130907181129.GA23695@fluxcoil.net> On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote: > Are [1] and[2] still the current and best sources of information for > configuring sudo for use with the current release of FreeIPA on Fedora > 19? > > 1. > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html > 2. > http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf There is also the Identity_Management_Guide as part of the RHEL product documentation: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html Christian From dpal at redhat.com Sat Sep 7 23:35:21 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 07 Sep 2013 19:35:21 -0400 Subject: [Freeipa-users] freeipa and sudo In-Reply-To: <20130907181129.GA23695@fluxcoil.net> References: <1378573597.16595.5.camel@host.hunter.org> <20130907181129.GA23695@fluxcoil.net> Message-ID: <522BB839.7030203@redhat.com> On 09/07/2013 02:11 PM, Christian Horn wrote: > On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote: >> Are [1] and[2] still the current and best sources of information for >> configuring sudo for use with the current release of FreeIPA on Fedora >> 19? >> >> 1. >> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html >> 2. >> http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > There is also the Identity_Management_Guide as part of the RHEL > product documentation: > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html This and the pdf above are the latest word in this area. > Christian > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From andrew at andrewklau.com Sun Sep 8 03:54:47 2013 From: andrew at andrewklau.com (Andrew Lau) Date: Sun, 8 Sep 2013 13:54:47 +1000 Subject: [Freeipa-users] Split Horizon DNS on IPA? Message-ID: Hi all, I wasn't able to find much, but is it possible to configure FreeIPA to serve as a split horizon DNS server? I would like the local network to be able to enroll and authenticate locally, but at the same time bridge remote clients as well. Suggestions? Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From deanhunter at comcast.net Sun Sep 8 20:42:16 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Sun, 08 Sep 2013 15:42:16 -0500 Subject: [Freeipa-users] freeipa and sudo In-Reply-To: <522BB839.7030203@redhat.com> References: <1378573597.16595.5.camel@host.hunter.org> <20130907181129.GA23695@fluxcoil.net> <522BB839.7030203@redhat.com> Message-ID: <1378672936.24034.5.camel@host.hunter.org> On Sat, 2013-09-07 at 19:35 -0400, Dmitri Pal wrote: > On 09/07/2013 02:11 PM, Christian Horn wrote: > > On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote: > >> Are [1] and[2] still the current and best sources of information for > >> configuring sudo for use with the current release of FreeIPA on Fedora > >> 19? > >> > >> 1. > >> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html > >> 2. > >> http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > > There is also the Identity_Management_Guide as part of the RHEL > > product documentation: > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html > This and the pdf above are the latest word in this area. > > > Christian > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Some sudo rules are causing: [dean at desktop2 ~]$ sudo id sudo: internal error, tried to erealloc3(0) , but others do not. In the trial and error process of determining which rule specifications are causing the error, I have been restarting the virtual machine I am using as the sudo client between tests. Is there a better way to clear the SSSD cache between trials to make sure I am testing the most recent rule change? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Sun Sep 8 21:11:22 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 8 Sep 2013 23:11:22 +0200 Subject: [Freeipa-users] freeipa and sudo In-Reply-To: <1378672936.24034.5.camel@host.hunter.org> References: <1378573597.16595.5.camel@host.hunter.org> <20130907181129.GA23695@fluxcoil.net> <522BB839.7030203@redhat.com> <1378672936.24034.5.camel@host.hunter.org> Message-ID: <20130908211122.GA11616@hendrix.redhat.com> On Sun, Sep 08, 2013 at 03:42:16PM -0500, Dean Hunter wrote: > On Sat, 2013-09-07 at 19:35 -0400, Dmitri Pal wrote: > > > On 09/07/2013 02:11 PM, Christian Horn wrote: > > > On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote: > > >> Are [1] and[2] still the current and best sources of information for > > >> configuring sudo for use with the current release of FreeIPA on Fedora > > >> 19? > > >> > > >> 1. > > >> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html > > >> 2. > > >> http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > > > There is also the Identity_Management_Guide as part of the RHEL > > > product documentation: > > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html > > This and the pdf above are the latest word in this area. > > > > > Christian > > > > > > _______________________________________________ > > > Freeipa-users mailing list > > > Freeipa-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > Some sudo rules are causing: > > [dean at desktop2 ~]$ sudo id > sudo: internal error, tried to erealloc3(0) This is a known bug: https://bugzilla.redhat.com/show_bug.cgi?id=1000389 I think the sudo rules are just missing the sudoHost attribute. > > , but others do not. In the trial and error process of determining > which rule specifications are causing the error, I have been restarting > the virtual machine I am using as the sudo client between tests. Is > there a better way to clear the SSSD cache between trials to make sure I > am testing the most recent rule change? Unfortunately right now the only way is to rm the sssd cache which would also remove any cached credentials. I thought there was an RFE open to track the enhancement to make sss_cache invalidate and refresh sudo rules, but I can't find it now in the SSSD trac, so I filed another one: https://fedorahosted.org/sssd/ticket/2081 Worst case, we mark it as a duplicate. From deanhunter at comcast.net Sun Sep 8 22:26:27 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Sun, 08 Sep 2013 17:26:27 -0500 Subject: [Freeipa-users] freeipa and sudo In-Reply-To: <20130908211122.GA11616@hendrix.redhat.com> References: <1378573597.16595.5.camel@host.hunter.org> <20130907181129.GA23695@fluxcoil.net> <522BB839.7030203@redhat.com> <1378672936.24034.5.camel@host.hunter.org> <20130908211122.GA11616@hendrix.redhat.com> Message-ID: <1378679187.24034.15.camel@host.hunter.org> On Sun, 2013-09-08 at 23:11 +0200, Jakub Hrozek wrote: > On Sun, Sep 08, 2013 at 03:42:16PM -0500, Dean Hunter wrote: > > On Sat, 2013-09-07 at 19:35 -0400, Dmitri Pal wrote: > > > > > On 09/07/2013 02:11 PM, Christian Horn wrote: > > > > On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote: > > > >> Are [1] and[2] still the current and best sources of information for > > > >> configuring sudo for use with the current release of FreeIPA on Fedora > > > >> 19? > > > >> > > > >> 1. > > > >> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html > > > >> 2. > > > >> http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > > > > There is also the Identity_Management_Guide as part of the RHEL > > > > product documentation: > > > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html > > > This and the pdf above are the latest word in this area. > > > > > > > Christian > > > > > > > > _______________________________________________ > > > > Freeipa-users mailing list > > > > Freeipa-users at redhat.com > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > > > > Some sudo rules are causing: > > > > [dean at desktop2 ~]$ sudo id > > sudo: internal error, tried to erealloc3(0) > > This is a known bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1000389 > > I think the sudo rules are just missing the sudoHost attribute. > > > > > , but others do not. In the trial and error process of determining > > which rule specifications are causing the error, I have been restarting > > the virtual machine I am using as the sudo client between tests. Is > > there a better way to clear the SSSD cache between trials to make sure I > > am testing the most recent rule change? > > Unfortunately right now the only way is to rm the sssd cache which would > also remove any cached credentials. I thought there was an RFE open to > track the enhancement to make sss_cache invalidate and refresh sudo > rules, but I can't find it now in the SSSD trac, so I filed another one: > https://fedorahosted.org/sssd/ticket/2081 > > Worst case, we mark it as a duplicate. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users I saw bug report 1000389, but I could not understand it or whether it applied to me. I discovered that sudo rules for which I specified a host group caused the error. Rules with a host category of "all" instead of the host group did not cause the error. Is this what 1000389 says? ipa sudorule-add server-admins --desc "Server Administrators" ipa sudorule-mod server-admins --cmdcat all # ipa sudorule-add-host server-admins --hostgroups servers ipa sudorule-mod server-admins --hostcat all ipa sudorule-add-option server-admins --sudooption '! authenticate' ipa sudorule-add-runasuser server-admins --users root ipa sudorule-add-runasgroup server-admins --groups root ipa sudorule-add-user server-admins --groups server-admins This problem exists with the latest updates on both Fedora 18 and Fedora 19. I also discovered that libsss_sudo.so is missing from Fedora 18 installations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Mon Sep 9 07:30:52 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 9 Sep 2013 03:30:52 -0400 Subject: [Freeipa-users] Trouble in ipa-ca-install Message-ID: I've had some great success in the past 48 hours in recovering my system. Here's where I stand right now: 1. I successfully stood up a new replica (ipamaster7) and transferred CA authority to it from my old master (ipamaster). 2. I shutdown ipamaster and re-baselined it. 3. I created a new replica file from ipamaster7 for ipamaster (to transfer everything back). 4. I reinstalled the IPA software on ipamaster. I also made a small change to CS.cfg to work around my earlier CA problem. 5. I ran "ipa-replica-install --setup-dns --no-forwarders replica-info-ipamaster.foo.net.gpg", which ran to completion. 6. I attempted to run "ipa-ca-install replica-info-ipamaster.foo.net.gpg", which failed due to a 403 error. /var/log/ipareplica-ca-install.log showed this: 2013-09-09T07:10:30Z DEBUG Starting external process 2013-09-09T07:10:30Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpyIMTdo 2013-09-09T07:10:31Z DEBUG Process finished, return code=1 2013-09-09T07:10:31Z DEBUG stdout=Loading deployment configuration from /tmp/tmpyIMTdo. ERROR: Unable to access security domain: 403 Client Error: Forbidden 2013-09-09T07:10:31Z DEBUG stderr= 2013-09-09T07:10:31Z CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpyIMTdo' returned non-zero exit status 1 2013-09-09T07:10:31Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 619, in run_script return_value = main_function() File "/usr/sbin/ipa-ca-install", line 182, in main config, dogtag_master_ds_port, postinstall=True) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 1809, in install_replica_ca subject_base=config.subject_base) File "/usr/ib/python2.7/site-packages/ipaserver/install/cainstance.py", line625, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 358, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 744, in __spawn_instance raise RuntimeError('Configuration of CA failed') 2013-09-09T07:10:31Z INFO The ipa-ca-install command failed, exception: RuntimeError: Configuration of CA failed Does this look familiar to anyone? I'd like to complete the transition back to ipamaster so that I can then finish cleaning up the dead replicas. Until I can do this, I'll have to leave ipamaster7 in place as my master. Thanks! * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrezina at redhat.com Mon Sep 9 09:23:35 2013 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Mon, 09 Sep 2013 11:23:35 +0200 Subject: [Freeipa-users] freeipa and sudo In-Reply-To: <522BB839.7030203@redhat.com> References: <1378573597.16595.5.camel@host.hunter.org> <20130907181129.GA23695@fluxcoil.net> <522BB839.7030203@redhat.com> Message-ID: <522D9397.20504@redhat.com> On 09/08/2013 01:35 AM, Dmitri Pal wrote: > On 09/07/2013 02:11 PM, Christian Horn wrote: >> On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote: >>> Are [1] and[2] still the current and best sources of information for >>> configuring sudo for use with the current release of FreeIPA on Fedora >>> 19? >>> >>> 1. >>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html >>> 2. >>> http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >> There is also the Identity_Management_Guide as part of the RHEL >> product documentation: >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html > This and the pdf above are the latest word in this area. Hi, those documents describes configuration for SSSD 1.9. Although it is still valid, we have simplified configuration for IPA provider in 1.10. The most up to date document for your version of SSSD is always man sssd-sudo. From pbrezina at redhat.com Mon Sep 9 09:29:23 2013 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Mon, 09 Sep 2013 11:29:23 +0200 Subject: [Freeipa-users] freeipa and sudo In-Reply-To: <20130908211122.GA11616@hendrix.redhat.com> References: <1378573597.16595.5.camel@host.hunter.org> <20130907181129.GA23695@fluxcoil.net> <522BB839.7030203@redhat.com> <1378672936.24034.5.camel@host.hunter.org> <20130908211122.GA11616@hendrix.redhat.com> Message-ID: <522D94F3.9050301@redhat.com> On 09/08/2013 11:11 PM, Jakub Hrozek wrote: > On Sun, Sep 08, 2013 at 03:42:16PM -0500, Dean Hunter wrote: >> On Sat, 2013-09-07 at 19:35 -0400, Dmitri Pal wrote: >> >>> On 09/07/2013 02:11 PM, Christian Horn wrote: >>>> On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote: >>>>> Are [1] and[2] still the current and best sources of information for >>>>> configuring sudo for use with the current release of FreeIPA on Fedora >>>>> 19? >>>>> >>>>> 1. >>>>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html >>>>> 2. >>>>> http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >>>> There is also the Identity_Management_Guide as part of the RHEL >>>> product documentation: >>>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html >>> This and the pdf above are the latest word in this area. >>> >>>> Christian >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >> >> Some sudo rules are causing: >> >> [dean at desktop2 ~]$ sudo id >> sudo: internal error, tried to erealloc3(0) > > This is a known bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1000389 > > I think the sudo rules are just missing the sudoHost attribute. > >> >> , but others do not. In the trial and error process of determining >> which rule specifications are causing the error, I have been restarting >> the virtual machine I am using as the sudo client between tests. Is >> there a better way to clear the SSSD cache between trials to make sure I >> am testing the most recent rule change? > > Unfortunately right now the only way is to rm the sssd cache which would > also remove any cached credentials. You don't necessarily have to remove the cache. If you just restart SSSD the rules will be refreshed in approximately 15 seconds. I thought there was an RFE open to > track the enhancement to make sss_cache invalidate and refresh sudo > rules, but I can't find it now in the SSSD trac, so I filed another one: > https://fedorahosted.org/sssd/ticket/2081 > > Worst case, we mark it as a duplicate. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From pbrezina at redhat.com Mon Sep 9 09:35:52 2013 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Mon, 09 Sep 2013 11:35:52 +0200 Subject: [Freeipa-users] freeipa and sudo In-Reply-To: <1378679187.24034.15.camel@host.hunter.org> References: <1378573597.16595.5.camel@host.hunter.org> <20130907181129.GA23695@fluxcoil.net> <522BB839.7030203@redhat.com> <1378672936.24034.5.camel@host.hunter.org> <20130908211122.GA11616@hendrix.redhat.com> <1378679187.24034.15.camel@host.hunter.org> Message-ID: <522D9678.5020005@redhat.com> On 09/09/2013 12:26 AM, Dean Hunter wrote: > On Sun, 2013-09-08 at 23:11 +0200, Jakub Hrozek wrote: >> On Sun, Sep 08, 2013 at 03:42:16PM -0500, Dean Hunter wrote: >> > On Sat, 2013-09-07 at 19:35 -0400, Dmitri Pal wrote: >> > >> > > On 09/07/2013 02:11 PM, Christian Horn wrote: >> > > > On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote: >> > > >> Are [1] and[2] still the current and best sources of information for >> > > >> configuring sudo for use with the current release of FreeIPA on Fedora >> > > >> 19? >> > > >> >> > > >> 1. >> > > >>http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html >> > > >> 2. >> > > >>http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >> > > > There is also the Identity_Management_Guide as part of the RHEL >> > > > product documentation: >> > > >https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html >> > > This and the pdf above are the latest word in this area. >> > > >> > > > Christian >> > > > >> > > > _______________________________________________ >> > > > Freeipa-users mailing list >> > > >Freeipa-users at redhat.com >> > > >https://www.redhat.com/mailman/listinfo/freeipa-users >> > > >> > > >> > >> > Some sudo rules are causing: >> > >> > [dean at desktop2 ~]$ sudo id >> > sudo: internal error, tried to erealloc3(0) >> >> This is a known bug: >> https://bugzilla.redhat.com/show_bug.cgi?id=1000389 >> >> I think the sudo rules are just missing the sudoHost attribute. >> >> > >> > , but others do not. In the trial and error process of determining >> > which rule specifications are causing the error, I have been restarting >> > the virtual machine I am using as the sudo client between tests. Is >> > there a better way to clear the SSSD cache between trials to make sure I >> > am testing the most recent rule change? >> >> Unfortunately right now the only way is to rm the sssd cache which would >> also remove any cached credentials. I thought there was an RFE open to >> track the enhancement to make sss_cache invalidate and refresh sudo >> rules, but I can't find it now in the SSSD trac, so I filed another one: >> https://fedorahosted.org/sssd/ticket/2081 >> >> Worst case, we mark it as a duplicate. >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > I saw bug report 1000389, but I could not understand it or whether it > applied to me. > > I discovered that sudo rules for which I specified a host group caused > the error. Rules with a host category of "all" instead of the host > group did not cause the error. Is this what 1000389 says? > > ipa sudorule-add server-admins --desc "Server Administrators" > ipa sudorule-mod server-admins --cmdcat all > # ipa sudorule-add-host server-admins --hostgroups servers > ipa sudorule-mod server-admins --hostcat all > ipa sudorule-add-option server-admins --sudooption '!authenticate' > ipa sudorule-add-runasuser server-admins --users root > ipa sudorule-add-runasgroup server-admins --groups root > ipa sudorule-add-user server-admins --groups server-admins Does the machine where sudo prints this error belongs to the hostgroup 'servers'? If the answer is *no* then you are hitting 1000389. > This problem exists with the latest updates on both Fedora 18 and Fedora 19. > > I also discovered that libsss_sudo.so is missing from Fedora 18 > installations. It needs to be installed separately by installing libsss_sudo package. From jhrozek at redhat.com Mon Sep 9 09:58:20 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 9 Sep 2013 11:58:20 +0200 Subject: [Freeipa-users] freeipa and sudo In-Reply-To: <522D9678.5020005@redhat.com> References: <1378573597.16595.5.camel@host.hunter.org> <20130907181129.GA23695@fluxcoil.net> <522BB839.7030203@redhat.com> <1378672936.24034.5.camel@host.hunter.org> <20130908211122.GA11616@hendrix.redhat.com> <1378679187.24034.15.camel@host.hunter.org> <522D9678.5020005@redhat.com> Message-ID: <20130909095820.GK11616@hendrix.redhat.com> On Mon, Sep 09, 2013 at 11:35:52AM +0200, Pavel B?ezina wrote: > >This problem exists with the latest updates on both Fedora 18 and Fedora 19. > > > >I also discovered that libsss_sudo.so is missing from Fedora 18 > >installations. > > It needs to be installed separately by installing libsss_sudo package. btw this is only true on "older" systems, recently we folded back libsss_sudo and libsss_autofs back to the main packages to avoid this kind of confusion. From pspacek at redhat.com Mon Sep 9 10:26:11 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 09 Sep 2013 12:26:11 +0200 Subject: [Freeipa-users] Split Horizon DNS on IPA? In-Reply-To: References: Message-ID: <522DA243.7000202@redhat.com> On 8.9.2013 05:54, Andrew Lau wrote: > Hi all, > > I wasn't able to find much, but is it possible to configure FreeIPA to > serve as a split horizon DNS server? > > I would like the local network to be able to enroll and authenticate > locally, but at the same time bridge remote clients as well. > > Suggestions? Could you give us more details? We can try to find some solution for you particular situation. In general, FreeIPA doesn't support so-called views from BIND9 directly, but you can use e.g. FreeIPA integrated DNS for internal network (the internal view) and expose flat zone file for external view. Example configuration (/etc/named.conf): view "internal" { /* This view will contain zones you want to serve only to "internal" clients that connect via your directly attached LAN interfaces - "localnets" . */ match-clients { localnets; }; recursion yes; dynamic-db "ipa" { library "ldap.so"; arg "uri ldapi://%2fvar%2frun%2fslapd-IPA-TEST.socket"; arg "base cn=dns, dc=ipa,dc=test"; }; }; view "external" { /* This view will contain zones you want to serve only to "external" clients * that have addresses that are not match any above view: */ match-clients { any; }; recursion no; zone "my.external.zone" { type master; file "my.external.zone.db"; }; }; Have a nice day. -- Petr^2 Spacek From bret.wortman at damascusgrp.com Mon Sep 9 10:33:26 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Mon, 9 Sep 2013 06:33:26 -0400 Subject: [Freeipa-users] Trouble in ipa-ca-install In-Reply-To: References: Message-ID: Never mind. I just gave up and re-installed my original master from scratch. We're just going to accept the pain of re-enrolling all the clients and resetting all the user passwords. Whatever had gone wrong inside my database was just too much. This gets us clean again. * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret On Mon, Sep 9, 2013 at 3:30 AM, Bret Wortman wrote: > I've had some great success in the past 48 hours in recovering my system. > Here's where I stand right now: > > 1. I successfully stood up a new replica (ipamaster7) and transferred CA > authority to it from my old master (ipamaster). > 2. I shutdown ipamaster and re-baselined it. > 3. I created a new replica file from ipamaster7 for ipamaster (to transfer > everything back). > 4. I reinstalled the IPA software on ipamaster. I also made a small change > to CS.cfg to work around my earlier CA problem. > 5. I ran "ipa-replica-install --setup-dns --no-forwarders > replica-info-ipamaster.foo.net.gpg", which ran to completion. > 6. I attempted to run "ipa-ca-install replica-info-ipamaster.foo.net.gpg", > which failed due to a 403 error. > > /var/log/ipareplica-ca-install.log showed this: > > 2013-09-09T07:10:30Z DEBUG Starting external process > 2013-09-09T07:10:30Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpyIMTdo > 2013-09-09T07:10:31Z DEBUG Process finished, return code=1 > 2013-09-09T07:10:31Z DEBUG stdout=Loading deployment configuration from > /tmp/tmpyIMTdo. > ERROR: Unable to access security domain: 403 Client Error: Forbidden > > 2013-09-09T07:10:31Z DEBUG stderr= > 2013-09-09T07:10:31Z CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmpyIMTdo' returned non-zero exit status 1 > 2013-09-09T07:10:31Z INFO File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line > 619, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-ca-install", line 182, in main > config, dogtag_master_ds_port, postinstall=True) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 1809, in install_replica_ca > subject_base=config.subject_base) > > File "/usr/ib/python2.7/site-packages/ipaserver/install/cainstance.py", > line625, in configure_instance > self.start_creation(runtime=210) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 358, in start_creation > method() > > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 744, in __spawn_instance > raise RuntimeError('Configuration of CA failed') > > 2013-09-09T07:10:31Z INFO The ipa-ca-install command failed, exception: > RuntimeError: Configuration of CA failed > > Does this look familiar to anyone? I'd like to complete the transition > back to ipamaster so that I can then finish cleaning up the dead replicas. > Until I can do this, I'll have to leave ipamaster7 in place as my master. > > Thanks! > * > * > *Bret Wortman* > > http://damascusgrp.com/ > http://about.me/wortmanbret > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at andrewklau.com Mon Sep 9 11:30:00 2013 From: andrew at andrewklau.com (Andrew Lau) Date: Mon, 9 Sep 2013 21:30:00 +1000 Subject: [Freeipa-users] Split Horizon DNS on IPA? In-Reply-To: <522DA243.7000202@redhat.com> References: <522DA243.7000202@redhat.com> Message-ID: On Mon, Sep 9, 2013 at 8:26 PM, Petr Spacek wrote: > On 8.9.2013 05:54, Andrew Lau wrote: > >> Hi all, >> >> I wasn't able to find much, but is it possible to configure FreeIPA to >> serve as a split horizon DNS server? >> >> I would like the local network to be able to enroll and authenticate >> locally, but at the same time bridge remote clients as well. >> >> Suggestions? >> > > Could you give us more details? We can try to find some solution for you > particular situation. > > In general, FreeIPA doesn't support so-called views from BIND9 directly, > but you can use e.g. FreeIPA integrated DNS for internal network (the > internal view) and expose flat zone file for external view. > > Example configuration (/etc/named.conf): > view "internal" > { > /* This view will contain zones you want to serve only to "internal" > clients > that connect via your directly attached LAN interfaces - "localnets" . > */ > match-clients { localnets; }; > recursion yes; > > dynamic-db "ipa" { > library "ldap.so"; > arg "uri ldapi://%2fvar%2frun%2fslapd-**IPA-TEST.socket"; > arg "base cn=dns, dc=ipa,dc=test"; > }; > }; > > view "external" > { > /* This view will contain zones you want to serve only to "external" > clients > * that have addresses that are not match any above view: > */ > match-clients { any; }; > recursion no; > > zone "my.external.zone" { > type master; > file "my.external.zone.db"; > }; > }; > > Have a nice day. Hi Petr, Thanks - I ended up running a slave DNS server with bind9 views. It's just a bit of a pain having to now manage two DNS configs but it'll have to do. Thanks, Andrew. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Sep 9 11:36:20 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 09 Sep 2013 13:36:20 +0200 Subject: [Freeipa-users] IPA, Named and DHCP In-Reply-To: <1378571811.2804.1249.camel@willson.li.ssimo.org> References: <1378571811.2804.1249.camel@willson.li.ssimo.org> Message-ID: <522DB2B4.9030108@redhat.com> On 7.9.2013 18:36, Simo Sorce wrote: > On Fri, 2013-09-06 at 20:12 -0400, bwellsnc wrote: >> Hello. I am working on implementing several new things at my >> company, IPA, a new DHCP server, and a new named server. The problem >> is that I am running an infrastructure with Windows, Linux, and Mac. >> This means that DNS entries cannot be kept up to date using the >> windows/mac side because they are not part of IPA. The current >> DHCP/Named instance I am replacing does named updates from DHCP. I am >> wondering, can the named instance used by IPA be updated using DHCP. >> The ideal situation would be for DHCP to be allowed to automatically >> make additions to IPA's DNS server, even if there is no entry for that >> host. Can something like this be implemented with ipa: >> >> >> http://edmann.com/Computers-Technology/2008/01/08/ISC-DHCP-and-Ldap-Backend >> > The LDAP backend for ISC DHCP is used to store dhcp data, but wouldn't > be very useful for your purpose. > > If you can run a script from the DHCP server when a machine registers, > then what you can do is to create a user/service allowed to modify DNS > entries (aadding a named ACI to the relative zone) and then simply use > the script to call 'nsupdate' and issue GSS-TSIG signed dns update > requests. Simo is right. Please see: - man dhcpd.conf, particularly section 'EVENTS' and options ddns-*, do-forward-updates and client-updates. - http://www.freeipa.org/page/Dynamic_updates_with_GSS-TSIG, particularly section about update-policies Don't hesitate to ask again if you find some something unclear or misleading information. -- Petr^2 Spacek From deanhunter at comcast.net Mon Sep 9 15:53:02 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Mon, 09 Sep 2013 10:53:02 -0500 Subject: [Freeipa-users] freeipa and sudo In-Reply-To: <522D9678.5020005@redhat.com> References: <1378573597.16595.5.camel@host.hunter.org> <20130907181129.GA23695@fluxcoil.net> <522BB839.7030203@redhat.com> <1378672936.24034.5.camel@host.hunter.org> <20130908211122.GA11616@hendrix.redhat.com> <1378679187.24034.15.camel@host.hunter.org> <522D9678.5020005@redhat.com> Message-ID: <1378741982.15777.3.camel@host.hunter.org> On Mon, 2013-09-09 at 11:35 +0200, Pavel B?ezina wrote: > On 09/09/2013 12:26 AM, Dean Hunter wrote: > > On Sun, 2013-09-08 at 23:11 +0200, Jakub Hrozek wrote: > >> On Sun, Sep 08, 2013 at 03:42:16PM -0500, Dean Hunter wrote: > >> > On Sat, 2013-09-07 at 19:35 -0400, Dmitri Pal wrote: > >> > > >> > > On 09/07/2013 02:11 PM, Christian Horn wrote: > >> > > > On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote: > >> > > >> Are [1] and[2] still the current and best sources of information for > >> > > >> configuring sudo for use with the current release of FreeIPA on Fedora > >> > > >> 19? > >> > > >> > >> > > >> 1. > >> > > >>http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html > >> > > >> 2. > >> > > >>http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > >> > > > There is also the Identity_Management_Guide as part of the RHEL > >> > > > product documentation: > >> > > >https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html > >> > > This and the pdf above are the latest word in this area. > >> > > > >> > > > Christian > >> > > > > >> > > > _______________________________________________ > >> > > > Freeipa-users mailing list > >> > > >Freeipa-users at redhat.com > >> > > >https://www.redhat.com/mailman/listinfo/freeipa-users > >> > > > >> > > > >> > > >> > Some sudo rules are causing: > >> > > >> > [dean at desktop2 ~]$ sudo id > >> > sudo: internal error, tried to erealloc3(0) > >> > >> This is a known bug: > >> https://bugzilla.redhat.com/show_bug.cgi?id=1000389 > >> > >> I think the sudo rules are just missing the sudoHost attribute. > >> > >> > > >> > , but others do not. In the trial and error process of determining > >> > which rule specifications are causing the error, I have been restarting > >> > the virtual machine I am using as the sudo client between tests. Is > >> > there a better way to clear the SSSD cache between trials to make sure I > >> > am testing the most recent rule change? > >> > >> Unfortunately right now the only way is to rm the sssd cache which would > >> also remove any cached credentials. I thought there was an RFE open to > >> track the enhancement to make sss_cache invalidate and refresh sudo > >> rules, but I can't find it now in the SSSD trac, so I filed another one: > >> https://fedorahosted.org/sssd/ticket/2081 > >> > >> Worst case, we mark it as a duplicate. > >> > >> _______________________________________________ > >> Freeipa-users mailing list > >> Freeipa-users at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > I saw bug report 1000389, but I could not understand it or whether it > > applied to me. > > > > I discovered that sudo rules for which I specified a host group caused > > the error. Rules with a host category of "all" instead of the host > > group did not cause the error. Is this what 1000389 says? > > > > ipa sudorule-add server-admins --desc "Server Administrators" > > ipa sudorule-mod server-admins --cmdcat all > > # ipa sudorule-add-host server-admins --hostgroups servers > > ipa sudorule-mod server-admins --hostcat all > > ipa sudorule-add-option server-admins --sudooption '!authenticate' > > ipa sudorule-add-runasuser server-admins --users root > > ipa sudorule-add-runasgroup server-admins --groups root > > ipa sudorule-add-user server-admins --groups server-admins > > Does the machine where sudo prints this error belongs to the hostgroup > 'servers'? If the answer is *no* then you are hitting 1000389. Yes, the virtual machine where the sudo internal error occurs is a member of the hostgroup. So I guess this is a new error and should be reported? > > This problem exists with the latest updates on both Fedora 18 and Fedora 19. > > > > I also discovered that libsss_sudo.so is missing from Fedora 18 > > installations. > > It needs to be installed separately by installing libsss_sudo package. Yes, I did find the package and installed it. > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From deanhunter at comcast.net Mon Sep 9 15:55:33 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Mon, 09 Sep 2013 10:55:33 -0500 Subject: [Freeipa-users] freeipa and sudo In-Reply-To: <522D94F3.9050301@redhat.com> References: <1378573597.16595.5.camel@host.hunter.org> <20130907181129.GA23695@fluxcoil.net> <522BB839.7030203@redhat.com> <1378672936.24034.5.camel@host.hunter.org> <20130908211122.GA11616@hendrix.redhat.com> <522D94F3.9050301@redhat.com> Message-ID: <1378742133.15777.5.camel@host.hunter.org> On Mon, 2013-09-09 at 11:29 +0200, Pavel B?ezina wrote: > On 09/08/2013 11:11 PM, Jakub Hrozek wrote: > > On Sun, Sep 08, 2013 at 03:42:16PM -0500, Dean Hunter wrote: > >> On Sat, 2013-09-07 at 19:35 -0400, Dmitri Pal wrote: > >> > >>> On 09/07/2013 02:11 PM, Christian Horn wrote: > >>>> On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote: > >>>>> Are [1] and[2] still the current and best sources of information for > >>>>> configuring sudo for use with the current release of FreeIPA on Fedora > >>>>> 19? > >>>>> > >>>>> 1. > >>>>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html > >>>>> 2. > >>>>> http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > >>>> There is also the Identity_Management_Guide as part of the RHEL > >>>> product documentation: > >>>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html > >>> This and the pdf above are the latest word in this area. > >>> > >>>> Christian > >>>> > >>>> _______________________________________________ > >>>> Freeipa-users mailing list > >>>> Freeipa-users at redhat.com > >>>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>> > >>> > >> > >> Some sudo rules are causing: > >> > >> [dean at desktop2 ~]$ sudo id > >> sudo: internal error, tried to erealloc3(0) > > > > This is a known bug: > > https://bugzilla.redhat.com/show_bug.cgi?id=1000389 > > > > I think the sudo rules are just missing the sudoHost attribute. > > > >> > >> , but others do not. In the trial and error process of determining > >> which rule specifications are causing the error, I have been restarting > >> the virtual machine I am using as the sudo client between tests. Is > >> there a better way to clear the SSSD cache between trials to make sure I > >> am testing the most recent rule change? > > > > Unfortunately right now the only way is to rm the sssd cache which would > > also remove any cached credentials. > > You don't necessarily have to remove the cache. If you just restart SSSD > the rules will be refreshed in approximately 15 seconds. Ah! Thank you. I will try to remember that for the next time I have to debug rules > I thought there was an RFE open to > > track the enhancement to make sss_cache invalidate and refresh sudo > > rules, but I can't find it now in the SSSD trac, so I filed another one: > > https://fedorahosted.org/sssd/ticket/2081 > > > > Worst case, we mark it as a duplicate. > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From shelltoesuperstar at gmail.com Mon Sep 9 16:20:55 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Mon, 9 Sep 2013 17:20:55 +0100 Subject: [Freeipa-users] IPA Query Tuning and a Recovery Question Message-ID: Hi, 2 questions, some of our automation accounts are needlessly querying the IPA server every time they call a command via sudo. This is generating a lot of noise in our access logs. Is there any way to ensure certain system accounts don't call out to the IPA server for additional groups or sudo permission when completing tasks? The other question is slightly more embarrassing, one of our guys saw /var filling and noticed that /var/lib/dirsrv/slapd-EXAMPLE-COM/db/ had a load of "log" files which looked like they weren't being tidied. One stupid decision later and I'm now here asking on his behalf if there is anyway of restoring the database from a replica or is a complete rebuild required? Second question is obviously a little bit more urgent than the first but any advice is greatly appreciated. Thanks, Charlie -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Sep 9 16:32:01 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 09 Sep 2013 10:32:01 -0600 Subject: [Freeipa-users] IPA Query Tuning and a Recovery Question In-Reply-To: References: Message-ID: <522DF801.9050703@redhat.com> On 09/09/2013 10:20 AM, Charlie Derwent wrote: > Hi, > 2 questions, some of our automation accounts are needlessly querying > the IPA server every time they call a command via sudo. This is > generating a lot of noise in our access logs. Is there any way to > ensure certain system accounts don't call out to the IPA server for > additional groups or sudo permission when completing tasks? What are your client platforms? Does sssd or newer versions of sudo cache? > The other question is slightly more embarrassing, one of our guys saw > /var filling and noticed that /var/lib/dirsrv/slapd-EXAMPLE-COM/db/ > had a load of "log" files which looked like they weren't being tidied. They are automatically cleaned up. If you have a lot of updates, it may take longer. > One stupid decision later and I'm now here asking on his behalf if > there is anyway of restoring the database from a replica or is a > complete rebuild required? Just reinit the replica using ipa-replica-manage. > Second question is obviously a little bit more urgent than the first > but any advice is greatly appreciated. > Thanks, > Charlie > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From deanhunter at comcast.net Mon Sep 9 17:32:10 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Mon, 09 Sep 2013 12:32:10 -0500 Subject: [Freeipa-users] freeipa and sudo In-Reply-To: <522D9397.20504@redhat.com> References: <1378573597.16595.5.camel@host.hunter.org> <20130907181129.GA23695@fluxcoil.net> <522BB839.7030203@redhat.com> <522D9397.20504@redhat.com> Message-ID: <1378747930.23322.16.camel@host.hunter.org> On Mon, 2013-09-09 at 11:23 +0200, Pavel B?ezina wrote: > On 09/08/2013 01:35 AM, Dmitri Pal wrote: > > On 09/07/2013 02:11 PM, Christian Horn wrote: > >> On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote: > >>> Are [1] and[2] still the current and best sources of information for > >>> configuring sudo for use with the current release of FreeIPA on Fedora > >>> 19? > >>> > >>> 1. > >>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html > >>> 2. > >>> http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > >> There is also the Identity_Management_Guide as part of the RHEL > >> product documentation: > >> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html > > This and the pdf above are the latest word in this area. > > Hi, > those documents describes configuration for SSSD 1.9. Although it is > still valid, we have simplified configuration for IPA provider in 1.10. > > The most up to date document for your version of SSSD is always man > sssd-sudo. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Thank you. Please verify that I have correctly understood your note. Your slides from 12-20-2012 applied to SSSD 1.9 and included a reference to the manual pages, which I now understand, as well as this example configuration: sudo_provider = ldap ldap_uri = ldap://ipa.example.com ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/hostname.example.com ldap_sasl_realm = EXAMPLE.COM krb5_server = ipa.example.com I have used this configuration with good results. However, reading "man sssd-sudo" from sssd-1.9.5-2.fc18.x86_64 I find this paragraph: When the SSSD is configured to use the IPA provider, the sudo provider is automatically enabled. The sudo search base is configured to use the compat tree (ou=sudoers,$DC). May I suggest that you change "IPA provider" to "IPA as the ID provider"? There are a number of providers identified in sssd.conf and most of them are configured to use IPA. Testing shows that the only change now required to sssd.conf is the addition of sudo to the services list in the sssd section [sssd]: services = autofs, nss, pam, ssh, sudo Add to this the one line change in nsswitch.conf sudoers: files sss and I am done. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shelltoesuperstar at gmail.com Mon Sep 9 17:40:43 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Mon, 9 Sep 2013 18:40:43 +0100 Subject: [Freeipa-users] IPA Query Tuning and a Recovery Question In-Reply-To: <522DF801.9050703@redhat.com> References: <522DF801.9050703@redhat.com> Message-ID: On Mon, Sep 9, 2013 at 5:32 PM, Rich Megginson wrote: > On 09/09/2013 10:20 AM, Charlie Derwent wrote: > > Hi, > > 2 questions, some of our automation accounts are needlessly querying the > IPA server every time they call a command via sudo. This is generating a > lot of noise in our access logs. Is there any way to ensure certain system > accounts don't call out to the IPA server for additional groups or sudo > permission when completing tasks? > > > What are your client platforms? Does sssd or newer versions of sudo cache? > > The clients are a mix of RHEL and CentOS 5.8 servers, what version am I looking for any kind of caching? > > > The other question is slightly more embarrassing, one of our guys saw /var > filling and noticed that /var/lib/dirsrv/slapd-EXAMPLE-COM/db/ had a load > of "log" files which looked like they weren't being tidied. > > > They are automatically cleaned up. If you have a lot of updates, it may > take longer. > > > One stupid decision later and I'm now here asking on his behalf if there > is anyway of restoring the database from a replica or is a complete rebuild > required? > > > Just reinit the replica using ipa-replica-manage. > > Thanks will give it a go tomorrow. > > Second question is obviously a little bit more urgent than the first but > any advice is greatly appreciated. > > Thanks, > Charlie > > > > > > > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Sep 9 18:26:03 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 09 Sep 2013 12:26:03 -0600 Subject: [Freeipa-users] IPA Query Tuning and a Recovery Question In-Reply-To: References: <522DF801.9050703@redhat.com> Message-ID: <522E12BB.6030905@redhat.com> On 09/09/2013 11:40 AM, Charlie Derwent wrote: > > On Mon, Sep 9, 2013 at 5:32 PM, Rich Megginson > wrote: > > On 09/09/2013 10:20 AM, Charlie Derwent wrote: >> Hi, >> 2 questions, some of our automation accounts are needlessly >> querying the IPA server every time they call a command via sudo. >> This is generating a lot of noise in our access logs. Is there >> any way to ensure certain system accounts don't call out to the >> IPA server for additional groups or sudo permission when >> completing tasks? > > What are your client platforms? Does sssd or newer versions of > sudo cache? > > The clients are a mix of RHEL and CentOS 5.8 servers, what version am > I looking for any kind of caching? By default, on EL5, sudo has to connect/bind/search/close for every single sudo lookup. I believe there are versions of sssd/sudo that do some sort of caching. I'm not sure if those are available for EL5. > >> The other question is slightly more embarrassing, one of our guys >> saw /var filling and noticed that >> /var/lib/dirsrv/slapd-EXAMPLE-COM/db/ had a load of "log" files >> which looked like they weren't being tidied. > > They are automatically cleaned up. If you have a lot of updates, > it may take longer. > > >> One stupid decision later and I'm now here asking on his behalf >> if there is anyway of restoring the database from a replica or is >> a complete rebuild required? > > Just reinit the replica using ipa-replica-manage. > > Thanks will give it a go tomorrow. > >> Second question is obviously a little bit more urgent than the >> first but any advice is greatly appreciated. >> Thanks, >> Charlie >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Sep 10 00:46:57 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 09 Sep 2013 20:46:57 -0400 Subject: [Freeipa-users] IPA Query Tuning and a Recovery Question In-Reply-To: <522E12BB.6030905@redhat.com> References: <522DF801.9050703@redhat.com> <522E12BB.6030905@redhat.com> Message-ID: <522E6C01.8080902@redhat.com> On 09/09/2013 02:26 PM, Rich Megginson wrote: > On 09/09/2013 11:40 AM, Charlie Derwent wrote: >> >> On Mon, Sep 9, 2013 at 5:32 PM, Rich Megginson > > wrote: >> >> On 09/09/2013 10:20 AM, Charlie Derwent wrote: >>> Hi, >>> >>> 2 questions, some of our automation accounts are needlessly >>> querying the IPA server every time they call a command via sudo. >>> This is generating a lot of noise in our access logs. Is there >>> any way to ensure certain system accounts don't call out to the >>> IPA server for additional groups or sudo permission when >>> completing tasks? >> >> What are your client platforms? Does sssd or newer versions of >> sudo cache? >> >> The clients are a mix of RHEL and CentOS 5.8 servers, what version am >> I looking for any kind of caching? > > By default, on EL5, sudo has to connect/bind/search/close for every > single sudo lookup. I believe there are versions of sssd/sudo that do > some sort of caching. I'm not sure if those are available for EL5. In RHEL 6.4 sudo can be integrated with SSSD that would provide the caching of the sudo rules on the client. > >> >>> >>> The other question is slightly more embarrassing, one of our >>> guys saw /var filling and noticed that >>> /var/lib/dirsrv/slapd-EXAMPLE-COM/db/ had a load of "log" files >>> which looked like they weren't being tidied. >> >> They are automatically cleaned up. If you have a lot of updates, >> it may take longer. >> >> >> >>> One stupid decision later and I'm now here asking on his behalf >>> if there is anyway of restoring the database from a replica or >>> is a complete rebuild required? >> >> Just reinit the replica using ipa-replica-manage. >> >> Thanks will give it a go tomorrow. >> >>> >>> Second question is obviously a little bit more urgent than the >>> first but any advice is greatly appreciated. >>> >>> Thanks, >>> Charlie >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at andrewklau.com Tue Sep 10 03:28:33 2013 From: andrew at andrewklau.com (Andrew Lau) Date: Tue, 10 Sep 2013 13:28:33 +1000 Subject: [Freeipa-users] Split Horizon DNS on IPA? In-Reply-To: References: <522DA243.7000202@redhat.com> Message-ID: On Mon, Sep 9, 2013 at 9:30 PM, Andrew Lau wrote: > On Mon, Sep 9, 2013 at 8:26 PM, Petr Spacek wrote: > >> On 8.9.2013 05:54, Andrew Lau wrote: >> >>> Hi all, >>> >>> I wasn't able to find much, but is it possible to configure FreeIPA to >>> serve as a split horizon DNS server? >>> >>> I would like the local network to be able to enroll and authenticate >>> locally, but at the same time bridge remote clients as well. >>> >>> Suggestions? >>> >> >> Could you give us more details? We can try to find some solution for you >> particular situation. >> >> In general, FreeIPA doesn't support so-called views from BIND9 directly, >> but you can use e.g. FreeIPA integrated DNS for internal network (the >> internal view) and expose flat zone file for external view. >> >> Example configuration (/etc/named.conf): >> view "internal" >> { >> /* This view will contain zones you want to serve only to "internal" >> clients >> that connect via your directly attached LAN interfaces - "localnets" . >> */ >> match-clients { localnets; }; >> recursion yes; >> >> dynamic-db "ipa" { >> library "ldap.so"; >> arg "uri ldapi://%2fvar%2frun%2fslapd-**IPA-TEST.socket"; >> arg "base cn=dns, dc=ipa,dc=test"; >> }; >> }; >> >> view "external" >> { >> /* This view will contain zones you want to serve only to "external" >> clients >> * that have addresses that are not match any above view: >> */ >> match-clients { any; }; >> recursion no; >> >> zone "my.external.zone" { >> type master; >> file "my.external.zone.db"; >> }; >> }; >> >> Have a nice day. > > > Hi Petr, > > Thanks - I ended up running a slave DNS server with bind9 views. It's just > a bit of a pain having to now manage two DNS configs but it'll have to do. > > Thanks, > Andrew. > > I spoke too soon.. My scenario I have is internal clients enrolled into FreeIPA, all the IPs registered on internal.domain.com are internal IPs. I want to use the FreeIPA server to also serve the DNS for domain.com but because it's hidden in a private network I had setup slave DNS servers but they don't seem to use the authoritative nameserver setting, So eg. ipa01.internal.domain.com (private IP Address) --> dns01.domain.com (public IP adddress) The records that get served to dns01.domain.com are: domain.com IN SOA ipa02.internal.domain.com. hostmaster.domain.com. ( Any suggestions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Sep 10 07:54:13 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 Sep 2013 09:54:13 +0200 Subject: [Freeipa-users] Split Horizon DNS on IPA? In-Reply-To: References: <522DA243.7000202@redhat.com> Message-ID: <522ED025.6090309@redhat.com> On 10.9.2013 05:28, Andrew Lau wrote: > On Mon, Sep 9, 2013 at 9:30 PM, Andrew Lau wrote: > >> On Mon, Sep 9, 2013 at 8:26 PM, Petr Spacek wrote: >> >>> On 8.9.2013 05:54, Andrew Lau wrote: >>> >>>> Hi all, >>>> >>>> I wasn't able to find much, but is it possible to configure FreeIPA to >>>> serve as a split horizon DNS server? >>>> >>>> I would like the local network to be able to enroll and authenticate >>>> locally, but at the same time bridge remote clients as well. >>>> >>>> Suggestions? >>>> >>> >>> Could you give us more details? We can try to find some solution for you >>> particular situation. >>> >>> In general, FreeIPA doesn't support so-called views from BIND9 directly, >>> but you can use e.g. FreeIPA integrated DNS for internal network (the >>> internal view) and expose flat zone file for external view. >>> >>> Example configuration (/etc/named.conf): >>> view "internal" >>> { >>> /* This view will contain zones you want to serve only to "internal" >>> clients >>> that connect via your directly attached LAN interfaces - "localnets" . >>> */ >>> match-clients { localnets; }; >>> recursion yes; >>> >>> dynamic-db "ipa" { >>> library "ldap.so"; >>> arg "uri ldapi://%2fvar%2frun%2fslapd-**IPA-TEST.socket"; >>> arg "base cn=dns, dc=ipa,dc=test"; >>> }; >>> }; >>> >>> view "external" >>> { >>> /* This view will contain zones you want to serve only to "external" >>> clients >>> * that have addresses that are not match any above view: >>> */ >>> match-clients { any; }; >>> recursion no; >>> >>> zone "my.external.zone" { >>> type master; >>> file "my.external.zone.db"; >>> }; >>> }; >>> >>> Have a nice day. >> >> >> Hi Petr, >> >> Thanks - I ended up running a slave DNS server with bind9 views. It's just >> a bit of a pain having to now manage two DNS configs but it'll have to do. >> >> Thanks, >> Andrew. >> >> > I spoke too soon.. > > My scenario I have is internal clients enrolled into FreeIPA, all the IPs > registered on internal.domain.com are internal IPs. I want to use the > FreeIPA server to also serve the DNS for domain.com but because it's hidden > in a private network I had setup slave DNS servers but they don't seem to > use the authoritative nameserver setting, > > So eg. > ipa01.internal.domain.com (private IP Address) --> dns01.domain.com (public > IP adddress) > > The records that get served to dns01.domain.com are: > > domain.com IN SOA ipa02.internal.domain.com. hostmaster.domain.com. > ( > > Any suggestions? It is most probably caused by 'fake_mname' setting in /etc/named.conf. Named will respect the value in SOA record if you comment this value out, but will lose the ability to load balance DNS dynamic updates between FreeIPA replicas. The point is that clients use this name to find the server responsible for zone updates (and nothing else). In FreeIPA's case, any server can update the zone so all servers report itself as zone 'masters'. This allows to spread the load among all replicas and there is no single point of failure. The question is - do you need it for external zone? Do you use dynamic update for domain.com? I would ignore the internal hostname in the zone if you don't use DNS updates (if you are okay with such information leak). Side note: Don't forget that internal host names normally leak in e-mail headers; from mis-configured clients in internal network; via roaming clients trying to access internal resources while they are not on VPN; etc. etc. -- Petr^2 Spacek From andrew at andrewklau.com Tue Sep 10 08:33:07 2013 From: andrew at andrewklau.com (Andrew Lau) Date: Tue, 10 Sep 2013 18:33:07 +1000 Subject: [Freeipa-users] Split Horizon DNS on IPA? In-Reply-To: <522ED025.6090309@redhat.com> References: <522DA243.7000202@redhat.com> <522ED025.6090309@redhat.com> Message-ID: On Tue, Sep 10, 2013 at 5:54 PM, Petr Spacek wrote: > On 10.9.2013 05:28, Andrew Lau wrote: > >> On Mon, Sep 9, 2013 at 9:30 PM, Andrew Lau wrote: >> >> On Mon, Sep 9, 2013 at 8:26 PM, Petr Spacek wrote: >>> >>> On 8.9.2013 05:54, Andrew Lau wrote: >>>> >>>> Hi all, >>>>> >>>>> I wasn't able to find much, but is it possible to configure FreeIPA to >>>>> serve as a split horizon DNS server? >>>>> >>>>> I would like the local network to be able to enroll and authenticate >>>>> locally, but at the same time bridge remote clients as well. >>>>> >>>>> Suggestions? >>>>> >>>>> >>>> Could you give us more details? We can try to find some solution for you >>>> particular situation. >>>> >>>> In general, FreeIPA doesn't support so-called views from BIND9 directly, >>>> but you can use e.g. FreeIPA integrated DNS for internal network (the >>>> internal view) and expose flat zone file for external view. >>>> >>>> Example configuration (/etc/named.conf): >>>> view "internal" >>>> { >>>> /* This view will contain zones you want to serve only to "internal" >>>> clients >>>> that connect via your directly attached LAN interfaces - >>>> "localnets" . >>>> */ >>>> match-clients { localnets; }; >>>> recursion yes; >>>> >>>> dynamic-db "ipa" { >>>> library "ldap.so"; >>>> arg "uri ldapi://%2fvar%2frun%2fslapd-*** >>>> *IPA-TEST.socket"; >>>> >>>> arg "base cn=dns, dc=ipa,dc=test"; >>>> }; >>>> }; >>>> >>>> view "external" >>>> { >>>> /* This view will contain zones you want to serve only to "external" >>>> clients >>>> * that have addresses that are not match any above view: >>>> */ >>>> match-clients { any; }; >>>> recursion no; >>>> >>>> zone "my.external.zone" { >>>> type master; >>>> file "my.external.zone.db"; >>>> }; >>>> }; >>>> >>>> Have a nice day. >>>> >>> >>> >>> Hi Petr, >>> >>> Thanks - I ended up running a slave DNS server with bind9 views. It's >>> just >>> a bit of a pain having to now manage two DNS configs but it'll have to >>> do. >>> >>> Thanks, >>> Andrew. >>> >>> >>> I spoke too soon.. >> >> My scenario I have is internal clients enrolled into FreeIPA, all the IPs >> registered on internal.domain.com are internal IPs. I want to use the >> FreeIPA server to also serve the DNS for domain.com but because it's >> hidden >> in a private network I had setup slave DNS servers but they don't seem to >> use the authoritative nameserver setting, >> >> So eg. >> ipa01.internal.domain.com (private IP Address) --> dns01.domain.com(public >> IP adddress) >> >> The records that get served to dns01.domain.com are: >> >> domain.com IN SOA ipa02.internal.domain.com. >> hostmaster.domain.com. >> ( >> >> Any suggestions? >> > > It is most probably caused by 'fake_mname' setting in /etc/named.conf. > Named will respect the value in SOA record if you comment this value out, > but will lose the ability to load balance DNS dynamic updates between > FreeIPA replicas. > > The point is that clients use this name to find the server responsible for > zone updates (and nothing else). In FreeIPA's case, any server can update > the zone so all servers report itself as zone 'masters'. This allows to > spread the load among all replicas and there is no single point of failure. > > The question is - do you need it for external zone? Do you use dynamic > update for domain.com? I would ignore the internal hostname in the zone > if you don't use DNS updates (if you are okay with such information leak). > > Side note: > Don't forget that internal host names normally leak in e-mail headers; > from mis-configured clients in internal network; via roaming clients trying > to access internal resources while they are not on VPN; etc. etc. > > -- > Petr^2 Spacek > I would like to keep the dynamic updates for domain.com so users can modify DNS zones without requiring direct access. My concern was, from what people have been telling me is that the SOA mname resolution is important, on the other hand many have said it's not. What I've been reading has been leaning towards the later. The internal hostnames aren't really hiding anything, it's only because they resolve to internal IPs -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Sep 10 08:50:28 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 Sep 2013 10:50:28 +0200 Subject: [Freeipa-users] Split Horizon DNS on IPA? In-Reply-To: References: <522DA243.7000202@redhat.com> <522ED025.6090309@redhat.com> Message-ID: <522EDD54.7080603@redhat.com> On 10.9.2013 10:33, Andrew Lau wrote: > On Tue, Sep 10, 2013 at 5:54 PM, Petr Spacek wrote: > >> On 10.9.2013 05:28, Andrew Lau wrote: >> >>> On Mon, Sep 9, 2013 at 9:30 PM, Andrew Lau wrote: >>> >>> On Mon, Sep 9, 2013 at 8:26 PM, Petr Spacek wrote: >>>> >>>> On 8.9.2013 05:54, Andrew Lau wrote: >>>>> >>>>> Hi all, >>>>>> >>>>>> I wasn't able to find much, but is it possible to configure FreeIPA to >>>>>> serve as a split horizon DNS server? >>>>>> >>>>>> I would like the local network to be able to enroll and authenticate >>>>>> locally, but at the same time bridge remote clients as well. >>>>>> >>>>>> Suggestions? >>>>>> >>>>>> >>>>> Could you give us more details? We can try to find some solution for you >>>>> particular situation. >>>>> >>>>> In general, FreeIPA doesn't support so-called views from BIND9 directly, >>>>> but you can use e.g. FreeIPA integrated DNS for internal network (the >>>>> internal view) and expose flat zone file for external view. >>>>> >>>>> Example configuration (/etc/named.conf): >>>>> view "internal" >>>>> { >>>>> /* This view will contain zones you want to serve only to "internal" >>>>> clients >>>>> that connect via your directly attached LAN interfaces - >>>>> "localnets" . >>>>> */ >>>>> match-clients { localnets; }; >>>>> recursion yes; >>>>> >>>>> dynamic-db "ipa" { >>>>> library "ldap.so"; >>>>> arg "uri ldapi://%2fvar%2frun%2fslapd-*** >>>>> *IPA-TEST.socket"; >>>>> >>>>> arg "base cn=dns, dc=ipa,dc=test"; >>>>> }; >>>>> }; >>>>> >>>>> view "external" >>>>> { >>>>> /* This view will contain zones you want to serve only to "external" >>>>> clients >>>>> * that have addresses that are not match any above view: >>>>> */ >>>>> match-clients { any; }; >>>>> recursion no; >>>>> >>>>> zone "my.external.zone" { >>>>> type master; >>>>> file "my.external.zone.db"; >>>>> }; >>>>> }; >>>>> >>>>> Have a nice day. >>>>> >>>> >>>> >>>> Hi Petr, >>>> >>>> Thanks - I ended up running a slave DNS server with bind9 views. It's >>>> just >>>> a bit of a pain having to now manage two DNS configs but it'll have to >>>> do. >>>> >>>> Thanks, >>>> Andrew. >>>> >>>> >>>> I spoke too soon.. >>> >>> My scenario I have is internal clients enrolled into FreeIPA, all the IPs >>> registered on internal.domain.com are internal IPs. I want to use the >>> FreeIPA server to also serve the DNS for domain.com but because it's >>> hidden >>> in a private network I had setup slave DNS servers but they don't seem to >>> use the authoritative nameserver setting, >>> >>> So eg. >>> ipa01.internal.domain.com (private IP Address) --> dns01.domain.com(public >>> IP adddress) >>> >>> The records that get served to dns01.domain.com are: >>> >>> domain.com IN SOA ipa02.internal.domain.com. >>> hostmaster.domain.com. >>> ( >>> >>> Any suggestions? >>> >> >> It is most probably caused by 'fake_mname' setting in /etc/named.conf. >> Named will respect the value in SOA record if you comment this value out, >> but will lose the ability to load balance DNS dynamic updates between >> FreeIPA replicas. >> >> The point is that clients use this name to find the server responsible for >> zone updates (and nothing else). In FreeIPA's case, any server can update >> the zone so all servers report itself as zone 'masters'. This allows to >> spread the load among all replicas and there is no single point of failure. >> >> The question is - do you need it for external zone? Do you use dynamic >> update for domain.com? I would ignore the internal hostname in the zone >> if you don't use DNS updates (if you are okay with such information leak). >> >> Side note: >> Don't forget that internal host names normally leak in e-mail headers; >> from mis-configured clients in internal network; via roaming clients trying >> to access internal resources while they are not on VPN; etc. etc. >> >> -- >> Petr^2 Spacek >> > > I would like to keep the dynamic updates for domain.com so users can modify > DNS zones without requiring direct access. My concern was, from what people > have been telling me is that the SOA mname resolution is important, on the > other hand many have said it's not. What I've been reading has been leaning > towards the later. > > The internal hostnames aren't really hiding anything, it's only because > they resolve to internal IPs If you want to use real master name to support dynamic updates, then comment out 'fake_mname' setting in /etc/named.conf and make sure that internal.domain.com and domain.com have proper values in their SOA records. You will have to bump SOA serial to enforce new zone transfer, but it should work. In theory, you can disable 'fake_mname' only on the FreeIPA replica from which you do zone transfers and let it enabled on all other replicas. Does it solve your problem? -- Petr^2 Spacek From jhrozek at redhat.com Tue Sep 10 11:30:31 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 10 Sep 2013 13:30:31 +0200 Subject: [Freeipa-users] Incorrect user information In-Reply-To: <52275C7A.3020800@gmail.com> References: <5227465D.7020308@gmail.com> <841815955.7935136.1378306069557.JavaMail.root@redhat.com> <237193263.7936259.1378306160770.JavaMail.root@redhat.com> <52274F35.5090508@gmail.com> <20130904153134.GH22590@hendrix.brq.redhat.com> <52275C7A.3020800@gmail.com> Message-ID: <20130910113031.GG11028@hendrix.brq.redhat.com> On Wed, Sep 04, 2013 at 11:14:50AM -0500, cbulist at gmail.com wrote: > Hi Jakub, > > > Thanks for your time and tips about sssd cache! > I'm sorry about the late response, I didn't flag your response when it came back.. > I did the test and let me explain what I got: > > - After step 4 I can see dataExpireTimestamp to 1 for the user. OK, this is expected. > - After step 7 dataExpireTimestamp is back to 0 but the user data have > not changed. This is really strange because if the dataExpireTimestamp was reset after the lookup, then the backend has updated the entry...and it should have updated the entry with the up-to-date data.. Can you put debug_level=8 into the [nss] and [domain] sections and paste or attach the contents of /var/log/sssd/sssd_nss.log and /var/log/sssd/sssd_$domain.log after the request that follows the sss_cache run? Also in the logs you should see the server the SSSD connects to, can you check if there is maybe some replica that is out of sync? Unfortunately I can't reproduce the bug here.. > > The first line after the command ldbsearch is: > > asq: Unable to register control with rootdse! No, that's an internal info, ignore this message. > > Is it a problem? > > We are not using nscd service. > > Please let me know if you need to do some other tests. > Thanks in advance! From deanhunter at comcast.net Wed Sep 11 02:36:03 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Tue, 10 Sep 2013 21:36:03 -0500 Subject: [Freeipa-users] Permission Denied Message-ID: <1378866963.2726.5.camel@host.hunter.org> How do I determine the cause of this problem? [dean at ipa2 ~]$ ssh dean at desktop2 Last login: Tue Sep 10 21:10:01 2013 from ipa2.hunter.org Could not chdir to home directory /home/net/dean: Permission denied -bash: /home/net/dean/.bash_profile: Permission denied -bash-4.2$ rpm -q freeipa-client freeipa-client-3.1.5-1.fc18.x86_64 -bash-4.2$ I can log in as dean on desktop2 using gdm without a problem. But when I try to log in using ssh then I am denied access to the user's home directory. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Sep 11 04:10:30 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 11 Sep 2013 07:10:30 +0300 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1378866963.2726.5.camel@host.hunter.org> References: <1378866963.2726.5.camel@host.hunter.org> Message-ID: <20130911041030.GB21212@redhat.com> Hi Dean, On Tue, 10 Sep 2013, Dean Hunter wrote: >How do I determine the cause of this problem? > > [dean at ipa2 ~]$ ssh dean at desktop2 > Last login: Tue Sep 10 21:10:01 2013 from ipa2.hunter.org > Could not chdir to home directory /home/net/dean: Permission > denied > -bash: /home/net/dean/.bash_profile: Permission denied > > -bash-4.2$ rpm -q freeipa-client > freeipa-client-3.1.5-1.fc18.x86_64 > -bash-4.2$ > >I can log in as dean on desktop2 using gdm without a problem. But when >I try to log in using ssh then I am denied access to the user's home >directory. Is there any SELinux AVC in the logs? Is /home/net an NFS mount? Does use_nfs_home_dirs SELinux boolean set to on? (getsebool -a|grep home) -- / Alexander Bokovoy From KevinTang at umac.mo Wed Sep 11 04:39:33 2013 From: KevinTang at umac.mo (KevinTang at umac.mo) Date: Wed, 11 Sep 2013 12:39:33 +0800 Subject: [Freeipa-users] IPA AD Trust issue Message-ID: Dear all, I am new to IPA and have some question about set up. I already setup IPA server (CentOS 6.4 64bit), IPA client (CentOS 6.4 64bit), and Windows AD (Windows 2008 R2 Standard 64bit). IPA Server and Windows AD already have 2-ways trusted. Windows AD user can logon under IPA client PC. I have 3 question about further setup. 1) IPA Client Login issue. In IPA client, if Windows AD user want to login, It need to type full name such as 'userA at win_ad.com'. How do I let Windows AD user logon only with their username? That means only use 'userA' to logon IPA Client PC rather than 'userA at win_ad.com' ? 2) Windows Login issue. I want to logon under Windows AD Client PC (Client PC's OS is Windows 7), Since this Windows PC already join win_ad domain, it can allow Windows AD domain user to logon. But when I try to logon IPA user, for example, logon as 'userB at ipa_ad.com' or 'ipa_ad.com\userB'. It always show 'There are currently no logon servers available to service the logon request.' and does not allow IPA user to logon. How do I do now? I need to modify Windows AD setting? or Windows client PC setting? 3) Windows Login issue. Can I login under Windows AD Client PC with IPA username only (not include IPA domain)? that is, only use 'userB' as username to login? Thanks all Kevin Tang -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Sep 11 04:52:03 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 11 Sep 2013 07:52:03 +0300 Subject: [Freeipa-users] IPA AD Trust issue In-Reply-To: References: Message-ID: <20130911045203.GC21212@redhat.com> On Wed, 11 Sep 2013, KevinTang at umac.mo wrote: >Dear all, > >I am new to IPA and have some question about set up. >I already setup IPA server (CentOS 6.4 64bit), IPA client (CentOS 6.4 >64bit), and Windows AD (Windows 2008 R2 Standard 64bit). IPA Server and >Windows AD already have 2-ways trusted. Windows AD user can logon under >IPA client PC. > >I have 3 question about further setup. > >1) IPA Client Login issue. >In IPA client, if Windows AD user want to login, It need to type full name >such as 'userA at win_ad.com'. How do I let Windows AD user logon only with >their username? That means only use 'userA' to logon IPA Client PC rather >than 'userA at win_ad.com' ? Not supported. There could be some obscure SSSD setting to allow one SSSD domain (as in /etc/sss/sssd.conf) be default but since trusted AD domains are represented as subdomains of a single IPA provider, full UPN is used to distinguish and discover which subdomain they belong to for performance reasons. >2) Windows Login issue. >I want to logon under Windows AD Client PC (Client PC's OS is Windows 7), >Since this Windows PC already join win_ad domain, it can allow Windows AD >domain user to logon. But when I try to logon IPA user, for example, logon >as 'userB at ipa_ad.com' or 'ipa_ad.com\userB'. It always show 'There are >currently no logon servers available to service the logon request.' and >does not allow IPA user to logon. How do I do now? I need to modify >Windows AD setting? or Windows client PC setting? We do not support this mode yet, it requires implementation of Global Catalog service on IPA side which is not done yet. Plans for doing that are in Fedora 20-21 time frame. >3) Windows Login issue. >Can I login under Windows AD Client PC with IPA username only (not include >IPA domain)? that is, only use 'userB' as username to login? No. Only users from the domain Windows PC is joined to could be logged without explicit domain name. Since IPA domain belongs to a separate forest, you cannot log in without explicit domain prefix. Please note, even that will only be possible when we implement Global Catalog service on IPA side. -- / Alexander Bokovoy From KevinTang at umac.mo Wed Sep 11 06:20:05 2013 From: KevinTang at umac.mo (KevinTang at umac.mo) Date: Wed, 11 Sep 2013 14:20:05 +0800 Subject: [Freeipa-users] IPA AD Trust issue In-Reply-To: <20130911045203.GC21212@redhat.com> References: <20130911045203.GC21212@redhat.com> Message-ID: Dear Alexander, If I use 'ipa-replica-prepare' to replica Windows AD to/from IPA AD, Will all user account in Windows AD 'copy' to IPA AD, and my IPA client can logon with Windows AD username only? (only use 'userA' to login directly, not 'userA at win_ad.com'). Or after replication, can I use IPA account logon Windows Client PC only with ipa username? (only use 'userB' logon, rather than 'userB at ipa_ad.com' to logon). Thank you very much Kevin Tang From: Alexander Bokovoy To: KevinTang at umac.mo Cc: freeipa-users at redhat.com Date: 09/11/2013 12:52 PM Subject: Re: [Freeipa-users] IPA AD Trust issue On Wed, 11 Sep 2013, KevinTang at umac.mo wrote: >Dear all, > >I am new to IPA and have some question about set up. >I already setup IPA server (CentOS 6.4 64bit), IPA client (CentOS 6.4 >64bit), and Windows AD (Windows 2008 R2 Standard 64bit). IPA Server and >Windows AD already have 2-ways trusted. Windows AD user can logon under >IPA client PC. > >I have 3 question about further setup. > >1) IPA Client Login issue. >In IPA client, if Windows AD user want to login, It need to type full name >such as 'userA at win_ad.com'. How do I let Windows AD user logon only with >their username? That means only use 'userA' to logon IPA Client PC rather >than 'userA at win_ad.com' ? Not supported. There could be some obscure SSSD setting to allow one SSSD domain (as in /etc/sss/sssd.conf) be default but since trusted AD domains are represented as subdomains of a single IPA provider, full UPN is used to distinguish and discover which subdomain they belong to for performance reasons. >2) Windows Login issue. >I want to logon under Windows AD Client PC (Client PC's OS is Windows 7), >Since this Windows PC already join win_ad domain, it can allow Windows AD >domain user to logon. But when I try to logon IPA user, for example, logon >as 'userB at ipa_ad.com' or 'ipa_ad.com\userB'. It always show 'There are >currently no logon servers available to service the logon request.' and >does not allow IPA user to logon. How do I do now? I need to modify >Windows AD setting? or Windows client PC setting? We do not support this mode yet, it requires implementation of Global Catalog service on IPA side which is not done yet. Plans for doing that are in Fedora 20-21 time frame. >3) Windows Login issue. >Can I login under Windows AD Client PC with IPA username only (not include >IPA domain)? that is, only use 'userB' as username to login? No. Only users from the domain Windows PC is joined to could be logged without explicit domain name. Since IPA domain belongs to a separate forest, you cannot log in without explicit domain prefix. Please note, even that will only be possible when we implement Global Catalog service on IPA side. -- / Alexander Bokovoy -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Sep 11 06:51:26 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 11 Sep 2013 09:51:26 +0300 Subject: [Freeipa-users] IPA AD Trust issue In-Reply-To: References: <20130911045203.GC21212@redhat.com> Message-ID: <20130911065124.GD21212@redhat.com> On Wed, 11 Sep 2013, KevinTang at umac.mo wrote: >Dear Alexander, > >If I use 'ipa-replica-prepare' to replica Windows AD to/from IPA AD, Will >all user account in Windows AD 'copy' to IPA AD, and my IPA client can >logon with Windows AD username only? (only use 'userA' to login directly, >not 'userA at win_ad.com'). If you are using ipa-replica-prepare against Windows AD, you are using winsync/passsync which is copying user entries from AD to IPA. In this case AD users become IPA users. It is not a trust per se, only a synchronization. In particular, users will not be able to use their AD Kerberos credentials at all. But yes, in winsync case these users will be able to login with just a user name. >Or after replication, can I use IPA account logon Windows Client PC only >with ipa username? (only use 'userB' logon, rather than 'userB at ipa_ad.com' >to logon). No, synchronization is from AD to IPA, not the other way around. A change in IPA for the account which was synchronized from AD will be propagated back to AD but IPA users will not be copied to AD. -- / Alexander Bokovoy From mkosek at redhat.com Wed Sep 11 07:38:57 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 11 Sep 2013 09:38:57 +0200 Subject: [Freeipa-users] IPA Load Problems? In-Reply-To: <52273D87.6010805@redhat.com> References: <70FAFDC6-AC64-4B42-AB75-ABECDE7B350E@digitalreasoning.com> <521D0FCE.3080800@redhat.com> <3B676396-41CB-40BA-A7D2-0E1CB8800C30@digitalreasoning.com> <521E1A03.1060904@redhat.com> <5220F587.6000808@redhat.com> <414556BA-3DDF-4259-AC40-D0778BF474DC@digitalreasoning.com> <5220FFC2.90207@redhat.com> <2C999C19-A8A2-435E-B54F-E6F9F7F964AF@digitalreasoning.com> <52210523.7030403@redhat.com> <6D4BA0C3-5003-46AD-842A-E95194B865E2@digitalreasonin! ! g.com> <522108C9.7030506@redhat.com> <5226E4E9.8090903@r! edhat.com> <52822038-F299-46D2-8BD1-D45DA0D99EA6@digitalreasoning.com> <52273AE3.30808! 06@redhat.com> <8EF44D2E-1F0D-481C-B189-7319248B67A7@digitalreasoning.com> <52273D87.6010805@redhat.com> Message-ID: <52301E11.8090403@redhat.com> On 09/04/2013 04:02 PM, Rich Megginson wrote: > On 09/04/2013 07:58 AM, John Moyer wrote: >> It was our opinion that it wasn't an index issue. I cleared the logs from >> the IPA server, and then just ran a JIRA sync with the server. I gave Rich >> the log file from my IPA for that sync. I can't find the exact conversation, >> but we determined that JIRA was connecting to LDAP some 1000 times or so to >> do the sync. In parallel to our investigation in FreeIPA, I think it would be beneficial to either check if Jira can be configured so that it does the synchronization in one LDAP connection instead of connecting 1000 of times to do the searches. If this is not possible, I think that a bug should be filed so that they can fix it eventually in future versions. > > Right. For every single entry in IPA (user and group), JIRA LDAP sync does - > connect/bind/search/unbind/disconnect. This is horribly inefficient, but it is > what it is, and apparently other apps work the same way (nexus? svn?), so this > would be a good avenue to investigate performance. > >> The logs didn't show but one search done that didn't have an index which is >> why we concluded it wasn't an index issue. > > Adding indexing did help, but not much, and not nearly enough to make the > performance acceptable. Ok, it seems that the problem is indeed a slow LDAP bind with FreeIPA. It is important to note that it will always be slower that simple auth LDAP Binds with a plain LDAP instance as FreeIPA has several DS plugin hooked to the Bind operation which provides some of the functionality. Our current plan is to profile the bind operation and see if some of our DS plugin does not take more time than it should. Hopefully, we will find some suboptimal or unnecessary check which could be optimized and which would improve the overall result. Martin From jhrozek at redhat.com Wed Sep 11 07:42:26 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 11 Sep 2013 09:42:26 +0200 Subject: [Freeipa-users] IPA AD Trust issue In-Reply-To: <20130911045203.GC21212@redhat.com> References: <20130911045203.GC21212@redhat.com> Message-ID: <20130911074226.GA8765@hendrix.brq.redhat.com> > >1) IPA Client Login issue. > >In IPA client, if Windows AD user want to login, It need to type full name > >such as 'userA at win_ad.com'. How do I let Windows AD user logon only with > >their username? That means only use 'userA' to logon IPA Client PC rather > >than 'userA at win_ad.com' ? > Not supported. There could be some obscure SSSD setting to allow one > SSSD domain (as in /etc/sss/sssd.conf) be default but since trusted AD > domains are represented as subdomains of a single IPA provider, full UPN is > used to distinguish and discover which subdomain they belong to for > performance reasons. Actually you can use "default_domain_suffix" in the [sssd] section. But then you need to fully-qualify the users from the IPA domain. default_domain_suffix (string) This string will be used as a default domain name for all names without a domain name component. The main use case is environments where the primary domain is intended for managing host policies and all users are located in a trusted domain. The option allows those users to log in just with their user name without giving a domain name as well. Please note that if this option is set all users from the primary domain have to use their fully qualified name, e.g. user at domain.name, to log in. Default: not set From Johan.Petersson at sscspace.com Wed Sep 11 08:11:24 2013 From: Johan.Petersson at sscspace.com (Johan Petersson) Date: Wed, 11 Sep 2013 08:11:24 +0000 Subject: [Freeipa-users] Clients locked screens freeze or crash problem Message-ID: <558C15177F5E714F83334217C9A197DFED1B8CEE@SSC-MBX2.ssc.internal> Hi, I have a IPA test network based on Red Hat 6.4 Servers and Clients where home directories are shared through NFS4 with krb5p. Autofs is handled by SSSD and everything works great except when the user do not logout and just lock the pc before a weekend or at least longer than a day. In this case the whole desktop crashes or are frozen unresponsive with the screensaver. Could this have to do with the NFS4 Home Directories through Kerberos and that the users ticket is no longer valid? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrezina at redhat.com Wed Sep 11 09:21:51 2013 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Wed, 11 Sep 2013 11:21:51 +0200 Subject: [Freeipa-users] freeipa and sudo In-Reply-To: <1378747930.23322.16.camel@host.hunter.org> References: <1378573597.16595.5.camel@host.hunter.org> <20130907181129.GA23695@fluxcoil.net> <522BB839.7030203@redhat.com> <522D9397.20504@redhat.com> <1378747930.23322.16.camel@host.hunter.org> Message-ID: <5230362F.4060704@redhat.com> On 09/09/2013 07:32 PM, Dean Hunter wrote: > > On Mon, 2013-09-09 at 11:23 +0200, Pavel B?ezina wrote: >> On 09/08/2013 01:35 AM, Dmitri Pal wrote: >>> On 09/07/2013 02:11 PM, Christian Horn wrote: >>>> On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote: >>>>> Are [1] and[2] still the current and best sources of >>>>> information for configuring sudo for use with the current >>>>> release of FreeIPA on Fedora 19? >>>>> >>>>> 1. >>>>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html >> >>>>> >>> 2. >>>>> http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >> >>>>> >> There is also the Identity_Management_Guide as part of the RHEL >>>> product documentation: >>>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html >> >>>> > This and the pdf above are the latest word in this area. >> >> Hi, those documents describes configuration for SSSD 1.9. Although >> it is still valid, we have simplified configuration for IPA >> provider in 1.10. >> >> The most up to date document for your version of SSSD is always >> man sssd-sudo. >> >> _______________________________________________ Freeipa-users >> mailing list Freeipa-users at redhat.com >> >> https://www.redhat.com/mailman/listinfo/freeipa-users > > Thank you. Please verify that I have correctly understood your note. > Your slides from 12-20-2012 applied to SSSD 1.9 and included a > reference to the manual pages, which I now understand, as well as > this example configuration: > > sudo_provider = ldap ldap_uri = ldap://ipa.example.com > ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_sasl_mech = > GSSAPI ldap_sasl_authid = host/hostname.example.com ldap_sasl_realm = > EXAMPLE.COM krb5_server = ipa.example.com > > I have used this configuration with good results. However, reading > "man sssd-sudo" from sssd-1.9.5-2.fc18.x86_64 I find this paragraph: > > When the SSSD is configured to use the IPA provider, the sudo > provider is automatically enabled. The sudo search base is configured > to use the compat tree (ou=sudoers,$DC). I forgot that the configuration was simplified also in 1.9. You can just stick with contents of sssd-sudo. I.e. you only need to put sudo to "services" (there's an RFE to do it automatically by ipa-client-install) and "sudoers: files sss" to /etc/nsswitch.conf > May I suggest that you change "IPA provider" to "IPA as the ID > provider"? There are a number of providers identified in sssd.conf > and most of them are configured to use IPA. This is a valid point, thanks. > > Testing shows that the only change now required to sssd.conf is the > addition of sudo to the services list in the sssd section [sssd]: > > services = autofs, nss, pam, ssh, sudo > > Add to this the one line change in nsswitch.conf > > sudoers: files sss > > and I am done. Correct. From pbrezina at redhat.com Wed Sep 11 09:27:02 2013 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Wed, 11 Sep 2013 11:27:02 +0200 Subject: [Freeipa-users] freeipa and sudo In-Reply-To: <1378741982.15777.3.camel@host.hunter.org> References: <1378573597.16595.5.camel@host.hunter.org> <20130907181129.GA23695@fluxcoil.net> <522BB839.7030203@redhat.com> <1378672936.24034.5.camel@host.hunter.org> <20130908211122.GA11616@hendrix.redhat.com> <1378679187.24034.15.camel@host.hunter.org> <522D9678.5020005@redhat.com> <1378741982.15777.3.camel@host.hunter.org> Message-ID: <52303766.6080107@redhat.com> On 09/09/2013 05:53 PM, Dean Hunter wrote: > On Mon, 2013-09-09 at 11:35 +0200, Pavel B?ezina wrote: >> On 09/09/2013 12:26 AM, Dean Hunter wrote: >> > On Sun, 2013-09-08 at 23:11 +0200, Jakub Hrozek wrote: >> >> On Sun, Sep 08, 2013 at 03:42:16PM -0500, Dean Hunter wrote: >> >> > On Sat, 2013-09-07 at 19:35 -0400, Dmitri Pal wrote: >> >> > >> >> > > On 09/07/2013 02:11 PM, Christian Horn wrote: >> >> > > > On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote: >> >> > > >> Are [1] and[2] still the current and best sources of information for >> >> > > >> configuring sudo for use with the current release of FreeIPA on Fedora >> >> > > >> 19? >> >> > > >> >> >> > > >> 1. >> >> > > >>http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html >> >> > > >> 2. >> >> > > >>http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >> >> > > > There is also the Identity_Management_Guide as part of the RHEL >> >> > > > product documentation: >> >> > > >https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html >> >> > > This and the pdf above are the latest word in this area. >> >> > > >> >> > > > Christian >> >> > > > >> >> > > > _______________________________________________ >> >> > > > Freeipa-users mailing list >> >> > > >Freeipa-users at redhat.com >> >> > > >https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > >> >> > > >> >> > >> >> > Some sudo rules are causing: >> >> > >> >> > [dean at desktop2 ~]$ sudo id >> >> > sudo: internal error, tried to erealloc3(0) >> >> >> >> This is a known bug: >> >>https://bugzilla.redhat.com/show_bug.cgi?id=1000389 >> >> >> >> I think the sudo rules are just missing the sudoHost attribute. >> >> >> >> > >> >> > , but others do not. In the trial and error process of determining >> >> > which rule specifications are causing the error, I have been restarting >> >> > the virtual machine I am using as the sudo client between tests. Is >> >> > there a better way to clear the SSSD cache between trials to make sure I >> >> > am testing the most recent rule change? >> >> >> >> Unfortunately right now the only way is to rm the sssd cache which would >> >> also remove any cached credentials. I thought there was an RFE open to >> >> track the enhancement to make sss_cache invalidate and refresh sudo >> >> rules, but I can't find it now in the SSSD trac, so I filed another one: >> >>https://fedorahosted.org/sssd/ticket/2081 >> >> >> >> Worst case, we mark it as a duplicate. >> >> >> >> _______________________________________________ >> >> Freeipa-users mailing list >> >>Freeipa-users at redhat.com >> >>https://www.redhat.com/mailman/listinfo/freeipa-users >> > >> > I saw bug report 1000389, but I could not understand it or whether it >> > applied to me. >> > >> > I discovered that sudo rules for which I specified a host group caused >> > the error. Rules with a host category of "all" instead of the host >> > group did not cause the error. Is this what 1000389 says? >> > >> > ipa sudorule-add server-admins --desc "Server Administrators" >> > ipa sudorule-mod server-admins --cmdcat all >> > # ipa sudorule-add-host server-admins --hostgroups servers >> > ipa sudorule-mod server-admins --hostcat all >> > ipa sudorule-add-option server-admins --sudooption '!authenticate' >> > ipa sudorule-add-runasuser server-admins --users root >> > ipa sudorule-add-runasgroup server-admins --groups root >> > ipa sudorule-add-user server-admins --groups server-admins >> >> Does the machine where sudo prints this error belongs to the hostgroup >> 'servers'? If the answer is *no* then you are hitting 1000389. > > Yes, the virtual machine where the sudo internal error occurs is a > member of the hostgroup. So I guess this is a new error and should be > reported? FYI Dean reported https://bugzilla.redhat.com/show_bug.cgi?id=1006611 I still think it is the same bug as 1000389, however with slightly different back trace. I'll follow up in BZ. > >> > This problem exists with the latest updates on both Fedora 18 and Fedora 19. >> > >> > I also discovered that libsss_sudo.so is missing from Fedora 18 >> > installations. >> >> It needs to be installed separately by installing libsss_sudo package. > > Yes, I did find the package and installed it. > >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From pbrezina at redhat.com Wed Sep 11 09:38:05 2013 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Wed, 11 Sep 2013 11:38:05 +0200 Subject: [Freeipa-users] freeipa and sudo In-Reply-To: <5230362F.4060704@redhat.com> References: <1378573597.16595.5.camel@host.hunter.org> <20130907181129.GA23695@fluxcoil.net> <522BB839.7030203@redhat.com> <522D9397.20504@redhat.com> <1378747930.23322.16.camel@host.hunter.org> <5230362F.4060704@redhat.com> Message-ID: <523039FD.9060900@redhat.com> On 09/11/2013 11:21 AM, Pavel B?ezina wrote: > On 09/09/2013 07:32 PM, Dean Hunter wrote: >> >> On Mon, 2013-09-09 at 11:23 +0200, Pavel B?ezina wrote: >>> On 09/08/2013 01:35 AM, Dmitri Pal wrote: >>>> On 09/07/2013 02:11 PM, Christian Horn wrote: >>>>> On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote: >>>>>> Are [1] and[2] still the current and best sources of >>>>>> information for configuring sudo for use with the current >>>>>> release of FreeIPA on Fedora 19? >>>>>> >>>>>> 1. >>>>>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html >>>>>> >>> >>>>>> >>>> 2. >>>>>> http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >>>>>> >>> >>>>>> >>> There is also the Identity_Management_Guide as part of the RHEL >>>>> product documentation: >>>>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html >>>>> >>> >>>>> >> This and the pdf above are the latest word in this area. >>> >>> Hi, those documents describes configuration for SSSD 1.9. Although >>> it is still valid, we have simplified configuration for IPA >>> provider in 1.10. >>> >>> The most up to date document for your version of SSSD is always >>> man sssd-sudo. >>> >>> _______________________________________________ Freeipa-users >>> mailing list Freeipa-users at redhat.com >>> >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> Thank you. Please verify that I have correctly understood your note. >> Your slides from 12-20-2012 applied to SSSD 1.9 and included a >> reference to the manual pages, which I now understand, as well as >> this example configuration: >> >> sudo_provider = ldap ldap_uri = ldap://ipa.example.com >> ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_sasl_mech = >> GSSAPI ldap_sasl_authid = host/hostname.example.com ldap_sasl_realm = >> EXAMPLE.COM krb5_server = ipa.example.com >> >> I have used this configuration with good results. However, reading >> "man sssd-sudo" from sssd-1.9.5-2.fc18.x86_64 I find this paragraph: >> >> When the SSSD is configured to use the IPA provider, the sudo >> provider is automatically enabled. The sudo search base is configured >> to use the compat tree (ou=sudoers,$DC). > > I forgot that the configuration was simplified also in 1.9. You can just > stick with contents of sssd-sudo. I.e. you only need to put sudo to > "services" (there's an RFE to do it automatically by ipa-client-install) > and "sudoers: files sss" to /etc/nsswitch.conf > >> May I suggest that you change "IPA provider" to "IPA as the ID >> provider"? There are a number of providers identified in sssd.conf >> and most of them are configured to use IPA. > > This is a valid point, thanks. https://fedorahosted.org/sssd/ticket/2085 > >> >> Testing shows that the only change now required to sssd.conf is the >> addition of sudo to the services list in the sssd section [sssd]: >> >> services = autofs, nss, pam, ssh, sudo >> >> Add to this the one line change in nsswitch.conf >> >> sudoers: files sss >> >> and I am done. > > Correct. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From KevinTang at umac.mo Wed Sep 11 09:57:00 2013 From: KevinTang at umac.mo (KevinTang at umac.mo) Date: Wed, 11 Sep 2013 17:57:00 +0800 Subject: [Freeipa-users] IPA AD Trust issue In-Reply-To: <20130911065124.GD21212@redhat.com> References: <20130911045203.GC21212@redhat.com> <20130911065124.GD21212@redhat.com> Message-ID: Dear Alexander, Understand, thank you very much. Kevin. From: Alexander Bokovoy To: KevinTang at umac.mo Cc: freeipa-users at redhat.com Date: 09/11/2013 02:52 PM Subject: Re: [Freeipa-users] IPA AD Trust issue On Wed, 11 Sep 2013, KevinTang at umac.mo wrote: >Dear Alexander, > >If I use 'ipa-replica-prepare' to replica Windows AD to/from IPA AD, Will >all user account in Windows AD 'copy' to IPA AD, and my IPA client can >logon with Windows AD username only? (only use 'userA' to login directly, >not 'userA at win_ad.com'). If you are using ipa-replica-prepare against Windows AD, you are using winsync/passsync which is copying user entries from AD to IPA. In this case AD users become IPA users. It is not a trust per se, only a synchronization. In particular, users will not be able to use their AD Kerberos credentials at all. But yes, in winsync case these users will be able to login with just a user name. >Or after replication, can I use IPA account logon Windows Client PC only >with ipa username? (only use 'userB' logon, rather than 'userB at ipa_ad.com' >to logon). No, synchronization is from AD to IPA, not the other way around. A change in IPA for the account which was synchronized from AD will be propagated back to AD but IPA users will not be copied to AD. -- / Alexander Bokovoy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Wed Sep 11 10:41:19 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 11 Sep 2013 12:41:19 +0200 Subject: [Freeipa-users] Clients locked screens freeze or crash problem In-Reply-To: <558C15177F5E714F83334217C9A197DFED1B8CEE@SSC-MBX2.ssc.internal> References: <558C15177F5E714F83334217C9A197DFED1B8CEE@SSC-MBX2.ssc.internal> Message-ID: <20130911104119.GF8765@hendrix.brq.redhat.com> On Wed, Sep 11, 2013 at 08:11:24AM +0000, Johan Petersson wrote: > Hi, > > I have a IPA test network based on Red Hat 6.4 Servers and Clients where home directories are shared through NFS4 with krb5p. > Autofs is handled by SSSD and everything works great except when the user do not logout and just lock the pc before a weekend or at least longer than a day. In this case the whole desktop crashes or are frozen unresponsive with the screensaver. > > Could this have to do with the NFS4 Home Directories through Kerberos and that the users ticket is no longer valid? Hi Johann, is the home directory mounted using user's credentials? Have you checked the Kerberos credentials renewing? See man sssd-krb5, options like krb5_renew_interval From deanhunter at comcast.net Wed Sep 11 13:27:31 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Wed, 11 Sep 2013 08:27:31 -0500 Subject: [Freeipa-users] Permission Denied In-Reply-To: <20130911041030.GB21212@redhat.com> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> Message-ID: <1378906051.23036.12.camel@host.hunter.org> On Wed, 2013-09-11 at 07:10 +0300, Alexander Bokovoy wrote: > Hi Dean, > > On Tue, 10 Sep 2013, Dean Hunter wrote: > >How do I determine the cause of this problem? > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > Last login: Tue Sep 10 21:10:01 2013 from ipa2.hunter.org > > Could not chdir to home directory /home/net/dean: Permission > > denied > > -bash: /home/net/dean/.bash_profile: Permission denied > > > > -bash-4.2$ rpm -q freeipa-client > > freeipa-client-3.1.5-1.fc18.x86_64 > > -bash-4.2$ > > > >I can log in as dean on desktop2 using gdm without a problem. But when > >I try to log in using ssh then I am denied access to the user's home > >directory. > Is there any SELinux AVC in the logs? Is /home/net an NFS mount? Does > use_nfs_home_dirs SELinux boolean set to on? (getsebool -a|grep home) > 1) Is there any SELinux AVC in the logs? [dean at desktop2 ~]$ sudo ausearch --message avc 2) Is /home/net an NFS mount? Yes 3) Is use_nfs_home_dirs SELinux boolean set to on? [dean at desktop2 ~]$ getsebool use_nfs_home_dirs use_nfs_home_dirs --> on Here is the script I use to configure IPA NFS clients: # Configure the Network File System client setsebool -P use_nfs_home_dirs on cat /usr/lib/systemd/system/nfs-secure.service \ | sed -e s/WantedBy=nfs.target/WantedBy=multi-user.target/ \ > /etc/systemd/system/nfs-secure.service # RedHat bug 972363 ipa-client-automount \\ --location VM \\ --unattended sed -i 's/sss files/ files sss/g' /etc/nsswitch.conf # FreeIPA bug 3733 systemctl restart sssd.service # FreeIPA bug 3733 systemctl restart autofs.service # FreeIPA bug 3733 -------------- next part -------------- An HTML attachment was scrubbed... URL: From deanhunter at comcast.net Wed Sep 11 13:39:15 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Wed, 11 Sep 2013 08:39:15 -0500 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1378906051.23036.12.camel@host.hunter.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> Message-ID: <1378906755.23036.14.camel@host.hunter.org> On Wed, 2013-09-11 at 08:27 -0500, Dean Hunter wrote: > On Wed, 2013-09-11 at 07:10 +0300, Alexander Bokovoy wrote: > > > Hi Dean, > > > > On Tue, 10 Sep 2013, Dean Hunter wrote: > > >How do I determine the cause of this problem? > > > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > > Last login: Tue Sep 10 21:10:01 2013 from ipa2.hunter.org > > > Could not chdir to home directory /home/net/dean: Permission > > > denied > > > -bash: /home/net/dean/.bash_profile: Permission denied > > > > > > -bash-4.2$ rpm -q freeipa-client > > > freeipa-client-3.1.5-1.fc18.x86_64 > > > -bash-4.2$ > > > > > >I can log in as dean on desktop2 using gdm without a problem. But when > > >I try to log in using ssh then I am denied access to the user's home > > >directory. > > Is there any SELinux AVC in the logs? Is /home/net an NFS mount? Does > > use_nfs_home_dirs SELinux boolean set to on? (getsebool -a|grep home) > > > > 1) Is there any SELinux AVC in the logs? > > [dean at desktop2 ~]$ sudo ausearch --message avc > > > > 2) Is /home/net an NFS mount? Yes > > 3) Is use_nfs_home_dirs SELinux boolean set to on? > > [dean at desktop2 ~]$ getsebool use_nfs_home_dirs > use_nfs_home_dirs --> on > > > Here is the script I use to configure IPA NFS clients: > > # Configure the Network File System client > > setsebool -P use_nfs_home_dirs on > > cat /usr/lib/systemd/system/nfs-secure.service \ > | sed -e s/WantedBy=nfs.target/WantedBy=multi-user.target/ > \ > > /etc/systemd/system/nfs-secure.service # > RedHat bug 972363 > > ipa-client-automount \\ > --location VM \\ > --unattended > > sed -i 's/sss files/ files sss/g' /etc/nsswitch.conf # > FreeIPA bug 3733 > systemctl restart sssd.service # > FreeIPA bug 3733 > systemctl restart autofs.service # > FreeIPA bug 3733 > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users I do NOT believe this: [dean at ipa2 ~]$ ssh dean at desktop2 Last login: Wed Sep 11 08:32:21 2013 from ipa2.hunter.org Could not chdir to home directory /home/net/dean: Permission denied -bash: /home/net/dean/.bash_profile: Permission denied -bash-4.2$ logout -bash: /home/net/dean/.bash_logout: Permission denied Connection to desktop2 closed. [dean at ipa2 ~]$ su - Password: [root at ipa2 ~]# ssh dean at desktop2 dean at desktop2's password: Last login: Wed Sep 11 08:34:29 2013 from ipa2.hunter.org [dean at desktop2 ~]$ logout Connection to desktop2 closed. [root at ipa2 ~]# logout [dean at ipa2 ~]$ ssh dean at desktop2 Last login: Wed Sep 11 08:35:16 2013 from ipa2.hunter.org [dean at desktop2 ~]$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Sep 11 15:20:05 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Sep 2013 11:20:05 -0400 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1378906755.23036.14.camel@host.hunter.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> Message-ID: <1378912805.2804.1603.camel@willson.li.ssimo.org> On Wed, 2013-09-11 at 08:39 -0500, Dean Hunter wrote: > I do NOT believe this: > [dean at ipa2 ~]$ ssh dean at desktop2 > Last login: Wed Sep 11 08:32:21 2013 from ipa2.hunter.org > Could not chdir to home directory /home/net/dean: Permission > denied > -bash: /home/net/dean/.bash_profile: Permission denied > > -bash-4.2$ logout > -bash: /home/net/dean/.bash_logout: Permission denied > Connection to desktop2 closed. > > [dean at ipa2 ~]$ su - > Password: > > [root at ipa2 ~]# ssh dean at desktop2 > dean at desktop2's password: > Last login: Wed Sep 11 08:34:29 2013 from ipa2.hunter.org > > [dean at desktop2 ~]$ logout > Connection to desktop2 closed. > > [root at ipa2 ~]# logout > > [dean at ipa2 ~]$ ssh dean at desktop2 > Last login: Wed Sep 11 08:35:16 2013 from ipa2.hunter.org > > [dean at desktop2 ~]$ > Are you using a kerberized NFS mount ? I think what is happening is that when going via SSH rpc.gssd cannot find your ticket, ssh may be doing something "wrong" in this case. Simo. -- Simo Sorce * Red Hat, Inc * New York From deanhunter at comcast.net Wed Sep 11 15:39:51 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Wed, 11 Sep 2013 10:39:51 -0500 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1378912805.2804.1603.camel@willson.li.ssimo.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> Message-ID: <1378913991.23036.16.camel@host.hunter.org> On Wed, 2013-09-11 at 11:20 -0400, Simo Sorce wrote: > On Wed, 2013-09-11 at 08:39 -0500, Dean Hunter wrote: > > > I do NOT believe this: > > [dean at ipa2 ~]$ ssh dean at desktop2 > > Last login: Wed Sep 11 08:32:21 2013 from ipa2.hunter.org > > Could not chdir to home directory /home/net/dean: Permission > > denied > > -bash: /home/net/dean/.bash_profile: Permission denied > > > > -bash-4.2$ logout > > -bash: /home/net/dean/.bash_logout: Permission denied > > Connection to desktop2 closed. > > > > [dean at ipa2 ~]$ su - > > Password: > > > > [root at ipa2 ~]# ssh dean at desktop2 > > dean at desktop2's password: > > Last login: Wed Sep 11 08:34:29 2013 from ipa2.hunter.org > > > > [dean at desktop2 ~]$ logout > > Connection to desktop2 closed. > > > > [root at ipa2 ~]# logout > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > Last login: Wed Sep 11 08:35:16 2013 from ipa2.hunter.org > > > > [dean at desktop2 ~]$ > > > > Are you using a kerberized NFS mount ? > > I think what is happening is that when going via SSH rpc.gssd cannot > find your ticket, ssh may be doing something "wrong" in this case. > > Simo. > Yes, I am using Kerberos with NFS. Should I report this as a bug? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Sep 11 15:49:28 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Sep 2013 11:49:28 -0400 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1378913991.23036.16.camel@host.hunter.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> Message-ID: <1378914568.2804.1606.camel@willson.li.ssimo.org> On Wed, 2013-09-11 at 10:39 -0500, Dean Hunter wrote: > On Wed, 2013-09-11 at 11:20 -0400, Simo Sorce wrote: > > On Wed, 2013-09-11 at 08:39 -0500, Dean Hunter wrote: > > > > > I do NOT believe this: > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > > Last login: Wed Sep 11 08:32:21 2013 from ipa2.hunter.org > > > Could not chdir to home directory /home/net/dean: Permission > > > denied > > > -bash: /home/net/dean/.bash_profile: Permission denied > > > > > > -bash-4.2$ logout > > > -bash: /home/net/dean/.bash_logout: Permission denied > > > Connection to desktop2 closed. > > > > > > [dean at ipa2 ~]$ su - > > > Password: > > > > > > [root at ipa2 ~]# ssh dean at desktop2 > > > dean at desktop2's password: > > > Last login: Wed Sep 11 08:34:29 2013 from ipa2.hunter.org > > > > > > [dean at desktop2 ~]$ logout > > > Connection to desktop2 closed. > > > > > > [root at ipa2 ~]# logout > > > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > > Last login: Wed Sep 11 08:35:16 2013 from ipa2.hunter.org > > > > > > [dean at desktop2 ~]$ > > > > > > > Are you using a kerberized NFS mount ? > > > > I think what is happening is that when going via SSH rpc.gssd cannot > > find your ticket, ssh may be doing something "wrong" in this case. > > > > Simo. > > > Yes, I am using Kerberos with NFS. > > Should I report this as a bug? > We need to decide what component is faulty. It may be possible we can get it working somehow. When you ssh in what is the ccache ssh assign you ? can you run klist and post the output (sanitize it if needed) ? Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Wed Sep 11 16:08:17 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Sep 2013 12:08:17 -0400 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1378914568.2804.1606.camel@willson.li.ssimo.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> Message-ID: <52309571.50703@redhat.com> On 09/11/2013 11:49 AM, Simo Sorce wrote: > On Wed, 2013-09-11 at 10:39 -0500, Dean Hunter wrote: >> On Wed, 2013-09-11 at 11:20 -0400, Simo Sorce wrote: >>> On Wed, 2013-09-11 at 08:39 -0500, Dean Hunter wrote: >>> >>>> I do NOT believe this: >>>> [dean at ipa2 ~]$ ssh dean at desktop2 >>>> Last login: Wed Sep 11 08:32:21 2013 from ipa2.hunter.org >>>> Could not chdir to home directory /home/net/dean: Permission >>>> denied >>>> -bash: /home/net/dean/.bash_profile: Permission denied >>>> >>>> -bash-4.2$ logout >>>> -bash: /home/net/dean/.bash_logout: Permission denied >>>> Connection to desktop2 closed. >>>> >>>> [dean at ipa2 ~]$ su - >>>> Password: >>>> >>>> [root at ipa2 ~]# ssh dean at desktop2 >>>> dean at desktop2's password: >>>> Last login: Wed Sep 11 08:34:29 2013 from ipa2.hunter.org >>>> >>>> [dean at desktop2 ~]$ logout >>>> Connection to desktop2 closed. >>>> >>>> [root at ipa2 ~]# logout >>>> >>>> [dean at ipa2 ~]$ ssh dean at desktop2 >>>> Last login: Wed Sep 11 08:35:16 2013 from ipa2.hunter.org >>>> >>>> [dean at desktop2 ~]$ >>>> >>> Are you using a kerberized NFS mount ? >>> >>> I think what is happening is that when going via SSH rpc.gssd cannot >>> find your ticket, ssh may be doing something "wrong" in this case. >>> >>> Simo. >>> >> Yes, I am using Kerberos with NFS. >> >> Should I report this as a bug? >> > We need to decide what component is faulty. It may be possible we can > get it working somehow. > > When you ssh in what is the ccache ssh assign you ? > can you run klist and post the output (sanitize it if needed) ? > > Simo. > Simo, Would setting KRBCCACHE explicitly on the client help? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From christovamps at gmail.com Wed Sep 11 17:06:40 2013 From: christovamps at gmail.com (Christovam Paynes Silva) Date: Wed, 11 Sep 2013 14:06:40 -0300 Subject: [Freeipa-users] FreeIPA integrating samba4 + AD Message-ID: Hello! First I apologize if this topic is redundant. I'm looking on the implementation of FreeIPA . Looking for the forums , have some comments that authentication does not work with Samba4 . Elsewhere say that that possibility exists . Today we have nearly 200 computers in the domain with the "Active Directory" and one wireless "captive portal" with 1000 + proxy users . I would like to see if the following scenario is possible : 1 - Integrating Samba4 with "Active Directory" , to use their GPO and authenticate network users through the FreeIPA . 2 - Authenticate proxy servers in FreeIPA . 3 - And if it is possible some integration with FreeRADIUS Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Sep 11 19:25:20 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Sep 2013 15:25:20 -0400 Subject: [Freeipa-users] Permission Denied In-Reply-To: <52309571.50703@redhat.com> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> <52309571.50703@redhat.com> Message-ID: <1378927520.2804.1702.camel@willson.li.ssimo.org> On Wed, 2013-09-11 at 12:08 -0400, Dmitri Pal wrote: > On 09/11/2013 11:49 AM, Simo Sorce wrote: > > On Wed, 2013-09-11 at 10:39 -0500, Dean Hunter wrote: > >> On Wed, 2013-09-11 at 11:20 -0400, Simo Sorce wrote: > >>> On Wed, 2013-09-11 at 08:39 -0500, Dean Hunter wrote: > >>> > >>>> I do NOT believe this: > >>>> [dean at ipa2 ~]$ ssh dean at desktop2 > >>>> Last login: Wed Sep 11 08:32:21 2013 from ipa2.hunter.org > >>>> Could not chdir to home directory /home/net/dean: Permission > >>>> denied > >>>> -bash: /home/net/dean/.bash_profile: Permission denied > >>>> > >>>> -bash-4.2$ logout > >>>> -bash: /home/net/dean/.bash_logout: Permission denied > >>>> Connection to desktop2 closed. > >>>> > >>>> [dean at ipa2 ~]$ su - > >>>> Password: > >>>> > >>>> [root at ipa2 ~]# ssh dean at desktop2 > >>>> dean at desktop2's password: > >>>> Last login: Wed Sep 11 08:34:29 2013 from ipa2.hunter.org > >>>> > >>>> [dean at desktop2 ~]$ logout > >>>> Connection to desktop2 closed. > >>>> > >>>> [root at ipa2 ~]# logout > >>>> > >>>> [dean at ipa2 ~]$ ssh dean at desktop2 > >>>> Last login: Wed Sep 11 08:35:16 2013 from ipa2.hunter.org > >>>> > >>>> [dean at desktop2 ~]$ > >>>> > >>> Are you using a kerberized NFS mount ? > >>> > >>> I think what is happening is that when going via SSH rpc.gssd cannot > >>> find your ticket, ssh may be doing something "wrong" in this case. > >>> > >>> Simo. > >>> > >> Yes, I am using Kerberos with NFS. > >> > >> Should I report this as a bug? > >> > > We need to decide what component is faulty. It may be possible we can > > get it working somehow. > > > > When you ssh in what is the ccache ssh assign you ? > > can you run klist and post the output (sanitize it if needed) ? > > > > Simo. > > > > Simo, > > Would setting KRBCCACHE explicitly on the client help? It depends, it would not help if you used GSSAPI SSO auth but did *not* delegate your credentials for example, as you have no credentials on the target system in that case. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Sep 11 19:28:02 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Sep 2013 15:28:02 -0400 Subject: [Freeipa-users] FreeIPA integrating samba4 + AD In-Reply-To: References: Message-ID: <1378927682.2804.1708.camel@willson.li.ssimo.org> On Wed, 2013-09-11 at 14:06 -0300, Christovam Paynes Silva wrote: > Hello! > > > First I apologize if this topic is redundant. > > > I'm looking on the implementation of FreeIPA . Looking for the > forums , have some comments that authentication does not work with > Samba4 . Elsewhere say that that possibility exists . Today we have > nearly 200 computers in the domain with the "Active Directory" and one > wireless "captive portal" with 1000 + proxy users . > > I would like to see if the following scenario is possible : > 1 - Integrating Samba4 with "Active Directory" , to use their GPO and > authenticate network users through the FreeIPA . > 2 - Authenticate proxy servers in FreeIPA . > 3 - And if it is possible some integration with FreeRADIUS > Hi Christovam, it is a bit unclear what you mean by integrating here. Is your intent to use Samba4 as an AD domain controller for your Windows client s and IPA for your servers ? If that's the case unfortunately this is not possible at the moment as samba4 does not yet support Forest level trusts. A Microsoft AD server can be used this way instead. Simo. -- Simo Sorce * Red Hat, Inc * New York From christovamps at gmail.com Wed Sep 11 19:37:52 2013 From: christovamps at gmail.com (Christovam Paynes Silva) Date: Wed, 11 Sep 2013 16:37:52 -0300 Subject: [Freeipa-users] FreeIPA integrating samba4 + AD In-Reply-To: <1378927682.2804.1708.camel@willson.li.ssimo.org> References: <1378927682.2804.1708.camel@willson.li.ssimo.org> Message-ID: Hello Simo, thanks for the feedback. I would use the Samba4 with AD and authenticate my clients windows in FreeIPA. Is this possible? 2013/9/11 Simo Sorce > On Wed, 2013-09-11 at 14:06 -0300, Christovam Paynes Silva wrote: > > Hello! > > > > > > First I apologize if this topic is redundant. > > > > > > I'm looking on the implementation of FreeIPA . Looking for the > > forums , have some comments that authentication does not work with > > Samba4 . Elsewhere say that that possibility exists . Today we have > > nearly 200 computers in the domain with the "Active Directory" and one > > wireless "captive portal" with 1000 + proxy users . > > > > I would like to see if the following scenario is possible : > > 1 - Integrating Samba4 with "Active Directory" , to use their GPO and > > authenticate network users through the FreeIPA . > > 2 - Authenticate proxy servers in FreeIPA . > > 3 - And if it is possible some integration with FreeRADIUS > > > > Hi Christovam, it is a bit unclear what you mean by integrating here. > > Is your intent to use Samba4 as an AD domain controller for your Windows > client s and IPA for your servers ? > > If that's the case unfortunately this is not possible at the moment as > samba4 does not yet support Forest level trusts. > A Microsoft AD server can be used this way instead. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Sep 11 19:59:26 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Sep 2013 15:59:26 -0400 Subject: [Freeipa-users] FreeIPA integrating samba4 + AD In-Reply-To: References: <1378927682.2804.1708.camel@willson.li.ssimo.org> Message-ID: <1378929566.2804.1745.camel@willson.li.ssimo.org> On Wed, 2013-09-11 at 16:37 -0300, Christovam Paynes Silva wrote: > Hello Simo, thanks for the feedback. > I would use the Samba4 with AD and authenticate my clients windows in > FreeIPA. > Is this possible? It is not possible at this point to combine Samba4 AD and freeIPA. Simo. > > 2013/9/11 Simo Sorce > On Wed, 2013-09-11 at 14:06 -0300, Christovam Paynes Silva > wrote: > > Hello! > > > > > > First I apologize if this topic is redundant. > > > > > > I'm looking on the implementation of FreeIPA . Looking for > the > > forums , have some comments that authentication does not > work with > > Samba4 . Elsewhere say that that possibility exists . Today > we have > > nearly 200 computers in the domain with the "Active > Directory" and one > > wireless "captive portal" with 1000 + proxy users . > > > > I would like to see if the following scenario is possible : > > 1 - Integrating Samba4 with "Active Directory" , to use > their GPO and > > authenticate network users through the FreeIPA . > > 2 - Authenticate proxy servers in FreeIPA . > > 3 - And if it is possible some integration with FreeRADIUS > > > > > Hi Christovam, it is a bit unclear what you mean by > integrating here. > > Is your intent to use Samba4 as an AD domain controller for > your Windows > client s and IPA for your servers ? > > If that's the case unfortunately this is not possible at the > moment as > samba4 does not yet support Forest level trusts. > A Microsoft AD server can be used this way instead. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > > -- Simo Sorce * Red Hat, Inc * New York From christovamps at gmail.com Wed Sep 11 20:02:19 2013 From: christovamps at gmail.com (Christovam Paynes Silva) Date: Wed, 11 Sep 2013 17:02:19 -0300 Subject: [Freeipa-users] FreeIPA integrating samba4 + AD In-Reply-To: <1378929566.2804.1745.camel@willson.li.ssimo.org> References: <1378927682.2804.1708.camel@willson.li.ssimo.org> <1378929566.2804.1745.camel@willson.li.ssimo.org> Message-ID: It is a pity! Thank you! 2013/9/11 Simo Sorce > On Wed, 2013-09-11 at 16:37 -0300, Christovam Paynes Silva wrote: > > Hello Simo, thanks for the feedback. > > I would use the Samba4 with AD and authenticate my clients windows in > > FreeIPA. > > Is this possible? > > It is not possible at this point to combine Samba4 AD and freeIPA. > > Simo. > > > > 2013/9/11 Simo Sorce > > On Wed, 2013-09-11 at 14:06 -0300, Christovam Paynes Silva > > wrote: > > > Hello! > > > > > > > > > First I apologize if this topic is redundant. > > > > > > > > > I'm looking on the implementation of FreeIPA . Looking for > > the > > > forums , have some comments that authentication does not > > work with > > > Samba4 . Elsewhere say that that possibility exists . Today > > we have > > > nearly 200 computers in the domain with the "Active > > Directory" and one > > > wireless "captive portal" with 1000 + proxy users . > > > > > > I would like to see if the following scenario is possible : > > > 1 - Integrating Samba4 with "Active Directory" , to use > > their GPO and > > > authenticate network users through the FreeIPA . > > > 2 - Authenticate proxy servers in FreeIPA . > > > 3 - And if it is possible some integration with FreeRADIUS > > > > > > > > > Hi Christovam, it is a bit unclear what you mean by > > integrating here. > > > > Is your intent to use Samba4 as an AD domain controller for > > your Windows > > client s and IPA for your servers ? > > > > If that's the case unfortunately this is not possible at the > > moment as > > samba4 does not yet support Forest level trusts. > > A Microsoft AD server can be used this way instead. > > > > Simo. > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > > > > > > > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Sep 11 21:21:32 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Sep 2013 17:21:32 -0400 Subject: [Freeipa-users] FreeIPA integrating samba4 + AD In-Reply-To: References: <1378927682.2804.1708.camel@willson.li.ssimo.org> <1378929566.2804.1745.camel@willson.li.ssimo.org> Message-ID: <5230DEDC.9080207@redhat.com> On 09/11/2013 04:02 PM, Christovam Paynes Silva wrote: > It is a pity! > Thank you! I did not get a feeling that we understand the whole picture correctly to say that we provided the full answer.. What I get from the description: 1) Presence of Windows Clients = 100 2) Presence of AD to rule them 3) Presence of users (I deduce in AD too, but unclear) = 1000 Intent: use open source technologies instead of proprietary solution. What is not clear: a) Are the users that come through the portal the same users that use Windows Clients or not? Is there an overlap? b) Is there any kind of Linux servers/machines in the picture? If you do not have Linux systems and all users can be stored in one place it might be that you do not need FreeIPA. It might be that you can solve the problem by using Samba4 instead of AD, connecting your clients to it, putting your external portal users into a special OU in Samba4, configuring FreeRADIUS to use this OU for authentication. Configure your portal to use RADIUS. HTH Thanks Dmitri > > > 2013/9/11 Simo Sorce > > > On Wed, 2013-09-11 at 16:37 -0300, Christovam Paynes Silva wrote: > > Hello Simo, thanks for the feedback. > > I would use the Samba4 with AD and authenticate my clients > windows in > > FreeIPA. > > Is this possible? > > It is not possible at this point to combine Samba4 AD and freeIPA. > > Simo. > > > > 2013/9/11 Simo Sorce > > > On Wed, 2013-09-11 at 14:06 -0300, Christovam Paynes Silva > > wrote: > > > Hello! > > > > > > > > > First I apologize if this topic is redundant. > > > > > > > > > I'm looking on the implementation of FreeIPA . Looking for > > the > > > forums , have some comments that authentication does not > > work with > > > Samba4 . Elsewhere say that that possibility exists . > Today > > we have > > > nearly 200 computers in the domain with the "Active > > Directory" and one > > > wireless "captive portal" with 1000 + proxy users . > > > > > > I would like to see if the following scenario is > possible : > > > 1 - Integrating Samba4 with "Active Directory" , to use > > their GPO and > > > authenticate network users through the FreeIPA . > > > 2 - Authenticate proxy servers in FreeIPA . > > > 3 - And if it is possible some integration with FreeRADIUS > > > > > > > > > Hi Christovam, it is a bit unclear what you mean by > > integrating here. > > > > Is your intent to use Samba4 as an AD domain controller for > > your Windows > > client s and IPA for your servers ? > > > > If that's the case unfortunately this is not possible at the > > moment as > > samba4 does not yet support Forest level trusts. > > A Microsoft AD server can be used this way instead. > > > > Simo. > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > > > > > > > > -- > Simo Sorce * Red Hat, Inc * New York > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From deanhunter at comcast.net Wed Sep 11 21:32:46 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Wed, 11 Sep 2013 16:32:46 -0500 Subject: [Freeipa-users] freeipa and sudo In-Reply-To: <5230362F.4060704@redhat.com> References: <1378573597.16595.5.camel@host.hunter.org> <20130907181129.GA23695@fluxcoil.net> <522BB839.7030203@redhat.com> <522D9397.20504@redhat.com> <1378747930.23322.16.camel@host.hunter.org> <5230362F.4060704@redhat.com> Message-ID: <1378935166.23036.18.camel@host.hunter.org> On Wed, 2013-09-11 at 11:21 +0200, Pavel B?ezina wrote: > On 09/09/2013 07:32 PM, Dean Hunter wrote: > > > > On Mon, 2013-09-09 at 11:23 +0200, Pavel B?ezina wrote: > >> On 09/08/2013 01:35 AM, Dmitri Pal wrote: > >>> On 09/07/2013 02:11 PM, Christian Horn wrote: > >>>> On Sat, Sep 07, 2013 at 12:06:37PM -0500, Dean Hunter wrote: > >>>>> Are [1] and[2] still the current and best sources of > >>>>> information for configuring sudo for use with the current > >>>>> release of FreeIPA on Fedora 19? > >>>>> > >>>>> 1. > >>>>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/sudo.html > >> > >>>>> > >>> 2. > >>>>> http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > >> > >>>>> > >> There is also the Identity_Management_Guide as part of the RHEL > >>>> product documentation: > >>>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html > >> > >>>> > > This and the pdf above are the latest word in this area. > >> > >> Hi, those documents describes configuration for SSSD 1.9. Although > >> it is still valid, we have simplified configuration for IPA > >> provider in 1.10. > >> > >> The most up to date document for your version of SSSD is always > >> man sssd-sudo. > >> > >> _______________________________________________ Freeipa-users > >> mailing list Freeipa-users at redhat.com > >> > >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > Thank you. Please verify that I have correctly understood your note. > > Your slides from 12-20-2012 applied to SSSD 1.9 and included a > > reference to the manual pages, which I now understand, as well as > > this example configuration: > > > > sudo_provider = ldap ldap_uri = ldap://ipa.example.com > > ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_sasl_mech = > > GSSAPI ldap_sasl_authid = host/hostname.example.com ldap_sasl_realm = > > EXAMPLE.COM krb5_server = ipa.example.com > > > > I have used this configuration with good results. However, reading > > "man sssd-sudo" from sssd-1.9.5-2.fc18.x86_64 I find this paragraph: > > > > When the SSSD is configured to use the IPA provider, the sudo > > provider is automatically enabled. The sudo search base is configured > > to use the compat tree (ou=sudoers,$DC). > > I forgot that the configuration was simplified also in 1.9. You can just > stick with contents of sssd-sudo. I.e. you only need to put sudo to > "services" (there's an RFE to do it automatically by ipa-client-install) > and "sudoers: files sss" to /etc/nsswitch.conf > > > May I suggest that you change "IPA provider" to "IPA as the ID > > provider"? There are a number of providers identified in sssd.conf > > and most of them are configured to use IPA. > > This is a valid point, thanks. > > > > > Testing shows that the only change now required to sssd.conf is the > > addition of sudo to the services list in the sssd section [sssd]: > > > > services = autofs, nss, pam, ssh, sudo > > > > Add to this the one line change in nsswitch.conf > > > > sudoers: files sss > > > > and I am done. > > Correct. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Nope, there is still one step remaining. nisdomainname must be configured: -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmarzantowicz at osdf.com.pl Wed Sep 11 22:33:19 2013 From: mmarzantowicz at osdf.com.pl (Mateusz Marzantowicz) Date: Thu, 12 Sep 2013 00:33:19 +0200 Subject: [Freeipa-users] FreeIPA on Fedora 20: Configuration of CA failed Message-ID: <5230EFAF.7090706@osdf.com.pl> I'm trying to install FreeIPA Server on Fedora 20 (with all updates installed) but it fails on ipa-server-install -N command. Error message: CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmppTdhYM' returned non-zero exit status 1 which pointed me to [1] and [2]. I've found bug 953488 [3] but recommended solution does not work for me. Is there any way I can install and configure FreeIPA server on Fedora 20? Here are some lines from /var/log/ipaserver-install.log: 2013-09-11T20:13:40Z DEBUG Starting external process 2013-09-11T20:13:40Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmppTdhYM 2013-09-11T20:13:40Z DEBUG Process finished, return code=1 2013-09-11T20:13:40Z DEBUG stdout=Loading deployment configuration from /tmp/tmppTdhYM. Installing CA into /var/lib/pki/pki-tomcat. Storing deployment configuration into /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. Installation failed. 2013-09-11T20:13:40Z DEBUG stderr=pkispawn : WARNING ....... Dangling symlink '/var/lib/pki/pki-tomcat/pki-tomcat'-->'/usr/sbin/tomcat-sysd' 2013-09-11T20:13:40Z CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmppTdhYM' returned non-zero exit status 1 2013-09-11T20:13:40Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 622, in run_script return_value = main_function() File "/usr/sbin/ipa-server-install", line 1022, in main dm_password, subject_base=options.subject) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 478, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 364, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 604, in __spawn_instance raise RuntimeError('Configuration of CA failed') 2013-09-11T20:13:40Z DEBUG The ipa-server-install command failed, exception: RuntimeError: Configuration of CA failed and few more lines from /var/log/pki/pki-ca-spawn.20130911221340.log: 2013-09-11 22:13:40 pkispawn : INFO ....... mkdir -p /var/lib/pki/pki-tomcat/work/Catalina/localhost/ca 2013-09-11 22:13:40 pkispawn : DEBUG ........... chmod 770 /var/lib/pki/pki-tomcat/work/Catalina/localhost/ca 2013-09-11 22:13:40 pkispawn : DEBUG ........... chown 995:994 /var/lib/pki/pki-tomcat/work/Catalina/localhost/ca 2013-09-11 22:13:40 pkispawn : INFO ....... ln -s /usr/share/tomcat/bin /var/lib/pki/pki-tomcat/bin 2013-09-11 22:13:40 pkispawn : DEBUG ........... chown -h 995:994 /var/lib/pki/pki-tomcat/bin 2013-09-11 22:13:40 pkispawn : WARNING ....... Dangling symlink '/var/lib/pki/pki-tomcat/pki-tomcat'-->'/usr/sbin/tomcat-sysd' 2013-09-11 22:13:40 pkispawn : DEBUG ....... Error Type: SystemExit 2013-09-11 22:13:40 pkispawn : DEBUG ....... Error Message: 1 2013-09-11 22:13:40 pkispawn : DEBUG ....... File "/usr/sbin/pkispawn", line 374, in main rv = instance.spawn() File "/usr/lib/python2.7/site-packages/pki/deployment/instance_layout.py", line 87, in spawn uid=0, gid=0) File "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py", line 1774, in create sys.exit(1) Mateusz Marzantowicz [1] https://www.redhat.com/archives/freeipa-users/2013-July/msg00247.html [2] https://www.redhat.com/archives/freeipa-users/2012-December/msg00010.html [3] https://bugzilla.redhat.com/show_bug.cgi?id=953488 From nkinder at redhat.com Wed Sep 11 23:54:05 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 11 Sep 2013 16:54:05 -0700 Subject: [Freeipa-users] FreeIPA on Fedora 20: Configuration of CA failed In-Reply-To: <5230EFAF.7090706@osdf.com.pl> References: <5230EFAF.7090706@osdf.com.pl> Message-ID: <5231029D.4000305@redhat.com> On 09/11/2013 03:33 PM, Mateusz Marzantowicz wrote: > I'm trying to install FreeIPA Server on Fedora 20 (with all updates > installed) but it fails on ipa-server-install -N command. > > Error message: > CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s > CA -f /tmp/tmppTdhYM' returned non-zero exit status 1 > > which pointed me to [1] and [2]. I've found bug 953488 [3] but > recommended solution does not work for me. > > Is there any way I can install and configure FreeIPA server on Fedora 20? I believe that this is all caused by a recent change to the way Tomcat startup works in F20, which breaks the Dogtag CA. We hope to have a new build of Dogtag soon that addresses this. Thanks, -NGK > > Here are some lines from /var/log/ipaserver-install.log: > > 2013-09-11T20:13:40Z DEBUG Starting external process > 2013-09-11T20:13:40Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmppTdhYM > 2013-09-11T20:13:40Z DEBUG Process finished, return code=1 > 2013-09-11T20:13:40Z DEBUG stdout=Loading deployment configuration from > /tmp/tmppTdhYM. > Installing CA into /var/lib/pki/pki-tomcat. > Storing deployment configuration into > /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. > Installation failed. > > > 2013-09-11T20:13:40Z DEBUG stderr=pkispawn : WARNING ....... > Dangling symlink > '/var/lib/pki/pki-tomcat/pki-tomcat'-->'/usr/sbin/tomcat-sysd' > > 2013-09-11T20:13:40Z CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmppTdhYM' returned non-zero exit status 1 > 2013-09-11T20:13:40Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 622, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-server-install", line 1022, in main > dm_password, subject_base=options.subject) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 478, in configure_instance > self.start_creation(runtime=210) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 364, in start_creation > method() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 604, in __spawn_instance > raise RuntimeError('Configuration of CA failed') > > 2013-09-11T20:13:40Z DEBUG The ipa-server-install command failed, > exception: RuntimeError: Configuration of CA failed > > > and few more lines from /var/log/pki/pki-ca-spawn.20130911221340.log: > > 2013-09-11 22:13:40 pkispawn : INFO ....... mkdir -p > /var/lib/pki/pki-tomcat/work/Catalina/localhost/ca > 2013-09-11 22:13:40 pkispawn : DEBUG ........... chmod 770 > /var/lib/pki/pki-tomcat/work/Catalina/localhost/ca > 2013-09-11 22:13:40 pkispawn : DEBUG ........... chown 995:994 > /var/lib/pki/pki-tomcat/work/Catalina/localhost/ca > 2013-09-11 22:13:40 pkispawn : INFO ....... ln -s > /usr/share/tomcat/bin /var/lib/pki/pki-tomcat/bin > 2013-09-11 22:13:40 pkispawn : DEBUG ........... chown -h 995:994 > /var/lib/pki/pki-tomcat/bin > 2013-09-11 22:13:40 pkispawn : WARNING ....... Dangling symlink > '/var/lib/pki/pki-tomcat/pki-tomcat'-->'/usr/sbin/tomcat-sysd' > 2013-09-11 22:13:40 pkispawn : DEBUG ....... Error Type: SystemExit > 2013-09-11 22:13:40 pkispawn : DEBUG ....... Error Message: 1 > 2013-09-11 22:13:40 pkispawn : DEBUG ....... File > "/usr/sbin/pkispawn", line 374, in main > rv = instance.spawn() > File > "/usr/lib/python2.7/site-packages/pki/deployment/instance_layout.py", > line 87, in spawn > uid=0, gid=0) > File "/usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py", > line 1774, in create > sys.exit(1) > > > Mateusz Marzantowicz > > > [1] https://www.redhat.com/archives/freeipa-users/2013-July/msg00247.html > [2] > https://www.redhat.com/archives/freeipa-users/2012-December/msg00010.html > [3] https://bugzilla.redhat.com/show_bug.cgi?id=953488 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From deanhunter at comcast.net Thu Sep 12 00:49:17 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Wed, 11 Sep 2013 19:49:17 -0500 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1378914568.2804.1606.camel@willson.li.ssimo.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> Message-ID: <1378946957.6584.2.camel@host.hunter.org> On Wed, 2013-09-11 at 11:49 -0400, Simo Sorce wrote: > On Wed, 2013-09-11 at 10:39 -0500, Dean Hunter wrote: > > On Wed, 2013-09-11 at 11:20 -0400, Simo Sorce wrote: > > > On Wed, 2013-09-11 at 08:39 -0500, Dean Hunter wrote: > > > > > > > I do NOT believe this: > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > > > Last login: Wed Sep 11 08:32:21 2013 from ipa2.hunter.org > > > > Could not chdir to home directory /home/net/dean: Permission > > > > denied > > > > -bash: /home/net/dean/.bash_profile: Permission denied > > > > > > > > -bash-4.2$ logout > > > > -bash: /home/net/dean/.bash_logout: Permission denied > > > > Connection to desktop2 closed. > > > > > > > > [dean at ipa2 ~]$ su - > > > > Password: > > > > > > > > [root at ipa2 ~]# ssh dean at desktop2 > > > > dean at desktop2's password: > > > > Last login: Wed Sep 11 08:34:29 2013 from ipa2.hunter.org > > > > > > > > [dean at desktop2 ~]$ logout > > > > Connection to desktop2 closed. > > > > > > > > [root at ipa2 ~]# logout > > > > > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > > > Last login: Wed Sep 11 08:35:16 2013 from ipa2.hunter.org > > > > > > > > [dean at desktop2 ~]$ > > > > > > > > > > Are you using a kerberized NFS mount ? > > > > > > I think what is happening is that when going via SSH rpc.gssd cannot > > > find your ticket, ssh may be doing something "wrong" in this case. > > > > > > Simo. > > > > > Yes, I am using Kerberos with NFS. > > > > Should I report this as a bug? > > > We need to decide what component is faulty. It may be possible we can > get it working somehow. > > When you ssh in what is the ccache ssh assign you ? > can you run klist and post the output (sanitize it if needed) ? > > Simo. > I hope this is what you requested: [dean at ipa2 ~]$ klist Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR Default principal: dean at HUNTER.ORG Valid starting Expires Service principal 09/11/13 19:43:28 09/12/13 19:43:28 krbtgt/HUNTER.ORG at HUNTER.ORG [dean at ipa2 ~]$ ssh dean at desktop2 Last login: Wed Sep 11 19:41:48 2013 from ipa2.hunter.org Could not chdir to home directory /home/net/dean: Permission denied -bash: /home/net/dean/.bash_profile: Permission denied -bash-4.2$ hostname desktop2.hunter.org -bash-4.2$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1387400001) -bash-4.2$ logout -bash: /home/net/dean/.bash_logout: Permission denied Connection to desktop2 closed. [dean at ipa2 ~]$ klist Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR Default principal: dean at HUNTER.ORG Valid starting Expires Service principal 09/11/13 19:43:28 09/12/13 19:43:28 krbtgt/HUNTER.ORG at HUNTER.ORG 09/11/13 19:44:43 09/12/13 19:43:28 host/desktop2.hunter.org at HUNTER.ORG [dean at ipa2 ~]$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Sep 12 01:10:59 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Sep 2013 21:10:59 -0400 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1378946957.6584.2.camel@host.hunter.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> <1378946957.6584.2.camel@host.hunter.org> Message-ID: <523114A3.3060307@redhat.com> On 09/11/2013 08:49 PM, Dean Hunter wrote: > On Wed, 2013-09-11 at 11:49 -0400, Simo Sorce wrote: >> On Wed, 2013-09-11 at 10:39 -0500, Dean Hunter wrote: >> > On Wed, 2013-09-11 at 11:20 -0400, Simo Sorce wrote: >> > > On Wed, 2013-09-11 at 08:39 -0500, Dean Hunter wrote: >> > > >> > > > I do NOT believe this: >> > > > [dean at ipa2 ~]$ ssh dean at desktop2 >> > > > Last login: Wed Sep 11 08:32:21 2013 from ipa2.hunter.org >> > > > Could not chdir to home directory /home/net/dean: Permission >> > > > denied >> > > > -bash: /home/net/dean/.bash_profile: Permission denied >> > > > >> > > > -bash-4.2$ logout >> > > > -bash: /home/net/dean/.bash_logout: Permission denied >> > > > Connection to desktop2 closed. >> > > > >> > > > [dean at ipa2 ~]$ su - >> > > > Password: >> > > > >> > > > [root at ipa2 ~]# ssh dean at desktop2 >> > > > dean at desktop2's password: >> > > > Last login: Wed Sep 11 08:34:29 2013 from ipa2.hunter.org >> > > > >> > > > [dean at desktop2 ~]$ logout >> > > > Connection to desktop2 closed. >> > > > >> > > > [root at ipa2 ~]# logout >> > > > >> > > > [dean at ipa2 ~]$ ssh dean at desktop2 >> > > > Last login: Wed Sep 11 08:35:16 2013 from ipa2.hunter.org >> > > > >> > > > [dean at desktop2 ~]$ >> > > > >> > > >> > > Are you using a kerberized NFS mount ? >> > > >> > > I think what is happening is that when going via SSH rpc.gssd cannot >> > > find your ticket, ssh may be doing something "wrong" in this case. >> > > >> > > Simo. >> > > >> > Yes, I am using Kerberos with NFS. >> > >> > Should I report this as a bug? >> > >> We need to decide what component is faulty. It may be possible we can >> get it working somehow. >> >> When you ssh in what is the ccache ssh assign you ? >> can you run klist and post the output (sanitize it if needed) ? >> >> Simo. >> > I hope this is what you requested: > > [dean at ipa2 ~]$ klist > Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR > Default principal: dean at HUNTER.ORG > > Valid starting Expires Service principal > 09/11/13 19:43:28 09/12/13 19:43:28 krbtgt/HUNTER.ORG at HUNTER.ORG > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > Last login: Wed Sep 11 19:41:48 2013 from ipa2.hunter.org > Could not chdir to home directory /home/net/dean: Permission denied > -bash: /home/net/dean/.bash_profile: Permission denied > > -bash-4.2$ hostname > desktop2.hunter.org > > -bash-4.2$ klist > klist: No credentials cache found (ticket cache > FILE:/tmp/krb5cc_1387400001) > > -bash-4.2$ logout > -bash: /home/net/dean/.bash_logout: Permission denied > Connection to desktop2 closed. > > [dean at ipa2 ~]$ klist > Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR > Default principal: dean at HUNTER.ORG > > Valid starting Expires Service principal > 09/11/13 19:43:28 09/12/13 19:43:28 krbtgt/HUNTER.ORG at HUNTER.ORG > > 09/11/13 19:44:43 09/12/13 19:43:28 > host/desktop2.hunter.org at HUNTER.ORG > > > [dean at ipa2 ~]$ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Do I get it right: you tried twice and the first time it did not work while the second it did? There might be a race condition mounting your home directory using your ticket. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From deanhunter at comcast.net Thu Sep 12 01:27:57 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Wed, 11 Sep 2013 20:27:57 -0500 Subject: [Freeipa-users] Permission Denied In-Reply-To: <523114A3.3060307@redhat.com> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> <1378946957.6584.2.camel@host.hunter.org> <523114A3.3060307@redhat.com> Message-ID: <1378949277.6584.12.camel@host.hunter.org> On Wed, 2013-09-11 at 21:10 -0400, Dmitri Pal wrote: > On 09/11/2013 08:49 PM, Dean Hunter wrote: > > > On Wed, 2013-09-11 at 11:49 -0400, Simo Sorce wrote: > > > > > On Wed, 2013-09-11 at 10:39 -0500, Dean Hunter wrote: > > > > On Wed, 2013-09-11 at 11:20 -0400, Simo Sorce wrote: > > > > > On Wed, 2013-09-11 at 08:39 -0500, Dean Hunter wrote: > > > > > > > > > > > I do NOT believe this: > > > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > > > > > Last login: Wed Sep 11 08:32:21 2013 from ipa2.hunter.org > > > > > > Could not chdir to home directory /home/net/dean: Permission > > > > > > denied > > > > > > -bash: /home/net/dean/.bash_profile: Permission denied > > > > > > > > > > > > -bash-4.2$ logout > > > > > > -bash: /home/net/dean/.bash_logout: Permission denied > > > > > > Connection to desktop2 closed. > > > > > > > > > > > > [dean at ipa2 ~]$ su - > > > > > > Password: > > > > > > > > > > > > [root at ipa2 ~]# ssh dean at desktop2 > > > > > > dean at desktop2's password: > > > > > > Last login: Wed Sep 11 08:34:29 2013 from ipa2.hunter.org > > > > > > > > > > > > [dean at desktop2 ~]$ logout > > > > > > Connection to desktop2 closed. > > > > > > > > > > > > [root at ipa2 ~]# logout > > > > > > > > > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > > > > > Last login: Wed Sep 11 08:35:16 2013 from ipa2.hunter.org > > > > > > > > > > > > [dean at desktop2 ~]$ > > > > > > > > > > > > > > > > Are you using a kerberized NFS mount ? > > > > > > > > > > I think what is happening is that when going via SSH rpc.gssd cannot > > > > > find your ticket, ssh may be doing something "wrong" in this case. > > > > > > > > > > Simo. > > > > > > > > > Yes, I am using Kerberos with NFS. > > > > > > > > Should I report this as a bug? > > > > > > > We need to decide what component is faulty. It may be possible we can > > > get it working somehow. > > > > > > When you ssh in what is the ccache ssh assign you ? > > > can you run klist and post the output (sanitize it if needed) ? > > > > > > Simo. > > > > > > > I hope this is what you requested: > > > > [dean at ipa2 ~]$ klist > > Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR > > Default principal: dean at HUNTER.ORG > > > > Valid starting Expires Service principal > > 09/11/13 19:43:28 09/12/13 19:43:28 > > krbtgt/HUNTER.ORG at HUNTER.ORG > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > Last login: Wed Sep 11 19:41:48 2013 from ipa2.hunter.org > > Could not chdir to home directory /home/net/dean: Permission > > denied > > -bash: /home/net/dean/.bash_profile: Permission denied > > > > -bash-4.2$ hostname > > desktop2.hunter.org > > > > -bash-4.2$ klist > > klist: No credentials cache found (ticket cache > > FILE:/tmp/krb5cc_1387400001) > > > > -bash-4.2$ logout > > -bash: /home/net/dean/.bash_logout: Permission denied > > Connection to desktop2 closed. > > > > [dean at ipa2 ~]$ klist > > Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR > > Default principal: dean at HUNTER.ORG > > > > Valid starting Expires Service principal > > 09/11/13 19:43:28 09/12/13 19:43:28 > > krbtgt/HUNTER.ORG at HUNTER.ORG > > 09/11/13 19:44:43 09/12/13 19:43:28 > > host/desktop2.hunter.org at HUNTER.ORG > > > > [dean at ipa2 ~]$ > > > > > > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Do I get it right: you tried twice and the first time it did not work > while the second it did? > There might be a race condition mounting your home directory using > your ticket. > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Starting clean after rebuilding ipa2 and desktop2 and a gdm login to ipa2 as dean, if I "ssh dean at desktop2" it will consistently fail as noted in my last note. However, if I: 1. su - 2. ssh dean at desktop2 3. logout of dean at desktop2 4. logout of root at ipa2 then "ssh dean at desktop2" succeeds! Does that answer your question? So I do not think there is a race. It is more like the super user session leaves something behind that was missing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Sep 12 01:34:17 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Sep 2013 21:34:17 -0400 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1378949277.6584.12.camel@host.hunter.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> <1378946957.6584.2.camel@host.hunter.org> <523114A3.3060307@redhat.com> <1378949277.6584.12.camel@host.hunter.org> Message-ID: <52311A19.1090203@redhat.com> On 09/11/2013 09:27 PM, Dean Hunter wrote: > On Wed, 2013-09-11 at 21:10 -0400, Dmitri Pal wrote: >> On 09/11/2013 08:49 PM, Dean Hunter wrote: >>> On Wed, 2013-09-11 at 11:49 -0400, Simo Sorce wrote: >>>> On Wed, 2013-09-11 at 10:39 -0500, Dean Hunter wrote: >>>> > On Wed, 2013-09-11 at 11:20 -0400, Simo Sorce wrote: >>>> > > On Wed, 2013-09-11 at 08:39 -0500, Dean Hunter wrote: >>>> > > >>>> > > > I do NOT believe this: >>>> > > > [dean at ipa2 ~]$ ssh dean at desktop2 >>>> > > > Last login: Wed Sep 11 08:32:21 2013 from ipa2.hunter.org >>>> > > > Could not chdir to home directory /home/net/dean: Permission >>>> > > > denied >>>> > > > -bash: /home/net/dean/.bash_profile: Permission denied >>>> > > > >>>> > > > -bash-4.2$ logout >>>> > > > -bash: /home/net/dean/.bash_logout: Permission denied >>>> > > > Connection to desktop2 closed. >>>> > > > >>>> > > > [dean at ipa2 ~]$ su - >>>> > > > Password: >>>> > > > >>>> > > > [root at ipa2 ~]# ssh dean at desktop2 >>>> > > > dean at desktop2's password: >>>> > > > Last login: Wed Sep 11 08:34:29 2013 from ipa2.hunter.org >>>> > > > >>>> > > > [dean at desktop2 ~]$ logout >>>> > > > Connection to desktop2 closed. >>>> > > > >>>> > > > [root at ipa2 ~]# logout >>>> > > > >>>> > > > [dean at ipa2 ~]$ ssh dean at desktop2 >>>> > > > Last login: Wed Sep 11 08:35:16 2013 from ipa2.hunter.org >>>> > > > >>>> > > > [dean at desktop2 ~]$ >>>> > > > >>>> > > >>>> > > Are you using a kerberized NFS mount ? >>>> > > >>>> > > I think what is happening is that when going via SSH rpc.gssd cannot >>>> > > find your ticket, ssh may be doing something "wrong" in this case. >>>> > > >>>> > > Simo. >>>> > > >>>> > Yes, I am using Kerberos with NFS. >>>> > >>>> > Should I report this as a bug? >>>> > >>>> We need to decide what component is faulty. It may be possible we can >>>> get it working somehow. >>>> >>>> When you ssh in what is the ccache ssh assign you ? >>>> can you run klist and post the output (sanitize it if needed) ? >>>> >>>> Simo. >>>> >>> I hope this is what you requested: >>> >>> [dean at ipa2 ~]$ klist >>> Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR >>> Default principal: dean at HUNTER.ORG >>> >>> Valid starting Expires Service principal >>> 09/11/13 19:43:28 09/12/13 19:43:28 >>> krbtgt/HUNTER.ORG at HUNTER.ORG >>> >>> [dean at ipa2 ~]$ ssh dean at desktop2 >>> >>> Last login: Wed Sep 11 19:41:48 2013 from ipa2.hunter.org >>> Could not chdir to home directory /home/net/dean: Permission denied >>> -bash: /home/net/dean/.bash_profile: Permission denied >>> >>> -bash-4.2$ hostname >>> desktop2.hunter.org >>> >>> -bash-4.2$ klist >>> klist: No credentials cache found (ticket cache >>> FILE:/tmp/krb5cc_1387400001) >>> >>> -bash-4.2$ logout >>> -bash: /home/net/dean/.bash_logout: Permission denied >>> Connection to desktop2 closed. >>> >>> [dean at ipa2 ~]$ klist >>> Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR >>> Default principal: dean at HUNTER.ORG >>> >>> Valid starting Expires Service principal >>> 09/11/13 19:43:28 09/12/13 19:43:28 >>> krbtgt/HUNTER.ORG at HUNTER.ORG >>> 09/11/13 19:44:43 09/12/13 19:43:28 >>> host/desktop2.hunter.org at HUNTER.ORG >>> >>> >>> [dean at ipa2 ~]$ >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> Do I get it right: you tried twice and the first time it did not work >> while the second it did? >> There might be a race condition mounting your home directory using >> your ticket. >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > Starting clean after rebuilding ipa2 and desktop2 and a gdm login to > ipa2 as dean, if I "ssh dean at desktop2 " it will > consistently fail as noted in my last note. However, if I: > > 1. su - > 2. ssh dean at desktop2 > 3. logout of dean at desktop2 > 4. logout of root at ipa2 > > then "ssh dean at desktop2" succeeds! > > Does that answer your question? So I do not think there is a race. > It is more like the super user session leaves something behind that > was missing? Does it succeed if after step 3 but before step 4 you do kdestoy? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From deanhunter at comcast.net Thu Sep 12 02:10:29 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Wed, 11 Sep 2013 21:10:29 -0500 Subject: [Freeipa-users] Permission Denied In-Reply-To: <52311A19.1090203@redhat.com> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> <1378946957.6584.2.camel@host.hunter.org> <523114A3.3060307@redhat.com> <1378949277.6584.12.camel@host.hunter.org> <52311A19.1090203@redhat.com> Message-ID: <1378951829.6584.18.camel@host.hunter.org> On Wed, 2013-09-11 at 21:34 -0400, Dmitri Pal wrote: > On 09/11/2013 09:27 PM, Dean Hunter wrote: > > > On Wed, 2013-09-11 at 21:10 -0400, Dmitri Pal wrote: > > > > > On 09/11/2013 08:49 PM, Dean Hunter wrote: > > > > > > > On Wed, 2013-09-11 at 11:49 -0400, Simo Sorce wrote: > > > > > > > > > On Wed, 2013-09-11 at 10:39 -0500, Dean Hunter wrote: > > > > > > On Wed, 2013-09-11 at 11:20 -0400, Simo Sorce wrote: > > > > > > > On Wed, 2013-09-11 at 08:39 -0500, Dean Hunter wrote: > > > > > > > > > > > > > > > I do NOT believe this: > > > > > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > > > > > > > Last login: Wed Sep 11 08:32:21 2013 from ipa2.hunter.org > > > > > > > > Could not chdir to home directory /home/net/dean: Permission > > > > > > > > denied > > > > > > > > -bash: /home/net/dean/.bash_profile: Permission denied > > > > > > > > > > > > > > > > -bash-4.2$ logout > > > > > > > > -bash: /home/net/dean/.bash_logout: Permission denied > > > > > > > > Connection to desktop2 closed. > > > > > > > > > > > > > > > > [dean at ipa2 ~]$ su - > > > > > > > > Password: > > > > > > > > > > > > > > > > [root at ipa2 ~]# ssh dean at desktop2 > > > > > > > > dean at desktop2's password: > > > > > > > > Last login: Wed Sep 11 08:34:29 2013 from ipa2.hunter.org > > > > > > > > > > > > > > > > [dean at desktop2 ~]$ logout > > > > > > > > Connection to desktop2 closed. > > > > > > > > > > > > > > > > [root at ipa2 ~]# logout > > > > > > > > > > > > > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > > > > > > > Last login: Wed Sep 11 08:35:16 2013 from ipa2.hunter.org > > > > > > > > > > > > > > > > [dean at desktop2 ~]$ > > > > > > > > > > > > > > > > > > > > > > Are you using a kerberized NFS mount ? > > > > > > > > > > > > > > I think what is happening is that when going via SSH rpc.gssd cannot > > > > > > > find your ticket, ssh may be doing something "wrong" in this case. > > > > > > > > > > > > > > Simo. > > > > > > > > > > > > > Yes, I am using Kerberos with NFS. > > > > > > > > > > > > Should I report this as a bug? > > > > > > > > > > > We need to decide what component is faulty. It may be possible we can > > > > > get it working somehow. > > > > > > > > > > When you ssh in what is the ccache ssh assign you ? > > > > > can you run klist and post the output (sanitize it if needed) ? > > > > > > > > > > Simo. > > > > > > > > > > > > > I hope this is what you requested: > > > > > > > > [dean at ipa2 ~]$ klist > > > > Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR > > > > Default principal: dean at HUNTER.ORG > > > > > > > > Valid starting Expires Service principal > > > > 09/11/13 19:43:28 09/12/13 19:43:28 > > > > krbtgt/HUNTER.ORG at HUNTER.ORG > > > > > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > > > Last login: Wed Sep 11 19:41:48 2013 from > > > > ipa2.hunter.org > > > > Could not chdir to home directory /home/net/dean: > > > > Permission denied > > > > -bash: /home/net/dean/.bash_profile: Permission denied > > > > > > > > -bash-4.2$ hostname > > > > desktop2.hunter.org > > > > > > > > -bash-4.2$ klist > > > > klist: No credentials cache found (ticket cache > > > > FILE:/tmp/krb5cc_1387400001) > > > > > > > > -bash-4.2$ logout > > > > -bash: /home/net/dean/.bash_logout: Permission denied > > > > Connection to desktop2 closed. > > > > > > > > [dean at ipa2 ~]$ klist > > > > Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR > > > > Default principal: dean at HUNTER.ORG > > > > > > > > Valid starting Expires Service principal > > > > 09/11/13 19:43:28 09/12/13 19:43:28 > > > > krbtgt/HUNTER.ORG at HUNTER.ORG > > > > 09/11/13 19:44:43 09/12/13 19:43:28 > > > > host/desktop2.hunter.org at HUNTER.ORG > > > > > > > > [dean at ipa2 ~]$ > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Freeipa-users mailing list > > > > Freeipa-users at redhat.com > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > Do I get it right: you tried twice and the first time it did not > > > work while the second it did? > > > There might be a race condition mounting your home directory using > > > your ticket. > > > > > > > > > -- > > > Thank you, > > > Dmitri Pal > > > > > > Sr. Engineering Manager for IdM portfolio > > > Red Hat Inc. > > > > > > > > > ------------------------------- > > > Looking to carve out IT costs? > > > www.redhat.com/carveoutcosts/ > > > > > > > > > _______________________________________________ > > > Freeipa-users mailing list > > > Freeipa-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > Starting clean after rebuilding ipa2 and desktop2 and a gdm login to > > ipa2 as dean, if I "ssh dean at desktop2" it will consistently fail as > > noted in my last note. However, if I: > > 1. su - > > 2. ssh dean at desktop2 > > 3. logout of dean at desktop2 > > 4. logout of root at ipa2 > > then "ssh dean at desktop2" succeeds! > > > > Does that answer your question? So I do not think there is a race. > > It is more like the super user session leaves something behind that > > was missing? > > > Does it succeed if after step 3 but before step 4 you do kdestoy? > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > Hah! Even better, it works the first time and every time, if I start with a kdestroy: 1. From Virtual Machine Manager open ipa2 2. Login as dean 3. Open a terminal 4. kdestroy 5. ssh dean at desktop2 6. logout 7. ssh dean at desktop2 8. logout Now, the fun starts. Why do it do that? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Sep 12 02:25:43 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Sep 2013 22:25:43 -0400 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1378951829.6584.18.camel@host.hunter.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> <1378946957.6584.2.camel@host.hunter.org> <523114A3.3060307@redhat.com> <1378949277.6584.12.camel@host.hunter.org> <52311A19.1090203@redhat.com> <1378951829.6584.18.camel@host.hunter.org> Message-ID: <52312627.90204@redhat.com> On 09/11/2013 10:10 PM, Dean Hunter wrote: > On Wed, 2013-09-11 at 21:34 -0400, Dmitri Pal wrote: >> On 09/11/2013 09:27 PM, Dean Hunter wrote: >>> On Wed, 2013-09-11 at 21:10 -0400, Dmitri Pal wrote: >>>> On 09/11/2013 08:49 PM, Dean Hunter wrote: >>>>> On Wed, 2013-09-11 at 11:49 -0400, Simo Sorce wrote: >>>>>> On Wed, 2013-09-11 at 10:39 -0500, Dean Hunter wrote: >>>>>> > On Wed, 2013-09-11 at 11:20 -0400, Simo Sorce wrote: >>>>>> > > On Wed, 2013-09-11 at 08:39 -0500, Dean Hunter wrote: >>>>>> > > >>>>>> > > > I do NOT believe this: >>>>>> > > > [dean at ipa2 ~]$ ssh dean at desktop2 >>>>>> > > > Last login: Wed Sep 11 08:32:21 2013 from ipa2.hunter.org >>>>>> > > > Could not chdir to home directory /home/net/dean: Permission >>>>>> > > > denied >>>>>> > > > -bash: /home/net/dean/.bash_profile: Permission denied >>>>>> > > > >>>>>> > > > -bash-4.2$ logout >>>>>> > > > -bash: /home/net/dean/.bash_logout: Permission denied >>>>>> > > > Connection to desktop2 closed. >>>>>> > > > >>>>>> > > > [dean at ipa2 ~]$ su - >>>>>> > > > Password: >>>>>> > > > >>>>>> > > > [root at ipa2 ~]# ssh dean at desktop2 >>>>>> > > > dean at desktop2's password: >>>>>> > > > Last login: Wed Sep 11 08:34:29 2013 from ipa2.hunter.org >>>>>> > > > >>>>>> > > > [dean at desktop2 ~]$ logout >>>>>> > > > Connection to desktop2 closed. >>>>>> > > > >>>>>> > > > [root at ipa2 ~]# logout >>>>>> > > > >>>>>> > > > [dean at ipa2 ~]$ ssh dean at desktop2 >>>>>> > > > Last login: Wed Sep 11 08:35:16 2013 from ipa2.hunter.org >>>>>> > > > >>>>>> > > > [dean at desktop2 ~]$ >>>>>> > > > >>>>>> > > >>>>>> > > Are you using a kerberized NFS mount ? >>>>>> > > >>>>>> > > I think what is happening is that when going via SSH rpc.gssd cannot >>>>>> > > find your ticket, ssh may be doing something "wrong" in this case. >>>>>> > > >>>>>> > > Simo. >>>>>> > > >>>>>> > Yes, I am using Kerberos with NFS. >>>>>> > >>>>>> > Should I report this as a bug? >>>>>> > >>>>>> We need to decide what component is faulty. It may be possible we can >>>>>> get it working somehow. >>>>>> >>>>>> When you ssh in what is the ccache ssh assign you ? >>>>>> can you run klist and post the output (sanitize it if needed) ? >>>>>> >>>>>> Simo. >>>>>> >>>>> I hope this is what you requested: >>>>> >>>>> [dean at ipa2 ~]$ klist >>>>> Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR >>>>> Default principal: dean at HUNTER.ORG >>>>> >>>>> Valid starting Expires Service principal >>>>> 09/11/13 19:43:28 09/12/13 19:43:28 >>>>> krbtgt/HUNTER.ORG at HUNTER.ORG >>>>> >>>>> [dean at ipa2 ~]$ ssh dean at desktop2 >>>>> >>>>> Last login: Wed Sep 11 19:41:48 2013 from ipa2.hunter.org >>>>> Could not chdir to home directory /home/net/dean: Permission >>>>> denied >>>>> -bash: /home/net/dean/.bash_profile: Permission denied >>>>> >>>>> -bash-4.2$ hostname >>>>> desktop2.hunter.org >>>>> >>>>> -bash-4.2$ klist >>>>> klist: No credentials cache found (ticket cache >>>>> FILE:/tmp/krb5cc_1387400001) >>>>> >>>>> -bash-4.2$ logout >>>>> -bash: /home/net/dean/.bash_logout: Permission denied >>>>> Connection to desktop2 closed. >>>>> >>>>> [dean at ipa2 ~]$ klist >>>>> Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR >>>>> Default principal: dean at HUNTER.ORG >>>>> >>>>> Valid starting Expires Service principal >>>>> 09/11/13 19:43:28 09/12/13 19:43:28 >>>>> krbtgt/HUNTER.ORG at HUNTER.ORG >>>>> 09/11/13 19:44:43 09/12/13 19:43:28 >>>>> host/desktop2.hunter.org at HUNTER.ORG >>>>> >>>>> >>>>> [dean at ipa2 ~]$ >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Do I get it right: you tried twice and the first time it did not >>>> work while the second it did? >>>> There might be a race condition mounting your home directory using >>>> your ticket. >>>> >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager for IdM portfolio >>>> Red Hat Inc. >>>> >>>> >>>> ------------------------------- >>>> Looking to carve out IT costs? >>>> www.redhat.com/carveoutcosts/ >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> Starting clean after rebuilding ipa2 and desktop2 and a gdm login to >>> ipa2 as dean, if I "ssh dean at desktop2 " it >>> will consistently fail as noted in my last note. However, if I: >>> >>> 1. su - >>> 2. ssh dean at desktop2 >>> 3. logout of dean at desktop2 >>> 4. logout of root at ipa2 >>> >>> then "ssh dean at desktop2" succeeds! >>> >>> Does that answer your question? So I do not think there is a race. >>> It is more like the super user session leaves something behind that >>> was missing? >> >> Does it succeed if after step 3 but before step 4 you do kdestoy? >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> > > Hah! Even better, it works the first time and every time, if I start > with a kdestroy: > > 1. From Virtual Machine Manager open ipa2 > 2. Login as dean > 3. Open a terminal > 4. kdestroy > 5. ssh dean at desktop2 > 6. logout > 7. ssh dean at desktop2 > 8. logout > > Now, the fun starts. Why do it do that? > > Now you need to see what you have before kdestroy. Klist will help to see what cache is in play. Then you need to see whether you as dean can access this cache (check permissions and SELinux). Based on the input you provided earlier the cache might be in FILE:/tmp/krb5cc_1387400001 While after you login it is in DIR::/run/user/1387400001/krb5cc/tktFDDxRR The latter is the right one. All applications in Fedora starting F18 should use DIR cache. It seems that on this machine there is some other kerberized software (NFS client?) that is not configured or updated to create DIR cache style cache and continues to use FILE style cache. There have been a slew of bugs around this. It seems you are hitting one of those. Just FYI to avoid this confusion and to fight some race conditions related to creation of the /run/user/uid directory the cache is now moved to kernel and we are in process of updating different components to use it. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From KevinTang at umac.mo Thu Sep 12 07:16:10 2013 From: KevinTang at umac.mo (KevinTang at umac.mo) Date: Thu, 12 Sep 2013 15:16:10 +0800 Subject: [Freeipa-users] [How to] Set UID, GID, HomeDir in Trust AD user Message-ID: Dear all, I have two domain, one is Windows AD domain, another is IPA domain. Both two domain already have two-ways trust, and Windows AD user can logon under IPA Client PC successfully. Since user account in Windows AD can logon IPA Client PC, May I set UID, GID, HomeDir for the user from Windows AD? If so, how should I do? Any tutorial on web? Thanks Kevin Tang -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Sep 12 07:29:31 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Sep 2013 09:29:31 +0200 Subject: [Freeipa-users] [How to] Set UID, GID, HomeDir in Trust AD user In-Reply-To: References: Message-ID: <52316D5B.8020007@redhat.com> On 09/12/2013 09:16 AM, KevinTang at umac.mo wrote: > Dear all, > > I have two domain, one is Windows AD domain, another is IPA domain. Both > two domain already have two-ways trust, and Windows AD user can logon > under IPA Client PC successfully. > > Since user account in Windows AD can logon IPA Client PC, May I set UID, > GID, HomeDir for the user from Windows AD? If so, how should I do? Any > tutorial on web? > > Thanks > Kevin Tang > With a plain Active Directory and users signing from AD to FreeIPA Linux client, AD user will get automatically assigned UID and GID based on their Windows identification (SID). This should work fine. However, I think you cannot set custom home dir centrally, unless you configure "Services for Identity Management for UNIX" AD extension and FreeIPA to use it: Design page of the feature: http://www.freeipa.org/page/V3/Use_posix_attributes_defined_in_AD Test day page (a.k.a. tutorials): https://fedoraproject.org/wiki/Test_Day:2013-07-25_AD_trusts_with_POSIX_attributes_in_AD_and_support_for_old_clients ... and particularly this part: https://fedoraproject.org/wiki/QA:Testcase_freeipa_using_posix_attributes_in_ad If you do not want to use the extension, you could for example override the default home dir on FreeIPA clients e.g. with subdomain_homedir option of sssd.conf (man sssd.conf). HTH, Martin From KevinTang at umac.mo Thu Sep 12 07:32:53 2013 From: KevinTang at umac.mo (KevinTang at umac.mo) Date: Thu, 12 Sep 2013 15:32:53 +0800 Subject: [Freeipa-users] [How to] Set UID, GID, HomeDir in Trust AD user In-Reply-To: <52316D5B.8020007@redhat.com> References: <52316D5B.8020007@redhat.com> Message-ID: Dear Martin, Thank you very much Kevin From: Martin Kosek To: KevinTang at umac.mo Cc: freeipa-users at redhat.com Date: 09/12/2013 03:29 PM Subject: Re: [Freeipa-users] [How to] Set UID, GID, HomeDir in Trust AD user On 09/12/2013 09:16 AM, KevinTang at umac.mo wrote: > Dear all, > > I have two domain, one is Windows AD domain, another is IPA domain. Both > two domain already have two-ways trust, and Windows AD user can logon > under IPA Client PC successfully. > > Since user account in Windows AD can logon IPA Client PC, May I set UID, > GID, HomeDir for the user from Windows AD? If so, how should I do? Any > tutorial on web? > > Thanks > Kevin Tang > With a plain Active Directory and users signing from AD to FreeIPA Linux client, AD user will get automatically assigned UID and GID based on their Windows identification (SID). This should work fine. However, I think you cannot set custom home dir centrally, unless you configure "Services for Identity Management for UNIX" AD extension and FreeIPA to use it: Design page of the feature: http://www.freeipa.org/page/V3/Use_posix_attributes_defined_in_AD Test day page (a.k.a. tutorials): https://fedoraproject.org/wiki/Test_Day:2013-07-25_AD_trusts_with_POSIX_attributes_in_AD_and_support_for_old_clients ... and particularly this part: https://fedoraproject.org/wiki/QA:Testcase_freeipa_using_posix_attributes_in_ad If you do not want to use the extension, you could for example override the default home dir on FreeIPA clients e.g. with subdomain_homedir option of sssd.conf (man sssd.conf). HTH, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.raehalme at codecenter.fi Thu Sep 12 11:46:07 2013 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Thu, 12 Sep 2013 14:46:07 +0300 Subject: [Freeipa-users] Using FreeIPA for LDAP authentication in 3rd party applications Message-ID: Hi, Previously we have used Atlassian Crowd as a source for user data in various applications, both in-house built and proprietary such as JIRA or Confluence. As we have deployed FreeIPA, I would like to start using it as the identity source. Unfortunately using Kerberos is not always possible so I am thinking about LDAP which often is an option in 3rd party applicaitons. Anonymous access to the FreeIPA LDAP is enabled by default. Is it possible to configure username/password to access the information? Currently vSphere has a problem with anonymous access to LDAP not working as intended. Ofcourse it would be nice to be able to restrict access anyways. If using FreeIPA LDAP as the identity source, how should authentication be handled? Is it possible to read the hash code for passwords? Is it possible to authenticate against the LDAP service? Any advice appreciated! Best regards, Thomas -- Thomas Raehalme CTO, teknologiajohtaja Mobile +358 40 545 0605 Codecenter Oy V?in?nkatu 26 A, 4th Floor 40100 JYV?SKYL?, Finland Tel. +358 10 322 0040 www.codecenter.fi Codecenter - Tietoj?rjestelmi? ymm?rrett?v?sti From thomas.raehalme at codecenter.fi Thu Sep 12 11:54:10 2013 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Thu, 12 Sep 2013 14:54:10 +0300 Subject: [Freeipa-users] Using subdomains (or dots) in hostnames Message-ID: Hi! >> Let's say we're using domain example.com. Adding clients a.example.com >> and b.example.com was smooth. Adding client a.sub1.example.com also >> had no problems until I tried to get sudoers from the IPA server >> (using SSSD and LDAP as suggested). The client fails to find any users >> matching the server name. Because the only difference compared to a >> fully functional server is the dot in the host name, that's probably >> the reason why no sudoers are found for the server in the subdomain? > >What do you use in nsswitch.conf for sudoers? ldap or sss? If sss, can >you also paste your sssd.conf? >Can you paste the output of sudo along with the -D parameter to get some >debugging? I managed to get subdomains working after adding the subdomain to the IPA DNS and filling in the various SRV records pointing to the IPA master. After the DNS was setup properly, DNS discovery would display the correct subdomain on ipa-client-install. After the DNS discovery was successful, also sudo started working properly on most servers. As I specified sss for sudoers in nsswitch.conf and added the necessary configuration to sssd.conf as described in the RedHat documentation, I was able to sudo the commands I had enabled in the IPA policy. That's great! Some servers are still, however, causing headache. According to /var/log/secure sudo can authenticate me, but for some reason the list of allowed commands is empty (sudo -l responds "Sorry, user xxx may not run sudo on yyy."). I have defined sudo rules so that anybody can use sudo on any host, but only certain commands. I'll try to debug the problems and let you know how it goes. The caching mechanism for sudo/sssd and especially clearing the cache with sss_cache has turned out to be somewhat challenging to understand. Does anybody know the correct parameters that cause the sudoers cache be invalidated? Thanks also to everybody else for replying to my message! Best regards, Thomas -- Thomas Raehalme CTO, teknologiajohtaja Mobile +358 40 545 0605 Codecenter Oy V?in?nkatu 26 A, 4th Floor 40100 JYV?SKYL?, Finland Tel. +358 10 322 0040 www.codecenter.fi Codecenter - Tietoj?rjestelmi? ymm?rrett?v?sti From mkosek at redhat.com Thu Sep 12 12:28:45 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Sep 2013 14:28:45 +0200 Subject: [Freeipa-users] Using FreeIPA for LDAP authentication in 3rd party applications In-Reply-To: References: Message-ID: <5231B37D.2010705@redhat.com> On 09/12/2013 01:46 PM, Thomas Raehalme wrote: > Hi, > > Previously we have used Atlassian Crowd as a source for user data in > various applications, both in-house built and proprietary such as JIRA > or Confluence. As we have deployed FreeIPA, I would like to start > using it as the identity source. Unfortunately using Kerberos is not > always possible so I am thinking about LDAP which often is an option > in 3rd party applicaitons. > > Anonymous access to the FreeIPA LDAP is enabled by default. Is it > possible to configure username/password to access the information? > Currently vSphere has a problem with anonymous access to LDAP not > working as intended. Ofcourse it would be nice to be able to restrict > access anyways. > > If using FreeIPA LDAP as the identity source, how should > authentication be handled? Is it possible to read the hash code for > passwords? Is it possible to authenticate against the LDAP service? > > Any advice appreciated! > > Best regards, > Thomas > When using FreeIPA LDAP as identity source, you could ideally use Kerberos/GSSAPI authentication. But if that is not available, you can use simple LDAP binds too. You cannot read the hash codes unless you are "cn=Directory Manager" (or unless you set ACI allowing that, but this is very unsecure). If you do not want to access the LDAP anonymously and you do not want to use a full IPA user for that (added via "ipa user-add"), you can manually add a system user and use that for binding to LDAP: # ldapadd -h `hostname` -D "cn=Directory Manager" -x -w kokos123 dn: uid=vsphere,cn=sysaccounts,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com objectClass: account objectClass: simplesecurityobject objectClass: top uid: vsphere userPassword: SuperSecretPassword adding new entry "uid=vsphere,cn=sysaccounts,cn=etc,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" HTH, Martin From thomas.raehalme at codecenter.fi Thu Sep 12 12:54:59 2013 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Thu, 12 Sep 2013 15:54:59 +0300 Subject: [Freeipa-users] Using FreeIPA for LDAP authentication in 3rd party applications In-Reply-To: <5231B37D.2010705@redhat.com> References: <5231B37D.2010705@redhat.com> Message-ID: Hi! On Thu, Sep 12, 2013 at 3:28 PM, Martin Kosek wrote: > When using FreeIPA LDAP as identity source, you could ideally use > Kerberos/GSSAPI authentication. But if that is not available, you can use > simple LDAP binds too. You cannot read the hash codes unless you are > "cn=Directory Manager" (or unless you set ACI allowing that, but this is very > unsecure). Could you please elaborate on using simple LDAP binds? Thanks for the detailed example! Best regards, Thomas -- Thomas Raehalme CTO, teknologiajohtaja Mobile +358 40 545 0605 Codecenter Oy V?in?nkatu 26 A, 4th Floor 40100 JYV?SKYL?, Finland Tel. +358 10 322 0040 www.codecenter.fi Codecenter - Tietoj?rjestelmi? ymm?rrett?v?sti From mkosek at redhat.com Thu Sep 12 13:06:26 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Sep 2013 15:06:26 +0200 Subject: [Freeipa-users] Using FreeIPA for LDAP authentication in 3rd party applications In-Reply-To: References: <5231B37D.2010705@redhat.com> Message-ID: <5231BC52.40401@redhat.com> On 09/12/2013 02:54 PM, Thomas Raehalme wrote: > Hi! > > On Thu, Sep 12, 2013 at 3:28 PM, Martin Kosek wrote: > >> When using FreeIPA LDAP as identity source, you could ideally use >> Kerberos/GSSAPI authentication. But if that is not available, you can use >> simple LDAP binds too. You cannot read the hash codes unless you are >> "cn=Directory Manager" (or unless you set ACI allowing that, but this is very >> unsecure). > > Could you please elaborate on using simple LDAP binds? I was just referring to fact, that when a system or application uses LDAP as an identity and authentication source, it often use simple LDAP Bind operation (i.e. accessing LDAP with user+password or) when testing if the user accessing the application provided the right credentials. I am no expert on how you configure that with vSphere or similar, but if it supports general LDAP as an identity/authentication source, it should also work with FreeIPA. I found some doc where may be relevant: http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.security.doc%2FGUID-B23B1360-8838-4FF2-B074-71643C4CB040.html Maybe other users are capable of giving more detailed answer with respect to vSphere. Martin From simo at redhat.com Thu Sep 12 13:09:06 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Sep 2013 09:09:06 -0400 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1378946957.6584.2.camel@host.hunter.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> <1378946957.6584.2.camel@host.hunter.org> Message-ID: <1378991346.2804.1890.camel@willson.li.ssimo.org> On Wed, 2013-09-11 at 19:49 -0500, Dean Hunter wrote: > On Wed, 2013-09-11 at 11:49 -0400, Simo Sorce wrote: > > On Wed, 2013-09-11 at 10:39 -0500, Dean Hunter wrote: > > > On Wed, 2013-09-11 at 11:20 -0400, Simo Sorce wrote: > > > > On Wed, 2013-09-11 at 08:39 -0500, Dean Hunter wrote: > > > > > > > > > I do NOT believe this: > > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > > > > Last login: Wed Sep 11 08:32:21 2013 from ipa2.hunter.org > > > > > Could not chdir to home directory /home/net/dean: Permission > > > > > denied > > > > > -bash: /home/net/dean/.bash_profile: Permission denied > > > > > > > > > > -bash-4.2$ logout > > > > > -bash: /home/net/dean/.bash_logout: Permission denied > > > > > Connection to desktop2 closed. > > > > > > > > > > [dean at ipa2 ~]$ su - > > > > > Password: > > > > > > > > > > [root at ipa2 ~]# ssh dean at desktop2 > > > > > dean at desktop2's password: > > > > > Last login: Wed Sep 11 08:34:29 2013 from ipa2.hunter.org > > > > > > > > > > [dean at desktop2 ~]$ logout > > > > > Connection to desktop2 closed. > > > > > > > > > > [root at ipa2 ~]# logout > > > > > > > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > > > > Last login: Wed Sep 11 08:35:16 2013 from ipa2.hunter.org > > > > > > > > > > [dean at desktop2 ~]$ > > > > > > > > > > > > > Are you using a kerberized NFS mount ? > > > > > > > > I think what is happening is that when going via SSH rpc.gssd cannot > > > > find your ticket, ssh may be doing something "wrong" in this case. > > > > > > > > Simo. > > > > > > > Yes, I am using Kerberos with NFS. > > > > > > Should I report this as a bug? > > > > > We need to decide what component is faulty. It may be possible we can > > get it working somehow. > > > > When you ssh in what is the ccache ssh assign you ? > > can you run klist and post the output (sanitize it if needed) ? > > > > Simo. > > > I hope this is what you requested: Yes it is, but I need to see also what you get on the successfull ssh case, klist is all I need to see, no other output. Also does it work all the time if you use the command ssh -K dean at desktop2 ? > [dean at ipa2 ~]$ klist > Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR > Default principal: dean at HUNTER.ORG > > Valid starting Expires Service principal > 09/11/13 19:43:28 09/12/13 19:43:28 > krbtgt/HUNTER.ORG at HUNTER.ORG > > [dean at ipa2 ~]$ ssh dean at desktop2 > Last login: Wed Sep 11 19:41:48 2013 from ipa2.hunter.org > Could not chdir to home directory /home/net/dean: Permission > denied > -bash: /home/net/dean/.bash_profile: Permission denied > > -bash-4.2$ hostname > desktop2.hunter.org > > -bash-4.2$ klist > klist: No credentials cache found (ticket cache > FILE:/tmp/krb5cc_1387400001) > > -bash-4.2$ logout > -bash: /home/net/dean/.bash_logout: Permission denied > Connection to desktop2 closed. > > [dean at ipa2 ~]$ klist > Ticket cache: DIR::/run/user/1387400001/krb5cc/tktFDDxRR > Default principal: dean at HUNTER.ORG > > Valid starting Expires Service principal > 09/11/13 19:43:28 09/12/13 19:43:28 > krbtgt/HUNTER.ORG at HUNTER.ORG > 09/11/13 19:44:43 09/12/13 19:43:28 > host/desktop2.hunter.org at HUNTER.ORG > > [dean at ipa2 ~]$ > -- Simo Sorce * Red Hat, Inc * New York From thomas.raehalme at codecenter.fi Thu Sep 12 13:18:49 2013 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Thu, 12 Sep 2013 16:18:49 +0300 Subject: [Freeipa-users] Using FreeIPA for LDAP authentication in 3rd party applications In-Reply-To: <5231BC52.40401@redhat.com> References: <5231B37D.2010705@redhat.com> <5231BC52.40401@redhat.com> Message-ID: Hi! On Thu, Sep 12, 2013 at 4:06 PM, Martin Kosek wrote: > I was just referring to fact, that when a system or application uses LDAP as an > identity and authentication source, it often use simple LDAP Bind operation > (i.e. accessing LDAP with user+password or) when testing if the user accessing > the application provided the right credentials. Yes, that's true at least for some applications. Does the LDAP in FreeIPA allow that kind of login by default for IPA users? If not, is it possible to enable it somehow? Best regards, Thomas Raehalme -- Thomas Raehalme CTO, teknologiajohtaja Mobile +358 40 545 0605 Codecenter Oy V?in?nkatu 26 A, 4th Floor 40100 JYV?SKYL?, Finland Tel. +358 10 322 0040 www.codecenter.fi Codecenter - Tietoj?rjestelmi? ymm?rrett?v?sti From mkosek at redhat.com Thu Sep 12 13:33:35 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Sep 2013 15:33:35 +0200 Subject: [Freeipa-users] Using FreeIPA for LDAP authentication in 3rd party applications In-Reply-To: References: <5231B37D.2010705@redhat.com> <5231BC52.40401@redhat.com> Message-ID: <5231C2AF.7040003@redhat.com> On 09/12/2013 03:18 PM, Thomas Raehalme wrote: > Hi! > > On Thu, Sep 12, 2013 at 4:06 PM, Martin Kosek wrote: >> I was just referring to fact, that when a system or application uses LDAP as an >> identity and authentication source, it often use simple LDAP Bind operation >> (i.e. accessing LDAP with user+password or) when testing if the user accessing >> the application provided the right credentials. > > Yes, that's true at least for some applications. Does the LDAP in > FreeIPA allow that kind of login by default for IPA users? If not, is > it possible to enable it somehow? > > Best regards, > Thomas Raehalme Well, LDAP is the data backend for all FreeIPA identity data, you can certainly use plain LDAP binds with them (though Kerberos/GSSAPI auth is preferred). See an example when I add a new IPA user and do LDAP bind with his credentials: # ipa user-add --first=John --last=Doe jdoe --random ----------------- Added user "jdoe" ----------------- User login: jdoe First name: John Last name: Doe Full name: John Doe Display name: John Doe Initials: JD Home directory: /home/jdoe GECOS: John Doe Login shell: /bin/sh Kerberos principal: jdoe at EXAMPLE.COM Email address: jdoe at example.com Random password: xO3xs5yOv,dL UID: 470000066 GID: 470000066 Password: True Member of groups: ipausers Kerberos keys available: True # ldapsearch -h `hostname` -D "uid=jdoe,cn=users,cn=accounts,dc=example,dc=com" -x -w xO3xs5yOv,dL -b "" -s base # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: ALL # # dn: objectClass: top ... Martin From sergey57 at gmail.com Thu Sep 12 15:23:04 2013 From: sergey57 at gmail.com (sergey ivanov) Date: Thu, 12 Sep 2013 11:23:04 -0400 Subject: [Freeipa-users] Is kerberos DB import to IPA possible? Message-ID: Hi, I am looking for deployment of freeIPA in our organization. We have kerberos servers used for authentication on our computers and in applications, while users are mostly defined in /etc/passwd. For migration of user's password I have tried the way we usually do replicating password changes from master kerberos server to slaves. I did kdb5_util dump on old servers, transferred the dump to machine running FreeIPA, and was not able to do kdb5_util load -update, because of "Kerberos database constraints violated". Is there a way to import into freeIPA kerberos servers dump of kerberos principals, dumped by kdb5_util? -- Regards, Sergey Ivanov | sergey57 at gmail.com http://www.linkedin.com/pub/sergey-ivanov/8/270/a09 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Sep 12 16:07:33 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 12 Sep 2013 18:07:33 +0200 Subject: [Freeipa-users] Using FreeIPA for LDAP authentication in 3rd party applications In-Reply-To: <5231B37D.2010705@redhat.com> References: <5231B37D.2010705@redhat.com> Message-ID: <20130912160733.GS9504@hendrix.brq.redhat.com> On Thu, Sep 12, 2013 at 02:28:45PM +0200, Martin Kosek wrote: > # ldapadd -h `hostname` -D "cn=Directory Manager" -x -w kokos123 ^^^^^^^^^^ 0wn3d :-) From deanhunter at comcast.net Thu Sep 12 16:27:40 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Thu, 12 Sep 2013 11:27:40 -0500 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1378991346.2804.1890.camel@willson.li.ssimo.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> <1378946957.6584.2.camel@host.hunter.org> <1378991346.2804.1890.camel@willson.li.ssimo.org> Message-ID: <1379003260.20745.4.camel@host.hunter.org> On Thu, 2013-09-12 at 09:09 -0400, Simo Sorce wrote: > Yes it is, but I need to see also what you get on the successfull ssh > case, klist is all I need to see, no other output. > > Also does it work all the time if you use the command > > ssh -K dean at desktop2 ? [dean at ipa2 ~]$ klist Ticket cache: DIR::/run/user/1440800001/krb5cc/tktH9faWP Default principal: dean at HUNTER.ORG Valid starting Expires Service principal 09/12/13 11:14:40 09/13/13 11:14:40 krbtgt/HUNTER.ORG at HUNTER.ORG [dean at ipa2 ~]$ ssh dean at desktop2 Last login: Wed Sep 11 21:14:18 2013 from ipa2.hunter.org Could not chdir to home directory /home/net/dean: Permission denied -bash: /home/net/dean/.bash_profile: Permission denied -bash-4.2$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1440800001) -bash-4.2$ logout -bash: /home/net/dean/.bash_logout: Permission denied Connection to desktop2 closed. [dean at ipa2 ~]$ klist Ticket cache: DIR::/run/user/1440800001/krb5cc/tktH9faWP Default principal: dean at HUNTER.ORG Valid starting Expires Service principal 09/12/13 11:14:40 09/13/13 11:14:40 krbtgt/HUNTER.ORG at HUNTER.ORG 09/12/13 11:15:29 09/13/13 11:14:40 host/desktop2.hunter.org at HUNTER.ORG [dean at ipa2 ~]$ su - Password: [root at ipa2 ~]# klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0) [root at ipa2 ~]# ssh dean at desktop2 dean at desktop2's password: Last login: Thu Sep 12 11:16:15 2013 from ipa2.hunter.org [dean at desktop2 ~]$ klist Ticket cache: DIR::/run/user/1440800001/krb5cc/tktrhI7WX Default principal: dean at HUNTER.ORG Valid starting Expires Service principal 09/12/13 11:17:40 09/13/13 11:17:39 krbtgt/HUNTER.ORG at HUNTER.ORG 09/12/13 11:17:40 09/13/13 11:17:39 nfs/ipa2.hunter.org at HUNTER.ORG [dean at desktop2 ~]$ logout Connection to desktop2 closed. [root at ipa2 ~]# logout [dean at ipa2 ~]$ klist Ticket cache: DIR::/run/user/1440800001/krb5cc/tktH9faWP Default principal: dean at HUNTER.ORG Valid starting Expires Service principal 09/12/13 11:14:40 09/13/13 11:14:40 krbtgt/HUNTER.ORG at HUNTER.ORG 09/12/13 11:15:29 09/13/13 11:14:40 host/desktop2.hunter.org at HUNTER.ORG [dean at ipa2 ~]$ ssh dean at desktop2 Last login: Thu Sep 12 11:17:39 2013 from ipa2.hunter.org [dean at desktop2 ~]$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1440800001) [dean at desktop2 ~]$ logout Connection to desktop2 closed. [dean at ipa2 ~]$ klist Ticket cache: DIR::/run/user/1440800001/krb5cc/tktH9faWP Default principal: dean at HUNTER.ORG Valid starting Expires Service principal 09/12/13 11:14:40 09/13/13 11:14:40 krbtgt/HUNTER.ORG at HUNTER.ORG 09/12/13 11:15:29 09/13/13 11:14:40 host/desktop2.hunter.org at HUNTER.ORG reboot .... [dean at ipa2 ~]$ klist Ticket cache: DIR::/run/user/1440800001/krb5cc/tktLOSJxT Default principal: dean at HUNTER.ORG Valid starting Expires Service principal 09/12/13 11:23:56 09/13/13 11:23:56 krbtgt/HUNTER.ORG at HUNTER.ORG [dean at ipa2 ~]$ ssh -k dean at desktop2 Last login: Thu Sep 12 11:22:31 2013 from ipa2.hunter.org Could not chdir to home directory /home/net/dean: Permission denied -bash: /home/net/dean/.bash_profile: Permission denied -bash-4.2$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1440800001) -bash-4.2$ logout -bash: /home/net/dean/.bash_logout: Permission denied Connection to desktop2 closed. [dean at ipa2 ~]$ klist Ticket cache: DIR::/run/user/1440800001/krb5cc/tktLOSJxT Default principal: dean at HUNTER.ORG Valid starting Expires Service principal 09/12/13 11:23:56 09/13/13 11:23:56 krbtgt/HUNTER.ORG at HUNTER.ORG 09/12/13 11:24:43 09/13/13 11:23:56 host/desktop2.hunter.org at HUNTER.ORG -------------- next part -------------- An HTML attachment was scrubbed... URL: From deanhunter at comcast.net Thu Sep 12 16:43:22 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Thu, 12 Sep 2013 11:43:22 -0500 Subject: [Freeipa-users] Permission Denied In-Reply-To: <52312627.90204@redhat.com> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> <1378946957.6584.2.camel@host.hunter.org> <523114A3.3060307@redhat.com> <1378949277.6584.12.camel@host.hunter.org> <52311A19.1090203@redhat.com> <1378951829.6584.18.camel@host.hunter.org> <52312627.90204@redhat.com> Message-ID: <1379004202.20745.6.camel@host.hunter.org> On Wed, 2013-09-11 at 22:25 -0400, Dmitri Pal wrote: > On 09/11/2013 10:10 PM, Dean Hunter wrote: > > > On Wed, 2013-09-11 at 21:34 -0400, Dmitri Pal wrote: > > > > > On 09/11/2013 09:27 PM, Dean Hunter wrote: > > > > > > > On Wed, 2013-09-11 at 21:10 -0400, Dmitri Pal wrote: > > > > > > > > > On 09/11/2013 08:49 PM, Dean Hunter wrote: > > > > > > > > > > > On Wed, 2013-09-11 at 11:49 -0400, Simo Sorce wrote: > > > > > > > > > > > > > On Wed, 2013-09-11 at 10:39 -0500, Dean Hunter wrote: > > > > > > > > On Wed, 2013-09-11 at 11:20 -0400, Simo Sorce wrote: > > > > > > > > > On Wed, 2013-09-11 at 08:39 -0500, Dean Hunter wrote: > > > > > > > > > > > > > > > > > > > I do NOT believe this: > > > > > > > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > > > > > > > > > Last login: Wed Sep 11 08:32:21 2013 from ipa2.hunter.org > > > > > > > > > > Could not chdir to home directory /home/net/dean: Permission > > > > > > > > > > denied > > > > > > > > > > -bash: /home/net/dean/.bash_profile: Permission denied > > > > > > > > > > > > > > > > > > > > -bash-4.2$ logout > > > > > > > > > > -bash: /home/net/dean/.bash_logout: Permission denied > > > > > > > > > > Connection to desktop2 closed. > > > > > > > > > > > > > > > > > > > > [dean at ipa2 ~]$ su - > > > > > > > > > > Password: > > > > > > > > > > > > > > > > > > > > [root at ipa2 ~]# ssh dean at desktop2 > > > > > > > > > > dean at desktop2's password: > > > > > > > > > > Last login: Wed Sep 11 08:34:29 2013 from ipa2.hunter.org > > > > > > > > > > > > > > > > > > > > [dean at desktop2 ~]$ logout > > > > > > > > > > Connection to desktop2 closed. > > > > > > > > > > > > > > > > > > > > [root at ipa2 ~]# logout > > > > > > > > > > > > > > > > > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > > > > > > > > > Last login: Wed Sep 11 08:35:16 2013 from ipa2.hunter.org > > > > > > > > > > > > > > > > > > > > [dean at desktop2 ~]$ > > > > > > > > > > > > > > > > > > > > > > > > > > > > Are you using a kerberized NFS mount ? > > > > > > > > > > > > > > > > > > I think what is happening is that when going via SSH rpc.gssd cannot > > > > > > > > > find your ticket, ssh may be doing something "wrong" in this case. > > > > > > > > > > > > > > > > > > Simo. > > > > > > > > > > > > > > > > > Yes, I am using Kerberos with NFS. > > > > > > > > > > > > > > > > Should I report this as a bug? > > > > > > > > > > > > > > > We need to decide what component is faulty. It may be possible we can > > > > > > > get it working somehow. > > > > > > > > > > > > > > When you ssh in what is the ccache ssh assign you ? > > > > > > > can you run klist and post the output (sanitize it if needed) ? > > > > > > > > > > > > > > Simo. > > > > > > > > > > > > > > > > > > > I hope this is what you requested: > > > > > > > > > > > > [dean at ipa2 ~]$ klist > > > > > > Ticket cache: > > > > > > DIR::/run/user/1387400001/krb5cc/tktFDDxRR > > > > > > Default principal: dean at HUNTER.ORG > > > > > > > > > > > > Valid starting Expires Service > > > > > > principal > > > > > > 09/11/13 19:43:28 09/12/13 19:43:28 > > > > > > krbtgt/HUNTER.ORG at HUNTER.ORG > > > > > > > > > > > > [dean at ipa2 ~]$ ssh dean at desktop2 > > > > > > Last login: Wed Sep 11 19:41:48 2013 from > > > > > > ipa2.hunter.org > > > > > > Could not chdir to home directory /home/net/dean: > > > > > > Permission denied > > > > > > -bash: /home/net/dean/.bash_profile: Permission > > > > > > denied > > > > > > > > > > > > -bash-4.2$ hostname > > > > > > desktop2.hunter.org > > > > > > > > > > > > -bash-4.2$ klist > > > > > > klist: No credentials cache found (ticket cache > > > > > > FILE:/tmp/krb5cc_1387400001) > > > > > > > > > > > > -bash-4.2$ logout > > > > > > -bash: /home/net/dean/.bash_logout: Permission > > > > > > denied > > > > > > Connection to desktop2 closed. > > > > > > > > > > > > [dean at ipa2 ~]$ klist > > > > > > Ticket cache: > > > > > > DIR::/run/user/1387400001/krb5cc/tktFDDxRR > > > > > > Default principal: dean at HUNTER.ORG > > > > > > > > > > > > Valid starting Expires Service > > > > > > principal > > > > > > 09/11/13 19:43:28 09/12/13 19:43:28 > > > > > > krbtgt/HUNTER.ORG at HUNTER.ORG > > > > > > 09/11/13 19:44:43 09/12/13 19:43:28 > > > > > > host/desktop2.hunter.org at HUNTER.ORG > > > > > > > > > > > > [dean at ipa2 ~]$ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Freeipa-users mailing list > > > > > > Freeipa-users at redhat.com > > > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > > > > Do I get it right: you tried twice and the first time it did > > > > > not work while the second it did? > > > > > There might be a race condition mounting your home directory > > > > > using your ticket. > > > > > > > > > > > > > > > -- > > > > > Thank you, > > > > > Dmitri Pal > > > > > > > > > > Sr. Engineering Manager for IdM portfolio > > > > > Red Hat Inc. > > > > > > > > > > > > > > > ------------------------------- > > > > > Looking to carve out IT costs? > > > > > www.redhat.com/carveoutcosts/ > > > > > > > > > > > > > > > _______________________________________________ > > > > > Freeipa-users mailing list > > > > > Freeipa-users at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > > > > > > Starting clean after rebuilding ipa2 and desktop2 and a gdm > > > > login to ipa2 as dean, if I "ssh dean at desktop2" it will > > > > consistently fail as noted in my last note. However, if I: > > > > 1. su - > > > > 2. ssh dean at desktop2 > > > > 3. logout of dean at desktop2 > > > > 4. logout of root at ipa2 > > > > then "ssh dean at desktop2" succeeds! > > > > > > > > Does that answer your question? So I do not think there is a > > > > race. It is more like the super user session leaves something > > > > behind that was missing? > > > > > > > > > Does it succeed if after step 3 but before step 4 you do kdestoy? > > > > > > > > > > > > -- > > > Thank you, > > > Dmitri Pal > > > > > > Sr. Engineering Manager for IdM portfolio > > > Red Hat Inc. > > > > > > > > > ------------------------------- > > > Looking to carve out IT costs? > > > www.redhat.com/carveoutcosts/ > > > > > > > > > Hah! Even better, it works the first time and every time, if I > > start with a kdestroy: > > 1. From Virtual Machine Manager open ipa2 > > 2. Login as dean > > 3. Open a terminal > > 4. kdestroy > > 5. ssh dean at desktop2 > > 6. logout > > 7. ssh dean at desktop2 > > 8. logout > > Now, the fun starts. Why do it do that? > > > > > > Now you need to see what you have before kdestroy. > Klist will help to see what cache is in play. > Then you need to see whether you as dean can access this cache (check > permissions and SELinux). > > Based on the input you provided earlier the cache might be in > FILE:/tmp/krb5cc_1387400001 > While after you login it is in > DIR::/run/user/1387400001/krb5cc/tktFDDxRR > The latter is the right one. > All applications in Fedora starting F18 should use DIR cache. > It seems that on this machine there is some other kerberized software > (NFS client?) that is not configured or updated to create DIR cache > style cache and continues to use FILE style cache. There have been a > slew of bugs around this. It seems you are hitting one of those. > Just FYI to avoid this confusion and to fight some race conditions > related to creation of the /run/user/uid directory the cache is now > moved to kernel and we are in process of updating different components > to use it. > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > [dean at ipa2 ~]$ ssh dean at desktop2 Last login: Thu Sep 12 11:25:13 2013 from ipa2.hunter.org Could not chdir to home directory /home/net/dean: Permission denied -bash: /home/net/dean/.bash_profile: Permission denied -bash-4.2$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1440800001) -bash-4.2$ ls -lZ /tmp/krb5cc* -rw-------. root root system_u:object_r:gssd_tmp_t:s0 /tmp/krb5ccmachine_HUNTER.ORG -bash-4.2$ rpm -q nfs-utils nfs-utils-1.2.7-6.fc18.x86_64 -bash-4.2$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Sep 12 17:59:49 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Sep 2013 13:59:49 -0400 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1379003260.20745.4.camel@host.hunter.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> <1378946957.6584.2.camel@host.hunter.org> <1378991346.2804.1890.camel@willson.li.ssimo.org> <1379003260.20745.4.camel@host.hunter.org> Message-ID: <1379008789.2804.1934.camel@willson.li.ssimo.org> On Thu, 2013-09-12 at 11:27 -0500, Dean Hunter wrote: > On Thu, 2013-09-12 at 09:09 -0400, Simo Sorce wrote: > > > Yes it is, but I need to see also what you get on the successfull ssh > > case, klist is all I need to see, no other output. > > > > Also does it work all the time if you use the command > > > > ssh -K dean at desktop2 ? you did not try the above ^^ :-) > [dean at ipa2 ~]$ klist > Ticket cache: DIR::/run/user/1440800001/krb5cc/tktH9faWP > Default principal: dean at HUNTER.ORG > > Valid starting Expires Service principal > 09/12/13 11:14:40 09/13/13 11:14:40 krbtgt/HUNTER.ORG at HUNTER.ORG > > [dean at ipa2 ~]$ ssh dean at desktop2 > Last login: Wed Sep 11 21:14:18 2013 from ipa2.hunter.org > Could not chdir to home directory /home/net/dean: Permission denied > -bash: /home/net/dean/.bash_profile: Permission denied > > -bash-4.2$ klist > klist: No credentials cache found (ticket cache > FILE:/tmp/krb5cc_1440800001) > > -bash-4.2$ logout > -bash: /home/net/dean/.bash_logout: Permission denied > Connection to desktop2 closed. > > [dean at ipa2 ~]$ klist > Ticket cache: DIR::/run/user/1440800001/krb5cc/tktH9faWP > Default principal: dean at HUNTER.ORG > > Valid starting Expires Service principal > 09/12/13 11:14:40 09/13/13 11:14:40 krbtgt/HUNTER.ORG at HUNTER.ORG > 09/12/13 11:15:29 09/13/13 11:14:40 > host/desktop2.hunter.org at HUNTER.ORG > > [dean at ipa2 ~]$ su - > Password: > > [root at ipa2 ~]# klist > klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0) > > [root at ipa2 ~]# ssh dean at desktop2 > dean at desktop2's password: > Last login: Thu Sep 12 11:16:15 2013 from ipa2.hunter.org > [dean at desktop2 ~]$ klist > Ticket cache: DIR::/run/user/1440800001/krb5cc/tktrhI7WX > Default principal: dean at HUNTER.ORG > > Valid starting Expires Service principal > 09/12/13 11:17:40 09/13/13 11:17:39 krbtgt/HUNTER.ORG at HUNTER.ORG > 09/12/13 11:17:40 09/13/13 11:17:39 nfs/ipa2.hunter.org at HUNTER.ORG > > [dean at desktop2 ~]$ logout > Connection to desktop2 closed. > > [root at ipa2 ~]# logout > > [dean at ipa2 ~]$ klist > Ticket cache: DIR::/run/user/1440800001/krb5cc/tktH9faWP > Default principal: dean at HUNTER.ORG > > Valid starting Expires Service principal > 09/12/13 11:14:40 09/13/13 11:14:40 krbtgt/HUNTER.ORG at HUNTER.ORG > 09/12/13 11:15:29 09/13/13 11:14:40 > host/desktop2.hunter.org at HUNTER.ORG > > [dean at ipa2 ~]$ ssh dean at desktop2 > Last login: Thu Sep 12 11:17:39 2013 from ipa2.hunter.org > > [dean at desktop2 ~]$ klist > klist: No credentials cache found (ticket cache > FILE:/tmp/krb5cc_1440800001) > > [dean at desktop2 ~]$ logout > Connection to desktop2 closed. > > [dean at ipa2 ~]$ klist > Ticket cache: DIR::/run/user/1440800001/krb5cc/tktH9faWP > Default principal: dean at HUNTER.ORG > > Valid starting Expires Service principal > 09/12/13 11:14:40 09/13/13 11:14:40 krbtgt/HUNTER.ORG at HUNTER.ORG > 09/12/13 11:15:29 09/13/13 11:14:40 > host/desktop2.hunter.org at HUNTER.ORG > > reboot .... > > [dean at ipa2 ~]$ klist > Ticket cache: DIR::/run/user/1440800001/krb5cc/tktLOSJxT > Default principal: dean at HUNTER.ORG > > Valid starting Expires Service principal > 09/12/13 11:23:56 09/13/13 11:23:56 krbtgt/HUNTER.ORG at HUNTER.ORG > > [dean at ipa2 ~]$ ssh -k dean at desktop2 > Last login: Thu Sep 12 11:22:31 2013 from ipa2.hunter.org > Could not chdir to home directory /home/net/dean: Permission denied > -bash: /home/net/dean/.bash_profile: Permission denied > > -bash-4.2$ klist > klist: No credentials cache found (ticket cache > FILE:/tmp/krb5cc_1440800001) > > -bash-4.2$ logout > -bash: /home/net/dean/.bash_logout: Permission denied > Connection to desktop2 closed. > > [dean at ipa2 ~]$ klist > Ticket cache: DIR::/run/user/1440800001/krb5cc/tktLOSJxT > Default principal: dean at HUNTER.ORG > > Valid starting Expires Service principal > 09/12/13 11:23:56 09/13/13 11:23:56 krbtgt/HUNTER.ORG at HUNTER.ORG > 09/12/13 11:24:43 09/13/13 11:23:56 > host/desktop2.hunter.org at HUNTER.ORG > However here is the exact explanation of what is going on. The first time you ssh in you are not using password authentication but SSO (GSSAPI auth) *however* you are not delegating credentials to desktop2 (-K option). What this means is that ssh can allow you in because you have a valid ticket, but once you alnd of the cmahine there are no credentials avaliable there locally so the NFS client has no way to authenticate you to the NFS server. Later on when you do the su - and the ssh you are doing password authentication instead. *that* is the key difference, the fact that you do su - is a red herring and only causes you to not have credentials to use and makes ssh fall back to password authentication. you can obtain the same effect calling kdestroy instead of su - or telling ssh to not use GSSAPI for auth. Anyway when you authenticate with a password you give the target system your password which it will use to obtain a ticket for you and it places the ticket in the DIR:/run/user/... directory. There the NFS client can find it and uses it to authenticate your user to the NFS Server, so you can access the home directory no problem. The second time you do a straight ssh with GSSAPI auth (no password requested) it works because the cache generated with the previous attempt hasn't been removed, so the NFS client still finds it. Finally it starts failing again after reboot because /run/user it a tmpfs and gets wiped at reboot. Bottom line: if you need credentials on the target system (and you need them because you are using kerberized NFS for homes) you either use ssh -K dead at desktop2 so that you forward credentials each time, or you force your client to use password authentication so the target system can fetch credentials on its own/ HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From thomas.raehalme at codecenter.fi Thu Sep 12 18:29:21 2013 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Thu, 12 Sep 2013 21:29:21 +0300 Subject: [Freeipa-users] Using FreeIPA for LDAP authentication in 3rd party applications In-Reply-To: <5231C2AF.7040003@redhat.com> References: <5231B37D.2010705@redhat.com> <5231BC52.40401@redhat.com> <5231C2AF.7040003@redhat.com> Message-ID: Hi! On Thu, Sep 12, 2013 at 4:33 PM, Martin Kosek wrote: > Well, LDAP is the data backend for all FreeIPA identity data, you can certainly > use plain LDAP binds with them (though Kerberos/GSSAPI auth is preferred). > # ldapsearch -h `hostname` -D "uid=jdoe,cn=users,cn=accounts,dc=example,dc=com" > -x -w xO3xs5yOv,dL -b "" -s base Now I got it working. I didn't remember to use dn to login, so no wonder it didn't work :-) Thank you for all your help! Best regards, Thomas From dpal at redhat.com Thu Sep 12 18:37:40 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 12 Sep 2013 14:37:40 -0400 Subject: [Freeipa-users] FreeIPA integrating samba4 + AD In-Reply-To: References: <1378927682.2804.1708.camel@willson.li.ssimo.org> <1378929566.2804.1745.camel@willson.li.ssimo.org> <5230DEDC.9080207@redhat.com> Message-ID: <523209F4.7080100@redhat.com> On 09/11/2013 11:27 PM, Christovam Paynes Silva wrote: > > > > 2013/9/11 Dmitri Pal > > > On 09/11/2013 04:02 PM, Christovam Paynes Silva wrote: >> It is a pity! >> Thank you! > > > > I did not get a feeling that we understand the whole picture > correctly to say that we provided the full answer.. > > What I get from the description: > 1) Presence of Windows Clients = 100 > > > Correct! > > > 2) Presence of AD to rule them > > > Correct! > > 3) Presence of users (I deduce in AD too, but unclear) = 1000 > > > Correct! Users are wirelessly. Use windows and linux without domain. > > > Intent: use open source technologies instead of proprietary solution. > > > That's right! > > > > What is not clear: > a) Are the users that come through the portal the same users that > use Windows Clients or not? Is there an overlap? > > > Users are via wireless. Authenticate users on a "captive portal" with > Squid. Customers are windows, linux and without domain. > > > b) Is there any kind of Linux servers/machines in the picture? > > > This question was not clear to me. FreeIPA is a domain controller for Linux/UNIX systems. It main value it to manage Linux environment inside your enterprise. It can manage users and groups too as any directory can. It can also authenticate users but its value is in creating a integrated Linux environment in terms of identity management. It seems that the setup you have does not actually have such Linux environment, i.e. Linux machines to join to IPA domain and manage. The question was: "Do you have Linux systems to manage?". > > > > If you do not have Linux systems and all users can be stored in > one place it might be that you do not need FreeIPA. It might be > that you can solve the problem by using Samba4 instead of AD, > connecting your clients to it, putting your external portal users > into a special OU in Samba4, configuring FreeRADIUS to use this OU > for authentication. Configure your portal to use RADIUS. > > > > Sorry, I may not have understood the concept of FreeIPA. > > I would like to continue using the AD, because of Group Policy Objects > (GPO). You need to check whether Samba 4 supports GPO and to what extent. http://wiki.samba.org/index.php/FAQ#Is_it_possible_to_set_user_specific_password_policies_in_Samba4_.28e._g._on_a_OU-base.29.3F > It has the ability to authenticate email services, applications, among > others directly in Samba4? Yes as with any LDAP server but if you are planning to use AD than you do not need Samba 4 either. You then point your mail service and applications to AD directly. Most of modern applications have some sort of LDAP integration for identity lookup and authentication. That means you would be able to point them to prety much any directory: AD, Samba4, IPA, 389 ... > > > > > > HTH > > Thanks > Dmitri > > > >> >> >> 2013/9/11 Simo Sorce > >> >> On Wed, 2013-09-11 at 16:37 -0300, Christovam Paynes Silva wrote: >> > Hello Simo, thanks for the feedback. >> > I would use the Samba4 with AD and authenticate my clients >> windows in >> > FreeIPA. >> > Is this possible? >> >> It is not possible at this point to combine Samba4 AD and >> freeIPA. >> >> Simo. >> > >> > 2013/9/11 Simo Sorce > >> > On Wed, 2013-09-11 at 14:06 -0300, Christovam >> Paynes Silva >> > wrote: >> > > Hello! >> > > >> > > >> > > First I apologize if this topic is redundant. >> > > >> > > >> > > I'm looking on the implementation of FreeIPA . >> Looking for >> > the >> > > forums , have some comments that authentication >> does not >> > work with >> > > Samba4 . Elsewhere say that that possibility >> exists . Today >> > we have >> > > nearly 200 computers in the domain with the "Active >> > Directory" and one >> > > wireless "captive portal" with 1000 + proxy users . >> > > >> > > I would like to see if the following scenario is >> possible : >> > > 1 - Integrating Samba4 with "Active Directory" , >> to use >> > their GPO and >> > > authenticate network users through the FreeIPA . >> > > 2 - Authenticate proxy servers in FreeIPA . >> > > 3 - And if it is possible some integration with >> FreeRADIUS >> > > >> > >> > >> > Hi Christovam, it is a bit unclear what you mean by >> > integrating here. >> > >> > Is your intent to use Samba4 as an AD domain >> controller for >> > your Windows >> > client s and IPA for your servers ? >> > >> > If that's the case unfortunately this is not >> possible at the >> > moment as >> > samba4 does not yet support Forest level trusts. >> > A Microsoft AD server can be used this way instead. >> > >> > Simo. >> > >> > -- >> > Simo Sorce * Red Hat, Inc * New York >> > >> > >> > >> >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbulist at gmail.com Thu Sep 12 18:39:30 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Thu, 12 Sep 2013 13:39:30 -0500 Subject: [Freeipa-users] Incorrect user information In-Reply-To: <20130910113031.GG11028@hendrix.brq.redhat.com> References: <5227465D.7020308@gmail.com> <841815955.7935136.1378306069557.JavaMail.root@redhat.com> <237193263.7936259.1378306160770.JavaMail.root@redhat.com> <52274F35.5090508@gmail.com> <20130904153134.GH22590@hendrix.brq.redhat.com> <52275C7A.3020800@gmail.com> <20130910113031.GG11028@hendrix.brq.redhat.com> Message-ID: <52320A62.4050402@gmail.com> Hi Jakub!.. Don't worry and thank for your help. Let me try it tomorrow and I will let you know asap. Thanks! On 09/10/2013 06:30 AM, Jakub Hrozek wrote: > On Wed, Sep 04, 2013 at 11:14:50AM -0500, cbulist at gmail.com wrote: >> Hi Jakub, >> >> >> Thanks for your time and tips about sssd cache! >> > I'm sorry about the late response, I didn't flag your response when it > came back.. > >> I did the test and let me explain what I got: >> >> - After step 4 I can see dataExpireTimestamp to 1 for the user. > OK, this is expected. > >> - After step 7 dataExpireTimestamp is back to 0 but the user data have >> not changed. > This is really strange because if the dataExpireTimestamp was reset > after the lookup, then the backend has updated the entry...and it should > have updated the entry with the up-to-date data.. > > Can you put debug_level=8 into the [nss] and [domain] sections > and paste or attach the contents of /var/log/sssd/sssd_nss.log and > /var/log/sssd/sssd_$domain.log after the request that follows the sss_cache > run? > > Also in the logs you should see the server the SSSD connects to, can you > check if there is maybe some replica that is out of sync? > > Unfortunately I can't reproduce the bug here.. > >> The first line after the command ldbsearch is: >> >> asq: Unable to register control with rootdse! > No, that's an internal info, ignore this message. > >> Is it a problem? >> >> We are not using nscd service. >> >> Please let me know if you need to do some other tests. >> Thanks in advance! > From mkosek at redhat.com Thu Sep 12 18:58:34 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Sep 2013 20:58:34 +0200 Subject: [Freeipa-users] Using FreeIPA for LDAP authentication in 3rd party applications In-Reply-To: References: <5231B37D.2010705@redhat.com> <5231BC52.40401@redhat.com> <5231C2AF.7040003@redhat.com> Message-ID: <52320EDA.2040704@redhat.com> On 09/12/2013 08:29 PM, Thomas Raehalme wrote: > Hi! > > On Thu, Sep 12, 2013 at 4:33 PM, Martin Kosek wrote: >> Well, LDAP is the data backend for all FreeIPA identity data, you can certainly >> use plain LDAP binds with them (though Kerberos/GSSAPI auth is preferred). >> # ldapsearch -h `hostname` -D "uid=jdoe,cn=users,cn=accounts,dc=example,dc=com" >> -x -w xO3xs5yOv,dL -b "" -s base > > Now I got it working. I didn't remember to use dn to login, so no > wonder it didn't work :-) > > Thank you for all your help! > > Best regards, > Thomas > Good! I am glad I could help :-) Martin From simo at redhat.com Thu Sep 12 19:33:02 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Sep 2013 15:33:02 -0400 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1379008789.2804.1934.camel@willson.li.ssimo.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> <1378946957.6584.2.camel@host.hunter.org> <1378991346.2804.1890.camel@willson.li.ssimo.org> <1379003260.20745.4.camel@host.hunter.org> <1379008789.2804.1934.camel@willson.li.ssimo.org> Message-ID: <1379014382.2804.1950.camel@willson.li.ssimo.org> On Thu, 2013-09-12 at 13:59 -0400, Simo Sorce wrote: > ticket, but once you alnd of the cmahine there are no credentials this meant to be 'land on the machine', sorry for my typing impairment. Simo. -- Simo Sorce * Red Hat, Inc * New York From deanhunter at comcast.net Thu Sep 12 20:34:04 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Thu, 12 Sep 2013 15:34:04 -0500 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1379008789.2804.1934.camel@willson.li.ssimo.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> <1378946957.6584.2.camel@host.hunter.org> <1378991346.2804.1890.camel@willson.li.ssimo.org> <1379003260.20745.4.camel@host.hunter.org> <1379008789.2804.1934.camel@willson.li.ssimo.org> Message-ID: <1379018044.13444.21.camel@host.hunter.org> On Thu, 2013-09-12 at 13:59 -0400, Simo Sorce wrote: > On Thu, 2013-09-12 at 11:27 -0500, Dean Hunter wrote: > > On Thu, 2013-09-12 at 09:09 -0400, Simo Sorce wrote: > > > > > Yes it is, but I need to see also what you get on the successfull ssh > > > case, klist is all I need to see, no other output. > > > > > > Also does it work all the time if you use the command > > > > > > ssh -K dean at desktop2 ? > > you did not try the above ^^ :-) Oops, it is these old eyes. OK, "ssh -K dean at desktop2" works all the time. Now there are problems when I log out, sometimes one processor starts spinning other times I get tossed all the way out of Gnome. I have not yet established a pattern. Is this familiar? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Sep 12 20:59:46 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Sep 2013 16:59:46 -0400 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1379018044.13444.21.camel@host.hunter.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> <1378946957.6584.2.camel@host.hunter.org> <1378991346.2804.1890.camel@willson.li.ssimo.org> <1379003260.20745.4.camel@host.hunter.org> <1379008789.2804.1934.camel@willson.li.ssimo.org> <1379018044.13444.21.camel@host.hunter.org> Message-ID: <1379019586.2804.1954.camel@willson.li.ssimo.org> On Thu, 2013-09-12 at 15:34 -0500, Dean Hunter wrote: > On Thu, 2013-09-12 at 13:59 -0400, Simo Sorce wrote: > > On Thu, 2013-09-12 at 11:27 -0500, Dean Hunter wrote: > > > On Thu, 2013-09-12 at 09:09 -0400, Simo Sorce wrote: > > > > > > > Yes it is, but I need to see also what you get on the successfull ssh > > > > case, klist is all I need to see, no other output. > > > > > > > > Also does it work all the time if you use the command > > > > > > > > ssh -K dean at desktop2 ? > > > > you did not try the above ^^ :-) > > Oops, it is these old eyes. OK, "ssh -K dean at desktop2" works all the > time. good > Now there are problems when I log out, sometimes one processor starts > spinning other times I get tossed all the way out of Gnome. I have > not yet established a pattern. Is this familiar? > Is this related to ssh in ? or is it a completely unrelated problem ? Simo. -- Simo Sorce * Red Hat, Inc * New York From christovamps at gmail.com Thu Sep 12 03:27:47 2013 From: christovamps at gmail.com (Christovam Paynes Silva) Date: Thu, 12 Sep 2013 00:27:47 -0300 Subject: [Freeipa-users] FreeIPA integrating samba4 + AD In-Reply-To: <5230DEDC.9080207@redhat.com> References: <1378927682.2804.1708.camel@willson.li.ssimo.org> <1378929566.2804.1745.camel@willson.li.ssimo.org> <5230DEDC.9080207@redhat.com> Message-ID: 2013/9/11 Dmitri Pal > On 09/11/2013 04:02 PM, Christovam Paynes Silva wrote: > > It is a pity! > Thank you! > > > > > I did not get a feeling that we understand the whole picture correctly to > say that we provided the full answer.. > > What I get from the description: > 1) Presence of Windows Clients = 100 > Correct! > 2) Presence of AD to rule them > Correct! 3) Presence of users (I deduce in AD too, but unclear) = 1000 > Correct! Users are wirelessly. Use windows and linux without domain. > Intent: use open source technologies instead of proprietary solution. > That's right! > > What is not clear: > a) Are the users that come through the portal the same users that use > Windows Clients or not? Is there an overlap? > Users are via wireless. Authenticate users on a "captive portal" with Squid. Customers are windows, linux and without domain. > b) Is there any kind of Linux servers/machines in the picture? > This question was not clear to me. > > If you do not have Linux systems and all users can be stored in one place > it might be that you do not need FreeIPA. It might be that you can solve > the problem by using Samba4 instead of AD, connecting your clients to it, > putting your external portal users into a special OU in Samba4, configuring > FreeRADIUS to use this OU for authentication. Configure your portal to use > RADIUS. > Sorry, I may not have understood the concept of FreeIPA. I would like to continue using the AD, because of Group Policy Objects (GPO). It has the ability to authenticate email services, applications, among others directly in Samba4? > > HTH > > Thanks > Dmitri > > > > > > 2013/9/11 Simo Sorce > >> On Wed, 2013-09-11 at 16:37 -0300, Christovam Paynes Silva wrote: >> > Hello Simo, thanks for the feedback. >> > I would use the Samba4 with AD and authenticate my clients windows in >> > FreeIPA. >> > Is this possible? >> >> It is not possible at this point to combine Samba4 AD and freeIPA. >> >> Simo. >> > >> > 2013/9/11 Simo Sorce >> > On Wed, 2013-09-11 at 14:06 -0300, Christovam Paynes Silva >> > wrote: >> > > Hello! >> > > >> > > >> > > First I apologize if this topic is redundant. >> > > >> > > >> > > I'm looking on the implementation of FreeIPA . Looking for >> > the >> > > forums , have some comments that authentication does not >> > work with >> > > Samba4 . Elsewhere say that that possibility exists . Today >> > we have >> > > nearly 200 computers in the domain with the "Active >> > Directory" and one >> > > wireless "captive portal" with 1000 + proxy users . >> > > >> > > I would like to see if the following scenario is possible : >> > > 1 - Integrating Samba4 with "Active Directory" , to use >> > their GPO and >> > > authenticate network users through the FreeIPA . >> > > 2 - Authenticate proxy servers in FreeIPA . >> > > 3 - And if it is possible some integration with FreeRADIUS >> > > >> > >> > >> > Hi Christovam, it is a bit unclear what you mean by >> > integrating here. >> > >> > Is your intent to use Samba4 as an AD domain controller for >> > your Windows >> > client s and IPA for your servers ? >> > >> > If that's the case unfortunately this is not possible at the >> > moment as >> > samba4 does not yet support Forest level trusts. >> > A Microsoft AD server can be used this way instead. >> > >> > Simo. >> > >> > -- >> > Simo Sorce * Red Hat, Inc * New York >> > >> > >> > >> >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mussz624 at robertmorris.edu Thu Sep 12 21:13:26 2013 From: mussz624 at robertmorris.edu (Zach Musselman) Date: Thu, 12 Sep 2013 16:13:26 -0500 Subject: [Freeipa-users] IPA vs 3.0 and Windows Group Policy Message-ID: Hello, My company currently has RHEL 6.4 with IPA vs 3.0 and Samba vs 3. Is it currently possible to integrate a Windows server into this domain for using group policies to my Windows clients without creating a Windows domain or Active Directory? -- Zach -------------- next part -------------- An HTML attachment was scrubbed... URL: From deanhunter at comcast.net Thu Sep 12 21:16:06 2013 From: deanhunter at comcast.net (Dean Hunter) Date: Thu, 12 Sep 2013 16:16:06 -0500 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1379019586.2804.1954.camel@willson.li.ssimo.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> <1378946957.6584.2.camel@host.hunter.org> <1378991346.2804.1890.camel@willson.li.ssimo.org> <1379003260.20745.4.camel@host.hunter.org> <1379008789.2804.1934.camel@willson.li.ssimo.org> <1379018044.13444.21.camel@host.hunter.org> <1379019586.2804.1954.camel@willson.li.ssimo.org> Message-ID: <1379020566.13444.25.camel@host.hunter.org> On Thu, 2013-09-12 at 16:59 -0400, Simo Sorce wrote: > On Thu, 2013-09-12 at 15:34 -0500, Dean Hunter wrote: > > On Thu, 2013-09-12 at 13:59 -0400, Simo Sorce wrote: > > > On Thu, 2013-09-12 at 11:27 -0500, Dean Hunter wrote: > > > > On Thu, 2013-09-12 at 09:09 -0400, Simo Sorce wrote: > > > > > > > > > Yes it is, but I need to see also what you get on the successfull ssh > > > > > case, klist is all I need to see, no other output. > > > > > > > > > > Also does it work all the time if you use the command > > > > > > > > > > ssh -K dean at desktop2 ? > > > > > > you did not try the above ^^ :-) > > > > Oops, it is these old eyes. OK, "ssh -K dean at desktop2" works all the > > time. > > good > > > Now there are problems when I log out, sometimes one processor starts > > spinning other times I get tossed all the way out of Gnome. I have > > not yet established a pattern. Is this familiar? > > > Is this related to ssh in ? or is it a completely unrelated problem ? > > Simo. I am sorry. I see now that I was not clear. When I log out of ssh on desktop2 it sometimes spins. When I log out of Gnome terminal after the spins I get tossed all the way out of Gnome. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Thu Sep 12 21:40:33 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Sep 2013 17:40:33 -0400 Subject: [Freeipa-users] Permission Denied In-Reply-To: <1379020566.13444.25.camel@host.hunter.org> References: <1378866963.2726.5.camel@host.hunter.org> <20130911041030.GB21212@redhat.com> <1378906051.23036.12.camel@host.hunter.org> <1378906755.23036.14.camel@host.hunter.org> <1378912805.2804.1603.camel@willson.li.ssimo.org> <1378913991.23036.16.camel@host.hunter.org> <1378914568.2804.1606.camel@willson.li.ssimo.org> <1378946957.6584.2.camel@host.hunter.org> <1378991346.2804.1890.camel@willson.li.ssimo.org> <1379003260.20745.4.camel@host.hunter.org> <1379008789.2804.1934.camel@willson.li.ssimo.org> <1379018044.13444.21.camel@host.hunter.org> <1379019586.2804.1954.camel@willson.li.ssimo.org> <1379020566.13444.25.camel@host.hunter.org> Message-ID: <1379022033.2804.1955.camel@willson.li.ssimo.org> On Thu, 2013-09-12 at 16:16 -0500, Dean Hunter wrote: > On Thu, 2013-09-12 at 16:59 -0400, Simo Sorce wrote: > > On Thu, 2013-09-12 at 15:34 -0500, Dean Hunter wrote: > > > On Thu, 2013-09-12 at 13:59 -0400, Simo Sorce wrote: > > > > On Thu, 2013-09-12 at 11:27 -0500, Dean Hunter wrote: > > > > > On Thu, 2013-09-12 at 09:09 -0400, Simo Sorce wrote: > > > > > > > > > > > Yes it is, but I need to see also what you get on the successfull ssh > > > > > > case, klist is all I need to see, no other output. > > > > > > > > > > > > Also does it work all the time if you use the command > > > > > > > > > > > > ssh -K dean at desktop2 ? > > > > > > > > you did not try the above ^^ :-) > > > > > > Oops, it is these old eyes. OK, "ssh -K dean at desktop2" works all the > > > time. > > > > good > > > > > Now there are problems when I log out, sometimes one processor starts > > > spinning other times I get tossed all the way out of Gnome. I have > > > not yet established a pattern. Is this familiar? > > > > > Is this related to ssh in ? or is it a completely unrelated problem ? > > > > Simo. > > I am sorry. I see now that I was not clear. When I log out of ssh on > desktop2 it sometimes spins. When I log out of Gnome terminal after > the spins I get tossed all the way out of Gnome. > Sounds like a bug in gnome-terminal or gnome in general, I've never seen that. Simo. -- Simo Sorce * Red Hat, Inc * New York From shelltoesuperstar at gmail.com Fri Sep 13 02:04:32 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Fri, 13 Sep 2013 03:04:32 +0100 Subject: [Freeipa-users] IPA Query Tuning and a Recovery Question In-Reply-To: <522DF801.9050703@redhat.com> References: <522DF801.9050703@redhat.com> Message-ID: On Mon, Sep 9, 2013 at 5:32 PM, Rich Megginson wrote: > On 09/09/2013 10:20 AM, Charlie Derwent wrote: > > Hi, > > 2 questions, some of our automation accounts are needlessly querying the > IPA server every time they call a command via sudo. This is generating a > lot of noise in our access logs. Is there any way to ensure certain system > accounts don't call out to the IPA server for additional groups or sudo > permission when completing tasks? > > > What are your client platforms? Does sssd or newer versions of sudo cache? > > > > The other question is slightly more embarrassing, one of our guys saw /var > filling and noticed that /var/lib/dirsrv/slapd-EXAMPLE-COM/db/ had a load > of "log" files which looked like they weren't being tidied. > > > They are automatically cleaned up. If you have a lot of updates, it may > take longer. > > > One stupid decision later and I'm now here asking on his behalf if there > is anyway of restoring the database from a replica or is a complete rebuild > required? > > > Just reinit the replica using ipa-replica-manage. > > I just tried to reinit the replica but I'm getting an error about failure to connect to LDAP server I'm guessing that's because it's impossible for me to kinit on the server now given the state of the DB. > > > Second question is obviously a little bit more urgent than the first but > any advice is greatly appreciated. > > Thanks, > Charlie > > > > > > > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Sep 13 04:25:38 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 13 Sep 2013 07:25:38 +0300 Subject: [Freeipa-users] IPA vs 3.0 and Windows Group Policy In-Reply-To: References: Message-ID: <20130913042538.GK21212@redhat.com> On Thu, 12 Sep 2013, Zach Musselman wrote: >Hello, > >My company currently has RHEL 6.4 with IPA vs 3.0 and Samba vs 3. > >Is it currently possible to integrate a Windows server into this domain for >using group policies to my Windows clients without creating a Windows >domain or Active Directory? No, it is not possible. -- / Alexander Bokovoy From marina.moreda at cica.es Fri Sep 13 09:16:45 2013 From: marina.moreda at cica.es (Marina Moreda) Date: Fri, 13 Sep 2013 11:16:45 +0200 Subject: [Freeipa-users] Date of last access attribute Message-ID: <5232D7FD.6080509@cica.es> Hi all, I need to add in my LDAP an attribute to save the date of last access to mail account, or something similar, to know when an user has stopped using his mail account. I can't find any attribute like this one. Any suggestions on how I can do this? Thanks so much. -- Marina Moreda Rodr?guez Departamento de Seguridad Inform?tica (nis at cica.es) Centro Inform?tico Cient?fico de Andaluc?a (CICA) Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain) Tfno.: +34 955 056 600 / FAX: +34 955 056 650 Consejer?a de Econom?a, Innovaci?n, Ciencia y Empleo Junta de Andaluc?a -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4210 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Sep 13 13:47:46 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 13 Sep 2013 07:47:46 -0600 Subject: [Freeipa-users] Date of last access attribute In-Reply-To: <5232D7FD.6080509@cica.es> References: <5232D7FD.6080509@cica.es> Message-ID: <52331782.7090905@redhat.com> On 09/13/2013 03:16 AM, Marina Moreda wrote: > Hi all, > > I need to add in my LDAP an attribute to save the date of last access > to mail account, or something similar, to know when an user has > stopped using his mail account. I can't find any attribute like this > one. Any suggestions on how I can do this? 389 has a feature which keeps track of lastLoginTime - that is - the last time someone did a BIND to the LDAP server. I don't know if IPA has a similar feature for Kerberos authentication. http://www.port389.org/wiki/Account_Policy_Design > > Thanks so much. > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Sep 13 13:49:16 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 13 Sep 2013 07:49:16 -0600 Subject: [Freeipa-users] IPA Query Tuning and a Recovery Question In-Reply-To: References: <522DF801.9050703@redhat.com> Message-ID: <523317DC.2050800@redhat.com> On 09/12/2013 08:04 PM, Charlie Derwent wrote: > > > On Mon, Sep 9, 2013 at 5:32 PM, Rich Megginson > wrote: > > On 09/09/2013 10:20 AM, Charlie Derwent wrote: >> Hi, >> 2 questions, some of our automation accounts are needlessly >> querying the IPA server every time they call a command via sudo. >> This is generating a lot of noise in our access logs. Is there >> any way to ensure certain system accounts don't call out to the >> IPA server for additional groups or sudo permission when >> completing tasks? > > What are your client platforms? Does sssd or newer versions of > sudo cache? > > >> The other question is slightly more embarrassing, one of our guys >> saw /var filling and noticed that >> /var/lib/dirsrv/slapd-EXAMPLE-COM/db/ had a load of "log" files >> which looked like they weren't being tidied. > > They are automatically cleaned up. If you have a lot of updates, > it may take longer. > > >> One stupid decision later and I'm now here asking on his behalf >> if there is anyway of restoring the database from a replica or is >> a complete rebuild required? > > Just reinit the replica using ipa-replica-manage. > > I just tried to reinit the replica but I'm getting an error about > failure to connect to LDAP server I'm guessing that's because it's > impossible for me to kinit on the server now given the state of the DB. It depends. What error? Can you provide the exact error message and/or excerpts from /var/log/dirsrv/slapd-DOMAIN-COM/errors? >> Second question is obviously a little bit more urgent than the >> first but any advice is greatly appreciated. >> Thanks, >> Charlie >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Sep 13 14:44:51 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 13 Sep 2013 10:44:51 -0400 Subject: [Freeipa-users] IPA vs 3.0 and Windows Group Policy In-Reply-To: <20130913042538.GK21212@redhat.com> References: <20130913042538.GK21212@redhat.com> Message-ID: <523324E3.2040106@redhat.com> On 09/13/2013 12:25 AM, Alexander Bokovoy wrote: > On Thu, 12 Sep 2013, Zach Musselman wrote: >> Hello, >> >> My company currently has RHEL 6.4 with IPA vs 3.0 and Samba vs 3. >> >> Is it currently possible to integrate a Windows server into this >> domain for >> using group policies to my Windows clients without creating a Windows >> domain or Active Directory? > No, it is not possible. > And would not possible with pure IPA. Our vision is to let Samba4 manage Windows side for cases like this and then have trusts between Samba 4 and IPA. Trusts are not yet supported on Samba 4 side. There some work going on in this area. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Sep 13 14:50:01 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 13 Sep 2013 10:50:01 -0400 Subject: [Freeipa-users] Date of last access attribute In-Reply-To: <5232D7FD.6080509@cica.es> References: <5232D7FD.6080509@cica.es> Message-ID: <52332619.2040501@redhat.com> On 09/13/2013 05:16 AM, Marina Moreda wrote: > Hi all, > > I need to add in my LDAP an attribute to save the date of last access > to mail account, or something similar, to know when an user has > stopped using his mail account. I can't find any attribute like this > one. Any suggestions on how I can do this? > > Thanks so much. > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users I think there are some operational, i.e. "meta" attributes that store information when some attribute was last modified so if there is a way to associate mail activity with a modification of some user attribute then you can check the time stamp of this modification rather than create a separate attribute. With a new attribute the question comes: who, when and how updates it and whether the software you have is capable of doing it? May be software already updates something on every activity for the account and if this is the case then operation attributes would help. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Sep 13 14:58:18 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Sep 2013 10:58:18 -0400 Subject: [Freeipa-users] Date of last access attribute In-Reply-To: <52332619.2040501@redhat.com> References: <5232D7FD.6080509@cica.es> <52332619.2040501@redhat.com> Message-ID: <5233280A.2000202@redhat.com> Dmitri Pal wrote: > On 09/13/2013 05:16 AM, Marina Moreda wrote: >> Hi all, >> >> I need to add in my LDAP an attribute to save the date of last access >> to mail account, or something similar, to know when an user has >> stopped using his mail account. I can't find any attribute like this >> one. Any suggestions on how I can do this? >> >> Thanks so much. >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > I think there are some operational, i.e. "meta" attributes that store > information when some attribute was last modified so if there is a way > to associate mail activity with a modification of some user attribute > then you can check the time stamp of this modification rather than > create a separate attribute. With a new attribute the question comes: > who, when and how updates it and whether the software you have is > capable of doing it? May be software already updates something on every > activity for the account and if this is the case then operation > attributes would help. There is no mail-specific activity attribute. I think about the closest you could get is last successful Kerberos authentication (krblastsuccessfulauth), but again this isn't specific to mail activity (unless that is all the users can do). Note too that this attribute is by default not replicated so if you have several IPA masters you'd need to check them all. This attribute not updated on LDAP binds. rob From chris at redhat.com Fri Sep 13 15:13:52 2013 From: chris at redhat.com (Chris Hudson) Date: Fri, 13 Sep 2013 11:13:52 -0400 (EDT) Subject: [Freeipa-users] Using FreeIPA for LDAP authentication in 3rd party applications In-Reply-To: References: <5231B37D.2010705@redhat.com> Message-ID: <1969373104.11826788.1379085232753.JavaMail.root@redhat.com> A simple bind would be using a user/password combination to access LDAP. An example of a simple bind in an ldapsearch would look something like: # ldapsearch -x -h ldap.example.com -D uid=user1,ou=people,dc=example,dc=com -w password -b dc=example,dc=com You can see how we are using -x (simple bind) and then -D (who to bind with?) and then -w (password) to access the LDAP database on ldap.example.com. HTH, Chris ----- Original Message ----- > From: "Thomas Raehalme" > To: "Martin Kosek" > Cc: freeipa-users at redhat.com > Sent: Thursday, September 12, 2013 8:54:59 AM > Subject: Re: [Freeipa-users] Using FreeIPA for LDAP authentication in 3rd > party applications > Hi! > On Thu, Sep 12, 2013 at 3:28 PM, Martin Kosek wrote: > > When using FreeIPA LDAP as identity source, you could ideally use > > Kerberos/GSSAPI authentication. But if that is not available, you can use > > simple LDAP binds too. You cannot read the hash codes unless you are > > "cn=Directory Manager" (or unless you set ACI allowing that, but this is > > very > > unsecure). > Could you please elaborate on using simple LDAP binds? > Thanks for the detailed example! > Best regards, > Thomas > -- > Thomas Raehalme > CTO, teknologiajohtaja > Mobile +358 40 545 0605 > Codecenter Oy > V?in?nkatu 26 A, 4th Floor > 40100 JYV?SKYL?, Finland > Tel. +358 10 322 0040 > www.codecenter.fi > Codecenter - Tietoj?rjestelmi? ymm?rrett?v?sti > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Sep 13 15:18:15 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 13 Sep 2013 17:18:15 +0200 Subject: [Freeipa-users] Using subdomains (or dots) in hostnames In-Reply-To: References: Message-ID: <20130913151814.GX2954@hendrix.brq.redhat.com> On Thu, Sep 12, 2013 at 02:54:10PM +0300, Thomas Raehalme wrote: > Hi! > > >> Let's say we're using domain example.com. Adding clients a.example.com > >> and b.example.com was smooth. Adding client a.sub1.example.com also > >> had no problems until I tried to get sudoers from the IPA server > >> (using SSSD and LDAP as suggested). The client fails to find any users > >> matching the server name. Because the only difference compared to a > >> fully functional server is the dot in the host name, that's probably > >> the reason why no sudoers are found for the server in the subdomain? > > > >What do you use in nsswitch.conf for sudoers? ldap or sss? If sss, can > >you also paste your sssd.conf? > > >Can you paste the output of sudo along with the -D parameter to get some > >debugging? > > I managed to get subdomains working after adding the subdomain to the > IPA DNS and filling in the various SRV records pointing to the IPA > master. After the DNS was setup properly, DNS discovery would display > the correct subdomain on ipa-client-install. > > After the DNS discovery was successful, also sudo started working > properly on most servers. As I specified sss for sudoers in > nsswitch.conf and added the necessary configuration to sssd.conf as > described in the RedHat documentation, I was able to sudo the commands > I had enabled in the IPA policy. That's great! > > Some servers are still, however, causing headache. According to > /var/log/secure sudo can authenticate me, but for some reason the list > of allowed commands is empty (sudo -l responds "Sorry, user xxx may > not run sudo on yyy."). I have defined sudo rules so that anybody can > use sudo on any host, but only certain commands. I'll try to debug the > problems and let you know how it goes. > > The caching mechanism for sudo/sssd and especially clearing the cache > with sss_cache has turned out to be somewhat challenging to > understand. Does anybody know the correct parameters that cause the > sudoers cache be invalidated? Unfortunately sss_cache cannot clean sudoers rules. It's not as easy as it sounds, I'm afraid, but we're tracking the work in: https://fedorahosted.org/sssd/ticket/2081 From jhrozek at redhat.com Fri Sep 13 15:20:30 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 13 Sep 2013 17:20:30 +0200 Subject: [Freeipa-users] Using FreeIPA for LDAP authentication in 3rd party applications In-Reply-To: References: <5231B37D.2010705@redhat.com> Message-ID: <20130913152030.GY2954@hendrix.brq.redhat.com> On Thu, Sep 12, 2013 at 03:54:59PM +0300, Thomas Raehalme wrote: > Hi! > > On Thu, Sep 12, 2013 at 3:28 PM, Martin Kosek wrote: > > > When using FreeIPA LDAP as identity source, you could ideally use > > Kerberos/GSSAPI authentication. But if that is not available, you can use > > simple LDAP binds too. You cannot read the hash codes unless you are > > "cn=Directory Manager" (or unless you set ACI allowing that, but this is very > > unsecure). > > Could you please elaborate on using simple LDAP binds? > > Thanks for the detailed example! simple bind == with a password. The simple bind has two components - the DN to bind as and a password. See the example Martin posted. The ldapadd command there authenticates using DN "cn=Directory Manager" and Martin was kind enough to also show how a password can be provided. From jhrozek at redhat.com Fri Sep 13 15:21:03 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 13 Sep 2013 17:21:03 +0200 Subject: [Freeipa-users] Using FreeIPA for LDAP authentication in 3rd party applications In-Reply-To: References: <5231B37D.2010705@redhat.com> <5231BC52.40401@redhat.com> Message-ID: <20130913152103.GZ2954@hendrix.brq.redhat.com> On Thu, Sep 12, 2013 at 04:18:49PM +0300, Thomas Raehalme wrote: > Hi! > > On Thu, Sep 12, 2013 at 4:06 PM, Martin Kosek wrote: > > I was just referring to fact, that when a system or application uses LDAP as an > > identity and authentication source, it often use simple LDAP Bind operation > > (i.e. accessing LDAP with user+password or) when testing if the user accessing > > the application provided the right credentials. > > Yes, that's true at least for some applications. Does the LDAP in > FreeIPA allow that kind of login by default for IPA users? If not, is > it possible to enable it somehow? > > Best regards, > Thomas Raehalme The simple binds should be enabled by default in IPA. From jhrozek at redhat.com Fri Sep 13 15:38:36 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 13 Sep 2013 17:38:36 +0200 Subject: [Freeipa-users] Date of last access attribute In-Reply-To: <52331782.7090905@redhat.com> References: <5232D7FD.6080509@cica.es> <52331782.7090905@redhat.com> Message-ID: <20130913153836.GB2954@hendrix.brq.redhat.com> On Fri, Sep 13, 2013 at 07:47:46AM -0600, Rich Megginson wrote: > On 09/13/2013 03:16 AM, Marina Moreda wrote: > >Hi all, > > > >I need to add in my LDAP an attribute to save the date of last > >access to mail account, or something similar, to know when an user > >has stopped using his mail account. I can't find any attribute > >like this one. Any suggestions on how I can do this? > > 389 has a feature which keeps track of lastLoginTime - that is - the > last time someone did a BIND to the LDAP server. I don't know if > IPA has a similar feature for Kerberos authentication. > > > http://www.port389.org/wiki/Account_Policy_Design In IPA, I think the closest match is krbLastSuccessfulAuth. From simo at redhat.com Fri Sep 13 16:24:15 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 13 Sep 2013 12:24:15 -0400 Subject: [Freeipa-users] Is kerberos DB import to IPA possible? In-Reply-To: References: Message-ID: <1379089455.2804.1990.camel@willson.li.ssimo.org> On Thu, 2013-09-12 at 11:23 -0400, sergey ivanov wrote: > Hi, > I am looking for deployment of freeIPA in our organization. We have > kerberos servers used for authentication on our computers and in > applications, while users are mostly defined in /etc/passwd. > For migration of user's password I have tried the way we usually do > replicating password changes from master kerberos server to slaves. I > did kdb5_util dump on old servers, transferred the dump to machine > running FreeIPA, and was not able to do kdb5_util load -update, > because of "Kerberos database constraints violated". Is there a way to > import into freeIPA kerberos servers dump of kerberos principals, > dumped by kdb5_util? > You could *try* do it *after* you create all users in freeipa, but I think you'd break something. At the very least you would break plain text binds as you would not generate the userPassword hash, not sure what else, and I cannot guarantee it really works all the way. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Sep 13 16:26:11 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 13 Sep 2013 12:26:11 -0400 Subject: [Freeipa-users] Date of last access attribute In-Reply-To: <5233280A.2000202@redhat.com> References: <5232D7FD.6080509@cica.es> <52332619.2040501@redhat.com> <5233280A.2000202@redhat.com> Message-ID: <1379089571.2804.1991.camel@willson.li.ssimo.org> On Fri, 2013-09-13 at 10:58 -0400, Rob Crittenden wrote: > Dmitri Pal wrote: > > On 09/13/2013 05:16 AM, Marina Moreda wrote: > >> Hi all, > >> > >> I need to add in my LDAP an attribute to save the date of last access > >> to mail account, or something similar, to know when an user has > >> stopped using his mail account. I can't find any attribute like this > >> one. Any suggestions on how I can do this? > >> > >> Thanks so much. > >> > >> > >> > >> _______________________________________________ > >> Freeipa-users mailing list > >> Freeipa-users at redhat.com > >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > I think there are some operational, i.e. "meta" attributes that store > > information when some attribute was last modified so if there is a way > > to associate mail activity with a modification of some user attribute > > then you can check the time stamp of this modification rather than > > create a separate attribute. With a new attribute the question comes: > > who, when and how updates it and whether the software you have is > > capable of doing it? May be software already updates something on every > > activity for the account and if this is the case then operation > > attributes would help. > > There is no mail-specific activity attribute. I think about the closest > you could get is last successful Kerberos authentication > (krblastsuccessfulauth), but again this isn't specific to mail activity > (unless that is all the users can do). > > Note too that this attribute is by default not replicated so if you have > several IPA masters you'd need to check them all. This attribute not > updated on LDAP binds. Rob, should we open a ticket to update this for plain text binds too ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Sep 13 17:46:29 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Sep 2013 13:46:29 -0400 Subject: [Freeipa-users] Date of last access attribute In-Reply-To: <1379089571.2804.1991.camel@willson.li.ssimo.org> References: <5232D7FD.6080509@cica.es> <52332619.2040501@redhat.com> <5233280A.2000202@redhat.com> <1379089571.2804.1991.camel@willson.li.ssimo.org> Message-ID: <52334F75.1090806@redhat.com> Simo Sorce wrote: > On Fri, 2013-09-13 at 10:58 -0400, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 09/13/2013 05:16 AM, Marina Moreda wrote: >>>> Hi all, >>>> >>>> I need to add in my LDAP an attribute to save the date of last access >>>> to mail account, or something similar, to know when an user has >>>> stopped using his mail account. I can't find any attribute like this >>>> one. Any suggestions on how I can do this? >>>> >>>> Thanks so much. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> I think there are some operational, i.e. "meta" attributes that store >>> information when some attribute was last modified so if there is a way >>> to associate mail activity with a modification of some user attribute >>> then you can check the time stamp of this modification rather than >>> create a separate attribute. With a new attribute the question comes: >>> who, when and how updates it and whether the software you have is >>> capable of doing it? May be software already updates something on every >>> activity for the account and if this is the case then operation >>> attributes would help. >> >> There is no mail-specific activity attribute. I think about the closest >> you could get is last successful Kerberos authentication >> (krblastsuccessfulauth), but again this isn't specific to mail activity >> (unless that is all the users can do). >> >> Note too that this attribute is by default not replicated so if you have >> several IPA masters you'd need to check them all. This attribute not >> updated on LDAP binds. > > Rob, > should we open a ticket to update this for plain text binds too ? > > Simo. That's an interesting question. The attribute has krb in it which suggests a kerberos authentication, so I wonder if this would cause other confusion. rob From dpal at redhat.com Fri Sep 13 18:15:17 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 13 Sep 2013 14:15:17 -0400 Subject: [Freeipa-users] Date of last access attribute In-Reply-To: <52334F75.1090806@redhat.com> References: <5232D7FD.6080509@cica.es> <52332619.2040501@redhat.com> <5233280A.2000202@redhat.com> <1379089571.2804.1991.camel@willson.li.ssimo.org> <52334F75.1090806@redhat.com> Message-ID: <52335635.6070505@redhat.com> On 09/13/2013 01:46 PM, Rob Crittenden wrote: > Simo Sorce wrote: >> On Fri, 2013-09-13 at 10:58 -0400, Rob Crittenden wrote: >>> Dmitri Pal wrote: >>>> On 09/13/2013 05:16 AM, Marina Moreda wrote: >>>>> Hi all, >>>>> >>>>> I need to add in my LDAP an attribute to save the date of last access >>>>> to mail account, or something similar, to know when an user has >>>>> stopped using his mail account. I can't find any attribute like this >>>>> one. Any suggestions on how I can do this? >>>>> >>>>> Thanks so much. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> I think there are some operational, i.e. "meta" attributes that store >>>> information when some attribute was last modified so if there is a way >>>> to associate mail activity with a modification of some user attribute >>>> then you can check the time stamp of this modification rather than >>>> create a separate attribute. With a new attribute the question comes: >>>> who, when and how updates it and whether the software you have is >>>> capable of doing it? May be software already updates something on >>>> every >>>> activity for the account and if this is the case then operation >>>> attributes would help. >>> >>> There is no mail-specific activity attribute. I think about the closest >>> you could get is last successful Kerberos authentication >>> (krblastsuccessfulauth), but again this isn't specific to mail activity >>> (unless that is all the users can do). >>> >>> Note too that this attribute is by default not replicated so if you >>> have >>> several IPA masters you'd need to check them all. This attribute not >>> updated on LDAP binds. >> >> Rob, >> should we open a ticket to update this for plain text binds too ? >> >> Simo. > > That's an interesting question. The attribute has krb in it which > suggests a kerberos authentication, so I wonder if this would cause > other confusion. Wasn't there an intent not to update data on a successful auth? Only on a failure or first time after a failure to clear the counts? > > > rob > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Sep 13 18:22:29 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 13 Sep 2013 14:22:29 -0400 Subject: [Freeipa-users] Is kerberos DB import to IPA possible? In-Reply-To: <1379089455.2804.1990.camel@willson.li.ssimo.org> References: <1379089455.2804.1990.camel@willson.li.ssimo.org> Message-ID: <523357E5.6010405@redhat.com> On 09/13/2013 12:24 PM, Simo Sorce wrote: > On Thu, 2013-09-12 at 11:23 -0400, sergey ivanov wrote: >> Hi, >> I am looking for deployment of freeIPA in our organization. We have >> kerberos servers used for authentication on our computers and in >> applications, while users are mostly defined in /etc/passwd. >> For migration of user's password I have tried the way we usually do >> replicating password changes from master kerberos server to slaves. I >> did kdb5_util dump on old servers, transferred the dump to machine >> running FreeIPA, and was not able to do kdb5_util load -update, >> because of "Kerberos database constraints violated". Is there a way to >> import into freeIPA kerberos servers dump of kerberos principals, >> dumped by kdb5_util? >> > You could *try* do it *after* you create all users in freeipa, but I > think you'd break something. At the very least you would break plain > text binds as you would not generate the userPassword hash, not sure > what else, and I cannot guarantee it really works all the way. > > Simo. > So the answer is no, not the way you envisioned it. You need to get users from KDC DB. Reformat into and LDIF or just script invocation of the ipa user-add command. You would need to set temp passwords for users. Users would have to change their passwords on the first login. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From cbulist at gmail.com Fri Sep 13 19:55:18 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Fri, 13 Sep 2013 14:55:18 -0500 Subject: [Freeipa-users] Incorrect user information In-Reply-To: <20130910113031.GG11028@hendrix.brq.redhat.com> References: <5227465D.7020308@gmail.com> <841815955.7935136.1378306069557.JavaMail.root@redhat.com> <237193263.7936259.1378306160770.JavaMail.root@redhat.com> <52274F35.5090508@gmail.com> <20130904153134.GH22590@hendrix.brq.redhat.com> <52275C7A.3020800@gmail.com> <20130910113031.GG11028@hendrix.brq.redhat.com> Message-ID: <52336DA6.1020600@gmail.com> Hi Jakub, I attached the log files after doing the same test that you requested me before. Please let me know if you need anything else. Thanks!! On 09/10/2013 06:30 AM, Jakub Hrozek wrote: > On Wed, Sep 04, 2013 at 11:14:50AM -0500, cbulist at gmail.com wrote: >> Hi Jakub, >> >> >> Thanks for your time and tips about sssd cache! >> > I'm sorry about the late response, I didn't flag your response when it > came back.. > >> I did the test and let me explain what I got: >> >> - After step 4 I can see dataExpireTimestamp to 1 for the user. > OK, this is expected. > >> - After step 7 dataExpireTimestamp is back to 0 but the user data have >> not changed. > This is really strange because if the dataExpireTimestamp was reset > after the lookup, then the backend has updated the entry...and it should > have updated the entry with the up-to-date data.. > > Can you put debug_level=8 into the [nss] and [domain] sections > and paste or attach the contents of /var/log/sssd/sssd_nss.log and > /var/log/sssd/sssd_$domain.log after the request that follows the sss_cache > run? > > Also in the logs you should see the server the SSSD connects to, can you > check if there is maybe some replica that is out of sync? > > Unfortunately I can't reproduce the bug here.. > >> The first line after the command ldbsearch is: >> >> asq: Unable to register control with rootdse! > No, that's an internal info, ignore this message. > >> Is it a problem? >> >> We are not using nscd service. >> >> Please let me know if you need to do some other tests. >> Thanks in advance! > -------------- next part -------------- A non-text attachment was scrubbed... Name: adf_log.tar Type: application/x-tar Size: 133120 bytes Desc: not available URL: From brs at usf.edu Fri Sep 13 22:26:35 2013 From: brs at usf.edu (Brian Lindblom) Date: Fri, 13 Sep 2013 18:26:35 -0400 Subject: [Freeipa-users] Incorrect user information In-Reply-To: <52336DA6.1020600@gmail.com> References: <5227465D.7020308@gmail.com> <841815955.7935136.1378306069557.JavaMail.root@redhat.com> <237193263.7936259.1378306160770.JavaMail.root@redhat.com> <52274F35.5090508@gmail.com> <20130904153134.GH22590@hendrix.brq.redhat.com> <52275C7A.3020800@gmail.com> <20130910113031.GG11028@hendrix.brq.redhat.com> <52336DA6.1020600@gmail.com> Message-ID: I've run into this exact same problem. Check the output of ipa user-find --all The GECOS field is probably set to the old information. You can use ipa user-mod --gecos="New Name" to correct the issue. This solved it for me. -Brian On Fri, Sep 13, 2013 at 3:55 PM, cbulist at gmail.com wrote: > Hi Jakub, > > I attached the log files after doing the same test that you requested me > before. > Please let me know if you need anything else. > > Thanks!! > > > > On 09/10/2013 06:30 AM, Jakub Hrozek wrote: > > On Wed, Sep 04, 2013 at 11:14:50AM -0500, cbulist at gmail.com wrote: > >> Hi Jakub, > >> > >> > >> Thanks for your time and tips about sssd cache! > >> > > I'm sorry about the late response, I didn't flag your response when it > > came back.. > > > >> I did the test and let me explain what I got: > >> > >> - After step 4 I can see dataExpireTimestamp to 1 for the user. > > OK, this is expected. > > > >> - After step 7 dataExpireTimestamp is back to 0 but the user data have > >> not changed. > > This is really strange because if the dataExpireTimestamp was reset > > after the lookup, then the backend has updated the entry...and it should > > have updated the entry with the up-to-date data.. > > > > Can you put debug_level=8 into the [nss] and [domain] sections > > and paste or attach the contents of /var/log/sssd/sssd_nss.log and > > /var/log/sssd/sssd_$domain.log after the request that follows the > sss_cache > > run? > > > > Also in the logs you should see the server the SSSD connects to, can you > > check if there is maybe some replica that is out of sync? > > > > Unfortunately I can't reproduce the bug here.. > > > >> The first line after the command ldbsearch is: > >> > >> asq: Unable to register control with rootdse! > > No, that's an internal info, ignore this message. > > > >> Is it a problem? > >> > >> We are not using nscd service. > >> > >> Please let me know if you need to do some other tests. > >> Thanks in advance! > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Brian Lindblom (Smith) Assistant Director Research Computing, University of South Florida 4202 E. Fowler Ave. SVC4010 Office Phone: +1 813 974-1467 Organization URL: http://rc.usf.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at andrewklau.com Sat Sep 14 08:00:03 2013 From: andrew at andrewklau.com (Andrew Lau) Date: Sat, 14 Sep 2013 18:00:03 +1000 Subject: [Freeipa-users] Wildcard SSL Message-ID: Hi, I have a reverse proxy infront of many of my hosts, each of the virtual hosts have their own SSL cert, currently with FreeIPA I'm adding hosts for each virtual host and then creating a cert. >From what I've found, it doesn't seem to be possible to do a wildcard ssl through FreeIPA, I tried exporting the ca root private key to manually sign a wildcard cert with no success. I may have done that wrong. Any suggestions? Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From brs at usf.edu Sat Sep 14 17:11:36 2013 From: brs at usf.edu (Brian Lindblom) Date: Sat, 14 Sep 2013 13:11:36 -0400 Subject: [Freeipa-users] Incorrect user information In-Reply-To: References: <5227465D.7020308@gmail.com> <841815955.7935136.1378306069557.JavaMail.root@redhat.com> <237193263.7936259.1378306160770.JavaMail.root@redhat.com> <52274F35.5090508@gmail.com> <20130904153134.GH22590@hendrix.brq.redhat.com> <52275C7A.3020800@gmail.com> <20130910113031.GG11028@hendrix.brq.redhat.com> <52336DA6.1020600@gmail.com> Message-ID: Of course, I would imagine that since the GECOS field is set upon account creation based on the values provided for first and last name, and since GECOS is not a provided field in the UI for user attributes, that GECOS should be updated automatically to reflect those changes. Bug perhaps? On Fri, Sep 13, 2013 at 6:26 PM, Brian Lindblom wrote: > I've run into this exact same problem. Check the output of > > ipa user-find --all > > The GECOS field is probably set to the old information. You can use > > ipa user-mod --gecos="New Name" > > to correct the issue. This solved it for me. > > -Brian > > > On Fri, Sep 13, 2013 at 3:55 PM, cbulist at gmail.com wrote: > >> Hi Jakub, >> >> I attached the log files after doing the same test that you requested me >> before. >> Please let me know if you need anything else. >> >> Thanks!! >> >> >> >> On 09/10/2013 06:30 AM, Jakub Hrozek wrote: >> > On Wed, Sep 04, 2013 at 11:14:50AM -0500, cbulist at gmail.com wrote: >> >> Hi Jakub, >> >> >> >> >> >> Thanks for your time and tips about sssd cache! >> >> >> > I'm sorry about the late response, I didn't flag your response when it >> > came back.. >> > >> >> I did the test and let me explain what I got: >> >> >> >> - After step 4 I can see dataExpireTimestamp to 1 for the user. >> > OK, this is expected. >> > >> >> - After step 7 dataExpireTimestamp is back to 0 but the user data have >> >> not changed. >> > This is really strange because if the dataExpireTimestamp was reset >> > after the lookup, then the backend has updated the entry...and it should >> > have updated the entry with the up-to-date data.. >> > >> > Can you put debug_level=8 into the [nss] and [domain] sections >> > and paste or attach the contents of /var/log/sssd/sssd_nss.log and >> > /var/log/sssd/sssd_$domain.log after the request that follows the >> sss_cache >> > run? >> > >> > Also in the logs you should see the server the SSSD connects to, can you >> > check if there is maybe some replica that is out of sync? >> > >> > Unfortunately I can't reproduce the bug here.. >> > >> >> The first line after the command ldbsearch is: >> >> >> >> asq: Unable to register control with rootdse! >> > No, that's an internal info, ignore this message. >> > >> >> Is it a problem? >> >> >> >> We are not using nscd service. >> >> >> >> Please let me know if you need to do some other tests. >> >> Thanks in advance! >> > >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > > > -- > Brian Lindblom (Smith) > Assistant Director > Research Computing, University of South Florida > 4202 E. Fowler Ave. SVC4010 > Office Phone: +1 813 974-1467 > Organization URL: http://rc.usf.edu > -- Brian Lindblom (Smith) Assistant Director Research Computing, University of South Florida 4202 E. Fowler Ave. SVC4010 Office Phone: +1 813 974-1467 Organization URL: http://rc.usf.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sun Sep 15 18:23:39 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 15 Sep 2013 14:23:39 -0400 Subject: [Freeipa-users] Wildcard SSL In-Reply-To: References: Message-ID: <5235FB2B.2040500@redhat.com> On 09/14/2013 04:00 AM, Andrew Lau wrote: > Hi, > > I have a reverse proxy infront of many of my hosts, each of the > virtual hosts have their own SSL cert, currently with FreeIPA I'm > adding hosts for each virtual host and then creating a cert. > > From what I've found, it doesn't seem to be possible to do a wildcard > ssl through FreeIPA, I tried exporting the ca root private key to > manually sign a wildcard cert with no success. I may have done that wrong. > > Any suggestions? Is this what you are looking for? https://fedorahosted.org/freeipa/ticket/3475 It is currently on a distant roadmap but help always welcome. > > Thanks, > Andrew > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at andrewklau.com Sun Sep 15 23:20:50 2013 From: andrew at andrewklau.com (Andrew Lau) Date: Mon, 16 Sep 2013 09:20:50 +1000 Subject: [Freeipa-users] Wildcard SSL In-Reply-To: <5235FB2B.2040500@redhat.com> References: <5235FB2B.2040500@redhat.com> Message-ID: On Mon, Sep 16, 2013 at 4:23 AM, Dmitri Pal wrote: > On 09/14/2013 04:00 AM, Andrew Lau wrote: > > Hi, > > I have a reverse proxy infront of many of my hosts, each of the virtual > hosts have their own SSL cert, currently with FreeIPA I'm adding hosts for > each virtual host and then creating a cert. > > From what I've found, it doesn't seem to be possible to do a wildcard > ssl through FreeIPA, I tried exporting the ca root private key to manually > sign a wildcard cert with no success. I may have done that wrong. > > Any suggestions? > > > Is this what you are looking for? > https://fedorahosted.org/freeipa/ticket/3475 > > It is currently on a distant roadmap but help always welcome. > > > Thanks, > Andrew > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > Yeah. Is there any way of manually doing that now by pulling the root ca and key out to sign a cert? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Sep 16 00:38:53 2013 From: simo at redhat.com (Simo Sorce) Date: Sun, 15 Sep 2013 20:38:53 -0400 Subject: [Freeipa-users] Incorrect user information In-Reply-To: References: <5227465D.7020308@gmail.com> <841815955.7935136.1378306069557.JavaMail.root@redhat.com> <237193263.7936259.1378306160770.JavaMail.root@redhat.com> <52274F35.5090508@gmail.com> <20130904153134.GH22590@hendrix.brq.redhat.com> <52275C7A.3020800@gmail.com> <20130910113031.GG11028@hendrix.brq.redhat.com> <52336DA6.1020600@gmail.com> Message-ID: <1379291933.3902.2.camel@willson.li.ssimo.org> On Sat, 2013-09-14 at 13:11 -0400, Brian Lindblom wrote: > Of course, I would imagine that since the GECOS field is set upon > account creation based on the values provided for first and last name, > and since GECOS is not a provided field in the UI for user attributes, > that GECOS should be updated automatically to reflect those changes. > Bug perhaps? If gecos is set on creation but not updated it is a bug please open a ticket with the details. Thanks, Simo. > > On Fri, Sep 13, 2013 at 6:26 PM, Brian Lindblom wrote: > I've run into this exact same problem. Check the output of > > > ipa user-find --all > > > The GECOS field is probably set to the old information. You > can use > > > ipa user-mod --gecos="New Name" > > > to correct the issue. This solved it for me. > > > -Brian > > > On Fri, Sep 13, 2013 at 3:55 PM, cbulist at gmail.com > wrote: > > Hi Jakub, > > I attached the log files after doing the same test > that you requested me > before. > Please let me know if you need anything else. > > Thanks!! > > > > On 09/10/2013 06:30 AM, Jakub Hrozek wrote: > > > On Wed, Sep 04, 2013 at 11:14:50AM -0500, > cbulist at gmail.com wrote: > >> Hi Jakub, > >> > >> > >> Thanks for your time and tips about sssd cache! > >> > > I'm sorry about the late response, I didn't flag > your response when it > > came back.. > > > >> I did the test and let me explain what I got: > >> > >> - After step 4 I can see dataExpireTimestamp to 1 > for the user. > > OK, this is expected. > > > >> - After step 7 dataExpireTimestamp is back to 0 but > the user data have > >> not changed. > > This is really strange because if the > dataExpireTimestamp was reset > > after the lookup, then the backend has updated the > entry...and it should > > have updated the entry with the up-to-date data.. > > > > Can you put debug_level=8 into the [nss] and > [domain] sections > > and paste or attach the contents > of /var/log/sssd/sssd_nss.log and > > /var/log/sssd/sssd_$domain.log after the request > that follows the sss_cache > > run? > > > > Also in the logs you should see the server the SSSD > connects to, can you > > check if there is maybe some replica that is out of > sync? > > > > Unfortunately I can't reproduce the bug here.. > > > >> The first line after the command ldbsearch is: > >> > >> asq: Unable to register control with rootdse! > > No, that's an internal info, ignore this message. > > > >> Is it a problem? > >> > >> We are not using nscd service. > >> > >> Please let me know if you need to do some other > tests. > >> Thanks in advance! > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > Brian Lindblom (Smith) > Assistant Director > Research Computing, University of South Florida > 4202 E. Fowler Ave. SVC4010 > Office Phone: +1 813 974-1467 > Organization URL: http://rc.usf.edu > > > > > -- > Brian Lindblom (Smith) > Assistant Director > Research Computing, University of South Florida > 4202 E. Fowler Ave. SVC4010 > Office Phone: +1 813 974-1467 > Organization URL: http://rc.usf.edu > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York From shelltoesuperstar at gmail.com Mon Sep 16 09:21:40 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Mon, 16 Sep 2013 10:21:40 +0100 Subject: [Freeipa-users] IPA Query Tuning and a Recovery Question In-Reply-To: <523317DC.2050800@redhat.com> References: <522DF801.9050703@redhat.com> <523317DC.2050800@redhat.com> Message-ID: Hi Update on the errors kinit charlesd kinit: Generic error (see e-text) while getting initial credentials krb5kdc.log - LOOKING_UP_CLIENT: charlesd at EXAMPLE.COM for krbtg/ EXAMPLE.COM at EXAMPLE.COM, Server Error Starting the IPA service (dirsrv in particular) gives Failed to read data from Directory Service: Failed to get list of services to probe status! Configured hostname 'ipa3.example.com' doesn't match any master server in LDAP: No master found because of error: {'matched': dc=example,dc=com', 'desc': 'No such object'} Shutting down The errors log has a load of different services schema-compat-plugin. dna-plugin, ipalockout_preop/postop all complaining in one way or another about being unable to retrieve entries or no entries being set up. Cheers, Charlie On Fri, Sep 13, 2013 at 2:49 PM, Rich Megginson wrote: > On 09/12/2013 08:04 PM, Charlie Derwent wrote: > > > > On Mon, Sep 9, 2013 at 5:32 PM, Rich Megginson wrote: > >> On 09/09/2013 10:20 AM, Charlie Derwent wrote: >> >> Hi, >> >> 2 questions, some of our automation accounts are needlessly querying the >> IPA server every time they call a command via sudo. This is generating a >> lot of noise in our access logs. Is there any way to ensure certain system >> accounts don't call out to the IPA server for additional groups or sudo >> permission when completing tasks? >> >> >> What are your client platforms? Does sssd or newer versions of sudo >> cache? >> >> >> >> The other question is slightly more embarrassing, one of our guys saw >> /var filling and noticed that /var/lib/dirsrv/slapd-EXAMPLE-COM/db/ had a >> load of "log" files which looked like they weren't being tidied. >> >> >> They are automatically cleaned up. If you have a lot of updates, it may >> take longer. >> >> >> One stupid decision later and I'm now here asking on his behalf if >> there is anyway of restoring the database from a replica or is a complete >> rebuild required? >> >> >> Just reinit the replica using ipa-replica-manage. >> >> > I just tried to reinit the replica but I'm getting an error about failure > to connect to LDAP server I'm guessing that's because it's impossible for > me to kinit on the server now given the state of the DB. > > > It depends. What error? Can you provide the exact error message and/or > excerpts from /var/log/dirsrv/slapd-DOMAIN-COM/errors? > > > >> > >> > Second question is obviously a little bit more urgent than the first >> but any advice is greatly appreciated. >> >> Thanks, >> Charlie >> >> >> >> >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From meesvirk at outlook.com Mon Sep 16 10:05:48 2013 From: meesvirk at outlook.com (mees virk) Date: Mon, 16 Sep 2013 13:05:48 +0300 Subject: [Freeipa-users] Elliptic curves with the CA Message-ID: Hello all, Is it possible to setup the FreeIPA's CA use ECC cryptographic methods (ECDSA & co) instead of RSA? That includes generating ECC CA certificates, and so on. I don't think I was given any option towards this in the default installation process. Would appreciate instructions and/or pointers towards this. Also, can the default generated RSA CA switched later to ECC/ECDSA? Why doesn't the CA allow cross-signing (RSA/ECDSA hybrid keychains) certificates? It seems to validate the types, although it is not strictly forbidden as crypthographic practice (mostly just inconvenient, but it's legal). I gave the CA ECC CSR (generated by openSSL on one of the servers), and to my amazement it failed to sign it properly complaining about the type not being RSA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Sep 16 10:31:58 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 16 Sep 2013 12:31:58 +0200 Subject: [Freeipa-users] Incorrect user information In-Reply-To: References: <5227465D.7020308@gmail.com> <841815955.7935136.1378306069557.JavaMail.root@redhat.com> <237193263.7936259.1378306160770.JavaMail.root@redhat.com> <52274F35.5090508@gmail.com> <20130904153134.GH22590@hendrix.brq.redhat.com> <52275C7A.3020800@gmail.com> <20130910113031.GG11028@hendrix.brq.redhat.com> <52336DA6.1020600@gmail.com> Message-ID: <20130916103158.GJ28667@hendrix.brq.redhat.com> On Sat, Sep 14, 2013 at 01:11:36PM -0400, Brian Lindblom wrote: > Of course, I would imagine that since the GECOS field is set upon account > creation based on the values provided for first and last name, and since > GECOS is not a provided field in the UI for user attributes, that GECOS > should be updated automatically to reflect those changes. Bug perhaps? > You're right, I didn't realize that the reporter was modifying first and last name separately, I was under the assumption he had modified GECOS. Thanks for pointing that out. From tainsworth at vsi-corp.com Mon Sep 16 10:43:39 2013 From: tainsworth at vsi-corp.com (Ainsworth, Thomas) Date: Mon, 16 Sep 2013 06:43:39 -0400 Subject: [Freeipa-users] remove me from list Message-ID: please remove* tainsworth at vsi-corp.com* from the distro email list. Thanks, Tom Ainsworth -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Sep 16 11:13:05 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Sep 2013 13:13:05 +0200 Subject: [Freeipa-users] remove me from list In-Reply-To: References: Message-ID: <5236E7C1.5050600@redhat.com> On 09/16/2013 12:43 PM, Ainsworth, Thomas wrote: > please remove tainsworth at vsi-corp.com > from the distro email list. > > Thanks, > > Tom Ainsworth Hello, This list is managed by Mailman. You can unsubscribe yourself at https://www.redhat.com/mailman/listinfo/freeipa-users (bottom of the page), or by sending an e-mail to freeipa-users-leave at redhat.com -- Petr? From rcritten at redhat.com Mon Sep 16 12:44:15 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Sep 2013 08:44:15 -0400 Subject: [Freeipa-users] Date of last access attribute In-Reply-To: <52335635.6070505@redhat.com> References: <5232D7FD.6080509@cica.es> <52332619.2040501@redhat.com> <5233280A.2000202@redhat.com> <1379089571.2804.1991.camel@willson.li.ssimo.org> <52334F75.1090806@redhat.com> <52335635.6070505@redhat.com> Message-ID: <5236FD1F.1080409@redhat.com> Dmitri Pal wrote: > On 09/13/2013 01:46 PM, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Fri, 2013-09-13 at 10:58 -0400, Rob Crittenden wrote: >>>> Dmitri Pal wrote: >>>>> On 09/13/2013 05:16 AM, Marina Moreda wrote: >>>>>> Hi all, >>>>>> >>>>>> I need to add in my LDAP an attribute to save the date of last access >>>>>> to mail account, or something similar, to know when an user has >>>>>> stopped using his mail account. I can't find any attribute like this >>>>>> one. Any suggestions on how I can do this? >>>>>> >>>>>> Thanks so much. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-users mailing list >>>>>> Freeipa-users at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>> >>>>> I think there are some operational, i.e. "meta" attributes that store >>>>> information when some attribute was last modified so if there is a way >>>>> to associate mail activity with a modification of some user attribute >>>>> then you can check the time stamp of this modification rather than >>>>> create a separate attribute. With a new attribute the question comes: >>>>> who, when and how updates it and whether the software you have is >>>>> capable of doing it? May be software already updates something on >>>>> every >>>>> activity for the account and if this is the case then operation >>>>> attributes would help. >>>> >>>> There is no mail-specific activity attribute. I think about the closest >>>> you could get is last successful Kerberos authentication >>>> (krblastsuccessfulauth), but again this isn't specific to mail activity >>>> (unless that is all the users can do). >>>> >>>> Note too that this attribute is by default not replicated so if you >>>> have >>>> several IPA masters you'd need to check them all. This attribute not >>>> updated on LDAP binds. >>> >>> Rob, >>> should we open a ticket to update this for plain text binds too ? >>> >>> Simo. >> >> That's an interesting question. The attribute has krb in it which >> suggests a kerberos authentication, so I wonder if this would cause >> other confusion. > > Wasn't there an intent not to update data on a successful auth? Only on > a failure or first time after a failure to clear the counts? It certainly seems like an argument I'd make, but I don't recall specifically. rob From simo at redhat.com Mon Sep 16 13:35:21 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 16 Sep 2013 09:35:21 -0400 Subject: [Freeipa-users] Date of last access attribute In-Reply-To: <5236FD1F.1080409@redhat.com> References: <5232D7FD.6080509@cica.es> <52332619.2040501@redhat.com> <5233280A.2000202@redhat.com> <1379089571.2804.1991.camel@willson.li.ssimo.org> <52334F75.1090806@redhat.com> <52335635.6070505@redhat.com> <5236FD1F.1080409@redhat.com> Message-ID: <1379338521.3902.34.camel@willson.li.ssimo.org> On Mon, 2013-09-16 at 08:44 -0400, Rob Crittenden wrote: > Dmitri Pal wrote: > > On 09/13/2013 01:46 PM, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> On Fri, 2013-09-13 at 10:58 -0400, Rob Crittenden wrote: > >>>> Dmitri Pal wrote: > >>>>> On 09/13/2013 05:16 AM, Marina Moreda wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> I need to add in my LDAP an attribute to save the date of last access > >>>>>> to mail account, or something similar, to know when an user has > >>>>>> stopped using his mail account. I can't find any attribute like this > >>>>>> one. Any suggestions on how I can do this? > >>>>>> > >>>>>> Thanks so much. > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Freeipa-users mailing list > >>>>>> Freeipa-users at redhat.com > >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>>>> > >>>>> I think there are some operational, i.e. "meta" attributes that store > >>>>> information when some attribute was last modified so if there is a way > >>>>> to associate mail activity with a modification of some user attribute > >>>>> then you can check the time stamp of this modification rather than > >>>>> create a separate attribute. With a new attribute the question comes: > >>>>> who, when and how updates it and whether the software you have is > >>>>> capable of doing it? May be software already updates something on > >>>>> every > >>>>> activity for the account and if this is the case then operation > >>>>> attributes would help. > >>>> > >>>> There is no mail-specific activity attribute. I think about the closest > >>>> you could get is last successful Kerberos authentication > >>>> (krblastsuccessfulauth), but again this isn't specific to mail activity > >>>> (unless that is all the users can do). > >>>> > >>>> Note too that this attribute is by default not replicated so if you > >>>> have > >>>> several IPA masters you'd need to check them all. This attribute not > >>>> updated on LDAP binds. > >>> > >>> Rob, > >>> should we open a ticket to update this for plain text binds too ? > >>> > >>> Simo. > >> > >> That's an interesting question. The attribute has krb in it which > >> suggests a kerberos authentication, so I wonder if this would cause > >> other confusion. > > > > Wasn't there an intent not to update data on a successful auth? Only on > > a failure or first time after a failure to clear the counts? > > It certainly seems like an argument I'd make, but I don't recall > specifically. No, we need to update as it is used to unlock auto-locked accounts. What we decided on was to not propagate any of these operations via replication to avoid huge churn across all of the enterprise. Simo. -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Mon Sep 16 13:44:27 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 16 Sep 2013 07:44:27 -0600 Subject: [Freeipa-users] IPA Query Tuning and a Recovery Question In-Reply-To: References: <522DF801.9050703@redhat.com> <523317DC.2050800@redhat.com> Message-ID: <52370B3B.3000500@redhat.com> On 09/16/2013 03:21 AM, Charlie Derwent wrote: > Hi > Update on the errors > kinit charlesd > kinit: Generic error (see e-text) while getting initial credentials > krb5kdc.log - LOOKING_UP_CLIENT: charlesd at EXAMPLE.COM > for krbtg/EXAMPLE.COM at EXAMPLE.COM > , Server Error > Starting the IPA service (dirsrv in particular) gives > Failed to read data from Directory Service: Failed to get list of > services to probe status! > Configured hostname 'ipa3.example.com ' > doesn't match any master server in LDAP: > No master found because of error: {'matched': dc=example,dc=com', > 'desc': 'No such object'} > Shutting down > The errors log has a load of different services schema-compat-plugin. > dna-plugin, ipalockout_preop/postop all complaining in one way or > another about being unable to retrieve entries or no entries being set up. I think you'll have to use the workaround where you change replication to use simple bind in order to initialize the consumer, then switch back to sasl/gssapi. Simo/Rob - which ticket was this? Does freeipa.org have the workaround? > > Cheers, > Charlie > On Fri, Sep 13, 2013 at 2:49 PM, Rich Megginson > wrote: > > On 09/12/2013 08:04 PM, Charlie Derwent wrote: >> >> >> On Mon, Sep 9, 2013 at 5:32 PM, Rich Megginson >> > wrote: >> >> On 09/09/2013 10:20 AM, Charlie Derwent wrote: >>> Hi, >>> 2 questions, some of our automation accounts are needlessly >>> querying the IPA server every time they call a command via >>> sudo. This is generating a lot of noise in our access logs. >>> Is there any way to ensure certain system accounts don't >>> call out to the IPA server for additional groups or sudo >>> permission when completing tasks? >> >> What are your client platforms? Does sssd or newer versions >> of sudo cache? >> >> >>> The other question is slightly more embarrassing, one of our >>> guys saw /var filling and noticed that >>> /var/lib/dirsrv/slapd-EXAMPLE-COM/db/ had a load of "log" >>> files which looked like they weren't being tidied. >> >> They are automatically cleaned up. If you have a lot of >> updates, it may take longer. >> >> >>> One stupid decision later and I'm now here asking on his >>> behalf if there is anyway of restoring the database from a >>> replica or is a complete rebuild required? >> >> Just reinit the replica using ipa-replica-manage. >> >> I just tried to reinit the replica but I'm getting an error about >> failure to connect to LDAP server I'm guessing that's because >> it's impossible for me to kinit on the server now given the state >> of the DB. > > It depends. What error? Can you provide the exact error message > and/or excerpts from /var/log/dirsrv/slapd-DOMAIN-COM/errors? > > >>> Second question is obviously a little bit more urgent than >>> the first but any advice is greatly appreciated. >>> Thanks, >>> Charlie >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbulist at gmail.com Mon Sep 16 14:05:01 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Mon, 16 Sep 2013 09:05:01 -0500 Subject: [Freeipa-users] Incorrect user information In-Reply-To: <20130916103158.GJ28667@hendrix.brq.redhat.com> References: <5227465D.7020308@gmail.com> <841815955.7935136.1378306069557.JavaMail.root@redhat.com> <237193263.7936259.1378306160770.JavaMail.root@redhat.com> <52274F35.5090508@gmail.com> <20130904153134.GH22590@hendrix.brq.redhat.com> <52275C7A.3020800@gmail.com> <20130910113031.GG11028@hendrix.brq.redhat.com> <52336DA6.1020600@gmail.com> <20130916103158.GJ28667@hendrix.brq.redhat.com> Message-ID: <5237100D.2010806@gmail.com> Brian, Simo and Jakub, Thanks so much for your help. I will create a ticket for this problem. Thanks! On 09/16/2013 05:31 AM, Jakub Hrozek wrote: > On Sat, Sep 14, 2013 at 01:11:36PM -0400, Brian Lindblom wrote: >> Of course, I would imagine that since the GECOS field is set upon account >> creation based on the values provided for first and last name, and since >> GECOS is not a provided field in the UI for user attributes, that GECOS >> should be updated automatically to reflect those changes. Bug perhaps? >> > You're right, I didn't realize that the reporter was modifying first and > last name separately, I was under the assumption he had modified GECOS. > > Thanks for pointing that out. From rcritten at redhat.com Mon Sep 16 14:21:05 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Sep 2013 10:21:05 -0400 Subject: [Freeipa-users] IPA Query Tuning and a Recovery Question In-Reply-To: <52370B3B.3000500@redhat.com> References: <522DF801.9050703@redhat.com> <523317DC.2050800@redhat.com> <52370B3B.3000500@redhat.com> Message-ID: <523713D1.6050202@redhat.com> Rich Megginson wrote: > On 09/16/2013 03:21 AM, Charlie Derwent wrote: >> Hi >> Update on the errors >> kinit charlesd >> kinit: Generic error (see e-text) while getting initial credentials >> krb5kdc.log - LOOKING_UP_CLIENT: charlesd at EXAMPLE.COM >> for krbtg/EXAMPLE.COM at EXAMPLE.COM >> , Server Error >> Starting the IPA service (dirsrv in particular) gives >> Failed to read data from Directory Service: Failed to get list of >> services to probe status! >> Configured hostname 'ipa3.example.com ' >> doesn't match any master server in LDAP: >> No master found because of error: {'matched': dc=example,dc=com', >> 'desc': 'No such object'} >> Shutting down >> The errors log has a load of different services schema-compat-plugin. >> dna-plugin, ipalockout_preop/postop all complaining in one way or >> another about being unable to retrieve entries or no entries being set up. > > I think you'll have to use the workaround where you change replication > to use simple bind in order to initialize the consumer, then switch back > to sasl/gssapi. > > Simo/Rob - which ticket was this? Does freeipa.org have the workaround? http://freeipa.org/page/TroubleshootingGuide#Replica_Re-Initialization rob From sakodak at gmail.com Mon Sep 16 16:02:40 2013 From: sakodak at gmail.com (KodaK) Date: Mon, 16 Sep 2013 11:02:40 -0500 Subject: [Freeipa-users] Timeout (?) issues Message-ID: Yet another AIX related problem: The AIX LDAP client is called secldapclntd (sure, they could make it more awkward, but the budget ran out.) I'm running into the issue detailed here: http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 "If an LDAP server fails to answer an LDAP query, secldapclntd caches the non-answered query negatively. This may happen if the LDAP server is down for example. After the LDAP server is back again secldapclntd will use the negative cache entry and the application initiating the original query will still fail until the cache entry expires." IBM is working on porting the fix to our specific TL and SP levels. What I'm concerned with here, though, is *why* is it timing out? I don't know what the current timeout values are (AIX sucks, etc.) I don't see timeout issues on my Linux boxes, which leads me to believe that either the sssd timouts are longer or that sssd is just more robust when dealing with timeouts. I believe I'm seeing similar behavior with LDAP sudo on AIX as well, because I occasionally have to re-run sudo commands because they initially fail (and I know I'm using the right passwords.) However, sudo doesn't appear to have a cache (or it handles caching better.) Does anyone have any troubleshooting suggestions? Any general "speed things up" suggestions on the IPA side? Thanks, --Jason -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ovalousek at vendavo.com Mon Sep 16 16:04:49 2013 From: ovalousek at vendavo.com (Ondrej Valousek) Date: Mon, 16 Sep 2013 16:04:49 +0000 Subject: [Freeipa-users] IE or Firefox & Apache Kerberos authentication Message-ID: <1B2E2C093FF3B7459F3C605C42E4B5040B77D587@exmb1> Hi list, Is there any howto describing Firefox (or IE, if possible) authenticating against Apache web server using GSSAPI/Kerberos? Both client & server in the same IPA domain. Ideally I would like to know FF and Apache setup + compatibility info (i.e. does IE + IIS use the same thing or not) Many thanks for any hints. Ondrej -------------- next part -------------- An HTML attachment was scrubbed... URL: From chorn at fluxcoil.net Mon Sep 16 16:32:27 2013 From: chorn at fluxcoil.net (Christian Horn) Date: Mon, 16 Sep 2013 18:32:27 +0200 Subject: [Freeipa-users] IE or Firefox & Apache Kerberos authentication In-Reply-To: <1B2E2C093FF3B7459F3C605C42E4B5040B77D587@exmb1> References: <1B2E2C093FF3B7459F3C605C42E4B5040B77D587@exmb1> Message-ID: <20130916163227.GA16787@fluxcoil.net> Hi, On Mon, Sep 16, 2013 at 04:04:49PM +0000, Ondrej Valousek wrote: > Is there any howto describing Firefox (or IE, if possible) authenticating against Apache web server using GSSAPI/Kerberos? > Both client & server in the same IPA domain. > Ideally I would like to know FF and Apache setup + compatibility info (i.e. does IE + IIS use the same thing or not) Not aware of a "includes all"-guide, but would start here: - adding the HTTP service principal: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#adding-service-entry-cmd http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/managing-services.html#adding-service-entry - when you host multiple kerberized sites on the server (access required a Red Hat subscription): https://access.redhat.com/site/solutions/206623 - apache side config: http://modauthkerb.sourceforge.net/configure.html - firefox client side config: http://www.grolmsnet.de/kerbtut/firefox.html Christian From ovalousek at vendavo.com Mon Sep 16 17:04:19 2013 From: ovalousek at vendavo.com (Ondrej Valousek) Date: Mon, 16 Sep 2013 17:04:19 +0000 Subject: [Freeipa-users] IE or Firefox & Apache Kerberos authentication In-Reply-To: <20130916163227.GA16787@fluxcoil.net> References: <1B2E2C093FF3B7459F3C605C42E4B5040B77D587@exmb1>, <20130916163227.GA16787@fluxcoil.net> Message-ID: Thanks, Is the article about http principals for apache still relevant? I would guess that with gss-proxy (F19) it is much simpler. Ondrej Odesl?no ze Samsung Mobile -------- P?vodn? zpr?va -------- Od: Christian Horn Datum: Komu: freeipa-users at redhat.com P?edm?t: Re: [Freeipa-users] IE or Firefox & Apache Kerberos authentication Hi, On Mon, Sep 16, 2013 at 04:04:49PM +0000, Ondrej Valousek wrote: > Is there any howto describing Firefox (or IE, if possible) authenticating against Apache web server using GSSAPI/Kerberos? > Both client & server in the same IPA domain. > Ideally I would like to know FF and Apache setup + compatibility info (i.e. does IE + IIS use the same thing or not) Not aware of a "includes all"-guide, but would start here: - adding the HTTP service principal: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#adding-service-entry-cmd http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/managing-services.html#adding-service-entry - when you host multiple kerberized sites on the server (access required a Red Hat subscription): https://access.redhat.com/site/solutions/206623 - apache side config: http://modauthkerb.sourceforge.net/configure.html - firefox client side config: http://www.grolmsnet.de/kerbtut/firefox.html Christian _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Sep 16 17:46:09 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 16 Sep 2013 13:46:09 -0400 Subject: [Freeipa-users] IE or Firefox & Apache Kerberos authentication In-Reply-To: References: <1B2E2C093FF3B7459F3C605C42E4B5040B77D587@exmb1> , <20130916163227.GA16787@fluxcoil.net> Message-ID: <1379353569.3902.55.camel@willson.li.ssimo.org> On Mon, 2013-09-16 at 17:04 +0000, Ondrej Valousek wrote: > Thanks, > Is the article about http principals for apache still relevant? > I would guess that with gss-proxy (F19) it is much simpler. You still need a princiapl and a keytab yes. Here instructions if you want to use iot with GSS-Proxy: https://fedorahosted.org/gss-proxy/wiki/Apache HTH, Simo. > Ondrej > > > > > Odesl?no ze Samsung Mobile > > > > -------- P?vodn? zpr?va -------- > Od: Christian Horn > Datum: > Komu: freeipa-users at redhat.com > P?edm?t: Re: [Freeipa-users] IE or Firefox & Apache Kerberos > authentication > > > > > Hi, > > On Mon, Sep 16, 2013 at 04:04:49PM +0000, Ondrej Valousek wrote: > > Is there any howto describing Firefox (or IE, if possible) > authenticating against Apache web server using GSSAPI/Kerberos? > > Both client & server in the same IPA domain. > > Ideally I would like to know FF and Apache setup + compatibility > info (i.e. does IE + IIS use the same thing or not) > > Not aware of a "includes all"-guide, but would start here: > > - adding the HTTP service principal: > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#adding-service-entry-cmd > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/managing-services.html#adding-service-entry > - when you host multiple kerberized sites on the server > (access required a Red Hat subscription): > https://access.redhat.com/site/solutions/206623 > - apache side config: > http://modauthkerb.sourceforge.net/configure.html > - firefox client side config: > http://www.grolmsnet.de/kerbtut/firefox.html > > > Christian > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York From ovalousek at vendavo.com Mon Sep 16 18:35:31 2013 From: ovalousek at vendavo.com (Ondrej Valousek) Date: Mon, 16 Sep 2013 18:35:31 +0000 Subject: [Freeipa-users] IE or Firefox & Apache Kerberos authentication In-Reply-To: <1379353569.3902.55.camel@willson.li.ssimo.org> References: <1B2E2C093FF3B7459F3C605C42E4B5040B77D587@exmb1> , <20130916163227.GA16787@fluxcoil.net> , <1379353569.3902.55.camel@willson.li.ssimo.org> Message-ID: Thanks, I hoped that with gssproxy I could use a single central /etc/krb5.keytab (with all necessary principals) for nfs, apache, dhcpd,... and not worrying about file permissions. The beauty would be saved work with copying principals to separate files. Is it true? Ondrej Odesl?no ze Samsung Mobile -------- P?vodn? zpr?va -------- Od: Simo Sorce Datum: Komu: Ondrej Valousek Kopie: chorn at fluxcoil.net,freeipa-users at redhat.com P?edm?t: Re: [Freeipa-users] IE or Firefox & Apache Kerberos authentication On Mon, 2013-09-16 at 17:04 +0000, Ondrej Valousek wrote: > Thanks, > Is the article about http principals for apache still relevant? > I would guess that with gss-proxy (F19) it is much simpler. You still need a princiapl and a keytab yes. Here instructions if you want to use iot with GSS-Proxy: https://fedorahosted.org/gss-proxy/wiki/Apache HTH, Simo. > Ondrej > > > > > Odesl?no ze Samsung Mobile > > > > -------- P?vodn? zpr?va -------- > Od: Christian Horn > Datum: > Komu: freeipa-users at redhat.com > P?edm?t: Re: [Freeipa-users] IE or Firefox & Apache Kerberos > authentication > > > > > Hi, > > On Mon, Sep 16, 2013 at 04:04:49PM +0000, Ondrej Valousek wrote: > > Is there any howto describing Firefox (or IE, if possible) > authenticating against Apache web server using GSSAPI/Kerberos? > > Both client & server in the same IPA domain. > > Ideally I would like to know FF and Apache setup + compatibility > info (i.e. does IE + IIS use the same thing or not) > > Not aware of a "includes all"-guide, but would start here: > > - adding the HTTP service principal: > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#adding-service-entry-cmd > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/managing-services.html#adding-service-entry > - when you host multiple kerberized sites on the server > (access required a Red Hat subscription): > https://access.redhat.com/site/solutions/206623 > - apache side config: > http://modauthkerb.sourceforge.net/configure.html > - firefox client side config: > http://www.grolmsnet.de/kerbtut/firefox.html > > > Christian > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Sep 16 18:46:36 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 16 Sep 2013 14:46:36 -0400 Subject: [Freeipa-users] IE or Firefox & Apache Kerberos authentication In-Reply-To: References: <1B2E2C093FF3B7459F3C605C42E4B5040B77D587@exmb1> , <20130916163227.GA16787@fluxcoil.net> ,<1379353569.3902.55.camel@willson.li.ssimo.org> Message-ID: <1379357196.3902.61.camel@willson.li.ssimo.org> On Mon, 2013-09-16 at 18:35 +0000, Ondrej Valousek wrote: > Thanks, > I hoped that with gssproxy I could use a single > central /etc/krb5.keytab (with all necessary principals) for nfs, > apache, dhcpd,... and not worrying about file permissions. > The beauty would be saved work with copying principals to separate > files. > Is it true? Yes, you can keep the principal's keys wherever you want with gssproxy, although I would personally still use separate keytabs for ease of management should you need to change just one set of keys. Simo. > Ondrej > > > > > Odesl?no ze Samsung Mobile > > > > -------- P?vodn? zpr?va -------- > Od: Simo Sorce > Datum: > Komu: Ondrej Valousek > Kopie: chorn at fluxcoil.net,freeipa-users at redhat.com > P?edm?t: Re: [Freeipa-users] IE or Firefox & Apache Kerberos > authentication > > > > On Mon, 2013-09-16 at 17:04 +0000, Ondrej Valousek wrote: > > Thanks, > > Is the article about http principals for apache still relevant? > > I would guess that with gss-proxy (F19) it is much simpler. > > You still need a princiapl and a keytab yes. > > Here instructions if you want to use iot with GSS-Proxy: > > https://fedorahosted.org/gss-proxy/wiki/Apache > > > HTH, > Simo. > > > Ondrej > > > > > > > > > > Odesl?no ze Samsung Mobile > > > > > > > > -------- P?vodn? zpr?va -------- > > Od: Christian Horn > > Datum: > > Komu: freeipa-users at redhat.com > > P?edm?t: Re: [Freeipa-users] IE or Firefox & Apache Kerberos > > authentication > > > > > > > > > > Hi, > > > > On Mon, Sep 16, 2013 at 04:04:49PM +0000, Ondrej Valousek wrote: > > > Is there any howto describing Firefox (or IE, if possible) > > authenticating against Apache web server using GSSAPI/Kerberos? > > > Both client & server in the same IPA domain. > > > Ideally I would like to know FF and Apache setup + compatibility > > info (i.e. does IE + IIS use the same thing or not) > > > > Not aware of a "includes all"-guide, but would start here: > > > > - adding the HTTP service principal: > > > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#adding-service-entry-cmd > > > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/managing-services.html#adding-service-entry > > - when you host multiple kerberized sites on the server > > (access required a Red Hat subscription): > > https://access.redhat.com/site/solutions/206623 > > - apache side config: > > http://modauthkerb.sourceforge.net/configure.html > > - firefox client side config: > > http://www.grolmsnet.de/kerbtut/firefox.html > > > > > > Christian > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Simo Sorce * Red Hat, Inc * New York > > -- Simo Sorce * Red Hat, Inc * New York From christovamps at gmail.com Mon Sep 16 19:05:09 2013 From: christovamps at gmail.com (Christovam Paynes Silva) Date: Mon, 16 Sep 2013 16:05:09 -0300 Subject: [Freeipa-users] FreeIPA integrating samba4 + AD In-Reply-To: <523209F4.7080100@redhat.com> References: <1378927682.2804.1708.camel@willson.li.ssimo.org> <1378929566.2804.1745.camel@willson.li.ssimo.org> <5230DEDC.9080207@redhat.com> <523209F4.7080100@redhat.com> Message-ID: 2013/9/12 Dmitri Pal > On 09/11/2013 11:27 PM, Christovam Paynes Silva wrote: > > > > > 2013/9/11 Dmitri Pal > >> On 09/11/2013 04:02 PM, Christovam Paynes Silva wrote: >> >> It is a pity! >> Thank you! >> >> >> >> >> I did not get a feeling that we understand the whole picture correctly >> to say that we provided the full answer.. >> >> What I get from the description: >> 1) Presence of Windows Clients = 100 >> > > Correct! > > >> 2) Presence of AD to rule them >> > > Correct! > > 3) Presence of users (I deduce in AD too, but unclear) = 1000 >> > > Correct! Users are wirelessly. Use windows and linux without domain. > > >> Intent: use open source technologies instead of proprietary solution. >> > > That's right! > > >> >> What is not clear: >> a) Are the users that come through the portal the same users that use >> Windows Clients or not? Is there an overlap? >> > > Users are via wireless. Authenticate users on a "captive portal" with > Squid. Customers are windows, linux and without domain. > > >> b) Is there any kind of Linux servers/machines in the picture? >> > > This question was not clear to me. > > > FreeIPA is a domain controller for Linux/UNIX systems. It main value it to > manage Linux environment inside your enterprise. It can manage users and > groups too as any directory can. It can also authenticate users but its > value is in creating a integrated Linux environment in terms of identity > management. It seems that the setup you have does not actually have such > Linux environment, i.e. Linux machines to join to IPA domain and manage. > The question was: "Do you have Linux systems to manage?". > > > I have 5 servers. But that's just me working on them. I believe we do not need the IPA. I appreciate the attention. Thank you. > > >> >> If you do not have Linux systems and all users can be stored in one place >> it might be that you do not need FreeIPA. It might be that you can solve >> the problem by using Samba4 instead of AD, connecting your clients to it, >> putting your external portal users into a special OU in Samba4, configuring >> FreeRADIUS to use this OU for authentication. Configure your portal to use >> RADIUS. >> > > > Sorry, I may not have understood the concept of FreeIPA. > > I would like to continue using the AD, because of Group Policy Objects > (GPO). > > > You need to check whether Samba 4 supports GPO and to what extent. > > http://wiki.samba.org/index.php/FAQ#Is_it_possible_to_set_user_specific_password_policies_in_Samba4_.28e._g._on_a_OU-base.29.3F > > > It has the ability to authenticate email services, applications, among > others directly in Samba4? > > > Yes as with any LDAP server but if you are planning to use AD than you do > not need Samba 4 either. > You then point your mail service and applications to AD directly. > Most of modern applications have some sort of LDAP integration for > identity lookup and authentication. That means you would be able to point > them to prety much any directory: AD, Samba4, IPA, 389 ... > > > > > > > >> >> HTH >> >> Thanks >> Dmitri >> >> >> >> >> >> 2013/9/11 Simo Sorce >> >>> On Wed, 2013-09-11 at 16:37 -0300, Christovam Paynes Silva wrote: >>> > Hello Simo, thanks for the feedback. >>> > I would use the Samba4 with AD and authenticate my clients windows in >>> > FreeIPA. >>> > Is this possible? >>> >>> It is not possible at this point to combine Samba4 AD and freeIPA. >>> >>> Simo. >>> > >>> > 2013/9/11 Simo Sorce >>> > On Wed, 2013-09-11 at 14:06 -0300, Christovam Paynes Silva >>> > wrote: >>> > > Hello! >>> > > >>> > > >>> > > First I apologize if this topic is redundant. >>> > > >>> > > >>> > > I'm looking on the implementation of FreeIPA . Looking for >>> > the >>> > > forums , have some comments that authentication does not >>> > work with >>> > > Samba4 . Elsewhere say that that possibility exists . Today >>> > we have >>> > > nearly 200 computers in the domain with the "Active >>> > Directory" and one >>> > > wireless "captive portal" with 1000 + proxy users . >>> > > >>> > > I would like to see if the following scenario is possible : >>> > > 1 - Integrating Samba4 with "Active Directory" , to use >>> > their GPO and >>> > > authenticate network users through the FreeIPA . >>> > > 2 - Authenticate proxy servers in FreeIPA . >>> > > 3 - And if it is possible some integration with FreeRADIUS >>> > > >>> > >>> > >>> > Hi Christovam, it is a bit unclear what you mean by >>> > integrating here. >>> > >>> > Is your intent to use Samba4 as an AD domain controller for >>> > your Windows >>> > client s and IPA for your servers ? >>> > >>> > If that's the case unfortunately this is not possible at the >>> > moment as >>> > samba4 does not yet support Forest level trusts. >>> > A Microsoft AD server can be used this way instead. >>> > >>> > Simo. >>> > >>> > -- >>> > Simo Sorce * Red Hat, Inc * New York >>> > >>> > >>> > >>> >>> >>> -- >>> Simo Sorce * Red Hat, Inc * New York >>> >>> >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs?www.redhat.com/carveoutcosts/ >> >> > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Sep 16 20:53:58 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 16 Sep 2013 16:53:58 -0400 Subject: [Freeipa-users] Elliptic curves with the CA In-Reply-To: References: Message-ID: <1379364838.3902.63.camel@willson.li.ssimo.org> On Mon, 2013-09-16 at 13:05 +0300, mees virk wrote: > Hello all, > > Is it possible to setup the FreeIPA's CA use ECC cryptographic > methods (ECDSA & co) instead of RSA? That includes generating ECC CA > certificates, and so on. At the moment our code (dogtag and nss) does not support ECC crypto. I will let Dogtag developers chime in fopr when they plan to introduce ECC based crypto in the codebase. Simo. > I don't think I was given any option towards this in the default > installation process. Would appreciate instructions and/or pointers > towards this. > > Also, can the default generated RSA CA switched later to ECC/ECDSA? > > Why doesn't the CA allow cross-signing (RSA/ECDSA hybrid keychains) > certificates? It seems to validate the types, although it is not > strictly forbidden as crypthographic practice (mostly just > inconvenient, but it's legal). I gave the CA ECC CSR (generated by > openSSL on one of the servers), and to my amazement it failed to sign > it properly complaining about the type not being RSA. > -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Sep 17 01:49:12 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 16 Sep 2013 21:49:12 -0400 Subject: [Freeipa-users] Elliptic curves with the CA In-Reply-To: References: Message-ID: <5237B518.6060808@redhat.com> On 09/16/2013 06:05 AM, mees virk wrote: > Hello all, > > Is it possible to setup the FreeIPA's CA use ECC cryptographic > methods (ECDSA & co) instead of RSA? That includes generating ECC CA > certificates, and so on. > > I don't think I was given any option towards this in the default > installation process. Would appreciate instructions and/or pointers > towards this. > > Also, can the default generated RSA CA switched later to ECC/ECDSA? > > Why doesn't the CA allow cross-signing (RSA/ECDSA hybrid keychains) > certificates? It seems to validate the types, although it is not > strictly forbidden as crypthographic practice (mostly just > inconvenient, but it's legal). I gave the CA ECC CSR (generated by > openSSL on one of the servers), and to my amazement it failed to sign > it properly complaining about the type not being RSA. > IPA uses NSS, NSS support of ECC algorithms is very fresh, we have not looked at this area yet. I suspect it would require changes in Dogtag first. Would be best if you can file and RFE ticket, then we would be able to follow up. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Sep 17 01:57:30 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 16 Sep 2013 21:57:30 -0400 Subject: [Freeipa-users] Timeout (?) issues In-Reply-To: References: Message-ID: <5237B70A.5050307@redhat.com> On 09/16/2013 12:02 PM, KodaK wrote: > Yet another AIX related problem: > > The AIX LDAP client is called secldapclntd (sure, they could make it > more awkward, but the budget ran out.) I'm running into the issue > detailed here: > > http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 > > "If an LDAP server fails to answer an LDAP query, secldapclntd caches > the non-answered query negatively. This may happen if the LDAP server > is down for example. After the LDAP server is back > again secldapclntd will use the negative cache entry and the > application initiating the original query will still fail until the > cache entry expires." > > IBM is working on porting the fix to our specific TL and SP levels. > > What I'm concerned with here, though, is *why* is it timing out? I > don't know what the current timeout values are (AIX sucks, etc.) > > I don't see timeout issues on my Linux boxes, which leads me to > believe that either the sssd timouts are longer or that sssd is just > more robust when dealing with timeouts. > > I believe I'm seeing similar behavior with LDAP sudo on AIX as well, > because I occasionally have to re-run sudo commands because they > initially fail (and I know I'm using the right passwords.) However, > sudo doesn't appear to have a cache (or it handles caching better.) > > Does anyone have any troubleshooting suggestions? Any general "speed > things up" suggestions on the IPA side? > > Thanks, > > --Jason > > -- > The government is going to read our mail anyway, might as well make it > tough for them. GPG Public key ID: B6A1A7C6 > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users Is the server FreeIPA? Can see in the server logs what is actually happening is it the server that really takes time or there is a network connectivity issue or FW is dropping packets? I would really start with the server side logs. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aborrero at cica.es Tue Sep 17 07:18:00 2013 From: aborrero at cica.es (Arturo Borrero) Date: Tue, 17 Sep 2013 09:18:00 +0200 Subject: [Freeipa-users] Date of last access attribute In-Reply-To: <1379338521.3902.34.camel@willson.li.ssimo.org> References: <5232D7FD.6080509@cica.es> <52332619.2040501@redhat.com> <5233280A.2000202@redhat.com> <1379089571.2804.1991.camel@willson.li.ssimo.org> <52334F75.1090806@redhat.com> <52335635.6070505@redhat.com> <5236FD1F.1080409@redhat.com> <1379338521.3902.34.camel@willson.li.ssimo.org> Message-ID: <52380228.4070104@cica.es> On 16/09/13 15:35, Simo Sorce wrote: > > No, we need to update as it is used to unlock auto-locked accounts. What > we decided on was to not propagate any of these operations via > replication to avoid huge churn across all of the enterprise. > > Simo. > The underlying issue is: with a large scale userbase, some method is needed to know about inactive user accounts. Users that don't send/recv mails, users that don't bind/kinit, whatever.. * some kind of attribute is needed to store when was the last activity. * activity would mean a kerberos auth or ldap bind, or an attribute modification. * this last time info needs to be replicated. This way, a policy like 'purge accounts inactive by 1 year' can be implemented. Or even get a sorted list of user by inactivity time. I think this is a very nice functionality that FreeIPA should have. Best regards. -- Arturo Borrero Gonz?lez Departamento de Seguridad Inform?tica (nis at cica.es) Centro Inform?tico Cient?fico de Andaluc?a (CICA) Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain) Tfno.: +34 955 056 600 / FAX: +34 955 056 650 Consejer?a de Econom?a, Innovaci?n, Ciencia y Empleo Junta de Andaluc?a -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3072 bytes Desc: S/MIME Cryptographic Signature URL: From pspacek at redhat.com Tue Sep 17 08:38:45 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 17 Sep 2013 10:38:45 +0200 Subject: [Freeipa-users] Date of last access attribute In-Reply-To: <52380228.4070104@cica.es> References: <5232D7FD.6080509@cica.es> <52332619.2040501@redhat.com> <5233280A.2000202@redhat.com> <1379089571.2804.1991.camel@willson.li.ssimo.org> <52334F75.1090806@redhat.com> <52335635.6070505@redhat.com> <5236FD1F.1080409@redhat.com> <1379338521.3902.34.camel@willson.li.ssimo.org> <52380228.4070104@cica.es> Message-ID: <52381515.9090102@redhat.com> On 17.9.2013 09:18, Arturo Borrero wrote: > On 16/09/13 15:35, Simo Sorce wrote: >> >> No, we need to update as it is used to unlock auto-locked accounts. What >> we decided on was to not propagate any of these operations via >> replication to avoid huge churn across all of the enterprise. >> >> Simo. >> > > The underlying issue is: with a large scale userbase, some method is needed to > know about inactive user accounts. > Users that don't send/recv mails, users that don't bind/kinit, whatever.. > > * some kind of attribute is needed to store when was the last activity. > * activity would mean a kerberos auth or ldap bind, or an attribute > modification. > * this last time info needs to be replicated. > > This way, a policy like 'purge accounts inactive by 1 year' can be implemented. > Or even get a sorted list of user by inactivity time. > > I think this is a very nice functionality that FreeIPA should have. Interesting idea, but it needs careful design not to omit any possible case. Please create RFE ticket (request for enhancement): https://fedorahosted.org/freeipa/newticket You will need an Fedora Account, please follow this: https://fedoraproject.org/wiki/Account_System/NewAccount Workaround for now is to read attributes krbLastSuccessfulAuth & lastLoginTime from all replicas and use highest value. Simple script with ldapsearch could work. -- Petr^2 Spacek From aborrero at cica.es Tue Sep 17 09:02:07 2013 From: aborrero at cica.es (Arturo Borrero) Date: Tue, 17 Sep 2013 11:02:07 +0200 Subject: [Freeipa-users] Date of last access attribute In-Reply-To: <52381515.9090102@redhat.com> References: <5232D7FD.6080509@cica.es> <52332619.2040501@redhat.com> <5233280A.2000202@redhat.com> <1379089571.2804.1991.camel@willson.li.ssimo.org> <52334F75.1090806@redhat.com> <52335635.6070505@redhat.com> <5236FD1F.1080409@redhat.com> <1379338521.3902.34.camel@willson.li.ssimo.org> <52380228.4070104@cica.es> <52381515.9090102@redhat.com> Message-ID: <52381A8F.7060208@cica.es> On 17/09/13 10:38, Petr Spacek wrote: > > Interesting idea, but it needs careful design not to omit any possible > case. > > Please create RFE ticket (request for enhancement): > https://fedorahosted.org/freeipa/newticket > > You will need an Fedora Account, please follow this: > https://fedoraproject.org/wiki/Account_System/NewAccount > > > Workaround for now is to read attributes krbLastSuccessfulAuth & > lastLoginTime from all replicas and use highest value. Simple script > with ldapsearch could work. > I created the ticket: https://fedorahosted.org/freeipa/ticket/3933 Best regards. -- Arturo Borrero Gonz?lez Departamento de Seguridad Inform?tica (nis at cica.es) Centro Inform?tico Cient?fico de Andaluc?a (CICA) Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain) Tfno.: +34 955 056 600 / FAX: +34 955 056 650 Consejer?a de Econom?a, Innovaci?n, Ciencia y Empleo Junta de Andaluc?a -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3072 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Sep 17 14:01:39 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 17 Sep 2013 08:01:39 -0600 Subject: [Freeipa-users] Timeout (?) issues In-Reply-To: <5237B70A.5050307@redhat.com> References: <5237B70A.5050307@redhat.com> Message-ID: <523860C3.5050206@redhat.com> On 09/16/2013 07:57 PM, Dmitri Pal wrote: > On 09/16/2013 12:02 PM, KodaK wrote: >> Yet another AIX related problem: >> >> The AIX LDAP client is called secldapclntd (sure, they could make it >> more awkward, but the budget ran out.) I'm running into the issue >> detailed here: >> >> http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 >> >> "If an LDAP server fails to answer an LDAP query, secldapclntd caches >> the non-answered query negatively. This may happen if the LDAP server >> is down for example. After the LDAP server is back again secldapclntd >> will use the negative cache entry and the application initiating the >> original query will still fail until the cache entry expires." >> >> IBM is working on porting the fix to our specific TL and SP levels. >> >> What I'm concerned with here, though, is *why* is it timing out? I >> don't know what the current timeout values are (AIX sucks, etc.) >> >> I don't see timeout issues on my Linux boxes, which leads me to >> believe that either the sssd timouts are longer or that sssd is just >> more robust when dealing with timeouts. >> >> I believe I'm seeing similar behavior with LDAP sudo on AIX as well, >> because I occasionally have to re-run sudo commands because they >> initially fail (and I know I'm using the right passwords.) However, >> sudo doesn't appear to have a cache (or it handles caching better.) >> >> Does anyone have any troubleshooting suggestions? Any general "speed >> things up" suggestions on the IPA side? >> >> Thanks, >> >> --Jason >> >> -- >> The government is going to read our mail anyway, might as well make >> it tough for them. GPG Public key ID: B6A1A7C6 >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > Is the server FreeIPA? > Can see in the server logs what is actually happening is it the server > that really takes time or there is a network connectivity issue or FW > is dropping packets? > I would really start with the server side logs. As far as 389 goes, run logconv.pl against the access logs in /var/log/dirsrv/slapd-DOMAIN-COM > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From trevor.t.kates at dom.com Tue Sep 17 19:40:28 2013 From: trevor.t.kates at dom.com (Trevor T Kates (Services - 6)) Date: Tue, 17 Sep 2013 19:40:28 +0000 Subject: [Freeipa-users] Replica of a Replica and Master Recovery In-Reply-To: References: Message-ID: I apologize for the weird subject. The problem I'm facing feels a little weird and I could use some help. I'm running IPA in a test environment and trying to find different ways in which I can break it and then repair it. My IPA is running on CentOS 6.4: Linux ipa00.testdomain.com 2.6.32-358.18.1.el6.x86_64 #1 SMP Wed Aug 28 17:19:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux bind-9.8.2-0.17.rc1.el6_4.6.x86_64 bind-dyndb-ldap-2.3-2.el6_4.1.x86_64 ipa-server-3.0.0-26.el6_4.4.x86_64 I seem to have created a problem for myself involving the original master server. At the beginning, I created a master IPA server with the dogtag CA and several replicas with replica dogtag CAs. I stored the /root/cacert.p12 file in a backup, reimaged the original master and turned it into a replica. In doing so, I seem to have eliminated my ability to create additional replicas due to not completely backing up everything related to the CA on the master. After preparing a replica on my reimaged master and attemping to install it on a different test server, I ran into the following error: [root at ipa04 ~]# ipa-replica-install --setup-ca -N --setup-dns /var/lib/ipa/replica-info-ipa04.testdomain.com.gpg Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'ipa00.testdomain.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK PKI-CA: Directory Service port (7389): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master admin at TESTDOMAIN.COM password: Execute check on remote master admin at ipa00.testdomain.com's password: Check connection from master to remote replica 'ipa04.testdomain.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK PKI-CA: Directory Service port (7389): OK Connection from master to replica is OK. Connection check OK Configuring directory server for the CA (pkids): Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server Done configuring directory server for the CA (pkids). Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds [1/17]: creating certificate server user [2/17]: creating pki-ca instance [3/17]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ipa04.testdomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-krRAM2 -client_certdb_pwd XXXXXXXX -preop_pin 2e3Wsf8VDR8lEXLi3HyX -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=TESTDOMAIN.COM -ldap_host ipa04.testdomain.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=TESTDOMAIN.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=TESTDOMAIN.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=TESTDOMAIN.COM -ca_server_cert_subject_name CN=ipa04.testdomain.com,O=TESTDOMAIN.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=TESTDOMAIN.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=TESTDOMAIN.COM -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname ipa00.testdomain.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true -clone_uri https://ipa00.testdomain.com:443' returned non-zero exit status 255 Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed ___ /var/log/ipareplica-install.log: ############################################# Attempting to connect to: ipa04.testdomain.com:9445 Connected. Posting Query = https://ipa04.testdomain.com:9445//ca/admin/console/config/wi zard?p=5&subsystem=CA&session_id=-4262354986382644304&xml=true RESPONSE STATUS: HTTP/1.1 200 OK RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 RESPONSE HEADER: Date: Tue, 17 Sep 2013 17:49:16 GMT RESPONSE HEADER: Connection: close Exception in SecurityDomainLoginPanel(): java.lang.Exception: Invalid clone_uri ERROR: ConfigureSubCA: SecurityDomainLoginPanel() failure ERROR: unable to create CA ####################################################################### 2013-09-17T17:49:17Z DEBUG stderr=java.lang.Exception: Invalid clone_uri at ConfigureCA.SecurityDomainLoginPanel(ConfigureCA.java:392) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1188) at ConfigureCA.main(ConfigureCA.java:1672) 2013-09-17T17:49:17Z CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname ipa04.testdomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-krRAM2 -client_certdb_pwd XXXXXXXX -preop_pin 2e3Wsf8VDR8lEXLi3HyX -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=VANCPOWER.COM -ldap_host ipa04.testdomain.com -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=VANCPOWER.COM -ca_subsystem_cert_subject_name CN=CA Subsystem,O=VANCPOWER.COM -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=VANCPOWER.COM -ca_server_cert_subject_name CN=ipa04.testdomain.com,O=VANCPOWER.COM -ca_audit_signing_cert_subject_name CN=CA Audit,O=VANCPOWER.COM -ca_sign_cert_subject_name CN=Certificate Authority,O=VANCPOWER.COM -external false -clone true -clone_p12_file ca.p12 -clone_p12_password XXXXXXXX -sd_hostname ipa00.testdomain.com -sd_admin_port 443 -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true -clone_uri https://ipa00.testdomain.com:443' returned non-zero exit status 255 2013-09-17T17:49:17Z INFO File "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", line 614, in run_script return_value = main_function() File "/usr/sbin/ipa-replica-install", line 467, in main (CA, cs) = cainstance.install_replica_ca(config) File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 1604, in install_replica_ca subject_base=config.subject_base) File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 617, in configure_instance self.start_creation(runtime=210) File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", line 358, in start_creation method() File "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line 879, in __configure_instance raise RuntimeError('Configuration of CA failed') 2013-09-17T17:49:17Z INFO The ipa-replica-install command failed, exception: RuntimeError: Configuration of CA failed ___ In the event that there is no recovery from this short of rebuilding the master, is there a way for me to repopulate it with existing data from the name server and user store? As always, your help is greatly appreciated. Thanks. Trevor T. Kates CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aborrero at cica.es Wed Sep 18 11:40:16 2013 From: aborrero at cica.es (Arturo Borrero) Date: Wed, 18 Sep 2013 13:40:16 +0200 Subject: [Freeipa-users] Recomendations on multi-domain environments Message-ID: <52399120.1070804@cica.es> Hi there! This is my situation. I have some users of my main domain "cica.es". But I also maintain a database of users of others domain, ie "example.es". I can apply most of FreeIPA configuration to "cica.es" users: access to hosts, groups, policies, roles, etc.. But users of "example.es" are dummy users, who just have an LDAP account in order to use virtual mailboxes in Postfix/Dovecot. Do anyone have any advice on how handle this situation? I see some options: * create a second FreeIPA server, each to handle his own domain. * get the main FreeIPA server to handle two complete different LDAP tree (with different root DNs, don't know if possible). * integrate "example.es" users into specific groups, "prefix" or something each group and user. We are talking of about 2k users in total (main domain + secondary domain). In addition, there is the possibility to have more than two domains. How FreeIPA handles this multi-domain environment? Best regards. -- Arturo Borrero Gonz?lez Departamento de Seguridad Inform?tica (nis at cica.es) Centro Inform?tico Cient?fico de Andaluc?a (CICA) Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain) Tfno.: +34 955 056 600 / FAX: +34 955 056 650 Consejer?a de Econom?a, Innovaci?n, Ciencia y Empleo Junta de Andaluc?a -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3072 bytes Desc: S/MIME Cryptographic Signature URL: From andrew at andrewklau.com Wed Sep 18 11:55:36 2013 From: andrew at andrewklau.com (Andrew Lau) Date: Wed, 18 Sep 2013 21:55:36 +1000 Subject: [Freeipa-users] Recomendations on multi-domain environments In-Reply-To: <52399120.1070804@cica.es> References: <52399120.1070804@cica.es> Message-ID: On Wed, Sep 18, 2013 at 9:40 PM, Arturo Borrero wrote: > Hi there! > > This is my situation. > > I have some users of my main domain "cica.es". > > But I also maintain a database of users of others domain, ie "example.es". > > I can apply most of FreeIPA configuration to "cica.es" users: access to > hosts, groups, policies, roles, etc.. > > But users of "example.es" are dummy users, who just have an LDAP account > in order to use virtual mailboxes in Postfix/Dovecot. > > Do anyone have any advice on how handle this situation? > > I see some options: > * create a second FreeIPA server, each to handle his own domain. > * get the main FreeIPA server to handle two complete different LDAP tree > (with different root DNs, don't know if possible). > * integrate "example.es" users into specific groups, "prefix" or > something each group and user. > > We are talking of about 2k users in total (main domain + secondary > domain). In addition, there is the possibility to have more than two > domains. > > How FreeIPA handles this multi-domain environment? > > Best regards. > > -- > If your second domain is just for LDAP (this is a little similar to what I did). It's not a fluid as you end up limited to the two domains.. . Keep the FreeIPA for hosting cica.es to do your host polices etc. Then on your virtual mailboxes two options we did was either: - Change the default mail atribute in FreeIPA settings so a user would have user.name at example.es rather than user.domain at cica.es in their mail attribute then have the LDAP config lookup that rather than username - The other simple alternative is simply have LDAP search the username and append @example.es or not at all. HTH -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.bittner at nbu.cz Wed Sep 18 15:10:06 2013 From: j.bittner at nbu.cz (Jakub Bittner) Date: Wed, 18 Sep 2013 17:10:06 +0200 Subject: [Freeipa-users] ipa and puppet Message-ID: <5239C24E.2080903@nbu.cz> Hi, we are testing freeipa and we are wonder if anyone knows how to edit ldap tree (or what to do) to be able to store puppet nodes in ipa's ldap. I found this RFE on redhat bugzilla, but I do not understand it so much. https://bugzilla.redhat.com/show_bug.cgi?id=805368 Thank you for any hint. Jakub Bittner From avdusheff at gmail.com Wed Sep 18 15:42:07 2013 From: avdusheff at gmail.com (=?KOI8-R?B?7cnIwcnMIOE=?=) Date: Wed, 18 Sep 2013 19:42:07 +0400 Subject: [Freeipa-users] ipa-client auth with windomain account Message-ID: Hi, Do I need network access to ports from the ipa-client to the server- windows for authentication with windomain accounts? ipa-server fedora19 ipa-client fedora19 winserver win2012 the ipa-client is located in another network within the network ipa-server, ipa-client and windows-server authentication works to the ipa-client: #id windomainuser at windomain id: windomainuser at windomain: No such user please tell me what I'm doing wrong -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbulist at gmail.com Wed Sep 18 17:00:24 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Wed, 18 Sep 2013 12:00:24 -0500 Subject: [Freeipa-users] slapi-nis bypass Password Policies Message-ID: <5239DC28.8070203@gmail.com> Hi, We have a client server connected to the IPA server using NIS. It's working well but we have a service running at client server that doesn't handle the password expiration properly. Is it possible to bypass the Password Policies from this client server? Thanks! From rcritten at redhat.com Wed Sep 18 17:16:46 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Sep 2013 13:16:46 -0400 Subject: [Freeipa-users] ipa and puppet In-Reply-To: <5239C24E.2080903@nbu.cz> References: <5239C24E.2080903@nbu.cz> Message-ID: <5239DFFE.8070403@redhat.com> Jakub Bittner wrote: > Hi, > > we are testing freeipa and we are wonder if anyone knows how to edit > ldap tree (or what to do) to be able to store puppet nodes in ipa's ldap. > > I found this RFE on redhat bugzilla, but I do not understand it so much. > https://bugzilla.redhat.com/show_bug.cgi?id=805368 > > Thank you for any hint. I guess it depends on what sort of integration you're looking to do. If the data is independent, sure you can store it in the IPA ldap server, we just recommend storing it in a separate container, separate from the IPA data. If you want to augment existing entries then that is possible, just a bit more complicated. rob From meesvirk at outlook.com Wed Sep 18 17:53:13 2013 From: meesvirk at outlook.com (mees virk) Date: Wed, 18 Sep 2013 20:53:13 +0300 Subject: [Freeipa-users] Elliptic curves with the CA In-Reply-To: <5237B518.6060808@redhat.com> References: , <5237B518.6060808@redhat.com> Message-ID: I do not have a valid support contract, or other contracts with RedHat. Doesn't that stop me from opening proper RFE ticket? In any case, my interest was this time solely for evaluation purposes. If I were actively choosing an integrated identity management product, I might not choose Freeipa because it takes the longevity of the product and the development stance (lack of roadmap?) into question. RSA is slowly getting into slippery slope, because it really isn't about what it's worth today. When you protect something with a cryptographic algorithm you have to take account for how long certain types of data will be stored, and factor that time frame in. Increasing the key sizes will not be solution, because several embedded devices such as VPN products, smartcards and RFID devices will start failing pretty fast after 1024-2048 bit keys. ECC was designed to solve some of these issues; it's important development not mostly because of security today but because it will scale better up (it was designed to be implementable better on hardware), and the key sizes start from nicer point of security vs size. So it's the feature that would future proof the CA. At this moment there is available ECC support on some products on all the areas such as smart cards, so the products not having that option out of the box will start basically losing in the competition. I'm not trying to make a technical point here (if I made some minor error there, sorry) but a managerial, and from product management viewpoint. ECC must be on the feature set, or the CA features will be discarded in the future by potential users. That means the Freeipa as a whole might not be selected for some projects. Plus, it doesn't really hurt having ECC in. :) IPA uses NSS, NSS support of ECC algorithms is very fresh, we have not looked at this area yet. I suspect it would require changes in Dogtag first. Would be best if you can file and RFE ticket, then we would be able to follow up. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Sep 18 17:58:39 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 18 Sep 2013 11:58:39 -0600 Subject: [Freeipa-users] Elliptic curves with the CA In-Reply-To: References: , <5237B518.6060808@redhat.com> Message-ID: <5239E9CF.10507@redhat.com> On 09/18/2013 11:53 AM, mees virk wrote: > I do not have a valid support contract, or other contracts with > RedHat. Doesn't that stop me from opening proper RFE ticket? Not at all - https://fedorahosted.org/freeipa/newticket - depending on what you mean by "proper". > > In any case, my interest was this time solely for evaluation purposes. > If I were actively choosing an integrated identity management product, > I might not choose Freeipa because it takes the longevity of the > product and the development stance (lack of roadmap?) into question. > > RSA is slowly getting into slippery slope, because it really isn't > about what it's worth today. When you protect something with a > cryptographic algorithm you have to take account for how long certain > types of data will be stored, and factor that time frame in. > Increasing the key sizes will not be solution, because several > embedded devices such as VPN products, smartcards and RFID devices > will start failing pretty fast after 1024-2048 bit keys. > > ECC was designed to solve some of these issues; it's important > development not mostly because of security today but because it will > scale better up (it was designed to be implementable better on > hardware), and the key sizes start from nicer point of security vs > size. So it's the feature that would future proof the CA. At this > moment there is available ECC support on some products on all the > areas such as smart cards, so the products not having that option out > of the box will start basically losing in the competition. > > I'm not trying to make a technical point here (if I made some minor > error there, sorry) but a managerial, and from product management > viewpoint. ECC must be on the feature set, or the CA features will be > discarded in the future by potential users. That means the Freeipa as > a whole might not be selected for some projects. Plus, it doesn't > really hurt having ECC in. :) > > ------------------------------------------------------------------------ > > > IPA uses NSS, NSS support of ECC algorithms is very fresh, we have not > looked at this area yet. > I suspect it would require changes in Dogtag first. > > Would be best if you can file and RFE ticket, then we would be able to > follow up. > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Wed Sep 18 18:12:29 2013 From: jdennis at redhat.com (John Dennis) Date: Wed, 18 Sep 2013 14:12:29 -0400 Subject: [Freeipa-users] Elliptic curves with the CA In-Reply-To: References: , <5237B518.6060808@redhat.com> Message-ID: <5239ED0D.4050503@redhat.com> On 09/18/2013 01:53 PM, mees virk wrote: > I do not have a valid support contract, or other contracts with RedHat. > Doesn't that stop me from opening proper RFE ticket? > > In any case, my interest was this time solely for evaluation purposes. > If I were actively choosing an integrated identity management product, I > might not choose Freeipa because it takes the longevity of the product > and the development stance (lack of roadmap?) into question. > > RSA is slowly getting into slippery slope, because it really isn't about > what it's worth today. When you protect something with a cryptographic > algorithm you have to take account for how long certain types of data > will be stored, and factor that time frame in. Increasing the key sizes > will not be solution, because several embedded devices such as VPN > products, smartcards and RFID devices will start failing pretty fast > after 1024-2048 bit keys. > > ECC was designed to solve some of these issues; it's important > development not mostly because of security today but because it will > scale better up (it was designed to be implementable better on > hardware), and the key sizes start from nicer point of security vs size. > So it's the feature that would future proof the CA. At this moment there > is available ECC support on some products on all the areas such as smart > cards, so the products not having that option out of the box will start > basically losing in the competition. > > I'm not trying to make a technical point here (if I made some minor > error there, sorry) but a managerial, and from product management > viewpoint. ECC must be on the feature set, or the CA features will be > discarded in the future by potential users. That means the Freeipa as a > whole might not be selected for some projects. Plus, it doesn't really > hurt having ECC in. :) Yes we understand these issues. IPA is designed for longevity. EC is still very new, there are many components on which IPA depends which have to gain EC support before IPA can offer it, that is work which is actively in progress. There are still some intellectual property questions which are under consideration with respect to EC. And there has to be demand to support EC in IPA otherwise other RFE's and bug's will take precedence. The short story is EC is emerging, we comprehend it's value and it will almost certainly appear at some point in IPA in some form. Please do file an RFE. -- John From sakodak at gmail.com Thu Sep 19 18:48:02 2013 From: sakodak at gmail.com (KodaK) Date: Thu, 19 Sep 2013 13:48:02 -0500 Subject: [Freeipa-users] Timeout (?) issues In-Reply-To: <523860C3.5050206@redhat.com> References: <5237B70A.5050307@redhat.com> <523860C3.5050206@redhat.com> Message-ID: Thanks. I've been running that against my logs, and this has to be abnormal: err=32 129274 No Such Object err=0 10952 Successful Operations err=14 536 SASL Bind in Progress err=53 39 Unwilling To Perform err=49 3 Invalid Credentials (Bad Password) I'm still trying to figure out why there are so many error 32s. Are there any usual suspects I should know about? (That's just the current access log, btw.) On Tue, Sep 17, 2013 at 9:01 AM, Rich Megginson wrote: > On 09/16/2013 07:57 PM, Dmitri Pal wrote: > > On 09/16/2013 12:02 PM, KodaK wrote: > > Yet another AIX related problem: > > The AIX LDAP client is called secldapclntd (sure, they could make it > more awkward, but the budget ran out.) I'm running into the issue detailed > here: > > http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 > > "If an LDAP server fails to answer an LDAP query, secldapclntd caches > the non-answered query negatively. This may happen if the LDAP server is down > for example. After the LDAP server is back again secldapclntd will use > the negative cache entry and the application initiating the original > query will still fail until the cache entry expires." > > IBM is working on porting the fix to our specific TL and SP levels. > > What I'm concerned with here, though, is *why* is it timing out? I > don't know what the current timeout values are (AIX sucks, etc.) > > I don't see timeout issues on my Linux boxes, which leads me to believe > that either the sssd timouts are longer or that sssd is just more robust > when dealing with timeouts. > > I believe I'm seeing similar behavior with LDAP sudo on AIX as well, > because I occasionally have to re-run sudo commands because they initially > fail (and I know I'm using the right passwords.) However, sudo doesn't > appear to have a cache (or it handles caching better.) > > Does anyone have any troubleshooting suggestions? Any general "speed > things up" suggestions on the IPA side? > > Thanks, > > --Jason > > -- > The government is going to read our mail anyway, might as well make it > tough for them. GPG Public key ID: B6A1A7C6 > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > Is the server FreeIPA? > Can see in the server logs what is actually happening is it the server > that really takes time or there is a network connectivity issue or FW is > dropping packets? > I would really start with the server side logs. > > > As far as 389 goes, run logconv.pl against the access logs in > /var/log/dirsrv/slapd-DOMAIN-COM > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Thu Sep 19 18:57:50 2013 From: sakodak at gmail.com (KodaK) Date: Thu, 19 Sep 2013 13:57:50 -0500 Subject: [Freeipa-users] Timeout (?) issues In-Reply-To: References: <5237B70A.5050307@redhat.com> <523860C3.5050206@redhat.com> Message-ID: Well, this is awkward: [root at slpidml01 slapd-UNIX-xxx-COM]# grep conn=170902 access* | wc -l 5453936 [root at slpidml01 slapd-UNIX-xxx-COM]# On Thu, Sep 19, 2013 at 1:48 PM, KodaK wrote: > Thanks. I've been running that against my logs, and this has to be > abnormal: > > err=32 129274 No Such Object > err=0 10952 Successful Operations > err=14 536 SASL Bind in Progress > err=53 39 Unwilling To Perform > err=49 3 Invalid Credentials (Bad Password) > > I'm still trying to figure out why there are so many error 32s. Are there > any usual suspects I should know about? (That's just the current access > log, btw.) > > > On Tue, Sep 17, 2013 at 9:01 AM, Rich Megginson wrote: > >> On 09/16/2013 07:57 PM, Dmitri Pal wrote: >> >> On 09/16/2013 12:02 PM, KodaK wrote: >> >> Yet another AIX related problem: >> >> The AIX LDAP client is called secldapclntd (sure, they could make it >> more awkward, but the budget ran out.) I'm running into the issue detailed >> here: >> >> http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 >> >> "If an LDAP server fails to answer an LDAP query, secldapclntd caches >> the non-answered query negatively. This may happen if the LDAP server is down >> for example. After the LDAP server is back again secldapclntd will use >> the negative cache entry and the application initiating the original >> query will still fail until the cache entry expires." >> >> IBM is working on porting the fix to our specific TL and SP levels. >> >> What I'm concerned with here, though, is *why* is it timing out? I >> don't know what the current timeout values are (AIX sucks, etc.) >> >> I don't see timeout issues on my Linux boxes, which leads me to believe >> that either the sssd timouts are longer or that sssd is just more robust >> when dealing with timeouts. >> >> I believe I'm seeing similar behavior with LDAP sudo on AIX as well, >> because I occasionally have to re-run sudo commands because they initially >> fail (and I know I'm using the right passwords.) However, sudo doesn't >> appear to have a cache (or it handles caching better.) >> >> Does anyone have any troubleshooting suggestions? Any general "speed >> things up" suggestions on the IPA side? >> >> Thanks, >> >> --Jason >> >> -- >> The government is going to read our mail anyway, might as well make it >> tough for them. GPG Public key ID: B6A1A7C6 >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> Is the server FreeIPA? >> Can see in the server logs what is actually happening is it the server >> that really takes time or there is a network connectivity issue or FW is >> dropping packets? >> I would really start with the server side logs. >> >> >> As far as 389 goes, run logconv.pl against the access logs in >> /var/log/dirsrv/slapd-DOMAIN-COM >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs?www.redhat.com/carveoutcosts/ >> >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > > > -- > The government is going to read our mail anyway, might as well make it > tough for them. GPG Public key ID: B6A1A7C6 > -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Thu Sep 19 19:18:56 2013 From: sakodak at gmail.com (KodaK) Date: Thu, 19 Sep 2013 14:18:56 -0500 Subject: [Freeipa-users] Timeout (?) issues In-Reply-To: References: <5237B70A.5050307@redhat.com> <523860C3.5050206@redhat.com> Message-ID: SRV records were missing for _ldaps_tcp. I added them in for the IPA servers and that knocked out some of the errors, but there are still a lot. I suspect these boxes are overloaded with bad dns queries (probably due to something I've messed up.) Any help would be appreciated, but I'm opening a RH ticket. Thanks, --Jason On Thu, Sep 19, 2013 at 1:57 PM, KodaK wrote: > Well, this is awkward: > > [root at slpidml01 slapd-UNIX-xxx-COM]# grep conn=170902 access* | wc -l > 5453936 > [root at slpidml01 slapd-UNIX-xxx-COM]# > > > On Thu, Sep 19, 2013 at 1:48 PM, KodaK wrote: > >> Thanks. I've been running that against my logs, and this has to be >> abnormal: >> >> err=32 129274 No Such Object >> err=0 10952 Successful Operations >> err=14 536 SASL Bind in Progress >> err=53 39 Unwilling To Perform >> err=49 3 Invalid Credentials (Bad Password) >> >> I'm still trying to figure out why there are so many error 32s. Are >> there any usual suspects I should know about? (That's just the current >> access log, btw.) >> >> >> On Tue, Sep 17, 2013 at 9:01 AM, Rich Megginson wrote: >> >>> On 09/16/2013 07:57 PM, Dmitri Pal wrote: >>> >>> On 09/16/2013 12:02 PM, KodaK wrote: >>> >>> Yet another AIX related problem: >>> >>> The AIX LDAP client is called secldapclntd (sure, they could make it >>> more awkward, but the budget ran out.) I'm running into the issue detailed >>> here: >>> >>> http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 >>> >>> "If an LDAP server fails to answer an LDAP query, secldapclntd caches >>> the non-answered query negatively. This may happen if the LDAP server >>> is down for example. After the LDAP server is back again secldapclntd will >>> use the negative cache entry and the application initiating the original >>> query will still fail until the cache entry expires." >>> >>> IBM is working on porting the fix to our specific TL and SP levels. >>> >>> What I'm concerned with here, though, is *why* is it timing out? I >>> don't know what the current timeout values are (AIX sucks, etc.) >>> >>> I don't see timeout issues on my Linux boxes, which leads me to >>> believe that either the sssd timouts are longer or that sssd is just more >>> robust when dealing with timeouts. >>> >>> I believe I'm seeing similar behavior with LDAP sudo on AIX as well, >>> because I occasionally have to re-run sudo commands because they initially >>> fail (and I know I'm using the right passwords.) However, sudo doesn't >>> appear to have a cache (or it handles caching better.) >>> >>> Does anyone have any troubleshooting suggestions? Any general "speed >>> things up" suggestions on the IPA side? >>> >>> Thanks, >>> >>> --Jason >>> >>> -- >>> The government is going to read our mail anyway, might as well make it >>> tough for them. GPG Public key ID: B6A1A7C6 >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> Is the server FreeIPA? >>> Can see in the server logs what is actually happening is it the server >>> that really takes time or there is a network connectivity issue or FW is >>> dropping packets? >>> I would really start with the server side logs. >>> >>> >>> As far as 389 goes, run logconv.pl against the access logs in >>> /var/log/dirsrv/slapd-DOMAIN-COM >>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager for IdM portfolio >>> Red Hat Inc. >>> >>> >>> ------------------------------- >>> Looking to carve out IT costs?www.redhat.com/carveoutcosts/ >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >> >> >> >> -- >> The government is going to read our mail anyway, might as well make it >> tough for them. GPG Public key ID: B6A1A7C6 >> > > > > -- > The government is going to read our mail anyway, might as well make it > tough for them. GPG Public key ID: B6A1A7C6 > -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Thu Sep 19 19:23:19 2013 From: sakodak at gmail.com (KodaK) Date: Thu, 19 Sep 2013 14:23:19 -0500 Subject: [Freeipa-users] Replication causing long etimes In-Reply-To: References: Message-ID: Terry, did you ever get to the bottom of this? I appear to be having a similar issue with the same version of IPA. On Wed, Sep 4, 2013 at 1:18 PM, Terry Soucy wrote: > I am experiencing some long execution times, and I'm wondering if anyone > can give me some insight. > > We are running FreeIPA 3.0.0-26 on Redhat 6.1. We have multimaster > replication running among 4 hosts. We have approv 100 users, 25 usergroups > and hostgroups, and approx 2000 hosts in a single domain. We noticed that > some DNS queries were timing out periodically. When I investigated further, > I found several of the DNS requests in the access log > > [04/Sep/2013:13:42:24 -0300] conn=122491 op=3888679 SRCH > base="idnsName=compute- > 1.amazonaws.com,idnsname=prod.ca2.example.com,cn=dns,dc=example,dc=com" > scope=0 filter=" > (objectClass=idnsRecord)" attrs=ALL > [04/Sep/2013:13:42:44 -0300] conn=122491 op=3888679 RESULT err=32 tag=101 > nentri > es=0 etime=20 > > There are a lot of those, as expected, since we first noticed this issue > with DNS. > > Then I found this ... > > [04/Sep/2013:13:42:23 -0300] conn=368561 op=9 EXT > oid="2.16.840.1.113730.3.5.5" name="Netscape Replication End Session" > [04/Sep/2013:13:42:44 -0300] conn=368561 op=9 RESULT err=0 tag=120 > nentries=0 etime=22 > > and lots of this ... > > [04/Sep/2013:13:42:26 -0300] conn=368604 op=0 BIND dn="" method=sasl > version=3 mech=GSSAPI > [04/Sep/2013:13:42:44 -0300] conn=368604 op=0 RESULT err=14 tag=97 > nentries=0 etime=18, SASL bind in progress > > > So, is my SASL bind causing the replication to go long, or is the > replication taking a long time and causing the hang? Is there a way I can > see the details of the replication? There is not a lot of changes going on > that require replication with regards to dns, users, hosts, etc, so I'm not > sure why it would take so long. Also, can I remove the SASL bind and just > add a replication user to the dse.ldif to remove the requirement for > kerberos for replication? > > Terry > -- > Terry Soucy - Systems Engineer > Salesforce MarketingCloud - http://www.salesforce.com > (o) 506.631.7445 (c) 506.609.3247 | (e) tsoucy at salesforce.com > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Sep 19 19:51:12 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 19 Sep 2013 13:51:12 -0600 Subject: [Freeipa-users] Timeout (?) issues In-Reply-To: References: <5237B70A.5050307@redhat.com> <523860C3.5050206@redhat.com> Message-ID: <523B55B0.3090309@redhat.com> On 09/19/2013 12:57 PM, KodaK wrote: > Well, this is awkward: > > [root at slpidml01 slapd-UNIX-xxx-COM]# grep conn=170902 access* | wc -l > 5453936 > [root at slpidml01 slapd-UNIX-xxx-COM]# Why is it awkward? > > > On Thu, Sep 19, 2013 at 1:48 PM, KodaK > wrote: > > Thanks. I've been running that against my logs, and this has to > be abnormal: > > err=32 129274 No Such Object > err=0 10952 Successful Operations > err=14 536 SASL Bind in Progress > err=53 39 Unwilling To Perform > err=49 3 Invalid Credentials (Bad Password) > > I'm still trying to figure out why there are so many error 32s. > Are there any usual suspects I should know about? (That's just > the current access log, btw.) > > > On Tue, Sep 17, 2013 at 9:01 AM, Rich Megginson > > wrote: > > On 09/16/2013 07:57 PM, Dmitri Pal wrote: >> On 09/16/2013 12:02 PM, KodaK wrote: >>> Yet another AIX related problem: >>> >>> The AIX LDAP client is called secldapclntd (sure, they could >>> make it more awkward, but the budget ran out.) I'm running >>> into the issue detailed here: >>> >>> http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 >>> >>> "If an LDAP server fails to answer an LDAP query, >>> secldapclntd caches the non-answered query negatively. This >>> may happen if the LDAP server is down for example. After the >>> LDAP server is back again secldapclntd will use the negative >>> cache entry and the application initiating the original >>> query will still fail until the cache entry expires." >>> >>> IBM is working on porting the fix to our specific TL and SP >>> levels. >>> >>> What I'm concerned with here, though, is *why* is it timing >>> out? I don't know what the current timeout values are (AIX >>> sucks, etc.) >>> >>> I don't see timeout issues on my Linux boxes, which leads me >>> to believe that either the sssd timouts are longer or that >>> sssd is just more robust when dealing with timeouts. >>> >>> I believe I'm seeing similar behavior with LDAP sudo on AIX >>> as well, because I occasionally have to re-run sudo commands >>> because they initially fail (and I know I'm using the right >>> passwords.) However, sudo doesn't appear to have a cache >>> (or it handles caching better.) >>> >>> Does anyone have any troubleshooting suggestions? Any >>> general "speed things up" suggestions on the IPA side? >>> >>> Thanks, >>> >>> --Jason >>> >>> -- >>> The government is going to read our mail anyway, might as >>> well make it tough for them. GPG Public key ID: B6A1A7C6 >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >> Is the server FreeIPA? >> Can see in the server logs what is actually happening is it >> the server that really takes time or there is a network >> connectivity issue or FW is dropping packets? >> I would really start with the server side logs. > > As far as 389 goes, run logconv.pl against > the access logs in /var/log/dirsrv/slapd-DOMAIN-COM >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > The government is going to read our mail anyway, might as well > make it tough for them. GPG Public key ID: B6A1A7C6 > > > > > -- > The government is going to read our mail anyway, might as well make it > tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Thu Sep 19 20:05:02 2013 From: sakodak at gmail.com (KodaK) Date: Thu, 19 Sep 2013 15:05:02 -0500 Subject: [Freeipa-users] Timeout (?) issues In-Reply-To: <523B55B0.3090309@redhat.com> References: <5237B70A.5050307@redhat.com> <523860C3.5050206@redhat.com> <523B55B0.3090309@redhat.com> Message-ID: I didn't realize that DNS created one connection. I thought it was one connection spanning several days. On Thu, Sep 19, 2013 at 2:51 PM, Rich Megginson wrote: > On 09/19/2013 12:57 PM, KodaK wrote: > > Well, this is awkward: > > [root at slpidml01 slapd-UNIX-xxx-COM]# grep conn=170902 access* | wc -l > 5453936 > [root at slpidml01 slapd-UNIX-xxx-COM]# > > > Why is it awkward? > > > > > On Thu, Sep 19, 2013 at 1:48 PM, KodaK wrote: > >> Thanks. I've been running that against my logs, and this has to be >> abnormal: >> >> err=32 129274 No Such Object >> err=0 10952 Successful Operations >> err=14 536 SASL Bind in Progress >> err=53 39 Unwilling To Perform >> err=49 3 Invalid Credentials (Bad Password) >> >> I'm still trying to figure out why there are so many error 32s. Are >> there any usual suspects I should know about? (That's just the current >> access log, btw.) >> >> >> On Tue, Sep 17, 2013 at 9:01 AM, Rich Megginson wrote: >> >>> On 09/16/2013 07:57 PM, Dmitri Pal wrote: >>> >>> On 09/16/2013 12:02 PM, KodaK wrote: >>> >>> Yet another AIX related problem: >>> >>> The AIX LDAP client is called secldapclntd (sure, they could make it >>> more awkward, but the budget ran out.) I'm running into the issue detailed >>> here: >>> >>> http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 >>> >>> "If an LDAP server fails to answer an LDAP query, secldapclntd caches >>> the non-answered query negatively. This may happen if the LDAP server >>> is down for example. After the LDAP server is back again secldapclntd will >>> use the negative cache entry and the application initiating the original >>> query will still fail until the cache entry expires." >>> >>> IBM is working on porting the fix to our specific TL and SP levels. >>> >>> What I'm concerned with here, though, is *why* is it timing out? I >>> don't know what the current timeout values are (AIX sucks, etc.) >>> >>> I don't see timeout issues on my Linux boxes, which leads me to >>> believe that either the sssd timouts are longer or that sssd is just more >>> robust when dealing with timeouts. >>> >>> I believe I'm seeing similar behavior with LDAP sudo on AIX as well, >>> because I occasionally have to re-run sudo commands because they initially >>> fail (and I know I'm using the right passwords.) However, sudo doesn't >>> appear to have a cache (or it handles caching better.) >>> >>> Does anyone have any troubleshooting suggestions? Any general "speed >>> things up" suggestions on the IPA side? >>> >>> Thanks, >>> >>> --Jason >>> >>> -- >>> The government is going to read our mail anyway, might as well make it >>> tough for them. GPG Public key ID: B6A1A7C6 >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> Is the server FreeIPA? >>> Can see in the server logs what is actually happening is it the server >>> that really takes time or there is a network connectivity issue or FW is >>> dropping packets? >>> I would really start with the server side logs. >>> >>> >>> As far as 389 goes, run logconv.pl against the access logs in >>> /var/log/dirsrv/slapd-DOMAIN-COM >>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager for IdM portfolio >>> Red Hat Inc. >>> >>> >>> ------------------------------- >>> Looking to carve out IT costs?www.redhat.com/carveoutcosts/ >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> >> >> >> >> -- >> The government is going to read our mail anyway, might as well make it >> tough for them. GPG Public key ID: B6A1A7C6 >> > > > > -- > The government is going to read our mail anyway, might as well make it > tough for them. GPG Public key ID: B6A1A7C6 > > > -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Thu Sep 19 23:24:04 2013 From: sakodak at gmail.com (KodaK) Date: Thu, 19 Sep 2013 18:24:04 -0500 Subject: [Freeipa-users] Timeout (?) issues In-Reply-To: References: <5237B70A.5050307@redhat.com> <523860C3.5050206@redhat.com> <523B55B0.3090309@redhat.com> Message-ID: This is ridiculous, right? IPA server 1: # for i in $(ls access*); do echo -n $i:\ ;grep err=32 $i | wc -l; done access: 248478 access.20130916-043207: 302774 access.20130916-123642: 272572 access.20130916-201516: 294308 access.20130917-081053: 295060 access.20130917-144559: 284498 access.20130917-231435: 281035 access.20130918-091611: 291165 access.20130918-154945: 275792 access.20130919-014322: 296113 IPA server 2: access: 4313 access.20130909-200216: 4023 access.20130910-200229: 4161 access.20130911-200239: 4182 access.20130912-200249: 5069 access.20130913-200258: 3833 access.20130914-200313: 4208 access.20130915-200323: 4702 access.20130916-200332: 4532 IPA server 3: access: 802 access.20130910-080737: 3876 access.20130911-080748: 3902 access.20130912-080802: 3678 access.20130913-080810: 3765 access.20130914-080826: 3524 access.20130915-080907: 4142 access.20130916-080916: 4930 access.20130917-080926: 4769 access.20130918-081005: 2879 IPA server 4: access: 2812 access.20130910-003051: 4095 access.20130911-003105: 3623 access.20130912-003113: 3606 access.20130913-003125: 3581 access.20130914-003135: 3758 access.20130915-003150: 3935 access.20130916-003159: 4184 access.20130917-003210: 3859 access.20130918-003221: 5110 The vast majority of the err=32 messages are DNS entries. Here are some samples: [19/Sep/2013:18:19:51 -0500] conn=9 op=169764 SRCH base="idnsName=xxx.com ,idnsname=unix.xxx.com,cn=dns,dc=unix,dc=xxx,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [19/Sep/2013:18:19:51 -0500] conn=9 op=169764 RESULT err=32 tag=101 nentries=0 etime=0 [19/Sep/2013:18:19:51 -0500] conn=9 op=169774 SRCH base="idnsName= slpoxacl01.unix.xxx.com,idnsname=unix.xxx.com,cn=dns,dc=unix,dc=xxx,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [19/Sep/2013:18:19:51 -0500] conn=9 op=169774 RESULT err=32 tag=101 nentries=0 etime=0 [19/Sep/2013:18:19:51 -0500] conn=9 op=169770 SRCH base="idnsName= sla400q1.unix.xxx.com,idnsname=unix.xxx.com,cn=dns,dc=unix,dc=xxx,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [19/Sep/2013:18:19:51 -0500] conn=9 op=169770 RESULT err=32 tag=101 nentries=0 etime=0 [19/Sep/2013:18:19:51 -0500] conn=9 op=169772 SRCH base="idnsName= magellanhealth.com,idnsname=unix.magellanhealth.com,cn=dns,dc=unix,dc=magellanhealth,dc=com" scope=0 filter="(objectClass=idnsRecord)" attrs=ALL [19/Sep/2013:18:19:51 -0500] conn=9 op=169772 RESULT err=32 tag=101 nentries=0 etime=0 So far today there are over half a million of these. That can't be right. On Thu, Sep 19, 2013 at 3:05 PM, KodaK wrote: > I didn't realize that DNS created one connection. I thought it was one > connection spanning several days. > > > On Thu, Sep 19, 2013 at 2:51 PM, Rich Megginson wrote: > >> On 09/19/2013 12:57 PM, KodaK wrote: >> >> Well, this is awkward: >> >> [root at slpidml01 slapd-UNIX-xxx-COM]# grep conn=170902 access* | wc -l >> 5453936 >> [root at slpidml01 slapd-UNIX-xxx-COM]# >> >> >> Why is it awkward? >> >> >> >> >> On Thu, Sep 19, 2013 at 1:48 PM, KodaK wrote: >> >>> Thanks. I've been running that against my logs, and this has to be >>> abnormal: >>> >>> err=32 129274 No Such Object >>> err=0 10952 Successful Operations >>> err=14 536 SASL Bind in Progress >>> err=53 39 Unwilling To Perform >>> err=49 3 Invalid Credentials (Bad Password) >>> >>> I'm still trying to figure out why there are so many error 32s. Are >>> there any usual suspects I should know about? (That's just the current >>> access log, btw.) >>> >>> >>> On Tue, Sep 17, 2013 at 9:01 AM, Rich Megginson wrote: >>> >>>> On 09/16/2013 07:57 PM, Dmitri Pal wrote: >>>> >>>> On 09/16/2013 12:02 PM, KodaK wrote: >>>> >>>> Yet another AIX related problem: >>>> >>>> The AIX LDAP client is called secldapclntd (sure, they could make it >>>> more awkward, but the budget ran out.) I'm running into the issue detailed >>>> here: >>>> >>>> http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 >>>> >>>> "If an LDAP server fails to answer an LDAP query, secldapclntd caches >>>> the non-answered query negatively. This may happen if the LDAP server >>>> is down for example. After the LDAP server is back again secldapclntd will >>>> use the negative cache entry and the application initiating the original >>>> query will still fail until the cache entry expires." >>>> >>>> IBM is working on porting the fix to our specific TL and SP levels. >>>> >>>> What I'm concerned with here, though, is *why* is it timing out? I >>>> don't know what the current timeout values are (AIX sucks, etc.) >>>> >>>> I don't see timeout issues on my Linux boxes, which leads me to >>>> believe that either the sssd timouts are longer or that sssd is just more >>>> robust when dealing with timeouts. >>>> >>>> I believe I'm seeing similar behavior with LDAP sudo on AIX as well, >>>> because I occasionally have to re-run sudo commands because they initially >>>> fail (and I know I'm using the right passwords.) However, sudo doesn't >>>> appear to have a cache (or it handles caching better.) >>>> >>>> Does anyone have any troubleshooting suggestions? Any general "speed >>>> things up" suggestions on the IPA side? >>>> >>>> Thanks, >>>> >>>> --Jason >>>> >>>> -- >>>> The government is going to read our mail anyway, might as well make it >>>> tough for them. GPG Public key ID: B6A1A7C6 >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> >>>> Is the server FreeIPA? >>>> Can see in the server logs what is actually happening is it the server >>>> that really takes time or there is a network connectivity issue or FW is >>>> dropping packets? >>>> I would really start with the server side logs. >>>> >>>> >>>> As far as 389 goes, run logconv.pl against the access logs in >>>> /var/log/dirsrv/slapd-DOMAIN-COM >>>> >>>> >>>> >>>> -- >>>> Thank you, >>>> Dmitri Pal >>>> >>>> Sr. Engineering Manager for IdM portfolio >>>> Red Hat Inc. >>>> >>>> >>>> ------------------------------- >>>> Looking to carve out IT costs?www.redhat.com/carveoutcosts/ >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> >>> >>> >>> >>> -- >>> The government is going to read our mail anyway, might as well make it >>> tough for them. GPG Public key ID: B6A1A7C6 >>> >> >> >> >> -- >> The government is going to read our mail anyway, might as well make it >> tough for them. GPG Public key ID: B6A1A7C6 >> >> >> > > > -- > The government is going to read our mail anyway, might as well make it > tough for them. GPG Public key ID: B6A1A7C6 > -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Sep 20 03:28:03 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 19 Sep 2013 23:28:03 -0400 Subject: [Freeipa-users] slapi-nis bypass Password Policies In-Reply-To: <5239DC28.8070203@gmail.com> References: <5239DC28.8070203@gmail.com> Message-ID: <1379647683.19525.15.camel@willson.li.ssimo.org> On Wed, 2013-09-18 at 12:00 -0500, cbulist at gmail.com wrote: > Hi, > > We have a client server connected to the IPA server using NIS. It's > working well but we have a service running at client server that doesn't > handle the password expiration properly. > Is it possible to bypass the Password Policies from this client server? I am not sure I understand in what way you'd want to bypass them. You'd like to be able to continue to authenticate even if the passwords are expired ? Or you just want to avoid being sent password expiration messages ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Fri Sep 20 08:07:04 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 20 Sep 2013 10:07:04 +0200 Subject: [Freeipa-users] Timeout (?) issues In-Reply-To: References: <5237B70A.5050307@redhat.com> <523860C3.5050206@redhat.com> <523B55B0.3090309@redhat.com> Message-ID: <523C0228.70408@redhat.com> On 20.9.2013 01:24, KodaK wrote: > This is ridiculous, right? > > IPA server 1: > > # for i in $(ls access*); do echo -n $i:\ ;grep err=32 $i | wc -l; done > access: 248478 > access.20130916-043207: 302774 > access.20130916-123642: 272572 > access.20130916-201516: 294308 > access.20130917-081053: 295060 > access.20130917-144559: 284498 > access.20130917-231435: 281035 > access.20130918-091611: 291165 > access.20130918-154945: 275792 > access.20130919-014322: 296113 > > IPA server 2: > > access: 4313 > access.20130909-200216: 4023 > access.20130910-200229: 4161 > access.20130911-200239: 4182 > access.20130912-200249: 5069 > access.20130913-200258: 3833 > access.20130914-200313: 4208 > access.20130915-200323: 4702 > access.20130916-200332: 4532 > > > IPA server 3: > > access: 802 > access.20130910-080737: 3876 > access.20130911-080748: 3902 > access.20130912-080802: 3678 > access.20130913-080810: 3765 > access.20130914-080826: 3524 > access.20130915-080907: 4142 > access.20130916-080916: 4930 > access.20130917-080926: 4769 > access.20130918-081005: 2879 > > IPA server 4: > > access: 2812 > access.20130910-003051: 4095 > access.20130911-003105: 3623 > access.20130912-003113: 3606 > access.20130913-003125: 3581 > access.20130914-003135: 3758 > access.20130915-003150: 3935 > access.20130916-003159: 4184 > access.20130917-003210: 3859 > access.20130918-003221: 5110 > > > The vast majority of the err=32 messages are DNS entries. It depends on your setup. Bind-dyndb-ldap does LDAP search for each non-existent name to verify that the name wasn't added to LDAP in meanwhile. If you have clients doing 1M queries for non-existing names per day, then you will see 1M LDAP queries with err=32 per day. Next major version of bind-dyndb-ldap will have reworked internal database and it will support negative caching, so number of err=32 should drop significantly. > Here are some samples: > > [19/Sep/2013:18:19:51 -0500] conn=9 op=169764 SRCH base="idnsName=xxx.com > ,idnsname=unix.xxx.com,cn=dns,dc=unix,dc=xxx,dc=com" scope=0 > filter="(objectClass=idnsRecord)" attrs=ALL > [19/Sep/2013:18:19:51 -0500] conn=9 op=169764 RESULT err=32 tag=101 > nentries=0 etime=0 This is interesting, because this LDAP query is equal to DNS query for "xxx.com.unix.xxx.com." Are your clients that crazy? :-) > [19/Sep/2013:18:19:51 -0500] conn=9 op=169774 SRCH base="idnsName= > slpoxacl01.unix.xxx.com,idnsname=unix.xxx.com,cn=dns,dc=unix,dc=xxx,dc=com" > scope=0 filter="(objectClass=idnsRecord)" attrs=ALL > [19/Sep/2013:18:19:51 -0500] conn=9 op=169774 RESULT err=32 tag=101 > nentries=0 etime=0 This is equivalent to DNS query for "slpoxacl01.unix.xxx.com.unix.xxx.com.". > [19/Sep/2013:18:19:51 -0500] conn=9 op=169770 SRCH base="idnsName= > sla400q1.unix.xxx.com,idnsname=unix.xxx.com,cn=dns,dc=unix,dc=xxx,dc=com" > scope=0 filter="(objectClass=idnsRecord)" attrs=ALL > [19/Sep/2013:18:19:51 -0500] conn=9 op=169770 RESULT err=32 tag=101 > nentries=0 etime=0 And this is "sla400q1.unix.xxx.com.unix.xxx.com.". > [19/Sep/2013:18:19:51 -0500] conn=9 op=169772 SRCH base="idnsName= > magellanhealth.com,idnsname=unix.magellanhealth.com,cn=dns,dc=unix,dc=magellanhealth,dc=com" > scope=0 filter="(objectClass=idnsRecord)" attrs=ALL > [19/Sep/2013:18:19:51 -0500] conn=9 op=169772 RESULT err=32 tag=101 > nentries=0 etime=0 > > So far today there are over half a million of these. That can't be right. I would recommend you to use network sniffer and check which clients sends these crazy queries. My guess is that your resolver library (libc?) causes this. On my Linux system with glibc-2.17-14.fc19.x86_64 it behaves in this way: client query = nonexistent.example.com. (I used $ "ping nonexistent.example.com.") search domain in /etc/resolv.conf = brq.redhat.com. DNS query #1: nonexistent.example.com. => NXDOMAIN DNS query #2: nonexistent.example.com.brq.redhat.com. => NXDOMAIN DNS query #3: nonexistent.example.com.redhat.com. => NXDOMAIN > On Thu, Sep 19, 2013 at 3:05 PM, KodaK wrote: > >> I didn't realize that DNS created one connection. I thought it was one >> connection spanning several days. In theory, there should be 2-4 LDAP connections from each DNS server and those connections should live until DNS or LDAP server restarts/crashes. Petr^2 Spacek >> On Thu, Sep 19, 2013 at 2:51 PM, Rich Megginson wrote: >> >>> On 09/19/2013 12:57 PM, KodaK wrote: >>> >>> Well, this is awkward: >>> >>> [root at slpidml01 slapd-UNIX-xxx-COM]# grep conn=170902 access* | wc -l >>> 5453936 >>> [root at slpidml01 slapd-UNIX-xxx-COM]# >>> >>> >>> Why is it awkward? >>> >>> >>> >>> >>> On Thu, Sep 19, 2013 at 1:48 PM, KodaK wrote: >>> >>>> Thanks. I've been running that against my logs, and this has to be >>>> abnormal: >>>> >>>> err=32 129274 No Such Object >>>> err=0 10952 Successful Operations >>>> err=14 536 SASL Bind in Progress >>>> err=53 39 Unwilling To Perform >>>> err=49 3 Invalid Credentials (Bad Password) >>>> >>>> I'm still trying to figure out why there are so many error 32s. Are >>>> there any usual suspects I should know about? (That's just the current >>>> access log, btw.) >>>> >>>> >>>> On Tue, Sep 17, 2013 at 9:01 AM, Rich Megginson wrote: >>>> >>>>> On 09/16/2013 07:57 PM, Dmitri Pal wrote: >>>>> >>>>> On 09/16/2013 12:02 PM, KodaK wrote: >>>>> >>>>> Yet another AIX related problem: >>>>> >>>>> The AIX LDAP client is called secldapclntd (sure, they could make it >>>>> more awkward, but the budget ran out.) I'm running into the issue detailed >>>>> here: >>>>> >>>>> http://www-01.ibm.com/support/docview.wss?uid=isg1IV11344 >>>>> >>>>> "If an LDAP server fails to answer an LDAP query, secldapclntd caches >>>>> the non-answered query negatively. This may happen if the LDAP server >>>>> is down for example. After the LDAP server is back again secldapclntd will >>>>> use the negative cache entry and the application initiating the original >>>>> query will still fail until the cache entry expires." >>>>> >>>>> IBM is working on porting the fix to our specific TL and SP levels. >>>>> >>>>> What I'm concerned with here, though, is *why* is it timing out? I >>>>> don't know what the current timeout values are (AIX sucks, etc.) >>>>> >>>>> I don't see timeout issues on my Linux boxes, which leads me to >>>>> believe that either the sssd timouts are longer or that sssd is just more >>>>> robust when dealing with timeouts. >>>>> >>>>> I believe I'm seeing similar behavior with LDAP sudo on AIX as well, >>>>> because I occasionally have to re-run sudo commands because they initially >>>>> fail (and I know I'm using the right passwords.) However, sudo doesn't >>>>> appear to have a cache (or it handles caching better.) >>>>> >>>>> Does anyone have any troubleshooting suggestions? Any general "speed >>>>> things up" suggestions on the IPA side? >>>>> >>>>> Thanks, >>>>> >>>>> --Jason >>>>> >>>>> -- >>>>> The government is going to read our mail anyway, might as well make it >>>>> tough for them. GPG Public key ID: B6A1A7C6 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >>>>> >>>>> >>>>> Is the server FreeIPA? >>>>> Can see in the server logs what is actually happening is it the server >>>>> that really takes time or there is a network connectivity issue or FW is >>>>> dropping packets? >>>>> I would really start with the server side logs. >>>>> >>>>> >>>>> As far as 389 goes, run logconv.pl against the access logs in >>>>> /var/log/dirsrv/slapd-DOMAIN-COM From andrew at andrewklau.com Fri Sep 20 08:14:55 2013 From: andrew at andrewklau.com (Andrew Lau) Date: Fri, 20 Sep 2013 18:14:55 +1000 Subject: [Freeipa-users] Export SSL Cert Message-ID: Hi, On my ever quest to finally get freeipa working behind a reverse proxy, the final thing was is it possible to export the private key and cert of the freeipa http cert? I would like to put the SSL cert on the reverse proxy but it seems I'm not having any luck getting the private key out from the certdb. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Fri Sep 20 10:48:06 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 20 Sep 2013 12:48:06 +0200 Subject: [Freeipa-users] Export SSL Cert In-Reply-To: References: Message-ID: <523C27E6.6020304@redhat.com> On 20.9.2013 10:14, Andrew Lau wrote: > Hi, > > On my ever quest to finally get freeipa working behind a reverse proxy, > the final thing was is it possible to export the private key and cert of > the freeipa http cert? I would like to put the SSL cert on the reverse > proxy but it seems I'm not having any luck getting the private key out > from the certdb. > > Thanks. > Hi, you can use pk12util to export it to PKCS#12 file, which contains both the certificate and the private key: # pk12util -o file.p12 -n Server-Cert -d /etc/httpd/alias -k /etc/httpd/alias/pwdfile.txt Honza -- Jan Cholasta From andrew at andrewklau.com Fri Sep 20 11:01:18 2013 From: andrew at andrewklau.com (Andrew Lau) Date: Fri, 20 Sep 2013 21:01:18 +1000 Subject: [Freeipa-users] Export SSL Cert In-Reply-To: <523C27E6.6020304@redhat.com> References: <523C27E6.6020304@redhat.com> Message-ID: On Fri, Sep 20, 2013 at 8:48 PM, Jan Cholasta wrote: > On 20.9.2013 10:14, Andrew Lau wrote: > >> Hi, >> >> On my ever quest to finally get freeipa working behind a reverse proxy, >> the final thing was is it possible to export the private key and cert of >> the freeipa http cert? I would like to put the SSL cert on the reverse >> proxy but it seems I'm not having any luck getting the private key out >> from the certdb. >> >> Thanks. >> >> > Hi, > > you can use pk12util to export it to PKCS#12 file, which contains both the > certificate and the private key: > > # pk12util -o file.p12 -n Server-Cert -d /etc/httpd/alias -k > /etc/httpd/alias/pwdfile.txt > > Honza > > -- > Jan Cholasta > Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From fvzwieten at vxcompany.com Fri Sep 20 11:33:09 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Fri, 20 Sep 2013 13:33:09 +0200 Subject: [Freeipa-users] Fwd: Windows, Samba and IPA In-Reply-To: References: Message-ID: Hi, I wonder if it is possible to have Windows clients (member of some domain) to connect to SAMBA shares with an IPA account. I found various howto's voor Kerberized SAMBA but they al use Linux as the client platform. I have tried to set it up using a Red Hat Solution article, but I did not get it to work. Is it possible without using trust or synchronization between AD and IPA? If yes, how? Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From loris at lgs.com.ve Fri Sep 20 14:31:21 2013 From: loris at lgs.com.ve (Loris Santamaria) Date: Fri, 20 Sep 2013 10:01:21 -0430 Subject: [Freeipa-users] Joining a Windows Workstation to an IPA realm (It works better than expected!) Message-ID: <1379687481.27594.28.camel@toron.pzo.lgs.com.ve> Hi all, yesterday I was going to try puppet on windows, so I fired up a Windows 7 VM, and just for curiosity, instead of joining it to the AD realm, i decided to try the instructions outlined in the wiki to join the machine to the IPA realm: http://www.freeipa.org/page/Windows_authentication_against_FreeIPA So I went with the instructions, on the windows Workstation. ksetup /setdomain [REALM NAME] ksetup /addkdc [REALM NAME] [kdc DNS name] ksetup /addkpassword [REALM NAME] [kdc DNS name] ksetup /setcomputerpassword [MACHINE_PASSWORD] (the one used above) ksetup /mapuser * * Next, the instructions tell you to create Windows local users corresponding to the IPA kerberos realm users, because you know, kerberos only does authentication and it can tell nothing to the windows workstation about the identity of the user... However, just for kicks, I rebooted the VM and _without creating any local user_ I tried to login with myuser at IPA.REALM ? And it worked! It created a profile directory, showed my full name on the start menu. Then I tried to browse the web and SSO with squid worked like a charm, SSO with putty worked and I even logged in to the IPA administration page with my ticket. But it wasn't supposed to work without creating a local user... why it was working then? Please notice this, the IPA realm has a trust with the AD realm, so samba 4 is running on the IPA servers and every user in the IPA realm has a SID assigned... and its ticket comes with a PAC, I think that is the important part. Finally, what worked and what don't: * I was able to login on Win 7 with an IPA user and having a local profile created automatically * I was able to perform SSO authentication with IPA services * I was able to add my IPA user to the "Administrators" group in windows, with the NET LOCALGROUP command. * I couldn't add the IPA "admins" group to the "Administrators" group. With "NET LOCALGROUP Administrators IPA\admins /add" it tells me that it doesn't recognise the IPA\admins group. * I couldn't add other IPA users to the Administrators group, only my logged in user. * I can't add IPA users to group with the graphical administration tools, they won't show the IPA realm, only the NET command worked somehow I'm investigating why Windows can't see IPA users and group other than the currently logged in user, but I suspect that is simply because Windows takes the logged in user SID from the PAC and it doesn't really talk to samba4. If one could add IPA groups to local Windows groups, combine that with puppet policies, that would be the holy grail of system administration :) -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6173 bytes Desc: not available URL: From abokovoy at redhat.com Fri Sep 20 15:01:08 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 20 Sep 2013 18:01:08 +0300 Subject: [Freeipa-users] Joining a Windows Workstation to an IPA realm (It works better than expected!) In-Reply-To: <1379687481.27594.28.camel@toron.pzo.lgs.com.ve> References: <1379687481.27594.28.camel@toron.pzo.lgs.com.ve> Message-ID: <20130920150108.GI4216@redhat.com> On Fri, 20 Sep 2013, Loris Santamaria wrote: >Hi all, > >yesterday I was going to try puppet on windows, so I fired up a Windows >7 VM, and just for curiosity, instead of joining it to the AD realm, i >decided to try the instructions outlined in the wiki to join the machine >to the IPA realm: >http://www.freeipa.org/page/Windows_authentication_against_FreeIPA > >So I went with the instructions, on the windows Workstation. > >ksetup /setdomain [REALM NAME] >ksetup /addkdc [REALM NAME] [kdc DNS name] >ksetup /addkpassword [REALM NAME] [kdc DNS name] >ksetup /setcomputerpassword [MACHINE_PASSWORD] (the one used above) >ksetup /mapuser * * > >Next, the instructions tell you to create Windows local users >corresponding to the IPA kerberos realm users, because you know, >kerberos only does authentication and it can tell nothing to the windows >workstation about the identity of the user... However, just for kicks, I >rebooted the VM and _without creating any local user_ I tried to login >with myuser at IPA.REALM ? And it worked! It created a profile directory, >showed my full name on the start menu. Then I tried to browse the web >and SSO with squid worked like a charm, SSO with putty worked and I even >logged in to the IPA administration page with my ticket. > >But it wasn't supposed to work without creating a local user... why it >was working then? > >Please notice this, the IPA realm has a trust with the AD realm, so >samba 4 is running on the IPA servers and every user in the IPA realm >has a SID assigned... and its ticket comes with a PAC, I think that is >the important part. Exactly. You actually don't need to create the trust, just run ipa-adtrust-install to make sure IPA's infrastructure is configured to issue SIDs and accept them. > >Finally, what worked and what don't: > > * I was able to login on Win 7 with an IPA user and having a local > profile created automatically > * I was able to perform SSO authentication with IPA services > * I was able to add my IPA user to the "Administrators" group in > windows, with the NET LOCALGROUP command. > * I couldn't add the IPA "admins" group to the "Administrators" > group. With "NET LOCALGROUP Administrators IPA\admins /add" it > tells me that it doesn't recognise the IPA\admins group. Right, because it doesn't know where to look up translation between IPA\admins string and SID as you haven't really configured Windows PC to be part of the domain and IPA domain doesn't provide services Windows PC expect to be there by default for resolving user/group to SIDs in Active Directory. > * I couldn't add other IPA users to the Administrators group, only > my logged in user. Same here. > * I can't add IPA users to group with the graphical administration > tools, they won't show the IPA realm, only the NET command > worked somehow Same here. Windows UIs rely on AD global catalog service which we don't implement. >I'm investigating why Windows can't see IPA users and group other than >the currently logged in user, but I suspect that is simply because >Windows takes the logged in user SID from the PAC and it doesn't really >talk to samba4. Yep, only that it doesn't know where to talk as there is no proper service available. -- / Alexander Bokovoy From dpal at redhat.com Fri Sep 20 15:25:39 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Sep 2013 11:25:39 -0400 Subject: [Freeipa-users] Replica of a Replica and Master Recovery In-Reply-To: References: Message-ID: <523C68F3.8080200@redhat.com> On 09/17/2013 03:40 PM, Trevor T Kates (Services - 6) wrote: > I apologize for the weird subject. The problem I'm facing feels a > little weird and I could use some help. > > I'm running IPA in a test environment and trying to find different > ways in which I can break it and then repair it. My IPA is running on > CentOS 6.4: > > Linux ipa00.testdomain.com 2.6.32-358.18.1.el6.x86_64 #1 SMP Wed Aug > 28 17:19:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > bind-9.8.2-0.17.rc1.el6_4.6.x86_64 > bind-dyndb-ldap-2.3-2.el6_4.1.x86_64 > ipa-server-3.0.0-26.el6_4.4.x86_64 > > I seem to have created a problem for myself involving the original > master server. At the beginning, I created a master IPA server with > the dogtag CA and several replicas with replica dogtag CAs. I stored > the /root/cacert.p12 file in a backup, reimaged the original master > and turned it into a replica. In doing so, I seem to have eliminated > my ability to create additional replicas due to not completely backing > up everything related to the CA on the master. After preparing a > replica on my reimaged master and attemping to install it on a > different test server, I ran into the following error: > > [root at ipa04 ~]# ipa-replica-install --setup-ca -N --setup-dns > /var/lib/ipa/replica-info-ipa04.testdomain.com.gpg > Directory Manager (existing master) password: > > Run connection check to master > Check connection from replica to remote master 'ipa00.testdomain.com': > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): OK > Kerberos KDC: TCP (88): OK > Kerberos Kpasswd: TCP (464): OK > HTTP Server: Unsecure port (80): OK > HTTP Server: Secure port (443): OK > PKI-CA: Directory Service port (7389): OK > > The following list of ports use UDP protocol and would need to be > checked manually: > Kerberos KDC: UDP (88): SKIPPED > Kerberos Kpasswd: UDP (464): SKIPPED > > Connection from replica to master is OK. > Start listening on required ports for remote master check > Get credentials to log in to remote master > admin at TESTDOMAIN.COM password: > > Execute check on remote master > admin at ipa00.testdomain.com's password: > Check connection from master to remote replica 'ipa04.testdomain.com': > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): OK > Kerberos KDC: TCP (88): OK > Kerberos KDC: UDP (88): OK > Kerberos Kpasswd: TCP (464): OK > Kerberos Kpasswd: UDP (464): OK > HTTP Server: Unsecure port (80): OK > HTTP Server: Secure port (443): OK > PKI-CA: Directory Service port (7389): OK > > Connection from master to replica is OK. > > Connection check OK > Configuring directory server for the CA (pkids): Estimated time 30 seconds > [1/3]: creating directory server user > [2/3]: creating directory server instance > [3/3]: restarting directory server > Done configuring directory server for the CA (pkids). > Configuring certificate server (pki-cad): Estimated time 3 minutes 30 > seconds > [1/17]: creating certificate server user > [2/17]: creating pki-ca instance > [3/17]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > ipa04.testdomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-krRAM2 > -client_certdb_pwd XXXXXXXX -preop_pin 2e3Wsf8VDR8lEXLi3HyX > -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=TESTDOMAIN.COM -ldap_host ipa04.testdomain.com > -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX > -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa > -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX > -subsystem_name pki-cad -token_name internal > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=TESTDOMAIN.COM > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=TESTDOMAIN.COM > -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=TESTDOMAIN.COM > -ca_server_cert_subject_name CN=ipa04.testdomain.com,O=TESTDOMAIN.COM > -ca_audit_signing_cert_subject_name CN=CA Audit,O=TESTDOMAIN.COM > -ca_sign_cert_subject_name CN=Certificate Authority,O=TESTDOMAIN.COM > -external false -clone true -clone_p12_file ca.p12 -clone_p12_password > XXXXXXXX -sd_hostname ipa00.testdomain.com -sd_admin_port 443 > -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true > -clone_uri https://ipa00.testdomain.com:443' returned non-zero exit > status 255 > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Configuration of CA failed > > ___ > /var/log/ipareplica-install.log: > > ############################################# > Attempting to connect to: ipa04.testdomain.com:9445 > Connected. > Posting Query = > https://ipa04.testdomain.com:9445//ca/admin/console/config/wi > zard?p=5&subsystem=CA&session_id=-4262354986382644304&xml=true > RESPONSE STATUS: HTTP/1.1 200 OK > RESPONSE HEADER: Server: Apache-Coyote/1.1 > RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 > RESPONSE HEADER: Date: Tue, 17 Sep 2013 17:49:16 GMT > RESPONSE HEADER: Connection: close > Exception in SecurityDomainLoginPanel(): java.lang.Exception: Invalid > clone_uri > ERROR: ConfigureSubCA: SecurityDomainLoginPanel() failure > ERROR: unable to create CA > > ####################################################################### > > 2013-09-17T17:49:17Z DEBUG stderr=java.lang.Exception: Invalid clone_uri > at ConfigureCA.SecurityDomainLoginPanel(ConfigureCA.java:392) > at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1188) > at ConfigureCA.main(ConfigureCA.java:1672) > > 2013-09-17T17:49:17Z CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > ipa04.testdomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-krRAM2 > -client_certdb_pwd XXXXXXXX -preop_pin 2e3Wsf8VDR8lEXLi3HyX > -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=VANCPOWER.COM -ldap_host ipa04.testdomain.com > -ldap_port 7389 -bind_dn cn=Directory Manager -bind_password XXXXXXXX > -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa > -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX > -subsystem_name pki-cad -token_name internal > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=VANCPOWER.COM > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=VANCPOWER.COM > -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=VANCPOWER.COM > -ca_server_cert_subject_name CN=ipa04.testdomain.com,O=VANCPOWER.COM > -ca_audit_signing_cert_subject_name CN=CA Audit,O=VANCPOWER.COM > -ca_sign_cert_subject_name CN=Certificate Authority,O=VANCPOWER.COM > -external false -clone true -clone_p12_file ca.p12 -clone_p12_password > XXXXXXXX -sd_hostname ipa00.testdomain.com -sd_admin_port 443 > -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true > -clone_uri https://ipa00.testdomain.com:443' returned non-zero exit > status 255 > 2013-09-17T17:49:17Z INFO File > "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", > line 614, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-replica-install", line 467, in main > (CA, cs) = cainstance.install_replica_ca(config) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", > line 1604, in install_replica_ca > subject_base=config.subject_base) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", > line 617, in configure_instance > self.start_creation(runtime=210) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", line > 358, in start_creation > method() > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", > line 879, in __configure_instance > raise RuntimeError('Configuration of CA failed') > > 2013-09-17T17:49:17Z INFO The ipa-replica-install command failed, > exception: RuntimeError: Configuration of CA failed > > ___ > > In the event that there is no recovery from this short of rebuilding > the master, is there a way for me to repopulate it with existing data > from the name server and user store? As always, your help is greatly > appreciated. Nathan, do you think it is a problem with IPA replica management or Dogtag? > > > Thanks. > > > > Trevor T. Kates > > *CONFIDENTIALITY NOTICE:* This electronic message contains information > which may be legally confidential and/or privileged and does not in > any case represent a firm ENERGY COMMODITY bid or offer relating > thereto which binds the sender without an additional express written > confirmation to that effect. The information is intended solely for > the individual or entity named above and access by anyone else is > unauthorized. If you are not the intended recipient, any disclosure, > copying, distribution, or use of the contents of this information is > prohibited and may be unlawful. If you have received this electronic > transmission in error, please reply immediately to the sender that you > have received the message in error, and delete it. Thank you. > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Sep 20 15:36:10 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Sep 2013 11:36:10 -0400 Subject: [Freeipa-users] Recomendations on multi-domain environments In-Reply-To: References: <52399120.1070804@cica.es> Message-ID: <523C6B6A.8000600@redhat.com> On 09/18/2013 07:55 AM, Andrew Lau wrote: > > On Wed, Sep 18, 2013 at 9:40 PM, Arturo Borrero > wrote: > > Hi there! > > This is my situation. > > I have some users of my main domain "cica.es ". > > But I also maintain a database of users of others domain, ie > "example.es ". > > I can apply most of FreeIPA configuration to "cica.es > " users: access to hosts, groups, policies, roles, > etc.. > > But users of "example.es " are dummy users, who > just have an LDAP account in order to use virtual mailboxes in > Postfix/Dovecot. > > Do anyone have any advice on how handle this situation? > > I see some options: > * create a second FreeIPA server, each to handle his own domain. > * get the main FreeIPA server to handle two complete different > LDAP tree (with different root DNs, don't know if possible). > * integrate "example.es " users into specific > groups, "prefix" or something each group and user. > > We are talking of about 2k users in total (main domain + secondary > domain). In addition, there is the possibility to have more than > two domains. > > How FreeIPA handles this multi-domain environment? > > Best regards. > > -- > > > If your second domain is just for LDAP (this is a little similar to > what I did). It's not a fluid as you end up limited to the two domains.. . > > Keep the FreeIPA for hosting cica.es to do your host > polices etc. Then on your virtual mailboxes two options we did was either: > > - Change the default mail atribute in FreeIPA settings so a user would > have user.name at example.es rather > than user.domain at cica.es in their mail > attribute then have the LDAP config lookup that rather than username > - The other simple alternative is simply have LDAP search the username > and append @example.es or not at all. > > HTH > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users I am not sure that the answer above is 100% relevant to what has been asked. The question was "should I merge two domains or keep them separate, and if I merger the users into IPA how should I do it to be able to differentiate users from two different original sources". At least this is how I interpreted the question. I would say "it depends". 1) Are the users in two domains are same users? If yes then you should follow advice above and merge. 2) If users are actually different users then I would keep the two namespaces separate and not merge. If you merge you would be able to use groups and prefixes and may be special attributes but would not be able to put users into different sub trees. Well... you can... but the rest of the IPA would not see them if you do it right or might be confused if you do it wrong. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Sep 20 15:38:13 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Sep 2013 11:38:13 -0400 Subject: [Freeipa-users] Replica of a Replica and Master Recovery In-Reply-To: References: Message-ID: <523C6BE5.2040500@redhat.com> Trevor T Kates (Services - 6) wrote: > I apologize for the weird subject. The problem I'm facing feels a little > weird and I could use some help. > > I'm running IPA in a test environment and trying to find different ways > in which I can break it and then repair it. My IPA is running on CentOS 6.4: > > Linux ipa00.testdomain.com 2.6.32-358.18.1.el6.x86_64 #1 SMP Wed Aug 28 > 17:19:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > bind-9.8.2-0.17.rc1.el6_4.6.x86_64 > bind-dyndb-ldap-2.3-2.el6_4.1.x86_64 > ipa-server-3.0.0-26.el6_4.4.x86_64 > > I seem to have created a problem for myself involving the original > master server. At the beginning, I created a master IPA server with the > dogtag CA and several replicas with replica dogtag CAs. I stored the > /root/cacert.p12 file in a backup, reimaged the original master and > turned it into a replica. In doing so, I seem to have eliminated my > ability to create additional replicas due to not completely backing up > everything related to the CA on the master. After preparing a replica on > my reimaged master and attemping to install it on a different test > server, I ran into the following error: I think some clarification is needed. Every server in IPA is a master, on equal footing with the exception of some optional services like the CA and DNS. The initial CA is also responsible for CRL generation and distributing renewed certificates, but those can be moved. I think we need to know what state the machine is in an how it got there. What does reimaging mean in this case? rob > > [root at ipa04 ~]# ipa-replica-install --setup-ca -N --setup-dns > /var/lib/ipa/replica-info-ipa04.testdomain.com.gpg > Directory Manager (existing master) password: > > Run connection check to master > Check connection from replica to remote master 'ipa00.testdomain.com': > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): OK > Kerberos KDC: TCP (88): OK > Kerberos Kpasswd: TCP (464): OK > HTTP Server: Unsecure port (80): OK > HTTP Server: Secure port (443): OK > PKI-CA: Directory Service port (7389): OK > > The following list of ports use UDP protocol and would need to be > checked manually: > Kerberos KDC: UDP (88): SKIPPED > Kerberos Kpasswd: UDP (464): SKIPPED > > Connection from replica to master is OK. > Start listening on required ports for remote master check > Get credentials to log in to remote master > admin at TESTDOMAIN.COM password: > > Execute check on remote master > admin at ipa00.testdomain.com's password: > Check connection from master to remote replica 'ipa04.testdomain.com': > Directory Service: Unsecure port (389): OK > Directory Service: Secure port (636): OK > Kerberos KDC: TCP (88): OK > Kerberos KDC: UDP (88): OK > Kerberos Kpasswd: TCP (464): OK > Kerberos Kpasswd: UDP (464): OK > HTTP Server: Unsecure port (80): OK > HTTP Server: Secure port (443): OK > PKI-CA: Directory Service port (7389): OK > > Connection from master to replica is OK. > > Connection check OK > Configuring directory server for the CA (pkids): Estimated time 30 seconds > [1/3]: creating directory server user > [2/3]: creating directory server instance > [3/3]: restarting directory server > Done configuring directory server for the CA (pkids). > Configuring certificate server (pki-cad): Estimated time 3 minutes 30 > seconds > [1/17]: creating certificate server user > [2/17]: creating pki-ca instance > [3/17]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > ipa04.testdomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-krRAM2 > -client_certdb_pwd XXXXXXXX -preop_pin 2e3Wsf8VDR8lEXLi3HyX -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=TESTDOMAIN.COM -ldap_host > ipa04.testdomain.com -ldap_port 7389 -bind_dn cn=Directory Manager > -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 > -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd > XXXXXXXX -subsystem_name pki-cad -token_name internal > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=TESTDOMAIN.COM > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=TESTDOMAIN.COM > -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=TESTDOMAIN.COM > -ca_server_cert_subject_name CN=ipa04.testdomain.com,O=TESTDOMAIN.COM > -ca_audit_signing_cert_subject_name CN=CA Audit,O=TESTDOMAIN.COM > -ca_sign_cert_subject_name CN=Certificate Authority,O=TESTDOMAIN.COM > -external false -clone true -clone_p12_file ca.p12 -clone_p12_password > XXXXXXXX -sd_hostname ipa00.testdomain.com -sd_admin_port 443 > -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true > -clone_uri https://ipa00.testdomain.com:443' returned non-zero exit > status 255 > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Configuration of CA failed > > ___ > /var/log/ipareplica-install.log: > > ############################################# > Attempting to connect to: ipa04.testdomain.com:9445 > Connected. > Posting Query = > https://ipa04.testdomain.com:9445//ca/admin/console/config/wi > zard?p=5&subsystem=CA&session_id=-4262354986382644304&xml=true > RESPONSE STATUS: HTTP/1.1 200 OK > RESPONSE HEADER: Server: Apache-Coyote/1.1 > RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 > RESPONSE HEADER: Date: Tue, 17 Sep 2013 17:49:16 GMT > RESPONSE HEADER: Connection: close > Exception in SecurityDomainLoginPanel(): java.lang.Exception: Invalid > clone_uri > ERROR: ConfigureSubCA: SecurityDomainLoginPanel() failure > ERROR: unable to create CA > > ####################################################################### > > 2013-09-17T17:49:17Z DEBUG stderr=java.lang.Exception: Invalid clone_uri > at ConfigureCA.SecurityDomainLoginPanel(ConfigureCA.java:392) > at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1188) > at ConfigureCA.main(ConfigureCA.java:1672) > > 2013-09-17T17:49:17Z CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > ipa04.testdomain.com -cs_port 9445 -client_certdb_dir /tmp/tmp-krRAM2 > -client_certdb_pwd XXXXXXXX -preop_pin 2e3Wsf8VDR8lEXLi3HyX -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=VANCPOWER.COM -ldap_host > ipa04.testdomain.com -ldap_port 7389 -bind_dn cn=Directory Manager > -bind_password XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 > -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd > XXXXXXXX -subsystem_name pki-cad -token_name internal > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=VANCPOWER.COM > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=VANCPOWER.COM > -ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=VANCPOWER.COM > -ca_server_cert_subject_name CN=ipa04.testdomain.com,O=VANCPOWER.COM > -ca_audit_signing_cert_subject_name CN=CA Audit,O=VANCPOWER.COM > -ca_sign_cert_subject_name CN=Certificate Authority,O=VANCPOWER.COM > -external false -clone true -clone_p12_file ca.p12 -clone_p12_password > XXXXXXXX -sd_hostname ipa00.testdomain.com -sd_admin_port 443 > -sd_admin_name admin -sd_admin_password XXXXXXXX -clone_start_tls true > -clone_uri https://ipa00.testdomain.com:443' returned non-zero exit > status 255 > 2013-09-17T17:49:17Z INFO File > "/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py", > line 614, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-replica-install", line 467, in main > (CA, cs) = cainstance.install_replica_ca(config) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line > 1604, in install_replica_ca > subject_base=config.subject_base) > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line > 617, in configure_instance > self.start_creation(runtime=210) > > File "/usr/lib/python2.6/site-packages/ipaserver/install/service.py", > line 358, in start_creation > method() > > File > "/usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py", line > 879, in __configure_instance > raise RuntimeError('Configuration of CA failed') > > 2013-09-17T17:49:17Z INFO The ipa-replica-install command failed, > exception: RuntimeError: Configuration of CA failed > > ___ > > In the event that there is no recovery from this short of rebuilding the > master, is there a way for me to repopulate it with existing data from > the name server and user store? As always, your help is greatly appreciated. > > > Thanks. > > > > Trevor T. Kates > > *CONFIDENTIALITY NOTICE:* This electronic message contains information > which may be legally confidential and/or privileged and does not in any > case represent a firm ENERGY COMMODITY bid or offer relating thereto > which binds the sender without an additional express written > confirmation to that effect. The information is intended solely for the > individual or entity named above and access by anyone else is > unauthorized. If you are not the intended recipient, any disclosure, > copying, distribution, or use of the contents of this information is > prohibited and may be unlawful. If you have received this electronic > transmission in error, please reply immediately to the sender that you > have received the message in error, and delete it. Thank you. > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From dpal at redhat.com Fri Sep 20 15:48:03 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Sep 2013 11:48:03 -0400 Subject: [Freeipa-users] Elliptic curves with the CA In-Reply-To: References: , <5237B518.6060808@redhat.com> Message-ID: <523C6E33.90302@redhat.com> On 09/18/2013 01:53 PM, mees virk wrote: > I do not have a valid support contract, or other contracts with > RedHat. Doesn't that stop me from opening proper RFE ticket? > > In any case, my interest was this time solely for evaluation purposes. > If I were actively choosing an integrated identity management product, > I might not choose Freeipa because it takes the longevity of the > product and the development stance (lack of roadmap?) into question. I wonder where the lack of roadmap came from? http://www.freeipa.org/page/Roadmap So the trac system we use gives a good view of the dynamics of the project https://fedorahosted.org/freeipa/roadmap However IMO disconnect in expectations is that support of the ECC is not exactly FreeIPA's problem (yet). It needs to be implemented by the lower levels of the stack first: NSS, Dogtag etc. We have plans for support of the certs for users and we understand that RSA becomes outdated. Your RFE would allow us to track your specific requirements and interest (and make it our problem). Right now the position is that: let the underlying components grow ECC suppoirt and consume this functionality in FreeIPA when it matures. Filing an RFE would change this dynamics and would signal us that there is interest in the community in the actual end point solution, i.e. FreeIPA supporting ECC. Thanks! > > RSA is slowly getting into slippery slope, because it really isn't > about what it's worth today. When you protect something with a > cryptographic algorithm you have to take account for how long certain > types of data will be stored, and factor that time frame in. > Increasing the key sizes will not be solution, because several > embedded devices such as VPN products, smartcards and RFID devices > will start failing pretty fast after 1024-2048 bit keys. > > ECC was designed to solve some of these issues; it's important > development not mostly because of security today but because it will > scale better up (it was designed to be implementable better on > hardware), and the key sizes start from nicer point of security vs > size. So it's the feature that would future proof the CA. At this > moment there is available ECC support on some products on all the > areas such as smart cards, so the products not having that option out > of the box will start basically losing in the competition. > > I'm not trying to make a technical point here (if I made some minor > error there, sorry) but a managerial, and from product management > viewpoint. ECC must be on the feature set, or the CA features will be > discarded in the future by potential users. That means the Freeipa as > a whole might not be selected for some projects. Plus, it doesn't > really hurt having ECC in. :) > > ------------------------------------------------------------------------ > > > > IPA uses NSS, NSS support of ECC algorithms is very fresh, we have not > looked at this area yet. > I suspect it would require changes in Dogtag first. > > Would be best if you can file and RFE ticket, then we would be able to > follow up. > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Sep 20 15:51:22 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Sep 2013 11:51:22 -0400 Subject: [Freeipa-users] ipa-client auth with windomain account In-Reply-To: References: Message-ID: <523C6EFA.4080606@redhat.com> On 09/18/2013 11:42 AM, ?????? ? wrote: > Hi, > Do I need network access to ports from the ipa-client to the server- > windows for authentication with windomain accounts? > ipa-server fedora19 > ipa-client fedora19 > winserver win2012 > the ipa-client is located in another network > within the network ipa-server, ipa-client and windows-server > authentication works > to the ipa-client: > #id windomainuser at windomain > id: windomainuser at windomain: No such user > please tell me what I'm doing wrong > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users We need to understand more about your setup. Are you using trusts? What is your DNS configuration? Generally if you are using trusts than clients should be able to resolve AD server and connect to it. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Sep 20 16:02:22 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Sep 2013 12:02:22 -0400 Subject: [Freeipa-users] Fwd: Windows, Samba and IPA In-Reply-To: References: Message-ID: <523C718E.4060808@redhat.com> On 09/20/2013 07:33 AM, Fred van Zwieten wrote: > Hi, > > I wonder if it is possible to have Windows clients (member of some > domain) to connect to SAMBA shares with an IPA account. I found > various howto's voor Kerberized SAMBA but they al use Linux as the > client platform. I have tried to set it up using a Red Hat Solution > article, but I did not get it to work. > > Is it possible without using trust or synchronization between AD and > IPA? If yes, how? > > Fred > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users So the setup is: AD and IPA not in trust or sync There is an IPA user logging into Windows client in AD domain and trying to access Samba share in which domain? I mean is Samba a member server in AD domain or IPA? Anyways it would not work. What should work is: * User from AD accessing a samba share in AD domain (this is the setup in the documentation that you refer to). * User from IPA accessing samba share in IPA domain using Linux client (I think that has been possible in the past) Other scenarios would not work yet AFAIU because: 1) IPA does not provide global catalog yet 2) Samba FS and IPA integration as a member server in trust setup is not ready to serve users from a trusted domains. There is some work to be done there. Both are on the roadmap but not available right now. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Sep 20 16:07:49 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Sep 2013 12:07:49 -0400 Subject: [Freeipa-users] Joining a Windows Workstation to an IPA realm (It works better than expected!) In-Reply-To: <20130920150108.GI4216@redhat.com> References: <1379687481.27594.28.camel@toron.pzo.lgs.com.ve> <20130920150108.GI4216@redhat.com> Message-ID: <523C72D5.1040606@redhat.com> On 09/20/2013 11:01 AM, Alexander Bokovoy wrote: > On Fri, 20 Sep 2013, Loris Santamaria wrote: >> Hi all, >> >> yesterday I was going to try puppet on windows, so I fired up a Windows >> 7 VM, and just for curiosity, instead of joining it to the AD realm, i >> decided to try the instructions outlined in the wiki to join the machine >> to the IPA realm: >> http://www.freeipa.org/page/Windows_authentication_against_FreeIPA >> >> So I went with the instructions, on the windows Workstation. >> >> ksetup /setdomain [REALM NAME] >> ksetup /addkdc [REALM NAME] [kdc DNS name] >> ksetup /addkpassword [REALM NAME] [kdc DNS name] >> ksetup /setcomputerpassword [MACHINE_PASSWORD] (the one used above) >> ksetup /mapuser * * >> >> Next, the instructions tell you to create Windows local users >> corresponding to the IPA kerberos realm users, because you know, >> kerberos only does authentication and it can tell nothing to the windows >> workstation about the identity of the user... However, just for kicks, I >> rebooted the VM and _without creating any local user_ I tried to login >> with myuser at IPA.REALM ? And it worked! It created a profile directory, >> showed my full name on the start menu. Then I tried to browse the web >> and SSO with squid worked like a charm, SSO with putty worked and I even >> logged in to the IPA administration page with my ticket. >> >> But it wasn't supposed to work without creating a local user... why it >> was working then? >> >> Please notice this, the IPA realm has a trust with the AD realm, so >> samba 4 is running on the IPA servers and every user in the IPA realm >> has a SID assigned... and its ticket comes with a PAC, I think that is >> the important part. > Exactly. You actually don't need to create the trust, just run > ipa-adtrust-install to make sure IPA's infrastructure is configured to > issue SIDs and accept them. > >> >> Finally, what worked and what don't: >> >> * I was able to login on Win 7 with an IPA user and having a local >> profile created automatically >> * I was able to perform SSO authentication with IPA services >> * I was able to add my IPA user to the "Administrators" group in >> windows, with the NET LOCALGROUP command. >> * I couldn't add the IPA "admins" group to the "Administrators" >> group. With "NET LOCALGROUP Administrators IPA\admins /add" it >> tells me that it doesn't recognise the IPA\admins group. > Right, because it doesn't know where to look up translation between > IPA\admins string and SID as you haven't really configured Windows PC to > be part of the domain and IPA domain doesn't provide services Windows PC > expect to be there by default for resolving user/group to SIDs in Active > Directory. > >> * I couldn't add other IPA users to the Administrators group, only >> my logged in user. > Same here. > >> * I can't add IPA users to group with the graphical administration >> tools, they won't show the IPA realm, only the NET command >> worked somehow > Same here. Windows UIs rely on AD global catalog service which we don't > implement. > > >> I'm investigating why Windows can't see IPA users and group other than >> the currently logged in user, but I suspect that is simply because >> Windows takes the logged in user SID from the PAC and it doesn't really >> talk to samba4. > Yep, only that it doesn't know where to talk as there is no proper > service available. > > Loris, This is a great input! Thanks for investigation, it is really helpful! Alexander, So when we add GC support in IPA how would the picture change? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From alee at redhat.com Fri Sep 20 16:09:08 2013 From: alee at redhat.com (Ade Lee) Date: Fri, 20 Sep 2013 12:09:08 -0400 Subject: [Freeipa-users] Elliptic curves with the CA In-Reply-To: <523C6E33.90302@redhat.com> References: , <5237B518.6060808@redhat.com> <523C6E33.90302@redhat.com> Message-ID: <1379693348.12743.4.camel@aleeredhat.laptop> As a partial answer to this, work has been ongoing to fully support ECC in Dogtag. Attached is a most likely out-of-date wiki page detailing ECC support in Dogtag. https://pki.fedoraproject.org/wiki/ECC_in_Dogtag If I recall correctly, we are somewhere around phase 3. Ade On Fri, 2013-09-20 at 11:48 -0400, Dmitri Pal wrote: > On 09/18/2013 01:53 PM, mees virk wrote: > > I do not have a valid support contract, or other contracts with > > RedHat. Doesn't that stop me from opening proper RFE ticket? > > > > In any case, my interest was this time solely for evaluation > > purposes. If I were actively choosing an integrated identity > > management product, I might not choose Freeipa because it takes the > > longevity of the product and the development stance (lack of > > roadmap?) into question. > > > > I wonder where the lack of roadmap came from? > http://www.freeipa.org/page/Roadmap > So the trac system we use gives a good view of the dynamics of the > project > https://fedorahosted.org/freeipa/roadmap > > However IMO disconnect in expectations is that support of the ECC is > not exactly FreeIPA's problem (yet). > It needs to be implemented by the lower levels of the stack first: > NSS, Dogtag etc. > We have plans for support of the certs for users and we understand > that RSA becomes outdated. > Your RFE would allow us to track your specific requirements and > interest (and make it our problem). > > Right now the position is that: let the underlying components grow ECC > suppoirt and consume this functionality in FreeIPA when it matures. > Filing an RFE would change this dynamics and would signal us that > there is interest in the community in the actual end point solution, > i.e. FreeIPA supporting ECC. > > Thanks! > > > > > RSA is slowly getting into slippery slope, because it really isn't > > about what it's worth today. When you protect something with a > > cryptographic algorithm you have to take account for how long > > certain types of data will be stored, and factor that time frame in. > > Increasing the key sizes will not be solution, because several > > embedded devices such as VPN products, smartcards and RFID devices > > will start failing pretty fast after 1024-2048 bit keys. > > > > ECC was designed to solve some of these issues; it's important > > development not mostly because of security today but because it will > > scale better up (it was designed to be implementable better on > > hardware), and the key sizes start from nicer point of security vs > > size. So it's the feature that would future proof the CA. At this > > moment there is available ECC support on some products on all the > > areas such as smart cards, so the products not having that option > > out of the box will start basically losing in the competition. > > > > I'm not trying to make a technical point here (if I made some minor > > error there, sorry) but a managerial, and from product management > > viewpoint. ECC must be on the feature set, or the CA features will > > be discarded in the future by potential users. That means the > > Freeipa as a whole might not be selected for some projects. Plus, it > > doesn't really hurt having ECC in. :) > > > > > > ____________________________________________________________________ > > > > > > > > IPA uses NSS, NSS support of ECC algorithms is very fresh, we have > > not looked at this area yet. > > I suspect it would require changes in Dogtag first. > > > > Would be best if you can file and RFE ticket, then we would be able > > to follow up. > > > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From trevor.t.kates at dom.com Fri Sep 20 19:20:34 2013 From: trevor.t.kates at dom.com (Trevor T Kates (Services - 6)) Date: Fri, 20 Sep 2013 19:20:34 +0000 Subject: [Freeipa-users] Replica of a Replica and Master Recovery In-Reply-To: <523C6BE5.2040500@redhat.com> References: , <523C6BE5.2040500@redhat.com> Message-ID: > From: Rob Crittenden [rcritten at redhat.com] > Sent: Friday, September 20, 2013 11:38 AM > To: Trevor T Kates (Services - 6); freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Replica of a Replica and Master Recovery > -snip- > > I think some clarification is needed. Every server in IPA is a master, > on equal footing with the exception of some optional services like the > CA and DNS. The initial CA is also responsible for CRL generation and > distributing renewed certificates, but those can be moved. > > I think we need to know what state the machine is in an how it got > there. What does reimaging mean in this case? Thanks for responding and sorry for the ambiguity. This was the order of events: kickstart -> ipa as ipa.testdomain.com kickstart -> ipa00 as ipa00.testdomain.com ipa-server-install with CA and DNS ipa-replica-prepare ipa00.testdomain.com ipa-replica-install ipa00 with CA and DNS on ipa: copy /root/cacert.p12 to ipa00 on ipa00: ipa-replica-manage del ipa.testdomain.com kickstart -> ipa as ipa04.testdomain.com on ipa00: ipa-replica-prepare ipa04.testdomain.com on ipa04: ipa-replica-install with CA and DNS CA error and replica install fails Let me know if I need to provide better information and thank you very much for the help! > rob > > -snip- Trevor T. Kates CONFIDENTIALITY NOTICE: This electronic message contains information which may be legally confidential and/or privileged and does not in any case represent a firm ENERGY COMMODITY bid or offer relating thereto which binds the sender without an additional express written confirmation to that effect. The information is intended solely for the individual or entity named above and access by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. From abokovoy at redhat.com Fri Sep 20 19:55:24 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 20 Sep 2013 22:55:24 +0300 Subject: [Freeipa-users] Joining a Windows Workstation to an IPA realm (It works better than expected!) In-Reply-To: <523C72D5.1040606@redhat.com> References: <1379687481.27594.28.camel@toron.pzo.lgs.com.ve> <20130920150108.GI4216@redhat.com> <523C72D5.1040606@redhat.com> Message-ID: <20130920195524.GJ4216@redhat.com> On Fri, 20 Sep 2013, Dmitri Pal wrote: >On 09/20/2013 11:01 AM, Alexander Bokovoy wrote: >> On Fri, 20 Sep 2013, Loris Santamaria wrote: >>> Hi all, >>> >>> yesterday I was going to try puppet on windows, so I fired up a Windows >>> 7 VM, and just for curiosity, instead of joining it to the AD realm, i >>> decided to try the instructions outlined in the wiki to join the machine >>> to the IPA realm: >>> http://www.freeipa.org/page/Windows_authentication_against_FreeIPA >>> >>> So I went with the instructions, on the windows Workstation. >>> >>> ksetup /setdomain [REALM NAME] >>> ksetup /addkdc [REALM NAME] [kdc DNS name] >>> ksetup /addkpassword [REALM NAME] [kdc DNS name] >>> ksetup /setcomputerpassword [MACHINE_PASSWORD] (the one used above) >>> ksetup /mapuser * * >>> >>> Next, the instructions tell you to create Windows local users >>> corresponding to the IPA kerberos realm users, because you know, >>> kerberos only does authentication and it can tell nothing to the windows >>> workstation about the identity of the user... However, just for kicks, I >>> rebooted the VM and _without creating any local user_ I tried to login >>> with myuser at IPA.REALM ? And it worked! It created a profile directory, >>> showed my full name on the start menu. Then I tried to browse the web >>> and SSO with squid worked like a charm, SSO with putty worked and I even >>> logged in to the IPA administration page with my ticket. >>> >>> But it wasn't supposed to work without creating a local user... why it >>> was working then? >>> >>> Please notice this, the IPA realm has a trust with the AD realm, so >>> samba 4 is running on the IPA servers and every user in the IPA realm >>> has a SID assigned... and its ticket comes with a PAC, I think that is >>> the important part. >> Exactly. You actually don't need to create the trust, just run >> ipa-adtrust-install to make sure IPA's infrastructure is configured to >> issue SIDs and accept them. >> >>> >>> Finally, what worked and what don't: >>> >>> * I was able to login on Win 7 with an IPA user and having a local >>> profile created automatically >>> * I was able to perform SSO authentication with IPA services >>> * I was able to add my IPA user to the "Administrators" group in >>> windows, with the NET LOCALGROUP command. >>> * I couldn't add the IPA "admins" group to the "Administrators" >>> group. With "NET LOCALGROUP Administrators IPA\admins /add" it >>> tells me that it doesn't recognise the IPA\admins group. >> Right, because it doesn't know where to look up translation between >> IPA\admins string and SID as you haven't really configured Windows PC to >> be part of the domain and IPA domain doesn't provide services Windows PC >> expect to be there by default for resolving user/group to SIDs in Active >> Directory. >> >>> * I couldn't add other IPA users to the Administrators group, only >>> my logged in user. >> Same here. >> >>> * I can't add IPA users to group with the graphical administration >>> tools, they won't show the IPA realm, only the NET command >>> worked somehow >> Same here. Windows UIs rely on AD global catalog service which we don't >> implement. >> >> >>> I'm investigating why Windows can't see IPA users and group other than >>> the currently logged in user, but I suspect that is simply because >>> Windows takes the logged in user SID from the PAC and it doesn't really >>> talk to samba4. >> Yep, only that it doesn't know where to talk as there is no proper >> service available. >> >> >Loris, > >This is a great input! Thanks for investigation, it is really helpful! > >Alexander, > >So when we add GC support in IPA how would the picture change? For AD domains trusted by IPA, this would solve all problems stated above (they are the same for both in-domain and out-of-domain Windows PCs). For out-of-domain Windows PC I'd like to see some network traces to identify whether it tries to search for a GC server associated with the Kerberos domain or not. If it does, we can be closer to the solution. If not, then a local mapping will have to happen somehow. -- / Alexander Bokovoy From cbulist at gmail.com Fri Sep 20 20:50:28 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Fri, 20 Sep 2013 15:50:28 -0500 Subject: [Freeipa-users] slapi-nis bypass Password Policies In-Reply-To: <1379647683.19525.15.camel@willson.li.ssimo.org> References: <5239DC28.8070203@gmail.com> <1379647683.19525.15.camel@willson.li.ssimo.org> Message-ID: <523CB514.3050809@gmail.com> Hi Simon, The first option. I would like to be able to continue to authenticate even if the passwords are expired. It sounds crazy but we need to accomplish that just for one service. Thanks in advance! On 09/19/2013 10:28 PM, Simo Sorce wrote: > On Wed, 2013-09-18 at 12:00 -0500, cbulist at gmail.com wrote: >> Hi, >> >> We have a client server connected to the IPA server using NIS. It's >> working well but we have a service running at client server that doesn't >> handle the password expiration properly. >> Is it possible to bypass the Password Policies from this client server? > I am not sure I understand in what way you'd want to bypass them. > > You'd like to be able to continue to authenticate even if the passwords > are expired ? > Or you just want to avoid being sent password expiration messages ? > > Simo. > From JR.Aquino at citrix.com Fri Sep 20 21:10:36 2013 From: JR.Aquino at citrix.com (JR Aquino) Date: Fri, 20 Sep 2013 21:10:36 +0000 Subject: [Freeipa-users] slapi-nis bypass Password Policies In-Reply-To: <5239DC28.8070203@gmail.com> References: <5239DC28.8070203@gmail.com> Message-ID: <4C51E5D7-C9A1-436E-8C12-77C217278A4B@citrixonline.com> Is your client simply using LDAP to bind and authenticate your service? If so, you may be able to create a special dedicated sysaccount in: cn=sysaccounts,cn=etc,dc=domain,dc=com This account could be used to bind your service without having it be a member of the standard users database subjected to Password Policy expirations etc. "You cannot hope to secure that which you do not first understand" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jr Aquino | Sr. Information Security Specialist GXPN | GIAC Exploit Researcher and Advanced Penetration Tester GCIH | GIAC Certified Incident Handler GWAPT | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 C: +1 805.717.0365 jr.aquino at citrix.com http://www.citrixonline.com On Sep 18, 2013, at 10:00 AM, cbulist at gmail.com wrote: Hi, We have a client server connected to the IPA server using NIS. It's working well but we have a service running at client server that doesn't handle the password expiration properly. Is it possible to bypass the Password Policies from this client server? Thanks! _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From fvzwieten at vxcompany.com Sat Sep 21 09:36:11 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Sat, 21 Sep 2013 11:36:11 +0200 Subject: [Freeipa-users] IPA, Samba and AD In-Reply-To: <20130703141944.GA7273@redhat.com> References: <20130703091127.GN24422@vda.li> <20130703141944.GA7273@redhat.com> Message-ID: OK, I know this is an old thread, but I just got a new idea. What if I create a NT4 style domain on our SAMBA servers, So I have a Samba NT4 style PDC. Then I create a NT4 style trust with the AD domain. This way, I don't use kerberos nor DNS SRV records, both of which are needed if I would go the AD route. But now, users from the AD domain can access Samba shares. Correct? Fred On Wed, Jul 3, 2013 at 4:19 PM, Alexander Bokovoy wrote: > On Wed, 03 Jul 2013, Fred van Zwieten wrote: > >1. Do you have the same realms for both IPA and AD? > >Yes. > > > >2. Do you have exactly same DNS domains for both IPA and AD? > >Also yes. Because of this we must, for now, maintain 2 seperate DNS > >implementations: one for AD and one for IPA, because otherwise the service > >records would name-clash. > > > >If I get correctly from the above description, your new RHEL 6.4 server > >is enrolled into IPA domain, i.e. its host keytab contains keys to > >the host service coming from IPA KDC. It probably also uses SSSD in both > >nsswitch and PAM configurations? > >Correct! > > > >Are you planning to use pam_winbind/nss_winbind for the Samba/AD > >interoperability? > >I don't know yet. It depends on what works best with this setup. I am not > >(yet) a Samba wunderguy, so these discussions help me (thanks for that). > I'm not sure that this configuration will work flawlessly. > > If the host is not enrolled to IPA realm, you can easily make it > working against AD domain. If you enrolled the host to IPA realm which > is exactly same as AD domain, both DNS and krb5.conf collisions will be > creating quite serious issues. Basically, it is 'either - either' case. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sat Sep 21 09:51:30 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 21 Sep 2013 12:51:30 +0300 Subject: [Freeipa-users] IPA, Samba and AD In-Reply-To: References: <20130703091127.GN24422@vda.li> <20130703141944.GA7273@redhat.com> Message-ID: <20130921095130.GM4216@redhat.com> On Sat, 21 Sep 2013, Fred van Zwieten wrote: >OK, > >I know this is an old thread, but I just got a new idea. > >What if I create a NT4 style domain on our SAMBA servers, So I have a Samba >NT4 style PDC. Then I create a NT4 style trust with the AD domain. This >way, I don't use kerberos nor DNS SRV records, both of which are needed if >I would go the AD route. But now, users from the AD domain can access Samba >shares. > >Correct? This is not supported yet. We only now working on making subdomains of an AD trust supported in FreeIPA 3.4. However, that only includes normal Kerberos-based domains since the whole trust story is around Kerbreros trust. Samba work on full trust support is on roadmap -- https://wiki.samba.org/index.php/Samba_Next_Goals#Trust_support but there is quite a lot work to acomplish all needed goals. Once that part is done, Samba AD domains will be supporting cross-forest trusts and therefore will work with FreeIPA out of the box. -- / Alexander Bokovoy From fvzwieten at vxcompany.com Sat Sep 21 19:07:26 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Sat, 21 Sep 2013 21:07:26 +0200 Subject: [Freeipa-users] IPA, Samba and AD In-Reply-To: <20130921095130.GM4216@redhat.com> References: <20130703091127.GN24422@vda.li> <20130703141944.GA7273@redhat.com> <20130921095130.GM4216@redhat.com> Message-ID: Hold on. This has, in principle, nothing to do with FreeIPA. I have a SAMBA server that I make a NT-4 style PDC en build a trust with an AD domain. The only thing is that the SAMBA service runs on a server that is an IPA-client. In this setup the system is member of IPA and the SAMBA service running on it is member of it's own NT-4 Domain. Afaik NT-4 style domains do nothing with kerberos nor with DNS. So, no name clashes. Correct? Met vriendelijke groeten, * Fred van Zwieten * *Enterprise Open Source Services* * Consultant* *(woensdags afwezig)* *VX Company IT Services B.V.* *T* (035) 539 09 50 mobiel (06) 41 68 28 48 *F* (035) 539 09 08 *E* fvzwieten at vxcompany.com *I* www.vxcompany.com Seeing, contrary to popular wisdom, isn?t believing. It?s where belief stops, because it isn?t needed any more.. (Terry Pratchett) On Sat, Sep 21, 2013 at 11:51 AM, Alexander Bokovoy wrote: > On Sat, 21 Sep 2013, Fred van Zwieten wrote: > >OK, > > > >I know this is an old thread, but I just got a new idea. > > > >What if I create a NT4 style domain on our SAMBA servers, So I have a > Samba > >NT4 style PDC. Then I create a NT4 style trust with the AD domain. This > >way, I don't use kerberos nor DNS SRV records, both of which are needed if > >I would go the AD route. But now, users from the AD domain can access > Samba > >shares. > > > >Correct? > This is not supported yet. We only now working on making subdomains of > an AD trust supported in FreeIPA 3.4. However, that only includes normal > Kerberos-based domains since the whole trust story is around Kerbreros > trust. > > Samba work on full trust support is on roadmap -- > https://wiki.samba.org/index.php/Samba_Next_Goals#Trust_support but > there is quite a lot work to acomplish all needed goals. > > Once that part is done, Samba AD domains will be supporting cross-forest > trusts and therefore will work with FreeIPA out of the box. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sat Sep 21 20:30:26 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 21 Sep 2013 23:30:26 +0300 Subject: [Freeipa-users] IPA, Samba and AD In-Reply-To: References: <20130703091127.GN24422@vda.li> <20130703141944.GA7273@redhat.com> <20130921095130.GM4216@redhat.com> Message-ID: <20130921203026.GO4216@redhat.com> On Sat, 21 Sep 2013, Fred van Zwieten wrote: >Hold on. This has, in principle, nothing to do with FreeIPA. I have a SAMBA >server that I make a NT-4 style PDC en build a trust with an AD domain. The >only thing is that the SAMBA service runs on a server that is an >IPA-client. In this setup the system is member of IPA and the SAMBA service >running on it is member of it's own NT-4 Domain. Afaik NT-4 style domains >do nothing with kerberos nor with DNS. So, no name clashes. > >Correct? Sure. What this PDC would use as user/group/password databases? Existing FreeIPA setup does not provide you needed objectclasses to support ldapsam PASSDB module, we utilize different schema to store passwords and SIDs. If you have AD domain, you already can have trust with AD using features provided by FreeIPA 3.x. But you can join Windows PC already to that AD domain. What is purpose of making another NT4-style domain? Even if the NT4-style domain is there, would it be in forest with AD domain? If yes, then its members would only get access to FreeIPA resources with upcoming FreeIPA 3.4 where subdomains (domains of the trusted forest other than its root) would be supported -- again, with Kerberos only, since we don't use winbindd to perform lookups for the users in FreeIPA 3.3+. By definition that NT4-style domain would not support Kerberos, thus loosing way to follow trust path. If you don't have AD domain, making another NT4-style domain backed by the same FreeIPA database via some module and then force Windows PC to join the domain via that DC would in theory allow access to other FreeIPA services. I'm not sure though if this is going to work with Windows 7 and above as they are trying to resolve DNS and use SRV records first and prefer to follow AD join path if found, so you'd need to play firewall and other games with convincing them being off path. -- / Alexander Bokovoy From fvzwieten at vxcompany.com Sun Sep 22 16:09:22 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Sun, 22 Sep 2013 18:09:22 +0200 Subject: [Freeipa-users] IPA, Samba and AD In-Reply-To: <20130921203026.GO4216@redhat.com> References: <20130703091127.GN24422@vda.li> <20130703141944.GA7273@redhat.com> <20130921095130.GM4216@redhat.com> <20130921203026.GO4216@redhat.com> Message-ID: Well, as explained in this thread, the problem here is that we have an IPA domain named "MYCOMP.EDU" _and_ an AD domain named "MYCOMP.EDU" as well. Both have there own DNS servers. It's beyond the scope of this mail to explain why we have named them exactly the same, and we do wish we didn't, but this is the current situation. Migrating any of these to another domain name would be the best solution but would involve quite a lot of work. So now we have a bunch of SAMBA services running on RHEL6.4 boxes that are IPA-clients and we would like to give the AD users access to them. How to proceed? We cannot use an IPA - AD trust, because both domains have the same name. We also cannot make the SAMBA services member of the AD domain, because the server itself is an IPA-member and krb5.conf already points to the IPA servers for domain MYCOMP.EDU.. Also /etc/resolv points to the DNS services of IPA. See my problem? If not, read the whole mail thread.. It get's even more complicated. The AD "MYCOMP.EDU" domain has a trust with an AD "OTHERCOMP.EDU" and users in "OTHERCOMP.EDU" must access resource in " MYCOMP.EDU". There is a trust between the AD domain "MYCOMP.EDU" and the AD domain "OTHERCOMP.EDU". This works. We have some shares on a NetApp filer who is member of the AD domain "MYCOMP.EDU" and people from "OTHERCOMP.EDU" can successfully access those shares (given correct group membership offcourse). Now, we would like to have peoply in the AD domains "OTHERCOMP.EDU" and " MYCOMP.EDU" to access shares served by SAMBA services on RHEL64 machines that are IPA clients in the IPA domain "MYCOMP.EDU". As all out RHEL servers are IPA clients by default we also want the servers running SAMBA to stay IPA-clients for system level central administration of users, groups, sudo policies, hbac, etc. Now, how to proceed: I see 2 possible solutions (besides byting the bullet and name change one of the MYCOMP domains): Solution 1: Create an intermediary domain. This gives the following trust relationships: AD(OTHERCOMP.EDU) <--trusts-- AD(MYCOMP.EDU) <--trusts-- AD( MYCOMP-INTERMEDIARY.EDU) <--trusts-- IPA(MYCOMP.EDU). I don't like this one and I am not even sure it solves my problem. Another problem involves adding to (virtual) Windows boxes to maintain this domain. Solution 2: Make a SAMBA only domain. Make one of the SAMBA servers a PDC and one BDC. Make a NT-4 style trust to the AD domain MYCOMP.EDU. NT-4 style to have no Kerberos involvement as that is used for IPA. Also no DNS clashes as NT-4 style doesn't use DNS SRV records. AD(OTHERCOMP.EDU) <--trusts-- AD(MYCOMP.EDU) <--nt-4-trusts-- NT4(MYCOMP-SAMBA) Now, giving correct group memberships and all, users in OTHERCOMP.EDUshould be able to access shares in MYCOMP-SAMBA. Correct? -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sun Sep 22 16:35:53 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sun, 22 Sep 2013 19:35:53 +0300 Subject: [Freeipa-users] IPA, Samba and AD In-Reply-To: References: <20130703091127.GN24422@vda.li> <20130703141944.GA7273@redhat.com> <20130921095130.GM4216@redhat.com> <20130921203026.GO4216@redhat.com> Message-ID: <20130922163553.GQ4216@redhat.com> On Sun, 22 Sep 2013, Fred van Zwieten wrote: >Well, as explained in this thread, the problem here is that we have an IPA >domain named "MYCOMP.EDU" _and_ an AD domain named "MYCOMP.EDU" as well. >Both have there own DNS servers. It's beyond the scope of this mail to >explain why we have named them exactly the same, and we do wish we didn't, >but this is the current situation. Migrating any of these to another domain >name would be the best solution but would involve quite a lot of work. > >So now we have a bunch of SAMBA services running on RHEL6.4 boxes that are >IPA-clients and we would like to give the AD users access to them. How to >proceed? We cannot use an IPA - AD trust, because both domains have the >same name. We also cannot make the SAMBA services member of the AD domain, >because the server itself is an IPA-member and krb5.conf already points to >the IPA servers for domain MYCOMP.EDU.. Also /etc/resolv points to the DNS >services of IPA. > >See my problem? If not, read the whole mail thread.. Now I see it. From the original thread it wasn't reall clear and as I said in July, I'm not sure that configuration wed discussed at the time would work. >It get's even more complicated. The AD "MYCOMP.EDU" domain has a trust with >an AD "OTHERCOMP.EDU" and users in "OTHERCOMP.EDU" must access resource in " >MYCOMP.EDU". There is a trust between the AD domain "MYCOMP.EDU" and the AD >domain "OTHERCOMP.EDU". This works. We have some shares on a NetApp filer >who is member of the AD domain "MYCOMP.EDU" and people from "OTHERCOMP.EDU" >can successfully access those shares (given correct group membership >offcourse). > >Now, we would like to have peoply in the AD domains "OTHERCOMP.EDU" and " >MYCOMP.EDU" to access shares served by SAMBA services on RHEL64 machines >that are IPA clients in the IPA domain "MYCOMP.EDU". > >As all out RHEL servers are IPA clients by default we also want the servers >running SAMBA to stay IPA-clients for system level central administration >of users, groups, sudo policies, hbac, etc. > >Now, how to proceed: > >I see 2 possible solutions (besides byting the bullet and name change one >of the MYCOMP domains): > >Solution 1: >Create an intermediary domain. This gives the following trust relationships: > >AD(OTHERCOMP.EDU) <--trusts-- AD(MYCOMP.EDU) <--trusts-- AD( >MYCOMP-INTERMEDIARY.EDU) <--trusts-- IPA(MYCOMP.EDU). I don't like this one >and I am not even sure it solves my problem. Another problem involves >adding to (virtual) Windows boxes to maintain this domain. It wouldn't solve the problem since RHEL 6.4 version of FreeIPA does not support more than forest root domain for trust purposes right now. So only directly trusted domain in an AD forest would be seen and trusted. >Solution 2: >Make a SAMBA only domain. Make one of the SAMBA servers a PDC and one BDC. >Make a NT-4 style trust to the AD domain MYCOMP.EDU. NT-4 style to have no >Kerberos involvement as that is used for IPA. Also no DNS clashes as NT-4 >style doesn't use DNS SRV records. > >AD(OTHERCOMP.EDU) <--trusts-- AD(MYCOMP.EDU) <--nt-4-trusts-- >NT4(MYCOMP-SAMBA) > >Now, giving correct group memberships and all, users in >OTHERCOMP.EDUshould be able to access shares in MYCOMP-SAMBA. If you get IPA's user/group database behind your Samba install (which is currently not easy), and convince winbindd/smbd that a trusted domain is actually NT4 style too, that might work. The latter is a bit handwavy due to the way discovery is done in winbindd which might decide Kerberos is preferred by the trusting party... -- / Alexander Bokovoy From simo at redhat.com Sun Sep 22 20:37:57 2013 From: simo at redhat.com (Simo Sorce) Date: Sun, 22 Sep 2013 16:37:57 -0400 Subject: [Freeipa-users] IPA, Samba and AD In-Reply-To: References: <20130703091127.GN24422@vda.li> <20130703141944.GA7273@redhat.com> <20130921095130.GM4216@redhat.com> <20130921203026.GO4216@redhat.com> Message-ID: <1379882277.17271.10.camel@willson.li.ssimo.org> On Sun, 2013-09-22 at 18:09 +0200, Fred van Zwieten wrote: > Well, as explained in this thread, the problem here is that we have an > IPA domain named "MYCOMP.EDU" _and_ an AD domain named "MYCOMP.EDU" as > well. Both have there own DNS servers. It's beyond the scope of this > mail to explain why we have named them exactly the same, and we do > wish we didn't, but this is the current situation. Migrating any of > these to another domain name would be the best solution but would > involve quite a lot of work. > > > So now we have a bunch of SAMBA services running on RHEL6.4 boxes that > are IPA-clients and we would like to give the AD users access to them. > How to proceed? We cannot use an IPA - AD trust, because both domains > have the same name. We also cannot make the SAMBA services member of > the AD domain, because the server itself is an IPA-member and > krb5.conf already points to the IPA servers for domain MYCOMP.EDU.. > Also /etc/resolv points to the DNS services of IPA. > See my problem? If not, read the whole mail thread.. > I haven't read all the thread way back, but what you *could* do is to configure Samba in a completely independent way for the rest of the machine. Join just the samba file server to the Ad domain but use net rpc join and configure samba with security = domain not security = ads, basically treat the AD domain as a legacy NT4 domain. It will allow you to use only NTLM, no kerberos. The main issue will be how to provide users to the system. If you can map the AD domain SIDs in a different ID range you could run both the normal sssd and add on top winbindd configured with idmap rid to map the Ad domain SIDs in a range that do not conflict and use fully qualified names for users so you have no chance of conflict with the native IPA users. It *might* work, but you'd have to try to know and you need to fully understand the nsswitch interactions as well as winbindd configuration nuissances to pull it off. It will be a fragile setup, in any case. > > > It get's even more complicated. The AD "MYCOMP.EDU" domain has a trust > with an AD "OTHERCOMP.EDU" and users in "OTHERCOMP.EDU" must access > resource in "MYCOMP.EDU". There is a trust between the AD domain > "MYCOMP.EDU" and the AD domain "OTHERCOMP.EDU". This works. We have > some shares on a NetApp filer who is member of the AD domain > "MYCOMP.EDU" and people from "OTHERCOMP.EDU" can successfully access > those shares (given correct group membership offcourse). > > > Now, we would like to have peoply in the AD domains "OTHERCOMP.EDU" > and "MYCOMP.EDU" to access shares served by SAMBA services on RHEL64 > machines that are IPA clients in the IPA domain "MYCOMP.EDU". > > > As all out RHEL servers are IPA clients by default we also want the > servers running SAMBA to stay IPA-clients for system level central > administration of users, groups, sudo policies, hbac, etc. > > > Now, how to proceed: > > > I see 2 possible solutions (besides byting the bullet and name change > one of the MYCOMP domains): Byting the bullet will be by far the easiest I think, although *changing* here really means installing a new domain and slowly phasing off the old one. > > Solution 1: > Create an intermediary domain. This gives the following trust > relationships: > > > AD(OTHERCOMP.EDU) <--trusts-- AD(MYCOMP.EDU) <--trusts-- > AD(MYCOMP-INTERMEDIARY.EDU) <--trusts-- IPA(MYCOMP.EDU). I don't like > this one and I am not even sure it solves my problem. Another problem > involves adding to (virtual) Windows boxes to maintain this domain. We do not have yet full support for transitive trusts, so it will not work with any released buts, although we *are* getting close. > > Solution 2: > Make a SAMBA only domain. Make one of the SAMBA servers a PDC and one > BDC. Make a NT-4 style trust to the AD domain MYCOMP.EDU. NT-4 style > to have no Kerberos involvement as that is used for IPA. Also no DNS > clashes as NT-4 style doesn't use DNS SRV records. I do not recall how good the old NT domain stuff is wrt trusts, but it is certainly a possibility, you have the same Winbindd issues as above plus having to manage to add the necessary samba objectlasses in the IPA tree manually when needed for the local users, or you'll have to keep a separate database, if you do not care exporting samba share tfor IPA users, you may just not create anything beyond a few admin users locally on the samba boxes and rely entirely on winbindd to provide trusted domain users. However at this point you can as well use the solution I proposed you above. > AD(OTHERCOMP.EDU) <--trusts-- AD(MYCOMP.EDU) <--nt-4-trusts-- > NT4(MYCOMP-SAMBA) > > > > Now, giving correct group memberships and all, users in OTHERCOMP.EDU > should be able to access shares in MYCOMP-SAMBA. > > > Correct? > Once you get through a correctly working trust you should be able to deal with this relatively easily, yes. Simo. -- Simo Sorce * Red Hat, Inc * New York From craig.freeipa at noboost.org Mon Sep 23 00:19:13 2013 From: craig.freeipa at noboost.org (craig.freeipa at noboost.org) Date: Mon, 23 Sep 2013 10:19:13 +1000 Subject: [Freeipa-users] Odd "dereference processing failed : Input/output error" Message-ID: <20130923001913.GA15574@noboost.org> Hi, Spec: Fedora release 19 * freeipa-client-3.3.0-2.fc19.x86_64 * sssd-ipa-1.11.0-0.2.beta2.fc19.x86_64 I've got a PC that keeps crashing Anyone see this error before? Note: the dbus messages may be unrelated. File: /var/log/messages Sep 20 16:40:03 craigpc sssd[be[teratext.saic.com.au]]: dereference processing failed : Input/output error Sep 20 17:08:06 craigpc dbus-daemon[408]: dbus[408]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.2" (uid=70 pid=407 comm="avahi-daemon: starting up ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.2700" (uid=365 pid=21991 comm="evince /data/download/DOC200913-20092013104309.pdf") Sep 20 17:08:06 craigpc dbus[408]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.2" (uid=70 pid=407 comm="avahi-daemon: starting up ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.2700" (uid=365 pid=21991 comm="evince /data/download/DOC200913-20092013104309.pdf") Sep 20 17:08:06 craigpc dbus[408]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.2" (uid=70 pid=407 comm="avahi-daemon: starting up ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.2700" (uid=365 pid=21991 comm="evince /data/download/DOC200913-20092013104309.pdf") Sep 20 17:08:06 craigpc dbus-daemon[408]: dbus[408]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.2" (uid=70 pid=407 comm="avahi-daemon: starting up ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.2700" (uid=365 pid=21991 comm="evince /data/download/DOC200913-20092013104309.pdf") Sep 20 17:50:01 craigpc sssd[be[teratext.saic.com.au]]: dereference processing failed : Input/output error cya Craig From pspacek at redhat.com Mon Sep 23 07:04:02 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 23 Sep 2013 09:04:02 +0200 Subject: [Freeipa-users] Recomendations on multi-domain environments In-Reply-To: <523C6B6A.8000600@redhat.com> References: <52399120.1070804@cica.es> <523C6B6A.8000600@redhat.com> Message-ID: <523FE7E2.3070908@redhat.com> On 20.9.2013 17:36, Dmitri Pal wrote: > On 09/18/2013 07:55 AM, Andrew Lau wrote: >> >> On Wed, Sep 18, 2013 at 9:40 PM, Arturo Borrero > > wrote: >> >> Hi there! >> >> This is my situation. >> >> I have some users of my main domain "cica.es ". >> >> But I also maintain a database of users of others domain, ie >> "example.es ". >> >> I can apply most of FreeIPA configuration to "cica.es >> " users: access to hosts, groups, policies, roles, >> etc.. >> >> But users of "example.es " are dummy users, who >> just have an LDAP account in order to use virtual mailboxes in >> Postfix/Dovecot. >> >> Do anyone have any advice on how handle this situation? >> >> I see some options: >> * create a second FreeIPA server, each to handle his own domain. >> * get the main FreeIPA server to handle two complete different >> LDAP tree (with different root DNs, don't know if possible). >> * integrate "example.es " users into specific >> groups, "prefix" or something each group and user. >> >> We are talking of about 2k users in total (main domain + secondary >> domain). In addition, there is the possibility to have more than >> two domains. >> >> How FreeIPA handles this multi-domain environment? >> >> Best regards. >> >> -- >> >> >> If your second domain is just for LDAP (this is a little similar to >> what I did). It's not a fluid as you end up limited to the two domains.. . >> >> Keep the FreeIPA for hosting cica.es to do your host >> polices etc. Then on your virtual mailboxes two options we did was either: >> >> - Change the default mail atribute in FreeIPA settings so a user would >> have user.name at example.es rather >> than user.domain at cica.es in their mail >> attribute then have the LDAP config lookup that rather than username >> - The other simple alternative is simply have LDAP search the username >> and append @example.es or not at all. >> >> HTH >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > I am not sure that the answer above is 100% relevant to what has been asked. > The question was "should I merge two domains or keep them separate, and > if I merger the users into IPA how should I do it to be able to > differentiate users from two different original sources". > At least this is how I interpreted the question. > > I would say "it depends". > 1) Are the users in two domains are same users? If yes then you should > follow advice above and merge. > 2) If users are actually different users then I would keep the two > namespaces separate and not merge. If you merge you would be able to use > groups and prefixes and may be special attributes but would not be able > to put users into different sub trees. Well... you can... but the rest > of the IPA would not see them if you do it right or might be confused if > you do it wrong. I would add one other point: Try to be 'future-proof'. Are you 100% sure that you will never merge both sets of users? 'Never' is a long time ... (Remember that you will have to solve UID/GID/naming conflicts during the merge. It will be painful.) What is the added value of two domains? -- Petr^2 Spacek From pspacek at redhat.com Mon Sep 23 07:07:54 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 23 Sep 2013 09:07:54 +0200 Subject: [Freeipa-users] Elliptic curves with the CA In-Reply-To: <1379693348.12743.4.camel@aleeredhat.laptop> References: , <5237B518.6060808@redhat.com> <523C6E33.90302@redhat.com> <1379693348.12743.4.camel@aleeredhat.laptop> Message-ID: <523FE8CA.7000309@redhat.com> Hello, by the way, this article contains very interesting thoughts about world-wide ECC deployment in context of DNSSEC: https://www.myicann.org/news/articles/31935/related/29167 Most of the article is focused on DNSSEC, but I would recommend you to read the second part beginning with sentence 'It has been suggested that algorithm rollover towards elliptic curve cryptography (ECC)'. Petr^2 Spacek On 20.9.2013 18:09, Ade Lee wrote: > As a partial answer to this, work has been ongoing to fully support ECC > in Dogtag. Attached is a most likely out-of-date wiki page detailing > ECC support in Dogtag. > > https://pki.fedoraproject.org/wiki/ECC_in_Dogtag > > If I recall correctly, we are somewhere around phase 3. > > Ade > > On Fri, 2013-09-20 at 11:48 -0400, Dmitri Pal wrote: >> On 09/18/2013 01:53 PM, mees virk wrote: >>> I do not have a valid support contract, or other contracts with >>> RedHat. Doesn't that stop me from opening proper RFE ticket? >>> >>> In any case, my interest was this time solely for evaluation >>> purposes. If I were actively choosing an integrated identity >>> management product, I might not choose Freeipa because it takes the >>> longevity of the product and the development stance (lack of >>> roadmap?) into question. >>> >> >> I wonder where the lack of roadmap came from? >> http://www.freeipa.org/page/Roadmap >> So the trac system we use gives a good view of the dynamics of the >> project >> https://fedorahosted.org/freeipa/roadmap >> >> However IMO disconnect in expectations is that support of the ECC is >> not exactly FreeIPA's problem (yet). >> It needs to be implemented by the lower levels of the stack first: >> NSS, Dogtag etc. >> We have plans for support of the certs for users and we understand >> that RSA becomes outdated. >> Your RFE would allow us to track your specific requirements and >> interest (and make it our problem). >> >> Right now the position is that: let the underlying components grow ECC >> suppoirt and consume this functionality in FreeIPA when it matures. >> Filing an RFE would change this dynamics and would signal us that >> there is interest in the community in the actual end point solution, >> i.e. FreeIPA supporting ECC. >> >> Thanks! >> >>> >>> RSA is slowly getting into slippery slope, because it really isn't >>> about what it's worth today. When you protect something with a >>> cryptographic algorithm you have to take account for how long >>> certain types of data will be stored, and factor that time frame in. >>> Increasing the key sizes will not be solution, because several >>> embedded devices such as VPN products, smartcards and RFID devices >>> will start failing pretty fast after 1024-2048 bit keys. >>> >>> ECC was designed to solve some of these issues; it's important >>> development not mostly because of security today but because it will >>> scale better up (it was designed to be implementable better on >>> hardware), and the key sizes start from nicer point of security vs >>> size. So it's the feature that would future proof the CA. At this >>> moment there is available ECC support on some products on all the >>> areas such as smart cards, so the products not having that option >>> out of the box will start basically losing in the competition. >>> >>> I'm not trying to make a technical point here (if I made some minor >>> error there, sorry) but a managerial, and from product management >>> viewpoint. ECC must be on the feature set, or the CA features will >>> be discarded in the future by potential users. That means the >>> Freeipa as a whole might not be selected for some projects. Plus, it >>> doesn't really hurt having ECC in. :) >>> >>> >>> ____________________________________________________________________ >>> >>> >>> >>> IPA uses NSS, NSS support of ECC algorithms is very fresh, we have >>> not looked at this area yet. >>> I suspect it would require changes in Dogtag first. >>> >>> Would be best if you can file and RFE ticket, then we would be able >>> to follow up. From jhrozek at redhat.com Mon Sep 23 07:27:56 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 23 Sep 2013 09:27:56 +0200 Subject: [Freeipa-users] Odd "dereference processing failed : Input/output error" In-Reply-To: <20130923001913.GA15574@noboost.org> References: <20130923001913.GA15574@noboost.org> Message-ID: <20130923072756.GB3433@hendrix.redhat.com> On Mon, Sep 23, 2013 at 10:19:13AM +1000, craig.freeipa at noboost.org wrote: > Hi, > > Spec: > Fedora release 19 > * freeipa-client-3.3.0-2.fc19.x86_64 > * sssd-ipa-1.11.0-0.2.beta2.fc19.x86_64 > > I've got a PC that keeps crashing The symptoms below don't indicate a crash, do you actually see a segfault? > Anyone see this error before? So far I've seen this error with some old Novell eDir servers that claimed to support dereference control in rootDSE but didn't. I've never seen this error with IPA. > Note: the dbus messages may be unrelated. > > File: /var/log/messages > Sep 20 16:40:03 craigpc sssd[be[teratext.saic.com.au]]: dereference > processing failed : Input/output error Can you reproduce this? Can you put debug_level=6 into the domain section of your sssd.conf, restart the sssd and attach logs? > > Sep 20 17:08:06 craigpc dbus-daemon[408]: dbus[408]: [system] Rejected > send message, 2 matched rules; type="method_return", sender=":1.2" > (uid=70 pid=407 comm="avahi-daemon: starting up ") interface="(unset)" > member="(unset)" error name="(unset)" requested_reply="0" > destination=":1.2700" (uid=365 pid=21991 comm="evince > /data/download/DOC200913-20092013104309.pdf") > > Sep 20 17:08:06 craigpc dbus[408]: [system] Rejected send message, 2 > matched rules; type="method_return", sender=":1.2" (uid=70 pid=407 > comm="avahi-daemon: starting up ") interface="(unset)" member="(unset)" > error name="(unset)" requested_reply="0" destination=":1.2700" (uid=365 > pid=21991 comm="evince /data/download/DOC200913-20092013104309.pdf") > > Sep 20 17:08:06 craigpc dbus[408]: [system] Rejected send message, 2 > matched rules; type="method_return", sender=":1.2" (uid=70 pid=407 > comm="avahi-daemon: starting up ") interface="(unset)" member="(unset)" > error name="(unset)" requested_reply="0" destination=":1.2700" (uid=365 > pid=21991 comm="evince /data/download/DOC200913-20092013104309.pdf") > > Sep 20 17:08:06 craigpc dbus-daemon[408]: dbus[408]: [system] Rejected > send message, 2 matched rules; type="method_return", sender=":1.2" > (uid=70 pid=407 comm="avahi-daemon: starting up ") interface="(unset)" > member="(unset)" error name="(unset)" requested_reply="0" > destination=":1.2700" (uid=365 pid=21991 comm="evince > /data/download/DOC200913-20092013104309.pdf") > Any change these four above could be SELinux related? > Sep 20 17:50:01 craigpc sssd[be[teratext.saic.com.au]]: dereference > processing failed : Input/output error > > cya > > Craig From fvzwieten at vxcompany.com Mon Sep 23 07:54:23 2013 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Mon, 23 Sep 2013 09:54:23 +0200 Subject: [Freeipa-users] IPA, Samba and AD In-Reply-To: <1379882277.17271.10.camel@willson.li.ssimo.org> References: <20130703091127.GN24422@vda.li> <20130703141944.GA7273@redhat.com> <20130921095130.GM4216@redhat.com> <20130921203026.GO4216@redhat.com> <1379882277.17271.10.camel@willson.li.ssimo.org> Message-ID: Suppose we would "bite the bullet" and *move* IPA to another domain. This would be a subdomain (IPA.MYCOMP.EDU). I have to install 2 new IPA servers. No problems there. However, I have to migrate the data. That is a real problem, I think. For HBAC rules, SUDO rules, etc we can do this manually. However Users and DNS is quit a lot *and* we want to migrate the user passwords. For DNS we could use zone transfers But for user passwords? Is there IPA export import type of functionality (in RHEL64) that can provide this? Met vriendelijke groeten, * Fred van Zwieten * *Enterprise Open Source Services* * Consultant* *(woensdags afwezig)* *VX Company IT Services B.V.* *T* (035) 539 09 50 mobiel (06) 41 68 28 48 *F* (035) 539 09 08 *E* fvzwieten at vxcompany.com *I* www.vxcompany.com Seeing, contrary to popular wisdom, isn?t believing. It?s where belief stops, because it isn?t needed any more.. (Terry Pratchett) On Sun, Sep 22, 2013 at 10:37 PM, Simo Sorce wrote: > On Sun, 2013-09-22 at 18:09 +0200, Fred van Zwieten wrote: > > Well, as explained in this thread, the problem here is that we have an > > IPA domain named "MYCOMP.EDU" _and_ an AD domain named "MYCOMP.EDU" as > > well. Both have there own DNS servers. It's beyond the scope of this > > mail to explain why we have named them exactly the same, and we do > > wish we didn't, but this is the current situation. Migrating any of > > these to another domain name would be the best solution but would > > involve quite a lot of work. > > > > > > So now we have a bunch of SAMBA services running on RHEL6.4 boxes that > > are IPA-clients and we would like to give the AD users access to them. > > How to proceed? We cannot use an IPA - AD trust, because both domains > > have the same name. We also cannot make the SAMBA services member of > > the AD domain, because the server itself is an IPA-member and > > krb5.conf already points to the IPA servers for domain MYCOMP.EDU.. > > Also /etc/resolv points to the DNS services of IPA. > > > See my problem? If not, read the whole mail thread.. > > > I haven't read all the thread way back, but what you *could* do is to > configure Samba in a completely independent way for the rest of the > machine. > > Join just the samba file server to the Ad domain but use net rpc join > and configure samba with security = domain not security = ads, basically > treat the AD domain as a legacy NT4 domain. > It will allow you to use only NTLM, no kerberos. > > The main issue will be how to provide users to the system. > > If you can map the AD domain SIDs in a different ID range you could run > both the normal sssd and add on top winbindd configured with idmap rid > to map the Ad domain SIDs in a range that do not conflict and use fully > qualified names for users so you have no chance of conflict with the > native IPA users. > > It *might* work, but you'd have to try to know and you need to fully > understand the nsswitch interactions as well as winbindd configuration > nuissances to pull it off. It will be a fragile setup, in any case. > > > > > > It get's even more complicated. The AD "MYCOMP.EDU" domain has a trust > > with an AD "OTHERCOMP.EDU" and users in "OTHERCOMP.EDU" must access > > resource in "MYCOMP.EDU". There is a trust between the AD domain > > "MYCOMP.EDU" and the AD domain "OTHERCOMP.EDU". This works. We have > > some shares on a NetApp filer who is member of the AD domain > > "MYCOMP.EDU" and people from "OTHERCOMP.EDU" can successfully access > > those shares (given correct group membership offcourse). > > > > > > Now, we would like to have peoply in the AD domains "OTHERCOMP.EDU" > > and "MYCOMP.EDU" to access shares served by SAMBA services on RHEL64 > > machines that are IPA clients in the IPA domain "MYCOMP.EDU". > > > > > > As all out RHEL servers are IPA clients by default we also want the > > servers running SAMBA to stay IPA-clients for system level central > > administration of users, groups, sudo policies, hbac, etc. > > > > > > Now, how to proceed: > > > > > > I see 2 possible solutions (besides byting the bullet and name change > > one of the MYCOMP domains): > > Byting the bullet will be by far the easiest I think, although > *changing* here really means installing a new domain and slowly phasing > off the old one. > > > > Solution 1: > > Create an intermediary domain. This gives the following trust > > relationships: > > > > > > AD(OTHERCOMP.EDU) <--trusts-- AD(MYCOMP.EDU) <--trusts-- > > AD(MYCOMP-INTERMEDIARY.EDU) <--trusts-- IPA(MYCOMP.EDU). I don't like > > this one and I am not even sure it solves my problem. Another problem > > involves adding to (virtual) Windows boxes to maintain this domain. > > We do not have yet full support for transitive trusts, so it will not > work with any released buts, although we *are* getting close. > > > > > Solution 2: > > Make a SAMBA only domain. Make one of the SAMBA servers a PDC and one > > BDC. Make a NT-4 style trust to the AD domain MYCOMP.EDU. NT-4 style > > to have no Kerberos involvement as that is used for IPA. Also no DNS > > clashes as NT-4 style doesn't use DNS SRV records. > > I do not recall how good the old NT domain stuff is wrt trusts, but it > is certainly a possibility, you have the same Winbindd issues as above > plus having to manage to add the necessary samba objectlasses in the IPA > tree manually when needed for the local users, or you'll have to keep a > separate database, if you do not care exporting samba share tfor IPA > users, you may just not create anything beyond a few admin users locally > on the samba boxes and rely entirely on winbindd to provide trusted > domain users. However at this point you can as well use the solution I > proposed you above. > > > AD(OTHERCOMP.EDU) <--trusts-- AD(MYCOMP.EDU) <--nt-4-trusts-- > > NT4(MYCOMP-SAMBA) > > > > > > > > Now, giving correct group memberships and all, users in OTHERCOMP.EDU > > should be able to access shares in MYCOMP-SAMBA. > > > > > > Correct? > > > Once you get through a correctly working trust you should be able to > deal with this relatively easily, yes. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Sep 23 08:41:16 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 23 Sep 2013 10:41:16 +0200 Subject: [Freeipa-users] migrating FreeIPA to another domain name (was: Re: IPA, Samba and AD) In-Reply-To: References: <20130703091127.GN24422@vda.li> <20130703141944.GA7273@redhat.com> <20130921095130.GM4216@redhat.com> <20130921203026.GO4216@redhat.com> <1379882277.17271.10.camel@willson.li.ssimo.org> Message-ID: <523FFEAC.5010305@redhat.com> On 23.9.2013 09:54, Fred van Zwieten wrote: > Suppose we would "bite the bullet" and*move* IPA to another domain. This > would be a subdomain (IPA.MYCOMP.EDU). I have to install 2 new IPA servers. > No problems there. However, I have to migrate the data. That is a real > problem, I think. For HBAC rules, SUDO rules, etc we can do this manually. > However Users and DNS is quit a lot*and* we want to migrate the user > passwords. > > For DNS we could use zone transfers FreeIPA stores all the data in LDAP, it would be better to do this: 1) export whole DNS sub-tree to LDIF (via ldapsearch) 2) change LDAP DNs (add dc=ipa to the DN components) 3) import all the data back (via ldapadd) SRV & FreeIPA host records will need some manual work, but basically you just need to add '.ipa.' component to all host names and references to them. Don't forget to add/change delegation NS+A records in the parent DNS zone (MYCOMP.EDU). Let us know if you need any assistance. > But for user passwords? Guys, could migrate-ds script help? > > Is there IPA export import type of functionality (in RHEL64) that can > provide this? -- Petr^2 Spacek From jpazdziora at redhat.com Mon Sep 23 08:44:28 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 23 Sep 2013 16:44:28 +0800 Subject: [Freeipa-users] Incorrect user information In-Reply-To: References: <5227465D.7020308@gmail.com> <841815955.7935136.1378306069557.JavaMail.root@redhat.com> <237193263.7936259.1378306160770.JavaMail.root@redhat.com> <52274F35.5090508@gmail.com> <20130904153134.GH22590@hendrix.brq.redhat.com> <52275C7A.3020800@gmail.com> <20130910113031.GG11028@hendrix.brq.redhat.com> <52336DA6.1020600@gmail.com> Message-ID: <20130923084428.GF2029@redhat.com> On Sat, Sep 14, 2013 at 01:11:36PM -0400, Brian Lindblom wrote: > Of course, I would imagine that since the GECOS field is set upon account > creation based on the values provided for first and last name, and since > GECOS is not a provided field in the UI for user attributes, that GECOS > should be updated automatically to reflect those changes. Bug perhaps? The ticket https://fedorahosted.org/freeipa/ticket/3569 tracks addition of the WebUI GECOS field. It's been added in upstream FreeIPA and it should find its way to the next RHEL releases as well. -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From aborrero at cica.es Mon Sep 23 11:19:17 2013 From: aborrero at cica.es (Arturo Borrero) Date: Mon, 23 Sep 2013 13:19:17 +0200 Subject: [Freeipa-users] Changing the WebUI idiom Message-ID: <524023B5.2010202@cica.es> Hi there! FreeIPA WebUI in spanish has some annoyances in how the text is showed. http://img545.imageshack.us/img545/9016/9eur.png We would like to switch from spanish to standar english in the WebUI. Could anyone please point me in the right direction about changing that? Best regards. -- Arturo Borrero Gonz?lez Departamento de Seguridad Inform?tica (nis at cica.es) Centro Inform?tico Cient?fico de Andaluc?a (CICA) Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain) Tfno.: +34 955 056 600 / FAX: +34 955 056 650 Consejer?a de Econom?a, Innovaci?n, Ciencia y Empleo Junta de Andaluc?a -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3072 bytes Desc: S/MIME Cryptographic Signature URL: From aborrero at cica.es Mon Sep 23 11:53:15 2013 From: aborrero at cica.es (Arturo Borrero) Date: Mon, 23 Sep 2013 13:53:15 +0200 Subject: [Freeipa-users] Recomendations on multi-domain environments In-Reply-To: <523FE7E2.3070908@redhat.com> References: <52399120.1070804@cica.es> <523C6B6A.8000600@redhat.com> <523FE7E2.3070908@redhat.com> Message-ID: <52402BAB.5040308@cica.es> On 23/09/13 09:04, Petr Spacek wrote: > I would add one other point: > Try to be 'future-proof'. Are you 100% sure that you will never merge > both sets of users? 'Never' is a long time ... (Remember that you will > have to solve UID/GID/naming conflicts during the merge. It will be > painful.) > > What is the added value of two domains? One of the added values of two domains (two servers) is the situation when owners of "second-domain.com" want to take its users db away. In that case, they just take the "second-domain.com" server. Anyway, both situations (merge of users, and users take-away) are unlikely to happen. -- Arturo Borrero Gonz?lez Departamento de Seguridad Inform?tica (nis at cica.es) Centro Inform?tico Cient?fico de Andaluc?a (CICA) Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain) Tfno.: +34 955 056 600 / FAX: +34 955 056 650 Consejer?a de Econom?a, Innovaci?n, Ciencia y Empleo Junta de Andaluc?a -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3072 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Mon Sep 23 11:55:07 2013 From: jdennis at redhat.com (John Dennis) Date: Mon, 23 Sep 2013 07:55:07 -0400 Subject: [Freeipa-users] Changing the WebUI idiom In-Reply-To: <524023B5.2010202@cica.es> References: <524023B5.2010202@cica.es> Message-ID: <52402C1B.3080901@redhat.com> On 09/23/2013 07:19 AM, Arturo Borrero wrote: > Hi there! > > FreeIPA WebUI in spanish has some annoyances in how the text is showed. > > http://img545.imageshack.us/img545/9016/9eur.png > > We would like to switch from spanish to standar english in the WebUI. > > Could anyone please point me in the right direction about changing that? Changing the language preference in your browser should accomplish that. In Firefox open the preferences dialog and select languages under Content. -- John From jdennis at redhat.com Mon Sep 23 11:57:29 2013 From: jdennis at redhat.com (John Dennis) Date: Mon, 23 Sep 2013 07:57:29 -0400 Subject: [Freeipa-users] Changing the WebUI idiom In-Reply-To: <52402C1B.3080901@redhat.com> References: <524023B5.2010202@cica.es> <52402C1B.3080901@redhat.com> Message-ID: <52402CA9.1070809@redhat.com> On 09/23/2013 07:55 AM, John Dennis wrote: > On 09/23/2013 07:19 AM, Arturo Borrero wrote: >> Hi there! >> >> FreeIPA WebUI in spanish has some annoyances in how the text is showed. >> >> http://img545.imageshack.us/img545/9016/9eur.png >> >> We would like to switch from spanish to standar english in the WebUI. >> >> Could anyone please point me in the right direction about changing that? > > Changing the language preference in your browser should accomplish that. > In Firefox open the preferences dialog and select languages under Content. Oh by the way, you could help us and file a bug on the spanish translation so we can get the translation fixed. -- John From jcholast at redhat.com Mon Sep 23 14:00:56 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Sep 2013 16:00:56 +0200 Subject: [Freeipa-users] Wildcard SSL In-Reply-To: References: <5235FB2B.2040500@redhat.com> Message-ID: <52404998.7030807@redhat.com> On 16.9.2013 01:20, Andrew Lau wrote: > > On Mon, Sep 16, 2013 at 4:23 AM, Dmitri Pal > wrote: > > On 09/14/2013 04:00 AM, Andrew Lau wrote: >> Hi, >> >> I have a reverse proxy infront of many of my hosts, each of the >> virtual hosts have their own SSL cert, currently with FreeIPA I'm >> adding hosts for each virtual host and then creating a cert. >> >> From what I've found, it doesn't seem to be possible to do a >> wildcard ssl through FreeIPA, I tried exporting the ca root >> private key to manually sign a wildcard cert with no success. I >> may have done that wrong. >> >> Any suggestions? > > Is this what you are looking for? > https://fedorahosted.org/freeipa/ticket/3475 > > It is currently on a distant roadmap but help always welcome. > >> >> Thanks, >> Andrew >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > Yeah. > > Is there any way of manually doing that now by pulling the root ca and > key out to sign a cert? You can do it manually via Dogtag. First, import the client cert from /root/ca-agent.p12 found on your IPA server to your web browser. Then, navigate your web browser to https://ipaserver:8443/ca/ee/ca/profileSelect?profileId=caServerCert, paste the wildcard CSR in the form and submit it. Then, navigate your web browser to https://ipaserver:8443/ca/agent/ca/listRequests.html, find your request and approve it. This should give you the signed certificate. Honza -- Jan Cholasta From dpal at redhat.com Mon Sep 23 14:07:10 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 23 Sep 2013 10:07:10 -0400 Subject: [Freeipa-users] ipa-client auth with windomain account In-Reply-To: References: <523C6EFA.4080606@redhat.com> Message-ID: <52404B0E.3040505@redhat.com> On 09/20/2013 03:21 PM, ?????? ? wrote: > hi! TRUST OK! > dig SRV _ldap._tcp.wiindomain-------ok win serv SRV > dig SRV _ldap._tcp.ipadomain.wiindomain------ok serv SRV > dns1:ipaserver1 > dns2:winserv1 > sorry for my english Please do not reply to me directly, reply to the list. This way people would be able too see and continue conversation. When I asked about DNS, I was asking about the relation between windows DNS and IPA. AFAIU in the setup you delegate a DNS zone from AD DNS to IPA. Is that the case? Also on the client please change the debug_level in sssd.conf to 9 or use a bitmask (see `man sssd.conf` on the client and search for debug_level), restart sssd and provide sssd logs to the list. Do not forget to sanitize them. We will be able to see what is going on in SSSD and why it does not get the user. BTW, have you restarted SSSD after adding trust? If so sssd might not yet know that the trust was added. We have a ticket about it. Please try restarting SSSD. Thanks Dmitri > > > 2013/9/20 Dmitri Pal > > > On 09/18/2013 11:42 AM, ?????? ? wrote: >> Hi, >> Do I need network access to ports from the ipa-client to the server- >> windows for authentication with windomain accounts? >> ipa-server fedora19 >> ipa-client fedora19 >> winserver win2012 >> the ipa-client is located in another network >> within the network ipa-server, ipa-client and windows-server >> authentication works >> to the ipa-client: >> #id windomainuser at windomain >> id: windomainuser at windomain: No such user >> please tell me what I'm doing wrong >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > We need to understand more about your setup. > Are you using trusts? > What is your DNS configuration? > > Generally if you are using trusts than clients should be able to > resolve AD server and connect to it. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbulist at gmail.com Mon Sep 23 14:20:22 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Mon, 23 Sep 2013 09:20:22 -0500 Subject: [Freeipa-users] slapi-nis bypass Password Policies In-Reply-To: <4C51E5D7-C9A1-436E-8C12-77C217278A4B@citrixonline.com> References: <5239DC28.8070203@gmail.com> <4C51E5D7-C9A1-436E-8C12-77C217278A4B@citrixonline.com> Message-ID: <52404E26.7030704@gmail.com> Hi JR, Thanks and I'm sorry for the delay. Your idea is good and I used something like that for other openldap implementation but in this case I need that all my users continue using their userid and pass in order to log in. We use NoMachine for Remote Access and this application has problem with password expiration or password change that is the reason why I was thinking bypass the password policies. Please let me know if you need any additional information about it. Thanks! On 09/20/2013 04:10 PM, JR Aquino wrote: > Is your client simply using LDAP to bind and authenticate your service? > > If so, you may be able to create a special dedicated sysaccount in: cn=sysaccounts,cn=etc,dc=domain,dc=com > > This account could be used to bind your service without having it be a member of the standard users database subjected to Password Policy expirations etc. > > "You cannot hope to secure that which you do not first understand" > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Jr Aquino | Sr. Information Security Specialist > GXPN | GIAC Exploit Researcher and Advanced Penetration Tester > GCIH | GIAC Certified Incident Handler > GWAPT | GIAC WebApp Penetration Tester > > Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 > T: +1 805.690.3478 > C: +1 805.717.0365 > jr.aquino at citrix.com > http://www.citrixonline.com > > On Sep 18, 2013, at 10:00 AM, cbulist at gmail.com wrote: > > Hi, > > We have a client server connected to the IPA server using NIS. It's > working well but we have a service running at client server that doesn't > handle the password expiration properly. > Is it possible to bypass the Password Policies from this client server? > > Thanks! > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From sakodak at gmail.com Mon Sep 23 15:59:02 2013 From: sakodak at gmail.com (KodaK) Date: Mon, 23 Sep 2013 10:59:02 -0500 Subject: [Freeipa-users] Timeout (?) issues In-Reply-To: <523C0228.70408@redhat.com> References: <5237B70A.5050307@redhat.com> <523860C3.5050206@redhat.com> <523B55B0.3090309@redhat.com> <523C0228.70408@redhat.com> Message-ID: I'm pretty sure this is the root of my problem (not confirmed yet, but it's AIX -- that's always the problem): http://www-01.ibm.com/support/docview.wss?uid=swg21212940 The takeaway is this: "The first query (184) is a normal IPV4 lookup for "ldap.austin.texas.com", which returns "192.168.1.255". But then an IPV6 lookup is done for the same name. Because there is no IPV6 address for ldap.austin.texas.com, it continues searching every search domain in the resolv.conf file ( example.austin.texas.com austin.texas.com texas.com) trying to find one." On Fri, Sep 20, 2013 at 3:07 AM, Petr Spacek wrote: > On 20.9.2013 01:24, KodaK wrote: > >> This is ridiculous, right? >> >> IPA server 1: >> >> # for i in $(ls access*); do echo -n $i:\ ;grep err=32 $i | wc -l; done >> access: 248478 >> access.20130916-043207: 302774 >> access.20130916-123642: 272572 >> access.20130916-201516: 294308 >> access.20130917-081053: 295060 >> access.20130917-144559: 284498 >> access.20130917-231435: 281035 >> access.20130918-091611: 291165 >> access.20130918-154945: 275792 >> access.20130919-014322: 296113 >> >> IPA server 2: >> >> access: 4313 >> access.20130909-200216: 4023 >> access.20130910-200229: 4161 >> access.20130911-200239: 4182 >> access.20130912-200249: 5069 >> access.20130913-200258: 3833 >> access.20130914-200313: 4208 >> access.20130915-200323: 4702 >> access.20130916-200332: 4532 >> >> >> IPA server 3: >> >> access: 802 >> access.20130910-080737: 3876 >> access.20130911-080748: 3902 >> access.20130912-080802: 3678 >> access.20130913-080810: 3765 >> access.20130914-080826: 3524 >> access.20130915-080907: 4142 >> access.20130916-080916: 4930 >> access.20130917-080926: 4769 >> access.20130918-081005: 2879 >> >> IPA server 4: >> >> access: 2812 >> access.20130910-003051: 4095 >> access.20130911-003105: 3623 >> access.20130912-003113: 3606 >> access.20130913-003125: 3581 >> access.20130914-003135: 3758 >> access.20130915-003150: 3935 >> access.20130916-003159: 4184 >> access.20130917-003210: 3859 >> access.20130918-003221: 5110 >> >> >> The vast majority of the err=32 messages are DNS entries. >> > > It depends on your setup. Bind-dyndb-ldap does LDAP search for each > non-existent name to verify that the name wasn't added to LDAP in > meanwhile. If you have clients doing 1M queries for non-existing names per > day, then you will see 1M LDAP queries with err=32 per day. > > Next major version of bind-dyndb-ldap will have reworked internal database > and it will support negative caching, so number of err=32 should drop > significantly. > > > Here are some samples: >> >> [19/Sep/2013:18:19:51 -0500] conn=9 op=169764 SRCH base="idnsName=xxx.com >> ,idnsname=unix.xxx.com,cn=dns,**dc=unix,dc=xxx,dc=com" scope=0 >> filter="(objectClass=**idnsRecord)" attrs=ALL >> [19/Sep/2013:18:19:51 -0500] conn=9 op=169764 RESULT err=32 tag=101 >> nentries=0 etime=0 >> > > This is interesting, because this LDAP query is equal to DNS query for " > xxx.com.unix.xxx.com." Are your clients that crazy? :-) > > > [19/Sep/2013:18:19:51 -0500] conn=9 op=169774 SRCH base="idnsName= >> slpoxacl01.unix.xxx.com,**idnsname=unix.xxx.com,cn=dns,** >> dc=unix,dc=xxx,dc=com" >> scope=0 filter="(objectClass=**idnsRecord)" attrs=ALL >> [19/Sep/2013:18:19:51 -0500] conn=9 op=169774 RESULT err=32 tag=101 >> nentries=0 etime=0 >> > > This is equivalent to DNS query for "slpoxacl01.unix.xxx.com.unix.** > xxx.com .". > > > [19/Sep/2013:18:19:51 -0500] conn=9 op=169770 SRCH base="idnsName= >> sla400q1.unix.xxx.com,**idnsname=unix.xxx.com,cn=dns,** >> dc=unix,dc=xxx,dc=com" >> scope=0 filter="(objectClass=**idnsRecord)" attrs=ALL >> [19/Sep/2013:18:19:51 -0500] conn=9 op=169770 RESULT err=32 tag=101 >> nentries=0 etime=0 >> > > And this is "sla400q1.unix.xxx.com.unix.**xxx.com > .". > > > [19/Sep/2013:18:19:51 -0500] conn=9 op=169772 SRCH base="idnsName= >> magellanhealth.com,idnsname=un**ix.magellanhealth.com >> ,cn=dns,**dc=unix,dc=magellanhealth,dc=**com" >> scope=0 filter="(objectClass=**idnsRecord)" attrs=ALL >> [19/Sep/2013:18:19:51 -0500] conn=9 op=169772 RESULT err=32 tag=101 >> nentries=0 etime=0 >> >> So far today there are over half a million of these. That can't be right. >> > > I would recommend you to use network sniffer and check which clients sends > these crazy queries. > > My guess is that your resolver library (libc?) causes this. > > On my Linux system with glibc-2.17-14.fc19.x86_64 it behaves in this way: > > client query = nonexistent.example.com. > (I used $ "ping nonexistent.example.com.") > search domain in /etc/resolv.conf = brq.redhat.com. > > DNS query #1: nonexistent.example.com. => NXDOMAIN > DNS query #2: nonexistent.example.com.brq.**redhat.com. > => NXDOMAIN > DNS query #3: nonexistent.example.com.**redhat.com. > => NXDOMAIN > > > On Thu, Sep 19, 2013 at 3:05 PM, KodaK wrote: >> >> I didn't realize that DNS created one connection. I thought it was one >>> connection spanning several days. >>> >> > In theory, there should be 2-4 LDAP connections from each DNS server and > those connections should live until DNS or LDAP server restarts/crashes. > > Petr^2 Spacek > > On Thu, Sep 19, 2013 at 2:51 PM, Rich Megginson >> >wrote: >>> >>> On 09/19/2013 12:57 PM, KodaK wrote: >>>> >>>> Well, this is awkward: >>>> >>>> [root at slpidml01 slapd-UNIX-xxx-COM]# grep conn=170902 access* | wc -l >>>> 5453936 >>>> [root at slpidml01 slapd-UNIX-xxx-COM]# >>>> >>>> >>>> Why is it awkward? >>>> >>>> >>>> >>>> >>>> On Thu, Sep 19, 2013 at 1:48 PM, KodaK wrote: >>>> >>>> Thanks. I've been running that against my logs, and this has to be >>>>> abnormal: >>>>> >>>>> err=32 129274 No Such Object >>>>> err=0 10952 Successful Operations >>>>> err=14 536 SASL Bind in Progress >>>>> err=53 39 Unwilling To Perform >>>>> err=49 3 Invalid Credentials (Bad Password) >>>>> >>>>> I'm still trying to figure out why there are so many error 32s. Are >>>>> there any usual suspects I should know about? (That's just the current >>>>> access log, btw.) >>>>> >>>>> >>>>> On Tue, Sep 17, 2013 at 9:01 AM, Rich Megginson >>>> >wrote: >>>>> >>>>> On 09/16/2013 07:57 PM, Dmitri Pal wrote: >>>>>> >>>>>> On 09/16/2013 12:02 PM, KodaK wrote: >>>>>> >>>>>> Yet another AIX related problem: >>>>>> >>>>>> The AIX LDAP client is called secldapclntd (sure, they could make it >>>>>> more awkward, but the budget ran out.) I'm running into the issue >>>>>> detailed >>>>>> here: >>>>>> >>>>>> http://www-01.ibm.com/support/**docview.wss?uid=isg1IV11344 >>>>>> >>>>>> "If an LDAP server fails to answer an LDAP query, secldapclntd >>>>>> caches >>>>>> the non-answered query negatively. This may happen if the LDAP server >>>>>> is down for example. After the LDAP server is back again secldapclntd >>>>>> will >>>>>> use the negative cache entry and the application initiating the >>>>>> original >>>>>> query will still fail until the cache entry expires." >>>>>> >>>>>> IBM is working on porting the fix to our specific TL and SP levels. >>>>>> >>>>>> What I'm concerned with here, though, is *why* is it timing out? I >>>>>> don't know what the current timeout values are (AIX sucks, etc.) >>>>>> >>>>>> I don't see timeout issues on my Linux boxes, which leads me to >>>>>> believe that either the sssd timouts are longer or that sssd is just >>>>>> more >>>>>> robust when dealing with timeouts. >>>>>> >>>>>> I believe I'm seeing similar behavior with LDAP sudo on AIX as well, >>>>>> because I occasionally have to re-run sudo commands because they >>>>>> initially >>>>>> fail (and I know I'm using the right passwords.) However, sudo >>>>>> doesn't >>>>>> appear to have a cache (or it handles caching better.) >>>>>> >>>>>> Does anyone have any troubleshooting suggestions? Any general >>>>>> "speed >>>>>> things up" suggestions on the IPA side? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> --Jason >>>>>> >>>>>> -- >>>>>> The government is going to read our mail anyway, might as well make it >>>>>> tough for them. GPG Public key ID: B6A1A7C6 >>>>>> >>>>>> >>>>>> ______________________________**_________________ >>>>>> Freeipa-users mailing listFreeipa-users at redhat.**comhttps:// >>>>>> www.redhat.com/**mailman/listinfo/freeipa-users >>>>>> >>>>>> >>>>>> >>>>>> Is the server FreeIPA? >>>>>> Can see in the server logs what is actually happening is it the server >>>>>> that really takes time or there is a network connectivity issue or FW >>>>>> is >>>>>> dropping packets? >>>>>> I would really start with the server side logs. >>>>>> >>>>>> >>>>>> As far as 389 goes, run logconv.pl against the access logs in >>>>>> /var/log/dirsrv/slapd-DOMAIN-**COM >>>>>> >>>>> > ______________________________**_________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/**mailman/listinfo/freeipa-users > -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From avdusheff at gmail.com Tue Sep 24 09:39:28 2013 From: avdusheff at gmail.com (=?KOI8-R?B?7cnIwcnMIOE=?=) Date: Tue, 24 Sep 2013 13:39:28 +0400 Subject: [Freeipa-users] access denied ssh Message-ID: Hello. freeipa-server-3.3fedora19 ipa-replica1-fedora19 ipa-replica2 ferdora19 ssh auth with windows accounts on ipa-replica1-fedora19 is OK ssh auth with windows accounts on ipa-replica1-fedora19 is acces denied id winuser at windomain ----OK var/log/secure selinux disabled firewaldd disabled help me please -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: secure Type: application/octet-stream Size: 8251 bytes Desc: not available URL: From sbose at redhat.com Tue Sep 24 10:06:43 2013 From: sbose at redhat.com (Sumit Bose) Date: Tue, 24 Sep 2013 12:06:43 +0200 Subject: [Freeipa-users] access denied ssh In-Reply-To: References: Message-ID: <20130924100643.GW25628@localhost.localdomain> On Tue, Sep 24, 2013 at 01:39:28PM +0400, ?????? ? wrote: > Hello. > freeipa-server-3.3fedora19 > ipa-replica1-fedora19 > ipa-replica2 ferdora19 > > ssh auth with windows accounts on ipa-replica1-fedora19 is OK > ssh auth with windows accounts on ipa-replica1-fedora19 is acces denied > > > id winuser at windomain ----OK > > var/log/secure > > > selinux disabled > firewaldd disabled > > help me please Please send the sssd log files from /var/log/sssd with a high debug level from the host where auth is failing. bye, Sumit > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From aborrero at cica.es Tue Sep 24 12:08:02 2013 From: aborrero at cica.es (Arturo Borrero) Date: Tue, 24 Sep 2013 14:08:02 +0200 Subject: [Freeipa-users] Changing the WebUI idiom In-Reply-To: <52402CA9.1070809@redhat.com> References: <524023B5.2010202@cica.es> <52402C1B.3080901@redhat.com> <52402CA9.1070809@redhat.com> Message-ID: <524180A2.4000305@cica.es> On 23/09/13 13:57, John Dennis wrote: > > Oh by the way, you could help us and file a bug on the spanish > translation so we can get the translation fixed. Of course, thanks! -- Arturo Borrero Gonz?lez Departamento de Seguridad Inform?tica (nis at cica.es) Centro Inform?tico Cient?fico de Andaluc?a (CICA) Avda. Reina Mercedes s/n - 41012 - Sevilla (Spain) Tfno.: +34 955 056 600 / FAX: +34 955 056 650 Consejer?a de Econom?a, Innovaci?n, Ciencia y Empleo Junta de Andaluc?a -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3072 bytes Desc: S/MIME Cryptographic Signature URL: From aellert at numeezy.com Tue Sep 24 13:36:51 2013 From: aellert at numeezy.com (Alexandre Ellert) Date: Tue, 24 Sep 2013 15:36:51 +0200 Subject: [Freeipa-users] Cross-realm trust with AD and ssh keys management Message-ID: <99A3C898-1FDA-45C8-982C-9996C8610254@numeezy.com> Hi, I've successfully setup a testing environment with an IPA server (RHEL 6.4) and a cross realm trust with my Active Directory (Win2008 R2). Authentication works both with AD passwords and Kerberos GSS-API. Now, I'm trying to find the way to manage ssh key which belong to AD users. It seems that I can do that only with users declared on IPA domain. Can you confirm that ? Does winsync method provide a way to add ssh key to an AD user ? Your suggestions are welcome. Thanks. Alexandre. From abokovoy at redhat.com Tue Sep 24 14:40:31 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 Sep 2013 17:40:31 +0300 Subject: [Freeipa-users] Cross-realm trust with AD and ssh keys management In-Reply-To: <99A3C898-1FDA-45C8-982C-9996C8610254@numeezy.com> References: <99A3C898-1FDA-45C8-982C-9996C8610254@numeezy.com> Message-ID: <20130924144031.GV4216@redhat.com> On Tue, 24 Sep 2013, Alexandre Ellert wrote: >Hi, > >I've successfully setup a testing environment with an IPA server (RHEL 6.4) and a cross realm trust with my Active Directory (Win2008 R2). >Authentication works both with AD passwords and Kerberos GSS-API. > >Now, I'm trying to find the way to manage ssh key which belong to AD >users. It seems that I can do that only with users declared on IPA >domain. Can you confirm that ? Yes. AD users do not exist physically in IPA LDAP, therefore there is no object to assign attributes into. >Does winsync method provide a way to add ssh key to an AD user ? Under winsync AD users would become 'normal' LDAP objects in IPA, therefore you can assign additional values/attributes to them. -- / Alexander Bokovoy From avdusheff at gmail.com Tue Sep 24 11:00:22 2013 From: avdusheff at gmail.com (=?KOI8-R?B?7cnIwcnMIOE=?=) Date: Tue, 24 Sep 2013 15:00:22 +0400 Subject: [Freeipa-users] access denied ssh In-Reply-To: <20130924100643.GW25628@localhost.localdomain> References: <20130924100643.GW25628@localhost.localdomain> Message-ID: [sssd] services = nss, pam, ssh config_file_version = 2 debug_level = 5 domains = ipa.sys.local 2013/9/24 Sumit Bose > On Tue, Sep 24, 2013 at 01:39:28PM +0400, ?????? ? wrote: > > Hello. > > freeipa-server-3.3fedora19 > > ipa-replica1-fedora19 > > ipa-replica2 ferdora19 > > > > ssh auth with windows accounts on ipa-replica1-fedora19 is OK > > ssh auth with windows accounts on ipa-replica1-fedora19 is acces denied > > > > > > id winuser at windomain ----OK > > > > var/log/secure > > > > > > selinux disabled > > firewaldd disabled > > > > help me please > > Please send the sssd log files from /var/log/sssd with a high debug > level from the host where auth is failing. > > bye, > Sumit > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd.log Type: application/octet-stream Size: 36543 bytes Desc: not available URL: From jhrozek at redhat.com Tue Sep 24 15:48:28 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 24 Sep 2013 17:48:28 +0200 Subject: [Freeipa-users] access denied ssh In-Reply-To: References: <20130924100643.GW25628@localhost.localdomain> Message-ID: <20130924154828.GS20217@hendrix.redhat.com> On Tue, Sep 24, 2013 at 03:00:22PM +0400, ?????? ? wrote: > [sssd] > services = nss, pam, ssh > config_file_version = 2 > debug_level = 5 > domains = ipa.sys.local Please put the debug_level directive to the [domain] section and then attach /var/log/sssd/sssd_$domain.log From erinn.looneytriggs at gmail.com Tue Sep 24 17:23:29 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 24 Sep 2013 11:23:29 -0600 Subject: [Freeipa-users] TLSA records in FreeIPA Message-ID: <5241CA91.3060003@gmail.com> I wanted to bring up the idea of integrating TLSA records into FreeIPA so that a host that is issued a certificate for say the web server (via dogtag) would also publish that information in DNS using a TLSA record. This is very much like how SSHFP records are handled now in FreeIPA. Has this been considered at all? I am more than happy to write up some more info about this, I just wanted to get a preliminary idea of whether this had been considered at all... -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From avdusheff at gmail.com Tue Sep 24 17:38:49 2013 From: avdusheff at gmail.com (=?KOI8-R?B?7cnIwcnMIOE=?=) Date: Tue, 24 Sep 2013 21:38:49 +0400 Subject: [Freeipa-users] access denied ssh In-Reply-To: <20130924154828.GS20217@hendrix.redhat.com> References: <20130924100643.GW25628@localhost.localdomain> <20130924154828.GS20217@hendrix.redhat.com> Message-ID: ok, all sssd logs 2013/9/24 Jakub Hrozek > On Tue, Sep 24, 2013 at 03:00:22PM +0400, ?????? ? wrote: > > [sssd] > > services = nss, pam, ssh > > config_file_version = 2 > > debug_level = 5 > > domains = ipa.sys.local > > Please put the debug_level directive to the [domain] section and then > attach /var/log/sssd/sssd_$domain.log > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ldap_child.log Type: application/octet-stream Size: 1646 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd.log Type: application/octet-stream Size: 2074597 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd_ipa.sys.local.log Type: application/octet-stream Size: 53699 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: krb5_child.log Type: application/octet-stream Size: 3606 bytes Desc: not available URL: From pspacek at redhat.com Tue Sep 24 18:06:11 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 24 Sep 2013 20:06:11 +0200 Subject: [Freeipa-users] TLSA records in FreeIPA In-Reply-To: <5241CA91.3060003@gmail.com> References: <5241CA91.3060003@gmail.com> Message-ID: <5241D493.8030808@redhat.com> On 24.9.2013 19:23, Erinn Looney-Triggs wrote: > I wanted to bring up the idea of integrating TLSA records into FreeIPA > so that a host that is issued a certificate for say the web server (via > dogtag) would also publish that information in DNS using a TLSA record. > This is very much like how SSHFP records are handled now in FreeIPA. > > Has this been considered at all? > > I am more than happy to write up some more info about this, I just > wanted to get a preliminary idea of whether this had been considered at > all... You definitely have my +1! I'm working on DNSSEC support in FreeIPA, but we didn't went so far in our plans :-) Please create RFE ticket (request for enhancement): https://fedorahosted.org/freeipa/newticket You will need an Fedora Account, please follow this: https://fedoraproject.org/wiki/Account_System/NewAccount I would recommend you to add your e-mail address to Cc field in the ticket to get latest updates. We can continue with discussion here, of course! -- Petr^2 Spacek From chorn at fluxcoil.net Wed Sep 25 06:20:48 2013 From: chorn at fluxcoil.net (Christian Horn) Date: Wed, 25 Sep 2013 08:20:48 +0200 Subject: [Freeipa-users] TLSA records in FreeIPA In-Reply-To: <5241CA91.3060003@gmail.com> References: <5241CA91.3060003@gmail.com> Message-ID: <20130925062048.GA8220@fluxcoil.net> On Tue, Sep 24, 2013 at 11:23:29AM -0600, Erinn Looney-Triggs wrote: > I wanted to bring up the idea of integrating TLSA records into FreeIPA > so that a host that is issued a certificate for say the web server (via > dogtag) would also publish that information in DNS using a TLSA record. > This is very much like how SSHFP records are handled now in FreeIPA. > > Has this been considered at all? Hm.. another nice idea would be to announce services via zeroconf/bonjour. I guess effectively its the same as having clients search in DNS "who offers service XYZ" which we already do for ker- beros, ldap etc. Christian From pspacek at redhat.com Wed Sep 25 06:52:53 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 25 Sep 2013 08:52:53 +0200 Subject: [Freeipa-users] zeroconf/bonjour & FreeIPA In-Reply-To: <20130925062048.GA8220@fluxcoil.net> References: <5241CA91.3060003@gmail.com> <20130925062048.GA8220@fluxcoil.net> Message-ID: <52428845.2000307@redhat.com> On 25.9.2013 08:20, Christian Horn wrote: > On Tue, Sep 24, 2013 at 11:23:29AM -0600, Erinn Looney-Triggs wrote: >> I wanted to bring up the idea of integrating TLSA records into FreeIPA >> so that a host that is issued a certificate for say the web server (via >> dogtag) would also publish that information in DNS using a TLSA record. >> This is very much like how SSHFP records are handled now in FreeIPA. >> >> Has this been considered at all? > > Hm.. another nice idea would be to announce services via > zeroconf/bonjour. I guess effectively its the same as having clients > search in DNS "who offers service XYZ" which we already do for ker- > beros, ldap etc. Interesting idea. Do you know any real use cases? I have not seen Bonjour in real use except for network printers. Please create RFE ticket (request for enhancement) to prevent it from falling through the cracks: https://fedorahosted.org/freeipa/newticket I would recommend you to add your e-mail address to Cc field in the ticket to get latest updates. We can continue with discussion about use cases here and copy conclusions to the ticket later. -- Petr^2 Spacek From chorn at fluxcoil.net Wed Sep 25 07:07:17 2013 From: chorn at fluxcoil.net (Christian Horn) Date: Wed, 25 Sep 2013 09:07:17 +0200 Subject: [Freeipa-users] zeroconf/bonjour & FreeIPA In-Reply-To: <52428845.2000307@redhat.com> References: <5241CA91.3060003@gmail.com> <20130925062048.GA8220@fluxcoil.net> <52428845.2000307@redhat.com> Message-ID: <20130925070717.GB8220@fluxcoil.net> On Wed, Sep 25, 2013 at 08:52:53AM +0200, Petr Spacek wrote: > On 25.9.2013 08:20, Christian Horn wrote: > > > >Hm.. another nice idea would be to announce services via > >zeroconf/bonjour. I guess effectively its the same as having clients > >search in DNS "who offers service XYZ" which we already do for ker- > >beros, ldap etc. > > Interesting idea. Do you know any real use cases? I have not seen > Bonjour in real use except for network printers. It can be used for all protocols, so "generic service dis- covery". So one could setup a client in a network and see "oh, someone offers XMPP service". "Here are printers announcing services." "This DLNA server offers video streamin." I think the big window managers like gnome3 also started to use those and offer > Please create RFE ticket (request for enhancement) to prevent it > from falling through the cracks: > https://fedorahosted.org/freeipa/newticket Will do, bringing it up there makes definitely sense. But really curious on how widely (or if at all) there is interest in this. I think this style of service discovery is currently more used in desktop environments than in server environments. Christian From jhrozek at redhat.com Wed Sep 25 07:23:06 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 25 Sep 2013 09:23:06 +0200 Subject: [Freeipa-users] zeroconf/bonjour & FreeIPA In-Reply-To: <20130925070717.GB8220@fluxcoil.net> References: <5241CA91.3060003@gmail.com> <20130925062048.GA8220@fluxcoil.net> <52428845.2000307@redhat.com> <20130925070717.GB8220@fluxcoil.net> Message-ID: <20130925072306.GA20217@hendrix.redhat.com> On Wed, Sep 25, 2013 at 09:07:17AM +0200, Christian Horn wrote: > On Wed, Sep 25, 2013 at 08:52:53AM +0200, Petr Spacek wrote: > > On 25.9.2013 08:20, Christian Horn wrote: > > > > > >Hm.. another nice idea would be to announce services via > > >zeroconf/bonjour. I guess effectively its the same as having clients > > >search in DNS "who offers service XYZ" which we already do for ker- > > >beros, ldap etc. > > > > Interesting idea. Do you know any real use cases? I have not seen > > Bonjour in real use except for network printers. > > It can be used for all protocols, so "generic service dis- > covery". So one could setup a client in a network and see > "oh, someone offers XMPP service". "Here are printers > announcing services." "This DLNA server offers video > streamin." > > I think the big window managers like gnome3 also started to > use those and offer Traditionally avahi is used as zeroconf implementation on Linux. I think bonjour was Apple's implementation? From chorn at fluxcoil.net Wed Sep 25 07:32:00 2013 From: chorn at fluxcoil.net (Christian Horn) Date: Wed, 25 Sep 2013 09:32:00 +0200 Subject: [Freeipa-users] zeroconf/bonjour & FreeIPA In-Reply-To: <20130925072306.GA20217@hendrix.redhat.com> References: <5241CA91.3060003@gmail.com> <20130925062048.GA8220@fluxcoil.net> <52428845.2000307@redhat.com> <20130925070717.GB8220@fluxcoil.net> <20130925072306.GA20217@hendrix.redhat.com> Message-ID: <20130925073200.GC8220@fluxcoil.net> On Wed, Sep 25, 2013 at 09:23:06AM +0200, Jakub Hrozek wrote: > On Wed, Sep 25, 2013 at 09:07:17AM +0200, Christian Horn wrote: > > On Wed, Sep 25, 2013 at 08:52:53AM +0200, Petr Spacek wrote: > > > On 25.9.2013 08:20, Christian Horn wrote: > > > > > > > >Hm.. another nice idea would be to announce services via > > > >zeroconf/bonjour. I guess effectively its the same as having clients > > > >search in DNS "who offers service XYZ" which we already do for ker- > > > >beros, ldap etc. > > > > > > Interesting idea. Do you know any real use cases? I have not seen > > > Bonjour in real use except for network printers. > > > > It can be used for all protocols, so "generic service dis- > > covery". So one could setup a client in a network and see > > "oh, someone offers XMPP service". "Here are printers > > announcing services." "This DLNA server offers video > > streamin." > > > > I think the big window managers like gnome3 also started to > > use those and offer > > Traditionally avahi is used as zeroconf implementation on Linux. I think > bonjour was Apple's implementation? Yes, different names for the same underlying protocols. After some more thought, IPA might not have anything to do with zeroconf actually; the server itself does announce the services. I should have checked earlier :) So DNS would be the serverside (IPA side) implementation to announce services. Christian From abokovoy at redhat.com Wed Sep 25 07:43:16 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 25 Sep 2013 10:43:16 +0300 Subject: [Freeipa-users] zeroconf/bonjour & FreeIPA In-Reply-To: <20130925070717.GB8220@fluxcoil.net> References: <5241CA91.3060003@gmail.com> <20130925062048.GA8220@fluxcoil.net> <52428845.2000307@redhat.com> <20130925070717.GB8220@fluxcoil.net> Message-ID: <20130925074316.GW4216@redhat.com> On Wed, 25 Sep 2013, Christian Horn wrote: >On Wed, Sep 25, 2013 at 08:52:53AM +0200, Petr Spacek wrote: >> On 25.9.2013 08:20, Christian Horn wrote: >> > >> >Hm.. another nice idea would be to announce services via >> >zeroconf/bonjour. I guess effectively its the same as having clients >> >search in DNS "who offers service XYZ" which we already do for ker- >> >beros, ldap etc. >> >> Interesting idea. Do you know any real use cases? I have not seen >> Bonjour in real use except for network printers. > >It can be used for all protocols, so "generic service dis- >covery". So one could setup a client in a network and see >"oh, someone offers XMPP service". "Here are printers >announcing services." "This DLNA server offers video >streamin." > >I think the big window managers like gnome3 also started to >use those and offer > > >> Please create RFE ticket (request for enhancement) to prevent it >> from falling through the cracks: >> https://fedorahosted.org/freeipa/newticket > >Will do, bringing it up there makes definitely sense. >But really curious on how widely (or if at all) there is >interest in this. I think this style of service discovery >is currently more used in desktop environments than in >server environments. Before adding a support for this in FreeIPA it is worth to see if any of supposed clients would already have it supported. - OpenLDAP: - no support for zeroconf protocol though a request for adding that was filed in 2006: http://www.openldap.org/its/index.cgi/Contrib?id=4455 and abandoned since 2007. - MIT Kerberos: - no zeroconf support - Heimdal Kereberos: - no zeroconf support For Kerberos zeroconf integration represents some issues since it is generally not guaranteed that IP address of the client would stay the same through the life time of the zeroconf-based network application. Kerberos protocol has some support for NAT-ed clients (a closest scheme where a client IP may fluctuate during session time) so this might not be a big deal, also given that LL networks aren't really in use where Kerberos is in use. However, lack of zeroconf support in libkrb5 makes questionable whole excercise. After all, libkrb5 is able to configure itself, including default realm information, through SRV and TXT records of the default DNS domain supplied to the client. If any other services managed by IPA server (i.e. the ones we can see in 'ipa service-find') need to be exposed to zeroconf-enabled clients, some contextual information is needed in order to publish. A mere existence of the record in IPA database does not mean the service is actually available for use. In zeroconf it is duty of applications that provide the services to publish them to the zeroconf clients. This means when service is available, it is published (via avahi, for example). If service is not running, it is not published. -- / Alexander Bokovoy From chorn at fluxcoil.net Wed Sep 25 08:01:32 2013 From: chorn at fluxcoil.net (Christian Horn) Date: Wed, 25 Sep 2013 10:01:32 +0200 Subject: [Freeipa-users] zeroconf/bonjour & FreeIPA In-Reply-To: <20130925074316.GW4216@redhat.com> References: <5241CA91.3060003@gmail.com> <20130925062048.GA8220@fluxcoil.net> <52428845.2000307@redhat.com> <20130925070717.GB8220@fluxcoil.net> <20130925074316.GW4216@redhat.com> Message-ID: <20130925080132.GD8220@fluxcoil.net> On Wed, Sep 25, 2013 at 10:43:16AM +0300, Alexander Bokovoy wrote: > Before adding a support for this in FreeIPA it is worth to see if any of > supposed clients would already have it supported. I was more having in mind to announce services that IPA learns about automatically, but the server offering the service should do that. > - OpenLDAP: > - MIT Kerberos: > - Heimdal Kereberos: > [...] > > After all, libkrb5 is able to configure itself, including default realm > information, through SRV and TXT records of the default DNS domain > supplied to the client. ACK, for those I rather see DNS based service discovery to be useful. Christian From mkosek at redhat.com Wed Sep 25 08:17:04 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Sep 2013 10:17:04 +0200 Subject: [Freeipa-users] Cross-realm trust with AD and ssh keys management In-Reply-To: <20130924144031.GV4216@redhat.com> References: <99A3C898-1FDA-45C8-982C-9996C8610254@numeezy.com> <20130924144031.GV4216@redhat.com> Message-ID: <52429C00.6060302@redhat.com> On 09/24/2013 04:40 PM, Alexander Bokovoy wrote: > On Tue, 24 Sep 2013, Alexandre Ellert wrote: >> Hi, >> >> I've successfully setup a testing environment with an IPA server (RHEL 6.4) >> and a cross realm trust with my Active Directory (Win2008 R2). >> Authentication works both with AD passwords and Kerberos GSS-API. >> >> Now, I'm trying to find the way to manage ssh key which belong to AD >> users. It seems that I can do that only with users declared on IPA >> domain. Can you confirm that ? > Yes. AD users do not exist physically in IPA LDAP, therefore there is no > object to assign attributes into. >> Does winsync method provide a way to add ssh key to an AD user ? > Under winsync AD users would become 'normal' LDAP objects in IPA, > therefore you can assign additional values/attributes to them. Though note that winsync, one would loose all the SSO capabilities... Alexander, I am just thinking about possibilities. We now have the concept of external groups in FreeIPA which one can then use as members of normal POSIX groups and use them in HBAC or other policies. Would it be possible to create "external users", i.e. user entries identified by FQDN/SID and then be able to assign selected set of user attributes (like SSH public key, home directory, shell...) which could then be leveraged by SSSD? Martin From jcholast at redhat.com Wed Sep 25 08:28:12 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Sep 2013 10:28:12 +0200 Subject: [Freeipa-users] Cross-realm trust with AD and ssh keys management In-Reply-To: <52429C00.6060302@redhat.com> References: <99A3C898-1FDA-45C8-982C-9996C8610254@numeezy.com> <20130924144031.GV4216@redhat.com> <52429C00.6060302@redhat.com> Message-ID: <52429E9C.3020503@redhat.com> On 25.9.2013 10:17, Martin Kosek wrote: > On 09/24/2013 04:40 PM, Alexander Bokovoy wrote: >> On Tue, 24 Sep 2013, Alexandre Ellert wrote: >>> Hi, >>> >>> I've successfully setup a testing environment with an IPA server (RHEL 6.4) >>> and a cross realm trust with my Active Directory (Win2008 R2). >>> Authentication works both with AD passwords and Kerberos GSS-API. >>> >>> Now, I'm trying to find the way to manage ssh key which belong to AD >>> users. It seems that I can do that only with users declared on IPA >>> domain. Can you confirm that ? >> Yes. AD users do not exist physically in IPA LDAP, therefore there is no >> object to assign attributes into. >>> Does winsync method provide a way to add ssh key to an AD user ? >> Under winsync AD users would become 'normal' LDAP objects in IPA, >> therefore you can assign additional values/attributes to them. > > Though note that winsync, one would loose all the SSO capabilities... > > Alexander, I am just thinking about possibilities. We now have the concept of > external groups in FreeIPA which one can then use as members of normal POSIX > groups and use them in HBAC or other policies. > > Would it be possible to create "external users", i.e. user entries identified > by FQDN/SID and then be able to assign selected set of user attributes (like > SSH public key, home directory, shell...) which could then be leveraged by SSSD? > > Martin > I think that if you add proper schema to AD, you can have SSSD directly use SSH public keys stored in AD. Honza -- Jan Cholasta From abokovoy at redhat.com Wed Sep 25 08:30:01 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 25 Sep 2013 11:30:01 +0300 Subject: [Freeipa-users] Cross-realm trust with AD and ssh keys management In-Reply-To: <52429C00.6060302@redhat.com> References: <99A3C898-1FDA-45C8-982C-9996C8610254@numeezy.com> <20130924144031.GV4216@redhat.com> <52429C00.6060302@redhat.com> Message-ID: <20130925083001.GX4216@redhat.com> On Wed, 25 Sep 2013, Martin Kosek wrote: >On 09/24/2013 04:40 PM, Alexander Bokovoy wrote: >> On Tue, 24 Sep 2013, Alexandre Ellert wrote: >>> Hi, >>> >>> I've successfully setup a testing environment with an IPA server (RHEL 6.4) >>> and a cross realm trust with my Active Directory (Win2008 R2). >>> Authentication works both with AD passwords and Kerberos GSS-API. >>> >>> Now, I'm trying to find the way to manage ssh key which belong to AD >>> users. It seems that I can do that only with users declared on IPA >>> domain. Can you confirm that ? >> Yes. AD users do not exist physically in IPA LDAP, therefore there is no >> object to assign attributes into. >>> Does winsync method provide a way to add ssh key to an AD user ? >> Under winsync AD users would become 'normal' LDAP objects in IPA, >> therefore you can assign additional values/attributes to them. > >Though note that winsync, one would loose all the SSO capabilities... > >Alexander, I am just thinking about possibilities. We now have the concept of >external groups in FreeIPA which one can then use as members of normal POSIX >groups and use them in HBAC or other policies. > >Would it be possible to create "external users", i.e. user entries identified >by FQDN/SID and then be able to assign selected set of user attributes (like >SSH public key, home directory, shell...) which could then be leveraged by SSSD? Not sure it makes sense given that one can manage these attributes in AD. -- / Alexander Bokovoy From mkosek at redhat.com Wed Sep 25 08:32:29 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Sep 2013 10:32:29 +0200 Subject: [Freeipa-users] Cross-realm trust with AD and ssh keys management In-Reply-To: <20130925083001.GX4216@redhat.com> References: <99A3C898-1FDA-45C8-982C-9996C8610254@numeezy.com> <20130924144031.GV4216@redhat.com> <52429C00.6060302@redhat.com> <20130925083001.GX4216@redhat.com> Message-ID: <52429F9D.5030601@redhat.com> On 09/25/2013 10:30 AM, Alexander Bokovoy wrote: > On Wed, 25 Sep 2013, Martin Kosek wrote: >> On 09/24/2013 04:40 PM, Alexander Bokovoy wrote: >>> On Tue, 24 Sep 2013, Alexandre Ellert wrote: >>>> Hi, >>>> >>>> I've successfully setup a testing environment with an IPA server (RHEL 6.4) >>>> and a cross realm trust with my Active Directory (Win2008 R2). >>>> Authentication works both with AD passwords and Kerberos GSS-API. >>>> >>>> Now, I'm trying to find the way to manage ssh key which belong to AD >>>> users. It seems that I can do that only with users declared on IPA >>>> domain. Can you confirm that ? >>> Yes. AD users do not exist physically in IPA LDAP, therefore there is no >>> object to assign attributes into. >>>> Does winsync method provide a way to add ssh key to an AD user ? >>> Under winsync AD users would become 'normal' LDAP objects in IPA, >>> therefore you can assign additional values/attributes to them. >> >> Though note that winsync, one would loose all the SSO capabilities... >> >> Alexander, I am just thinking about possibilities. We now have the concept of >> external groups in FreeIPA which one can then use as members of normal POSIX >> groups and use them in HBAC or other policies. >> >> Would it be possible to create "external users", i.e. user entries identified >> by FQDN/SID and then be able to assign selected set of user attributes (like >> SSH public key, home directory, shell...) which could then be leveraged by SSSD? > Not sure it makes sense given that one can manage these attributes in > AD. True. This may then lead to a RFE for "Services for Identity Management for UNIX Components" AD extension... And when it's there, a similar RFE for SSSD to use the new attributes. Martin From sbose at redhat.com Wed Sep 25 08:35:26 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 25 Sep 2013 10:35:26 +0200 Subject: [Freeipa-users] Cross-realm trust with AD and ssh keys management In-Reply-To: <52429C00.6060302@redhat.com> References: <99A3C898-1FDA-45C8-982C-9996C8610254@numeezy.com> <20130924144031.GV4216@redhat.com> <52429C00.6060302@redhat.com> Message-ID: <20130925083526.GC25628@localhost.localdomain> On Wed, Sep 25, 2013 at 10:17:04AM +0200, Martin Kosek wrote: > On 09/24/2013 04:40 PM, Alexander Bokovoy wrote: > > On Tue, 24 Sep 2013, Alexandre Ellert wrote: > >> Hi, > >> > >> I've successfully setup a testing environment with an IPA server (RHEL 6.4) > >> and a cross realm trust with my Active Directory (Win2008 R2). > >> Authentication works both with AD passwords and Kerberos GSS-API. > >> > >> Now, I'm trying to find the way to manage ssh key which belong to AD > >> users. It seems that I can do that only with users declared on IPA > >> domain. Can you confirm that ? > > Yes. AD users do not exist physically in IPA LDAP, therefore there is no > > object to assign attributes into. > >> Does winsync method provide a way to add ssh key to an AD user ? > > Under winsync AD users would become 'normal' LDAP objects in IPA, > > therefore you can assign additional values/attributes to them. > > Though note that winsync, one would loose all the SSO capabilities... > > Alexander, I am just thinking about possibilities. We now have the concept of > external groups in FreeIPA which one can then use as members of normal POSIX > groups and use them in HBAC or other policies. > > Would it be possible to create "external users", i.e. user entries identified > by FQDN/SID and then be able to assign selected set of user attributes (like > SSH public key, home directory, shell...) which could then be leveraged by SSSD? Does anyone know if there is a ssh key management solution for AD? If yes, I think it would be better to use this and enhance SSSD to fetch them from AD. The data can then be stored in the sssd cache on the IPA servers and distributed to the IPA clients with the LDAP exop we already use to make the AD users available to the clients. bye, Sumit > > Martin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From abokovoy at redhat.com Wed Sep 25 09:01:38 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 25 Sep 2013 12:01:38 +0300 Subject: [Freeipa-users] Cross-realm trust with AD and ssh keys management In-Reply-To: <20130925083526.GC25628@localhost.localdomain> References: <99A3C898-1FDA-45C8-982C-9996C8610254@numeezy.com> <20130924144031.GV4216@redhat.com> <52429C00.6060302@redhat.com> <20130925083526.GC25628@localhost.localdomain> Message-ID: <20130925090138.GY4216@redhat.com> On Wed, 25 Sep 2013, Sumit Bose wrote: >On Wed, Sep 25, 2013 at 10:17:04AM +0200, Martin Kosek wrote: >> On 09/24/2013 04:40 PM, Alexander Bokovoy wrote: >> > On Tue, 24 Sep 2013, Alexandre Ellert wrote: >> >> Hi, >> >> >> >> I've successfully setup a testing environment with an IPA server (RHEL 6.4) >> >> and a cross realm trust with my Active Directory (Win2008 R2). >> >> Authentication works both with AD passwords and Kerberos GSS-API. >> >> >> >> Now, I'm trying to find the way to manage ssh key which belong to AD >> >> users. It seems that I can do that only with users declared on IPA >> >> domain. Can you confirm that ? >> > Yes. AD users do not exist physically in IPA LDAP, therefore there is no >> > object to assign attributes into. >> >> Does winsync method provide a way to add ssh key to an AD user ? >> > Under winsync AD users would become 'normal' LDAP objects in IPA, >> > therefore you can assign additional values/attributes to them. >> >> Though note that winsync, one would loose all the SSO capabilities... >> >> Alexander, I am just thinking about possibilities. We now have the concept of >> external groups in FreeIPA which one can then use as members of normal POSIX >> groups and use them in HBAC or other policies. >> >> Would it be possible to create "external users", i.e. user entries identified >> by FQDN/SID and then be able to assign selected set of user attributes (like >> SSH public key, home directory, shell...) which could then be leveraged by SSSD? > >Does anyone know if there is a ssh key management solution for AD? If >yes, I think it would be better to use this and enhance SSSD to fetch >them from AD. The data can then be stored in the sssd cache on the IPA >servers and distributed to the IPA clients with the LDAP exop we already >use to make the AD users available to the clients. Yes, there are few commercial solutions. Many of them use their own schemes so supporting them would need to work on multiple different schemes. http://tools.ietf.org/html/draft-ylonen-sshkeybcp-01 describes recommended practices. -- / Alexander Bokovoy From sbose at redhat.com Wed Sep 25 09:15:43 2013 From: sbose at redhat.com (Sumit Bose) Date: Wed, 25 Sep 2013 11:15:43 +0200 Subject: [Freeipa-users] Cross-realm trust with AD and ssh keys management In-Reply-To: <20130925090138.GY4216@redhat.com> References: <99A3C898-1FDA-45C8-982C-9996C8610254@numeezy.com> <20130924144031.GV4216@redhat.com> <52429C00.6060302@redhat.com> <20130925083526.GC25628@localhost.localdomain> <20130925090138.GY4216@redhat.com> Message-ID: <20130925091543.GD25628@localhost.localdomain> On Wed, Sep 25, 2013 at 12:01:38PM +0300, Alexander Bokovoy wrote: > On Wed, 25 Sep 2013, Sumit Bose wrote: > >On Wed, Sep 25, 2013 at 10:17:04AM +0200, Martin Kosek wrote: > >>On 09/24/2013 04:40 PM, Alexander Bokovoy wrote: > >>> On Tue, 24 Sep 2013, Alexandre Ellert wrote: > >>>> Hi, > >>>> > >>>> I've successfully setup a testing environment with an IPA server (RHEL 6.4) > >>>> and a cross realm trust with my Active Directory (Win2008 R2). > >>>> Authentication works both with AD passwords and Kerberos GSS-API. > >>>> > >>>> Now, I'm trying to find the way to manage ssh key which belong to AD > >>>> users. It seems that I can do that only with users declared on IPA > >>>> domain. Can you confirm that ? > >>> Yes. AD users do not exist physically in IPA LDAP, therefore there is no > >>> object to assign attributes into. > >>>> Does winsync method provide a way to add ssh key to an AD user ? > >>> Under winsync AD users would become 'normal' LDAP objects in IPA, > >>> therefore you can assign additional values/attributes to them. > >> > >>Though note that winsync, one would loose all the SSO capabilities... > >> > >>Alexander, I am just thinking about possibilities. We now have the concept of > >>external groups in FreeIPA which one can then use as members of normal POSIX > >>groups and use them in HBAC or other policies. > >> > >>Would it be possible to create "external users", i.e. user entries identified > >>by FQDN/SID and then be able to assign selected set of user attributes (like > >>SSH public key, home directory, shell...) which could then be leveraged by SSSD? > > > >Does anyone know if there is a ssh key management solution for AD? If > >yes, I think it would be better to use this and enhance SSSD to fetch > >them from AD. The data can then be stored in the sssd cache on the IPA > >servers and distributed to the IPA clients with the LDAP exop we already > >use to make the AD users available to the clients. > Yes, there are few commercial solutions. Many of them use their own > schemes so supporting them would need to work on multiple different > schemes. > > http://tools.ietf.org/html/draft-ylonen-sshkeybcp-01 describes recommended practices. Thank you for the details. So it looks that this might be an interesting RFE. bye, Sumit > > > -- > / Alexander Bokovoy From mkosek at redhat.com Wed Sep 25 10:34:59 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Sep 2013 12:34:59 +0200 Subject: [Freeipa-users] Cross-realm trust with AD and ssh keys management In-Reply-To: <20130925091543.GD25628@localhost.localdomain> References: <99A3C898-1FDA-45C8-982C-9996C8610254@numeezy.com> <20130924144031.GV4216@redhat.com> <52429C00.6060302@redhat.com> <20130925083526.GC25628@localhost.localdomain> <20130925090138.GY4216@redhat.com> <20130925091543.GD25628@localhost.localdomain> Message-ID: <5242BC53.5080003@redhat.com> On 09/25/2013 11:15 AM, Sumit Bose wrote: > On Wed, Sep 25, 2013 at 12:01:38PM +0300, Alexander Bokovoy wrote: >> On Wed, 25 Sep 2013, Sumit Bose wrote: >>> On Wed, Sep 25, 2013 at 10:17:04AM +0200, Martin Kosek wrote: >>>> On 09/24/2013 04:40 PM, Alexander Bokovoy wrote: >>>>> On Tue, 24 Sep 2013, Alexandre Ellert wrote: >>>>>> Hi, >>>>>> >>>>>> I've successfully setup a testing environment with an IPA server (RHEL 6.4) >>>>>> and a cross realm trust with my Active Directory (Win2008 R2). >>>>>> Authentication works both with AD passwords and Kerberos GSS-API. >>>>>> >>>>>> Now, I'm trying to find the way to manage ssh key which belong to AD >>>>>> users. It seems that I can do that only with users declared on IPA >>>>>> domain. Can you confirm that ? >>>>> Yes. AD users do not exist physically in IPA LDAP, therefore there is no >>>>> object to assign attributes into. >>>>>> Does winsync method provide a way to add ssh key to an AD user ? >>>>> Under winsync AD users would become 'normal' LDAP objects in IPA, >>>>> therefore you can assign additional values/attributes to them. >>>> >>>> Though note that winsync, one would loose all the SSO capabilities... >>>> >>>> Alexander, I am just thinking about possibilities. We now have the concept of >>>> external groups in FreeIPA which one can then use as members of normal POSIX >>>> groups and use them in HBAC or other policies. >>>> >>>> Would it be possible to create "external users", i.e. user entries identified >>>> by FQDN/SID and then be able to assign selected set of user attributes (like >>>> SSH public key, home directory, shell...) which could then be leveraged by SSSD? >>> >>> Does anyone know if there is a ssh key management solution for AD? If >>> yes, I think it would be better to use this and enhance SSSD to fetch >>> them from AD. The data can then be stored in the sssd cache on the IPA >>> servers and distributed to the IPA clients with the LDAP exop we already >>> use to make the AD users available to the clients. >> Yes, there are few commercial solutions. Many of them use their own >> schemes so supporting them would need to work on multiple different >> schemes. >> >> http://tools.ietf.org/html/draft-ylonen-sshkeybcp-01 describes recommended practices. > > Thank you for the details. So it looks that this might be an interesting > RFE. > > bye, > Sumit Agreed. I filed a RFE ticket: https://fedorahosted.org/sssd/ticket/2099 Martin From bret.wortman at damascusgrp.com Wed Sep 25 15:32:11 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 25 Sep 2013 11:32:11 -0400 Subject: [Freeipa-users] Where should new clients register? Message-ID: Does it make a difference which replica (or master) a new client registers with? I've traditionally tried to match them up with the closest ones, but if it doesn't make any real difference, I'll just grab whoever answers first and be done with it. * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Sep 25 15:55:32 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Sep 2013 17:55:32 +0200 Subject: [Freeipa-users] Where should new clients register? In-Reply-To: References: Message-ID: <52430774.7040203@redhat.com> On 09/25/2013 05:32 PM, Bret Wortman wrote: > Does it make a difference which replica (or master) a new client registers > with? I've traditionally tried to match them up with the closest ones, but > if it doesn't make any real difference, I'll just grab whoever answers > first and be done with it. It would matter if you would not use DNS autodiscovery as client use just the provided list of IPA servers to communicate with. However, if you use DNS autodiscovery, client (SSSD), will first use a (random) IPA server from the list of autodiscovered servers via DNS SRV records. You can verify in your sssd.conf: # grep ipa_server /etc/sssd/sssd.conf ipa_server = _srv_, vm-052.example.com When no DNS SRV record is found, it should fall back to the replica it was configured against. Things would change when DNS sites RFE is implemented and you could focus clients only to geographically close servers: https://fedorahosted.org/freeipa/ticket/2008 Thanks, Martin From shelltoesuperstar at gmail.com Wed Sep 25 22:00:51 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Wed, 25 Sep 2013 23:00:51 +0100 Subject: [Freeipa-users] IPA Query Tuning and a Recovery Question In-Reply-To: <523713D1.6050202@redhat.com> References: <522DF801.9050703@redhat.com> <523317DC.2050800@redhat.com> <52370B3B.3000500@redhat.com> <523713D1.6050202@redhat.com> Message-ID: On Mon, Sep 16, 2013 at 3:21 PM, Rob Crittenden wrote: > Rich Megginson wrote: > >> On 09/16/2013 03:21 AM, Charlie Derwent wrote: >> >>> Hi >>> Update on the errors >>> kinit charlesd >>> kinit: Generic error (see e-text) while getting initial credentials >>> krb5kdc.log - LOOKING_UP_CLIENT: charlesd at EXAMPLE.COM >>> for krbtg/EXAMPLE.COM at EXAMPLE.COM >>> >, Server >>> Error >>> >>> Starting the IPA service (dirsrv in particular) gives >>> Failed to read data from Directory Service: Failed to get list of >>> services to probe status! >>> Configured hostname 'ipa3.example.com ' >>> >>> doesn't match any master server in LDAP: >>> No master found because of error: {'matched': dc=example,dc=com', >>> 'desc': 'No such object'} >>> Shutting down >>> The errors log has a load of different services schema-compat-plugin. >>> dna-plugin, ipalockout_preop/postop all complaining in one way or >>> another about being unable to retrieve entries or no entries being set >>> up. >>> >> >> I think you'll have to use the workaround where you change replication >> to use simple bind in order to initialize the consumer, then switch back >> to sasl/gssapi. >> >> Simo/Rob - which ticket was this? Does freeipa.org have the workaround? >> > > http://freeipa.org/page/**TroubleshootingGuide#Replica_**Re-Initialization > > Sorry I hate leaving threads like this unresolved. So I had a go implementing the changes as shown above and I can see how and why it should have worked but whenever I tried to reinitialise from the remote server it still didn't load so I uninstalled the server removed the replication agreements by force and started from scratch and it's all good now. "You might want to edit the line on the link so "nsSaslMapFilterTemplate: (krbPrincipalName=&@IDM.LAB.BOS.REDHAT.COM)" reads "nsSaslMapFilterTemplate: (krbPrincipalName=&@$REALM)" but it's kind of obvious anyway. Thanks for the help Charlie > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Sep 26 01:52:38 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 25 Sep 2013 21:52:38 -0400 Subject: [Freeipa-users] Cross-realm trust with AD and ssh keys management In-Reply-To: <5242BC53.5080003@redhat.com> References: <99A3C898-1FDA-45C8-982C-9996C8610254@numeezy.com> <20130924144031.GV4216@redhat.com> <52429C00.6060302@redhat.com> <20130925083526.GC25628@localhost.localdomain> <20130925090138.GY4216@redhat.com> <20130925091543.GD25628@localhost.localdomain> <5242BC53.5080003@redhat.com> Message-ID: <52439366.6030307@redhat.com> On 09/25/2013 06:34 AM, Martin Kosek wrote: > On 09/25/2013 11:15 AM, Sumit Bose wrote: >> On Wed, Sep 25, 2013 at 12:01:38PM +0300, Alexander Bokovoy wrote: >>> On Wed, 25 Sep 2013, Sumit Bose wrote: >>>> On Wed, Sep 25, 2013 at 10:17:04AM +0200, Martin Kosek wrote: >>>>> On 09/24/2013 04:40 PM, Alexander Bokovoy wrote: >>>>>> On Tue, 24 Sep 2013, Alexandre Ellert wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I've successfully setup a testing environment with an IPA server (RHEL 6.4) >>>>>>> and a cross realm trust with my Active Directory (Win2008 R2). >>>>>>> Authentication works both with AD passwords and Kerberos GSS-API. >>>>>>> >>>>>>> Now, I'm trying to find the way to manage ssh key which belong to AD >>>>>>> users. It seems that I can do that only with users declared on IPA >>>>>>> domain. Can you confirm that ? >>>>>> Yes. AD users do not exist physically in IPA LDAP, therefore there is no >>>>>> object to assign attributes into. >>>>>>> Does winsync method provide a way to add ssh key to an AD user ? >>>>>> Under winsync AD users would become 'normal' LDAP objects in IPA, >>>>>> therefore you can assign additional values/attributes to them. >>>>> Though note that winsync, one would loose all the SSO capabilities... >>>>> >>>>> Alexander, I am just thinking about possibilities. We now have the concept of >>>>> external groups in FreeIPA which one can then use as members of normal POSIX >>>>> groups and use them in HBAC or other policies. >>>>> >>>>> Would it be possible to create "external users", i.e. user entries identified >>>>> by FQDN/SID and then be able to assign selected set of user attributes (like >>>>> SSH public key, home directory, shell...) which could then be leveraged by SSSD? >>>> Does anyone know if there is a ssh key management solution for AD? If >>>> yes, I think it would be better to use this and enhance SSSD to fetch >>>> them from AD. The data can then be stored in the sssd cache on the IPA >>>> servers and distributed to the IPA clients with the LDAP exop we already >>>> use to make the AD users available to the clients. >>> Yes, there are few commercial solutions. Many of them use their own >>> schemes so supporting them would need to work on multiple different >>> schemes. >>> >>> http://tools.ietf.org/html/draft-ylonen-sshkeybcp-01 describes recommended practices. >> Thank you for the details. So it looks that this might be an interesting >> RFE. >> >> bye, >> Sumit > Agreed. > > I filed a RFE ticket: https://fedorahosted.org/sssd/ticket/2099 > > Martin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users And to get back to the original question. When you have trusts and HBAC why do you need SSH keys? They do not add any value and become a burden to manage. You can use you Kerberos ticket to access systems you need and systems would check if you are allowed to access so I fail to see the need for the SSH in this case at all. What am I missing? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pviktori at redhat.com Thu Sep 26 08:01:03 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 26 Sep 2013 10:01:03 +0200 Subject: [Freeipa-users] IPA Query Tuning and a Recovery Question In-Reply-To: References: <522DF801.9050703@redhat.com> <523317DC.2050800@redhat.com> <52370B3B.3000500@redhat.com> <523713D1.6050202@redhat.com> Message-ID: <5243E9BF.3080009@redhat.com> On 09/26/2013 12:00 AM, Charlie Derwent wrote: > On Mon, Sep 16, 2013 at 3:21 PM, Rob Crittenden > wrote: [...] > > http://freeipa.org/page/__TroubleshootingGuide#Replica___Re-Initialization > > [...] > "You might want to edit the line on the link so > "nsSaslMapFilterTemplate: (krbPrincipalName=&@IDM.LAB.BOS.REDHAT.COM > )" reads "nsSaslMapFilterTemplate: > (krbPrincipalName=&@$REALM)" but it's kind of obvious anyway. Thanks for noticing, I've fixed it. -- Petr? From Duncan.Innes at virginmoney.com Thu Sep 26 11:05:22 2013 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Thu, 26 Sep 2013 12:05:22 +0100 Subject: [Freeipa-users] Force IPA to accept password? In-Reply-To: <5243E9BF.3080009@redhat.com> References: <522DF801.9050703@redhat.com><523317DC.2050800@redhat.com><52370B3B.3000500@redhat.com> <523713D1.6050202@redhat.com> <5243E9BF.3080009@redhat.com> Message-ID: <56343345B145C043AE990701E3D1939501D56CEC@EXVS2.nrplc.localnet> Hi, Can I force IPA to accept a new password that I have chosen? Today I've had to change my password in 2x AD domains and other places according to policy. I've done this. But coming to IPA, I find that I've chosen a "BAD PASSWORD". Without getting into the merits of the AD password policy and the security of the password I've chosen, can I force IPA to accept my new password at all? At the end of the day, our aspiration is to merge the AD domains and connect IPA to the new AD domain with a trust relationship. So I *should* have a Single Sign-On across all our machines. That's not possible short (or probably medium) term. So I'm wondering if I can poke IPA into playing ball for now. Any solutions? Cheers Duncan This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Discovery House, Whiting Road, Norwich NR4 6EJ: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com From bret.wortman at damascusgrp.com Thu Sep 26 12:30:12 2013 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Thu, 26 Sep 2013 08:30:12 -0400 Subject: [Freeipa-users] Error trying to enroll new client Message-ID: # ipa-client-install --enable-dns-updates --mkhomedir Discovery was successful! Hostname: os105.foo.net Realm: FOO.NET DNS Domain: foo.net IPA Server: osipa.foo.net BaseDN: dc=foo,dc=net Continue to configure the system with these values? [no]: yes User authrozied to enroll computers: admin Synchronizing time with KDC... Unable to sync time with IPA NTP server, assuming the time is in sync. Password for admin at FOO.NET Enrolled in IPA realm FOO.NET Created /etc/ipa/default.conf COnfigured /etc/sssd/sssd.conf COnfigured /etc/krb5.conf for IPA realm FOO.NET Failed to obtain host TGT. Installation failed. Rolling back changes. # I've seen the "unable to sync time" error before and have still been able to enroll, but something's different with this host. It also does this when I try to enroll with other replicas as well. Thoughts? * * *Bret Wortman* http://damascusgrp.com/ http://about.me/wortmanbret -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at andrewklau.com Thu Sep 26 12:55:16 2013 From: andrew at andrewklau.com (Andrew Lau) Date: Thu, 26 Sep 2013 22:55:16 +1000 Subject: [Freeipa-users] Error trying to enroll new client In-Reply-To: References: Message-ID: Unable to sync time normally means you've got the ntpd service running on the client (or the port is blocked). Try turn that off and then run ntpdate ipaserver or ipa-client-install again. I noticed this happened to me too a few times. I think it's because the new host you're trying to enroll is in the past and kerberos keys aren't active until x time. I may be wrong.. On Thu, Sep 26, 2013 at 10:30 PM, Bret Wortman wrote: > # ipa-client-install --enable-dns-updates --mkhomedir > Discovery was successful! > Hostname: os105.foo.net > Realm: FOO.NET > DNS Domain: foo.net > IPA Server: osipa.foo.net > BaseDN: dc=foo,dc=net > > > Continue to configure the system with these values? [no]: yes > User authrozied to enroll computers: admin > Synchronizing time with KDC... > Unable to sync time with IPA NTP server, assuming the time is in sync. > Password for admin at FOO.NET > > Enrolled in IPA realm FOO.NET > Created /etc/ipa/default.conf > COnfigured /etc/sssd/sssd.conf > COnfigured /etc/krb5.conf for IPA realm FOO.NET > Failed to obtain host TGT. > Installation failed. Rolling back changes. > # > > I've seen the "unable to sync time" error before and have still been able > to enroll, but something's different with this host. It also does this when > I try to enroll with other replicas as well. Thoughts? > > * > * > *Bret Wortman* > > http://damascusgrp.com/ > http://about.me/wortmanbret > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Sep 26 13:29:17 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Sep 2013 15:29:17 +0200 Subject: [Freeipa-users] Force IPA to accept password? In-Reply-To: <56343345B145C043AE990701E3D1939501D56CEC@EXVS2.nrplc.localnet> References: <522DF801.9050703@redhat.com><523317DC.2050800@redhat.com><52370B3B.3000500@redhat.com> <523713D1.6050202@redhat.com> <5243E9BF.3080009@redhat.com> <56343345B145C043AE990701E3D1939501D56CEC@EXVS2.nrplc.localnet> Message-ID: <524436AD.4040504@redhat.com> On 09/26/2013 01:05 PM, Innes, Duncan wrote: > Hi, > > Can I force IPA to accept a new password that I have chosen? What password do you have in mind? A password of an IPA user? > > Today I've had to change my password in 2x AD domains and other places > according to policy. I've done this. > > But coming to IPA, I find that I've chosen a "BAD PASSWORD". Without > getting into the merits of the AD password policy and the security of > the password I've chosen, can I force IPA to accept my new password at > all? Well, without getting into security of the approach, you could change the global password policy or group password policy so that the new password is accepted: $ ipa pwpolicy-mod --minlength=5 or $ ipa pwpolicy-add usergroup --minlength=5 ... to "fix" whatever failing password policy attribute. HTH, Martin From Duncan.Innes at virginmoney.com Thu Sep 26 13:58:43 2013 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Thu, 26 Sep 2013 14:58:43 +0100 Subject: [Freeipa-users] Force IPA to accept password? In-Reply-To: <524436AD.4040504@redhat.com> References: <522DF801.9050703@redhat.com><523317DC.2050800@redhat.com><52370B3B.3000500@redhat.com> <523713D1.6050202@redhat.com> <5243E9BF.3080009@redhat.com> <56343345B145C043AE990701E3D1939501D56CEC@EXVS2.nrplc.localnet> <524436AD.4040504@redhat.com> Message-ID: <56343345B145C043AE990701E3D1939501D56CEF@EXVS2.nrplc.localnet> Sorry, > -----Original Message----- > From: Martin Kosek [mailto:mkosek at redhat.com] > Sent: 26 September 2013 14:29 > To: Innes, Duncan > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Force IPA to accept password? > > On 09/26/2013 01:05 PM, Innes, Duncan wrote: > > Hi, > > > > Can I force IPA to accept a new password that I have chosen? > > What password do you have in mind? A password of an IPA user? > Yes - for my authentication when SSHing onto a Linux box. > > > > Today I've had to change my password in 2x AD domains and > > other places according to policy. I've done this. > > > > But coming to IPA, I find that I've chosen a "BAD > > PASSWORD". Without getting into the merits of the AD password > > policy and the security of the password I've chosen, can I > > force IPA to accept my new password at all? > > Well, without getting into security of the approach, you > could change the global password policy or group password > policy so that the new password is > accepted: > > $ ipa pwpolicy-mod --minlength=5 > > or > > $ ipa pwpolicy-add usergroup --minlength=5 > > ... to "fix" whatever failing password policy attribute. > The error comes from a dictionary check I think. AD does as well as far as I know, but would appear to have a smaller dictionary or looser rules. Kind of what I expected/feared though. I don't want to change the IPA policy at all, just override it's objection. For now, I went the long route and changed my IPA password first, then changed the other passwords To match what IPA was happy with. > HTH, > Martin > Cheers & thanks for your help Duncan This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Discovery House, Whiting Road, Norwich NR4 6EJ: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com From SteveD at redhat.com Thu Sep 26 14:40:44 2013 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 26 Sep 2013 10:40:44 -0400 Subject: [Freeipa-users] ipa service-add failing Message-ID: <5244476C.1030408@RedHat.com> Hello, I'm trying to create a secure NFS server so I need to add a service to the IPA server, but is failing $ kinit admin $ ipa service-add nfs/redhat-14.nfsv4bat.org ipa: ERROR: cannot connect to 'https://batman.nfsv4bat.org/ipa/xml': Internal Server Error $ I'm not asking what the problem is, I'm ask how do I debug it? tia, steved. PS. Please cc me directly since I am not a member of this list. From rcritten at redhat.com Thu Sep 26 15:04:12 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Sep 2013 11:04:12 -0400 Subject: [Freeipa-users] ipa service-add failing In-Reply-To: <5244476C.1030408@RedHat.com> References: <5244476C.1030408@RedHat.com> Message-ID: <52444CEC.9020009@redhat.com> Steve Dickson wrote: > Hello, > > I'm trying to create a secure NFS server so I need > to add a service to the IPA server, but is failing > > $ kinit admin > $ ipa service-add nfs/redhat-14.nfsv4bat.org > ipa: ERROR: cannot connect to 'https://batman.nfsv4bat.org/ipa/xml': Internal Server Error > $ > > I'm not asking what the problem is, I'm ask how do I debug it? Start with /var/log/httpd/error_log. This usually indicates a python backtrace which we don't send to clients. To beef up the logging you can create /etc/ipa/server.conf containing: [global] debug = True then restart httpd. You can optionally set debug = True in /etc/ipa/default.conf but that will put any clients into debug mode too. rob From sakodak at gmail.com Thu Sep 26 15:35:23 2013 From: sakodak at gmail.com (KodaK) Date: Thu, 26 Sep 2013 10:35:23 -0500 Subject: [Freeipa-users] Force IPA to accept password? In-Reply-To: <56343345B145C043AE990701E3D1939501D56CEF@EXVS2.nrplc.localnet> References: <522DF801.9050703@redhat.com> <523317DC.2050800@redhat.com> <52370B3B.3000500@redhat.com> <523713D1.6050202@redhat.com> <5243E9BF.3080009@redhat.com> <56343345B145C043AE990701E3D1939501D56CEC@EXVS2.nrplc.localnet> <524436AD.4040504@redhat.com> <56343345B145C043AE990701E3D1939501D56CEF@EXVS2.nrplc.localnet> Message-ID: As far as I can tell, password policy is enforced on the client side, not the directory side. I set up a self-service password reset utility which enforces its own rules and bypasses the IPA password policies. I used this one: http://ltb-project.org I created a user that had the ability to create passwords, but IIRC there was some setting I had to change so that the passwords created didn't require a change. I'm pretty sure someone in this list told me how, so I'll search and see if I can find it. --Jason On Thu, Sep 26, 2013 at 8:58 AM, Innes, Duncan wrote: > Sorry, > > > -----Original Message----- > > From: Martin Kosek [mailto:mkosek at redhat.com] > > Sent: 26 September 2013 14:29 > > To: Innes, Duncan > > Cc: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] Force IPA to accept password? > > > > On 09/26/2013 01:05 PM, Innes, Duncan wrote: > > > Hi, > > > > > > Can I force IPA to accept a new password that I have chosen? > > > > What password do you have in mind? A password of an IPA user? > > > > Yes - for my authentication when SSHing onto a Linux box. > > > > > > > Today I've had to change my password in 2x AD domains and > > > other places according to policy. I've done this. > > > > > > But coming to IPA, I find that I've chosen a "BAD > > > PASSWORD". Without getting into the merits of the AD password > > > policy and the security of the password I've chosen, can I > > > force IPA to accept my new password at all? > > > > Well, without getting into security of the approach, you > > could change the global password policy or group password > > policy so that the new password is > > accepted: > > > > $ ipa pwpolicy-mod --minlength=5 > > > > or > > > > $ ipa pwpolicy-add usergroup --minlength=5 > > > > ... to "fix" whatever failing password policy attribute. > > > > The error comes from a dictionary check I think. AD does as well as far > as I know, but would appear to have a smaller dictionary or looser > rules. > > Kind of what I expected/feared though. I don't want to change the IPA > policy at all, just override it's objection. For now, I went the long > route and changed my IPA password first, then changed the other > passwords > To match what IPA was happy with. > > > HTH, > > Martin > > > > Cheers & thanks for your help > > Duncan > > This message has been checked for viruses and spam by the Virgin Money > email scanning system powered by Messagelabs. > > > > This e-mail is intended to be confidential to the recipient. If you > receive a copy in error, please inform the sender and then delete this > message. > > Virgin Money plc - Registered in England and Wales (Company no. 6952311). > Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. > Virgin Money plc is authorised by the Prudential Regulation Authority and > regulated by the Financial Conduct Authority and the Prudential Regulation > Authority. > > The following companies also trade as Virgin Money. They are both > authorised and regulated by the Financial Conduct Authority, are registered > in England and Wales and have their registered office at Discovery House, > Whiting Road, Norwich NR4 6EJ: Virgin Money Personal Financial Service > Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited > (Company no. 3000482). > > For further details of Virgin Money group companies please visit our > website at virginmoney.com > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sakodak at gmail.com Thu Sep 26 15:38:11 2013 From: sakodak at gmail.com (KodaK) Date: Thu, 26 Sep 2013 10:38:11 -0500 Subject: [Freeipa-users] Force IPA to accept password? In-Reply-To: References: <522DF801.9050703@redhat.com> <523317DC.2050800@redhat.com> <52370B3B.3000500@redhat.com> <523713D1.6050202@redhat.com> <5243E9BF.3080009@redhat.com> <56343345B145C043AE990701E3D1939501D56CEC@EXVS2.nrplc.localnet> <524436AD.4040504@redhat.com> <56343345B145C043AE990701E3D1939501D56CEF@EXVS2.nrplc.localnet> Message-ID: Here's what I had to do: http://www.freeipa.org/page/PasswordSynchronization On Thu, Sep 26, 2013 at 10:35 AM, KodaK wrote: > As far as I can tell, password policy is enforced on the client side, not > the directory side. > > I set up a self-service password reset utility which enforces its own > rules and bypasses the IPA password policies. > > I used this one: > > http://ltb-project.org > > I created a user that had the ability to create passwords, but IIRC there > was some setting I had to change so that the passwords created didn't > require a change. > > I'm pretty sure someone in this list told me how, so I'll search and see > if I can find it. > > --Jason > > > > On Thu, Sep 26, 2013 at 8:58 AM, Innes, Duncan < > Duncan.Innes at virginmoney.com> wrote: > >> Sorry, >> >> > -----Original Message----- >> > From: Martin Kosek [mailto:mkosek at redhat.com] >> > Sent: 26 September 2013 14:29 >> > To: Innes, Duncan >> > Cc: freeipa-users at redhat.com >> > Subject: Re: [Freeipa-users] Force IPA to accept password? >> > >> > On 09/26/2013 01:05 PM, Innes, Duncan wrote: >> > > Hi, >> > > >> > > Can I force IPA to accept a new password that I have chosen? >> > >> > What password do you have in mind? A password of an IPA user? >> > >> >> Yes - for my authentication when SSHing onto a Linux box. >> >> > > >> > > Today I've had to change my password in 2x AD domains and >> > > other places according to policy. I've done this. >> > > >> > > But coming to IPA, I find that I've chosen a "BAD >> > > PASSWORD". Without getting into the merits of the AD password >> > > policy and the security of the password I've chosen, can I >> > > force IPA to accept my new password at all? >> > >> > Well, without getting into security of the approach, you >> > could change the global password policy or group password >> > policy so that the new password is >> > accepted: >> > >> > $ ipa pwpolicy-mod --minlength=5 >> > >> > or >> > >> > $ ipa pwpolicy-add usergroup --minlength=5 >> > >> > ... to "fix" whatever failing password policy attribute. >> > >> >> The error comes from a dictionary check I think. AD does as well as far >> as I know, but would appear to have a smaller dictionary or looser >> rules. >> >> Kind of what I expected/feared though. I don't want to change the IPA >> policy at all, just override it's objection. For now, I went the long >> route and changed my IPA password first, then changed the other >> passwords >> To match what IPA was happy with. >> >> > HTH, >> > Martin >> > >> >> Cheers & thanks for your help >> >> Duncan >> >> This message has been checked for viruses and spam by the Virgin Money >> email scanning system powered by Messagelabs. >> >> >> >> This e-mail is intended to be confidential to the recipient. If you >> receive a copy in error, please inform the sender and then delete this >> message. >> >> Virgin Money plc - Registered in England and Wales (Company no. 6952311). >> Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. >> Virgin Money plc is authorised by the Prudential Regulation Authority and >> regulated by the Financial Conduct Authority and the Prudential Regulation >> Authority. >> >> The following companies also trade as Virgin Money. They are both >> authorised and regulated by the Financial Conduct Authority, are registered >> in England and Wales and have their registered office at Discovery House, >> Whiting Road, Norwich NR4 6EJ: Virgin Money Personal Financial Service >> Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited >> (Company no. 3000482). >> >> For further details of Virgin Money group companies please visit our >> website at virginmoney.com >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > > > -- > The government is going to read our mail anyway, might as well make it > tough for them. GPG Public key ID: B6A1A7C6 > -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Thu Sep 26 16:35:33 2013 From: sbose at redhat.com (Sumit Bose) Date: Thu, 26 Sep 2013 18:35:33 +0200 Subject: [Freeipa-users] Force IPA to accept password? In-Reply-To: <56343345B145C043AE990701E3D1939501D56CEF@EXVS2.nrplc.localnet> References: <523317DC.2050800@redhat.com> <52370B3B.3000500@redhat.com> <523713D1.6050202@redhat.com> <5243E9BF.3080009@redhat.com> <56343345B145C043AE990701E3D1939501D56CEC@EXVS2.nrplc.localnet> <524436AD.4040504@redhat.com> <56343345B145C043AE990701E3D1939501D56CEF@EXVS2.nrplc.localnet> Message-ID: <20130926163533.GF10000@localhost.localdomain> On Thu, Sep 26, 2013 at 02:58:43PM +0100, Innes, Duncan wrote: > Sorry, > > > -----Original Message----- > > From: Martin Kosek [mailto:mkosek at redhat.com] > > Sent: 26 September 2013 14:29 > > To: Innes, Duncan > > Cc: freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] Force IPA to accept password? > > > > On 09/26/2013 01:05 PM, Innes, Duncan wrote: > > > Hi, > > > > > > Can I force IPA to accept a new password that I have chosen? > > > > What password do you have in mind? A password of an IPA user? > > > > Yes - for my authentication when SSHing onto a Linux box. > > > > > > > Today I've had to change my password in 2x AD domains and > > > other places according to policy. I've done this. > > > > > > But coming to IPA, I find that I've chosen a "BAD > > > PASSWORD". Without getting into the merits of the AD password > > > policy and the security of the password I've chosen, can I > > > force IPA to accept my new password at all? > > > > Well, without getting into security of the approach, you > > could change the global password policy or group password > > policy so that the new password is > > accepted: > > > > $ ipa pwpolicy-mod --minlength=5 > > > > or > > > > $ ipa pwpolicy-add usergroup --minlength=5 > > > > ... to "fix" whatever failing password policy attribute. > > > > The error comes from a dictionary check I think. AD does as well as far > as I know, but would appear to have a smaller dictionary or looser > rules. > > Kind of what I expected/feared though. I don't want to change the IPA > policy at all, just override it's objection. For now, I went the long > route and changed my IPA password first, then changed the other > passwords > To match what IPA was happy with. Which command did you use to change the password? 'passwd' or 'ipa passwd'? If you use 'passwd' the PAM stack on the client for the passwd command comes into play which typically has some modules like pam_pwquality.so listed which do checks including dictionary checks. If you use 'ipa passwd' the password should be only validated against the server-side password policy Martin mentioned above. HTH bye, Sumit > > > HTH, > > Martin > > > > Cheers & thanks for your help > > Duncan > > This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. > > > > This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. > > Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. > > The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Discovery House, Whiting Road, Norwich NR4 6EJ: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). > > For further details of Virgin Money group companies please visit our website at virginmoney.com > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From erinn.looneytriggs at gmail.com Thu Sep 26 17:35:36 2013 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 26 Sep 2013 11:35:36 -0600 Subject: [Freeipa-users] TLSA records in FreeIPA In-Reply-To: <5241D493.8030808@redhat.com> References: <5241CA91.3060003@gmail.com> <5241D493.8030808@redhat.com> Message-ID: <52447068.1050506@gmail.com> On 09/24/2013 12:06 PM, Petr Spacek wrote: > On 24.9.2013 19:23, Erinn Looney-Triggs wrote: >> I wanted to bring up the idea of integrating TLSA records into FreeIPA >> so that a host that is issued a certificate for say the web server (via >> dogtag) would also publish that information in DNS using a TLSA record. >> This is very much like how SSHFP records are handled now in FreeIPA. >> >> Has this been considered at all? >> >> I am more than happy to write up some more info about this, I just >> wanted to get a preliminary idea of whether this had been considered at >> all... > > You definitely have my +1! > > I'm working on DNSSEC support in FreeIPA, but we didn't went so far in > our plans :-) > > > Please create RFE ticket (request for enhancement): > https://fedorahosted.org/freeipa/newticket > > You will need an Fedora Account, please follow this: > https://fedoraproject.org/wiki/Account_System/NewAccount > > I would recommend you to add your e-mail address to Cc field in the > ticket to get latest updates. > > We can continue with discussion here, of course! > Ok well here is my vision for this: I believe you folks are building a web and cli based interface via IPA into dogtag. This would tie into that and have something like a check box to publish the certificate hash in DNS. Again this is much like SSHFP records. I don't believe you would want all certificates published via TLSA so it should probably be optional. As well, the certificates would have to have a "purpose" by which I mean a way of differentiating between one for a web server and one for say SMTP. This may tie in with the X509 constraints but I am not sure on that front. A TLSA record looks much like a SRV record, to wit: _443._tcp.www.abaqis.com. IN TLSA 3 0 1 23ceabbd33f8458738de1dcec5662c97f4edb5b6251b498274e2351e7f695a04 So clearly with the port numbers etc included in there, there would need to be a way to mark a certificate as a web certificate etc. The certificate hashes would also of course need to be updated as the certificates are renewed. This may require a tie in to certmonger, though I suspect not. This would be a "very good thing" as TLSA will eventually allow us to circumvent the extremely broken trust model we have with current CAs and FreeIPA looks like a wonderful candidate place to automate exactly this. Requirements: TLSA is not very useful without DNSSEC, which you folks are currently implementing. BIND >= 9.7.6 though earlier versions can use TLSA records this was the version that implemented native handling. Use cases: Honestly at this point there are not a whole lot of programs that can utilize TLSA. The only notable exception that I know of is postfix, which will use TLSA natively if configured to do so (thus alleviating the cottage industry of self signed certificates for smtp server). Documentation here: http://www.postfix.org/TLS_README.html#client_tls_dane There is also a plugin for firefox that will validate TLSA: https://os3sec.org/ A nice primer on TLSA: http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec A program for creating hashes: http://people.redhat.com/pwouters/hash-slinger/ And a bit of an article on its use: http://www.internetsociety.org/deploy360/blog/2012/11/hash-slinger-helps-you-easily-create-tlsa-records-for-dnssec-dane/ And finally a link to the RFE: https://fedorahosted.org/freeipa/ticket/3950 -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From chandank.kumar at gmail.com Thu Sep 26 23:25:25 2013 From: chandank.kumar at gmail.com (Chandan Kumar) Date: Thu, 26 Sep 2013 16:25:25 -0700 Subject: [Freeipa-users] Accessing IPA servers on no-standard port Message-ID: Hello, I have basic configuration question, my apologies if it has already been discussed. I have ipa-server-3 server installed with default parameters with replication. We have Linux machines across different geo location and I would like to integrate them into IPA server, however, I don't want external clients to connect the server on standard port. For example, during ipa-client registration it requires all IPA services to be running on default port. Such as : trying https://ipa01.my.net/ipa/xml kdc = ipa01.my.net:88 master_kdc = ipa01.my.net:88 admin_server = ipa01.my.net:749 Is there any way in ipa-client-install or sssd file to instruct IPA client to connect to IPA server on no-standard ports such as trying https://ipa01.my.net:8080/ipa/xml This way I don't have to allocate a separate IP or additional web server to redirect the requests a simple NAT at firewall will do such as external 8080 -> internal 443 Thanks -- http://about.me/chandank -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Sep 27 02:51:25 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Sep 2013 22:51:25 -0400 Subject: [Freeipa-users] Accessing IPA servers on no-standard port In-Reply-To: References: Message-ID: <5244F2AD.8050603@redhat.com> Chandan Kumar wrote: > Hello, > > I have basic configuration question, my apologies if it has already been > discussed. > > I have ipa-server-3 server installed with default parameters with > replication. > > We have Linux machines across different geo location and I would like to > integrate them into IPA server, however, I don't want external clients > to connect the server on standard port. > > For example, during ipa-client registration it requires all IPA services > to be running on default port. > > Such as : trying https://ipa01.my.net/ipa/xml > > kdc = ipa01.my.net:88 > master_kdc = ipa01.my.net:88 > admin_server = ipa01.my.net:749 > > Is there any way in ipa-client-install or sssd file to instruct IPA > client to connect to IPA server on no-standard ports such as > > trying https://ipa01.my.net:8080/ipa/xml > > This way I don't have to allocate a separate IP or additional web server > to redirect the requests a simple NAT at firewall will do such as > external 8080 -> internal 443 Currently there is no way to do this. I'd have sworn we had a ticket to add this but a quick search didn't turn it up. If you'd like this supported feel free to open a ticket at https://fedorahosted.org/freeipa/newticket I don't think this would be tremendously difficult to do, the trick would be communicating the port to clients somehow while they are trying to enroll. A command-line option would probably be the shortest path. This may be decent low-hanging fruit if you're interested in being a contributor to IPA. rob From mohan.cheema at arrkgroup.com Fri Sep 27 04:45:21 2013 From: mohan.cheema at arrkgroup.com (Mohan Cheema) Date: Fri, 27 Sep 2013 05:45:21 +0100 Subject: [Freeipa-users] FreeIPA Master Slave Setup Client Configuration Message-ID: <411001cebb3c$607c6500$21752f00$@cheema@arrkgroup.com> Hi, We have setup FreeIPA within our environment the setup is master slave. We want to know how we can configure clients to look to slave incase master server is no available to authenticate the user. Regards, Mohan Cheema -------------- next part -------------- An HTML attachment was scrubbed... URL: From chandank.kumar at gmail.com Fri Sep 27 05:23:08 2013 From: chandank.kumar at gmail.com (Chandan Kumar) Date: Thu, 26 Sep 2013 22:23:08 -0700 Subject: [Freeipa-users] Accessing IPA servers on no-standard port In-Reply-To: <5244F2AD.8050603@redhat.com> References: <5244F2AD.8050603@redhat.com> Message-ID: Hi Rob, Thanks for the info. Sure I will create the ticket and will certainly try to pick the low-hanging fruit :-) -- http://about.me/chandank On Thu, Sep 26, 2013 at 7:51 PM, Rob Crittenden wrote: > Chandan Kumar wrote: > >> Hello, >> >> I have basic configuration question, my apologies if it has already been >> discussed. >> >> I have ipa-server-3 server installed with default parameters with >> replication. >> >> We have Linux machines across different geo location and I would like to >> integrate them into IPA server, however, I don't want external clients >> to connect the server on standard port. >> >> For example, during ipa-client registration it requires all IPA services >> to be running on default port. >> >> Such as : trying https://ipa01.my.net/ipa/xml >> >> kdc = ipa01.my.net:88 >> master_kdc = ipa01.my.net:88 >> admin_server = ipa01.my.net:749 >> >> >> Is there any way in ipa-client-install or sssd file to instruct IPA >> client to connect to IPA server on no-standard ports such as >> >> trying https://ipa01.my.net:8080/ipa/**xml >> >> This way I don't have to allocate a separate IP or additional web server >> to redirect the requests a simple NAT at firewall will do such as >> external 8080 -> internal 443 >> > > Currently there is no way to do this. I'd have sworn we had a ticket to > add this but a quick search didn't turn it up. If you'd like this supported > feel free to open a ticket at https://fedorahosted.org/**freeipa/newticket > > I don't think this would be tremendously difficult to do, the trick would > be communicating the port to clients somehow while they are trying to > enroll. A command-line option would probably be the shortest path. > > This may be decent low-hanging fruit if you're interested in being a > contributor to IPA. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Duncan.Innes at virginmoney.com Fri Sep 27 07:31:48 2013 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Fri, 27 Sep 2013 08:31:48 +0100 Subject: [Freeipa-users] Force IPA to accept password? In-Reply-To: <20130926163533.GF10000@localhost.localdomain> References: <523317DC.2050800@redhat.com><52370B3B.3000500@redhat.com> <523713D1.6050202@redhat.com><5243E9BF.3080009@redhat.com><56343345B145C043AE990701E3D1939501D56CEC@EXVS2.nrplc.localnet><524436AD.4040504@redhat.com><56343345B145C043AE990701E3D1939501D56CEF@EXVS2.nrplc.localnet> <20130926163533.GF10000@localhost.localdomain> Message-ID: <56343345B145C043AE990701E3D1939501D56CF2@EXVS2.nrplc.localnet> > -----Original Message----- > From: freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Sumit Bose > Sent: 26 September 2013 17:36 > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Force IPA to accept password? > > On Thu, Sep 26, 2013 at 02:58:43PM +0100, Innes, Duncan wrote: > > Sorry, > > > > > -----Original Message----- > > > From: Martin Kosek [mailto:mkosek at redhat.com] > > > Sent: 26 September 2013 14:29 > > > To: Innes, Duncan > > > Cc: freeipa-users at redhat.com > > > Subject: Re: [Freeipa-users] Force IPA to accept password? > > > > > > On 09/26/2013 01:05 PM, Innes, Duncan wrote: > > > > Hi, > > > > > > > > Can I force IPA to accept a new password that I have chosen? > > > > > > What password do you have in mind? A password of an IPA user? > > > > > > > Yes - for my authentication when SSHing onto a Linux box. > > > > > > > > > > Today I've had to change my password in 2x AD domains and other > > > > places according to policy. I've done this. > > > > > > > > But coming to IPA, I find that I've chosen a "BAD PASSWORD". > > > > Without getting into the merits of the AD password policy > > > > and the security of the password I've chosen, can I force IPA > > > > to accept my new password at all? > > > > > > Well, without getting into security of the approach, you could > > > change the global password policy or group password policy so > > > that the new password is accepted: > > > > > > $ ipa pwpolicy-mod --minlength=5 > > > > > > or > > > > > > $ ipa pwpolicy-add usergroup --minlength=5 > > > > > > ... to "fix" whatever failing password policy attribute. > > > > > > > The error comes from a dictionary check I think. AD does as well > > as far as I know, but would appear to have a smaller dictionary or > > looser rules. > > > > Kind of what I expected/feared though. I don't want to change the > > IPA policy at all, just override it's objection. For now, I went > > the long route and changed my IPA password first, then changed the > > other passwords To match what IPA was happy with. > > Which command did you use to change the password? 'passwd' or > 'ipa passwd'? > > If you use 'passwd' the PAM stack on the client for the > passwd command comes into play which typically has some > modules like pam_pwquality.so listed which do checks > including dictionary checks. > > If you use 'ipa passwd' the password should be only validated > against the server-side password policy Martin mentioned above. Sumit, yes - I used 'passwd'. I'll look into using 'ipa passwd' in about 3 months time :-) Thanks > > HTH > > bye, > Sumit > > > > > HTH, > > > Martin > > > > > > > Cheers & thanks for your help > > > > Duncan > > This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Discovery House, Whiting Road, Norwich NR4 6EJ: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com From pspacek at redhat.com Fri Sep 27 07:40:24 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 27 Sep 2013 09:40:24 +0200 Subject: [Freeipa-users] Accessing IPA servers on no-standard port In-Reply-To: References: <5244F2AD.8050603@redhat.com> Message-ID: <52453668.8080103@redhat.com> On 27.9.2013 07:23, Chandan Kumar wrote: > Hi Rob, > > Thanks for the info. Sure I will create the ticket and will certainly try > to pick the low-hanging fruit :-) > > > -- > http://about.me/chandank > > > On Thu, Sep 26, 2013 at 7:51 PM, Rob Crittenden wrote: > >> Chandan Kumar wrote: >> >>> Hello, >>> >>> I have basic configuration question, my apologies if it has already been >>> discussed. >>> >>> I have ipa-server-3 server installed with default parameters with >>> replication. >>> >>> We have Linux machines across different geo location and I would like to >>> integrate them into IPA server, however, I don't want external clients >>> to connect the server on standard port. >>> >>> For example, during ipa-client registration it requires all IPA services >>> to be running on default port. >>> >>> Such as : trying https://ipa01.my.net/ipa/xml >>> >>> kdc = ipa01.my.net:88 >>> master_kdc = ipa01.my.net:88 >>> admin_server = ipa01.my.net:749 >>> >>> >>> Is there any way in ipa-client-install or sssd file to instruct IPA >>> client to connect to IPA server on no-standard ports such as >>> >>> trying https://ipa01.my.net:8080/ipa/**xml >>> >>> This way I don't have to allocate a separate IP or additional web server >>> to redirect the requests a simple NAT at firewall will do such as >>> external 8080 -> internal 443 >>> >> >> Currently there is no way to do this. I'd have sworn we had a ticket to >> add this but a quick search didn't turn it up. If you'd like this supported >> feel free to open a ticket at https://fedorahosted.org/**freeipa/newticket >> >> I don't think this would be tremendously difficult to do, the trick would >> be communicating the port to clients somehow while they are trying to >> enroll. A command-line option would probably be the shortest path. >> >> This may be decent low-hanging fruit if you're interested in being a >> contributor to IPA. Speaking specifically about Kerberos, LDAP and NTP - it should be possible to change port number in SRV records in DNS and that is it. I'm not sure if client libraries really support this, but you can try it. HTTP and HTTPS will be more problematic because there there are no SRV records for them. -- Petr^2 Spacek From mkosek at redhat.com Fri Sep 27 08:22:07 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Sep 2013 10:22:07 +0200 Subject: [Freeipa-users] FreeIPA Master Slave Setup Client Configuration In-Reply-To: <411001cebb3c$607c6500$21752f00$@cheema@arrkgroup.com> References: <411001cebb3c$607c6500$21752f00$@cheema@arrkgroup.com> Message-ID: <5245402F.9080407@redhat.com> On 09/27/2013 06:45 AM, Mohan Cheema wrote: > Hi, > > We have setup FreeIPA within our environment the setup is master slave. We want > to know how we can configure clients to look to slave incase master server is > no available to authenticate the user. > > Regards, > > ** > > *Mohan Cheema* FreeIPA replicas are master-master replicas by default. Can you please elaborate how did you create the slave server? About client configuration - can you use autodiscovery with DNS SRV records? (the same as IPA uses for autodiscovery). You would just need to create DNS SRV records for your slave server, with priority lower than the priority of master server. Client should then look at the slave only if the master is not available. HTH, Martin From mkosek at redhat.com Fri Sep 27 08:27:30 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Sep 2013 10:27:30 +0200 Subject: [Freeipa-users] Force IPA to accept password? In-Reply-To: <56343345B145C043AE990701E3D1939501D56CF2@EXVS2.nrplc.localnet> References: <523317DC.2050800@redhat.com><52370B3B.3000500@redhat.com> <523713D1.6050202@redhat.com><5243E9BF.3080009@redhat.com><56343345B145C043AE990701E3D1939501D56CEC@EXVS2.nrplc.localnet><524436AD.4040504@redhat.com><56343345B145C043AE990701E3D1939501D56CEF@EXVS2.nrplc.localnet> <20130926163533.GF10000@localhost.localdomain> <56343345B145C043AE990701E3D1939501D56CF2@EXVS2.nrplc.localnet> Message-ID: <52454172.5070308@redhat.com> On 09/27/2013 09:31 AM, Innes, Duncan wrote: > > >> -----Original Message----- >> From: freeipa-users-bounces at redhat.com >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Sumit Bose >> Sent: 26 September 2013 17:36 >> To: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Force IPA to accept password? ... >> Which command did you use to change the password? 'passwd' or >> 'ipa passwd'? >> >> If you use 'passwd' the PAM stack on the client for the >> passwd command comes into play which typically has some >> modules like pam_pwquality.so listed which do checks >> including dictionary checks. >> >> If you use 'ipa passwd' the password should be only validated >> against the server-side password policy Martin mentioned above. > > Sumit, yes - I used 'passwd'. I'll look into using 'ipa passwd' in > about > 3 months time :-) Eh, ok :-) BTW, you could also standard kpasswd, it should also avoid modules like pam_pwquality.so and only use the server policy. Martin From Duncan.Innes at virginmoney.com Fri Sep 27 09:03:15 2013 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Fri, 27 Sep 2013 10:03:15 +0100 Subject: [Freeipa-users] Force IPA to accept password? In-Reply-To: <52454172.5070308@redhat.com> References: <523317DC.2050800@redhat.com><52370B3B.3000500@redhat.com> <523713D1.6050202@redhat.com><5243E9BF.3080009@redhat.com><56343345B145C043AE990701E3D1939501D56CEC@EXVS2.nrplc.localnet><524436AD.4040504@redhat.com><56343345B145C043AE990701E3D1939501D56CEF@EXVS2.nrplc.localnet> <20130926163533.GF10000@localhost.localdomain> <56343345B145C043AE990701E3D1939501D56CF2@EXVS2.nrplc.localnet> <52454172.5070308@redhat.com> Message-ID: <56343345B145C043AE990701E3D1939501D56CF5@EXVS2.nrplc.localnet> > From: Martin Kosek [mailto:mkosek at redhat.com] > Sent: 27 September 2013 09:28 > To: Innes, Duncan > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Force IPA to accept password? > > On 09/27/2013 09:31 AM, Innes, Duncan wrote: > > > > > >> From: freeipa-users-bounces at redhat.com > >> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Sumit Bose > >> Sent: 26 September 2013 17:36 > >> To: freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] Force IPA to accept password? > ... > >> Which command did you use to change the password? 'passwd' or 'ipa > >> passwd'? > >> > >> If you use 'passwd' the PAM stack on the client for the passwd > >> command comes into play which typically has some modules like > >> pam_pwquality.so listed which do checks including dictionary checks. > >> > >> If you use 'ipa passwd' the password should be only validated > >> against the server-side password policy Martin mentioned above. > > > > Sumit, yes - I used 'passwd'. I'll look into using 'ipa passwd' in > > about > > 3 months time :-) > > Eh, ok :-) BTW, you could also standard kpasswd, it should > also avoid modules like pam_pwquality.so and only use the > server policy. > > Martin > OK - this is opening my eyes somewhat. I know about the password policy section of IPA, but there doesn't appear to be anywhere to control the quality of the password. Is this done by PAM on the server? If it's not, how do I enforce things like ensuring at least 1 upper case, 1 lower case, 1 number and 1 special character? I don't see that in the docs. Would like to be able to ensure that the minimum password policy is centralised rather than perhaps having an erroneous strict policy on a few machines. Thanks Duncan This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Discovery House, Whiting Road, Norwich NR4 6EJ: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com From sbose at redhat.com Fri Sep 27 09:14:57 2013 From: sbose at redhat.com (Sumit Bose) Date: Fri, 27 Sep 2013 11:14:57 +0200 Subject: [Freeipa-users] Force IPA to accept password? In-Reply-To: <52454172.5070308@redhat.com> References: <52370B3B.3000500@redhat.com> <523713D1.6050202@redhat.com> <5243E9BF.3080009@redhat.com> <56343345B145C043AE990701E3D1939501D56CEC@EXVS2.nrplc.localnet> <524436AD.4040504@redhat.com> <56343345B145C043AE990701E3D1939501D56CEF@EXVS2.nrplc.localnet> <20130926163533.GF10000@localhost.localdomain> <56343345B145C043AE990701E3D1939501D56CF2@EXVS2.nrplc.localnet> <52454172.5070308@redhat.com> Message-ID: <20130927091457.GJ10000@localhost.localdomain> On Fri, Sep 27, 2013 at 10:27:30AM +0200, Martin Kosek wrote: > On 09/27/2013 09:31 AM, Innes, Duncan wrote: > > > > > >>-----Original Message----- > >>From: freeipa-users-bounces at redhat.com > >>[mailto:freeipa-users-bounces at redhat.com] On Behalf Of Sumit Bose > >>Sent: 26 September 2013 17:36 > >>To: freeipa-users at redhat.com > >>Subject: Re: [Freeipa-users] Force IPA to accept password? > ... > >>Which command did you use to change the password? 'passwd' or > >>'ipa passwd'? > >> > >>If you use 'passwd' the PAM stack on the client for the > >>passwd command comes into play which typically has some > >>modules like pam_pwquality.so listed which do checks > >>including dictionary checks. > >> > >>If you use 'ipa passwd' the password should be only validated > >>against the server-side password policy Martin mentioned above. > > > >Sumit, yes - I used 'passwd'. I'll look into using 'ipa passwd' in > >about > >3 months time :-) > > Eh, ok :-) BTW, you could also standard kpasswd, it should also > avoid modules like pam_pwquality.so and only use the server policy. Martin, pam_pwquality has an option called 'local_users_only'. According to bz849072 it should be set by default since F18 but it looks like it is not set in F19. Should we open a ticket to investigate it? bye, Sumit > > Martin > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From mkosek at redhat.com Fri Sep 27 09:16:47 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Sep 2013 11:16:47 +0200 Subject: [Freeipa-users] Force IPA to accept password? In-Reply-To: <56343345B145C043AE990701E3D1939501D56CF5@EXVS2.nrplc.localnet> References: <523317DC.2050800@redhat.com><52370B3B.3000500@redhat.com> <523713D1.6050202@redhat.com><5243E9BF.3080009@redhat.com><56343345B145C043AE990701E3D1939501D56CEC@EXVS2.nrplc.localnet><524436AD.4040504@redhat.com><56343345B145C043AE990701E3D1939501D56CEF@EXVS2.nrplc.localnet> <20130926163533.GF10000@localhost.localdomain> <56343345B145C043AE990701E3D1939501D56CF2@EXVS2.nrplc.localnet> <52454172.5070308@redhat.com> <56343345B145C043AE990701E3D1939501D56CF5@EXVS2.nrplc.localnet> Message-ID: <52454CFF.6070207@redhat.com> On 09/27/2013 11:03 AM, Innes, Duncan wrote: >> From: Martin Kosek [mailto:mkosek at redhat.com] >> Sent: 27 September 2013 09:28 >> To: Innes, Duncan >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Force IPA to accept password? >> >> On 09/27/2013 09:31 AM, Innes, Duncan wrote: >>> >>> >>>> From: freeipa-users-bounces at redhat.com >>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Sumit Bose >>>> Sent: 26 September 2013 17:36 >>>> To: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] Force IPA to accept password? >> ... >>>> Which command did you use to change the password? 'passwd' or 'ipa >>>> passwd'? >>>> >>>> If you use 'passwd' the PAM stack on the client for the passwd >>>> command comes into play which typically has some modules like >>>> pam_pwquality.so listed which do checks including dictionary > checks. >>>> >>>> If you use 'ipa passwd' the password should be only validated >>>> against the server-side password policy Martin mentioned above. >>> >>> Sumit, yes - I used 'passwd'. I'll look into using 'ipa passwd' in >>> about >>> 3 months time :-) >> >> Eh, ok :-) BTW, you could also standard kpasswd, it should >> also avoid modules like pam_pwquality.so and only use the >> server policy. >> >> Martin >> > > OK - this is opening my eyes somewhat. I know about the password policy > section of IPA, but there doesn't appear to be anywhere to control the > quality of the password. Is this done by PAM on the server? If it's > not, > how do I enforce things like ensuring at least 1 upper case, 1 lower > case, > 1 number and 1 special character? I don't see that in the docs. This should help: http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/user-pwdpolicy.html You can control character classes - if you set that for example to 3, password need to have at least: - one number, one lower-case char, one upper-case char OR - one number, one special char, one lower case char. You can also set minimal length. These 2 options should provide the settings you requested. Note that the policy is not related to PAM, it is required by an LDAP server plugin on FreeIPA server - so that it affect all possible password changes - like "ldapasswd", "passwd", "kpasswd" and others. > > Would like to be able to ensure that the minimum password policy is > centralised > rather than perhaps having an erroneous strict policy on a few machines. +1. You can set that centrally on server, you can even set different policies for different groups. It can just happen that pam_pwquality.so may interfere (as we found out) and add it's own password quality requirements on top of FreeIPA centralized ones. Martin From mkosek at redhat.com Fri Sep 27 09:28:12 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Sep 2013 11:28:12 +0200 Subject: [Freeipa-users] Force IPA to accept password? In-Reply-To: <20130927091457.GJ10000@localhost.localdomain> References: <52370B3B.3000500@redhat.com> <523713D1.6050202@redhat.com> <5243E9BF.3080009@redhat.com> <56343345B145C043AE990701E3D1939501D56CEC@EXVS2.nrplc.localnet> <524436AD.4040504@redhat.com> <56343345B145C043AE990701E3D1939501D56CEF@EXVS2.nrplc.localnet> <20130926163533.GF10000@localhost.localdomain> <56343345B145C043AE990701E3D1939501D56CF2@EXVS2.nrplc.localnet> <52454172.5070308@redhat.com> <20130927091457.GJ10000@localhost.localdomain> Message-ID: <52454FAC.1000302@redhat.com> On 09/27/2013 11:14 AM, Sumit Bose wrote: > On Fri, Sep 27, 2013 at 10:27:30AM +0200, Martin Kosek wrote: >> On 09/27/2013 09:31 AM, Innes, Duncan wrote: >>> >>> >>>> -----Original Message----- >>>> From: freeipa-users-bounces at redhat.com >>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Sumit Bose >>>> Sent: 26 September 2013 17:36 >>>> To: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] Force IPA to accept password? >> ... >>>> Which command did you use to change the password? 'passwd' or >>>> 'ipa passwd'? >>>> >>>> If you use 'passwd' the PAM stack on the client for the >>>> passwd command comes into play which typically has some >>>> modules like pam_pwquality.so listed which do checks >>>> including dictionary checks. >>>> >>>> If you use 'ipa passwd' the password should be only validated >>>> against the server-side password policy Martin mentioned above. >>> >>> Sumit, yes - I used 'passwd'. I'll look into using 'ipa passwd' in >>> about >>> 3 months time :-) >> >> Eh, ok :-) BTW, you could also standard kpasswd, it should also >> avoid modules like pam_pwquality.so and only use the server policy. > > Martin, pam_pwquality has an option called 'local_users_only'. According > to bz849072 it should be set by default since F18 but it looks like it > is not set in F19. Should we open a ticket to investigate it? > > bye, > Sumit Hmm, you are right. I found the original bug: https://bugzilla.redhat.com/show_bug.cgi?id=849072 ... and filed a new bug for Fedora 19 so that this can be fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1012854 Martin From Duncan.Innes at virginmoney.com Fri Sep 27 09:33:03 2013 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Fri, 27 Sep 2013 10:33:03 +0100 Subject: [Freeipa-users] Force IPA to accept password? In-Reply-To: <52454CFF.6070207@redhat.com> References: <523317DC.2050800@redhat.com><52370B3B.3000500@redhat.com> <523713D1.6050202@redhat.com><5243E9BF.3080009@redhat.com><56343345B145C043AE990701E3D1939501D56CEC@EXVS2.nrplc.localnet><524436AD.4040504@redhat.com><56343345B145C043AE990701E3D1939501D56CEF@EXVS2.nrplc.localnet> <20130926163533.GF10000@localhost.localdomain> <56343345B145C043AE990701E3D1939501D56CF2@EXVS2.nrplc.localnet> <52454172.5070308@redhat.com> <56343345B145C043AE990701E3D1939501D56CF5@EXVS2.nrplc.localnet> <52454CFF.6070207@redhat.com> Message-ID: <56343345B145C043AE990701E3D1939501D56CF8@EXVS2.nrplc.localnet> > -----Original Message----- > From: Martin Kosek [mailto:mkosek at redhat.com] > Sent: 27 September 2013 10:17 > To: Innes, Duncan > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Force IPA to accept password? > > On 09/27/2013 11:03 AM, Innes, Duncan wrote: > >> From: Martin Kosek [mailto:mkosek at redhat.com] > >> Sent: 27 September 2013 09:28 > >> To: Innes, Duncan > >> Cc: freeipa-users at redhat.com > >> Subject: Re: [Freeipa-users] Force IPA to accept password? > >> > >> On 09/27/2013 09:31 AM, Innes, Duncan wrote: > >>> > >>> > >>>> From: freeipa-users-bounces at redhat.com > >>>> [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Sumit Bose > >>>> Sent: 26 September 2013 17:36 > >>>> To: freeipa-users at redhat.com > >>>> Subject: Re: [Freeipa-users] Force IPA to accept password? > >> ... > >>>> Which command did you use to change the password? 'passwd' or 'ipa > >>>> passwd'? > >>>> > >>>> If you use 'passwd' the PAM stack on the client for the passwd > >>>> command comes into play which typically has some modules like > >>>> pam_pwquality.so listed which do checks including dictionary checks. > >>>> > >>>> If you use 'ipa passwd' the password should be only validated > >>>> against the server-side password policy Martin mentioned above. > >>> > >>> Sumit, yes - I used 'passwd'. I'll look into using 'ipa passwd' in > >>> about 3 months time :-) > >> > >> Eh, ok :-) BTW, you could also standard kpasswd, it should also avoid > >> modules like pam_pwquality.so and only use the server policy. > >> > >> Martin > >> > > > > OK - this is opening my eyes somewhat. I know about the password > > policy section of IPA, but there doesn't appear to be anywhere to > > control the quality of the password. Is this done by PAM on the > > server? If it's not, how do I enforce things like ensuring at least > > 1 upper case, 1 lower case, 1 number and 1 special character? I > > don't see that in the docs. > > This should help: > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/user-pw dpolicy.html > > You can control character classes - if you set that for > example to 3, password need to have at least: > - one number, one lower-case char, one upper-case char OR > - one number, one special char, one lower case char. > > You can also set minimal length. These 2 options should > provide the settings you requested. > > Note that the policy is not related to PAM, it is required by > an LDAP server plugin on FreeIPA server - so that it affect > all possible password changes - like "ldapasswd", "passwd", > "kpasswd" and others. > > > > > Would like to be able to ensure that the minimum password policy is > > centralised > > rather than perhaps having an erroneous strict policy on a > few machines. > > +1. You can set that centrally on server, you can even set > different policies > for different groups. It can just happen that > pam_pwquality.so may interfere > (as we found out) and add it's own password quality > requirements on top of > FreeIPA centralized ones. > > Martin > Brilliant. Thanks Martin. I either hadn't seen minclasses or had completely overlooked it. I'll just have to be careful about my local password policies I guess. Duncan This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Discovery House, Whiting Road, Norwich NR4 6EJ: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com From adrian.bradshaw at gmail.com Fri Sep 27 12:13:15 2013 From: adrian.bradshaw at gmail.com (Ade) Date: Fri, 27 Sep 2013 14:13:15 +0200 Subject: [Freeipa-users] Startup issue witrh dirsrv using slapi-nis Message-ID: Hi I have a dirsrv server using the slapi-nis plugin to provide 190+ nis maps. It works well apart from one issue - boot up If I do a reboot, the dirsrv starts up ok, but slapi-nis doesnt seem to register to rpc - logging in and restarting dirsrv fixes it I tried disabling dirsrv and putting a start into rc.local - exactly the same I tried disabling dirsrv and putting a start into rc.local with a sleep 120 first, and this works !! So it seems like it needs something to startup and settle first - any ideas? I can see that rpcbind starts before dirsrv. I even wrote a small script that waits for rpcinfo -p to return non zero before continuing to start dirsrv - didnt work From hazwan at cnc.net.my Fri Sep 27 07:56:24 2013 From: hazwan at cnc.net.my (hazwan) Date: Fri, 27 Sep 2013 15:56:24 +0800 (MYT) Subject: [Freeipa-users] ipa-replica-install command failed In-Reply-To: <575727794.19100.1380258366286.JavaMail.root@cnc.net.my> Message-ID: <1406731739.20963.1380268583972.JavaMail.root@cnc.net.my> hi, an update from previous mailing list https://www.redhat.com/archives/freeipa-users/2013-February/msg00440.html below is an 389-ds-base logs on the replica server [27/Sep/2013:15:30:59 +0800] - import userRoot: Processed 1567 entries -- average rate 78.3/sec, recent rate 78.3/sec, hit ratio 0% [27/Sep/2013:15:31:19 +0800] - import userRoot: Processed 1567 entries -- average rate 38.2/sec, recent rate 38.2/sec, hit ratio 0% [27/Sep/2013:15:31:39 +0800] - import userRoot: Processed 1567 entries -- average rate 25.7/sec, recent rate 0.0/sec, hit ratio 0% [27/Sep/2013:15:31:59 +0800] - import userRoot: Processed 1567 entries -- average rate 19.3/sec, recent rate 0.0/sec, hit ratio 0% [27/Sep/2013:15:32:19 +0800] - import userRoot: Processed 1567 entries -- average rate 15.5/sec, recent rate 0.0/sec, hit ratio 0% [27/Sep/2013:15:32:39 +0800] - import userRoot: Processed 1567 entries -- average rate 13.0/sec, recent rate 0.0/sec, hit ratio 0% [27/Sep/2013:15:32:44 +0800] - import userRoot: Workers finished; cleaning up... [27/Sep/2013:15:32:44 +0800] - import userRoot: Workers cleaned up. [27/Sep/2013:15:32:44 +0800] - import userRoot: Indexing complete. Post-processing... [27/Sep/2013:15:32:44 +0800] - import userRoot: Generating numSubordinates complete. [27/Sep/2013:15:32:44 +0800] - import userRoot: Flushing caches... [27/Sep/2013:15:32:44 +0800] - import userRoot: Closing files... [27/Sep/2013:15:32:45 +0800] - import userRoot: Import complete. Processed 1730 entries in 126 seconds. (13.73 entries/sec) [27/Sep/2013:15:32:45 +0800] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=doa,dc=gov,dc=my is coming online; enabling replication [27/Sep/2013:15:32:45 +0800] - Skipping CoS Definition cn=Password Policy,cn=accounts,dc=doa,dc=gov,dc=my--no CoS Templates found, which should be added before the CoS Definition. Privileged/confidential information may be contained in this message. If you are not the named recipient or addressee, you are hereby notified that any use review, disclosure or copying of the contents herein is strictly prohibited. In such a case, kindly discard all its contents and notify sender accordingly regarding such unauthorized disclosure or transmission by email. Opinions, conclusions, statements and other information in this message that do not relate to the official business of the Company shall be understood as neither given or endorsed by it. The contents herein are meant strictly for the use of the named recipient or addressee of the Company. No assumption of responsibility or liability whatsoever is undertaken by the Company in respect of prohibited and unauthorised use by any other person. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: errors Type: application/octet-stream Size: 37745 bytes Desc: not available URL: From mohan.cheema at arrkgroup.com Fri Sep 27 13:08:37 2013 From: mohan.cheema at arrkgroup.com (Mohan Cheema) Date: Fri, 27 Sep 2013 14:08:37 +0100 Subject: [Freeipa-users] FreeIPA Master Slave Setup Client Configuration In-Reply-To: <5245402F.9080407@redhat.com> References: <411001cebb3c$607c6500$21752f00$@cheema@arrkgroup.com> <5245402F.9080407@redhat.com> Message-ID: <448401cebb82$ae47b280$0ad71780$@cheema@arrkgroup.com> > -----Original Message----- > From: Martin Kosek [mailto:mkosek at redhat.com] > Sent: Friday, September 27, 2013 9:22 AM > To: Mohan Cheema > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] FreeIPA Master Slave Setup Client > Configuration > > On 09/27/2013 06:45 AM, Mohan Cheema wrote: > > Hi, > > > > We have setup FreeIPA within our environment the setup is master > slave. We want > > to know how we can configure clients to look to slave incase master > server is > > no available to authenticate the user. > > > > Regards, > > > > ** > > > > *Mohan Cheema* > > FreeIPA replicas are master-master replicas by default. Can you please > elaborate how did you create the slave server? > > About client configuration - can you use autodiscovery with DNS SRV > records? > (the same as IPA uses for autodiscovery). You would just need to create > DNS SRV > records for your slave server, with priority lower than the priority of > master > server. Client should then look at the slave only if the master is not > available. > > HTH, > Martin First installed the master server. Than we have used following command on it. ipa-replica-prepare kdc.domain.com Transferred it to second server and ran following command ipa-replica-install /var/lib/ipa/replica-info-kdc.domain.com Haven't really checked if I update the second master is updated. About client configuration I cannot use the DNS server as the hosting is on Amazon Web Service(AWS) and don't want to add another instance as we are tight budget. Cannot have DNS server on any of the server as this setup is for compliance. Regards, From mkosek at redhat.com Fri Sep 27 13:19:15 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Sep 2013 15:19:15 +0200 Subject: [Freeipa-users] FreeIPA Master Slave Setup Client Configuration In-Reply-To: <448401cebb82$ae47b280$0ad71780$@cheema@arrkgroup.com> References: <411001cebb3c$607c6500$21752f00$@cheema@arrkgroup.com> <5245402F.9080407@redhat.com> <448401cebb82$ae47b280$0ad71780$@cheema@arrkgroup.com> Message-ID: <524585D3.8050603@redhat.com> On 09/27/2013 03:08 PM, Mohan Cheema wrote: >> -----Original Message----- >> From: Martin Kosek [mailto:mkosek at redhat.com] >> Sent: Friday, September 27, 2013 9:22 AM >> To: Mohan Cheema >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] FreeIPA Master Slave Setup Client >> Configuration >> >> On 09/27/2013 06:45 AM, Mohan Cheema wrote: >>> Hi, >>> >>> We have setup FreeIPA within our environment the setup is master >> slave. We want >>> to know how we can configure clients to look to slave incase master >> server is >>> no available to authenticate the user. >>> >>> Regards, >>> >>> ** >>> >>> *Mohan Cheema* >> >> FreeIPA replicas are master-master replicas by default. Can you please >> elaborate how did you create the slave server? >> >> About client configuration - can you use autodiscovery with DNS SRV >> records? >> (the same as IPA uses for autodiscovery). You would just need to create >> DNS SRV >> records for your slave server, with priority lower than the priority of >> master >> server. Client should then look at the slave only if the master is not >> available. >> >> HTH, >> Martin > > > First installed the master server. Than we have used following command on > it. > > ipa-replica-prepare kdc.domain.com > > Transferred it to second server and ran following command > > ipa-replica-install /var/lib/ipa/replica-info-kdc.domain.com Ah, ok - this is standard master-master replication in FreeIPA. I.e. when you a modification in any of these servers, it is replicated to the other one too. > > Haven't really checked if I update the second master is updated. Is is. > > About client configuration I cannot use the DNS server as the hosting is on > Amazon Web Service(AWS) and don't want to add another instance as we are > tight budget. > Cannot have DNS server on any of the server as this setup is for compliance. > > Regards, Ok. If you are not using DNS, you could use a fixed list of IPA servers FQDNs when you are installing client. At least SSSD should use the first one as the primary point of contact and connect to the second one only if the first one is down. # ipa-client-install --server first.ipa.server --server second.ipa.server --domain ipa.server --fixed-primary Martin From chandank.kumar at gmail.com Fri Sep 27 17:58:36 2013 From: chandank.kumar at gmail.com (Chandan Kumar) Date: Fri, 27 Sep 2013 10:58:36 -0700 Subject: [Freeipa-users] Accessing IPA servers on no-standard port In-Reply-To: <52453668.8080103@redhat.com> References: <5244F2AD.8050603@redhat.com> <52453668.8080103@redhat.com> Message-ID: Ticket created : Ticket #3955 -- http://about.me/chandank On Fri, Sep 27, 2013 at 12:40 AM, Petr Spacek wrote: > On 27.9.2013 07:23, Chandan Kumar wrote: > >> Hi Rob, >> >> Thanks for the info. Sure I will create the ticket and will certainly try >> to pick the low-hanging fruit :-) >> >> >> -- >> http://about.me/chandank >> >> >> On Thu, Sep 26, 2013 at 7:51 PM, Rob Crittenden >> wrote: >> >> Chandan Kumar wrote: >>> >>> Hello, >>>> >>>> I have basic configuration question, my apologies if it has already been >>>> discussed. >>>> >>>> I have ipa-server-3 server installed with default parameters with >>>> replication. >>>> >>>> We have Linux machines across different geo location and I would like to >>>> integrate them into IPA server, however, I don't want external clients >>>> to connect the server on standard port. >>>> >>>> For example, during ipa-client registration it requires all IPA services >>>> to be running on default port. >>>> >>>> Such as : trying https://ipa01.my.net/ipa/xml >>>> >>>> kdc = ipa01.my.net:88 >>>> master_kdc = ipa01.my.net:88 >>>> admin_server = ipa01.my.net:749 >>>> >>>> >>>> Is there any way in ipa-client-install or sssd file to instruct IPA >>>> client to connect to IPA server on no-standard ports such as >>>> >>>> trying https://ipa01.my.net:8080/ipa/****xml >>>> >>>> > >>>> >>>> >>>> This way I don't have to allocate a separate IP or additional web server >>>> to redirect the requests a simple NAT at firewall will do such as >>>> external 8080 -> internal 443 >>>> >>>> >>> Currently there is no way to do this. I'd have sworn we had a ticket to >>> add this but a quick search didn't turn it up. If you'd like this >>> supported >>> feel free to open a ticket at https://fedorahosted.org/**** >>> freeipa/newticket < >>> https://**fedorahosted.org/freeipa/**newticket >>> > >>> >>> >>> I don't think this would be tremendously difficult to do, the trick would >>> be communicating the port to clients somehow while they are trying to >>> enroll. A command-line option would probably be the shortest path. >>> >>> This may be decent low-hanging fruit if you're interested in being a >>> contributor to IPA. >>> >> > Speaking specifically about Kerberos, LDAP and NTP - it should be possible > to change port number in SRV records in DNS and that is it. I'm not sure if > client libraries really support this, but you can try it. > > HTTP and HTTPS will be more problematic because there there are no SRV > records for them. > > -- > Petr^2 Spacek > > ______________________________**_________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/**mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbulist at gmail.com Fri Sep 27 20:26:35 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Fri, 27 Sep 2013 15:26:35 -0500 Subject: [Freeipa-users] Lock account Message-ID: <5245E9FB.5070505@gmail.com> Hi All, I would like to know if it is possible lock an user account after an inactive period of time. Thanks! From rcritten at redhat.com Fri Sep 27 20:53:48 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Sep 2013 16:53:48 -0400 Subject: [Freeipa-users] Lock account In-Reply-To: <5245E9FB.5070505@gmail.com> References: <5245E9FB.5070505@gmail.com> Message-ID: <5245F05C.4040600@redhat.com> cbulist at gmail.com wrote: > Hi All, > > I would like to know if it is possible lock an user account after an > inactive period of time. Not automatically, no. You'd need a cron job and an ldap query to find inactive users (across all IPA masters), then lock those you find. rob From cbulist at gmail.com Fri Sep 27 21:26:38 2013 From: cbulist at gmail.com (cbulist at gmail.com) Date: Fri, 27 Sep 2013 16:26:38 -0500 Subject: [Freeipa-users] Lock account In-Reply-To: <5245F05C.4040600@redhat.com> References: <5245E9FB.5070505@gmail.com> <5245F05C.4040600@redhat.com> Message-ID: <5245F80E.3060203@gmail.com> Thanks Rob your prompt reply and info! On 09/27/2013 03:53 PM, Rob Crittenden wrote: > cbulist at gmail.com wrote: >> Hi All, >> >> I would like to know if it is possible lock an user account after an >> inactive period of time. > Not automatically, no. You'd need a cron job and an ldap query to find > inactive users (across all IPA masters), then lock those you find. > > rob > From bwellsnc at gmail.com Fri Sep 27 23:56:24 2013 From: bwellsnc at gmail.com (bwellsnc) Date: Fri, 27 Sep 2013 19:56:24 -0400 Subject: [Freeipa-users] Connect OpenDirectory to FreeIPA Message-ID: I have a project that requires that I try to connect Apple OpenDirectory to FreeIPA. We have several macs on site and it would be easier to control access to theses using OpenDirectory vs FreeIPA. I want to use FreeIPA for all other systems, like Windows and Linux. Is there a way to connect OpenDirectory to FreeIPA or is there some schema changes to IPA to make it easier to manage Mac OSX. We are also currently using Jamf Casper to control packages and there are several ldap features that it needs. Any help would be appreciated. Thanks! Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From shelltoesuperstar at gmail.com Sat Sep 28 16:24:56 2013 From: shelltoesuperstar at gmail.com (Charlie Derwent) Date: Sat, 28 Sep 2013 17:24:56 +0100 Subject: [Freeipa-users] Automated Kickstart Enrollment In-Reply-To: <52260536.5070309@redhat.com> References: <56343345B145C043AE990701E3D1939501D56C0B@EXVS2.nrplc.localnet> <52260536.5070309@redhat.com> Message-ID: On Tue, Sep 3, 2013 at 4:50 PM, Dmitri Pal wrote: > On 09/03/2013 04:21 AM, Innes, Duncan wrote: > > Hi folks, > > I've got a question about kickstart enrollment with a one-time password. > Namely, is there any way that it can be done *without* the one-time > password. We're comfortable with the pre-creation of the host in IPA, > but just wonder if there's a way to enrol without the one-time password. > > The estate is Red Hat (mostly 6) and we deploy systems via kickstart from > the Satellite. Can the Satellite push out a certificate from the IPA > system that would allow client to enrol without the OTP? Our enrollment > script runs as part of the kickstart postinstall with the OTP effectively > sitting in plain text in the script. Removing the OTP would remove the > plain text authentication from this script, but I may be opening other > security holes as a result. > > Hello, > > > There have been 3 ways about how the host can be enrolled: > a) High level admin using his credential (no need to have a pre-created > host) > b) Lower level admin using his credential (requires a pre-created host) > c) OTP based (requires a pre-created host) > > All provisioning methods that use static kickstart files would have to > have something injected into the kickstart. OTP is the safest and if leaked > can be used to only provision this specific system. The fact that OTP was > stolen can be detected easily by having a failed enrollment of the valid > system combined with IPA logs indicating that there was a successful > enrollment of the new host with the same name. The fact that intruder was > able to join a machine into IPA domain does not escalate his privileges > against other systems and since it can be easily caught it is a risk but > not a huge one. > > The right approach of cause is not to have the OTP stored in kickstart but > rather parameterized in some way. In Satellite 6 (that we are looking at) > this will be done via Foreman and its smart proxies. The design is not > polished yet but we hope that we would be able to limit the exposure of the > OTPs there. > > Also a new provisioning method has been added in FreeIPA 3.2 mostly for > re-provisioning - ability to provision if you already have a keytab. > This method will be sort of equivalent to what you are asking with a cert. > But instead of the cert you would need to get keytab first by creating a > host and then using ipa-getkeytab command and passing keytab to the > kickstart. That can be done now and would address the issue you are > concerned about. > Hi Dimitri (or anyone who knows), Is there anyway except for waiting for RHEL 6.5 to get FreeIPA 3.2+ running in production? Really keen to get the re-provisioning functionality up and running but don't want to run it on Fedora. Also can you generate a keytab with ipa-getkeytab before you enrol a host, possibly when you add a host to the ipa-server for the first time? Or is the pattern provision with OTP first then backup keytab and provision with keytab after? Thanks, Charlie > > > HTH > > Thanks, > Dmitri > > Cheers > > Duncan Innes > > > This message has been checked for viruses and spam by the Virgin Money > email scanning system powered by Messagelabs. > > > > This e-mail is intended to be confidential to the recipient. If you > receive a copy in error, please inform the sender and then delete this > message. > > Virgin Money plc - Registered in England and Wales (Company no. 6952311). > Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. > Virgin Money plc is authorised by the Prudential Regulation Authority and > regulated by the Financial Conduct Authority and the Prudential Regulation > Authority. > > The following companies also trade as Virgin Money. They are both > authorised and regulated by the Financial Conduct Authority, are registered > in England and Wales and have their registered office at Discovery House, > Whiting Road, Norwich NR4 6EJ: Virgin Money Personal Financial Service > Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited > (Company no. 3000482). > > For further details of Virgin Money group companies please visit our > website at virginmoney.com > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Sun Sep 29 10:37:57 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 29 Sep 2013 12:37:57 +0200 Subject: [Freeipa-users] Connect OpenDirectory to FreeIPA In-Reply-To: References: Message-ID: <20130929103757.GA19290@hendrix.redhat.com> On Fri, Sep 27, 2013 at 07:56:24PM -0400, bwellsnc wrote: > I have a project that requires that I try to connect Apple OpenDirectory to > FreeIPA. We have several macs on site and it would be easier to control > access to theses using OpenDirectory vs FreeIPA. I want to use FreeIPA for > all other systems, like Windows and Linux. Is there a way to connect > OpenDirectory to FreeIPA or is there some schema changes to IPA to make it > easier to manage Mac OSX. We are also currently using Jamf Casper to > control packages and there are several ldap features that it needs. Any > help would be appreciated. Thanks! > > Brent Hi, I really don't have a complete solution but Alexander remembered something after you left #freeipa on Friday, so I'd thought I'll pass it on: 21:42 < bwellsnc> Apparently casper connects using an admin account and adds them. I will have to dig around the code to see 21:44 < bwellsnc> I have been looking over the open directory to openldap connections. Looks like there is custom schema that needs to be added to openldap to allow opendirectory to connect to that as well 22:00 < ab> jhrozek: https://wiki.uiowa.edu/download/attachments/23039229/Casper%20LDAP%20Presentation.pdf?version=1&modificationDate=1242940150453&api=v2 22:01 < ab> jhrozek: if he appears back after I go asleep 22:01 < ab> jhrozek: basically, Casper has way to map attributes I hope this helps. From jhrozek at redhat.com Sun Sep 29 11:09:07 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 29 Sep 2013 13:09:07 +0200 Subject: [Freeipa-users] access denied ssh In-Reply-To: References: <20130924100643.GW25628@localhost.localdomain> <20130924154828.GS20217@hendrix.redhat.com> Message-ID: <20130929110907.GD19290@hendrix.redhat.com> On Tue, Sep 24, 2013 at 09:38:49PM +0400, ?????? ? wrote: > ok, all sssd logs > > > 2013/9/24 Jakub Hrozek > > > On Tue, Sep 24, 2013 at 03:00:22PM +0400, ?????? ? wrote: > > > [sssd] > > > services = nss, pam, ssh > > > config_file_version = 2 > > > debug_level = 5 > > > domains = ipa.sys.local > > > > Please put the debug_level directive to the [domain] section and then > > attach /var/log/sssd/sssd_$domain.log It seems that the SSSD has trouble contacting the AD from the replica: Tue Sep 24 21:17:38 2013) [sssd[be[ipa.sys.local]]] [ad_resolve_callback] (0x0100): Constructed uri 'ldap://pk429ad-dc01.sys.local' (Tue Sep 24 21:17:38 2013) [sssd[be[ipa.sys.local]]] [ad_resolve_callback] (0x0100): Constructed GC uri 'ldap://pk429ad-dc01.sys.local' (Tue Sep 24 21:17:44 2013) [sssd[be[ipa.sys.local]]] [sdap_async_sys_connect_timeout] (0x0100): The LDAP connection timed out (Tue Sep 24 21:17:44 2013) [sssd[be[ipa.sys.local]]] [sss_ldap_init_sys_connect_done] (0x0020): sdap_async_sys_connect request failed. (Tue Sep 24 21:17:44 2013) [sssd[be[ipa.sys.local]]] [sdap_sys_connect_done] (0x0020): sdap_async_connect_call request failed. (Tue Sep 24 21:17:44 2013) [sssd[be[ipa.sys.local]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'pk429ad-dc01.sys.local' as 'not working' (Tue Sep 24 21:17:44 2013) [sssd[be[ipa.sys.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'sys.local' (Tue Sep 24 21:17:44 2013) [sssd[be[ipa.sys.local]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved Can you check the connectivity from the replica? From glenn.l.jenkins at smu.ac.uk Sun Sep 29 10:48:03 2013 From: glenn.l.jenkins at smu.ac.uk (Glenn Jenkins) Date: Sun, 29 Sep 2013 10:48:03 +0000 (UTC) Subject: [Freeipa-users] Fwd: FreeIPA on Fedora 19 won't work References: <53DB8A94-C71C-45D2-86AD-004F7A13AA59@monkey.org> <51BB7971.1080001@RedHat.com> <20130617133324.GA24492@redhat.com> Message-ID: Alexander Bokovoy writes: > > On Fri, 14 Jun 2013, Steve Dickson wrote: > >The $subject says it all... Any ideas what is going on here? > I did fresh install right now on a up to date F19 VM and experienced no > problem whatsoever. > > There were updates in pki-* and 389-ds-* packages over weekend. > > >2013-06-14T16:54:45Z DEBUG Starting external process > >2013-06-14T16:54:45Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpO2lDxI > >2013-06-14T16:54:51Z DEBUG Process finished, return code=1 > >2013-06-14T16:54:51Z DEBUG stdout=Loading deployment configuration from /tmp/tmpO2lDxI. > ^^^ The date corresponds to Friday last week, also there was issue with > metadata information in Fedora 19 and Rawhide repositories which > prevented proper packages propagating. > > Please try up to date packages from update-testing as of Monday. > I think this is similar to a bug I've seen reported elsewhere I believe the underlying cause may be the HTTP_PROXY and HTTPS_PROXY variables. If these are set then the ipa install script has problems locating the dogtag server and fails. The error I see in my install log is something along the lines of certificate server failed to restart. From the point of view of the running script the failure looks the same as that produced if the script is run twice. It should be easy to re-create this bug simply by setting HTTP_PROXY and HTTPS_PROXY on a test server and running the server install. Posts in other forums suggest re-installation solves the problem, I suggest this simply removes these variables. Could the install script check for them being set and unset-reset them or simply warn the user? G From mohan.cheema at arrkgroup.com Mon Sep 30 14:20:46 2013 From: mohan.cheema at arrkgroup.com (Mohan Cheema) Date: Mon, 30 Sep 2013 15:20:46 +0100 Subject: [Freeipa-users] krb5kdc Additional pre-authentication required Message-ID: <5d4a01cebde8$42833340$c78999c0$@cheema@arrkgroup.com> Hi, We are trying to authenticate from Windows machine and getting below error. -------------------- Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 10.43.2.45: NEEDED_PREAUTH: user at DOMAIN.COM for krbtgt/DOMAIN.COM at DOMAIN.COM, Additional pre-authentication required Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 10.43.2.45: ISSUE: authtime 1380550054, etypes {rep=18 tkt=18 ses=18}, user at DOMAIN.COM for krbtgt/DOMAIN.COM at DOMAIN.COM Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): TGS_REQ (7 etypes {18 17 23 3 1 24 -135}) 10.43.2.45: ISSUE: authtime 1380550054, etypes {rep=18 tkt=23 ses=23}, user at DOMAIN.COM for host/av.domain.com at DOMAIN.COM -------------------- We followed the instruction to integrate windows for authentication. Windows Client: Windows server 2008 R2 We are not able to figure out what the problem is. We are not using DNS server, instead we are using host file entries. DNS server setup is not an option for us right now. Same user can authenticate from Linux machine. Regards, Mohan Cheema -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Mon Sep 30 14:46:59 2013 From: sbose at redhat.com (Sumit Bose) Date: Mon, 30 Sep 2013 16:46:59 +0200 Subject: [Freeipa-users] krb5kdc Additional pre-authentication required In-Reply-To: <5d4a01cebde8$42833340$c78999c0$@cheema@arrkgroup.com> References: <5d4a01cebde8$42833340$c78999c0$@cheema@arrkgroup.com> Message-ID: <20130930144659.GR10000@localhost.localdomain> On Mon, Sep 30, 2013 at 03:20:46PM +0100, Mohan Cheema wrote: > Hi, > > > > We are trying to authenticate from Windows machine and getting below error. > > > > -------------------- > Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): AS_REQ (7 etypes {18 > 17 23 3 1 24 -135}) 10.43.2.45: NEEDED_PREAUTH: user at DOMAIN.COM for > krbtgt/DOMAIN.COM at DOMAIN.COM, Additional pre-authentication required This is expected behaviour. The client will first send the AS-REQ without any pre-authentication data. If the server requires pre-authentication for this principal it will return this error to the client to indicate that pre-authentication is expected. > > Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): AS_REQ (7 etypes {18 > 17 23 3 1 24 -135}) 10.43.2.45: ISSUE: authtime 1380550054, etypes {rep=18 > tkt=18 ses=18}, user at DOMAIN.COM for krbtgt/DOMAIN.COM at DOMAIN.COM In the second AS-REQ the client has included some pre-authentication data which is accepted by the KDC and a ticket is issued to the client. HTH bye, Sumit > > Sep 30 14:07:34 kdc1.domain.com krb5kdc[10105](info): TGS_REQ (7 etypes {18 > 17 23 3 1 24 -135}) 10.43.2.45: ISSUE: authtime 1380550054, etypes {rep=18 > tkt=23 ses=23}, user at DOMAIN.COM for host/av.domain.com at DOMAIN.COM > -------------------- > > > > We followed the instruction to integrate windows for authentication. > > > > Windows Client: Windows server 2008 R2 > > > > We are not able to figure out what the problem is. > > > > We are not using DNS server, instead we are using host file entries. DNS > server setup is not an option for us right now. > > > > Same user can authenticate from Linux machine. > > > > Regards, > > > > Mohan Cheema > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From Duncan.Innes at virginmoney.com Mon Sep 30 16:17:02 2013 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Mon, 30 Sep 2013 17:17:02 +0100 Subject: [Freeipa-users] SUDOers config with cleartext password? In-Reply-To: <5d4a01cebde8$42833340$c78999c0$@cheema@arrkgroup.com> References: <5d4a01cebde8$42833340$c78999c0$@cheema@arrkgroup.com> Message-ID: <56343345B145C043AE990701E3D1939501D56D15@EXVS2.nrplc.localnet> Hi folks, Just wondering if it's really the case that I have to use a cleartext bindpw in my /etc/sudo-ldap.conf file in order to get sudoers looking at my FreeIPA servers? It's the first time I've looked into this side of things in FreeIPA and it just seems a bit more clunky than other areas in my mind. Thanks Duncan This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Discovery House, Whiting Road, Norwich NR4 6EJ: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com From abokovoy at redhat.com Mon Sep 30 16:25:44 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 30 Sep 2013 19:25:44 +0300 Subject: [Freeipa-users] SUDOers config with cleartext password? In-Reply-To: <56343345B145C043AE990701E3D1939501D56D15@EXVS2.nrplc.localnet> References: <5d4a01cebde8$42833340$c78999c0$@cheema@arrkgroup.com> <56343345B145C043AE990701E3D1939501D56D15@EXVS2.nrplc.localnet> Message-ID: <20130930162544.GM4216@redhat.com> On Mon, 30 Sep 2013, Innes, Duncan wrote: >Hi folks, > >Just wondering if it's really the case that I have to use a cleartext >bindpw in my /etc/sudo-ldap.conf file in order to get sudoers looking at >my FreeIPA servers? > >It's the first time I've looked into this side of things in FreeIPA and >it just seems a bit more clunky than other areas in my mind. If you have Fedora 18+ or RHEL 6.4+, you simply follow this recipe: https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html and everything should work without exposing anything in clear text. -- / Alexander Bokovoy From Duncan.Innes at virginmoney.com Mon Sep 30 16:27:06 2013 From: Duncan.Innes at virginmoney.com (Innes, Duncan) Date: Mon, 30 Sep 2013 17:27:06 +0100 Subject: [Freeipa-users] SUDOers config with cleartext password? In-Reply-To: <20130930162544.GM4216@redhat.com> References: <5d4a01cebde8$42833340$c78999c0$@cheema@arrkgroup.com> <56343345B145C043AE990701E3D1939501D56D15@EXVS2.nrplc.localnet> <20130930162544.GM4216@redhat.com> Message-ID: <56343345B145C043AE990701E3D1939501D56D16@EXVS2.nrplc.localnet> Thanks, I'll try and speed up my migration to RHEL 6.4 then :) Duncan > -----Original Message----- > From: Alexander Bokovoy [mailto:abokovoy at redhat.com] > Sent: 30 September 2013 17:26 > To: Innes, Duncan > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] SUDOers config with cleartext password? > > On Mon, 30 Sep 2013, Innes, Duncan wrote: > >Hi folks, > > > >Just wondering if it's really the case that I have to use a > cleartext > >bindpw in my /etc/sudo-ldap.conf file in order to get > sudoers looking > >at my FreeIPA servers? > > > >It's the first time I've looked into this side of things in > FreeIPA and > >it just seems a bit more clunky than other areas in my mind. > If you have Fedora 18+ or RHEL 6.4+, you simply follow this recipe: > https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html > and everything should work without exposing anything in clear text. > > -- > / Alexander Bokovoy > > This message has been checked for viruses and spam by the > Virgin Money email scanning system powered by Messagelabs. > This message has been checked for viruses and spam by the Virgin Money email scanning system powered by Messagelabs. This e-mail is intended to be confidential to the recipient. If you receive a copy in error, please inform the sender and then delete this message. Virgin Money plc - Registered in England and Wales (Company no. 6952311). Registered office - Jubilee House, Gosforth, Newcastle upon Tyne NE3 4PL. Virgin Money plc is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. The following companies also trade as Virgin Money. They are both authorised and regulated by the Financial Conduct Authority, are registered in England and Wales and have their registered office at Discovery House, Whiting Road, Norwich NR4 6EJ: Virgin Money Personal Financial Service Limited (Company no. 3072766) and Virgin Money Unit Trust Managers Limited (Company no. 3000482). For further details of Virgin Money group companies please visit our website at virginmoney.com From andrew.tranquada at rackspace.com Mon Sep 30 16:41:50 2013 From: andrew.tranquada at rackspace.com (Andrew Tranquada) Date: Mon, 30 Sep 2013 12:41:50 -0400 (EDT) Subject: [Freeipa-users] Server randomly will stop accepting krb requests Message-ID: <1380559310.48899402@beta.apps.rackspace.com> I have 6 servers setup as freeipa replicas. 5 are working great, no problems. They are all running ipa-server-3.0.0-26.el6_4.4.x86_64 However, the same one will randomly stop working. By stop working I mean the following: (domain name and ips have been redacted) I cannot kinit as any user on that machine: [root at badserver ~]# kinit admin kinit: Generic error (see e-text) while getting initial credentials I cannot connect on 389 or 636 to that server: telnet badserver 636 telnet: Unable to connect to remote host: Connection refused slapd is running and listening on port 389 according to netstat: [root at badserver ~]# netstat -lpn | grep 389 tcp 0 0 :::7389 :::* LISTEN 16419/ns-slapd but nothing is returned for port 636 in the /var/log/slapd-PKI* or slapd- error files, the last error is from over a week ago, actually the last entry period is from there. [18/Sep/2013:01:09:34 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: PROCESS_TGS)) errno 2 (No such file or directory) /var/log/krb5kdc.log shows Sep 30 12:22:24 badserver krb5kdc[32063](info): AS_REQ (4 etypes {18 17 16 23}) : LOOKING_UP_CLIENT: admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Server error a service ipa restart ALWAYS fixes it. I added debug=true to /etc/ipa/default.conf but I do not see anything that is helpful. The only things listed in default.conf are things related to "importing plugin module" Any guidance/advice/docs to read would be greatly appreciated! The fact that it seems to be so random and the other 5 ipa servers are working great makes it even more frustrating! Thanks! From abokovoy at redhat.com Mon Sep 30 16:47:32 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 30 Sep 2013 19:47:32 +0300 Subject: [Freeipa-users] Server randomly will stop accepting krb requests In-Reply-To: <1380559310.48899402@beta.apps.rackspace.com> References: <1380559310.48899402@beta.apps.rackspace.com> Message-ID: <20130930164732.GN4216@redhat.com> On Mon, 30 Sep 2013, Andrew Tranquada wrote: >I have 6 servers setup as freeipa replicas. >5 are working great, no problems. >They are all running ipa-server-3.0.0-26.el6_4.4.x86_64 >However, the same one will randomly stop working. By stop working I mean the following: >(domain name and ips have been redacted) > >I cannot kinit as any user on that machine: >[root at badserver ~]# kinit admin >kinit: Generic error (see e-text) while getting initial credentials > >I cannot connect on 389 or 636 to that server: > > telnet badserver 636 > >telnet: Unable to connect to remote host: Connection refused > >slapd is running and listening on port 389 according to netstat: >[root at badserver ~]# netstat -lpn | grep 389 >tcp 0 0 :::7389 :::* LISTEN 16419/ns-slapd This is port 7389, for CA LDAP instance, not port 389 which is main LDAP instance. >but nothing is returned for port 636 Because port 636 is served by the same main dirsrv instance that is down. > >in the /var/log/slapd-PKI* or slapd- error files, the last error is from over a week ago, actually the last entry period is from there. > >[18/Sep/2013:01:09:34 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: PROCESS_TGS)) errno 2 (No such file or directory) > > >/var/log/krb5kdc.log shows >Sep 30 12:22:24 badserver krb5kdc[32063](info): AS_REQ (4 etypes {18 17 16 23}) : LOOKING_UP_CLIENT: admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Server error > >a service ipa restart ALWAYS fixes it. Directory server instance is down, so LDAP server is not accessible, so Kerberos KDC cannot read the data which is only in LDAP, so it denies access. >Any guidance/advice/docs to read would be greatly appreciated! The fact >that it seems to be so random and the other 5 ipa servers are working >great makes it even more frustrating! Look at directory server's logs to see what was the reason for refusing starting up in /var/log/dirsrv/slapd-/errors. -- / Alexander Bokovoy From andrew.tranquada at rackspace.com Mon Sep 30 16:52:33 2013 From: andrew.tranquada at rackspace.com (Andrew Tranquada) Date: Mon, 30 Sep 2013 12:52:33 -0400 (EDT) Subject: [Freeipa-users] Server randomly will stop accepting krb requests In-Reply-To: <20130930164732.GN4216@redhat.com> References: <1380559310.48899402@beta.apps.rackspace.com> <20130930164732.GN4216@redhat.com> Message-ID: <1380559953.075127519@beta.apps.rackspace.com> Thanks for the response I did look in /var/log/slapd-PKI* or slapd- (I guess I was not too clear I did that in my email) in those logs the last thing in that log is from Sep 18 >From /var/log/dirsrv/slapd-EXAMPLE-COM/errors: [18/Sep/2013:01:09:34 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: PROCESS_TGS)) errno 2 (No such file or directory) That is all, the items before that time are addition/deletion of entries which is normal. -----Original Message----- From: "Alexander Bokovoy" Sent: Monday, September 30, 2013 12:47pm To: "Andrew Tranquada" Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Server randomly will stop accepting krb requests On Mon, 30 Sep 2013, Andrew Tranquada wrote: >I have 6 servers setup as freeipa replicas. >5 are working great, no problems. >They are all running ipa-server-3.0.0-26.el6_4.4.x86_64 >However, the same one will randomly stop working. By stop working I mean the following: >(domain name and ips have been redacted) > >I cannot kinit as any user on that machine: >[root at badserver ~]# kinit admin >kinit: Generic error (see e-text) while getting initial credentials > >I cannot connect on 389 or 636 to that server: > > telnet badserver 636 > >telnet: Unable to connect to remote host: Connection refused > >slapd is running and listening on port 389 according to netstat: >[root at badserver ~]# netstat -lpn | grep 389 >tcp 0 0 :::7389 :::* LISTEN 16419/ns-slapd This is port 7389, for CA LDAP instance, not port 389 which is main LDAP instance. >but nothing is returned for port 636 Because port 636 is served by the same main dirsrv instance that is down. > >in the /var/log/slapd-PKI* or slapd- error files, the last error is from over a week ago, actually the last entry period is from there. > >[18/Sep/2013:01:09:34 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: PROCESS_TGS)) errno 2 (No such file or directory) > > >/var/log/krb5kdc.log shows >Sep 30 12:22:24 badserver krb5kdc[32063](info): AS_REQ (4 etypes {18 17 16 23}) : LOOKING_UP_CLIENT: admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Server error > >a service ipa restart ALWAYS fixes it. Directory server instance is down, so LDAP server is not accessible, so Kerberos KDC cannot read the data which is only in LDAP, so it denies access. >Any guidance/advice/docs to read would be greatly appreciated! The fact >that it seems to be so random and the other 5 ipa servers are working >great makes it even more frustrating! Look at directory server's logs to see what was the reason for refusing starting up in /var/log/dirsrv/slapd-/errors. -- / Alexander Bokovoy From rcritten at redhat.com Mon Sep 30 17:13:44 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Sep 2013 13:13:44 -0400 Subject: [Freeipa-users] Server randomly will stop accepting krb requests In-Reply-To: <1380559953.075127519@beta.apps.rackspace.com> References: <1380559310.48899402@beta.apps.rackspace.com> <20130930164732.GN4216@redhat.com> <1380559953.075127519@beta.apps.rackspace.com> Message-ID: <5249B148.3040009@redhat.com> Andrew Tranquada wrote: > Thanks for the response > I did look in /var/log/slapd-PKI* or slapd- (I guess I was not too clear I did that in my email) > in those logs the last thing in that log is from Sep 18 > >>From /var/log/dirsrv/slapd-EXAMPLE-COM/errors: > > [18/Sep/2013:01:09:34 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: PROCESS_TGS)) errno 2 (No such file or directory) > > That is all, the items before that time are addition/deletion of entries which is normal. > > -----Original Message----- > From: "Alexander Bokovoy" > Sent: Monday, September 30, 2013 12:47pm > To: "Andrew Tranquada" > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Server randomly will stop accepting krb requests > > On Mon, 30 Sep 2013, Andrew Tranquada wrote: >> I have 6 servers setup as freeipa replicas. >> 5 are working great, no problems. >> They are all running ipa-server-3.0.0-26.el6_4.4.x86_64 >> However, the same one will randomly stop working. By stop working I mean the following: >> (domain name and ips have been redacted) >> >> I cannot kinit as any user on that machine: >> [root at badserver ~]# kinit admin >> kinit: Generic error (see e-text) while getting initial credentials >> >> I cannot connect on 389 or 636 to that server: >> >> telnet badserver 636 >> >> telnet: Unable to connect to remote host: Connection refused >> >> slapd is running and listening on port 389 according to netstat: >> [root at badserver ~]# netstat -lpn | grep 389 >> tcp 0 0 :::7389 :::* LISTEN 16419/ns-slapd > This is port 7389, for CA LDAP instance, not port 389 which is main LDAP > instance. > >> but nothing is returned for port 636 > Because port 636 is served by the same main dirsrv instance that is > down. > >> >> in the /var/log/slapd-PKI* or slapd- error files, the last error is from over a week ago, actually the last entry period is from there. >> >> [18/Sep/2013:01:09:34 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: PROCESS_TGS)) errno 2 (No such file or directory) >> >> >> /var/log/krb5kdc.log shows >> Sep 30 12:22:24 badserver krb5kdc[32063](info): AS_REQ (4 etypes {18 17 16 23}) : LOOKING_UP_CLIENT: admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Server error >> >> a service ipa restart ALWAYS fixes it. > Directory server instance is down, so LDAP server is not accessible, so > Kerberos KDC cannot read the data which is only in LDAP, so it denies > access. > >> Any guidance/advice/docs to read would be greatly appreciated! The fact >> that it seems to be so random and the other 5 ipa servers are working >> great makes it even more frustrating! > Look at directory server's logs to see what was the reason for refusing > starting up in /var/log/dirsrv/slapd-/errors. I'd look for evidence in /var/log/messages of ns-slapd core dumping. rob From abokovoy at redhat.com Mon Sep 30 17:19:49 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 30 Sep 2013 20:19:49 +0300 Subject: [Freeipa-users] Server randomly will stop accepting krb requests In-Reply-To: <1380559953.075127519@beta.apps.rackspace.com> References: <1380559310.48899402@beta.apps.rackspace.com> <20130930164732.GN4216@redhat.com> <1380559953.075127519@beta.apps.rackspace.com> Message-ID: <20130930171949.GO4216@redhat.com> On Mon, 30 Sep 2013, Andrew Tranquada wrote: >Thanks for the response >I did look in /var/log/slapd-PKI* or slapd- (I guess I was not >too clear I did that in my email) in those logs the last thing in that >log is from Sep 18 > >From /var/log/dirsrv/slapd-EXAMPLE-COM/errors: > >[18/Sep/2013:01:09:34 -0400] slapd_ldap_sasl_interactive_bind - Error: >could not perform interactive bind for id [] mech [GSSAPI]: LDAP error >-2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified >GSS failure. Minor code may provide more information (KDC returned >error string: PROCESS_TGS)) errno 2 (No such file or directory) > >That is all, the items before that time are addition/deletion of >entries which is normal. 'PROCESS_TGS' error message most likely means that ns-slapd failed to serve a query from KDC's database driver and disappeared, thus breaking unix domain socket that the driver was using to communicate with ns-slapd (we see it with 'errno 2 (No such file or directory)' error message). As Rob said, there should be ns-slapd core somewhere that should tell where it crashed. -- / Alexander Bokovoy From andrew.tranquada at rackspace.com Mon Sep 30 17:27:42 2013 From: andrew.tranquada at rackspace.com (Andrew Tranquada) Date: Mon, 30 Sep 2013 13:27:42 -0400 (EDT) Subject: [Freeipa-users] Server randomly will stop accepting krb requests In-Reply-To: <5249B148.3040009@redhat.com> References: <1380559310.48899402@beta.apps.rackspace.com> <20130930164732.GN4216@redhat.com> <1380559953.075127519@beta.apps.rackspace.com> <5249B148.3040009@redhat.com> Message-ID: <1380562062.275210071@beta.apps.rackspace.com> Well I feel silly for not checking this earlier. You were correct. Sep 18 01:09:35 freeipa1 kernel: : ns-slapd[16553]: segfault at 4 ip 000000000041227a sp 00007fb9d15edc68 error 4 in ns-slapd[400000+53000] I am installing the 389-ds-base-debuginfo and accompanying packages now, restarting ipa, enabling core dumps in the kernel and changing core file size to unlimited. Will see what happens next! Thanks! -----Original Message----- From: "Rob Crittenden" Sent: Monday, September 30, 2013 1:13pm To: "Andrew Tranquada" , "Alexander Bokovoy" Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Server randomly will stop accepting krb requests Andrew Tranquada wrote: > Thanks for the response > I did look in /var/log/slapd-PKI* or slapd- (I guess I was not too clear I did that in my email) > in those logs the last thing in that log is from Sep 18 > >>From /var/log/dirsrv/slapd-EXAMPLE-COM/errors: > > [18/Sep/2013:01:09:34 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: PROCESS_TGS)) errno 2 (No such file or directory) > > That is all, the items before that time are addition/deletion of entries which is normal. > > -----Original Message----- > From: "Alexander Bokovoy" > Sent: Monday, September 30, 2013 12:47pm > To: "Andrew Tranquada" > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Server randomly will stop accepting krb requests > > On Mon, 30 Sep 2013, Andrew Tranquada wrote: >> I have 6 servers setup as freeipa replicas. >> 5 are working great, no problems. >> They are all running ipa-server-3.0.0-26.el6_4.4.x86_64 >> However, the same one will randomly stop working. By stop working I mean the following: >> (domain name and ips have been redacted) >> >> I cannot kinit as any user on that machine: >> [root at badserver ~]# kinit admin >> kinit: Generic error (see e-text) while getting initial credentials >> >> I cannot connect on 389 or 636 to that server: >> >> telnet badserver 636 >> >> telnet: Unable to connect to remote host: Connection refused >> >> slapd is running and listening on port 389 according to netstat: >> [root at badserver ~]# netstat -lpn | grep 389 >> tcp 0 0 :::7389 :::* LISTEN 16419/ns-slapd > This is port 7389, for CA LDAP instance, not port 389 which is main LDAP > instance. > >> but nothing is returned for port 636 > Because port 636 is served by the same main dirsrv instance that is > down. > >> >> in the /var/log/slapd-PKI* or slapd- error files, the last error is from over a week ago, actually the last entry period is from there. >> >> [18/Sep/2013:01:09:34 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: PROCESS_TGS)) errno 2 (No such file or directory) >> >> >> /var/log/krb5kdc.log shows >> Sep 30 12:22:24 badserver krb5kdc[32063](info): AS_REQ (4 etypes {18 17 16 23}) : LOOKING_UP_CLIENT: admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Server error >> >> a service ipa restart ALWAYS fixes it. > Directory server instance is down, so LDAP server is not accessible, so > Kerberos KDC cannot read the data which is only in LDAP, so it denies > access. > >> Any guidance/advice/docs to read would be greatly appreciated! The fact >> that it seems to be so random and the other 5 ipa servers are working >> great makes it even more frustrating! > Look at directory server's logs to see what was the reason for refusing > starting up in /var/log/dirsrv/slapd-/errors. I'd look for evidence in /var/log/messages of ns-slapd core dumping. rob From rmeggins at redhat.com Mon Sep 30 18:21:48 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 30 Sep 2013 12:21:48 -0600 Subject: [Freeipa-users] Server randomly will stop accepting krb requests In-Reply-To: <1380562062.275210071@beta.apps.rackspace.com> References: <1380559310.48899402@beta.apps.rackspace.com> <20130930164732.GN4216@redhat.com> <1380559953.075127519@beta.apps.rackspace.com> <5249B148.3040009@redhat.com> <1380562062.275210071@beta.apps.rackspace.com> Message-ID: <5249C13C.7020108@redhat.com> On 09/30/2013 11:27 AM, Andrew Tranquada wrote: > Well I feel silly for not checking this earlier. You were correct. > Sep 18 01:09:35 freeipa1 kernel: : ns-slapd[16553]: segfault at 4 ip 000000000041227a sp 00007fb9d15edc68 error 4 in ns-slapd[400000+53000] > I am installing the 389-ds-base-debuginfo and accompanying packages now, restarting ipa, enabling core dumps in the kernel and changing core file size to unlimited. http://port389.org/wiki/FAQ#Debugging_Crashes > > Will see what happens next! Thanks! > > > -----Original Message----- > From: "Rob Crittenden" > Sent: Monday, September 30, 2013 1:13pm > To: "Andrew Tranquada" , "Alexander Bokovoy" > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Server randomly will stop accepting krb requests > > Andrew Tranquada wrote: >> Thanks for the response >> I did look in /var/log/slapd-PKI* or slapd- (I guess I was not too clear I did that in my email) >> in those logs the last thing in that log is from Sep 18 >> >> >From /var/log/dirsrv/slapd-EXAMPLE-COM/errors: >> >> [18/Sep/2013:01:09:34 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: PROCESS_TGS)) errno 2 (No such file or directory) >> >> That is all, the items before that time are addition/deletion of entries which is normal. >> >> -----Original Message----- >> From: "Alexander Bokovoy" >> Sent: Monday, September 30, 2013 12:47pm >> To: "Andrew Tranquada" >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Server randomly will stop accepting krb requests >> >> On Mon, 30 Sep 2013, Andrew Tranquada wrote: >>> I have 6 servers setup as freeipa replicas. >>> 5 are working great, no problems. >>> They are all running ipa-server-3.0.0-26.el6_4.4.x86_64 >>> However, the same one will randomly stop working. By stop working I mean the following: >>> (domain name and ips have been redacted) >>> >>> I cannot kinit as any user on that machine: >>> [root at badserver ~]# kinit admin >>> kinit: Generic error (see e-text) while getting initial credentials >>> >>> I cannot connect on 389 or 636 to that server: >>> >>> telnet badserver 636 >>> >>> telnet: Unable to connect to remote host: Connection refused >>> >>> slapd is running and listening on port 389 according to netstat: >>> [root at badserver ~]# netstat -lpn | grep 389 >>> tcp 0 0 :::7389 :::* LISTEN 16419/ns-slapd >> This is port 7389, for CA LDAP instance, not port 389 which is main LDAP >> instance. >> >>> but nothing is returned for port 636 >> Because port 636 is served by the same main dirsrv instance that is >> down. >> >>> in the /var/log/slapd-PKI* or slapd- error files, the last error is from over a week ago, actually the last entry period is from there. >>> >>> [18/Sep/2013:01:09:34 -0400] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: PROCESS_TGS)) errno 2 (No such file or directory) >>> >>> >>> /var/log/krb5kdc.log shows >>> Sep 30 12:22:24 badserver krb5kdc[32063](info): AS_REQ (4 etypes {18 17 16 23}) : LOOKING_UP_CLIENT: admin at EXAMPLE.COM for krbtgt/EXAMPLE.COM at EXAMPLE.COM, Server error >>> >>> a service ipa restart ALWAYS fixes it. >> Directory server instance is down, so LDAP server is not accessible, so >> Kerberos KDC cannot read the data which is only in LDAP, so it denies >> access. >> >>> Any guidance/advice/docs to read would be greatly appreciated! The fact >>> that it seems to be so random and the other 5 ipa servers are working >>> great makes it even more frustrating! >> Look at directory server's logs to see what was the reason for refusing >> starting up in /var/log/dirsrv/slapd-/errors. > I'd look for evidence in /var/log/messages of ns-slapd core dumping. > > rob > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users