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-devel] [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-devel] [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-devel] [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-devel] [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 jpazdziora at redhat.com Mon Sep 2 06:31:54 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 2 Sep 2013 14:31:54 +0800 Subject: [Freeipa-devel] IPA Server UI Behind Proxy In-Reply-To: <520CE569.2000301@redhat.com> References: <520B338A.2070605@redhat.com> <20130815140231.GE4714@redhat.com> <520CE569.2000301@redhat.com> Message-ID: <20130902063154.GH7216@redhat.com> On Thu, Aug 15, 2013 at 04:27:53PM +0200, Petr Viktorin wrote: > > >Alternatively, how essential is this requirement for the referer > >header -- couldn't it be dropped, maybe via some config option? > > Without it, a malicious link/button on any webpage (or e-mail) could > do any action in IPA, if clicked by a logged-in admin. Could we change the CSRF protection method from the Referrer check to some user session specific token? -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From jpazdziora at redhat.com Mon Sep 2 07:42:32 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 2 Sep 2013 15:42:32 +0800 Subject: [Freeipa-devel] [PATCH] 448 Load updated Web UI files after server upgrade In-Reply-To: <5220B880.9040902@redhat.com> References: <5220B880.9040902@redhat.com> Message-ID: <20130902074232.GN7216@redhat.com> On Fri, Aug 30, 2013 at 05:21:36PM +0200, Petr Vobornik wrote: > > Solution: > * Implemented a mini loader which loads basic resources. Dojo loader > takes action after Dojo is loaded. > * The loader adds a version parameter (?v=__NUM_VERSION__) to all requests. > * Version is defined in the loader. It's set to current in `make > version-update`. > * All static pages use this loader to fetch their resources. Couldn't you make this a build time thing, marking the links with the version with make? Alternatively, you could mark them with the hash of the target, in which case if the target did not change with upgrade, the hash would stay the same and the browser would not need to reload it. -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From pspacek at redhat.com Mon Sep 2 08:49:58 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 02 Sep 2013 10:49:58 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <52161568.7060702@redhat.com> References: <52161568.7060702@redhat.com> Message-ID: <52245136.1090804@redhat.com> On 22.8.2013 15:43, Jan Cholasta wrote: > Hi, > > I'm currently investigating support for multiple CA certificates in LDAP > (, > ). This will be useful for CA > certificate renewal (, > ) and using certificates issued > by custom CAs for IPA HTTP and directory server instances > (). > > The biggest issue is how to make IPA clients aware of CA certificate changes. > One of the tickets suggests polling the LDAP server from SSSD. Would that be > sufficient? Perhaps a combination of polling and detecting certificate changes > when connecting to LDAP would be better? > > Another issue is how to handle updating IPA systems with new CA > certificate(s). On clients it is probably sufficient to store the > certificate(s) in /etc/ipa/ca.crt, but on servers there are multiple places > where the update needs to be done (HTTP and directory server NSS databases, > KDC pkinit_anchors file, etc.). IMO doing all this from SSSD is unrealistic, > so there should be a way to do this externally. The simplest thing that comes > to mind is that SSSD would execute an external script to do the update when it > detects changes, but I'm not sure how well would that work with SELinux in the > picture. Is there a better way to do this? It reminds me problems with key-rotation for DNSSEC. Could we find common problems and use the same/similar solution for both problems? An extension for certmonger? Oddjob? Or a completely new daemon? -- Petr^2 Spacek 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-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 pvoborni at redhat.com Mon Sep 2 08:57:14 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 02 Sep 2013 10:57:14 +0200 Subject: [Freeipa-devel] [PATCH] 448 Load updated Web UI files after server upgrade In-Reply-To: <20130902074232.GN7216@redhat.com> References: <5220B880.9040902@redhat.com> <20130902074232.GN7216@redhat.com> Message-ID: <522452EA.8070204@redhat.com> On 09/02/2013 09:42 AM, Jan Pazdziora wrote: > On Fri, Aug 30, 2013 at 05:21:36PM +0200, Petr Vobornik wrote: >> >> Solution: >> * Implemented a mini loader which loads basic resources. Dojo loader >> takes action after Dojo is loaded. >> * The loader adds a version parameter (?v=__NUM_VERSION__) to all requests. >> * Version is defined in the loader. It's set to current in `make >> version-update`. >> * All static pages use this loader to fetch their resources. > > Couldn't you make this a build time thing, marking the links with the > version with make? Would it bring us any benefit at this moment? > Alternatively, you could mark them with the hash of > the target, in which case if the target did not change with upgrade, > the hash would stay the same and the browser would not need to reload > it. Yes, it would optimize stuff even more. I'm not a fan of it though. Added benefit seems to be minimal. I try to avoid doing modification of Web UI files at build time because I think the modifications make development less transparent (more changes on different places). -- Petr Vobornik From jpazdziora at redhat.com Mon Sep 2 09:05:11 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 2 Sep 2013 17:05:11 +0800 Subject: [Freeipa-devel] [PATCH] 448 Load updated Web UI files after server upgrade In-Reply-To: <522452EA.8070204@redhat.com> References: <5220B880.9040902@redhat.com> <20130902074232.GN7216@redhat.com> <522452EA.8070204@redhat.com> Message-ID: <20130902090511.GP7216@redhat.com> On Mon, Sep 02, 2013 at 10:57:14AM +0200, Petr Vobornik wrote: > > > >Couldn't you make this a build time thing, marking the links with the > >version with make? > > Would it bring us any benefit at this moment? Less logic in runtime. > >Alternatively, you could mark them with the hash of > >the target, in which case if the target did not change with upgrade, > >the hash would stay the same and the browser would not need to reload > >it. > > Yes, it would optimize stuff even more. I'm not a fan of it though. > Added benefit seems to be minimal. > > I try to avoid doing modification of Web UI files at build time > because I think the modifications make development less transparent > (more changes on different places). Fair enough. -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From akrivoka at redhat.com Mon Sep 2 09:36:09 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 02 Sep 2013 11:36:09 +0200 Subject: [Freeipa-devel] [PATCH] 0059 Create DS user and group during ipa-restore In-Reply-To: <5220AE45.200@redhat.com> References: <521F3BA9.70001@redhat.com> <5220AE45.200@redhat.com> Message-ID: <52245C09.5070808@redhat.com> On 08/30/2013 04:37 PM, Petr Viktorin wrote: > On 08/29/2013 02:16 PM, Ana Krivokapic wrote: >> Hello, >> >> This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/3856. >> > > Thanks for the patch! > I haven't tested it yet, but I've read it and I have some comments below. > > >> diff --git a/install/share/copy-schema-to-ca.py >> b/install/share/copy-schema-to-ca.py >> index >> 1888f12513aa3edf22149e9330afea99f62bf41d..fe99a9256f1298bae1c746ea0c4d41339a4fbebb >> 100755 >> --- a/install/share/copy-schema-to-ca.py >> +++ b/install/share/copy-schema-to-ca.py >> @@ -15,10 +15,11 @@ >> import pwd >> import shutil >> >> -from ipapython import services, ipautil, dogtag >> +from ipapython import services, ipautil >> from ipapython.ipa_log_manager import root_logger, standard_logging_setup >> -from ipaserver.install.dsinstance import DS_USER, schema_dirname >> +from ipaserver.install.dsinstance import schema_dirname >> from ipaserver.install.cainstance import PKI_USER >> +from ipaserver.install.installutils import DS_USER >> from ipalib import api > > copy-schema-to-ca.py is intended to be copied to older systems, to prepare the > CA DSs of old IPA masters for replication with new masters with unified DSs. > This means that we can't remove anything we import here; the constants need to > be available at the old locations. Thanks for clearing that up, I didn't know about this requirement. > > That's the hard requirement, but anyway I think the constants, and the > create_ds_user & create_ds_group functions, are specific to the DS and so > belong in dsinstance. > Did I overlook a reason for moving them to installutils? You are right. I refactored these functions so that they can be more easily used from other modules, but there is no special reason to put them in installutils. I moved them back to dsinstance. > > [...] >> diff --git a/ipaserver/install/installutils.py >> b/ipaserver/install/installutils.py >> index >> 268279dc9d22b9f983406303cbfc80c00a2b8fa0..84846221d2800443ba6e291ec9c28b37a482d735 >> 100644 > [...] >> +def create_ds_user(): >> + """ >> + Create DS user if it doesn't exist yet >> + """ >> + try: >> + pwd.getpwnam(DS_USER) >> + root_logger.debug("DS user %s exists" % DS_USER) > > Use comma for debug() arguments, i.e. debug("DS group %s exists", DS_GROUP). > Same in other places. Fixed. > >> + except KeyError: >> + root_logger.debug("Adding DS user %s" % DS_USER) >> + args = ["/usr/sbin/useradd", "-g", DS_GROUP, >> + "-c", "DS System User", >> + "-d", "/var/lib/dirsrv", >> + "-s", "/sbin/nologin", >> + "-M", "-r", DS_USER] >> + try: >> + ipautil.run(args) >> + root_logger.debug("Done adding DS user") >> + except ipautil.CalledProcessError, e: >> + root_logger.critical("Failed to add DS user %s" % e) >> + >> + >> +def create_ds_group(): >> + """ >> + Create DS group if it doesn't exist yet >> + """ > > Please document the return value in the docstring, it's not obvious that this > returns True iff it didn't do anything. > Done. Updated patch attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0059-02-Create-DS-user-and-group-during-ipa-restore.patch Type: text/x-patch Size: 9076 bytes Desc: not available URL: From pviktori at redhat.com Mon Sep 2 10:30:46 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 02 Sep 2013 12:30:46 +0200 Subject: [Freeipa-devel] [PATCH] 0058 Add integration tests for forced client re-enrollment In-Reply-To: <5220B94F.9080006@redhat.com> References: <521DF54D.1040203@redhat.com> <52209DE5.5070404@redhat.com> <5220B94F.9080006@redhat.com> Message-ID: <522468D6.5080302@redhat.com> On 08/30/2013 05:25 PM, Ana Krivokapic wrote: > On 08/30/2013 03:28 PM, Petr Viktorin wrote: >> On 08/28/2013 03:04 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch adds integration tests for the forced client re-enrollment >>> feature, according to the test plan at: >>> http://www.freeipa.org/page/V3/Forced_client_re-enrollment#Test_Plan >>> >>> >>> https://fedorahosted.org/freeipa/ticket/3832 >> >> Thank you! The tests are good. As expected I have some nitpicks below. >> >> >> I recommend putting the test case names from the wiki in the method docstrings. >> >> [...] >>> + def restore_client(self): >>> + client = self.clients[0] >> >> I'll ask you to allow SSH here, because the controller can theoretically also >> act as one of the test hosts: >> >> iptables -A INPUT -p tcp --dport 22 -j ACCEPT >> >>> + client.run_command([ >>> + 'iptables', >>> + '-A', 'INPUT', >>> + '-j', 'REJECT', >>> + '-p', 'all', >>> + '--source', self.master.ip >>> + ]) >>> + self.uninstall_client() >>> + client.run_command(['iptables', '-F']) >> >> [...] >>> + def backup_keytab(self): >>> + self.clients[0].get_file(CLIENT_KEYTAB, TEMP_KEYTAB) >>> + self.master.put_file(TEMP_KEYTAB, BACKUP_KEYTAB) >> >> Please use get_file_contents & put_file_contents. There might be more tests >> running on the controller machine, we don't want to use a shared file. >> For BACKUP_KEYTAB and EMPTY_KEYTAB please use a file inside >> master.config.test_dir; we don't want to leave files on the testing machines. >> The test_dir gets cleaned up. >> > > Thanks for the review! > > All issues are fixed in the updated patch. > Thanks, ACK, pushed to: master: f40cb4c031b21940309ff1fbbf6b4f64aa5a6c39 ipa-3-3: adac5549a0fe57611e825fe7a1c4b538b498297b -- Petr? From pviktori at redhat.com Mon Sep 2 10:55:31 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 02 Sep 2013 12:55:31 +0200 Subject: [Freeipa-devel] [PATCH] 0061 Add option to ipa-client-install to configure automount In-Reply-To: <5220A7B8.8000901@redhat.com> References: <5220A7B8.8000901@redhat.com> Message-ID: <52246EA3.1040703@redhat.com> On 08/30/2013 04:10 PM, Ana Krivokapic wrote: > Hello, > > The attached patch addresses ticket https://fedorahosted.org/freeipa/ticket/3740. Hello, Please write a design doc for this RFE. Also you'll need to update the ipa-client-install man page. I wonder if `location` is too generic a name for this option. Did you think about `--automount-location`, plus maybe `--automount` without argument to just use the "default" location? It's a bit longer but it would make it immediately clear what the option is about. -- Petr? From akrivoka at redhat.com Mon Sep 2 11:31:33 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 02 Sep 2013 13:31:33 +0200 Subject: [Freeipa-devel] [PATCH] 0061 Add option to ipa-client-install to configure automount In-Reply-To: <52246EA3.1040703@redhat.com> References: <5220A7B8.8000901@redhat.com> <52246EA3.1040703@redhat.com> Message-ID: <52247715.9030500@redhat.com> On 09/02/2013 12:55 PM, Petr Viktorin wrote: > On 08/30/2013 04:10 PM, Ana Krivokapic wrote: >> Hello, >> >> The attached patch addresses ticket >> https://fedorahosted.org/freeipa/ticket/3740. > > Hello, > Please write a design doc for this RFE. I updated the Minor Enhancements page: http://www.freeipa.org/page/V3_Minor_Enhancements. I think it is sufficient in this case. > Also you'll need to update the ipa-client-install man page. Done. > > I wonder if `location` is too generic a name for this option. > Did you think about `--automount-location`, Good point, I changed `--location` to `--automount-location`. > plus maybe `--automount` without argument to just use the "default" location? > It's a bit longer but it would make it immediately clear what the option is > about. > I think this is a bit of an overkill, as "--automount-location=default" does precisely that. I would rather not complicate things further by adding more options. Thanks for the review, updated patch is attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0061-02-Add-option-to-ipa-client-install-to-configure-automo.patch Type: text/x-patch Size: 3495 bytes Desc: not available URL: From simo at redhat.com Mon Sep 2 12:38:51 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 02 Sep 2013 08:38:51 -0400 Subject: [Freeipa-devel] IPA Server UI Behind Proxy In-Reply-To: <20130902063154.GH7216@redhat.com> References: <520B338A.2070605@redhat.com> <20130815140231.GE4714@redhat.com> <520CE569.2000301@redhat.com> <20130902063154.GH7216@redhat.com> Message-ID: <1378125531.1691.2.camel@willson.li.ssimo.org> On Mon, 2013-09-02 at 14:31 +0800, Jan Pazdziora wrote: > On Thu, Aug 15, 2013 at 04:27:53PM +0200, Petr Viktorin wrote: > > > > >Alternatively, how essential is this requirement for the referer > > >header -- couldn't it be dropped, maybe via some config option? > > > > Without it, a malicious link/button on any webpage (or e-mail) could > > do any action in IPA, if clicked by a logged-in admin. > > Could we change the CSRF protection method from the Referrer check to > some user session specific token? Where do you store it on the client side ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Mon Sep 2 13:42:27 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 02 Sep 2013 15:42:27 +0200 Subject: [Freeipa-devel] certmonger/oddjob for DNSSEC key maintenance In-Reply-To: <521D1567.80401@redhat.com> References: <5204E103.1090109@redhat.com> <521CF250.3070803@redhat.com> <521CF85C.5050608@redhat.com> <521D1567.80401@redhat.com> Message-ID: <522495C3.8000107@redhat.com> On 27.8.2013 23:08, Dmitri Pal wrote: > On 08/27/2013 03:05 PM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 08/09/2013 08:30 AM, Petr Spacek wrote: >>>> Hello, >>>> >>>> I would like to get opinions about key maintenance for DNSSEC. >>>> >>>> Problem summary: >>>> - FreeIPA will support DNSSEC >>>> - DNSSEC deployment requires <2,n> cryptographic keys for each DNS >>>> zone (i.e. objects in LDAP) >>>> - The same keys are shared by all FreeIPA servers >>>> - Keys have limited lifetime and have to be re-generated on monthly >>>> basics (in very first approximation, it will be configurable and the >>>> interval will differ for different key types) >>>> - The plan is to store keys in LDAP and let 'something' (i.e. >>>> certmonger or oddjob?) to generate and store the new keys back into >>>> LDAP >>>> - There are command line tools for key-generation (dnssec-keygen from >>>> the package bind-utils) >>>> - We plan to select one super-master which will handle regular >>>> key-regeneration (i.e. do the same as we do for special CA >>>> certificates) >>>> - Keys stored in LDAP will be encrypted somehow, most probably by some >>>> symmetric key shared among all IPA DNS servers >>>> >>>> Could certmonger or oddjob do key maintenance for us? I can imagine >>>> something like this: >>>> - watch some attributes in LDAP and wait until some key expires >>>> - run dnssec-keygen utility >>>> - read resulting keys and encrypt them with given 'master key' >>>> - store resulting blobs in LDAP >>>> - wait until another key reaches expiration timestamp >>>> >>>> It is simplified, because there will be multiple keys with different >>>> lifetimes, but the idea is the same. All the gory details are in the >>>> thread '[Freeipa-devel] DNSSEC support design considerations: key >>>> material handling': >>>> https://www.redhat.com/archives/freeipa-devel/2013-July/msg00129.html >>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html >>>> >>>> Nalin and others, what do you think? Is certmonger or oddjob the right >>>> place to do something like this? >>>> >>>> Thank you for your time! >>>> >>> Was there any discussion of this mail? >>> >> >> I think at least some of this was covered in another thread, "DNSSEC >> support design considerations: key material handling" at >> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html >> >> rob >> >> > Yes, I have found that thread though I have not found it to come to some > conclusion and a firm plan. > I will leave to Petr to summarize outstanding issues and repost them. All questions stated in the first e-mail in this thread are still open: https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html There was no reply to these questions during my vacation, so I don't have much to add at the moment. Nalin, please, could you provide your opinion? How modular/extendible the certmonger is? Does it make sense to add DNSSEC key-management to certmonger? What about CA rotation problem? Can we share some algorithms (e.g. for super-master election) between CA rotation and DNSSEC key rotation mechanisms? > BTW I like the idea of masters being responsible for generating a subset > of the keys as Loris suggested. E-mail from Loris in archives: https://www.redhat.com/archives/freeipa-devel/2013-August/msg00100.html The idea seems really nice and simple, but I'm afraid that there could be some serious race conditions. - How will it work when topology changes? - What if number of masters is > number of days in month? (=> Auto-tune interval from month to smaller time period => Again, what should we do after a topology change?) - What we should do if topology was changed when a master was disconnected from the rest of the network? (I.e. Link over WAN was down at the moment of change.) What will happen after re-connection to the topology? Example: Time 0: Masters A, B; topology: A---B Time 1: Master A have lost connection to master B Time 2: Master C was added; topology: A ? B---C Time 3 (Day 3): A + C did rotation at the same time Time 4: Connection was restored; topology: A---B---C Now what? I have a feeling that we need something like quorum protocol for writes (only for sensitive operations like CA cert and DNSSEC key rotations). http://en.wikipedia.org/wiki/Quorum_(distributed_computing) The other question is how should we handle catastrophic situations where more than half of masters were lost? (Two of three data centres were blown by a tornado etc.) -- Petr^2 Spacek From abokovoy at redhat.com Mon Sep 2 13:58:13 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Sep 2013 16:58:13 +0300 Subject: [Freeipa-devel] [PATCH] Coverity fixes for slapi-nis Message-ID: <20130902135813.GF21212@redhat.com> Hi Nalin, attached please find two patches that fix minor Coverity issues. The first patch is for issue 11937 which is a false positive but caught up wrong use of the helper method -- the method map_data_set_entry() passes key and value length arguments through to map_data_save_list() which expects them to be arrays but we pass pointer to the variable. Luckily, in our case map_data_save_list() never goes beyond element 0 of the array so the fix is mostly cosmetic. The second fix is in PAM wrapper in the tests and minor too -- we would leak a memory if PAM wrapper wasn't called under wrapping condition. The same patches are in my Fedora people slapi-nis tree, branch 'coverity': http://fedorapeople.org/cgit/abbra/public_git/slapi-nis.git/log/?h=coverity -- / Alexander Bokovoy -------------- next part -------------- >From ec00422ceeabc1296031675ff0cbd559cbd23806 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 2 Sep 2013 15:58:09 +0300 Subject: [PATCH 1/2] Coverity#11937: use proper structure to pass to map_data_set_entry() map_data_set_entry() passes pointers to the lengths of the key and the value to map_data_save_list() which interpretes them as arrays of integers. --- src/back-sch.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/src/back-sch.c b/src/back-sch.c index c33e708..9d14a7e 100644 --- a/src/back-sch.c +++ b/src/back-sch.c @@ -394,7 +394,7 @@ backend_set_entry_from(Slapi_PBlock *pb, enum backend_entry_source source, const char *hexchars = "0123456789ABCDEF"; char *rdn, *ndn, *ldif, *plugin_id, *keys[2], *values[2], **ava, *p, *q; char *usn, *attr, *val; - unsigned int rdn_len, value_len, *ava_lens; + unsigned int rdn_len[2], value_len[2], *ava_lens; const char *rdnstr; int len, i, j, k, count; Slapi_Entry *entry; @@ -421,7 +421,7 @@ backend_set_entry_from(Slapi_PBlock *pb, enum backend_entry_source source, &data->common.inref_attrs, &data->common.ref_attr_list, &data->common.inref_attr_list, - &rdn_len); + rdn_len); if ((rdn == NULL) || (strlen(rdn) == 0) || (strchr(rdn, '=') == NULL)) { slapi_log_error(SLAPI_LOG_FATAL, plugin_id, "no RDN for %s, unsetting domain/map/id " @@ -601,14 +601,16 @@ backend_set_entry_from(Slapi_PBlock *pb, enum backend_entry_source source, rdn, ndn, slapi_entry_get_ndn(entry)); keys[0] = (char *) rdnstr; keys[1] = NULL; - rdn_len = strlen(rdnstr); + rdn_len[0] = strlen(rdnstr); + rdn_len[1] = -1; values[0] = (char *) slapi_entry_get_ndn(entry); values[1] = NULL; - value_len = -1; + value_len[0] = -1; + value_len[1] = -1; map_data_set_entry(data->common.state, data->common.group, data->common.set, ndn, - &rdn_len, keys, - &value_len, values, + rdn_len, keys, + value_len, values, backend_entry_make_entry_data(source, e_dn, entry), backend_entry_free_entry_data); -- 1.8.3.1 -------------- next part -------------- >From b58a7192b683fe7ab4c8c3d95d73ed4223f7247a Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 2 Sep 2013 16:39:30 +0300 Subject: [PATCH 2/2] Coverity#11940: do not leak memory in the pam wrapper test --- tests/wrap-pam.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/tests/wrap-pam.c b/tests/wrap-pam.c index dc92287..45fa0fc 100644 --- a/tests/wrap-pam.c +++ b/tests/wrap-pam.c @@ -111,14 +111,16 @@ pam_start(const char *service_name, const char *user, char buf[LINE_MAX], *p, *q; pam_handle_t *ret; + if (getenv("WRAPPERS_PAM_CREDS") == NULL) { + return PAM_ABORT; + } + ret = calloc(1, sizeof(*ret)); if (ret == NULL) { return PAM_BUF_ERR; } ret->conv = *pam_conversation; - if (getenv("WRAPPERS_PAM_CREDS") == NULL) { - return PAM_ABORT; - } + fp = fopen(getenv("WRAPPERS_PAM_CREDS"), "r"); if (fp == NULL) { free(ret); -- 1.8.3.1 From pspacek at redhat.com Mon Sep 2 14:20:09 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 02 Sep 2013 16:20:09 +0200 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <1376310604.31361.14.camel@toron.pzo.lgs.com.ve> References: <51924269.8020000@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> <1371824388.17111.118.camel@willson.li.ssimo.org> <51CC66F7.8020001@redhat.com> <1372351401.18685.35.camel@willson.li.ssimo.org> <51E40DF8.80105@redhat.com> <1373915246.30537.400.camel@willson.li.ssimo.org> <51E56376.6000606@redhat.com> <1374078320.32040.96.camel@willson.li.ssimo.org> <51E96952.2070804@redhat.com> <1374256500.32040.248.camel@willson.li.ssimo.org> <51EE44E9.6010807@redhat.com> <5204AB71.3080904@redhat.com> <1376052569.21810.114.camel@willson.li.ssimo.org> <5204EAC4.40100@redhat.com> <5204FB0B.70705@redhat.com> <1376310604.31361.14.camel@toron.pzo.lgs.com.ve> Message-ID: <52249E99.30703@redhat.com> On 12.8.2013 14:30, Loris Santamaria wrote: > El vie, 09-08-2013 a las 16:22 +0200, Petr Spacek escribi?: >> On 9.8.2013 15:12, Rob Crittenden wrote: >>> Simo Sorce wrote: >>>> On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote: >>>>> On 23.7.2013 10:55, Petr Spacek wrote: >>>>>> On 19.7.2013 19:55, Simo Sorce wrote: >>>>>>> I will reply to the rest of the message later if necessary, still >>>>>>> digesting some of your answers, but I wanted to address the following >>>>>>> first. >>>>>>> >>>>>>> On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: >>>>>>>> >>>>>>>> The most important question at the moment is "What can we postpone? >>>>>>>> How >>>>>>>> fragile it can be for shipping it as part of Fedora 20?" Could we >>>>>>>> declare >>>>>>>> DNSSEC support as "technology preview"/"don't use it for anything >>>>>>>> serious"? >>>>>>> >>>>>>> Until we figur out proper management in LDAP we will be a bit stuck, esp >>>>>>> if we want to consider usin the 'somthing' that stores keys instead of >>>>>>> toring them stright in LDAP. >>>>>>> >>>>>>> So maybe we can start with allowing just one server to do DNSSEC and >>>>>>> source keys from files for now ? >>>>>> >>>>>> The problem is that DNSSEC deployment *on single domain* is 'all or nothing': >>>>>> All DNS servers have to support DNSSEC otherwise the validation on client >>>>>> side >>>>>> can fail randomly. >>>>>> >>>>>> Note that *parent* zone indicates that the particular child zone is secured >>>>>> with DNSSEC by sending DS (delegation signer) record to the client. >>>>>> Validation >>>>>> will fail if client receives DS record from the parent but no signatures are >>>>>> present in data from 'child' zone itself. >>>>>> >>>>>> This prevents downgrade (DNSSEC => plain DNS) attacks. >>>>>> >>>>>> As a result, we have only two options: One DNS server with DNSSEC enabled or >>>>>> arbitrary number DNS servers without DNSSEC, which is very unfortunate. >>>>>> >>>>>>> as soon as we have that workign we should also have clearer plans about >>>>>>> how we manage keys in LDAP (or elsewhere). >>>>> >>>>> Dmitri, Martin and me discussed this proposal in person and the new plan is: >>>>> - Elect one super-master which will handle key generation (as we do with >>>>> special CA certificates) >>>> >>>> I guess we can start this way, but how do you determine which one is >>>> master ? >> How do we select the 'super-master' for CA certificates? I would re-use the >> same logic (for now). >> >>>> I do not really like to have all this 'super roles', it's brittle and >>>> admins will be confused which means one day their whole infrastructure >>>> will be down because the keys are expired and all the clients will >>>> refuse to communicate with anything. >>> >>> AFAIU keys don't expire, rather there is a rollover process. The problem would >>> be if the server that controlled the rollover went away the keys would never >>> roll, leaving you potentially exposed. >> In DNSSEC it could be a problem. Each signature contains validity interval and >> validation will fail when it expires. It practically means that DNS will stop >> working if the keys are not rotated in time. (More keys can co-exists, so the >> roll-over process can be started e.g. a month before the current key really >> expires.) >> >>>> I think it is ok as a first implementation, but I think this *must not* >>>> be the final state. We can and must do better than this. >> I definitely agree. IMHO the basic problem is the same or very similar for >> DNSSEC key generation & CA certificates, so we should solve both problems at >> once - one day. >> >> I mean - we need to coordinate key & cert maintenance between multiple masters >> somehow - and this will be the common problem for CA & DNSSEC. > > You could implement a "protocol" where each master has a day or the week > or the month where it checks if there are any pending keys or CA > certificates to renew and tries to do the job. Next day it is another > master's turn to do the same job and so on. > > Every master is identified by an unique nsDS5ReplicaId, which could be > used as a vector to generate an ordered list of masters. If you have > masters with nsDS5ReplicaId 5,34,35,45 you can say that the one with > nsDS5ReplicaId 5 is master number one, the next is master number two and > so on. > > On first day of the month it is master number one's turn to check of any > pending key and CA certificate renewal issues and to do the renewal. On > second day of the month it is master number two's turn to do the same. > So if a master was down the job will be done next day by the next > master. > > The cicle will repeat every "number of master" days, in the example > every four days. It is interesting idea... but I think that it is could be fragile and create some serious problems. Please see and reply to e-mail in this thread: https://www.redhat.com/archives/freeipa-devel/2013-September/msg00015.html Thank you for your time & contribution! -- Petr^2 Spacek From pviktori at redhat.com Mon Sep 2 14:35:06 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 02 Sep 2013 16:35:06 +0200 Subject: [Freeipa-devel] [PATCH] 0059 Create DS user and group during ipa-restore In-Reply-To: <52245C09.5070808@redhat.com> References: <521F3BA9.70001@redhat.com> <5220AE45.200@redhat.com> <52245C09.5070808@redhat.com> Message-ID: <5224A21A.6040808@redhat.com> On 09/02/2013 11:36 AM, Ana Krivokapic wrote: > On 08/30/2013 04:37 PM, Petr Viktorin wrote: >> On 08/29/2013 02:16 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/3856. >>> >> >> Thanks for the patch! >> I haven't tested it yet, but I've read it and I have some comments below. >> >> >>> diff --git a/install/share/copy-schema-to-ca.py >>> b/install/share/copy-schema-to-ca.py >>> index >>> 1888f12513aa3edf22149e9330afea99f62bf41d..fe99a9256f1298bae1c746ea0c4d41339a4fbebb >>> 100755 >>> --- a/install/share/copy-schema-to-ca.py >>> +++ b/install/share/copy-schema-to-ca.py >>> @@ -15,10 +15,11 @@ >>> import pwd >>> import shutil >>> >>> -from ipapython import services, ipautil, dogtag >>> +from ipapython import services, ipautil >>> from ipapython.ipa_log_manager import root_logger, standard_logging_setup >>> -from ipaserver.install.dsinstance import DS_USER, schema_dirname >>> +from ipaserver.install.dsinstance import schema_dirname >>> from ipaserver.install.cainstance import PKI_USER >>> +from ipaserver.install.installutils import DS_USER >>> from ipalib import api >> >> copy-schema-to-ca.py is intended to be copied to older systems, to prepare the >> CA DSs of old IPA masters for replication with new masters with unified DSs. >> This means that we can't remove anything we import here; the constants need to >> be available at the old locations. > > Thanks for clearing that up, I didn't know about this requirement. > >> >> That's the hard requirement, but anyway I think the constants, and the >> create_ds_user & create_ds_group functions, are specific to the DS and so >> belong in dsinstance. >> Did I overlook a reason for moving them to installutils? > > You are right. I refactored these functions so that they can be more easily used > from other modules, but there is no special reason to put them in installutils. > I moved them back to dsinstance. > >> >> [...] >>> diff --git a/ipaserver/install/installutils.py >>> b/ipaserver/install/installutils.py >>> index >>> 268279dc9d22b9f983406303cbfc80c00a2b8fa0..84846221d2800443ba6e291ec9c28b37a482d735 >>> 100644 >> [...] >>> +def create_ds_user(): >>> + """ >>> + Create DS user if it doesn't exist yet >>> + """ >>> + try: >>> + pwd.getpwnam(DS_USER) >>> + root_logger.debug("DS user %s exists" % DS_USER) >> >> Use comma for debug() arguments, i.e. debug("DS group %s exists", DS_GROUP). >> Same in other places. > > Fixed. > >> >>> + except KeyError: >>> + root_logger.debug("Adding DS user %s" % DS_USER) >>> + args = ["/usr/sbin/useradd", "-g", DS_GROUP, >>> + "-c", "DS System User", >>> + "-d", "/var/lib/dirsrv", >>> + "-s", "/sbin/nologin", >>> + "-M", "-r", DS_USER] >>> + try: >>> + ipautil.run(args) >>> + root_logger.debug("Done adding DS user") >>> + except ipautil.CalledProcessError, e: >>> + root_logger.critical("Failed to add DS user %s" % e) >>> + >>> + >>> +def create_ds_group(): >>> + """ >>> + Create DS group if it doesn't exist yet >>> + """ >> >> Please document the return value in the docstring, it's not obvious that this >> returns True iff it didn't do anything. >> > > Done. > > Updated patch attached. > I've run into other backup/restore problems that I still need to investigate, but the patch fixes this bug. ACK with a small change in create_ds_group docstring: s/DS/the group/ in "Returns True if DS already exists." I've made the change and pushed to master: de7b1f86dc5bc120e570a99e722a06865cad3fdd[[BR]] ipa-3-3: bc559c0b386cf6e55df6e60d6dcfbc39cf68b85e -- Petr? From pspacek at redhat.com Mon Sep 2 14:35:26 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 02 Sep 2013 16:35:26 +0200 Subject: [Freeipa-devel] DNSSEC support design considerations: key material handling In-Reply-To: <5204FB0B.70705@redhat.com> References: <51924269.8020000@redhat.com> <94125227.1971889.1368606594501.JavaMail.root@redhat.com> <5193A598.4050805@redhat.com> <1369051654.6162.12.camel@willson.li.ssimo.org> <519BA195.9050504@redhat.com> <1369161023.23339.20.camel@willson.li.ssimo.org> <519CDDBA.1010500@redhat.com> <1369252720.2769.23.camel@willson.li.ssimo.org> <519E0D09.3010108@redhat.com> <1369319538.2769.24.camel@willson.li.ssimo.org> <51C2F5E9.10109@redhat.com> <1371824388.17111.118.camel@willson.li.ssimo.org> <51CC66F7.8020001@redhat.com> <1372351401.18685.35.camel@willson.li.ssimo.org> <51E40DF8.80105@redhat.com> <1373915246.30537.400.camel@willson.li.ssimo.org> <51E56376.6000606@redhat.com> <1374078320.32040.96.camel@willson.li.ssimo.org> <51E96952.2070804@redhat.com> <1374256500.32040.248.camel@willson.li.ssimo.org> <51EE44E9.6010807@redhat.com> <5204AB71.3080904@redhat.com> <1376052569.21810.114.camel@willson.li.ssimo.org> <5204EAC4.40100@redhat.com> <5204FB0B.70705@redhat.com> Message-ID: <5224A22E.4050400@redhat.com> On 9.8.2013 16:22, Petr Spacek wrote: > On 9.8.2013 15:12, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote: >>>> On 23.7.2013 10:55, Petr Spacek wrote: >>>>> On 19.7.2013 19:55, Simo Sorce wrote: >>>>>> I will reply to the rest of the message later if necessary, still >>>>>> digesting some of your answers, but I wanted to address the following >>>>>> first. >>>>>> >>>>>> On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote: >>>>>>> >>>>>>> The most important question at the moment is "What can we postpone? >>>>>>> How >>>>>>> fragile it can be for shipping it as part of Fedora 20?" Could we >>>>>>> declare >>>>>>> DNSSEC support as "technology preview"/"don't use it for anything >>>>>>> serious"? >>>>>> >>>>>> Until we figur out proper management in LDAP we will be a bit stuck, esp >>>>>> if we want to consider usin the 'somthing' that stores keys instead of >>>>>> toring them stright in LDAP. >>>>>> >>>>>> So maybe we can start with allowing just one server to do DNSSEC and >>>>>> source keys from files for now ? >>>>> >>>>> The problem is that DNSSEC deployment *on single domain* is 'all or >>>>> nothing': >>>>> All DNS servers have to support DNSSEC otherwise the validation on client >>>>> side >>>>> can fail randomly. >>>>> >>>>> Note that *parent* zone indicates that the particular child zone is secured >>>>> with DNSSEC by sending DS (delegation signer) record to the client. >>>>> Validation >>>>> will fail if client receives DS record from the parent but no signatures are >>>>> present in data from 'child' zone itself. >>>>> >>>>> This prevents downgrade (DNSSEC => plain DNS) attacks. >>>>> >>>>> As a result, we have only two options: One DNS server with DNSSEC enabled or >>>>> arbitrary number DNS servers without DNSSEC, which is very unfortunate. >>>>> >>>>>> as soon as we have that workign we should also have clearer plans about >>>>>> how we manage keys in LDAP (or elsewhere). >>>> >>>> Dmitri, Martin and me discussed this proposal in person and the new plan is: >>>> - Elect one super-master which will handle key generation (as we do with >>>> special CA certificates) >>> >>> I guess we can start this way, but how do you determine which one is >>> master ? > How do we select the 'super-master' for CA certificates? I would re-use the > same logic (for now). > >>> I do not really like to have all this 'super roles', it's brittle and >>> admins will be confused which means one day their whole infrastructure >>> will be down because the keys are expired and all the clients will >>> refuse to communicate with anything. >> >> AFAIU keys don't expire, rather there is a rollover process. The problem would >> be if the server that controlled the rollover went away the keys would never >> roll, leaving you potentially exposed. > In DNSSEC it could be a problem. Each signature contains validity interval and > validation will fail when it expires. It practically means that DNS will stop > working if the keys are not rotated in time. (More keys can co-exists, so the > roll-over process can be started e.g. a month before the current key really > expires.) > >>> I think it is ok as a first implementation, but I think this *must not* >>> be the final state. We can and must do better than this. > I definitely agree. IMHO the basic problem is the same or very similar for > DNSSEC key generation & CA certificates, so we should solve both problems at > once - one day. > > I mean - we need to coordinate key & cert maintenance between multiple masters > somehow - and this will be the common problem for CA & DNSSEC. > >>>> - Store generated DNSSEC keys in LDAP >>>> - Encrypt stored keys with 'DNSSEC master key' shared by all servers >>> >>> ok. >>> >>>> - Derive 'DNSSEC master key' from 'Kerberos master key' during server >>>> install/upgrade and store it somewhere on the filesystem (as the Kerberos >>>> master key, on each IPA server) >>> >>> The Kerberos master key is not stored on disk, furthermore it could >>> change, so if you derive it at install time and install a replica after > Interesting. The master key is stored in the krbMKey attribute in > cn=REALM,cn=kerberos,dc=your,dc=domain , I didn't know that. > >>> it was changed everything will break. I think we need to store the key >>> in LDAP, encrypted, and dump it to disk when a new one is generated. > I agree. > >>> Aside, DNSSEC uses pub/private key crypto so this would be a special >>> 'master key' used exclusively to encrypt keys in LDAP ? > That was the original intention - generate a new 'DNSSEC master key'/'DNSSEC > wrapping key' and let named+certmonger/oddjob to play with it. > >>>> - Consider certmonger or oddjob as key generation triggers >>> >>> I do not understand this comment. > I mean: How hard would it be to extend certmonger/oddjob to take care of > DNSSEC key maintenance? > >> He is trying to automate the key rollover. I don't think certmonger will work >> as it is designed for X.509 certs. Are you proposing an additional attribute >> to schedule the rollover? I thought that it was a good idea to have some >> flexibility here to prevent timed DoS attacks for rollover time. > It definitely requires some changes in certmonger, I'm just exploring various > possibilities. > >>>> I think that we should add one new thing - a 'salt' - used for Kerberos >>>> master >>>> key->DNSSEC master key derivation. It would allow us to re-generate DNSSEC >>>> master key as necessary without a change in the Kerberos master key. >>> >>> Salts are not necessary, HKDF from a cryptographically random key does >>> not require it. > It is correct as long as you don't need to change the 'derived' key without a > change in the 'source' key. Did I miss something? We don't need to dive into > details because (as Simo pointed out) the K/M can change. > >>>> Does it make sense? Does anybody have any ideas/recommendations which >>>> libraries we should use for key derivation and key material en/decryption? >>> >>> openssl/nss I already have all the basic code we need for that. >> >> I prefer the procedure just outlined in >> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html which >> just calls dnssec-keygen rather than trying to roll your own. I don't know >> what derivation really buys you. > > I think that there is slight misunderstanding. We need to decide how the keys > generated by dnssec-keygen will be wrapped with 'the DNSSEC master key'. I > totally agree with using dnssec-keygen for the 'key generation' part! :-) > > > Simo proposed to use separate keys for each IPA DNS server. It could work in > theory, but I can see some problems: > > How the keys are split: > - The (trusted) parent zone 'com.' contains hashes of public parts of KSKs > (key signing keys) used by child zone 'example.com.' > - The child zone 'example.com.' contains the whole public parts of KSKs and ZSKs > - KSKs signs ZSKs (zone signing key, the keys used for signing of real data) > > Layers are: > top ] hash of the KSKs in parent zone 'com.' > middle] KSKs in the zone 'example.com.' > bottom] ZSKs - 'zone subkeys' used for real data signing > > > How the client validates DNSSEC signatures (client operates with public keys): > 1) Read hashes of KSKs from (trusted) parent domain 'com.' > 2) Get KSKs from the child domain 'example.com.' > 3) Compare hashes received from parent domain with hashes computed from KSKs. > 4) Trust ZSKs published in the zone 'example.com.' if they are signed by valid > KSK (valid = hash from parent and the zone itself match). > 5) Get data requested by user along with signatures. > 6) Validate that the data are signed by one of valid ZSKs. > > The point is that *parent* zone has to contain all KSKs used by all IPA > servers. As a result, different keys on each IPA server will create very > interesting game with KSKs (on each KSK re-generation, i.e. approximately once > a year). > > > The another problem is that each key & signature contains key-id, which has to > be unique for each key. The client use this key-id to chose the right public > key for signature validation. > > Key-id is 16 bits long unsigned integer, so there is not much space for > distributed number assignment. > > Fortunately, you can re-use key-id if the key was removed from the zone and > records with this key-id disappeared from all caches. A secure interval for > key-id reuse can be determined from key TTL. > > > And the third problem: Many keys in parent zone will result in much bigger > responses to clients from the parent. It could cause some problems if we > exceed some 'local limit'. Some crazy firewalls could drop large UDP DNS > packets and TCP is not very nice solution alternative. Simo, did you had a chance to summarize your idea with per-server keys? Thank you for your time! -- Petr^2 Spacek From akrivoka at redhat.com Mon Sep 2 15:05:51 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 02 Sep 2013 17:05:51 +0200 Subject: [Freeipa-devel] [PATCH] 0062 Replace ntpdate calls with ntpd Message-ID: <5224A94F.6070605@redhat.com> Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3797. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0062-Replace-ntpdate-calls-with-ntpd.patch Type: text/x-patch Size: 2106 bytes Desc: not available URL: From mkosek at redhat.com Mon Sep 2 15:41:08 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 02 Sep 2013 17:41:08 +0200 Subject: [Freeipa-devel] FreeIPA server package group In-Reply-To: <521F20F0.4060605@redhat.com> References: <521B09B2.3080907@redhat.com> <521B0DD9.4000209@redhat.com> <521B0E6A.1080709@redhat.com> <521DC6F7.8030409@redhat.com> <521DCAD6.7090800@redhat.com> <521DCEF2.1040405@redhat.com> <521F1AA5.1030500@redhat.com> <521F20F0.4060605@redhat.com> Message-ID: <5224B194.1060909@redhat.com> On 08/29/2013 12:22 PM, Tomas Babej wrote: > On 08/29/2013 11:55 AM, Petr Viktorin wrote: >> On 08/28/2013 12:20 PM, Tomas Babej wrote: >>> On 08/28/2013 12:03 PM, Petr Viktorin wrote: >>>> On 08/28/2013 11:46 AM, Tomas Babej wrote: >>>>> On 08/26/2013 10:14 AM, Tomas Babej wrote: >>>>>> On Mon 26 Aug 2013 10:12:09 AM CEST, Petr Vobornik wrote: >>>>>>> On 08/26/2013 09:54 AM, Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I cooked up a patch for comps that adds a FreeIPA package group. >>>>>>>> >>>>>>>> Please chime in if you're OK with package selection / description. >>>>>>>> >>>>>>>> For illustration, see the attached image. FreeIPA will be added as an >>>>>>>> add-on in an installer under the Infrastructure server environment, >>>>>>>> that means, in the included images it will be at the same level >>>>>>>> as DNS or FTP server. >>>>>>>> >>>>>>>> It will also appear in the Software Selection tool (PackageKit). >>>>>>>> >>>>>>>> It should also be available under as yum groupinstall "FreeIPA >>>>>>>> server", >>>>>>>> and in PackageKit, as I understand comps is also source for that too. >>>>>>>> >>>>>>>> https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3630 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> IMO the Audit part in the description is false advertisement. Same >>>>>>> issue is in package descriptions. >>>>>> >>>>>> I know, it's taken directly from there. >>>>>> >>>>>> I'd rather have it consistent, if we're going to change it here, we >>>>>> should do >>>>>> there too, so that we do not end up with multiple (seemingly >>>>>> incomplete) >>>>>> descriptions at various places. >>>>> >>>>> Anybody else does have any other concerns? We need to move with this >>>>> effort since string freeze for F20 is coming. >>>>> >>>>> I'm particulary dubious about including the freeipa-tests package. >>>> >>>> I don't think that should be included, developer tests are unnecessary >>>> for a server. >>>> >>> It was marked as optional in the initial proposal, but I agree it's >>> unnecessary for >>> it to be there at all. >>>>> We discussed the A (as Audit) part in the description with Rob. The >>>>> fact is >>>>> that this is taken from the freeipa-server package description and >>>>> nobody >>>>> complained in 7 years. >>>> >>> >>> Updated tests attached. >>> >> >> Oh, one more thing I remembered just now -- is it too late? >> We should include bind-dyndb-ldap (which pulls in bind). Preferably as default. >> > > I included it there. > > If anyone else wants to chime in, please do now, I'll create a ticket with > rel-eng at the end of the day. > Thanks for this effort. What is the status of the bug - did you create the request already? We will need to do one more change and remove freeipa-server-strict package as up on the decision on today's developer meeting we decided to drop this subpackage in Fedora 20 and later and depend on our new FreeIPA Continuous Integration system instead. Martin From tbabej at redhat.com Mon Sep 2 15:47:34 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 02 Sep 2013 17:47:34 +0200 Subject: [Freeipa-devel] FreeIPA server package group In-Reply-To: <5224B194.1060909@redhat.com> References: <521B09B2.3080907@redhat.com> <521B0DD9.4000209@redhat.com> <521B0E6A.1080709@redhat.com> <521DC6F7.8030409@redhat.com> <521DCAD6.7090800@redhat.com> <521DCEF2.1040405@redhat.com> <521F1AA5.1030500@redhat.com> <521F20F0.4060605@redhat.com> <5224B194.1060909@redhat.com> Message-ID: <5224B316.9050108@redhat.com> On 09/02/2013 05:41 PM, Martin Kosek wrote: > On 08/29/2013 12:22 PM, Tomas Babej wrote: >> On 08/29/2013 11:55 AM, Petr Viktorin wrote: >>> On 08/28/2013 12:20 PM, Tomas Babej wrote: >>>> On 08/28/2013 12:03 PM, Petr Viktorin wrote: >>>>> On 08/28/2013 11:46 AM, Tomas Babej wrote: >>>>>> On 08/26/2013 10:14 AM, Tomas Babej wrote: >>>>>>> On Mon 26 Aug 2013 10:12:09 AM CEST, Petr Vobornik wrote: >>>>>>>> On 08/26/2013 09:54 AM, Tomas Babej wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I cooked up a patch for comps that adds a FreeIPA package group. >>>>>>>>> >>>>>>>>> Please chime in if you're OK with package selection / description. >>>>>>>>> >>>>>>>>> For illustration, see the attached image. FreeIPA will be added as an >>>>>>>>> add-on in an installer under the Infrastructure server environment, >>>>>>>>> that means, in the included images it will be at the same level >>>>>>>>> as DNS or FTP server. >>>>>>>>> >>>>>>>>> It will also appear in the Software Selection tool (PackageKit). >>>>>>>>> >>>>>>>>> It should also be available under as yum groupinstall "FreeIPA >>>>>>>>> server", >>>>>>>>> and in PackageKit, as I understand comps is also source for that too. >>>>>>>>> >>>>>>>>> https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3630 >>>>>>>>> >>>>>>>>> >>>>>>>> IMO the Audit part in the description is false advertisement. Same >>>>>>>> issue is in package descriptions. >>>>>>> I know, it's taken directly from there. >>>>>>> >>>>>>> I'd rather have it consistent, if we're going to change it here, we >>>>>>> should do >>>>>>> there too, so that we do not end up with multiple (seemingly >>>>>>> incomplete) >>>>>>> descriptions at various places. >>>>>> Anybody else does have any other concerns? We need to move with this >>>>>> effort since string freeze for F20 is coming. >>>>>> >>>>>> I'm particulary dubious about including the freeipa-tests package. >>>>> I don't think that should be included, developer tests are unnecessary >>>>> for a server. >>>>> >>>> It was marked as optional in the initial proposal, but I agree it's >>>> unnecessary for >>>> it to be there at all. >>>>>> We discussed the A (as Audit) part in the description with Rob. The >>>>>> fact is >>>>>> that this is taken from the freeipa-server package description and >>>>>> nobody >>>>>> complained in 7 years. >>>> Updated tests attached. >>>> >>> Oh, one more thing I remembered just now -- is it too late? >>> We should include bind-dyndb-ldap (which pulls in bind). Preferably as default. >>> >> I included it there. >> >> If anyone else wants to chime in, please do now, I'll create a ticket with >> rel-eng at the end of the day. >> > Thanks for this effort. What is the status of the bug - did you create the > request already? > > We will need to do one more change and remove freeipa-server-strict package as > up on the decision on today's developer meeting we decided to drop this > subpackage in Fedora 20 and later and depend on our new FreeIPA Continuous > Integration system instead. > > Martin Bug was not needed at the end. Only substantial amount of persuasion that FreeIPA is a big enough project to deserve its own package group :) As for the removing the freeipa-server-strict package from comps, I will take care of that. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From pvoborni at redhat.com Mon Sep 2 15:57:16 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 02 Sep 2013 17:57:16 +0200 Subject: [Freeipa-devel] IPA Server UI Behind Proxy In-Reply-To: <20130902063154.GH7216@redhat.com> References: <520B338A.2070605@redhat.com> <20130815140231.GE4714@redhat.com> <520CE569.2000301@redhat.com> <20130902063154.GH7216@redhat.com> Message-ID: <5224B55C.5010703@redhat.com> On 09/02/2013 08:31 AM, Jan Pazdziora wrote: > On Thu, Aug 15, 2013 at 04:27:53PM +0200, Petr Viktorin wrote: >> >>> Alternatively, how essential is this requirement for the referer >>> header -- couldn't it be dropped, maybe via some config option? >> >> Without it, a malicious link/button on any webpage (or e-mail) could >> do any action in IPA, if clicked by a logged-in admin. > > Could we change the CSRF protection method from the Referrer check to > some user session specific token? > I don't think we can use the recommended method[1] where CSFR token is stored in a requested page(ie in hidden element) because we don't generate UI on a server. The only way to use the token, which I see, is to create CSFR token on login and returned it in a cookie. Web UI or other API consumer can read the token from the cookie. Then they will add this token as new method option. Server will compare the stored CSFR token with the value in the request. The cookie will be sent along with the request as well so it's value can be checked too but IMO it's not necessary. Attacker should not be able to read the cookie content because of different origin. This can be applied only to session usage (/ipa/session/*). Kerberized API on ipa/xml and ipa/json will still require referer check. [1] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#General_Recommendation:_Synchronizer_Token_Pattern -- Petr Vobornik From pviktori at redhat.com Mon Sep 2 16:07:01 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 02 Sep 2013 18:07:01 +0200 Subject: [Freeipa-devel] [PATCH] 0060 Add warning when uninstalling active replica In-Reply-To: <521F6F27.2010704@redhat.com> References: <521F6F27.2010704@redhat.com> Message-ID: <5224B7A5.5070700@redhat.com> On 08/29/2013 05:56 PM, Ana Krivokapic wrote: > Hello, > > This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3867. > Patch works well. It's temping to restart the discussion about how to wrap text output from installation tools. Wrapping at 60 characters because it looks better in the code seems suboptimal. Does anyone remember if we established some guideline last time this came up? -- Petr? From tbabej at redhat.com Mon Sep 2 16:21:04 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 02 Sep 2013 18:21:04 +0200 Subject: [Freeipa-devel] [PATCH] 0060 Add warning when uninstalling active replica In-Reply-To: <5224B7A5.5070700@redhat.com> References: <521F6F27.2010704@redhat.com> <5224B7A5.5070700@redhat.com> Message-ID: <5224BAF0.2070101@redhat.com> On 09/02/2013 06:07 PM, Petr Viktorin wrote: > On 08/29/2013 05:56 PM, Ana Krivokapic wrote: >> Hello, >> >> This patch addresses ticket >> https://fedorahosted.org/freeipa/ticket/3867. >> > > Patch works well. > It's temping to restart the discussion about how to wrap text output > from installation tools. Wrapping at 60 characters because it looks > better in the code seems suboptimal. > Does anyone remember if we established some guideline last time this > came up? > > I'm not sure if I'm missing something, but do we need a guideline here? I don't see any reason why not have best of the both worlds, using print as a function we can wrap the text inside the parenthesis with no effect on the output whatsoever. Or use print statement, but enclose the text in parenthesis. Or use backslash. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From tjaalton at ubuntu.com Mon Sep 2 21:43:07 2013 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Tue, 03 Sep 2013 00:43:07 +0300 Subject: [Freeipa-devel] =?iso-8859-1?q?=5BPATCH=5D=A0Debian_client_suppor?= =?iso-8859-1?q?t?= Message-ID: <5225066B.3010003@ubuntu.com> This fixes https://fedorahosted.org/freeipa/ticket/1887 and https://fedorahosted.org/freeipa/ticket/2455 the first three patches fix some bugs in how python is used fourth patch checks if dbus is already running before trying to start it fifth fixes some compilation warnings sixth finally adds the Debian platform module there are also distro patches that aren't upstreamable as-is, that do stuff like - give--install-layout=deb to setup.py - disable make-testcert since it needs a server running - fix hardcoded NFS related paths and a variable in ipa-client-automount - fix ldap.conf path in ipa-client-install - fix ntpdate options in ntpconf.py (Debian doesn't patch ntpdate like Fedora) - change nss includes in ipa_pwd.c ( not ) dunno what to do about those, the packaging can keep on carrying those but if you have ideas how to make them configurable so that upstream git/tarball could be used for development/testing on Debian then that would be nice. t -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0001-Use-usr-bin-python-as-fallback-python-path.patch Type: text/x-patch Size: 707 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0002-Don-t-search-platform-path.patch Type: text/x-patch Size: 1001 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0003-Don-t-exclude-symlinks-when-loading-plugins.patch Type: text/x-patch Size: 848 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0004-Check-dbus-before-starting-it.patch Type: text/x-patch Size: 1917 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0005-Fix-Wformat-security-warnings.patch Type: text/x-patch Size: 3228 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tjaalton-0006-Add-Debian-client-platform-support.patch Type: text/x-patch Size: 9538 bytes Desc: not available URL: From jpazdziora at redhat.com Tue Sep 3 00:25:50 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 3 Sep 2013 08:25:50 +0800 Subject: [Freeipa-devel] IPA Server UI Behind Proxy In-Reply-To: <1378125531.1691.2.camel@willson.li.ssimo.org> References: <520B338A.2070605@redhat.com> <20130815140231.GE4714@redhat.com> <520CE569.2000301@redhat.com> <20130902063154.GH7216@redhat.com> <1378125531.1691.2.camel@willson.li.ssimo.org> Message-ID: <20130903002550.GB16168@redhat.com> On Mon, Sep 02, 2013 at 08:38:51AM -0400, Simo Sorce wrote: > > > > Could we change the CSRF protection method from the Referrer check to > > some user session specific token? > > Where do you store it on the client side ? Storing it in some DOM element (hidden div) and retrieving it into any POST operation you do against the server would be my course of investigation. -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From jpazdziora at redhat.com Tue Sep 3 00:50:13 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 3 Sep 2013 08:50:13 +0800 Subject: [Freeipa-devel] IPA Server UI Behind Proxy In-Reply-To: <5224B55C.5010703@redhat.com> References: <520B338A.2070605@redhat.com> <20130815140231.GE4714@redhat.com> <520CE569.2000301@redhat.com> <20130902063154.GH7216@redhat.com> <5224B55C.5010703@redhat.com> Message-ID: <20130903005013.GC16168@redhat.com> On Mon, Sep 02, 2013 at 05:57:16PM +0200, Petr Vobornik wrote: > > > >Could we change the CSRF protection method from the Referrer check to > >some user session specific token? > > I don't think we can use the recommended method[1] where CSFR token > is stored in a requested page(ie in hidden element) because we don't > generate UI on a server. > > The only way to use the token, which I see, is to create CSFR token > on login and returned it in a cookie. Does it have to be cookie? What is the result of a login operation? It seems that at least for the /ipa/session/login_password call, it is the result of finalize_kerberos_acquisition which is return [''], and that empty string is ignored by IPA.login_password's success_handler. Could the return be the token, and get stored either to IPA.ui.csrf_token or similar place, or stored to an element in the DOM? You don't really need to use cookies for that. -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Tue Sep 3 06:25:32 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 03 Sep 2013 08:25:32 +0200 Subject: [Freeipa-devel] [PATCH] 0060 Add warning when uninstalling active replica In-Reply-To: <5224BAF0.2070101@redhat.com> References: <521F6F27.2010704@redhat.com> <5224B7A5.5070700@redhat.com> <5224BAF0.2070101@redhat.com> Message-ID: <522580DC.8010903@redhat.com> On 09/02/2013 06:21 PM, Tomas Babej wrote: > On 09/02/2013 06:07 PM, Petr Viktorin wrote: >> On 08/29/2013 05:56 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3867. >>> >> >> Patch works well. >> It's temping to restart the discussion about how to wrap text output from >> installation tools. Wrapping at 60 characters because it looks better in the >> code seems suboptimal. >> Does anyone remember if we established some guideline last time this came up? >> >> > I'm not sure if I'm missing something, but do we need a guideline here? > > I don't see any reason why not have best of the both worlds, using print as a > function we can wrap the text inside the parenthesis > with no effect on the output whatsoever. Or use print statement, but enclose > the text in parenthesis. Or use backslash. > Yes. But whatever we choose, we need to make sure that the resulting text is wrapped the same to avoid inconsistent output. IMO we should do our best to keep the text wrapped at 80 characters in new or updated texts. So I would prefer to have Ana's patch refactored a bit, to change wrapping of the resulting from 60 to 80 characters. Martin From pvoborni at redhat.com Tue Sep 3 07:57:45 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 03 Sep 2013 09:57:45 +0200 Subject: [Freeipa-devel] IPA Server UI Behind Proxy In-Reply-To: <20130903005013.GC16168@redhat.com> References: <520B338A.2070605@redhat.com> <20130815140231.GE4714@redhat.com> <520CE569.2000301@redhat.com> <20130902063154.GH7216@redhat.com> <5224B55C.5010703@redhat.com> <20130903005013.GC16168@redhat.com> Message-ID: <52259679.40002@redhat.com> On 09/03/2013 02:50 AM, Jan Pazdziora wrote: > On Mon, Sep 02, 2013 at 05:57:16PM +0200, Petr Vobornik wrote: >>> >>> Could we change the CSRF protection method from the Referrer check to >>> some user session specific token? >> >> I don't think we can use the recommended method[1] where CSFR token >> is stored in a requested page(ie in hidden element) because we don't >> generate UI on a server. >> >> The only way to use the token, which I see, is to create CSFR token >> on login and returned it in a cookie. > > Does it have to be cookie? > > What is the result of a login operation? It seems that at least for > the /ipa/session/login_password call, it is the result of > finalize_kerberos_acquisition which is return [''], and that empty > string is ignored by IPA.login_password's success_handler. Could the > return be the token, and get stored either to IPA.ui.csrf_token or > similar place, or stored to an element in the DOM? You don't really > need to use cookies for that. > It has one drawback. You won't have access to the token if you open new instance of Web UI because you already have a session and therefore don't need to log in. I suppose we can create a new handler (can't be a command) which new Web UI instance would call to obtain the token. Special care would be needed to prevent cross origin usage though. IMO the cookie is more secure, but I'm not a security expert ... -- Petr Vobornik From jpazdziora at redhat.com Tue Sep 3 08:06:27 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 3 Sep 2013 16:06:27 +0800 Subject: [Freeipa-devel] IPA Server UI Behind Proxy In-Reply-To: <52259679.40002@redhat.com> References: <520B338A.2070605@redhat.com> <20130815140231.GE4714@redhat.com> <520CE569.2000301@redhat.com> <20130902063154.GH7216@redhat.com> <5224B55C.5010703@redhat.com> <20130903005013.GC16168@redhat.com> <52259679.40002@redhat.com> Message-ID: <20130903080627.GJ16168@redhat.com> On Tue, Sep 03, 2013 at 09:57:45AM +0200, Petr Vobornik wrote: > > It has one drawback. You won't have access to the token if you open > new instance of Web UI because you already have a session and > therefore don't need to log in. > > I suppose we can create a new handler (can't be a command) which new > Web UI instance would call to obtain the token. Special care would Right. Well, you can actually make it a lazy thing -- only make the call to get the token before any POST is done (and the JS does not have the token). Chances are, if the user is only viewing things on the WebUI without modifying anything, you won't need the token at all. -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From pvoborni at redhat.com Tue Sep 3 08:07:27 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 03 Sep 2013 10:07:27 +0200 Subject: [Freeipa-devel] IPA Server UI Behind Proxy In-Reply-To: <52259679.40002@redhat.com> References: <520B338A.2070605@redhat.com> <20130815140231.GE4714@redhat.com> <520CE569.2000301@redhat.com> <20130902063154.GH7216@redhat.com> <5224B55C.5010703@redhat.com> <20130903005013.GC16168@redhat.com> <52259679.40002@redhat.com> Message-ID: <522598BF.1050306@redhat.com> On 09/03/2013 09:57 AM, Petr Vobornik wrote: > On 09/03/2013 02:50 AM, Jan Pazdziora wrote: >> On Mon, Sep 02, 2013 at 05:57:16PM +0200, Petr Vobornik wrote: >>>> >>>> Could we change the CSRF protection method from the Referrer check to >>>> some user session specific token? >>> >>> I don't think we can use the recommended method[1] where CSFR token >>> is stored in a requested page(ie in hidden element) because we don't >>> generate UI on a server. >>> >>> The only way to use the token, which I see, is to create CSFR token >>> on login and returned it in a cookie. >> >> Does it have to be cookie? >> >> What is the result of a login operation? It seems that at least for >> the /ipa/session/login_password call, it is the result of >> finalize_kerberos_acquisition which is return [''], and that empty >> string is ignored by IPA.login_password's success_handler. Could the >> return be the token, and get stored either to IPA.ui.csrf_token or >> similar place, or stored to an element in the DOM? You don't really >> need to use cookies for that. >> > > It has one drawback. You won't have access to the token if you open new > instance of Web UI because you already have a session and therefore > don't need to log in. > > I suppose we can create a new handler (can't be a command) which new Web > UI instance would call to obtain the token. Special care would be needed > to prevent cross origin usage though. > > IMO the cookie is more secure, but I'm not a security expert ... Maybe there is a way to avoid the cookie and the new handler. DOM is not usable as a storage, but sessionStorage or localStorage [1] might be. Browser support: http://caniuse.com/namevalue-storage [1] https://developer.mozilla.org/en-US/docs/Web/Guide/DOM/Storage -- Petr Vobornik From pviktori at redhat.com Tue Sep 3 09:00:07 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 03 Sep 2013 11:00:07 +0200 Subject: [Freeipa-devel] =?iso-8859-1?q?=5BPATCH=5D=A0Debian_client_suppor?= =?iso-8859-1?q?t?= In-Reply-To: <5225066B.3010003@ubuntu.com> References: <5225066B.3010003@ubuntu.com> Message-ID: <5225A517.80302@redhat.com> On 09/02/2013 11:43 PM, Timo Aaltonen wrote: > > This fixes https://fedorahosted.org/freeipa/ticket/1887 > and > https://fedorahosted.org/freeipa/ticket/2455 Thank you! > the first three patches fix some bugs in how python is used These look okay, I'll check when other build errors are fixed. > fourth patch checks if dbus is already running before trying to start it Please handle this in platform/debian/service.py. Is this only for D-Bus or do all start() methods for Debian need this? If it's all of them, add it in DebianService.start. If it's just D-Bus you'll want to make a special service there, like DebianSSHService. > fifth fixes some compilation warnings Looks good to my eyes, perhaps a C expert can look at this one too. I wonder why these warnings aren't enabled in our builds, though. > sixth finally adds the Debian platform module Please add copyright headers to the new files. in debian/auth.py:DebianAuthConfig.execute, you should use a dictionary for env: env = {'DEBCONF_FRONTEND': 'noninteractive'} You need to import ipautil to use ipautil.run in auth.py. This trips pylint and prevents building the code for me. Do you include pylint in your build procedure? platform/debian/auth.py: Git complains about a new blank line at EOF I don't think anyone from the regular IPA team can really verify the Debian code, so we may just trust you that it works and push it without full tests :) > there are also distro patches that aren't upstreamable as-is, that do > stuff like > - give--install-layout=deb to setup.py Add a SETUP_PY_ARGS variable to the Makefile. > - disable make-testcert since it needs a server running For now you can just run ./make-test directly. Getting `make test` working will be just icing on the cake at this point. > - fix hardcoded NFS related paths and a variable in ipa-client-automount > - fix ldap.conf path in ipa-client-install ipa-client requires ipa-python, we can just stick these in the platform module and include that. > - fix ntpdate options in ntpconf.py (Debian doesn't patch ntpdate like > Fedora) A patch to replace ntpdate with ntp is on review right now; you'll want to revisit this when it gets pushed. > - change nss includes in ipa_pwd.c ( not ) I'd ask for a C expert's opinion. > dunno what to do about those, the packaging can keep on carrying those > but if you have ideas how to make them configurable so that upstream > git/tarball could be used for development/testing on Debian then that > would be nice. Patches to make them configurable are very welcome. You might want to file a bug for each patch, so it's easier to keep track of what's left to do. -- Petr? From jhrozek at redhat.com Tue Sep 3 09:22:56 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 3 Sep 2013 11:22:56 +0200 Subject: [Freeipa-devel] =?iso-8859-1?q?=5BPATCH=5D=A0Debian_client_suppor?= =?iso-8859-1?q?t?= In-Reply-To: <5225A517.80302@redhat.com> References: <5225066B.3010003@ubuntu.com> <5225A517.80302@redhat.com> Message-ID: <20130903092256.GC18889@hendrix.redhat.com> On Tue, Sep 03, 2013 at 11:00:07AM +0200, Petr Viktorin wrote: > >fifth fixes some compilation warnings > > Looks good to my eyes, perhaps a C expert can look at this one too. > I wonder why these warnings aren't enabled in our builds, though. They look good to me, too. (Does this answer make me a C expert? :-)) -Wformat-security is not among default CFLAGS on Fedora. In SSSD, we only recently fixed these problems in our debug messages. From pviktori at redhat.com Tue Sep 3 10:27:17 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 03 Sep 2013 12:27:17 +0200 Subject: [Freeipa-devel] [PATCH] 0061 Add option to ipa-client-install to configure automount In-Reply-To: <52247715.9030500@redhat.com> References: <5220A7B8.8000901@redhat.com> <52246EA3.1040703@redhat.com> <52247715.9030500@redhat.com> Message-ID: <5225B985.3060802@redhat.com> On 09/02/2013 01:31 PM, Ana Krivokapic wrote: > On 09/02/2013 12:55 PM, Petr Viktorin wrote: >> On 08/30/2013 04:10 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> The attached patch addresses ticket >>> https://fedorahosted.org/freeipa/ticket/3740. >> >> Hello, >> Please write a design doc for this RFE. > > I updated the Minor Enhancements page: > http://www.freeipa.org/page/V3_Minor_Enhancements. I think it is sufficient in > this case. > >> Also you'll need to update the ipa-client-install man page. > > Done. >> >> I wonder if `location` is too generic a name for this option. >> Did you think about `--automount-location`, > > Good point, I changed `--location` to `--automount-location`. > >> plus maybe `--automount` without argument to just use the "default" location? >> It's a bit longer but it would make it immediately clear what the option is >> about. >> > > I think this is a bit of an overkill, as "--automount-location=default" does > precisely that. I would rather not complicate things further by adding more options. > > Thanks for the review, updated patch is attached. > Looks good! One more comment for usability. The man page should explain that --automount-location configures automount by running ipa-client-automount(1). -- Petr? From akrivoka at redhat.com Tue Sep 3 10:48:21 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 03 Sep 2013 12:48:21 +0200 Subject: [Freeipa-devel] [PATCH] 0063 Do not show unexpected error in ipa-ldap-updater Message-ID: <5225BE75.5070501@redhat.com> Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3825. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0063-Do-not-show-unexpected-error-in-ipa-ldap-updater.patch Type: text/x-patch Size: 1086 bytes Desc: not available URL: From akrivoka at redhat.com Tue Sep 3 11:02:48 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 03 Sep 2013 13:02:48 +0200 Subject: [Freeipa-devel] [PATCH] 0061 Add option to ipa-client-install to configure automount In-Reply-To: <5225B985.3060802@redhat.com> References: <5220A7B8.8000901@redhat.com> <52246EA3.1040703@redhat.com> <52247715.9030500@redhat.com> <5225B985.3060802@redhat.com> Message-ID: <5225C1D8.8090500@redhat.com> On 09/03/2013 12:27 PM, Petr Viktorin wrote: > On 09/02/2013 01:31 PM, Ana Krivokapic wrote: >> On 09/02/2013 12:55 PM, Petr Viktorin wrote: >>> On 08/30/2013 04:10 PM, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> The attached patch addresses ticket >>>> https://fedorahosted.org/freeipa/ticket/3740. >>> >>> Hello, >>> Please write a design doc for this RFE. >> >> I updated the Minor Enhancements page: >> http://www.freeipa.org/page/V3_Minor_Enhancements. I think it is sufficient in >> this case. >> >>> Also you'll need to update the ipa-client-install man page. >> >> Done. >>> >>> I wonder if `location` is too generic a name for this option. >>> Did you think about `--automount-location`, >> >> Good point, I changed `--location` to `--automount-location`. >> >>> plus maybe `--automount` without argument to just use the "default" location? >>> It's a bit longer but it would make it immediately clear what the option is >>> about. >>> >> >> I think this is a bit of an overkill, as "--automount-location=default" does >> precisely that. I would rather not complicate things further by adding more >> options. >> >> Thanks for the review, updated patch is attached. >> > > Looks good! One more comment for usability. > The man page should explain that --automount-location configures automount by > running ipa-client-automount(1). > > Fixed in updated patch. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0061-03-Add-option-to-ipa-client-install-to-configure-automo.patch Type: text/x-patch Size: 3578 bytes Desc: not available URL: From pviktori at redhat.com Tue Sep 3 11:15:56 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 03 Sep 2013 13:15:56 +0200 Subject: [Freeipa-devel] [PATCH] 0062 Replace ntpdate calls with ntpd In-Reply-To: <5224A94F.6070605@redhat.com> References: <5224A94F.6070605@redhat.com> Message-ID: <5225C4EC.8060605@redhat.com> On 09/02/2013 05:05 PM, Ana Krivokapic wrote: > Hello, > > This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/3797. > Thanks! I have a question. > - # retry several times -- logic follows /etc/init.d/ntpdate > - # implementation > + # retry several times > for retry in range(0, 3): What's the reason to try several times? Is it still necessary with ntpd? I checked /etc/init.d/ntpdate in RHEL (since Fedora doesn't have it any more) and I didn't see any repeating. -- Petr? From pviktori at redhat.com Tue Sep 3 11:34:48 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 03 Sep 2013 13:34:48 +0200 Subject: [Freeipa-devel] =?iso-8859-1?q?=5BPATCH=5D=A0Debian_client_suppor?= =?iso-8859-1?q?t?= In-Reply-To: <20130903092256.GC18889@hendrix.redhat.com> References: <5225066B.3010003@ubuntu.com> <5225A517.80302@redhat.com> <20130903092256.GC18889@hendrix.redhat.com> Message-ID: <5225C958.2000101@redhat.com> On 09/03/2013 11:22 AM, Jakub Hrozek wrote: > On Tue, Sep 03, 2013 at 11:00:07AM +0200, Petr Viktorin wrote: >>> fifth fixes some compilation warnings >> >> Looks good to my eyes, perhaps a C expert can look at this one too. >> I wonder why these warnings aren't enabled in our builds, though. > > They look good to me, too. (Does this answer make me a C expert? :-)) Why, yes! (Your certificate will arrive by mail shortly.) > -Wformat-security is not among default CFLAGS on Fedora. In SSSD, we > only recently fixed these problems in our debug messages. I've taken the WARNINGS from SSSD's aliases, built with them, and reported three additional warnings. https://fedorahosted.org/freeipa/ticket/3896 -- Petr? From jhrozek at redhat.com Tue Sep 3 11:42:20 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 3 Sep 2013 13:42:20 +0200 Subject: [Freeipa-devel] =?iso-8859-1?q?=5BPATCH=5D=A0Debian_client_suppor?= =?iso-8859-1?q?t?= In-Reply-To: <5225C958.2000101@redhat.com> References: <5225066B.3010003@ubuntu.com> <5225A517.80302@redhat.com> <20130903092256.GC18889@hendrix.redhat.com> <5225C958.2000101@redhat.com> Message-ID: <20130903114220.GG18889@hendrix.redhat.com> On Tue, Sep 03, 2013 at 01:34:48PM +0200, Petr Viktorin wrote: > On 09/03/2013 11:22 AM, Jakub Hrozek wrote: > >On Tue, Sep 03, 2013 at 11:00:07AM +0200, Petr Viktorin wrote: > >>>fifth fixes some compilation warnings > >> > >>Looks good to my eyes, perhaps a C expert can look at this one too. > >>I wonder why these warnings aren't enabled in our builds, though. > > > >They look good to me, too. (Does this answer make me a C expert? :-)) > > Why, yes! (Your certificate will arrive by mail shortly.) > > >-Wformat-security is not among default CFLAGS on Fedora. In SSSD, we > >only recently fixed these problems in our debug messages. > > I've taken the WARNINGS from SSSD's aliases, built with them, and > reported three additional warnings. > > https://fedorahosted.org/freeipa/ticket/3896 Yes, they are a good source of defensive CFLAGS. But make sure to grab a very recent version (git HEAD ideally), there was recently a typo that prevented the aliases from working correctly. From akrivoka at redhat.com Tue Sep 3 13:14:35 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 03 Sep 2013 15:14:35 +0200 Subject: [Freeipa-devel] [PATCH] 0060 Add warning when uninstalling active replica In-Reply-To: <522580DC.8010903@redhat.com> References: <521F6F27.2010704@redhat.com> <5224B7A5.5070700@redhat.com> <5224BAF0.2070101@redhat.com> <522580DC.8010903@redhat.com> Message-ID: <5225E0BB.9070404@redhat.com> On 09/03/2013 08:25 AM, Martin Kosek wrote: > On 09/02/2013 06:21 PM, Tomas Babej wrote: >> On 09/02/2013 06:07 PM, Petr Viktorin wrote: >>> On 08/29/2013 05:56 PM, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3867. >>>> >>> Patch works well. >>> It's temping to restart the discussion about how to wrap text output from >>> installation tools. Wrapping at 60 characters because it looks better in the >>> code seems suboptimal. >>> Does anyone remember if we established some guideline last time this came up? >>> >>> >> I'm not sure if I'm missing something, but do we need a guideline here? >> >> I don't see any reason why not have best of the both worlds, using print as a >> function we can wrap the text inside the parenthesis >> with no effect on the output whatsoever. Or use print statement, but enclose >> the text in parenthesis. Or use backslash. >> > Yes. But whatever we choose, we need to make sure that the resulting text is > wrapped the same to avoid inconsistent output. > > IMO we should do our best to keep the text wrapped at 80 characters in new or > updated texts. So I would prefer to have Ana's patch refactored a bit, to > change wrapping of the resulting from 60 to 80 characters. > > Martin Text is wrapped at 80 characters in the updated patch. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0060-02-Add-warning-when-uninstalling-active-replica.patch Type: text/x-patch Size: 3284 bytes Desc: not available URL: From dpal at redhat.com Tue Sep 3 16:16:43 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 03 Sep 2013 12:16:43 -0400 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <52245136.1090804@redhat.com> References: <52161568.7060702@redhat.com> <52245136.1090804@redhat.com> Message-ID: <52260B6B.7050906@redhat.com> On 09/02/2013 04:49 AM, Petr Spacek wrote: > On 22.8.2013 15:43, Jan Cholasta wrote: >> Hi, >> >> I'm currently investigating support for multiple CA certificates in LDAP >> (, >> ). This will be useful >> for CA >> certificate renewal (, >> ) and using >> certificates issued >> by custom CAs for IPA HTTP and directory server instances >> (). >> >> The biggest issue is how to make IPA clients aware of CA certificate >> changes. >> One of the tickets suggests polling the LDAP server from SSSD. Would >> that be >> sufficient? Perhaps a combination of polling and detecting >> certificate changes >> when connecting to LDAP would be better? >> >> Another issue is how to handle updating IPA systems with new CA >> certificate(s). On clients it is probably sufficient to store the >> certificate(s) in /etc/ipa/ca.crt, but on servers there are multiple >> places >> where the update needs to be done (HTTP and directory server NSS >> databases, >> KDC pkinit_anchors file, etc.). IMO doing all this from SSSD is >> unrealistic, >> so there should be a way to do this externally. The simplest thing >> that comes >> to mind is that SSSD would execute an external script to do the >> update when it >> detects changes, but I'm not sure how well would that work with >> SELinux in the >> picture. Is there a better way to do this? > > It reminds me problems with key-rotation for DNSSEC. > > Could we find common problems and use the same/similar solution for > both problems? > > An extension for certmonger? Oddjob? Or a completely new daemon? > Certmonger already has a way to: 1) Check things periodically 2) Hand certs in different places 3) Run post op scripts IMO it is a good candidate but I would leave it to Nalin to chime in. -- 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 Tue Sep 3 16:36:57 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 03 Sep 2013 12:36:57 -0400 Subject: [Freeipa-devel] certmonger/oddjob for DNSSEC key maintenance In-Reply-To: <522495C3.8000107@redhat.com> References: <5204E103.1090109@redhat.com> <521CF250.3070803@redhat.com> <521CF85C.5050608@redhat.com> <521D1567.80401@redhat.com> <522495C3.8000107@redhat.com> Message-ID: <52261029.3030001@redhat.com> On 09/02/2013 09:42 AM, Petr Spacek wrote: > On 27.8.2013 23:08, Dmitri Pal wrote: >> On 08/27/2013 03:05 PM, Rob Crittenden wrote: >>> Dmitri Pal wrote: >>>> On 08/09/2013 08:30 AM, Petr Spacek wrote: >>>>> Hello, >>>>> >>>>> I would like to get opinions about key maintenance for DNSSEC. >>>>> >>>>> Problem summary: >>>>> - FreeIPA will support DNSSEC >>>>> - DNSSEC deployment requires <2,n> cryptographic keys for each DNS >>>>> zone (i.e. objects in LDAP) >>>>> - The same keys are shared by all FreeIPA servers >>>>> - Keys have limited lifetime and have to be re-generated on monthly >>>>> basics (in very first approximation, it will be configurable and the >>>>> interval will differ for different key types) >>>>> - The plan is to store keys in LDAP and let 'something' (i.e. >>>>> certmonger or oddjob?) to generate and store the new keys back into >>>>> LDAP >>>>> - There are command line tools for key-generation (dnssec-keygen from >>>>> the package bind-utils) >>>>> - We plan to select one super-master which will handle regular >>>>> key-regeneration (i.e. do the same as we do for special CA >>>>> certificates) >>>>> - Keys stored in LDAP will be encrypted somehow, most probably by >>>>> some >>>>> symmetric key shared among all IPA DNS servers >>>>> >>>>> Could certmonger or oddjob do key maintenance for us? I can imagine >>>>> something like this: >>>>> - watch some attributes in LDAP and wait until some key expires >>>>> - run dnssec-keygen utility >>>>> - read resulting keys and encrypt them with given 'master key' >>>>> - store resulting blobs in LDAP >>>>> - wait until another key reaches expiration timestamp >>>>> >>>>> It is simplified, because there will be multiple keys with different >>>>> lifetimes, but the idea is the same. All the gory details are in the >>>>> thread '[Freeipa-devel] DNSSEC support design considerations: key >>>>> material handling': >>>>> https://www.redhat.com/archives/freeipa-devel/2013-July/msg00129.html >>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html >>>>> >>>>> >>>>> Nalin and others, what do you think? Is certmonger or oddjob the >>>>> right >>>>> place to do something like this? >>>>> >>>>> Thank you for your time! >>>>> >>>> Was there any discussion of this mail? >>>> >>> >>> I think at least some of this was covered in another thread, "DNSSEC >>> support design considerations: key material handling" at >>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html >>> >>> rob >>> >>> >> Yes, I have found that thread though I have not found it to come to some >> conclusion and a firm plan. >> I will leave to Petr to summarize outstanding issues and repost them. > > All questions stated in the first e-mail in this thread are still open: > https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html > > There was no reply to these questions during my vacation, so I don't > have much to add at the moment. > > Nalin, please, could you provide your opinion? > How modular/extendible the certmonger is? > Does it make sense to add DNSSEC key-management to certmonger? > What about CA rotation problem? Can we share some algorithms (e.g. for > super-master election) between CA rotation and DNSSEC key rotation > mechanisms? > >> BTW I like the idea of masters being responsible for generating a subset >> of the keys as Loris suggested. > E-mail from Loris in archives: > https://www.redhat.com/archives/freeipa-devel/2013-August/msg00100.html > > The idea seems really nice and simple, but I'm afraid that there could > be some serious race conditions. > > - How will it work when topology changes? > - What if number of masters is > number of days in month? (=> > Auto-tune interval from month to smaller time period => Again, what > should we do after a topology change?) > - What we should do if topology was changed when a master was > disconnected from the rest of the network? (I.e. Link over WAN was > down at the moment of change.) What will happen after re-connection to > the topology? > > Example: > Time 0: Masters A, B; topology: A---B > Time 1: Master A have lost connection to master B > Time 2: Master C was added; topology: A ? B---C > Time 3 (Day 3): A + C did rotation at the same time > Time 4: Connection was restored; topology: A---B---C > > Now what? > > > I have a feeling that we need something like quorum protocol for > writes (only for sensitive operations like CA cert and DNSSEC key > rotations). > > http://en.wikipedia.org/wiki/Quorum_(distributed_computing) > > > The other question is how should we handle catastrophic situations > where more than half of masters were lost? (Two of three data centres > were blown by a tornado etc.) > It becomes more and more obvious that there is no simple solution that we can use out of box. Let us start with a single nominated server. If the server is lost the key rotation responsibility can be moved to some other server manually. Not optimal but at least the first step. The next step would be to be able to define alternative (failover) servers. Here is an example. Let us say we have masters A, B, C. In topology A - B - C. Master A is responsible for the key rotation B is the fail-over. The key rotation time would be in some way recorded in the replication agreement(s) between A & B. If at the moment of the scheduled rotation A <-> B connection is not present A would skip rotation and B would start rotation. If A comes back and connects to B (or connection is just restored) the replication will update the keys on A. If A is lost the keys are taken care of by B for itself and C. There will be a short window of race condition but IMO it can be mitigated. If A clock is behind B then if A managed to connect to B it would notice that B already started rotation. If B clock is behind and A connects to B before B started rotation A has to perform rotation still (sort of just made it case). Later if we want more complexity we can define subsets of the keys to renew and assign them to different replicas and then define failover servers per set. But this is all complexity we can add later when we see the real problems with the single server approach. Just 2c. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pvoborni at redhat.com Tue Sep 3 17:14:39 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 03 Sep 2013 19:14:39 +0200 Subject: [Freeipa-devel] [PATCH] 450 Fix RUV search scope in ipa-replica-manage Message-ID: <522618FF.8000803@redhat.com> The search had an incorrect scope and therefore it didn't find any RUV. This issue prevented removing of replica. https://fedorahosted.org/freeipa/ticket/3876 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0449-Fix-RUV-search-scope-in-ipa-replica-manage.patch Type: text/x-patch Size: 2437 bytes Desc: not available URL: From tjaalton at ubuntu.com Tue Sep 3 17:19:56 2013 From: tjaalton at ubuntu.com (Timo Aaltonen) Date: Tue, 03 Sep 2013 20:19:56 +0300 Subject: [Freeipa-devel] =?iso-8859-1?q?=5BPATCH=5D=A0Debian_client_suppor?= =?iso-8859-1?q?t?= In-Reply-To: <5225A517.80302@redhat.com> References: <5225066B.3010003@ubuntu.com> <5225A517.80302@redhat.com> Message-ID: <52261A3C.6060704@ubuntu.com> On 03.09.2013 12:00, Petr Viktorin wrote: > On 09/02/2013 11:43 PM, Timo Aaltonen wrote: >> >> This fixes https://fedorahosted.org/freeipa/ticket/1887 >> and >> https://fedorahosted.org/freeipa/ticket/2455 > > Thank you! > >> the first three patches fix some bugs in how python is used > > These look okay, I'll check when other build errors are fixed. > >> fourth patch checks if dbus is already running before trying to start it > > Please handle this in platform/debian/service.py. > > Is this only for D-Bus or do all start() methods for Debian need this? > If it's all of them, add it in DebianService.start. > If it's just D-Bus you'll want to make a special service there, like > DebianSSHService. > >> fifth fixes some compilation warnings > > Looks good to my eyes, perhaps a C expert can look at this one too. > I wonder why these warnings aren't enabled in our builds, though. > >> sixth finally adds the Debian platform module > > Please add copyright headers to the new files. > > in debian/auth.py:DebianAuthConfig.execute, you should use a dictionary > for env: > env = {'DEBCONF_FRONTEND': 'noninteractive'} > > You need to import ipautil to use ipautil.run in auth.py. This trips > pylint and prevents building the code for me. Do you include pylint in > your build procedure? > > platform/debian/auth.py: Git complains about a new blank line at EOF Ok I have the platform module patch updated, but testing is blocked because client join fails with '401' error (authorization). This worked fine in June, still investigating what's wrong this time.. thanks for the review! -- t From ayoung at redhat.com Tue Sep 3 17:39:30 2013 From: ayoung at redhat.com (Adam Young) Date: Tue, 03 Sep 2013 13:39:30 -0400 Subject: [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: <52261ED2.6030607@redhat.com> As a possible approach to getting things started, would it be possible to use Alien and a JEOS install to get the FreeIPA server running on a Debian system, and then work on converting over the dependencies one at a time? It seems like there are likely to be a series of Debian vs Fedora issues, WRT things like Python Path (lib vs lib64) and so forth. Also, the Dogtag install is a very Custom way of configuring a Tomcat App. It is likely to But up against the Debian packaging standards for Java Web Apps: http://dep.debian.net/deps/dep7/ One other difference between the Debian and Fedora philosophies is that, after apt-get install, you tend to have a deployed service, whereas the Yum/RPM based approach calls for a post deployment configuration stage. It sounds like the effort should be split along the Core FreeIPA work and the Dogtag work. We used to have a "Self-Signed" Ca approach for IPA that would be useful to have again. With the current "External CA" work, we might be able to do something similar: generate the certificates we need in a self-signed manner and provide them to the IPA server. That will let the Dogtag effort continue without holding up the rest of the work. On 09/01/2013 04: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.. >>> >>> 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 simo at redhat.com Tue Sep 3 20:01:36 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 03 Sep 2013 16:01:36 -0400 Subject: [Freeipa-devel] certmonger/oddjob for DNSSEC key maintenance In-Reply-To: <52261029.3030001@redhat.com> References: <5204E103.1090109@redhat.com> <521CF250.3070803@redhat.com> <521CF85C.5050608@redhat.com> <521D1567.80401@redhat.com> <522495C3.8000107@redhat.com> <52261029.3030001@redhat.com> Message-ID: <1378238496.13768.50.camel@willson.li.ssimo.org> On Tue, 2013-09-03 at 12:36 -0400, Dmitri Pal wrote: > On 09/02/2013 09:42 AM, Petr Spacek wrote: > > On 27.8.2013 23:08, Dmitri Pal wrote: > >> On 08/27/2013 03:05 PM, Rob Crittenden wrote: > >>> Dmitri Pal wrote: > >>>> On 08/09/2013 08:30 AM, Petr Spacek wrote: > >>>>> Hello, > >>>>> > >>>>> I would like to get opinions about key maintenance for DNSSEC. > >>>>> > >>>>> Problem summary: > >>>>> - FreeIPA will support DNSSEC > >>>>> - DNSSEC deployment requires <2,n> cryptographic keys for each DNS > >>>>> zone (i.e. objects in LDAP) > >>>>> - The same keys are shared by all FreeIPA servers > >>>>> - Keys have limited lifetime and have to be re-generated on monthly > >>>>> basics (in very first approximation, it will be configurable and the > >>>>> interval will differ for different key types) > >>>>> - The plan is to store keys in LDAP and let 'something' (i.e. > >>>>> certmonger or oddjob?) to generate and store the new keys back into > >>>>> LDAP > >>>>> - There are command line tools for key-generation (dnssec-keygen from > >>>>> the package bind-utils) > >>>>> - We plan to select one super-master which will handle regular > >>>>> key-regeneration (i.e. do the same as we do for special CA > >>>>> certificates) > >>>>> - Keys stored in LDAP will be encrypted somehow, most probably by > >>>>> some > >>>>> symmetric key shared among all IPA DNS servers > >>>>> > >>>>> Could certmonger or oddjob do key maintenance for us? I can imagine > >>>>> something like this: > >>>>> - watch some attributes in LDAP and wait until some key expires > >>>>> - run dnssec-keygen utility > >>>>> - read resulting keys and encrypt them with given 'master key' > >>>>> - store resulting blobs in LDAP > >>>>> - wait until another key reaches expiration timestamp > >>>>> > >>>>> It is simplified, because there will be multiple keys with different > >>>>> lifetimes, but the idea is the same. All the gory details are in the > >>>>> thread '[Freeipa-devel] DNSSEC support design considerations: key > >>>>> material handling': > >>>>> https://www.redhat.com/archives/freeipa-devel/2013-July/msg00129.html > >>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html > >>>>> > >>>>> > >>>>> Nalin and others, what do you think? Is certmonger or oddjob the > >>>>> right > >>>>> place to do something like this? > >>>>> > >>>>> Thank you for your time! > >>>>> > >>>> Was there any discussion of this mail? > >>>> > >>> > >>> I think at least some of this was covered in another thread, "DNSSEC > >>> support design considerations: key material handling" at > >>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html > >>> > >>> rob > >>> > >>> > >> Yes, I have found that thread though I have not found it to come to some > >> conclusion and a firm plan. > >> I will leave to Petr to summarize outstanding issues and repost them. > > > > All questions stated in the first e-mail in this thread are still open: > > https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html > > > > There was no reply to these questions during my vacation, so I don't > > have much to add at the moment. > > > > Nalin, please, could you provide your opinion? > > How modular/extendible the certmonger is? > > Does it make sense to add DNSSEC key-management to certmonger? > > What about CA rotation problem? Can we share some algorithms (e.g. for > > super-master election) between CA rotation and DNSSEC key rotation > > mechanisms? > > > >> BTW I like the idea of masters being responsible for generating a subset > >> of the keys as Loris suggested. > > E-mail from Loris in archives: > > https://www.redhat.com/archives/freeipa-devel/2013-August/msg00100.html > > > > The idea seems really nice and simple, but I'm afraid that there could > > be some serious race conditions. > > > > - How will it work when topology changes? > > - What if number of masters is > number of days in month? (=> > > Auto-tune interval from month to smaller time period => Again, what > > should we do after a topology change?) > > - What we should do if topology was changed when a master was > > disconnected from the rest of the network? (I.e. Link over WAN was > > down at the moment of change.) What will happen after re-connection to > > the topology? > > > > Example: > > Time 0: Masters A, B; topology: A---B > > Time 1: Master A have lost connection to master B > > Time 2: Master C was added; topology: A ? B---C > > Time 3 (Day 3): A + C did rotation at the same time > > Time 4: Connection was restored; topology: A---B---C > > > > Now what? > > > > > > I have a feeling that we need something like quorum protocol for > > writes (only for sensitive operations like CA cert and DNSSEC key > > rotations). > > > > http://en.wikipedia.org/wiki/Quorum_(distributed_computing) > > > > > > The other question is how should we handle catastrophic situations > > where more than half of masters were lost? (Two of three data centres > > were blown by a tornado etc.) > > > It becomes more and more obvious that there is no simple solution that > we can use out of box. > Let us start with a single nominated server. If the server is lost the > key rotation responsibility can be moved to some other server manually. > Not optimal but at least the first step. > > The next step would be to be able to define alternative (failover) > servers. Here is an example. > Let us say we have masters A, B, C. In topology A - B - C. > Master A is responsible for the key rotation B is the fail-over. > The key rotation time would be in some way recorded in the replication > agreement(s) between A & B. > If at the moment of the scheduled rotation A <-> B connection is not > present A would skip rotation and B would start rotation. If A comes > back and connects to B (or connection is just restored) the replication > will update the keys on A. If A is lost the keys are taken care of by B > for itself and C. > There will be a short window of race condition but IMO it can be > mitigated. If A clock is behind B then if A managed to connect to B it > would notice that B already started rotation. If B clock is behind and A > connects to B before B started rotation A has to perform rotation still > (sort of just made it case). > > Later if we want more complexity we can define subsets of the keys to > renew and assign them to different replicas and then define failover > servers per set. > But this is all complexity we can add later when we see the real > problems with the single server approach. Actually I thought about this for a while, and I think I have an idea about how to handle this for DNSSEC, (may not apply to other cases like CA). IIRC keys are generate well in advance from the time they are used and old keys and new keys are used side by side for a while, until old keys are finally expired and only new keys are around. This iso regulated by a series of date attributes that determine when keys are in used when they expire and so on. Now the idea I have is to add yet another step. Assume we have key "generation 1" (G1) in use and we approach the time generation 1 will expire and generation 2 (G2) is needed, and G2 is created X months in advance and all stuff is signed with both G1 and G2 for a period. Now if we have a pre-G2 period we can have a period of time when we can let multiple servers try to generate the G2 series, say 1 month in advance of the time they would normally be used to start signing anything. Then only after that 1 month they are actually put into services. How does this helps? Well it helps in that even if multiple servers generate keys and we have duplicates they have all the time to see that there are duplicates (because 2 server raced). now if e can keep a subsecond 'creation' timestamp for the new keys when replication goes around all servers can check and use only the set of keys that have been create first, and the servers that created the set of keys that lose the race will just remove the duplicates. given we have 1 month of time between the creation and the actual time keys will be used we have all the time to let servers sort out whether there are keys available or not and prune out duplicates. A diagram in case I have not been clear enough Assume servers A, B, C they all randomize (within a week) the time at which they will attempt to create new keys if it is time to and none are available already. Say the time come to create G2, A, B ,C each throw a dice and it turns out A will do it in 35000 seconds, B will do it in 40000 seconds, and C in 32000 seconds, so C should do it first and there should be enough time for the others to see that new keys popped up and just discard their attempts. However is A or C are temporarily disconnected they may still end up generating new keys, so we have G2-A and G2-B, once they get reconnected and replication flows again all servers see that instead of a single G2 set we have 2 G2 sets available G2-A created at timestamp X+35000 and G2-B created at timestamp X+32000, so all servers know they should ignore G2-A, and they all ignore it. When A comes around to realize this itself it will just go and delete the G2-A set. Only G2-B set is left and that is what will be the final official G2. If we give a week of time for this operation to go on I think it will be easy to resolve any race or temporary diconnection that may happen. Also because all server can attempt (within that week) to create keys there is no real single point of failure. HTH, please poke holes in my reasoning :) Simo. -- Simo Sorce * Red Hat, Inc * New York 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-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-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-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-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 pviktori at redhat.com Wed Sep 4 07:59:57 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 04 Sep 2013 09:59:57 +0200 Subject: [Freeipa-devel] [PATCHES] 0270-0271 Support for Pylint 1.0 In-Reply-To: <5211F39F.2010606@redhat.com> References: <5211F39F.2010606@redhat.com> Message-ID: <5226E87D.7000005@redhat.com> On 08/19/2013 12:29 PM, Petr Viktorin wrote: > Hello, > The first patch fixes a minor problem that Pylint 1.0 finds in our code. > > The second patch makes make-lint compatible with Pylint 1.0. It contains > a workaround for a Pylint bug; before pushing this we should wait for a > while to see if a fixed Pylint is released. > A fixed version of Pylint was released, bug workarounds are no longer necessary. Updated patches attached. https://fedorahosted.org/freeipa/ticket/3865 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0270.2-Remove-__all__-specifications-in-ipaclient-and-ipase.patch Type: text/x-patch Size: 1661 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0271.2-Make-make-lint-compatible-with-Pylint-1.0.patch Type: text/x-patch Size: 2305 bytes Desc: not available URL: From pviktori at redhat.com Wed Sep 4 09:08:48 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 04 Sep 2013 11:08:48 +0200 Subject: [Freeipa-devel] [PATCH] 0060 Add warning when uninstalling active replica In-Reply-To: <5225E0BB.9070404@redhat.com> References: <521F6F27.2010704@redhat.com> <5224B7A5.5070700@redhat.com> <5224BAF0.2070101@redhat.com> <522580DC.8010903@redhat.com> <5225E0BB.9070404@redhat.com> Message-ID: <5226F8A0.1000508@redhat.com> On 09/03/2013 03:14 PM, Ana Krivokapic wrote: > On 09/03/2013 08:25 AM, Martin Kosek wrote: >> On 09/02/2013 06:21 PM, Tomas Babej wrote: >>> On 09/02/2013 06:07 PM, Petr Viktorin wrote: >>>> On 08/29/2013 05:56 PM, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3867. >>>>> >>>> Patch works well. >>>> It's temping to restart the discussion about how to wrap text output from >>>> installation tools. Wrapping at 60 characters because it looks better in the >>>> code seems suboptimal. >>>> Does anyone remember if we established some guideline last time this came up? >>>> >>>> >>> I'm not sure if I'm missing something, but do we need a guideline here? >>> >>> I don't see any reason why not have best of the both worlds, using print as a >>> function we can wrap the text inside the parenthesis >>> with no effect on the output whatsoever. Or use print statement, but enclose >>> the text in parenthesis. Or use backslash. >>> >> Yes. But whatever we choose, we need to make sure that the resulting text is >> wrapped the same to avoid inconsistent output. >> >> IMO we should do our best to keep the text wrapped at 80 characters in new or >> updated texts. So I would prefer to have Ana's patch refactored a bit, to >> change wrapping of the resulting from 60 to 80 characters. >> >> Martin > > Text is wrapped at 80 characters in the updated patch. > Thanks, ACK, push?d to: master: 7959f3ee1e38ce10e2f32a51c3fa0f45f949f06f ipa-3-3: 95d3d3d60b9e981bcd192ed11242d58873fd09bf -- Petr? From pviktori at redhat.com Wed Sep 4 10:48:27 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 04 Sep 2013 12:48:27 +0200 Subject: [Freeipa-devel] [PATCH] 450 Fix RUV search scope in ipa-replica-manage In-Reply-To: <522618FF.8000803@redhat.com> References: <522618FF.8000803@redhat.com> Message-ID: <52270FFB.6010203@redhat.com> On 09/03/2013 07:14 PM, Petr Vobornik wrote: > The search had an incorrect scope and therefore it didn't find any RUV. > > This issue prevented removing of replica. > > https://fedorahosted.org/freeipa/ticket/3876 > Thank you! ACK, pushed to master: f312d725102f903f67a2db688d3dce94cf84e77d ipa-3-3: 93b314da42efb79951b008cbbc8b0df0fc8c7dbe -- Petr? From dpal at redhat.com Wed Sep 4 13:08:41 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Sep 2013 09:08:41 -0400 Subject: [Freeipa-devel] certmonger/oddjob for DNSSEC key maintenance In-Reply-To: <1378238496.13768.50.camel@willson.li.ssimo.org> References: <5204E103.1090109@redhat.com> <521CF250.3070803@redhat.com> <521CF85C.5050608@redhat.com> <521D1567.80401@redhat.com> <522495C3.8000107@redhat.com> <52261029.3030001@redhat.com> <1378238496.13768.50.camel@willson.li.ssimo.org> Message-ID: <522730D9.2020102@redhat.com> On 09/03/2013 04:01 PM, Simo Sorce wrote: > On Tue, 2013-09-03 at 12:36 -0400, Dmitri Pal wrote: >> On 09/02/2013 09:42 AM, Petr Spacek wrote: >>> On 27.8.2013 23:08, Dmitri Pal wrote: >>>> On 08/27/2013 03:05 PM, Rob Crittenden wrote: >>>>> Dmitri Pal wrote: >>>>>> On 08/09/2013 08:30 AM, Petr Spacek wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I would like to get opinions about key maintenance for DNSSEC. >>>>>>> >>>>>>> Problem summary: >>>>>>> - FreeIPA will support DNSSEC >>>>>>> - DNSSEC deployment requires <2,n> cryptographic keys for each DNS >>>>>>> zone (i.e. objects in LDAP) >>>>>>> - The same keys are shared by all FreeIPA servers >>>>>>> - Keys have limited lifetime and have to be re-generated on monthly >>>>>>> basics (in very first approximation, it will be configurable and the >>>>>>> interval will differ for different key types) >>>>>>> - The plan is to store keys in LDAP and let 'something' (i.e. >>>>>>> certmonger or oddjob?) to generate and store the new keys back into >>>>>>> LDAP >>>>>>> - There are command line tools for key-generation (dnssec-keygen from >>>>>>> the package bind-utils) >>>>>>> - We plan to select one super-master which will handle regular >>>>>>> key-regeneration (i.e. do the same as we do for special CA >>>>>>> certificates) >>>>>>> - Keys stored in LDAP will be encrypted somehow, most probably by >>>>>>> some >>>>>>> symmetric key shared among all IPA DNS servers >>>>>>> >>>>>>> Could certmonger or oddjob do key maintenance for us? I can imagine >>>>>>> something like this: >>>>>>> - watch some attributes in LDAP and wait until some key expires >>>>>>> - run dnssec-keygen utility >>>>>>> - read resulting keys and encrypt them with given 'master key' >>>>>>> - store resulting blobs in LDAP >>>>>>> - wait until another key reaches expiration timestamp >>>>>>> >>>>>>> It is simplified, because there will be multiple keys with different >>>>>>> lifetimes, but the idea is the same. All the gory details are in the >>>>>>> thread '[Freeipa-devel] DNSSEC support design considerations: key >>>>>>> material handling': >>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-July/msg00129.html >>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html >>>>>>> >>>>>>> >>>>>>> Nalin and others, what do you think? Is certmonger or oddjob the >>>>>>> right >>>>>>> place to do something like this? >>>>>>> >>>>>>> Thank you for your time! >>>>>>> >>>>>> Was there any discussion of this mail? >>>>>> >>>>> I think at least some of this was covered in another thread, "DNSSEC >>>>> support design considerations: key material handling" at >>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html >>>>> >>>>> rob >>>>> >>>>> >>>> Yes, I have found that thread though I have not found it to come to some >>>> conclusion and a firm plan. >>>> I will leave to Petr to summarize outstanding issues and repost them. >>> All questions stated in the first e-mail in this thread are still open: >>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html >>> >>> There was no reply to these questions during my vacation, so I don't >>> have much to add at the moment. >>> >>> Nalin, please, could you provide your opinion? >>> How modular/extendible the certmonger is? >>> Does it make sense to add DNSSEC key-management to certmonger? >>> What about CA rotation problem? Can we share some algorithms (e.g. for >>> super-master election) between CA rotation and DNSSEC key rotation >>> mechanisms? >>> >>>> BTW I like the idea of masters being responsible for generating a subset >>>> of the keys as Loris suggested. >>> E-mail from Loris in archives: >>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00100.html >>> >>> The idea seems really nice and simple, but I'm afraid that there could >>> be some serious race conditions. >>> >>> - How will it work when topology changes? >>> - What if number of masters is > number of days in month? (=> >>> Auto-tune interval from month to smaller time period => Again, what >>> should we do after a topology change?) >>> - What we should do if topology was changed when a master was >>> disconnected from the rest of the network? (I.e. Link over WAN was >>> down at the moment of change.) What will happen after re-connection to >>> the topology? >>> >>> Example: >>> Time 0: Masters A, B; topology: A---B >>> Time 1: Master A have lost connection to master B >>> Time 2: Master C was added; topology: A ? B---C >>> Time 3 (Day 3): A + C did rotation at the same time >>> Time 4: Connection was restored; topology: A---B---C >>> >>> Now what? >>> >>> >>> I have a feeling that we need something like quorum protocol for >>> writes (only for sensitive operations like CA cert and DNSSEC key >>> rotations). >>> >>> http://en.wikipedia.org/wiki/Quorum_(distributed_computing) >>> >>> >>> The other question is how should we handle catastrophic situations >>> where more than half of masters were lost? (Two of three data centres >>> were blown by a tornado etc.) >>> >> It becomes more and more obvious that there is no simple solution that >> we can use out of box. >> Let us start with a single nominated server. If the server is lost the >> key rotation responsibility can be moved to some other server manually. >> Not optimal but at least the first step. >> >> The next step would be to be able to define alternative (failover) >> servers. Here is an example. >> Let us say we have masters A, B, C. In topology A - B - C. >> Master A is responsible for the key rotation B is the fail-over. >> The key rotation time would be in some way recorded in the replication >> agreement(s) between A & B. >> If at the moment of the scheduled rotation A <-> B connection is not >> present A would skip rotation and B would start rotation. If A comes >> back and connects to B (or connection is just restored) the replication >> will update the keys on A. If A is lost the keys are taken care of by B >> for itself and C. >> There will be a short window of race condition but IMO it can be >> mitigated. If A clock is behind B then if A managed to connect to B it >> would notice that B already started rotation. If B clock is behind and A >> connects to B before B started rotation A has to perform rotation still >> (sort of just made it case). >> >> Later if we want more complexity we can define subsets of the keys to >> renew and assign them to different replicas and then define failover >> servers per set. >> But this is all complexity we can add later when we see the real >> problems with the single server approach. > Actually I thought about this for a while, and I think I have an idea > about how to handle this for DNSSEC, (may not apply to other cases like > CA). > > IIRC keys are generate well in advance from the time they are used and > old keys and new keys are used side by side for a while, until old keys > are finally expired and only new keys are around. > > This iso regulated by a series of date attributes that determine when > keys are in used when they expire and so on. > > Now the idea I have is to add yet another step. > > Assume we have key "generation 1" (G1) in use and we approach the time > generation 1 will expire and generation 2 (G2) is needed, and G2 is > created X months in advance and all stuff is signed with both G1 and G2 > for a period. > > Now if we have a pre-G2 period we can have a period of time when we can > let multiple servers try to generate the G2 series, say 1 month in > advance of the time they would normally be used to start signing > anything. Then only after that 1 month they are actually put into > services. > > How does this helps? Well it helps in that even if multiple servers > generate keys and we have duplicates they have all the time to see that > there are duplicates (because 2 server raced). > now if e can keep a subsecond 'creation' timestamp for the new keys when > replication goes around all servers can check and use only the set of > keys that have been create first, and the servers that created the set > of keys that lose the race will just remove the duplicates. > given we have 1 month of time between the creation and the actual time > keys will be used we have all the time to let servers sort out whether > there are keys available or not and prune out duplicates. > > A diagram in case I have not been clear enough > > > Assume servers A, B, C they all randomize (within a week) the time at > which they will attempt to create new keys if it is time to and none are > available already. > > Say the time come to create G2, A, B ,C each throw a dice and it turns > out A will do it in 35000 seconds, B will do it in 40000 seconds, and C > in 32000 seconds, so C should do it first and there should be enough > time for the others to see that new keys popped up and just discard > their attempts. > > However is A or C are temporarily disconnected they may still end up > generating new keys, so we have G2-A and G2-B, once they get reconnected > and replication flows again all servers see that instead of a single G2 > set we have 2 G2 sets available > G2-A created at timestamp X+35000 and G2-B created at timestamp X+32000, > so all servers know they should ignore G2-A, and they all ignore it. > When A comes around to realize this itself it will just go and delete > the G2-A set. Only G2-B set is left and that is what will be the final > official G2. > > If we give a week of time for this operation to go on I think it will be > easy to resolve any race or temporary diconnection that may happen. > Also because all server can attempt (within that week) to create keys > there is no real single point of failure. > > HTH, > please poke holes in my reasoning :) > > Simo. > Reasonable just have couple comments. If there are many keys and many replicas the chance would be that there will be a lot of load. Generating keys is costly computation wise. Replication is costly too. Also you assume that topology works fine. I am mostly concerned about the case when some replication is not working and data from one part of the topology is not replicated to another. The concern is that people would not notice that things are not replicating. So if there is a problem and we let all these key to be generated all over the place it would be pretty hard to untie this knot later. I would actually suggest that if a replica X needs the keys in a month from moment A and the keys have not arrived in 3 first days after moment A and this replica is not entitled to generate keys it should start sending messages to admin. That way there will be enough time for admin to sort out what is wrong and nominate another replica to generate the keys if needed. There should be command as simple as: ipa dnssec-keymanager-set that would make the mentioned replica the key generator. There can be other commands like ipa dnssec-keymanager-info Appointed server: Keys store: Last time keys generated: Next time keys need to be generated: <...> ... IMO in this case we need to help admin to see that there is a problem and provide tools to easily mitigate it rather than try to solve it ourselves and build a complex algorythm. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From akrivoka at redhat.com Wed Sep 4 13:28:06 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 04 Sep 2013 15:28:06 +0200 Subject: [Freeipa-devel] [PATCH] 0062 Replace ntpdate calls with ntpd In-Reply-To: <5225C4EC.8060605@redhat.com> References: <5224A94F.6070605@redhat.com> <5225C4EC.8060605@redhat.com> Message-ID: <52273566.2040405@redhat.com> On 09/03/2013 01:15 PM, Petr Viktorin wrote: > On 09/02/2013 05:05 PM, Ana Krivokapic wrote: >> Hello, >> >> This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/3797. >> > > Thanks! I have a question. > >> - # retry several times -- logic follows /etc/init.d/ntpdate >> - # implementation >> + # retry several times >> for retry in range(0, 3): > > What's the reason to try several times? Is it still necessary with ntpd? > I checked /etc/init.d/ntpdate in RHEL (since Fedora doesn't have it any more) > and I didn't see any repeating. > I am not sure what the reason for trying several times was. My testing didn't reveal any need for that, but I left the code there mainly because it returns immediately after successful sync, so there is no harm. Attached is a version of the patch without the repetition. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0062-02-Replace-ntpdate-calls-with-ntpd.patch Type: text/x-patch Size: 2142 bytes Desc: not available URL: From dpal at redhat.com Wed Sep 4 13:33:10 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Sep 2013 09:33:10 -0400 Subject: [Freeipa-devel] certmonger/oddjob for DNSSEC key maintenance In-Reply-To: <522730D9.2020102@redhat.com> References: <5204E103.1090109@redhat.com> <521CF250.3070803@redhat.com> <521CF85C.5050608@redhat.com> <521D1567.80401@redhat.com> <522495C3.8000107@redhat.com> <52261029.3030001@redhat.com> <1378238496.13768.50.camel@willson.li.ssimo.org> <522730D9.2020102@redhat.com> Message-ID: <52273696.1030808@redhat.com> On 09/04/2013 09:08 AM, Dmitri Pal wrote: > On 09/03/2013 04:01 PM, Simo Sorce wrote: >> On Tue, 2013-09-03 at 12:36 -0400, Dmitri Pal wrote: >>> On 09/02/2013 09:42 AM, Petr Spacek wrote: >>>> On 27.8.2013 23:08, Dmitri Pal wrote: >>>>> On 08/27/2013 03:05 PM, Rob Crittenden wrote: >>>>>> Dmitri Pal wrote: >>>>>>> On 08/09/2013 08:30 AM, Petr Spacek wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I would like to get opinions about key maintenance for DNSSEC. >>>>>>>> >>>>>>>> Problem summary: >>>>>>>> - FreeIPA will support DNSSEC >>>>>>>> - DNSSEC deployment requires <2,n> cryptographic keys for each DNS >>>>>>>> zone (i.e. objects in LDAP) >>>>>>>> - The same keys are shared by all FreeIPA servers >>>>>>>> - Keys have limited lifetime and have to be re-generated on monthly >>>>>>>> basics (in very first approximation, it will be configurable and the >>>>>>>> interval will differ for different key types) >>>>>>>> - The plan is to store keys in LDAP and let 'something' (i.e. >>>>>>>> certmonger or oddjob?) to generate and store the new keys back into >>>>>>>> LDAP >>>>>>>> - There are command line tools for key-generation (dnssec-keygen from >>>>>>>> the package bind-utils) >>>>>>>> - We plan to select one super-master which will handle regular >>>>>>>> key-regeneration (i.e. do the same as we do for special CA >>>>>>>> certificates) >>>>>>>> - Keys stored in LDAP will be encrypted somehow, most probably by >>>>>>>> some >>>>>>>> symmetric key shared among all IPA DNS servers >>>>>>>> >>>>>>>> Could certmonger or oddjob do key maintenance for us? I can imagine >>>>>>>> something like this: >>>>>>>> - watch some attributes in LDAP and wait until some key expires >>>>>>>> - run dnssec-keygen utility >>>>>>>> - read resulting keys and encrypt them with given 'master key' >>>>>>>> - store resulting blobs in LDAP >>>>>>>> - wait until another key reaches expiration timestamp >>>>>>>> >>>>>>>> It is simplified, because there will be multiple keys with different >>>>>>>> lifetimes, but the idea is the same. All the gory details are in the >>>>>>>> thread '[Freeipa-devel] DNSSEC support design considerations: key >>>>>>>> material handling': >>>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-July/msg00129.html >>>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html >>>>>>>> >>>>>>>> >>>>>>>> Nalin and others, what do you think? Is certmonger or oddjob the >>>>>>>> right >>>>>>>> place to do something like this? >>>>>>>> >>>>>>>> Thank you for your time! >>>>>>>> >>>>>>> Was there any discussion of this mail? >>>>>>> >>>>>> I think at least some of this was covered in another thread, "DNSSEC >>>>>> support design considerations: key material handling" at >>>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html >>>>>> >>>>>> rob >>>>>> >>>>>> >>>>> Yes, I have found that thread though I have not found it to come to some >>>>> conclusion and a firm plan. >>>>> I will leave to Petr to summarize outstanding issues and repost them. >>>> All questions stated in the first e-mail in this thread are still open: >>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html >>>> >>>> There was no reply to these questions during my vacation, so I don't >>>> have much to add at the moment. >>>> >>>> Nalin, please, could you provide your opinion? >>>> How modular/extendible the certmonger is? >>>> Does it make sense to add DNSSEC key-management to certmonger? >>>> What about CA rotation problem? Can we share some algorithms (e.g. for >>>> super-master election) between CA rotation and DNSSEC key rotation >>>> mechanisms? >>>> >>>>> BTW I like the idea of masters being responsible for generating a subset >>>>> of the keys as Loris suggested. >>>> E-mail from Loris in archives: >>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00100.html >>>> >>>> The idea seems really nice and simple, but I'm afraid that there could >>>> be some serious race conditions. >>>> >>>> - How will it work when topology changes? >>>> - What if number of masters is > number of days in month? (=> >>>> Auto-tune interval from month to smaller time period => Again, what >>>> should we do after a topology change?) >>>> - What we should do if topology was changed when a master was >>>> disconnected from the rest of the network? (I.e. Link over WAN was >>>> down at the moment of change.) What will happen after re-connection to >>>> the topology? >>>> >>>> Example: >>>> Time 0: Masters A, B; topology: A---B >>>> Time 1: Master A have lost connection to master B >>>> Time 2: Master C was added; topology: A ? B---C >>>> Time 3 (Day 3): A + C did rotation at the same time >>>> Time 4: Connection was restored; topology: A---B---C >>>> >>>> Now what? >>>> >>>> >>>> I have a feeling that we need something like quorum protocol for >>>> writes (only for sensitive operations like CA cert and DNSSEC key >>>> rotations). >>>> >>>> http://en.wikipedia.org/wiki/Quorum_(distributed_computing) >>>> >>>> >>>> The other question is how should we handle catastrophic situations >>>> where more than half of masters were lost? (Two of three data centres >>>> were blown by a tornado etc.) >>>> >>> It becomes more and more obvious that there is no simple solution that >>> we can use out of box. >>> Let us start with a single nominated server. If the server is lost the >>> key rotation responsibility can be moved to some other server manually. >>> Not optimal but at least the first step. >>> >>> The next step would be to be able to define alternative (failover) >>> servers. Here is an example. >>> Let us say we have masters A, B, C. In topology A - B - C. >>> Master A is responsible for the key rotation B is the fail-over. >>> The key rotation time would be in some way recorded in the replication >>> agreement(s) between A & B. >>> If at the moment of the scheduled rotation A <-> B connection is not >>> present A would skip rotation and B would start rotation. If A comes >>> back and connects to B (or connection is just restored) the replication >>> will update the keys on A. If A is lost the keys are taken care of by B >>> for itself and C. >>> There will be a short window of race condition but IMO it can be >>> mitigated. If A clock is behind B then if A managed to connect to B it >>> would notice that B already started rotation. If B clock is behind and A >>> connects to B before B started rotation A has to perform rotation still >>> (sort of just made it case). >>> >>> Later if we want more complexity we can define subsets of the keys to >>> renew and assign them to different replicas and then define failover >>> servers per set. >>> But this is all complexity we can add later when we see the real >>> problems with the single server approach. >> Actually I thought about this for a while, and I think I have an idea >> about how to handle this for DNSSEC, (may not apply to other cases like >> CA). >> >> IIRC keys are generate well in advance from the time they are used and >> old keys and new keys are used side by side for a while, until old keys >> are finally expired and only new keys are around. >> >> This iso regulated by a series of date attributes that determine when >> keys are in used when they expire and so on. >> >> Now the idea I have is to add yet another step. >> >> Assume we have key "generation 1" (G1) in use and we approach the time >> generation 1 will expire and generation 2 (G2) is needed, and G2 is >> created X months in advance and all stuff is signed with both G1 and G2 >> for a period. >> >> Now if we have a pre-G2 period we can have a period of time when we can >> let multiple servers try to generate the G2 series, say 1 month in >> advance of the time they would normally be used to start signing >> anything. Then only after that 1 month they are actually put into >> services. >> >> How does this helps? Well it helps in that even if multiple servers >> generate keys and we have duplicates they have all the time to see that >> there are duplicates (because 2 server raced). >> now if e can keep a subsecond 'creation' timestamp for the new keys when >> replication goes around all servers can check and use only the set of >> keys that have been create first, and the servers that created the set >> of keys that lose the race will just remove the duplicates. >> given we have 1 month of time between the creation and the actual time >> keys will be used we have all the time to let servers sort out whether >> there are keys available or not and prune out duplicates. >> >> A diagram in case I have not been clear enough >> >> >> Assume servers A, B, C they all randomize (within a week) the time at >> which they will attempt to create new keys if it is time to and none are >> available already. >> >> Say the time come to create G2, A, B ,C each throw a dice and it turns >> out A will do it in 35000 seconds, B will do it in 40000 seconds, and C >> in 32000 seconds, so C should do it first and there should be enough >> time for the others to see that new keys popped up and just discard >> their attempts. >> >> However is A or C are temporarily disconnected they may still end up >> generating new keys, so we have G2-A and G2-B, once they get reconnected >> and replication flows again all servers see that instead of a single G2 >> set we have 2 G2 sets available >> G2-A created at timestamp X+35000 and G2-B created at timestamp X+32000, >> so all servers know they should ignore G2-A, and they all ignore it. >> When A comes around to realize this itself it will just go and delete >> the G2-A set. Only G2-B set is left and that is what will be the final >> official G2. >> >> If we give a week of time for this operation to go on I think it will be >> easy to resolve any race or temporary diconnection that may happen. >> Also because all server can attempt (within that week) to create keys >> there is no real single point of failure. >> >> HTH, >> please poke holes in my reasoning :) >> >> Simo. >> > Reasonable just have couple comments. > If there are many keys and many replicas the chance would be that there > will be a lot of load. Generating keys is costly computation wise. > Replication is costly too. > Also you assume that topology works fine. I am mostly concerned about > the case when some replication is not working and data from one part of > the topology is not replicated to another. The concern is that people > would not notice that things are not replicating. So if there is a > problem and we let all these key to be generated all over the place it > would be pretty hard to untie this knot later. > > I would actually suggest that if a replica X needs the keys in a month > from moment A and the keys have not arrived in 3 first days after moment > A and this replica is not entitled to generate keys it should start > sending messages to admin. That way there will be enough time for admin > to sort out what is wrong and nominate another replica to generate the > keys if needed. There should be command as simple as: > > ipa dnssec-keymanager-set > > that would make the mentioned replica the key generator. > There can be other commands like > > ipa dnssec-keymanager-info > > Appointed server: > Keys store: > Last time keys generated: > Next time keys need to be generated: <...> > ... > > > > > IMO in this case we need to help admin to see that there is a problem > and provide tools to easily mitigate it rather than try to solve it > ourselves and build a complex algorythm. > Thinking even more about this. May be we should start with the command that would be something like: ipa health This command would detect the topology, try to connect to all replicas check that they are all up and running, replicating, nothing is stuck and report any issues. The output of the command can be sent somewhere or as a mail to admin. Then it can be run periodically as a part of cron on couple servers and if there is any problem admin would know quite soon. Then admin would know things like: 1) The CRL generating server is down/unreachable 2) The DNSSEC key generating server is down/unreachable 3) Some CAs are unreachable 4) The server that rotates certificates is down/unreachable 5) The server that does AD sync is down/unreachable There might be other things. IMO we have enough sinlge point of failure services already. Adding DNSSEC key generation to that set is not a big deal but the utility like this would really go a long way making IPA more usable, manageable and useful. Should I file an RFE? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Wed Sep 4 13:50:11 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 4 Sep 2013 16:50:11 +0300 Subject: [Freeipa-devel] certmonger/oddjob for DNSSEC key maintenance In-Reply-To: <52273696.1030808@redhat.com> References: <5204E103.1090109@redhat.com> <521CF250.3070803@redhat.com> <521CF85C.5050608@redhat.com> <521D1567.80401@redhat.com> <522495C3.8000107@redhat.com> <52261029.3030001@redhat.com> <1378238496.13768.50.camel@willson.li.ssimo.org> <522730D9.2020102@redhat.com> <52273696.1030808@redhat.com> Message-ID: <20130904135011.GJ21212@redhat.com> On Wed, 04 Sep 2013, Dmitri Pal wrote: >On 09/04/2013 09:08 AM, Dmitri Pal wrote: >> On 09/03/2013 04:01 PM, Simo Sorce wrote: >>> On Tue, 2013-09-03 at 12:36 -0400, Dmitri Pal wrote: >>>> On 09/02/2013 09:42 AM, Petr Spacek wrote: >>>>> On 27.8.2013 23:08, Dmitri Pal wrote: >>>>>> On 08/27/2013 03:05 PM, Rob Crittenden wrote: >>>>>>> Dmitri Pal wrote: >>>>>>>> On 08/09/2013 08:30 AM, Petr Spacek wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I would like to get opinions about key maintenance for DNSSEC. >>>>>>>>> >>>>>>>>> Problem summary: >>>>>>>>> - FreeIPA will support DNSSEC >>>>>>>>> - DNSSEC deployment requires <2,n> cryptographic keys for each DNS >>>>>>>>> zone (i.e. objects in LDAP) >>>>>>>>> - The same keys are shared by all FreeIPA servers >>>>>>>>> - Keys have limited lifetime and have to be re-generated on monthly >>>>>>>>> basics (in very first approximation, it will be configurable and the >>>>>>>>> interval will differ for different key types) >>>>>>>>> - The plan is to store keys in LDAP and let 'something' (i.e. >>>>>>>>> certmonger or oddjob?) to generate and store the new keys back into >>>>>>>>> LDAP >>>>>>>>> - There are command line tools for key-generation (dnssec-keygen from >>>>>>>>> the package bind-utils) >>>>>>>>> - We plan to select one super-master which will handle regular >>>>>>>>> key-regeneration (i.e. do the same as we do for special CA >>>>>>>>> certificates) >>>>>>>>> - Keys stored in LDAP will be encrypted somehow, most probably by >>>>>>>>> some >>>>>>>>> symmetric key shared among all IPA DNS servers >>>>>>>>> >>>>>>>>> Could certmonger or oddjob do key maintenance for us? I can imagine >>>>>>>>> something like this: >>>>>>>>> - watch some attributes in LDAP and wait until some key expires >>>>>>>>> - run dnssec-keygen utility >>>>>>>>> - read resulting keys and encrypt them with given 'master key' >>>>>>>>> - store resulting blobs in LDAP >>>>>>>>> - wait until another key reaches expiration timestamp >>>>>>>>> >>>>>>>>> It is simplified, because there will be multiple keys with different >>>>>>>>> lifetimes, but the idea is the same. All the gory details are in the >>>>>>>>> thread '[Freeipa-devel] DNSSEC support design considerations: key >>>>>>>>> material handling': >>>>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-July/msg00129.html >>>>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html >>>>>>>>> >>>>>>>>> >>>>>>>>> Nalin and others, what do you think? Is certmonger or oddjob the >>>>>>>>> right >>>>>>>>> place to do something like this? >>>>>>>>> >>>>>>>>> Thank you for your time! >>>>>>>>> >>>>>>>> Was there any discussion of this mail? >>>>>>>> >>>>>>> I think at least some of this was covered in another thread, "DNSSEC >>>>>>> support design considerations: key material handling" at >>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html >>>>>>> >>>>>>> rob >>>>>>> >>>>>>> >>>>>> Yes, I have found that thread though I have not found it to come to some >>>>>> conclusion and a firm plan. >>>>>> I will leave to Petr to summarize outstanding issues and repost them. >>>>> All questions stated in the first e-mail in this thread are still open: >>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html >>>>> >>>>> There was no reply to these questions during my vacation, so I don't >>>>> have much to add at the moment. >>>>> >>>>> Nalin, please, could you provide your opinion? >>>>> How modular/extendible the certmonger is? >>>>> Does it make sense to add DNSSEC key-management to certmonger? >>>>> What about CA rotation problem? Can we share some algorithms (e.g. for >>>>> super-master election) between CA rotation and DNSSEC key rotation >>>>> mechanisms? >>>>> >>>>>> BTW I like the idea of masters being responsible for generating a subset >>>>>> of the keys as Loris suggested. >>>>> E-mail from Loris in archives: >>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00100.html >>>>> >>>>> The idea seems really nice and simple, but I'm afraid that there could >>>>> be some serious race conditions. >>>>> >>>>> - How will it work when topology changes? >>>>> - What if number of masters is > number of days in month? (=> >>>>> Auto-tune interval from month to smaller time period => Again, what >>>>> should we do after a topology change?) >>>>> - What we should do if topology was changed when a master was >>>>> disconnected from the rest of the network? (I.e. Link over WAN was >>>>> down at the moment of change.) What will happen after re-connection to >>>>> the topology? >>>>> >>>>> Example: >>>>> Time 0: Masters A, B; topology: A---B >>>>> Time 1: Master A have lost connection to master B >>>>> Time 2: Master C was added; topology: A ? B---C >>>>> Time 3 (Day 3): A + C did rotation at the same time >>>>> Time 4: Connection was restored; topology: A---B---C >>>>> >>>>> Now what? >>>>> >>>>> >>>>> I have a feeling that we need something like quorum protocol for >>>>> writes (only for sensitive operations like CA cert and DNSSEC key >>>>> rotations). >>>>> >>>>> http://en.wikipedia.org/wiki/Quorum_(distributed_computing) >>>>> >>>>> >>>>> The other question is how should we handle catastrophic situations >>>>> where more than half of masters were lost? (Two of three data centres >>>>> were blown by a tornado etc.) >>>>> >>>> It becomes more and more obvious that there is no simple solution that >>>> we can use out of box. >>>> Let us start with a single nominated server. If the server is lost the >>>> key rotation responsibility can be moved to some other server manually. >>>> Not optimal but at least the first step. >>>> >>>> The next step would be to be able to define alternative (failover) >>>> servers. Here is an example. >>>> Let us say we have masters A, B, C. In topology A - B - C. >>>> Master A is responsible for the key rotation B is the fail-over. >>>> The key rotation time would be in some way recorded in the replication >>>> agreement(s) between A & B. >>>> If at the moment of the scheduled rotation A <-> B connection is not >>>> present A would skip rotation and B would start rotation. If A comes >>>> back and connects to B (or connection is just restored) the replication >>>> will update the keys on A. If A is lost the keys are taken care of by B >>>> for itself and C. >>>> There will be a short window of race condition but IMO it can be >>>> mitigated. If A clock is behind B then if A managed to connect to B it >>>> would notice that B already started rotation. If B clock is behind and A >>>> connects to B before B started rotation A has to perform rotation still >>>> (sort of just made it case). >>>> >>>> Later if we want more complexity we can define subsets of the keys to >>>> renew and assign them to different replicas and then define failover >>>> servers per set. >>>> But this is all complexity we can add later when we see the real >>>> problems with the single server approach. >>> Actually I thought about this for a while, and I think I have an idea >>> about how to handle this for DNSSEC, (may not apply to other cases like >>> CA). >>> >>> IIRC keys are generate well in advance from the time they are used and >>> old keys and new keys are used side by side for a while, until old keys >>> are finally expired and only new keys are around. >>> >>> This iso regulated by a series of date attributes that determine when >>> keys are in used when they expire and so on. >>> >>> Now the idea I have is to add yet another step. >>> >>> Assume we have key "generation 1" (G1) in use and we approach the time >>> generation 1 will expire and generation 2 (G2) is needed, and G2 is >>> created X months in advance and all stuff is signed with both G1 and G2 >>> for a period. >>> >>> Now if we have a pre-G2 period we can have a period of time when we can >>> let multiple servers try to generate the G2 series, say 1 month in >>> advance of the time they would normally be used to start signing >>> anything. Then only after that 1 month they are actually put into >>> services. >>> >>> How does this helps? Well it helps in that even if multiple servers >>> generate keys and we have duplicates they have all the time to see that >>> there are duplicates (because 2 server raced). >>> now if e can keep a subsecond 'creation' timestamp for the new keys when >>> replication goes around all servers can check and use only the set of >>> keys that have been create first, and the servers that created the set >>> of keys that lose the race will just remove the duplicates. >>> given we have 1 month of time between the creation and the actual time >>> keys will be used we have all the time to let servers sort out whether >>> there are keys available or not and prune out duplicates. >>> >>> A diagram in case I have not been clear enough >>> >>> >>> Assume servers A, B, C they all randomize (within a week) the time at >>> which they will attempt to create new keys if it is time to and none are >>> available already. >>> >>> Say the time come to create G2, A, B ,C each throw a dice and it turns >>> out A will do it in 35000 seconds, B will do it in 40000 seconds, and C >>> in 32000 seconds, so C should do it first and there should be enough >>> time for the others to see that new keys popped up and just discard >>> their attempts. >>> >>> However is A or C are temporarily disconnected they may still end up >>> generating new keys, so we have G2-A and G2-B, once they get reconnected >>> and replication flows again all servers see that instead of a single G2 >>> set we have 2 G2 sets available >>> G2-A created at timestamp X+35000 and G2-B created at timestamp X+32000, >>> so all servers know they should ignore G2-A, and they all ignore it. >>> When A comes around to realize this itself it will just go and delete >>> the G2-A set. Only G2-B set is left and that is what will be the final >>> official G2. >>> >>> If we give a week of time for this operation to go on I think it will be >>> easy to resolve any race or temporary diconnection that may happen. >>> Also because all server can attempt (within that week) to create keys >>> there is no real single point of failure. >>> >>> HTH, >>> please poke holes in my reasoning :) >>> >>> Simo. >>> >> Reasonable just have couple comments. >> If there are many keys and many replicas the chance would be that there >> will be a lot of load. Generating keys is costly computation wise. >> Replication is costly too. >> Also you assume that topology works fine. I am mostly concerned about >> the case when some replication is not working and data from one part of >> the topology is not replicated to another. The concern is that people >> would not notice that things are not replicating. So if there is a >> problem and we let all these key to be generated all over the place it >> would be pretty hard to untie this knot later. >> >> I would actually suggest that if a replica X needs the keys in a month >> from moment A and the keys have not arrived in 3 first days after moment >> A and this replica is not entitled to generate keys it should start >> sending messages to admin. That way there will be enough time for admin >> to sort out what is wrong and nominate another replica to generate the >> keys if needed. There should be command as simple as: >> >> ipa dnssec-keymanager-set >> >> that would make the mentioned replica the key generator. >> There can be other commands like >> >> ipa dnssec-keymanager-info >> >> Appointed server: >> Keys store: >> Last time keys generated: >> Next time keys need to be generated: <...> >> ... >> >> >> >> >> IMO in this case we need to help admin to see that there is a problem >> and provide tools to easily mitigate it rather than try to solve it >> ourselves and build a complex algorythm. >> >Thinking even more about this. >May be we should start with the command that would be something like: > >ipa health > >This command would detect the topology, try to connect to all replicas >check that they are all up and running, replicating, nothing is stuck >and report any issues. >The output of the command can be sent somewhere or as a mail to admin. > >Then it can be run periodically as a part of cron on couple servers and >if there is any problem admin would know quite soon. >Then admin would know things like: >1) The CRL generating server is down/unreachable >2) The DNSSEC key generating server is down/unreachable >3) Some CAs are unreachable >4) The server that rotates certificates is down/unreachable >5) The server that does AD sync is down/unreachable > >There might be other things. >IMO we have enough sinlge point of failure services already. Adding >DNSSEC key generation to that set is not a big deal but the utility like >this would really go a long way making IPA more usable, manageable and >useful. > >Should I file an RFE? The tool you describe above should be able to perform operations on the master. it is in general better not to put master-specific operations into a client tool that could be run from an arbitrary host where ipa admin tools are installed. What about plugging the functionality into ipa-advise? ipa-advise health-check-{cert|replication|dnssec|...} -- / Alexander Bokovoy From akrivoka at redhat.com Wed Sep 4 14:13:53 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 04 Sep 2013 16:13:53 +0200 Subject: [Freeipa-devel] [PATCH] 0064 Fix invocations of FileError in ipa-client-install Message-ID: <52274021.808@redhat.com> Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3758. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0064-Fix-invocations-of-FileError-in-ipa-client-install.patch Type: text/x-patch Size: 2897 bytes Desc: not available URL: From pspacek at redhat.com Wed Sep 4 14:17:53 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 04 Sep 2013 16:17:53 +0200 Subject: [Freeipa-devel] certmonger/oddjob for DNSSEC key maintenance In-Reply-To: <20130904135011.GJ21212@redhat.com> References: <5204E103.1090109@redhat.com> <521CF250.3070803@redhat.com> <521CF85C.5050608@redhat.com> <521D1567.80401@redhat.com> <522495C3.8000107@redhat.com> <52261029.3030001@redhat.com> <1378238496.13768.50.camel@willson.li.ssimo.org> <522730D9.2020102@redhat.com> <52273696.1030808@redhat.com> <20130904135011.GJ21212@redhat.com> Message-ID: <52274111.3000805@redhat.com> On 4.9.2013 15:50, Alexander Bokovoy wrote: > On Wed, 04 Sep 2013, Dmitri Pal wrote: >> On 09/04/2013 09:08 AM, Dmitri Pal wrote: >>> On 09/03/2013 04:01 PM, Simo Sorce wrote: >>>> On Tue, 2013-09-03 at 12:36 -0400, Dmitri Pal wrote: >>>>> On 09/02/2013 09:42 AM, Petr Spacek wrote: >>>>>> On 27.8.2013 23:08, Dmitri Pal wrote: >>>>>>> On 08/27/2013 03:05 PM, Rob Crittenden wrote: >>>>>>>> Dmitri Pal wrote: >>>>>>>>> On 08/09/2013 08:30 AM, Petr Spacek wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I would like to get opinions about key maintenance for DNSSEC. >>>>>>>>>> >>>>>>>>>> Problem summary: >>>>>>>>>> - FreeIPA will support DNSSEC >>>>>>>>>> - DNSSEC deployment requires <2,n> cryptographic keys for each DNS >>>>>>>>>> zone (i.e. objects in LDAP) >>>>>>>>>> - The same keys are shared by all FreeIPA servers >>>>>>>>>> - Keys have limited lifetime and have to be re-generated on monthly >>>>>>>>>> basics (in very first approximation, it will be configurable and the >>>>>>>>>> interval will differ for different key types) >>>>>>>>>> - The plan is to store keys in LDAP and let 'something' (i.e. >>>>>>>>>> certmonger or oddjob?) to generate and store the new keys back into >>>>>>>>>> LDAP >>>>>>>>>> - There are command line tools for key-generation (dnssec-keygen from >>>>>>>>>> the package bind-utils) >>>>>>>>>> - We plan to select one super-master which will handle regular >>>>>>>>>> key-regeneration (i.e. do the same as we do for special CA >>>>>>>>>> certificates) >>>>>>>>>> - Keys stored in LDAP will be encrypted somehow, most probably by >>>>>>>>>> some >>>>>>>>>> symmetric key shared among all IPA DNS servers >>>>>>>>>> >>>>>>>>>> Could certmonger or oddjob do key maintenance for us? I can imagine >>>>>>>>>> something like this: >>>>>>>>>> - watch some attributes in LDAP and wait until some key expires >>>>>>>>>> - run dnssec-keygen utility >>>>>>>>>> - read resulting keys and encrypt them with given 'master key' >>>>>>>>>> - store resulting blobs in LDAP >>>>>>>>>> - wait until another key reaches expiration timestamp >>>>>>>>>> >>>>>>>>>> It is simplified, because there will be multiple keys with different >>>>>>>>>> lifetimes, but the idea is the same. All the gory details are in the >>>>>>>>>> thread '[Freeipa-devel] DNSSEC support design considerations: key >>>>>>>>>> material handling': >>>>>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-July/msg00129.html >>>>>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Nalin and others, what do you think? Is certmonger or oddjob the >>>>>>>>>> right >>>>>>>>>> place to do something like this? >>>>>>>>>> >>>>>>>>>> Thank you for your time! >>>>>>>>>> >>>>>>>>> Was there any discussion of this mail? >>>>>>>>> >>>>>>>> I think at least some of this was covered in another thread, "DNSSEC >>>>>>>> support design considerations: key material handling" at >>>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>>> >>>>>>> Yes, I have found that thread though I have not found it to come to some >>>>>>> conclusion and a firm plan. >>>>>>> I will leave to Petr to summarize outstanding issues and repost them. >>>>>> All questions stated in the first e-mail in this thread are still open: >>>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html >>>>>> >>>>>> There was no reply to these questions during my vacation, so I don't >>>>>> have much to add at the moment. >>>>>> >>>>>> Nalin, please, could you provide your opinion? >>>>>> How modular/extendible the certmonger is? >>>>>> Does it make sense to add DNSSEC key-management to certmonger? >>>>>> What about CA rotation problem? Can we share some algorithms (e.g. for >>>>>> super-master election) between CA rotation and DNSSEC key rotation >>>>>> mechanisms? >>>>>> >>>>>>> BTW I like the idea of masters being responsible for generating a subset >>>>>>> of the keys as Loris suggested. >>>>>> E-mail from Loris in archives: >>>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00100.html >>>>>> >>>>>> The idea seems really nice and simple, but I'm afraid that there could >>>>>> be some serious race conditions. >>>>>> >>>>>> - How will it work when topology changes? >>>>>> - What if number of masters is > number of days in month? (=> >>>>>> Auto-tune interval from month to smaller time period => Again, what >>>>>> should we do after a topology change?) >>>>>> - What we should do if topology was changed when a master was >>>>>> disconnected from the rest of the network? (I.e. Link over WAN was >>>>>> down at the moment of change.) What will happen after re-connection to >>>>>> the topology? >>>>>> >>>>>> Example: >>>>>> Time 0: Masters A, B; topology: A---B >>>>>> Time 1: Master A have lost connection to master B >>>>>> Time 2: Master C was added; topology: A ? B---C >>>>>> Time 3 (Day 3): A + C did rotation at the same time >>>>>> Time 4: Connection was restored; topology: A---B---C >>>>>> >>>>>> Now what? >>>>>> >>>>>> >>>>>> I have a feeling that we need something like quorum protocol for >>>>>> writes (only for sensitive operations like CA cert and DNSSEC key >>>>>> rotations). >>>>>> >>>>>> http://en.wikipedia.org/wiki/Quorum_(distributed_computing) >>>>>> >>>>>> >>>>>> The other question is how should we handle catastrophic situations >>>>>> where more than half of masters were lost? (Two of three data centres >>>>>> were blown by a tornado etc.) >>>>>> >>>>> It becomes more and more obvious that there is no simple solution that >>>>> we can use out of box. >>>>> Let us start with a single nominated server. If the server is lost the >>>>> key rotation responsibility can be moved to some other server manually. >>>>> Not optimal but at least the first step. >>>>> >>>>> The next step would be to be able to define alternative (failover) >>>>> servers. Here is an example. >>>>> Let us say we have masters A, B, C. In topology A - B - C. >>>>> Master A is responsible for the key rotation B is the fail-over. >>>>> The key rotation time would be in some way recorded in the replication >>>>> agreement(s) between A & B. >>>>> If at the moment of the scheduled rotation A <-> B connection is not >>>>> present A would skip rotation and B would start rotation. If A comes >>>>> back and connects to B (or connection is just restored) the replication >>>>> will update the keys on A. If A is lost the keys are taken care of by B >>>>> for itself and C. >>>>> There will be a short window of race condition but IMO it can be >>>>> mitigated. If A clock is behind B then if A managed to connect to B it >>>>> would notice that B already started rotation. If B clock is behind and A >>>>> connects to B before B started rotation A has to perform rotation still >>>>> (sort of just made it case). >>>>> >>>>> Later if we want more complexity we can define subsets of the keys to >>>>> renew and assign them to different replicas and then define failover >>>>> servers per set. >>>>> But this is all complexity we can add later when we see the real >>>>> problems with the single server approach. >>>> Actually I thought about this for a while, and I think I have an idea >>>> about how to handle this for DNSSEC, (may not apply to other cases like >>>> CA). >>>> >>>> IIRC keys are generate well in advance from the time they are used and >>>> old keys and new keys are used side by side for a while, until old keys >>>> are finally expired and only new keys are around. >>>> >>>> This iso regulated by a series of date attributes that determine when >>>> keys are in used when they expire and so on. >>>> >>>> Now the idea I have is to add yet another step. >>>> >>>> Assume we have key "generation 1" (G1) in use and we approach the time >>>> generation 1 will expire and generation 2 (G2) is needed, and G2 is >>>> created X months in advance and all stuff is signed with both G1 and G2 >>>> for a period. >>>> >>>> Now if we have a pre-G2 period we can have a period of time when we can >>>> let multiple servers try to generate the G2 series, say 1 month in >>>> advance of the time they would normally be used to start signing >>>> anything. Then only after that 1 month they are actually put into >>>> services. >>>> >>>> How does this helps? Well it helps in that even if multiple servers >>>> generate keys and we have duplicates they have all the time to see that >>>> there are duplicates (because 2 server raced). >>>> now if e can keep a subsecond 'creation' timestamp for the new keys when >>>> replication goes around all servers can check and use only the set of >>>> keys that have been create first, and the servers that created the set >>>> of keys that lose the race will just remove the duplicates. >>>> given we have 1 month of time between the creation and the actual time >>>> keys will be used we have all the time to let servers sort out whether >>>> there are keys available or not and prune out duplicates. >>>> >>>> A diagram in case I have not been clear enough >>>> >>>> >>>> Assume servers A, B, C they all randomize (within a week) the time at >>>> which they will attempt to create new keys if it is time to and none are >>>> available already. >>>> >>>> Say the time come to create G2, A, B ,C each throw a dice and it turns >>>> out A will do it in 35000 seconds, B will do it in 40000 seconds, and C >>>> in 32000 seconds, so C should do it first and there should be enough >>>> time for the others to see that new keys popped up and just discard >>>> their attempts. >>>> >>>> However is A or C are temporarily disconnected they may still end up >>>> generating new keys, so we have G2-A and G2-B, once they get reconnected >>>> and replication flows again all servers see that instead of a single G2 >>>> set we have 2 G2 sets available >>>> G2-A created at timestamp X+35000 and G2-B created at timestamp X+32000, >>>> so all servers know they should ignore G2-A, and they all ignore it. >>>> When A comes around to realize this itself it will just go and delete >>>> the G2-A set. Only G2-B set is left and that is what will be the final >>>> official G2. >>>> >>>> If we give a week of time for this operation to go on I think it will be >>>> easy to resolve any race or temporary diconnection that may happen. >>>> Also because all server can attempt (within that week) to create keys >>>> there is no real single point of failure. >>>> >>>> HTH, >>>> please poke holes in my reasoning :) >>>> >>>> Simo. >>>> >>> Reasonable just have couple comments. >>> If there are many keys and many replicas the chance would be that there >>> will be a lot of load. Generating keys is costly computation wise. >>> Replication is costly too. >>> Also you assume that topology works fine. I am mostly concerned about >>> the case when some replication is not working and data from one part of >>> the topology is not replicated to another. The concern is that people >>> would not notice that things are not replicating. So if there is a >>> problem and we let all these key to be generated all over the place it >>> would be pretty hard to untie this knot later. >>> >>> I would actually suggest that if a replica X needs the keys in a month >>> from moment A and the keys have not arrived in 3 first days after moment >>> A and this replica is not entitled to generate keys it should start >>> sending messages to admin. That way there will be enough time for admin >>> to sort out what is wrong and nominate another replica to generate the >>> keys if needed. There should be command as simple as: >>> >>> ipa dnssec-keymanager-set >>> >>> that would make the mentioned replica the key generator. >>> There can be other commands like >>> >>> ipa dnssec-keymanager-info >>> >>> Appointed server: >>> Keys store: >>> Last time keys generated: >>> Next time keys need to be generated: <...> >>> ... >>> >>> >>> >>> >>> IMO in this case we need to help admin to see that there is a problem >>> and provide tools to easily mitigate it rather than try to solve it >>> ourselves and build a complex algorythm. >>> >> Thinking even more about this. >> May be we should start with the command that would be something like: >> >> ipa health >> >> This command would detect the topology, try to connect to all replicas >> check that they are all up and running, replicating, nothing is stuck >> and report any issues. >> The output of the command can be sent somewhere or as a mail to admin. >> >> Then it can be run periodically as a part of cron on couple servers and >> if there is any problem admin would know quite soon. >> Then admin would know things like: >> 1) The CRL generating server is down/unreachable >> 2) The DNSSEC key generating server is down/unreachable >> 3) Some CAs are unreachable >> 4) The server that rotates certificates is down/unreachable >> 5) The server that does AD sync is down/unreachable >> >> There might be other things. >> IMO we have enough sinlge point of failure services already. Adding >> DNSSEC key generation to that set is not a big deal but the utility like >> this would really go a long way making IPA more usable, manageable and >> useful. >> >> Should I file an RFE? > The tool you describe above should be able to perform operations on the master. > it is in general better not to put master-specific operations into a > client tool that could be run from an arbitrary host where ipa admin > tools are installed. > > What about plugging the functionality into ipa-advise? > > ipa-advise health-check-{cert|replication|dnssec|...} I agree with health check idea and also with the modular approach proposed by Alexander. Side note: I think that the tool should have an option to enable machine parse-able output, because it would allow to third parties to connect it to monitoring systems like Zabbix etc. Today I spent some time with analysis of Simo's proposal and I wasn't able to find hole up to now. It seems as good idea and added code complexity should be relatively small. For that reason I vote for implementing it before we declare DNSSEC 'stable'. Don't forget that whole infrastructure will break if DNSSEC keys are not updated in time and that the rotation happens several times each month. -- Petr^2 Spacek From akrivoka at redhat.com Wed Sep 4 16:27:54 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 04 Sep 2013 18:27:54 +0200 Subject: [Freeipa-devel] [PATCH] 0065 Follow tmpfiles.d packaging guidelines Message-ID: <52275F8A.4080105@redhat.com> Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3881. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0065-Follow-tmpfiles.d-packaging-guidelines.patch Type: text/x-patch Size: 1784 bytes Desc: not available URL: From dpal at redhat.com Wed Sep 4 16:53:03 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Sep 2013 12:53:03 -0400 Subject: [Freeipa-devel] certmonger/oddjob for DNSSEC key maintenance In-Reply-To: <52274111.3000805@redhat.com> References: <5204E103.1090109@redhat.com> <521CF250.3070803@redhat.com> <521CF85C.5050608@redhat.com> <521D1567.80401@redhat.com> <522495C3.8000107@redhat.com> <52261029.3030001@redhat.com> <1378238496.13768.50.camel@willson.li.ssimo.org> <522730D9.2020102@redhat.com> <52273696.1030808@redhat.com> <20130904135011.GJ21212@redhat.com> <52274111.3000805@redhat.com> Message-ID: <5227656F.2020103@redhat.com> On 09/04/2013 10:17 AM, Petr Spacek wrote: > On 4.9.2013 15:50, Alexander Bokovoy wrote: >> On Wed, 04 Sep 2013, Dmitri Pal wrote: >>> On 09/04/2013 09:08 AM, Dmitri Pal wrote: >>>> On 09/03/2013 04:01 PM, Simo Sorce wrote: >>>>> On Tue, 2013-09-03 at 12:36 -0400, Dmitri Pal wrote: >>>>>> On 09/02/2013 09:42 AM, Petr Spacek wrote: >>>>>>> On 27.8.2013 23:08, Dmitri Pal wrote: >>>>>>>> On 08/27/2013 03:05 PM, Rob Crittenden wrote: >>>>>>>>> Dmitri Pal wrote: >>>>>>>>>> On 08/09/2013 08:30 AM, Petr Spacek wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> I would like to get opinions about key maintenance for DNSSEC. >>>>>>>>>>> >>>>>>>>>>> Problem summary: >>>>>>>>>>> - FreeIPA will support DNSSEC >>>>>>>>>>> - DNSSEC deployment requires <2,n> cryptographic keys for >>>>>>>>>>> each DNS >>>>>>>>>>> zone (i.e. objects in LDAP) >>>>>>>>>>> - The same keys are shared by all FreeIPA servers >>>>>>>>>>> - Keys have limited lifetime and have to be re-generated on >>>>>>>>>>> monthly >>>>>>>>>>> basics (in very first approximation, it will be configurable >>>>>>>>>>> and the >>>>>>>>>>> interval will differ for different key types) >>>>>>>>>>> - The plan is to store keys in LDAP and let 'something' (i.e. >>>>>>>>>>> certmonger or oddjob?) to generate and store the new keys >>>>>>>>>>> back into >>>>>>>>>>> LDAP >>>>>>>>>>> - There are command line tools for key-generation >>>>>>>>>>> (dnssec-keygen from >>>>>>>>>>> the package bind-utils) >>>>>>>>>>> - We plan to select one super-master which will handle regular >>>>>>>>>>> key-regeneration (i.e. do the same as we do for special CA >>>>>>>>>>> certificates) >>>>>>>>>>> - Keys stored in LDAP will be encrypted somehow, most >>>>>>>>>>> probably by >>>>>>>>>>> some >>>>>>>>>>> symmetric key shared among all IPA DNS servers >>>>>>>>>>> >>>>>>>>>>> Could certmonger or oddjob do key maintenance for us? I can >>>>>>>>>>> imagine >>>>>>>>>>> something like this: >>>>>>>>>>> - watch some attributes in LDAP and wait until some key expires >>>>>>>>>>> - run dnssec-keygen utility >>>>>>>>>>> - read resulting keys and encrypt them with given 'master key' >>>>>>>>>>> - store resulting blobs in LDAP >>>>>>>>>>> - wait until another key reaches expiration timestamp >>>>>>>>>>> >>>>>>>>>>> It is simplified, because there will be multiple keys with >>>>>>>>>>> different >>>>>>>>>>> lifetimes, but the idea is the same. All the gory details >>>>>>>>>>> are in the >>>>>>>>>>> thread '[Freeipa-devel] DNSSEC support design >>>>>>>>>>> considerations: key >>>>>>>>>>> material handling': >>>>>>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-July/msg00129.html >>>>>>>>>>> >>>>>>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Nalin and others, what do you think? Is certmonger or oddjob >>>>>>>>>>> the >>>>>>>>>>> right >>>>>>>>>>> place to do something like this? >>>>>>>>>>> >>>>>>>>>>> Thank you for your time! >>>>>>>>>>> >>>>>>>>>> Was there any discussion of this mail? >>>>>>>>>> >>>>>>>>> I think at least some of this was covered in another thread, >>>>>>>>> "DNSSEC >>>>>>>>> support design considerations: key material handling" at >>>>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html >>>>>>>>> >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>>> >>>>>>>> Yes, I have found that thread though I have not found it to >>>>>>>> come to some >>>>>>>> conclusion and a firm plan. >>>>>>>> I will leave to Petr to summarize outstanding issues and repost >>>>>>>> them. >>>>>>> All questions stated in the first e-mail in this thread are >>>>>>> still open: >>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html >>>>>>> >>>>>>> >>>>>>> There was no reply to these questions during my vacation, so I >>>>>>> don't >>>>>>> have much to add at the moment. >>>>>>> >>>>>>> Nalin, please, could you provide your opinion? >>>>>>> How modular/extendible the certmonger is? >>>>>>> Does it make sense to add DNSSEC key-management to certmonger? >>>>>>> What about CA rotation problem? Can we share some algorithms >>>>>>> (e.g. for >>>>>>> super-master election) between CA rotation and DNSSEC key rotation >>>>>>> mechanisms? >>>>>>> >>>>>>>> BTW I like the idea of masters being responsible for generating >>>>>>>> a subset >>>>>>>> of the keys as Loris suggested. >>>>>>> E-mail from Loris in archives: >>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00100.html >>>>>>> >>>>>>> >>>>>>> The idea seems really nice and simple, but I'm afraid that there >>>>>>> could >>>>>>> be some serious race conditions. >>>>>>> >>>>>>> - How will it work when topology changes? >>>>>>> - What if number of masters is > number of days in month? (=> >>>>>>> Auto-tune interval from month to smaller time period => Again, what >>>>>>> should we do after a topology change?) >>>>>>> - What we should do if topology was changed when a master was >>>>>>> disconnected from the rest of the network? (I.e. Link over WAN was >>>>>>> down at the moment of change.) What will happen after >>>>>>> re-connection to >>>>>>> the topology? >>>>>>> >>>>>>> Example: >>>>>>> Time 0: Masters A, B; topology: A---B >>>>>>> Time 1: Master A have lost connection to master B >>>>>>> Time 2: Master C was added; topology: A ? B---C >>>>>>> Time 3 (Day 3): A + C did rotation at the same time >>>>>>> Time 4: Connection was restored; topology: A---B---C >>>>>>> >>>>>>> Now what? >>>>>>> >>>>>>> >>>>>>> I have a feeling that we need something like quorum protocol for >>>>>>> writes (only for sensitive operations like CA cert and DNSSEC key >>>>>>> rotations). >>>>>>> >>>>>>> http://en.wikipedia.org/wiki/Quorum_(distributed_computing) >>>>>>> >>>>>>> >>>>>>> The other question is how should we handle catastrophic situations >>>>>>> where more than half of masters were lost? (Two of three data >>>>>>> centres >>>>>>> were blown by a tornado etc.) >>>>>>> >>>>>> It becomes more and more obvious that there is no simple solution >>>>>> that >>>>>> we can use out of box. >>>>>> Let us start with a single nominated server. If the server is >>>>>> lost the >>>>>> key rotation responsibility can be moved to some other server >>>>>> manually. >>>>>> Not optimal but at least the first step. >>>>>> >>>>>> The next step would be to be able to define alternative (failover) >>>>>> servers. Here is an example. >>>>>> Let us say we have masters A, B, C. In topology A - B - C. >>>>>> Master A is responsible for the key rotation B is the fail-over. >>>>>> The key rotation time would be in some way recorded in the >>>>>> replication >>>>>> agreement(s) between A & B. >>>>>> If at the moment of the scheduled rotation A <-> B connection is not >>>>>> present A would skip rotation and B would start rotation. If A comes >>>>>> back and connects to B (or connection is just restored) the >>>>>> replication >>>>>> will update the keys on A. If A is lost the keys are taken care >>>>>> of by B >>>>>> for itself and C. >>>>>> There will be a short window of race condition but IMO it can be >>>>>> mitigated. If A clock is behind B then if A managed to connect to >>>>>> B it >>>>>> would notice that B already started rotation. If B clock is >>>>>> behind and A >>>>>> connects to B before B started rotation A has to perform rotation >>>>>> still >>>>>> (sort of just made it case). >>>>>> >>>>>> Later if we want more complexity we can define subsets of the >>>>>> keys to >>>>>> renew and assign them to different replicas and then define failover >>>>>> servers per set. >>>>>> But this is all complexity we can add later when we see the real >>>>>> problems with the single server approach. >>>>> Actually I thought about this for a while, and I think I have an idea >>>>> about how to handle this for DNSSEC, (may not apply to other cases >>>>> like >>>>> CA). >>>>> >>>>> IIRC keys are generate well in advance from the time they are used >>>>> and >>>>> old keys and new keys are used side by side for a while, until old >>>>> keys >>>>> are finally expired and only new keys are around. >>>>> >>>>> This iso regulated by a series of date attributes that determine when >>>>> keys are in used when they expire and so on. >>>>> >>>>> Now the idea I have is to add yet another step. >>>>> >>>>> Assume we have key "generation 1" (G1) in use and we approach the >>>>> time >>>>> generation 1 will expire and generation 2 (G2) is needed, and G2 is >>>>> created X months in advance and all stuff is signed with both G1 >>>>> and G2 >>>>> for a period. >>>>> >>>>> Now if we have a pre-G2 period we can have a period of time when >>>>> we can >>>>> let multiple servers try to generate the G2 series, say 1 month in >>>>> advance of the time they would normally be used to start signing >>>>> anything. Then only after that 1 month they are actually put into >>>>> services. >>>>> >>>>> How does this helps? Well it helps in that even if multiple servers >>>>> generate keys and we have duplicates they have all the time to see >>>>> that >>>>> there are duplicates (because 2 server raced). >>>>> now if e can keep a subsecond 'creation' timestamp for the new >>>>> keys when >>>>> replication goes around all servers can check and use only the set of >>>>> keys that have been create first, and the servers that created the >>>>> set >>>>> of keys that lose the race will just remove the duplicates. >>>>> given we have 1 month of time between the creation and the actual >>>>> time >>>>> keys will be used we have all the time to let servers sort out >>>>> whether >>>>> there are keys available or not and prune out duplicates. >>>>> >>>>> A diagram in case I have not been clear enough >>>>> >>>>> >>>>> Assume servers A, B, C they all randomize (within a week) the time at >>>>> which they will attempt to create new keys if it is time to and >>>>> none are >>>>> available already. >>>>> >>>>> Say the time come to create G2, A, B ,C each throw a dice and it >>>>> turns >>>>> out A will do it in 35000 seconds, B will do it in 40000 seconds, >>>>> and C >>>>> in 32000 seconds, so C should do it first and there should be enough >>>>> time for the others to see that new keys popped up and just discard >>>>> their attempts. >>>>> >>>>> However is A or C are temporarily disconnected they may still end up >>>>> generating new keys, so we have G2-A and G2-B, once they get >>>>> reconnected >>>>> and replication flows again all servers see that instead of a >>>>> single G2 >>>>> set we have 2 G2 sets available >>>>> G2-A created at timestamp X+35000 and G2-B created at timestamp >>>>> X+32000, >>>>> so all servers know they should ignore G2-A, and they all ignore it. >>>>> When A comes around to realize this itself it will just go and delete >>>>> the G2-A set. Only G2-B set is left and that is what will be the >>>>> final >>>>> official G2. >>>>> >>>>> If we give a week of time for this operation to go on I think it >>>>> will be >>>>> easy to resolve any race or temporary diconnection that may happen. >>>>> Also because all server can attempt (within that week) to create keys >>>>> there is no real single point of failure. >>>>> >>>>> HTH, >>>>> please poke holes in my reasoning :) >>>>> >>>>> Simo. >>>>> >>>> Reasonable just have couple comments. >>>> If there are many keys and many replicas the chance would be that >>>> there >>>> will be a lot of load. Generating keys is costly computation wise. >>>> Replication is costly too. >>>> Also you assume that topology works fine. I am mostly concerned about >>>> the case when some replication is not working and data from one >>>> part of >>>> the topology is not replicated to another. The concern is that people >>>> would not notice that things are not replicating. So if there is a >>>> problem and we let all these key to be generated all over the place it >>>> would be pretty hard to untie this knot later. >>>> >>>> I would actually suggest that if a replica X needs the keys in a month >>>> from moment A and the keys have not arrived in 3 first days after >>>> moment >>>> A and this replica is not entitled to generate keys it should start >>>> sending messages to admin. That way there will be enough time for >>>> admin >>>> to sort out what is wrong and nominate another replica to generate the >>>> keys if needed. There should be command as simple as: >>>> >>>> ipa dnssec-keymanager-set >>>> >>>> that would make the mentioned replica the key generator. >>>> There can be other commands like >>>> >>>> ipa dnssec-keymanager-info >>>> >>>> Appointed server: >>>> Keys store: >>>> Last time keys generated: >>>> Next time keys need to be generated: <...> >>>> ... >>>> >>>> >>>> >>>> >>>> IMO in this case we need to help admin to see that there is a problem >>>> and provide tools to easily mitigate it rather than try to solve it >>>> ourselves and build a complex algorythm. >>>> >>> Thinking even more about this. >>> May be we should start with the command that would be something like: >>> >>> ipa health >>> >>> This command would detect the topology, try to connect to all replicas >>> check that they are all up and running, replicating, nothing is stuck >>> and report any issues. >>> The output of the command can be sent somewhere or as a mail to admin. >>> >>> Then it can be run periodically as a part of cron on couple servers and >>> if there is any problem admin would know quite soon. >>> Then admin would know things like: >>> 1) The CRL generating server is down/unreachable >>> 2) The DNSSEC key generating server is down/unreachable >>> 3) Some CAs are unreachable >>> 4) The server that rotates certificates is down/unreachable >>> 5) The server that does AD sync is down/unreachable >>> >>> There might be other things. >>> IMO we have enough sinlge point of failure services already. Adding >>> DNSSEC key generation to that set is not a big deal but the utility >>> like >>> this would really go a long way making IPA more usable, manageable and >>> useful. >>> >>> Should I file an RFE? >> The tool you describe above should be able to perform operations on >> the master. >> it is in general better not to put master-specific operations into a >> client tool that could be run from an arbitrary host where ipa admin >> tools are installed. >> >> What about plugging the functionality into ipa-advise? >> >> ipa-advise health-check-{cert|replication|dnssec|...} > > I agree with health check idea and also with the modular approach > proposed by Alexander. I assume you mean "a" master rather than "the" master :-) Running this command on any master would be fine. If it makes sense as an ipa-advise option I am fine with it too. If others agree then let us open a ticket to add this functionality to ipa-advise > > Side note: I think that the tool should have an option to enable > machine parse-able output, because it would allow to third parties to > connect it to monitoring systems like Zabbix etc. Yes. Agree. > > Today I spent some time with analysis of Simo's proposal and I wasn't > able to find hole up to now. It seems as good idea and added code > complexity should be relatively small. For that reason I vote for > implementing it before we declare DNSSEC 'stable'. Should we treat this functionality independent from the tool? I am concerned with volume of the load and replication. I think it should be an option - single master generates keys or you can enable others to generate the keys and if they are enabled to generate the keys they would follow the algorithm proposed by Simo. > > Don't forget that whole infrastructure will break if DNSSEC keys are > not updated in time and that the rotation happens several times each > month. > True but it is better if it is clear why it breaks and easy to fix and does not require complex procedure to get back online. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Wed Sep 4 17:17:01 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 04 Sep 2013 13:17:01 -0400 Subject: [Freeipa-devel] certmonger/oddjob for DNSSEC key maintenance In-Reply-To: <522730D9.2020102@redhat.com> References: <5204E103.1090109@redhat.com> <521CF250.3070803@redhat.com> <521CF85C.5050608@redhat.com> <521D1567.80401@redhat.com> <522495C3.8000107@redhat.com> <52261029.3030001@redhat.com> <1378238496.13768.50.camel@willson.li.ssimo.org> <522730D9.2020102@redhat.com> Message-ID: <1378315021.13768.108.camel@willson.li.ssimo.org> On Wed, 2013-09-04 at 09:08 -0400, Dmitri Pal wrote: > On 09/03/2013 04:01 PM, Simo Sorce wrote: > > On Tue, 2013-09-03 at 12:36 -0400, Dmitri Pal wrote: > >> On 09/02/2013 09:42 AM, Petr Spacek wrote: > >>> On 27.8.2013 23:08, Dmitri Pal wrote: > >>>> On 08/27/2013 03:05 PM, Rob Crittenden wrote: > >>>>> Dmitri Pal wrote: > >>>>>> On 08/09/2013 08:30 AM, Petr Spacek wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> I would like to get opinions about key maintenance for DNSSEC. > >>>>>>> > >>>>>>> Problem summary: > >>>>>>> - FreeIPA will support DNSSEC > >>>>>>> - DNSSEC deployment requires <2,n> cryptographic keys for each DNS > >>>>>>> zone (i.e. objects in LDAP) > >>>>>>> - The same keys are shared by all FreeIPA servers > >>>>>>> - Keys have limited lifetime and have to be re-generated on monthly > >>>>>>> basics (in very first approximation, it will be configurable and the > >>>>>>> interval will differ for different key types) > >>>>>>> - The plan is to store keys in LDAP and let 'something' (i.e. > >>>>>>> certmonger or oddjob?) to generate and store the new keys back into > >>>>>>> LDAP > >>>>>>> - There are command line tools for key-generation (dnssec-keygen from > >>>>>>> the package bind-utils) > >>>>>>> - We plan to select one super-master which will handle regular > >>>>>>> key-regeneration (i.e. do the same as we do for special CA > >>>>>>> certificates) > >>>>>>> - Keys stored in LDAP will be encrypted somehow, most probably by > >>>>>>> some > >>>>>>> symmetric key shared among all IPA DNS servers > >>>>>>> > >>>>>>> Could certmonger or oddjob do key maintenance for us? I can imagine > >>>>>>> something like this: > >>>>>>> - watch some attributes in LDAP and wait until some key expires > >>>>>>> - run dnssec-keygen utility > >>>>>>> - read resulting keys and encrypt them with given 'master key' > >>>>>>> - store resulting blobs in LDAP > >>>>>>> - wait until another key reaches expiration timestamp > >>>>>>> > >>>>>>> It is simplified, because there will be multiple keys with different > >>>>>>> lifetimes, but the idea is the same. All the gory details are in the > >>>>>>> thread '[Freeipa-devel] DNSSEC support design considerations: key > >>>>>>> material handling': > >>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-July/msg00129.html > >>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html > >>>>>>> > >>>>>>> > >>>>>>> Nalin and others, what do you think? Is certmonger or oddjob the > >>>>>>> right > >>>>>>> place to do something like this? > >>>>>>> > >>>>>>> Thank you for your time! > >>>>>>> > >>>>>> Was there any discussion of this mail? > >>>>>> > >>>>> I think at least some of this was covered in another thread, "DNSSEC > >>>>> support design considerations: key material handling" at > >>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html > >>>>> > >>>>> rob > >>>>> > >>>>> > >>>> Yes, I have found that thread though I have not found it to come to some > >>>> conclusion and a firm plan. > >>>> I will leave to Petr to summarize outstanding issues and repost them. > >>> All questions stated in the first e-mail in this thread are still open: > >>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html > >>> > >>> There was no reply to these questions during my vacation, so I don't > >>> have much to add at the moment. > >>> > >>> Nalin, please, could you provide your opinion? > >>> How modular/extendible the certmonger is? > >>> Does it make sense to add DNSSEC key-management to certmonger? > >>> What about CA rotation problem? Can we share some algorithms (e.g. for > >>> super-master election) between CA rotation and DNSSEC key rotation > >>> mechanisms? > >>> > >>>> BTW I like the idea of masters being responsible for generating a subset > >>>> of the keys as Loris suggested. > >>> E-mail from Loris in archives: > >>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00100.html > >>> > >>> The idea seems really nice and simple, but I'm afraid that there could > >>> be some serious race conditions. > >>> > >>> - How will it work when topology changes? > >>> - What if number of masters is > number of days in month? (=> > >>> Auto-tune interval from month to smaller time period => Again, what > >>> should we do after a topology change?) > >>> - What we should do if topology was changed when a master was > >>> disconnected from the rest of the network? (I.e. Link over WAN was > >>> down at the moment of change.) What will happen after re-connection to > >>> the topology? > >>> > >>> Example: > >>> Time 0: Masters A, B; topology: A---B > >>> Time 1: Master A have lost connection to master B > >>> Time 2: Master C was added; topology: A ? B---C > >>> Time 3 (Day 3): A + C did rotation at the same time > >>> Time 4: Connection was restored; topology: A---B---C > >>> > >>> Now what? > >>> > >>> > >>> I have a feeling that we need something like quorum protocol for > >>> writes (only for sensitive operations like CA cert and DNSSEC key > >>> rotations). > >>> > >>> http://en.wikipedia.org/wiki/Quorum_(distributed_computing) > >>> > >>> > >>> The other question is how should we handle catastrophic situations > >>> where more than half of masters were lost? (Two of three data centres > >>> were blown by a tornado etc.) > >>> > >> It becomes more and more obvious that there is no simple solution that > >> we can use out of box. > >> Let us start with a single nominated server. If the server is lost the > >> key rotation responsibility can be moved to some other server manually. > >> Not optimal but at least the first step. > >> > >> The next step would be to be able to define alternative (failover) > >> servers. Here is an example. > >> Let us say we have masters A, B, C. In topology A - B - C. > >> Master A is responsible for the key rotation B is the fail-over. > >> The key rotation time would be in some way recorded in the replication > >> agreement(s) between A & B. > >> If at the moment of the scheduled rotation A <-> B connection is not > >> present A would skip rotation and B would start rotation. If A comes > >> back and connects to B (or connection is just restored) the replication > >> will update the keys on A. If A is lost the keys are taken care of by B > >> for itself and C. > >> There will be a short window of race condition but IMO it can be > >> mitigated. If A clock is behind B then if A managed to connect to B it > >> would notice that B already started rotation. If B clock is behind and A > >> connects to B before B started rotation A has to perform rotation still > >> (sort of just made it case). > >> > >> Later if we want more complexity we can define subsets of the keys to > >> renew and assign them to different replicas and then define failover > >> servers per set. > >> But this is all complexity we can add later when we see the real > >> problems with the single server approach. > > Actually I thought about this for a while, and I think I have an idea > > about how to handle this for DNSSEC, (may not apply to other cases like > > CA). > > > > IIRC keys are generate well in advance from the time they are used and > > old keys and new keys are used side by side for a while, until old keys > > are finally expired and only new keys are around. > > > > This iso regulated by a series of date attributes that determine when > > keys are in used when they expire and so on. > > > > Now the idea I have is to add yet another step. > > > > Assume we have key "generation 1" (G1) in use and we approach the time > > generation 1 will expire and generation 2 (G2) is needed, and G2 is > > created X months in advance and all stuff is signed with both G1 and G2 > > for a period. > > > > Now if we have a pre-G2 period we can have a period of time when we can > > let multiple servers try to generate the G2 series, say 1 month in > > advance of the time they would normally be used to start signing > > anything. Then only after that 1 month they are actually put into > > services. > > > > How does this helps? Well it helps in that even if multiple servers > > generate keys and we have duplicates they have all the time to see that > > there are duplicates (because 2 server raced). > > now if e can keep a subsecond 'creation' timestamp for the new keys when > > replication goes around all servers can check and use only the set of > > keys that have been create first, and the servers that created the set > > of keys that lose the race will just remove the duplicates. > > given we have 1 month of time between the creation and the actual time > > keys will be used we have all the time to let servers sort out whether > > there are keys available or not and prune out duplicates. > > > > A diagram in case I have not been clear enough > > > > > > Assume servers A, B, C they all randomize (within a week) the time at > > which they will attempt to create new keys if it is time to and none are > > available already. > > > > Say the time come to create G2, A, B ,C each throw a dice and it turns > > out A will do it in 35000 seconds, B will do it in 40000 seconds, and C > > in 32000 seconds, so C should do it first and there should be enough > > time for the others to see that new keys popped up and just discard > > their attempts. > > > > However is A or C are temporarily disconnected they may still end up > > generating new keys, so we have G2-A and G2-B, once they get reconnected > > and replication flows again all servers see that instead of a single G2 > > set we have 2 G2 sets available > > G2-A created at timestamp X+35000 and G2-B created at timestamp X+32000, > > so all servers know they should ignore G2-A, and they all ignore it. > > When A comes around to realize this itself it will just go and delete > > the G2-A set. Only G2-B set is left and that is what will be the final > > official G2. > > > > If we give a week of time for this operation to go on I think it will be > > easy to resolve any race or temporary diconnection that may happen. > > Also because all server can attempt (within that week) to create keys > > there is no real single point of failure. > > > > HTH, > > please poke holes in my reasoning :) > > > > Simo. > > > > Reasonable just have couple comments. > If there are many keys and many replicas the chance would be that there > will be a lot of load. Generating keys is costly computation wise. > Replication is costly too. > Also you assume that topology works fine. I am mostly concerned about > the case when some replication is not working and data from one part of > the topology is not replicated to another. The concern is that people > would not notice that things are not replicating. So if there is a > problem and we let all these key to be generated all over the place it > would be pretty hard to untie this knot later. If replication is broken for so long you have *much* more serious issues. > I would actually suggest that if a replica X needs the keys in a month > from moment A and the keys have not arrived in 3 first days after moment > A and this replica is not entitled to generate keys it should start > sending messages to admin. That way there will be enough time for admin > to sort out what is wrong and nominate another replica to generate the > keys if needed. There should be command as simple as: If we are going to spam admins I think we should do that once a replica sees that replication is broken, and not just wait until some key material is late to arrive. I guess we needed to start thinking of allowing to configure an MTA address in one LDAP attribute and an administrative email address and then send messages when something critical happens. I think admins in general will be happy unless we overload them with garbage or repeated messages. > ipa dnssec-keymanager-set > > that would make the mentioned replica the key generator. I do not think there should be any special replica enable, my scheme makes every replica participate in key creation (at least every replica that has a DNS server on it). > There can be other commands like > > ipa dnssec-keymanager-info > > Appointed server: there is no appointed server, it would be a SPOF which is what I want to avoid with my scheme. > Keys store: > Last time keys generated: > Next time keys need to be generated: <...> > ... > > > > > IMO in this case we need to help admin to see that there is a problem > and provide tools to easily mitigate it rather than try to solve it > ourselves and build a complex algorythm. Yes, but this is a general problem, I think it is time to build some small part of A where at least we handle self-health checks and then spam admins if something really bad is happening. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Sep 4 17:57:45 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 04 Sep 2013 13:57:45 -0400 Subject: [Freeipa-devel] certmonger/oddjob for DNSSEC key maintenance In-Reply-To: <5227656F.2020103@redhat.com> References: <5204E103.1090109@redhat.com> <521CF250.3070803@redhat.com> <521CF85C.5050608@redhat.com> <521D1567.80401@redhat.com> <522495C3.8000107@redhat.com> <52261029.3030001@redhat.com> <1378238496.13768.50.camel@willson.li.ssimo.org> <522730D9.2020102@redhat.com> <52273696.1030808@redhat.com> <20130904135011.GJ21212@redhat.com> <52274111.3000805@redhat.com> <5227656F.2020103@redhat.com> Message-ID: <1378317465.13768.117.camel@willson.li.ssimo.org> On Wed, 2013-09-04 at 12:53 -0400, Dmitri Pal wrote: > Should we treat this functionality independent from the tool? > I am concerned with volume of the load and replication. I think it > should be an option - single master generates keys or you can enable > others to generate the keys and if they are enabled to generate the > keys > they would follow the algorithm proposed by Simo. > Having a single master generate keys is a single point of failure and will bring down your whole infrastructure if you really use DNSSEC. I say we cannot release DNSSEC as usable unless we have robust/redundant key generation. My schema does not add any relevant replication traffic, keep in mind the only keys generate are the signing keys, which are rotated once every few months. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Thu Sep 5 04:04:25 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 05 Sep 2013 00:04:25 -0400 Subject: [Freeipa-devel] [PATCH 0015] Add support for managing user auth types Message-ID: <1378353865.19352.9.camel@localhost> patch attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0015-Add-support-for-managing-user-auth-types.patch Type: text/x-patch Size: 5258 bytes Desc: not available URL: From npmccallum at redhat.com Thu Sep 5 04:06:13 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 05 Sep 2013 00:06:13 -0400 Subject: [Freeipa-devel] [PATCH 0016] Add RADIUS proxy support to ipalib CLI Message-ID: <1378353973.19352.11.camel@localhost> patch attached -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0016-Add-RADIUS-proxy-support-to-ipalib-CLI.patch Type: text/x-patch Size: 11249 bytes Desc: not available URL: From npmccallum at redhat.com Thu Sep 5 04:25:53 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 05 Sep 2013 00:25:53 -0400 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI Message-ID: <1378355153.19352.29.camel@localhost> This patch has a few problems that I'd like some help with. There are a few notes here as well. 1. The handling of the 'key' option is insecure. It should probably be treated like a password (hidden from logs, etc). However, in this case, it is binary, so I'm not quite sure how to do that. Passing it as a command line option may be nice for scripting, but is potentially a security problem if it ends up in bash.history. It would also be nice if the encoding were base32 instead of base64, since nearly all the OTP tools use this encoding. 2. The 'key' option also appears in otp-find. I'd like to suppress this. How? 3. I had to make the 'id' option optional to make the uuid autogeneration work in otp-add. However, this has the side-effect that 'id' is now optional in all the other commands. This is particularly bad in the case of otp-del, where calling this command with no ID transparently removes all tokens. How can I make this optional for otp-add but required for all other commands? 4. otp-import is not implemented. I spent a few hours looking and I didn't find any otp tool that actually uses this xml format for exporting. Should we implement this now or wait until someone can actually export data to us? 5. otp-del happily deletes the last token for a user. How can I find out the dn of the user executing the command? Also, what is the right exception to throw in pre_callback()? 6. user-show does not list the associated tokens for this user. Do we care? It is a single search: otp-find --owner npmccallum. 7. otp-add only prints the qr code if the --qrcode option is specified. This is for two reasons. First, and most importantly, the qr code doesn't fit on a standard 24x80 terminal. I wanted to avoid dumping garbage on people's screens by default. Second, you may not always want the qr code output (like for a hard token or manual code entry). Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0017-Add-OTP-support-to-ipalib-CLI.patch Type: text/x-patch Size: 12720 bytes Desc: not available URL: From npmccallum at redhat.com Thu Sep 5 04:29:07 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 05 Sep 2013 00:29:07 -0400 Subject: [Freeipa-devel] [PATCH 0016] Add RADIUS proxy support to ipalib CLI In-Reply-To: <1378353973.19352.11.camel@localhost> References: <1378353973.19352.11.camel@localhost> Message-ID: <1378355347.19352.32.camel@localhost> I forgot to mention that this code ignores the design page in one area: radius-show does not list the users attached to this server. How important is this? user-find --radius=MyRADIUSServer should find all the users. Nathaniel From npmccallum at redhat.com Thu Sep 5 04:38:25 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 05 Sep 2013 00:38:25 -0400 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <1378355153.19352.29.camel@localhost> References: <1378355153.19352.29.camel@localhost> Message-ID: <1378355905.19352.35.camel@localhost> On Thu, 2013-09-05 at 00:25 -0400, Nathaniel McCallum wrote: > This patch has a few problems that I'd like some help with. There are a > few notes here as well. > > 1. The handling of the 'key' option is insecure. It should probably be > treated like a password (hidden from logs, etc). However, in this case, > it is binary, so I'm not quite sure how to do that. Passing it as a > command line option may be nice for scripting, but is potentially a > security problem if it ends up in bash.history. It would also be nice if > the encoding were base32 instead of base64, since nearly all the OTP > tools use this encoding. > > 2. The 'key' option also appears in otp-find. I'd like to suppress this. > How? > > 3. I had to make the 'id' option optional to make the uuid > autogeneration work in otp-add. However, this has the side-effect that > 'id' is now optional in all the other commands. This is particularly bad > in the case of otp-del, where calling this command with no ID > transparently removes all tokens. How can I make this optional for > otp-add but required for all other commands? > > 4. otp-import is not implemented. I spent a few hours looking and I > didn't find any otp tool that actually uses this xml format for > exporting. Should we implement this now or wait until someone can > actually export data to us? > > 5. otp-del happily deletes the last token for a user. How can I find out > the dn of the user executing the command? Also, what is the right > exception to throw in pre_callback()? > > 6. user-show does not list the associated tokens for this user. Do we > care? It is a single search: otp-find --owner npmccallum. > > 7. otp-add only prints the qr code if the --qrcode option is specified. > This is for two reasons. First, and most importantly, the qr code > doesn't fit on a standard 24x80 terminal. I wanted to avoid dumping > garbage on people's screens by default. Second, you may not always want > the qr code output (like for a hard token or manual code entry). 8. If a user is deleted, the user's assigned tokens are left unmodified. That is *not* to say they are orphaned. The owner attribute retains a dn to an invalid user. This also means that otp-find --owner=deletedUser will fail since we can't look up the deleted user. How does dirsrv handle this for other relationships? Nathaniel From abokovoy at redhat.com Thu Sep 5 06:08:04 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Sep 2013 09:08:04 +0300 Subject: [Freeipa-devel] [PATCHES] 0270-0271 Support for Pylint 1.0 In-Reply-To: <5226E87D.7000005@redhat.com> References: <5211F39F.2010606@redhat.com> <5226E87D.7000005@redhat.com> Message-ID: <20130905060804.GK21212@redhat.com> On Wed, 04 Sep 2013, Petr Viktorin wrote: > On 08/19/2013 12:29 PM, Petr Viktorin wrote: >> Hello, >> The first patch fixes a minor problem that Pylint 1.0 finds in our code. >> >> The second patch makes make-lint compatible with Pylint 1.0. It contains >> a workaround for a Pylint bug; before pushing this we should wait for a >> while to see if a fixed Pylint is released. >> > > A fixed version of Pylint was released, bug workarounds are no > longer necessary. > > Updated patches attached. > > https://fedorahosted.org/freeipa/ticket/3865 I tried the patches and still see an error on up to date Fedora 19 (including updates-testing): ./make-lint Traceback (most recent call last): File "./make-lint", line 272, in sys.exit(main()) File "./make-lint", line 243, in main linter.check(files) File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 599, in check self.check_astroid_module(astroid, walker, rawcheckers, tokencheckers) File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 685, in check_astroid_module walker.walk(astroid) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 662, in walk self.walk(child) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 662, in walk self.walk(child) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 662, in walk self.walk(child) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 662, in walk self.walk(child) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 662, in walk self.walk(child) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 662, in walk self.walk(child) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 659, in walk cb(astroid) File "./make-lint", line 126, in visit_getattr ignored = self._find_ignored_attrs(owner) File "./make-lint", line 110, in _find_ignored_attrs for klass in self._related_classes(owner): File "./make-lint", line 102, in _related_classes for base in klass.ancestors(): File "/usr/lib/python2.7/site-packages/astroid/scoped_nodes.py", line 810, in ancestors for grandpa in baseobj.ancestors(True, context): File "/usr/lib/python2.7/site-packages/astroid/scoped_nodes.py", line 801, in ancestors for baseobj in stmt.infer(context): TypeError: unbound method infer() must be called with Tuple instance as first argument (got InferenceContext instance instead) At this point I'm not sure whether it is astroid's issue or ours... Astroid did change from 0.24 to 1.0 on August 13th in Fedora (even in Fedora 19 where version updates after release are generally discouraged, especially in case of ABI change). -- / Alexander Bokovoy From pspacek at redhat.com Thu Sep 5 07:50:24 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 05 Sep 2013 09:50:24 +0200 Subject: [Freeipa-devel] ipa health check (was: certmonger/oddjob for DNSSEC key maintenance) In-Reply-To: <1378315021.13768.108.camel@willson.li.ssimo.org> References: <5204E103.1090109@redhat.com> <521CF250.3070803@redhat.com> <521CF85C.5050608@redhat.com> <521D1567.80401@redhat.com> <522495C3.8000107@redhat.com> <52261029.3030001@redhat.com> <1378238496.13768.50.camel@willson.li.ssimo.org> <522730D9.2020102@redhat.com> <1378315021.13768.108.camel@willson.li.ssimo.org> Message-ID: <522837C0.5050003@redhat.com> On 4.9.2013 19:17, Simo Sorce wrote: > On Wed, 2013-09-04 at 09:08 -0400, Dmitri Pal wrote: >> On 09/03/2013 04:01 PM, Simo Sorce wrote: >>> On Tue, 2013-09-03 at 12:36 -0400, Dmitri Pal wrote: >>>> On 09/02/2013 09:42 AM, Petr Spacek wrote: >>>>> On 27.8.2013 23:08, Dmitri Pal wrote: >>>>>> On 08/27/2013 03:05 PM, Rob Crittenden wrote: >>>>>>> Dmitri Pal wrote: >>>>>>>> On 08/09/2013 08:30 AM, Petr Spacek wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I would like to get opinions about key maintenance for DNSSEC. >>>>>>>>> >>>>>>>>> Problem summary: >>>>>>>>> - FreeIPA will support DNSSEC >>>>>>>>> - DNSSEC deployment requires <2,n> cryptographic keys for each DNS >>>>>>>>> zone (i.e. objects in LDAP) >>>>>>>>> - The same keys are shared by all FreeIPA servers >>>>>>>>> - Keys have limited lifetime and have to be re-generated on monthly >>>>>>>>> basics (in very first approximation, it will be configurable and the >>>>>>>>> interval will differ for different key types) >>>>>>>>> - The plan is to store keys in LDAP and let 'something' (i.e. >>>>>>>>> certmonger or oddjob?) to generate and store the new keys back into >>>>>>>>> LDAP >>>>>>>>> - There are command line tools for key-generation (dnssec-keygen from >>>>>>>>> the package bind-utils) >>>>>>>>> - We plan to select one super-master which will handle regular >>>>>>>>> key-regeneration (i.e. do the same as we do for special CA >>>>>>>>> certificates) >>>>>>>>> - Keys stored in LDAP will be encrypted somehow, most probably by >>>>>>>>> some >>>>>>>>> symmetric key shared among all IPA DNS servers >>>>>>>>> >>>>>>>>> Could certmonger or oddjob do key maintenance for us? I can imagine >>>>>>>>> something like this: >>>>>>>>> - watch some attributes in LDAP and wait until some key expires >>>>>>>>> - run dnssec-keygen utility >>>>>>>>> - read resulting keys and encrypt them with given 'master key' >>>>>>>>> - store resulting blobs in LDAP >>>>>>>>> - wait until another key reaches expiration timestamp >>>>>>>>> >>>>>>>>> It is simplified, because there will be multiple keys with different >>>>>>>>> lifetimes, but the idea is the same. All the gory details are in the >>>>>>>>> thread '[Freeipa-devel] DNSSEC support design considerations: key >>>>>>>>> material handling': >>>>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-July/msg00129.html >>>>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html >>>>>>>>> >>>>>>>>> >>>>>>>>> Nalin and others, what do you think? Is certmonger or oddjob the >>>>>>>>> right >>>>>>>>> place to do something like this? >>>>>>>>> >>>>>>>>> Thank you for your time! >>>>>>>>> >>>>>>>> Was there any discussion of this mail? >>>>>>>> >>>>>>> I think at least some of this was covered in another thread, "DNSSEC >>>>>>> support design considerations: key material handling" at >>>>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html >>>>>>> >>>>>>> rob >>>>>>> >>>>>>> >>>>>> Yes, I have found that thread though I have not found it to come to some >>>>>> conclusion and a firm plan. >>>>>> I will leave to Petr to summarize outstanding issues and repost them. >>>>> All questions stated in the first e-mail in this thread are still open: >>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html >>>>> >>>>> There was no reply to these questions during my vacation, so I don't >>>>> have much to add at the moment. >>>>> >>>>> Nalin, please, could you provide your opinion? >>>>> How modular/extendible the certmonger is? >>>>> Does it make sense to add DNSSEC key-management to certmonger? >>>>> What about CA rotation problem? Can we share some algorithms (e.g. for >>>>> super-master election) between CA rotation and DNSSEC key rotation >>>>> mechanisms? >>>>> >>>>>> BTW I like the idea of masters being responsible for generating a subset >>>>>> of the keys as Loris suggested. >>>>> E-mail from Loris in archives: >>>>> https://www.redhat.com/archives/freeipa-devel/2013-August/msg00100.html >>>>> >>>>> The idea seems really nice and simple, but I'm afraid that there could >>>>> be some serious race conditions. >>>>> >>>>> - How will it work when topology changes? >>>>> - What if number of masters is > number of days in month? (=> >>>>> Auto-tune interval from month to smaller time period => Again, what >>>>> should we do after a topology change?) >>>>> - What we should do if topology was changed when a master was >>>>> disconnected from the rest of the network? (I.e. Link over WAN was >>>>> down at the moment of change.) What will happen after re-connection to >>>>> the topology? >>>>> >>>>> Example: >>>>> Time 0: Masters A, B; topology: A---B >>>>> Time 1: Master A have lost connection to master B >>>>> Time 2: Master C was added; topology: A ? B---C >>>>> Time 3 (Day 3): A + C did rotation at the same time >>>>> Time 4: Connection was restored; topology: A---B---C >>>>> >>>>> Now what? >>>>> >>>>> >>>>> I have a feeling that we need something like quorum protocol for >>>>> writes (only for sensitive operations like CA cert and DNSSEC key >>>>> rotations). >>>>> >>>>> http://en.wikipedia.org/wiki/Quorum_(distributed_computing) >>>>> >>>>> >>>>> The other question is how should we handle catastrophic situations >>>>> where more than half of masters were lost? (Two of three data centres >>>>> were blown by a tornado etc.) >>>>> >>>> It becomes more and more obvious that there is no simple solution that >>>> we can use out of box. >>>> Let us start with a single nominated server. If the server is lost the >>>> key rotation responsibility can be moved to some other server manually. >>>> Not optimal but at least the first step. >>>> >>>> The next step would be to be able to define alternative (failover) >>>> servers. Here is an example. >>>> Let us say we have masters A, B, C. In topology A - B - C. >>>> Master A is responsible for the key rotation B is the fail-over. >>>> The key rotation time would be in some way recorded in the replication >>>> agreement(s) between A & B. >>>> If at the moment of the scheduled rotation A <-> B connection is not >>>> present A would skip rotation and B would start rotation. If A comes >>>> back and connects to B (or connection is just restored) the replication >>>> will update the keys on A. If A is lost the keys are taken care of by B >>>> for itself and C. >>>> There will be a short window of race condition but IMO it can be >>>> mitigated. If A clock is behind B then if A managed to connect to B it >>>> would notice that B already started rotation. If B clock is behind and A >>>> connects to B before B started rotation A has to perform rotation still >>>> (sort of just made it case). >>>> >>>> Later if we want more complexity we can define subsets of the keys to >>>> renew and assign them to different replicas and then define failover >>>> servers per set. >>>> But this is all complexity we can add later when we see the real >>>> problems with the single server approach. >>> Actually I thought about this for a while, and I think I have an idea >>> about how to handle this for DNSSEC, (may not apply to other cases like >>> CA). >>> >>> IIRC keys are generate well in advance from the time they are used and >>> old keys and new keys are used side by side for a while, until old keys >>> are finally expired and only new keys are around. >>> >>> This iso regulated by a series of date attributes that determine when >>> keys are in used when they expire and so on. >>> >>> Now the idea I have is to add yet another step. >>> >>> Assume we have key "generation 1" (G1) in use and we approach the time >>> generation 1 will expire and generation 2 (G2) is needed, and G2 is >>> created X months in advance and all stuff is signed with both G1 and G2 >>> for a period. >>> >>> Now if we have a pre-G2 period we can have a period of time when we can >>> let multiple servers try to generate the G2 series, say 1 month in >>> advance of the time they would normally be used to start signing >>> anything. Then only after that 1 month they are actually put into >>> services. >>> >>> How does this helps? Well it helps in that even if multiple servers >>> generate keys and we have duplicates they have all the time to see that >>> there are duplicates (because 2 server raced). >>> now if e can keep a subsecond 'creation' timestamp for the new keys when >>> replication goes around all servers can check and use only the set of >>> keys that have been create first, and the servers that created the set >>> of keys that lose the race will just remove the duplicates. >>> given we have 1 month of time between the creation and the actual time >>> keys will be used we have all the time to let servers sort out whether >>> there are keys available or not and prune out duplicates. >>> >>> A diagram in case I have not been clear enough >>> >>> >>> Assume servers A, B, C they all randomize (within a week) the time at >>> which they will attempt to create new keys if it is time to and none are >>> available already. >>> >>> Say the time come to create G2, A, B ,C each throw a dice and it turns >>> out A will do it in 35000 seconds, B will do it in 40000 seconds, and C >>> in 32000 seconds, so C should do it first and there should be enough >>> time for the others to see that new keys popped up and just discard >>> their attempts. >>> >>> However is A or C are temporarily disconnected they may still end up >>> generating new keys, so we have G2-A and G2-B, once they get reconnected >>> and replication flows again all servers see that instead of a single G2 >>> set we have 2 G2 sets available >>> G2-A created at timestamp X+35000 and G2-B created at timestamp X+32000, >>> so all servers know they should ignore G2-A, and they all ignore it. >>> When A comes around to realize this itself it will just go and delete >>> the G2-A set. Only G2-B set is left and that is what will be the final >>> official G2. >>> >>> If we give a week of time for this operation to go on I think it will be >>> easy to resolve any race or temporary diconnection that may happen. >>> Also because all server can attempt (within that week) to create keys >>> there is no real single point of failure. >>> >>> HTH, >>> please poke holes in my reasoning :) >>> >>> Simo. >>> >> >> Reasonable just have couple comments. >> If there are many keys and many replicas the chance would be that there >> will be a lot of load. Generating keys is costly computation wise. >> Replication is costly too. >> Also you assume that topology works fine. I am mostly concerned about >> the case when some replication is not working and data from one part of >> the topology is not replicated to another. The concern is that people >> would not notice that things are not replicating. So if there is a >> problem and we let all these key to be generated all over the place it >> would be pretty hard to untie this knot later. > > If replication is broken for so long you have *much* more serious > issues. > >> I would actually suggest that if a replica X needs the keys in a month >> from moment A and the keys have not arrived in 3 first days after moment >> A and this replica is not entitled to generate keys it should start >> sending messages to admin. That way there will be enough time for admin >> to sort out what is wrong and nominate another replica to generate the >> keys if needed. There should be command as simple as: > > If we are going to spam admins I think we should do that once a replica > sees that replication is broken, and not just wait until some key > material is late to arrive. > > I guess we needed to start thinking of allowing to configure an MTA > address in one LDAP attribute and an administrative email address and > then send messages when something critical happens. > > I think admins in general will be happy unless we overload them with > garbage or repeated messages. Honestly, as a former sysadmin, I don't think that built-in SMTP client is a very good idea. 1) Each notification mechanism adds big complexity to the implementation: - message queue - fail-over if 'upstream' SMTP server is down - authentication to 'upstream server' - flood/repeated message detection/limitation - ... - and configuration for all this. Some of points above can be solved by existing MTA, but not all of them. 2) Besides implementation, it adds administrative burden during normal system operation: You have to reconfigure all SMTP clients if something was changed in SMTP server configuration. For example: - the organization started to require authentication/SSL for all SMTP connections - mail server's address was changed - backup mail server was added etc. Also, consider the situation where 'replica in trouble' is unable to send a message for some reason (WAN link to/from branch office is down, MTA/machine crashed etc.) This should be handled by some general monitoring system. Another aspect is that admin could want to use another communication channel than e-mail or combination of more channels at once (send e-mail/Jabber message instantly + send SMS if severity >= CRITICAL). Yet another problem is that definition of 'severity' depends on organization. You have to have a component which translates message from machine to context organization-defined 'severity'. And then we have dependency problem: If authentication service is down, then you don't need explicit notification that all 20 IMAP servers doesn't work. etc. etc. IMHO, for those reasons we should implement 'a tool for replica health check' with reasonably detailed output and defer problems mentioned above to generic monitoring systems. The monitoring problem is way more complex than it seems after first look. If you takes monitoring seriously, you already have a monitoring system. If you don't, then line 'ipa health-check | mail admin at example.com' in cron is perfectly enough. Does it make sense? Petr^2 Spacek >> ipa dnssec-keymanager-set >> >> that would make the mentioned replica the key generator. > > I do not think there should be any special replica enable, my scheme > makes every replica participate in key creation (at least every replica > that has a DNS server on it). > >> There can be other commands like >> >> ipa dnssec-keymanager-info >> >> Appointed server: > > there is no appointed server, it would be a SPOF which is what I want to > avoid with my scheme. > >> Keys store: >> Last time keys generated: >> Next time keys need to be generated: <...> >> ... >> >> >> >> >> IMO in this case we need to help admin to see that there is a problem >> and provide tools to easily mitigate it rather than try to solve it >> ourselves and build a complex algorythm. > > Yes, but this is a general problem, I think it is time to build some > small part of A where at least we handle self-health checks and then > spam admins if something really bad is happening. From pviktori at redhat.com Thu Sep 5 08:05:21 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 05 Sep 2013 10:05:21 +0200 Subject: [Freeipa-devel] [PATCHES] 0270-0271 Support for Pylint 1.0 In-Reply-To: <20130905060804.GK21212@redhat.com> References: <5211F39F.2010606@redhat.com> <5226E87D.7000005@redhat.com> <20130905060804.GK21212@redhat.com> Message-ID: <52283B41.1050103@redhat.com> On 09/05/2013 08:08 AM, Alexander Bokovoy wrote: > On Wed, 04 Sep 2013, Petr Viktorin wrote: >> On 08/19/2013 12:29 PM, Petr Viktorin wrote: >>> Hello, >>> The first patch fixes a minor problem that Pylint 1.0 finds in our code. >>> >>> The second patch makes make-lint compatible with Pylint 1.0. It contains >>> a workaround for a Pylint bug; before pushing this we should wait for a >>> while to see if a fixed Pylint is released. >>> >> >> A fixed version of Pylint was released, bug workarounds are no longer >> necessary. >> >> Updated patches attached. >> >> https://fedorahosted.org/freeipa/ticket/3865 > I tried the patches and still see an error on up to date Fedora 19 > (including updates-testing): > > ./make-lint Traceback (most recent call last): [...] > TypeError: unbound method infer() must be called with Tuple instance as > first argument (got InferenceContext instance instead) > > > At this point I'm not sure whether it is astroid's issue or ours... > Astroid did change from 0.24 to 1.0 on August 13th in Fedora (even in > Fedora 19 where version updates after release are generally > discouraged, especially in case of ABI change). Hello, Please use Pylint 1.0.0-2. It seems it hasn't reached the mirrors yet, you have the earlier buggy version. As for Fedora policy, it would probably be best to make that point with the maintainer. https://admin.fedoraproject.org/updates/FEDORA-2013-14942/pylint-1.0.0-2.fc19 -- Petr? From jcholast at redhat.com Thu Sep 5 08:28:36 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 05 Sep 2013 10:28:36 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <52260B6B.7050906@redhat.com> References: <52161568.7060702@redhat.com> <52245136.1090804@redhat.com> <52260B6B.7050906@redhat.com> Message-ID: <522840B4.30709@redhat.com> On 3.9.2013 18:16, Dmitri Pal wrote: > On 09/02/2013 04:49 AM, Petr Spacek wrote: >> On 22.8.2013 15:43, Jan Cholasta wrote: >>> Hi, >>> >>> I'm currently investigating support for multiple CA certificates in LDAP >>> (, >>> ). This will be useful >>> for CA >>> certificate renewal (, >>> ) and using >>> certificates issued >>> by custom CAs for IPA HTTP and directory server instances >>> (). >>> >>> The biggest issue is how to make IPA clients aware of CA certificate >>> changes. >>> One of the tickets suggests polling the LDAP server from SSSD. Would >>> that be >>> sufficient? Perhaps a combination of polling and detecting >>> certificate changes >>> when connecting to LDAP would be better? >>> >>> Another issue is how to handle updating IPA systems with new CA >>> certificate(s). On clients it is probably sufficient to store the >>> certificate(s) in /etc/ipa/ca.crt, but on servers there are multiple >>> places >>> where the update needs to be done (HTTP and directory server NSS >>> databases, >>> KDC pkinit_anchors file, etc.). IMO doing all this from SSSD is >>> unrealistic, >>> so there should be a way to do this externally. The simplest thing >>> that comes >>> to mind is that SSSD would execute an external script to do the >>> update when it >>> detects changes, but I'm not sure how well would that work with >>> SELinux in the >>> picture. Is there a better way to do this? >> >> It reminds me problems with key-rotation for DNSSEC. >> >> Could we find common problems and use the same/similar solution for >> both problems? >> >> An extension for certmonger? Oddjob? Or a completely new daemon? >> > Certmonger already has a way to: > 1) Check things periodically > 2) Hand certs in different places > 3) Run post op scripts > > IMO it is a good candidate but I would leave it to Nalin to chime in. > I would expect more things that require periodic checking on clients beyond certificates to come in the future, so I'm not sure if doing this in certmonger is the right thing to do. Also, SSSD already does a similar thing for realm domains, right? Honza -- Jan Cholasta From pviktori at redhat.com Thu Sep 5 10:19:17 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 05 Sep 2013 12:19:17 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <1378355905.19352.35.camel@localhost> References: <1378355153.19352.29.camel@localhost> <1378355905.19352.35.camel@localhost> Message-ID: <52285AA5.3010309@redhat.com> On 09/05/2013 06:38 AM, Nathaniel McCallum wrote: > On Thu, 2013-09-05 at 00:25 -0400, Nathaniel McCallum wrote: >> This patch has a few problems that I'd like some help with. There are a >> few notes here as well. >> >> 1. The handling of the 'key' option is insecure. It should probably be >> treated like a password (hidden from logs, etc). However, in this case, >> it is binary, so I'm not quite sure how to do that. Passing it as a >> command line option may be nice for scripting, but is potentially a >> security problem if it ends up in bash.history. It would also be nice if >> the encoding were base32 instead of base64, since nearly all the OTP >> tools use this encoding. Not only in bash_history; anyone can see command line parameters of running programs. We'll need to modify the framework to support more another password parameter type. The base32 on input/output can be added to that new type. >> 2. The 'key' option also appears in otp-find. I'd like to suppress this. >> How? Use the 'no_search' flag (which is currently undocumented; see below). >> 3. I had to make the 'id' option optional to make the uuid >> autogeneration work in otp-add. However, this has the side-effect that >> 'id' is now optional in all the other commands. This is particularly bad >> in the case of otp-del, where calling this command with no ID >> transparently removes all tokens. How can I make this optional for >> otp-add but required for all other commands? You'll need to add a new option flag. 1. Add a 'optional_create' flag to the comment in ipalib.parameters.Param. 2. Handle the flag in ipalib.crud.Create.get_options (clone with attribute=attribute, required=False) See the handling of 'ask_create' for exapmles. Please also document 'no_search' while you're modifying this part of the code. >> 4. otp-import is not implemented. I spent a few hours looking and I >> didn't find any otp tool that actually uses this xml format for >> exporting. Should we implement this now or wait until someone can >> actually export data to us? >> >> 5. otp-del happily deletes the last token for a user. How can I find out >> the dn of the user executing the command? Also, what is the right >> exception to throw in pre_callback()? Don't you want to check the token's owner rather than the current user? You could use LastMemberError here, or make your own error. >> 6. user-show does not list the associated tokens for this user. Do we >> care? It is a single search: otp-find --owner npmccallum. >> >> 7. otp-add only prints the qr code if the --qrcode option is specified. >> This is for two reasons. First, and most importantly, the qr code >> doesn't fit on a standard 24x80 terminal. I wanted to avoid dumping >> garbage on people's screens by default. Second, you may not always want >> the qr code output (like for a hard token or manual code entry). Would it make sense to add --qrcode to otp-show as well? If otp-add is the only opportunity to get the QR code, it's is easy to miss. > 8. If a user is deleted, the user's assigned tokens are left unmodified. > That is *not* to say they are orphaned. The owner attribute retains a dn > to an invalid user. This also means that otp-find --owner=deletedUser > will fail since we can't look up the deleted user. How does dirsrv > handle this for other relationships? In the hosts plugin, services are deleted in host_del.pre_callback. You could follow that example. -- Petr? From pviktori at redhat.com Thu Sep 5 10:45:16 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 05 Sep 2013 12:45:16 +0200 Subject: [Freeipa-devel] [PATCH] 0061 Add option to ipa-client-install to configure automount In-Reply-To: <5225C1D8.8090500@redhat.com> References: <5220A7B8.8000901@redhat.com> <52246EA3.1040703@redhat.com> <52247715.9030500@redhat.com> <5225B985.3060802@redhat.com> <5225C1D8.8090500@redhat.com> Message-ID: <522860BC.3080706@redhat.com> On 09/03/2013 01:02 PM, Ana Krivokapic wrote: > On 09/03/2013 12:27 PM, Petr Viktorin wrote: >> On 09/02/2013 01:31 PM, Ana Krivokapic wrote: >>> On 09/02/2013 12:55 PM, Petr Viktorin wrote: >>>> On 08/30/2013 04:10 PM, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> The attached patch addresses ticket >>>>> https://fedorahosted.org/freeipa/ticket/3740. >>>> >>>> Hello, >>>> Please write a design doc for this RFE. >>> >>> I updated the Minor Enhancements page: >>> http://www.freeipa.org/page/V3_Minor_Enhancements. I think it is sufficient in >>> this case. >>> >>>> Also you'll need to update the ipa-client-install man page. >>> >>> Done. >>>> >>>> I wonder if `location` is too generic a name for this option. >>>> Did you think about `--automount-location`, >>> >>> Good point, I changed `--location` to `--automount-location`. >>> >>>> plus maybe `--automount` without argument to just use the "default" location? >>>> It's a bit longer but it would make it immediately clear what the option is >>>> about. >>>> >>> >>> I think this is a bit of an overkill, as "--automount-location=default" does >>> precisely that. I would rather not complicate things further by adding more >>> options. >>> >>> Thanks for the review, updated patch is attached. >>> >> >> Looks good! One more comment for usability. >> The man page should explain that --automount-location configures automount by >> running ipa-client-automount(1). >> >> > > Fixed in updated patch. > ACK, pushed to master: 95483d3b9f0973e825cf37340f8ca91b567ab134 -- Petr? From simo at redhat.com Thu Sep 5 12:56:30 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 05 Sep 2013 08:56:30 -0400 Subject: [Freeipa-devel] ipa health check (was: certmonger/oddjob for DNSSEC key maintenance) In-Reply-To: <522837C0.5050003@redhat.com> References: <5204E103.1090109@redhat.com> <521CF250.3070803@redhat.com> <521CF85C.5050608@redhat.com> <521D1567.80401@redhat.com> <522495C3.8000107@redhat.com> <52261029.3030001@redhat.com> <1378238496.13768.50.camel@willson.li.ssimo.org> <522730D9.2020102@redhat.com> <1378315021.13768.108.camel@willson.li.ssimo.org> <522837C0.5050003@redhat.com> Message-ID: <1378385790.9321.2.camel@willson.li.ssimo.org> On Thu, 2013-09-05 at 09:50 +0200, Petr Spacek wrote: > Honestly, as a former sysadmin, I don't think that built-in SMTP > client is a > very good idea. > > 1) Each notification mechanism adds big complexity to the > implementation: > - message queue > - fail-over if 'upstream' SMTP server is down > - authentication to 'upstream server' > - flood/repeated message detection/limitation > - ... > - and configuration for all this. > > Some of points above can be solved by existing MTA, but not all of > them. > > 2) Besides implementation, it adds administrative burden during normal > system > operation: You have to reconfigure all SMTP clients if something was > changed > in SMTP server configuration. > For example: > - the organization started to require authentication/SSL for all SMTP > connections > - mail server's address was changed > - backup mail server was added > etc. > > Also, consider the situation where 'replica in trouble' is unable to > send a > message for some reason (WAN link to/from branch office is down, > MTA/machine > crashed etc.) This should be handled by some general monitoring > system. > > Another aspect is that admin could want to use another communication > channel > than e-mail or combination of more channels at once (send > e-mail/Jabber > message instantly + send SMS if severity >= CRITICAL). > > Yet another problem is that definition of 'severity' depends on > organization. > You have to have a component which translates message from machine to > context > organization-defined 'severity'. > > And then we have dependency problem: If authentication service is > down, then > you don't need explicit notification that all 20 IMAP servers doesn't > work. > > etc. etc. > > > IMHO, for those reasons we should implement 'a tool for replica health > check' > with reasonably detailed output and defer problems mentioned above to > generic > monitoring systems. The monitoring problem is way more complex than it > seems > after first look. > > If you takes monitoring seriously, you already have a monitoring > system. If > you don't, then line 'ipa health-check | mail admin at example.com' in > cron is > perfectly enough. > > Does it make sense? > Perfectly! Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Thu Sep 5 13:31:57 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 05 Sep 2013 09:31:57 -0400 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <52285AA5.3010309@redhat.com> References: <1378355153.19352.29.camel@localhost> <1378355905.19352.35.camel@localhost> <52285AA5.3010309@redhat.com> Message-ID: <1378387917.19352.43.camel@localhost> On Thu, 2013-09-05 at 12:19 +0200, Petr Viktorin wrote: > On 09/05/2013 06:38 AM, Nathaniel McCallum wrote: > > On Thu, 2013-09-05 at 00:25 -0400, Nathaniel McCallum wrote: > >> This patch has a few problems that I'd like some help with. There are a > >> few notes here as well. > >> > >> 1. The handling of the 'key' option is insecure. It should probably be > >> treated like a password (hidden from logs, etc). However, in this case, > >> it is binary, so I'm not quite sure how to do that. Passing it as a > >> command line option may be nice for scripting, but is potentially a > >> security problem if it ends up in bash.history. It would also be nice if > >> the encoding were base32 instead of base64, since nearly all the OTP > >> tools use this encoding. > > Not only in bash_history; anyone can see command line parameters of > running programs. > We'll need to modify the framework to support more another password > parameter type. > The base32 on input/output can be added to that new type. To clarify, by scripting I meant calling this from a python script. In this case, the argument wouldn't show up in the argv. Sorry my wording wasn't clear here. The primary case where this will apply is in otp-import (if we implement it). We will parse the XML and call self.api.Command.otp_add() for each token found, including the key. So it would be good to have this option available in python but not the shell. > >> 5. otp-del happily deletes the last token for a user. How can I find out > >> the dn of the user executing the command? Also, what is the right > >> exception to throw in pre_callback()? > > Don't you want to check the token's owner rather than the current user? > You could use LastMemberError here, or make your own error. If the executing user has permissions to remove another user's token, we assume they are an admin and know what they are doing. So this case only arises if the executing user is removing his/her own tokens. For instance: if executor == owner and tokenCount(owner) == 1: raise LastMemberError() > >> 7. otp-add only prints the qr code if the --qrcode option is specified. > >> This is for two reasons. First, and most importantly, the qr code > >> doesn't fit on a standard 24x80 terminal. I wanted to avoid dumping > >> garbage on people's screens by default. Second, you may not always want > >> the qr code output (like for a hard token or manual code entry). > > Would it make sense to add --qrcode to otp-show as well? If otp-add is > the only opportunity to get the QR code, it's is easy to miss. Only admins have permission to read 'key' from LDAP after creation. Standard users can create the OTP token object with a 'key', but cannot read back the key. Hence, the URI is only available at creation (provisioning) time. From pspacek at redhat.com Thu Sep 5 14:25:52 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 05 Sep 2013 16:25:52 +0200 Subject: [Freeipa-devel] [PATCH 0003] Add timestamps to named debug logs in /var/named/data/named.run Message-ID: <52289470.4020806@redhat.com> Hello, Add timestamps to named debug logs in /var/named/data/named.run. Tomas Babej and I spent more than hour with debugging bind-dyndb-ldap and timestamps were invaluable. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pspacek-0003-Add-timestamps-to-named-debug-logs-in-var-named-data.patch Type: text/x-patch Size: 736 bytes Desc: not available URL: From tbabej at redhat.com Thu Sep 5 14:29:10 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 05 Sep 2013 16:29:10 +0200 Subject: [Freeipa-devel] [PATCH 0003] Add timestamps to named debug logs in /var/named/data/named.run In-Reply-To: <52289470.4020806@redhat.com> References: <52289470.4020806@redhat.com> Message-ID: <52289536.3040801@redhat.com> On 09/05/2013 04:25 PM, Petr Spacek wrote: > Hello, > > Add timestamps to named debug logs in /var/named/data/named.run. > > > Tomas Babej and I spent more than hour with debugging bind-dyndb-ldap > and timestamps were invaluable. > ACK -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From npmccallum at redhat.com Thu Sep 5 14:29:43 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 05 Sep 2013 10:29:43 -0400 Subject: [Freeipa-devel] [PATCH 0003] Add timestamps to named debug logs in /var/named/data/named.run In-Reply-To: <52289470.4020806@redhat.com> References: <52289470.4020806@redhat.com> Message-ID: <1378391383.19352.44.camel@localhost> On Thu, 2013-09-05 at 16:25 +0200, Petr Spacek wrote: > Hello, > > Add timestamps to named debug logs in /var/named/data/named.run. > > > Tomas Babej and I spent more than hour with debugging bind-dyndb-ldap and > timestamps were invaluable. ACK From abokovoy at redhat.com Thu Sep 5 14:44:06 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Sep 2013 17:44:06 +0300 Subject: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created Message-ID: <20130905144406.GO21212@redhat.com> Hi! Attached please find a patch to clean up a mess we have with SID blacklist handling in ipa-sam. I noticed recently that Windows does not show IPA trusts as having AES encryption enabled. When investigating why is that happening, I've found out that there is a set of errors causing that but most important ones are the following two: - Wrong handle type was used to modify trust object information, and - SID blacklist handling in ipa-sam prevented LDAP updates from being correct which led to rejecting them by the LDAP server. Attached patch should fix the problem, more details are in the commit message. https://fedorahosted.org/freeipa/ticket/3898 -- / Alexander Bokovoy -------------- next part -------------- From aa63ab5d61d6f19401fa04d673095f14a1b5d0d3 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 5 Sep 2013 08:13:53 +0300 Subject: [PATCH 1/3] ipa-sam: fix setting encryption type for trust object already created When trust is established, last step done by IPA framework is to set encryption types associated with the trust. This operation fails due to ipa-sam attempting to modify trust object improperly: - object classes were changed unconditionally on each update - ACI entry was missing permission to modify SID blacklists - SID blacklists were reset on each update of the trust object using incorrect method which caused LDAP parsing errors at the server side due to multiple removals of the same value - trust POSIX offset value was not initialized which caused errors when fetching the trusted domain object in PDB. We don't use it yet but should initialize it to some default value (0 for now). Since the same code is used to create and update trusted domain object in LDAP, care should be taken to not remove/override those attributes that are set on the initialization of the trusted domain object but never touched by the ipa-sam anymore. SID blacklists are initialized by ipa-sam but used by Kerberos DAL driver and managed by IPA framework. Additionally, wrong handle was used by dcerpc.py code when executing SetInformationTrustedDomain() against IPA smbd which prevented even to reach the point where ipa-sam would be asked to modify the trust object. https://fedorahosted.org/freeipa/ticket/3898 --- daemons/ipa-sam/ipa_sam.c | 82 +++++++++++++++++++++++++++------------- install/updates/60-trusts.update | 1 + ipaserver/dcerpc.py | 9 +++++ 3 files changed, 65 insertions(+), 27 deletions(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 4a2fca5..a1e00dc 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -2229,11 +2229,14 @@ static NTSTATUS ipasam_set_trusted_domain(struct pdb_methods *methods, LDAPMod **mods; bool res; char *trusted_dn = NULL; - int ret, i; + int ret, i, count; NTSTATUS status; TALLOC_CTX *tmp_ctx; char *trustpw; char *sid; + char **in_blacklist = NULL; + char **out_blacklist = NULL; + uint32_t enctypes, trust_offset; DEBUG(10, ("ipasam_set_trusted_domain called for domain %s\n", domain)); @@ -2250,10 +2253,12 @@ static NTSTATUS ipasam_set_trusted_domain(struct pdb_methods *methods, } mods = NULL; - smbldap_make_mod(priv2ld(ldap_state), entry, &mods, "objectClass", - LDAP_OBJ_TRUSTED_DOMAIN); - smbldap_make_mod(priv2ld(ldap_state), entry, &mods, "objectClass", - LDAP_OBJ_ID_OBJECT); + if (entry == NULL) { + smbldap_make_mod(priv2ld(ldap_state), entry, &mods, "objectClass", + LDAP_OBJ_TRUSTED_DOMAIN); + smbldap_make_mod(priv2ld(ldap_state), entry, &mods, "objectClass", + LDAP_OBJ_ID_OBJECT); + } if (entry != NULL) { sid = get_single_attribute(tmp_ctx, priv2ld(ldap_state), entry, @@ -2314,26 +2319,37 @@ static NTSTATUS ipasam_set_trusted_domain(struct pdb_methods *methods, } } + trust_offset = 0; if (td->trust_posix_offset != NULL) { - res = smbldap_make_mod_uint32_t(priv2ld(ldap_state), entry, - &mods, - LDAP_ATTRIBUTE_TRUST_POSIX_OFFSET, - *td->trust_posix_offset); - if (!res) { - status = NT_STATUS_UNSUCCESSFUL; - goto done; - } + trust_offset = *td->trust_posix_offset; } + res = smbldap_make_mod_uint32_t(priv2ld(ldap_state), entry, + &mods, + LDAP_ATTRIBUTE_TRUST_POSIX_OFFSET, + trust_offset); + if (!res) { + status = NT_STATUS_UNSUCCESSFUL; + goto done; + } + + enctypes = KERB_ENCTYPE_DES_CBC_CRC | + KERB_ENCTYPE_DES_CBC_MD5 | + KERB_ENCTYPE_RC4_HMAC_MD5 | + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; + if (td->supported_enc_type != NULL) { - res = smbldap_make_mod_uint32_t(priv2ld(ldap_state), entry, - &mods, - LDAP_ATTRIBUTE_SUPPORTED_ENC_TYPE, - *td->supported_enc_type); - if (!res) { - status = NT_STATUS_UNSUCCESSFUL; - goto done; - } + enctypes = *td->supported_enc_type; + } + + res = smbldap_make_mod_uint32_t(priv2ld(ldap_state), entry, + &mods, + LDAP_ATTRIBUTE_SUPPORTED_ENC_TYPE, + enctypes); + if (!res) { + status = NT_STATUS_UNSUCCESSFUL; + goto done; } if (td->trust_auth_outgoing.data != NULL) { @@ -2354,13 +2370,24 @@ static NTSTATUS ipasam_set_trusted_domain(struct pdb_methods *methods, &td->trust_forest_trust_info); } + + /* Only add default blacklists for incoming and outgoing SIDs but don't modify existing ones */ + in_blacklist = get_attribute_values(tmp_ctx, ldap_state->smbldap_state->ldap_struct, entry, + LDAP_ATTRIBUTE_SID_BLACKLIST_INCOMING, &count); + out_blacklist = get_attribute_values(tmp_ctx, ldap_state->smbldap_state->ldap_struct, entry, + LDAP_ATTRIBUTE_SID_BLACKLIST_OUTGOING, &count); + for (i = 0; ipa_mspac_well_known_sids[i]; i++) { - smbldap_make_mod(priv2ld(ldap_state), entry, &mods, - LDAP_ATTRIBUTE_SID_BLACKLIST_INCOMING, - ipa_mspac_well_known_sids[i]); - smbldap_make_mod(priv2ld(ldap_state), entry, &mods, - LDAP_ATTRIBUTE_SID_BLACKLIST_OUTGOING, - ipa_mspac_well_known_sids[i]); + if (in_blacklist == NULL) { + smbldap_make_mod(priv2ld(ldap_state), entry, &mods, + LDAP_ATTRIBUTE_SID_BLACKLIST_INCOMING, + ipa_mspac_well_known_sids[i]); + } + if (out_blacklist == NULL) { + smbldap_make_mod(priv2ld(ldap_state), entry, &mods, + LDAP_ATTRIBUTE_SID_BLACKLIST_OUTGOING, + ipa_mspac_well_known_sids[i]); + } } smbldap_talloc_autofree_ldapmod(tmp_ctx, mods); @@ -2370,6 +2397,7 @@ static NTSTATUS ipasam_set_trusted_domain(struct pdb_methods *methods, status = NT_STATUS_NO_MEMORY; goto done; } + if (entry == NULL) { ret = smbldap_add(ldap_state->smbldap_state, trusted_dn, mods); } else { diff --git a/install/updates/60-trusts.update b/install/updates/60-trusts.update index 1b25115..46de01a 100644 --- a/install/updates/60-trusts.update +++ b/install/updates/60-trusts.update @@ -54,6 +54,7 @@ default: cn: trusts # 2. cn=trust admins,cn=groups,cn=accounts,$SUFFIX can manage trusts (via ipa tools) dn: cn=trusts,$SUFFIX add:aci: '(target = "ldap:///cn=trusts,$SUFFIX")(targetattr = "ipaNTTrustType || ipaNTTrustAttributes || ipaNTTrustDirection || ipaNTTrustPartner || ipaNTFlatName || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming || ipaNTSecurityIdentifier || ipaNTTrustForestTrustInfo || ipaNTTrustPosixOffset || ipaNTSupportedEncryptionTypes || krbPrincipalName || krbLastPwdChange || krbTicketFlags || krbLoginFailedCount || krbExtraData || krbPrincipalKey")(version 3.0;acl "Allow trust system user to create and delete trust accounts and cross realm principals"; allow (read,write,add,delete) groupdn="ldap:///cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX";)' +replace:aci:'(target = "ldap:///cn=trusts,$SUFFIX")(targetattr = "ipaNTTrustType || ipaNTTrustAttributes || ipaNTTrustDirection || ipaNTTrustPartner || ipaNTFlatName || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming || ipaNTSecurityIdentifier || ipaNTTrustForestTrustInfo || ipaNTTrustPosixOffset || ipaNTSupportedEncryptionTypes || krbPrincipalName || krbLastPwdChange || krbTicketFlags || krbLoginFailedCount || krbExtraData || krbPrincipalKey")(version 3.0;acl "Allow trust system user to create and delete trust accounts and cross realm principals"; allow (read,write,add,delete) groupdn="ldap:///cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX";)::(target = "ldap:///cn=trusts,$SUFFIX")(targetattr = "ipaNTTrustType || ipaNTTrustAttributes || ipaNTTrustDirection || ipaNTTrustPartner || ipaNTFlatName || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming || ipaNTSecurityIdentifier || ipaNTTrustForestTrustInfo || ipaNTTrustPosixOffset || ipaNTSupportedEncryptionTypes || ipaNTSIDBlacklistIncoming || ipaNTSIDBlacklistOutgoing || krbPrincipalName || krbLastPwdChange || krbTicketFlags || krbLoginFailedCount || krbExtraData || krbPrincipalKey")(version 3.0;acl "Allow trust system user to create and delete trust accounts and cross realm principals"; allow (read,write,add,delete) groupdn="ldap:///cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX";)' replace:aci:'(target = "ldap:///cn=trusts,$SUFFIX")(targetattr = "ipaNTTrustType || ipaNTTrustAttributes || ipaNTTrustDirection || ipaNTTrustPartner || ipaNTFlatName || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming || ipaNTSecurityIdentifier || ipaNTTrustForestTrustInfo || ipaNTTrustPosixOffset || ipaNTSupportedEncryptionTypes")(version 3.0;acl "Allow trust admins manage trust accounts"; allow (read,write,add,delete) groupdn="ldap:///cn=trust admins,cn=groups,cn=accounts,$SUFFIX";)::(target = "ldap:///cn=trusts,$SUFFIX")(targetattr = "ipaNTTrustType || ipaNTTrustAttributes || ipaNTTrustDirection || ipaNTTrustPartner || ipaNTFlatName || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming || ipaNTSecurityIdentifier || ipaNTTrustForestTrustInfo || ipaNTTrustPosixOffset || ipaNTSupportedEncryptionTypes || ipaNTSIDBlacklistIncoming || ipaNTSIDBlacklistOutgoing")(version 3.0;acl "Allow trust admins manage trust accounts"; allow (read,write,add,delete) groupdn="ldap:///cn=trust admins,cn=groups,cn=accounts,$SUFFIX";)' add:aci: '(target = "ldap:///cn=trusts,$SUFFIX")(targetattr = "ipaNTTrustType || ipaNTTrustAttributes || ipaNTTrustDirection || ipaNTTrustPartner || ipaNTFlatName || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming || ipaNTSecurityIdentifier || ipaNTTrustForestTrustInfo || ipaNTTrustPosixOffset || ipaNTSupportedEncryptionTypes || ipaNTSIDBlacklistIncoming || ipaNTSIDBlacklistOutgoing")(version 3.0;acl "Allow trust admins manage trust accounts"; allow (read,write,add,delete) groupdn="ldap:///cn=trust admins,cn=groups,cn=accounts,$SUFFIX";)' diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index a27a64d..bd8f5aa 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -912,12 +912,21 @@ class TrustDomainInstance(object): raise assess_dcerpc_exception(num=num, message=message) try: + # We should use proper trustdom handle in order to modify the + # trust settings. Samba insists this has to be done with LSA + # OpenTrustedDomain* calls, it is not enough to have a handle + # returned by the CreateTrustedDomainEx2 call. + trustdom_handle = self._pipe.OpenTrustedDomainByName(self._policy_handle, dname, security.SEC_FLAG_MAXIMUM_ALLOWED) infoclass = lsa.TrustDomainInfoSupportedEncTypes() infoclass.enc_types = security.KERB_ENCTYPE_RC4_HMAC_MD5 infoclass.enc_types |= security.KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 infoclass.enc_types |= security.KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96 self._pipe.SetInformationTrustedDomain(trustdom_handle, lsa.LSA_TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES, infoclass) except RuntimeError, e: + # We can ignore the error here -- changing enctypes is for + # improved security but the trust will work with default values as + # well. In particular, the call may fail against Windows 2003 + # server as that one doesn't support AES encryption types pass def verify_trust(self, another_domain): -- 1.8.3.1 From dpal at redhat.com Thu Sep 5 15:11:32 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Sep 2013 11:11:32 -0400 Subject: [Freeipa-devel] ipa health check In-Reply-To: <1378385790.9321.2.camel@willson.li.ssimo.org> References: <5204E103.1090109@redhat.com> <521CF250.3070803@redhat.com> <521CF85C.5050608@redhat.com> <521D1567.80401@redhat.com> <522495C3.8000107@redhat.com> <52261029.3030001@redhat.com> <1378238496.13768.50.camel@willson.li.ssimo.org> <522730D9.2020102@redhat.com> <1378315021.13768.108.camel@willson.li.ssimo.org> <522837C0.5050003@redhat.com> <1378385790.9321.2.camel@willson.li.ssimo.org> Message-ID: <52289F24.1050001@redhat.com> On 09/05/2013 08:56 AM, Simo Sorce wrote: > On Thu, 2013-09-05 at 09:50 +0200, Petr Spacek wrote: >> Honestly, as a former sysadmin, I don't think that built-in SMTP >> client is a >> very good idea. >> >> 1) Each notification mechanism adds big complexity to the >> implementation: >> - message queue >> - fail-over if 'upstream' SMTP server is down >> - authentication to 'upstream server' >> - flood/repeated message detection/limitation >> - ... >> - and configuration for all this. >> >> Some of points above can be solved by existing MTA, but not all of >> them. >> >> 2) Besides implementation, it adds administrative burden during normal >> system >> operation: You have to reconfigure all SMTP clients if something was >> changed >> in SMTP server configuration. >> For example: >> - the organization started to require authentication/SSL for all SMTP >> connections >> - mail server's address was changed >> - backup mail server was added >> etc. >> >> Also, consider the situation where 'replica in trouble' is unable to >> send a >> message for some reason (WAN link to/from branch office is down, >> MTA/machine >> crashed etc.) This should be handled by some general monitoring >> system. >> >> Another aspect is that admin could want to use another communication >> channel >> than e-mail or combination of more channels at once (send >> e-mail/Jabber >> message instantly + send SMS if severity >= CRITICAL). >> >> Yet another problem is that definition of 'severity' depends on >> organization. >> You have to have a component which translates message from machine to >> context >> organization-defined 'severity'. >> >> And then we have dependency problem: If authentication service is >> down, then >> you don't need explicit notification that all 20 IMAP servers doesn't >> work. >> >> etc. etc. >> >> >> IMHO, for those reasons we should implement 'a tool for replica health >> check' >> with reasonably detailed output and defer problems mentioned above to >> generic >> monitoring systems. The monitoring problem is way more complex than it >> seems >> after first look. >> >> If you takes monitoring seriously, you already have a monitoring >> system. If >> you don't, then line 'ipa health-check | mail admin at example.com' in >> cron is >> perfectly enough. >> >> Does it make sense? >> > Perfectly! > > Simo. > I agree too. I was not suggesting to replace any kind of deep monitoring rather a spot check for which the command above should be totally fine. -- 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 Thu Sep 5 15:28:24 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Sep 2013 11:28:24 -0400 Subject: [Freeipa-devel] [PATCH 0016] Add RADIUS proxy support to ipalib CLI In-Reply-To: <1378355347.19352.32.camel@localhost> References: <1378353973.19352.11.camel@localhost> <1378355347.19352.32.camel@localhost> Message-ID: <5228A318.7040604@redhat.com> On 09/05/2013 12:29 AM, Nathaniel McCallum wrote: > I forgot to mention that this code ignores the design page in one area: > radius-show does not list the users attached to this server. How > important is this? user-find --radius=MyRADIUSServer should find all the > users. > > Nathaniel > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel This is probably OK but then the design needs to be updated. Also I would suggest documenting that to get all users associated with a radius server you need to run the command above. -- 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 5 17:07:41 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 05 Sep 2013 19:07:41 +0200 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions Message-ID: <5228BA5D.8090702@redhat.com> Hello, I have some notes and questions on https://fedorahosted.org/freeipa/ticket/3566 (Control access of user roles to server functions). An IPA terminology refresher for reference: - ACI: The DS-level permission. - Permission: IPA object that encapsulates one ACI. Example: "add user". Permissions aren't as flexible as raw ACIs. - Privilege: IPA object that groups several permissions, e.g. with a "manage users" privilege you can "add user", "modify user", ... - Role: IPA object that groups privileges, e.g. an "User Administrator" can manage users and groups. Roles are assigned to users/groups/hosts. # Permission structure I think it would be best to have two permissions for each object, one for the entries and one for the container. This keeps the ACIs manageable with existing permission API: aci: (target = "ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX")(version 3.0;acl "permission:Read Groups";allow (read,search,compare) groupdn = "ldap:///cn=Read Groups,cn=permissions,cn=pbac,$SUFFIX";) aci: (target = "ldap:///cn=groups,cn=accounts,$SUFFIX")(version 3.0;acl "permission:Read Group Container";allow (read,search,compare) groupdn = "ldap:///cn=Read Group Container,cn=permissions,cn=pbac,$SUFFIX";) These would be combined in a "Group Readers" privilege. All the privileges would be granted to a role called "Users", which would contain ipausers and admins. # External users & system accounts I'm not sure how to handle external users here, since they're not added to any group. Either we'll need a special ACI for them, or somehow make it possible to add non-group sets of users to Roles. The same goes for system accounts, except those aren't even implemented in IPA yet (https://fedorahosted.org/freeipa/ticket/2801). # Protected attributes How to handle passwords and other non-public attributes? I'm thinking about keeping a global list of such attributes, and applying it to each read permission ACI on normal operations and upgrades; either generating a (targetfilter != ...) clause or filtering the (targetfilter = ...) one. Possibly that list would be configurable and stored in LDAP. For reference, we currently exclude these in the anonymous read rule: "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming" # Compat tree Do we want to reuse the read privileges for the compat tree, or create extra ones? # Combining read rights I think (read, search, compare) should be exposed in permission objects as a single right. Or is there a reason to keep it split? # P.S. I believe that we should strive to put our info about default permissions, containers, settings, and the schema for each plugin in the actual plugin module, rather than it all being split across several ldif/update files. This would make this data more manageable, introspectable and consistent, expose dependencies between plugins, and make it possible to actually write self-contained plugins. This should be done when the time comes for a new version of the ldap-updater. -- Petr? From sgallagh at redhat.com Thu Sep 5 17:34:07 2013 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 05 Sep 2013 13:34:07 -0400 Subject: [Freeipa-devel] [PATCH] IPA-CLIENT: NSS test needs to check against the domain name Message-ID: <5228C08F.80902@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In situations where the FreeIPA server is configured with different domain and realm values, we will fail to test for the admin account in the ipa-client-install script. With this patch, we will correctly run 'getent passwd admin at DOMAIN' -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIowI8ACgkQeiVVYja6o6ORiwCgnX1uVtWTktYpKdrVxuVTyQjZ WCsAn0ULhTR0TsfcCsEpknVwgkAN0d7F =KpH4 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-IPA-CLIENT-NSS-test-needs-to-check-against-the-domai.patch Type: text/x-patch Size: 1344 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-IPA-CLIENT-NSS-test-needs-to-check-against-the-domai.patch.sig Type: application/pgp-signature Size: 72 bytes Desc: not available URL: From rcritten at redhat.com Thu Sep 5 17:48:37 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Sep 2013 13:48:37 -0400 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <5228BA5D.8090702@redhat.com> References: <5228BA5D.8090702@redhat.com> Message-ID: <5228C3F5.5000505@redhat.com> Petr Viktorin wrote: > Hello, > I have some notes and questions on > https://fedorahosted.org/freeipa/ticket/3566 (Control access of user > roles to server functions). > > > An IPA terminology refresher for reference: > - ACI: The DS-level permission. > - Permission: IPA object that encapsulates one ACI. Example: "add user". > Permissions aren't as flexible as raw ACIs. > - Privilege: IPA object that groups several permissions, e.g. with a > "manage users" privilege you can "add user", "modify user", ... > - Role: IPA object that groups privileges, e.g. an "User Administrator" > can manage users and groups. Roles are assigned to users/groups/hosts. > > > # Permission structure > > I think it would be best to have two permissions for each object, one > for the entries and one for the container. This keeps the ACIs > manageable with existing permission API: > > aci: (target = "ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX")(version > 3.0;acl "permission:Read Groups";allow (read,search,compare) groupdn = > "ldap:///cn=Read Groups,cn=permissions,cn=pbac,$SUFFIX";) > > aci: (target = "ldap:///cn=groups,cn=accounts,$SUFFIX")(version 3.0;acl > "permission:Read Group Container";allow (read,search,compare) groupdn = > "ldap:///cn=Read Group Container,cn=permissions,cn=pbac,$SUFFIX";) > > These would be combined in a "Group Readers" privilege. > > All the privileges would be granted to a role called "Users", which > would contain ipausers and admins. I'm not sure I follow, what are you trying to achieve here? The more ACIs the slower the processing. > # External users & system accounts > > I'm not sure how to handle external users here, since they're not added > to any group. Either we'll need a special ACI for them, or somehow make > it possible to add non-group sets of users to Roles. > > The same goes for system accounts, except those aren't even implemented > in IPA yet (https://fedorahosted.org/freeipa/ticket/2801). I think they would have to be part of a group. Otherwise 389-ds has nothing to evaluate against (and even with groups I'm not 100% sure it'll work). > > # Protected attributes > > How to handle passwords and other non-public attributes? I'm thinking > about keeping a global list of such attributes, and applying it to each > read permission ACI on normal operations and upgrades; either generating > a (targetfilter != ...) clause or filtering the (targetfilter = ...) one. > Possibly that list would be configurable and stored in LDAP. > > For reference, we currently exclude these in the anonymous read rule: > "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword > || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || > ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming" It could get ugly real fast, and potentially cause a lot of extra processing. I think the object(s) for each attribute should be considered so these wouldn't have to be applied to every ACI but only those that are affected. We don't need to worry about userPassword in groups, for example. > > # Compat tree > > Do we want to reuse the read privileges for the compat tree, or create > extra ones? I don't think so. > > > # Combining read rights > > I think (read, search, compare) should be exposed in permission objects > as a single right. Or is there a reason to keep it split? Yes, they are separate for a reason. Using only search and compare isn't common, but it isn't unheard of either. For example, to be able to detect the presence of an attribute you can provide just the search permission. > > # P.S. > > I believe that we should strive to put our info about default > permissions, containers, settings, and the schema for each plugin in the > actual plugin module, rather than it all being split across several > ldif/update files. This would make this data more manageable, > introspectable and consistent, expose dependencies between plugins, and > make it possible to actually write self-contained plugins. > This should be done when the time comes for a new version of the > ldap-updater. I don't think we really have any problems having a more or less monolithic set up now. I think this would just add complexity. rob From rcritten at redhat.com Thu Sep 5 17:50:02 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Sep 2013 13:50:02 -0400 Subject: [Freeipa-devel] FreeIPA server package group In-Reply-To: <5224B194.1060909@redhat.com> References: <521B09B2.3080907@redhat.com> <521B0DD9.4000209@redhat.com> <521B0E6A.1080709@redhat.com> <521DC6F7.8030409@redhat.com> <521DCAD6.7090800@redhat.com> <521DCEF2.1040405@redhat.com> <521F1AA5.1030500@redhat.com> <521F20F0.4060605@redhat.com> <5224B194.1060909@redhat.com> Message-ID: <5228C44A.60407@redhat.com> Martin Kosek wrote: > On 08/29/2013 12:22 PM, Tomas Babej wrote: >> On 08/29/2013 11:55 AM, Petr Viktorin wrote: >>> On 08/28/2013 12:20 PM, Tomas Babej wrote: >>>> On 08/28/2013 12:03 PM, Petr Viktorin wrote: >>>>> On 08/28/2013 11:46 AM, Tomas Babej wrote: >>>>>> On 08/26/2013 10:14 AM, Tomas Babej wrote: >>>>>>> On Mon 26 Aug 2013 10:12:09 AM CEST, Petr Vobornik wrote: >>>>>>>> On 08/26/2013 09:54 AM, Tomas Babej wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I cooked up a patch for comps that adds a FreeIPA package group. >>>>>>>>> >>>>>>>>> Please chime in if you're OK with package selection / description. >>>>>>>>> >>>>>>>>> For illustration, see the attached image. FreeIPA will be added as an >>>>>>>>> add-on in an installer under the Infrastructure server environment, >>>>>>>>> that means, in the included images it will be at the same level >>>>>>>>> as DNS or FTP server. >>>>>>>>> >>>>>>>>> It will also appear in the Software Selection tool (PackageKit). >>>>>>>>> >>>>>>>>> It should also be available under as yum groupinstall "FreeIPA >>>>>>>>> server", >>>>>>>>> and in PackageKit, as I understand comps is also source for that too. >>>>>>>>> >>>>>>>>> https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3630 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> IMO the Audit part in the description is false advertisement. Same >>>>>>>> issue is in package descriptions. >>>>>>> >>>>>>> I know, it's taken directly from there. >>>>>>> >>>>>>> I'd rather have it consistent, if we're going to change it here, we >>>>>>> should do >>>>>>> there too, so that we do not end up with multiple (seemingly >>>>>>> incomplete) >>>>>>> descriptions at various places. >>>>>> >>>>>> Anybody else does have any other concerns? We need to move with this >>>>>> effort since string freeze for F20 is coming. >>>>>> >>>>>> I'm particulary dubious about including the freeipa-tests package. >>>>> >>>>> I don't think that should be included, developer tests are unnecessary >>>>> for a server. >>>>> >>>> It was marked as optional in the initial proposal, but I agree it's >>>> unnecessary for >>>> it to be there at all. >>>>>> We discussed the A (as Audit) part in the description with Rob. The >>>>>> fact is >>>>>> that this is taken from the freeipa-server package description and >>>>>> nobody >>>>>> complained in 7 years. >>>>> >>>> >>>> Updated tests attached. >>>> >>> >>> Oh, one more thing I remembered just now -- is it too late? >>> We should include bind-dyndb-ldap (which pulls in bind). Preferably as default. >>> >> >> I included it there. >> >> If anyone else wants to chime in, please do now, I'll create a ticket with >> rel-eng at the end of the day. >> > > Thanks for this effort. What is the status of the bug - did you create the > request already? > > We will need to do one more change and remove freeipa-server-strict package as > up on the decision on today's developer meeting we decided to drop this > subpackage in Fedora 20 and later and depend on our new FreeIPA Continuous > Integration system instead. I missed that meeting so maybe I'm re-hashing things, but I don't see how CI solves the problem that the strict subpackage does. Sure, it won't be as much a surprise to us when other packages are updated, but this doesn't prevent a user from also updating to the package. The strict package prevents upgrade until we've confirmed that things are actually working. CI does not. rob From lslebodn at redhat.com Thu Sep 5 21:25:17 2013 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Thu, 5 Sep 2013 23:25:17 +0200 Subject: [Freeipa-devel] =?utf-8?q?=5BPATCH=5D=C2=A0Debian__client_support?= In-Reply-To: <5225066B.3010003@ubuntu.com> References: <5225066B.3010003@ubuntu.com> Message-ID: <20130905212516.GB24203@mail.corp.redhat.com> On (03/09/13 00:43), Timo Aaltonen wrote: > >This fixes https://fedorahosted.org/freeipa/ticket/1887 >and >https://fedorahosted.org/freeipa/ticket/2455 > >the first three patches fix some bugs in how python is used >fourth patch checks if dbus is already running before trying to start it >fifth fixes some compilation warnings >sixth finally adds the Debian platform module > > > >there are also distro patches that aren't upstreamable as-is, that do >stuff like >- give--install-layout=deb to setup.py >- disable make-testcert since it needs a server running >- fix hardcoded NFS related paths and a variable in ipa-client-automount >- fix ldap.conf path in ipa-client-install >- fix ntpdate options in ntpconf.py (Debian doesn't patch ntpdate like >Fedora) >- change nss includes in ipa_pwd.c ( not ) Solution is simple. Use pkg-config generated NSS_CFLAGS bash$ pkg-config --cflags nss -I/usr/include/nss -I/usr/include/nspr bash$ uname -a Linux positron 3.10-2-686-pae #1 SMP Debian 3.10.5-1 (2013-08-07) i686 GNU/Linux bash$pkg-config --cflags nss -I/usr/include/nss3 -I/usr/include/nspr4 bash$uname -a Linux unused-4-233.brq.redhat.com 3.10.10-200.fc19.x86_64 #1 SMP Thu Aug 29 19:05:45 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux It works in sssd. I can send a patch. LS > >dunno what to do about those, the packaging can keep on carrying those >but if you have ideas how to make them configurable so that upstream >git/tarball could be used for development/testing on Debian then that >would be nice. > >t >From b08da1b7712f9621283719b190134586e59fb333 Mon Sep 17 00:00:00 2001 >From: Timo Aaltonen >Date: Tue, 3 Sep 2013 00:01:12 +0300 >Subject: [PATCH 1/6] Use /usr/bin/python as fallback python path > >--- > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/Makefile b/Makefile >index a21cf7e33275fd1a783e89baf237c8dcd8db6508..428f19b1a83da8c424893ea35c901f52dafaf546 100644 >--- a/Makefile >+++ b/Makefile >@@ -50,7 +50,7 @@ ifneq ($(DEVELOPER_MODE),0) > LINT_OPTIONS=--no-fail > endif > >-PYTHON ?= $(shell rpm -E %__python) >+PYTHON ?= $(shell rpm -E %__python || echo /usr/bin/python) > > all: bootstrap-autogen server tests > @for subdir in $(SUBDIRS); do \ >-- >1.8.3.2 > >From 7360486d7ed343202062716c0eb4f731923bb509 Mon Sep 17 00:00:00 2001 >From: Timo Aaltonen >Date: Tue, 3 Sep 2013 00:03:12 +0300 >Subject: [PATCH 2/6] Don't search platform path > >Don't use Python.h from the platform specific path >--- > ipapython/py_default_encoding/setup.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/ipapython/py_default_encoding/setup.py b/ipapython/py_default_encoding/setup.py >index de2478c1962aba7a78919efdb266bf0600965905..6a1af628272c6cd3eaa755c5728a7a5d020050ec 100644 >--- a/ipapython/py_default_encoding/setup.py >+++ b/ipapython/py_default_encoding/setup.py >@@ -22,7 +22,7 @@ from distutils.sysconfig import get_python_inc > import sys > import os > >-python_header = os.path.join(get_python_inc(plat_specific=1), 'Python.h') >+python_header = os.path.join(get_python_inc(plat_specific=0), 'Python.h') > if not os.path.exists(python_header): > sys.exit("Cannot find Python development packages that provide Python.h") > >-- >1.8.3.2 > >From be86f0a9bbc3196aa8808243aba6d7e68c6d083b Mon Sep 17 00:00:00 2001 >From: Nick Hatch >Date: Tue, 3 Sep 2013 00:08:13 +0300 >Subject: [PATCH 3/6] Don't exclude symlinks when loading plugins > >--- > ipalib/util.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/ipalib/util.py b/ipalib/util.py >index 3c52e4fd9a3e08d160dd4ae7076590be8b869d2c..e14077487e979f077ddc1f9e925678884a64b5b5 100644 >--- a/ipalib/util.py >+++ b/ipalib/util.py >@@ -81,7 +81,7 @@ def find_modules_in_dir(src_dir): > if not name.endswith(suffix): > continue > pyfile = os.path.join(src_dir, name) >- if os.path.islink(pyfile) or not os.path.isfile(pyfile): >+ if not os.path.isfile(pyfile): > continue > module = name[:-len(suffix)] > if module == '__init__': >-- >1.8.3.2 > >From 34d002d5483b9853a8329215ab12c946b8df7525 Mon Sep 17 00:00:00 2001 >From: Nick Hatch >Date: Tue, 3 Sep 2013 00:10:30 +0300 >Subject: [PATCH 4/6] Check dbus before starting it > >Check to see if the messagebus (dbus) is running before attempting to start it >--- > ipa-client/ipa-install/ipa-client-install | 18 ++++++++++-------- > 1 file changed, 10 insertions(+), 8 deletions(-) > >diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install >index 280edd793326150c416fe1b82f9866435e9c6509..7241a3421e348666c47f03a9b4fdac472b2ccabb 100755 >--- a/ipa-client/ipa-install/ipa-client-install >+++ b/ipa-client/ipa-install/ipa-client-install >@@ -372,10 +372,11 @@ def uninstall(options, env): > # Always start certmonger. We can't untrack something if it isn't > # running > messagebus = ipaservices.knownservices.messagebus >- try: >- messagebus.start() >- except Exception, e: >- log_service_error(messagebus.service_name, 'start', e) >+ if not messagebus.is_running(): >+ try: >+ messagebus.start() >+ except Exception, e: >+ log_service_error(messagebus.service_name, 'start', e) > > cmonger = ipaservices.knownservices.certmonger > try: >@@ -970,10 +971,11 @@ def configure_certmonger(fstore, subject_base, cli_realm, hostname, options, > principal = 'host/%s@%s' % (hostname, cli_realm) > > messagebus = ipaservices.knownservices.messagebus >- try: >- messagebus.start() >- except Exception, e: >- log_service_error(messagebus.service_name, 'start', e) >+ if not messagebus.is_running(): >+ try: >+ messagebus.start() >+ except Exception, e: >+ log_service_error(messagebus.service_name, 'start', e) > > # Ensure that certmonger has been started at least once to generate the > # cas files in /var/lib/certmonger/cas. >-- >1.8.3.2 > >From 926f2371eaa5166f39f1c25832bb502befca6d4e Mon Sep 17 00:00:00 2001 >From: Krzysztof Klimonda >Date: Tue, 3 Sep 2013 00:12:26 +0300 >Subject: [PATCH 5/6] Fix -Wformat-security warnings > >--- > daemons/ipa-slapi-plugins/ipa-enrollment/ipa_enrollment.c | 6 +++--- > daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 8 ++++---- > 2 files changed, 7 insertions(+), 7 deletions(-) > >diff --git a/daemons/ipa-slapi-plugins/ipa-enrollment/ipa_enrollment.c b/daemons/ipa-slapi-plugins/ipa-enrollment/ipa_enrollment.c >index 9f884bd39233adf90b0f4eff1868885d587d351a..22c40f2bcfc527127b745e1efde5977b148c78a8 100644 >--- a/daemons/ipa-slapi-plugins/ipa-enrollment/ipa_enrollment.c >+++ b/daemons/ipa-slapi-plugins/ipa-enrollment/ipa_enrollment.c >@@ -317,7 +317,7 @@ free_and_return: > > if (krbLastPwdChange) slapi_ch_free_string(&krbLastPwdChange); > >- LOG(errMesg ? errMesg : "success\n"); >+ LOG("%s", errMesg ? errMesg : "success\n"); > slapi_send_ldap_result(pb, rc, NULL, errMesg, 0, NULL); > > free(principal); >@@ -344,7 +344,7 @@ ipaenrollment_extop(Slapi_PBlock *pb) > if (slapi_pblock_get(pb, SLAPI_EXT_OP_REQ_OID, &oid ) != 0) { > errMesg = "Could not get OID and value from request.\n"; > rc = LDAP_OPERATIONS_ERROR; >- LOG(errMesg); >+ LOG("%s", errMesg); > goto free_and_return; > } > >@@ -357,7 +357,7 @@ ipaenrollment_extop(Slapi_PBlock *pb) > rc = LDAP_OPERATIONS_ERROR; > > free_and_return: >- LOG(errMesg); >+ LOG("%s", errMesg); > slapi_send_ldap_result(pb, rc, NULL, errMesg, 0, NULL); > > return SLAPI_PLUGIN_EXTENDED_SENT_RESULT; >diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c >index 1058c313d1f2a193eb7fae621bc9c5d103fb6d5f..c3e0ebd9d90f393be031b26fadcedd00f6091a8d 100644 >--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c >+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c >@@ -573,7 +573,7 @@ free_and_return: > if (targetEntry) slapi_entry_free(targetEntry); > if (ber) ber_free(ber, 1); > >- LOG(errMesg ? errMesg : "success"); >+ LOG("%s", errMesg ? errMesg : "success"); > slapi_send_ldap_result(pb, rc, NULL, errMesg, 0, NULL); > > return SLAPI_PLUGIN_EXTENDED_SENT_RESULT; >@@ -1143,7 +1143,7 @@ free_and_return: > > if (rc == LDAP_SUCCESS) > errMesg = NULL; >- LOG(errMesg ? errMesg : "success"); >+ LOG("%s", errMesg ? errMesg : "success"); > slapi_send_ldap_result(pb, rc, NULL, errMesg, 0, NULL); > > return SLAPI_PLUGIN_EXTENDED_SENT_RESULT; >@@ -1170,7 +1170,7 @@ static int ipapwd_extop(Slapi_PBlock *pb) > if (slapi_pblock_get(pb, SLAPI_EXT_OP_REQ_OID, &oid) != 0) { > errMesg = "Could not get OID value from request.\n"; > rc = LDAP_OPERATIONS_ERROR; >- LOG(errMesg); >+ LOG("%s", errMesg); > goto free_and_return; > } else { > LOG("Received extended operation request with OID %s\n", oid); >@@ -1193,7 +1193,7 @@ static int ipapwd_extop(Slapi_PBlock *pb) > free_and_return: > if (krbcfg) free_ipapwd_krbcfg(&krbcfg); > >- LOG(errMesg); >+ LOG("%s", errMesg); > slapi_send_ldap_result(pb, rc, NULL, errMesg, 0, NULL); > > return SLAPI_PLUGIN_EXTENDED_SENT_RESULT; >-- >1.8.3.2 > >From 9890f5ac23d927a668097f42a799219ea33b5cbc Mon Sep 17 00:00:00 2001 >From: Timo Aaltonen >Date: Tue, 3 Sep 2013 00:23:09 +0300 >Subject: [PATCH] Add Debian client platform support > >--- > ipapython/platform/debian/__init__.py | 43 ++++++++++++++ > ipapython/platform/debian/auth.py | 38 ++++++++++++ > ipapython/platform/debian/service.py | 107 ++++++++++++++++++++++++++++++++++ > ipapython/setup.py.in | 1 + > 4 files changed, 189 insertions(+) > create mode 100644 ipapython/platform/debian/__init__.py > create mode 100644 ipapython/platform/debian/auth.py > create mode 100644 ipapython/platform/debian/service.py > >diff --git a/ipapython/platform/debian/__init__.py b/ipapython/platform/debian/__init__.py >new file mode 100644 >index 0000000000000000000000000000000000000000..0312b554521b314b9afe1a460ed3856b493de2bb >--- /dev/null >+++ b/ipapython/platform/debian/__init__.py >@@ -0,0 +1,43 @@ >+import os >+ >+from ipapython.platform import base, redhat, fedora18 >+from ipapython.platform.debian.auth import DebianAuthConfig >+from ipapython.platform.debian.service import debian_service, DebianServices >+ >+# All what we allow exporting directly from this module >+# Everything else is made available through these symbols when they are >+# directly imported into ipapython.services: >+# >+# authconfig -- class reference for platform-specific implementation of >+# authconfig(8) >+# service -- class reference for platform-specific implementation of a >+# PlatformService class >+# knownservices -- factory instance to access named services IPA cares about, >+# names are ipapython.services.wellknownservices >+# backup_and_replace_hostname -- platform-specific way to set hostname and >+# make it persistent over reboots >+# restore_network_configuration -- platform-specific way of restoring network >+# configuration (e.g. static hostname) >+# restore_context -- platform-sepcific way to restore security context, if >+# applicable >+# check_selinux_status -- platform-specific way to see if SELinux is enabled >+# and restorecon is installed. >+__all__ = ['authconfig', 'service', 'knownservices', >+ 'backup_and_replace_hostname', 'restore_context', 'check_selinux_status', >+ 'restore_network_configuration', 'timedate_services'] >+ >+# Just copy a referential list of timedate services >+timedate_services = list(base.timedate_services) >+ >+def restore_network_configuration(fstore, statestore): >+ filepath = '/etc/hostname' >+ if fstore.has_file(filepath): >+ fstore.restore_file(filepath) >+ hostname_was_configured = True >+ >+authconfig = DebianAuthConfig >+service = debian_service >+knownservices = DebianServices() >+backup_and_replace_hostname = fedora18.backup_and_replace_hostname >+restore_context = redhat.restore_context >+check_selinux_status = redhat.check_selinux_status >diff --git a/ipapython/platform/debian/auth.py b/ipapython/platform/debian/auth.py >new file mode 100644 >index 0000000000000000000000000000000000000000..76e5c90255dc4a0c4830062a54bd237f10d5ca1b >--- /dev/null >+++ b/ipapython/platform/debian/auth.py >@@ -0,0 +1,38 @@ >+from ipapython.platform import base >+ >+class DebianAuthConfig(base.AuthConfig): >+ """ >+ Debian implementation of the AuthConfig class. >+ >+ Debian doesn't provide a single application for changing both >+ nss and pam configuration. PAM can be configured using debconf but there >+ is currently no such solution for updating NSS database and every package >+ does it by itself. >+ """ >+ >+ def __build_args(self): >+ args = ['--force'] >+ for (option, value) in self.parameters.items(): >+ if option == "sssdauth": >+ option = "sss" >+ # only sssd supported, filter the dupe >+ elif option in ["sssd", "krb5", "ldap", "update"]: >+ option = "" >+ if type(value) is bool: >+ if value: >+ if not "package" in args: >+ args.append("--package %s" % (option)) >+ else: >+ args.append("%s" % (option)) >+ else: >+ if not any("remove" in s for s in args): >+ args.append("--remove %s" % (option)) >+ else: >+ args.append("%s" % (option)) >+ >+ >+ def execute(self): >+ env = "DEBCONF_FRONTEND=noninteractive" >+ args = self.__build_args() >+ ipautil.run(["/usr/sbin/pam-auth-update"]+args,env) >+ >diff --git a/ipapython/platform/debian/service.py b/ipapython/platform/debian/service.py >new file mode 100644 >index 0000000000000000000000000000000000000000..dadd250c4e8cf393453b2c7d6344a6e612c79ad3 >--- /dev/null >+++ b/ipapython/platform/debian/service.py >@@ -0,0 +1,107 @@ >+import time >+ >+from ipapython import ipautil >+from ipapython.ipa_log_manager import root_logger >+from ipapython.platform import base >+from ipalib import api >+ >+class DebianService(base.PlatformService): >+ def __wait_for_open_ports(self, instance_name=""): >+ """ >+ If this is a service we need to wait for do so. >+ """ >+ ports = None >+ if instance_name in base.wellknownports: >+ ports = base.wellknownports[instance_name] >+ else: >+ if self.service_name in base.wellknownports: >+ ports = base.wellknownports[self.service_name] >+ if ports: >+ ipautil.wait_for_open_ports('localhost', ports, api.env.startup_timeout) >+ def stop(self, instance_name='', capture_output=True): >+ ipautil.run(["/usr/sbin/service", self.service_name, "stop", >+ instance_name], capture_output=capture_output) >+ if 'context' in api.env and api.env.context in ['ipactl', 'installer']: >+ update_service_list = True >+ else: >+ update_service_list = False >+ super(DebianService, self).stop(instance_name) >+ >+ def start(self, instance_name='', capture_output=True, wait=True): >+ ipautil.run(["/usr/sbin/service", self.service_name, "start", >+ instance_name], capture_output=capture_output) >+ if 'context' in api.env and api.env.context in ['ipactl', 'installer']: >+ update_service_list = True >+ else: >+ update_service_list = False >+ if wait and self.is_running(instance_name): >+ self.__wait_for_open_ports(instance_name) >+ super(DebianService, self).start(instance_name) >+ >+ def restart(self, instance_name='', capture_output=True, wait=True): >+ ipautil.run(["/usr/sbin/service", self.service_name, "restart", >+ instance_name], capture_output=capture_output) >+ if wait and self.is_running(instance_name): >+ self.__wait_for_open_ports(instance_name) >+ >+ def is_running(self, instance_name=""): >+ ret = True >+ try: >+ (sout, serr, rcode) = ipautil.run(["/usr/sbin/service", >+ self.service_name, "status", >+ instance_name]) >+ if sout.find("NOT running") >= 0: >+ ret = False >+ if sout.find("stop") >= 0: >+ ret = False >+ except ipautil.CalledProcessError: >+ ret = False >+ return ret >+ >+ def is_installed(self): >+ installed = True >+ try: >+ ipautil.run(["/usr/sbin/service", self.service_name, "status"]) >+ except ipautil.CalledProcessError, e: >+ if e.returncode == 1: >+ # service is not installed or there is other serious issue >+ installed = False >+ return installed >+ >+ def is_enabled(self, instance_name=""): >+ # Services are always assumed to be enabled when installed >+ return True >+ >+ def enable(self): >+ return True >+ >+ def disable(self): >+ return True >+ >+ def install(self): >+ return True >+ >+ def remove(self): >+ return True >+ >+class DebianSSHService(DebianService): >+ def get_config_dir(self, instance_name=""): >+ return '/etc/ssh' >+ >+def debian_service(name): >+ if name == 'sshd': >+ return DebianSSHService(name) >+ return DebianService(name) >+ >+class DebianServices(base.KnownServices): >+ def __init__(self): >+ services = dict() >+ for s in base.wellknownservices: >+ if s == "messagebus": >+ services[s] = debian_service("dbus") >+ elif s == "ntpd": >+ services[s] = debian_service("ntp") >+ else: >+ services[s] = debian_service(s) >+ # Call base class constructor. This will lock services to read-only >+ super(DebianServices, self).__init__(services) >diff --git a/ipapython/setup.py.in b/ipapython/setup.py.in >index d3bbcaf1e46528d50731ca18a96a3384f6b49548..9ebd76bf14d6cd8033c7d3d4922d0a949475d3c0 100644 >--- a/ipapython/setup.py.in >+++ b/ipapython/setup.py.in >@@ -68,6 +68,7 @@ def setup_package(): > packages = [ "ipapython", > "ipapython.platform", > "ipapython.platform.base", >+ "ipapython.platform.debian", > "ipapython.platform.fedora16", > "ipapython.platform.fedora18", > "ipapython.platform.redhat" ], >-- >1.8.3.2 > >_______________________________________________ >Freeipa-devel mailing list >Freeipa-devel at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-devel From jcholast at redhat.com Fri Sep 6 06:27:40 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 06 Sep 2013 08:27:40 +0200 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <5228C3F5.5000505@redhat.com> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> Message-ID: <522975DC.2070803@redhat.com> On 5.9.2013 19:48, Rob Crittenden wrote: > Petr Viktorin wrote: >> # External users & system accounts >> >> I'm not sure how to handle external users here, since they're not added >> to any group. Either we'll need a special ACI for them, or somehow make >> it possible to add non-group sets of users to Roles. >> >> The same goes for system accounts, except those aren't even implemented >> in IPA yet (https://fedorahosted.org/freeipa/ticket/2801). > > I think they would have to be part of a group. Otherwise 389-ds has > nothing to evaluate against (and even with groups I'm not 100% sure > it'll work). Once external users are mapped to entries in the directory (https://fedorahosted.org/freeipa/ticket/3242), they can be handled more or less the same way as internal users. Honza -- Jan Cholasta From mkosek at redhat.com Fri Sep 6 06:26:52 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Sep 2013 08:26:52 +0200 Subject: [Freeipa-devel] FreeIPA server package group In-Reply-To: <5228C44A.60407@redhat.com> References: <521B09B2.3080907@redhat.com> <521B0DD9.4000209@redhat.com> <521B0E6A.1080709@redhat.com> <521DC6F7.8030409@redhat.com> <521DCAD6.7090800@redhat.com> <521DCEF2.1040405@redhat.com> <521F1AA5.1030500@redhat.com> <521F20F0.4060605@redhat.com> <5224B194.1060909@redhat.com> <5228C44A.60407@redhat.com> Message-ID: <522975AC.9020308@redhat.com> On 09/05/2013 07:50 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 08/29/2013 12:22 PM, Tomas Babej wrote: >>> On 08/29/2013 11:55 AM, Petr Viktorin wrote: >>>> On 08/28/2013 12:20 PM, Tomas Babej wrote: >>>>> On 08/28/2013 12:03 PM, Petr Viktorin wrote: >>>>>> On 08/28/2013 11:46 AM, Tomas Babej wrote: >>>>>>> On 08/26/2013 10:14 AM, Tomas Babej wrote: >>>>>>>> On Mon 26 Aug 2013 10:12:09 AM CEST, Petr Vobornik wrote: >>>>>>>>> On 08/26/2013 09:54 AM, Tomas Babej wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I cooked up a patch for comps that adds a FreeIPA package group. >>>>>>>>>> >>>>>>>>>> Please chime in if you're OK with package selection / description. >>>>>>>>>> >>>>>>>>>> For illustration, see the attached image. FreeIPA will be added as an >>>>>>>>>> add-on in an installer under the Infrastructure server environment, >>>>>>>>>> that means, in the included images it will be at the same level >>>>>>>>>> as DNS or FTP server. >>>>>>>>>> >>>>>>>>>> It will also appear in the Software Selection tool (PackageKit). >>>>>>>>>> >>>>>>>>>> It should also be available under as yum groupinstall "FreeIPA >>>>>>>>>> server", >>>>>>>>>> and in PackageKit, as I understand comps is also source for that too. >>>>>>>>>> >>>>>>>>>> https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3630 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> IMO the Audit part in the description is false advertisement. Same >>>>>>>>> issue is in package descriptions. >>>>>>>> >>>>>>>> I know, it's taken directly from there. >>>>>>>> >>>>>>>> I'd rather have it consistent, if we're going to change it here, we >>>>>>>> should do >>>>>>>> there too, so that we do not end up with multiple (seemingly >>>>>>>> incomplete) >>>>>>>> descriptions at various places. >>>>>>> >>>>>>> Anybody else does have any other concerns? We need to move with this >>>>>>> effort since string freeze for F20 is coming. >>>>>>> >>>>>>> I'm particulary dubious about including the freeipa-tests package. >>>>>> >>>>>> I don't think that should be included, developer tests are unnecessary >>>>>> for a server. >>>>>> >>>>> It was marked as optional in the initial proposal, but I agree it's >>>>> unnecessary for >>>>> it to be there at all. >>>>>>> We discussed the A (as Audit) part in the description with Rob. The >>>>>>> fact is >>>>>>> that this is taken from the freeipa-server package description and >>>>>>> nobody >>>>>>> complained in 7 years. >>>>>> >>>>> >>>>> Updated tests attached. >>>>> >>>> >>>> Oh, one more thing I remembered just now -- is it too late? >>>> We should include bind-dyndb-ldap (which pulls in bind). Preferably as >>>> default. >>>> >>> >>> I included it there. >>> >>> If anyone else wants to chime in, please do now, I'll create a ticket with >>> rel-eng at the end of the day. >>> >> >> Thanks for this effort. What is the status of the bug - did you create the >> request already? >> >> We will need to do one more change and remove freeipa-server-strict package as >> up on the decision on today's developer meeting we decided to drop this >> subpackage in Fedora 20 and later and depend on our new FreeIPA Continuous >> Integration system instead. > > I missed that meeting so maybe I'm re-hashing things, but I don't see how CI > solves the problem that the strict subpackage does. Sure, it won't be as much a > surprise to us when other packages are updated, but this doesn't prevent a user > from also updating to the package. The strict package prevents upgrade until > we've confirmed that things are actually working. CI does not. CI should prevent problems at the begging, before they happen - right when the new Dogtag/Kerberos/389-ds-base is in updates-testing. That gives a change to give negative Karma and have that package fixed before it hits stable updates. IMO freeipa-server-strict subpackage is too heavy weight and does not provide the benefit we would want. So far, IMHO, it was rather a burden for maintainers and broke quite frequently. Martin From mkosek at redhat.com Fri Sep 6 07:26:22 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Sep 2013 09:26:22 +0200 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <5228C3F5.5000505@redhat.com> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> Message-ID: <5229839E.9070105@redhat.com> On 09/05/2013 07:48 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> Hello, >> I have some notes and questions on >> https://fedorahosted.org/freeipa/ticket/3566 (Control access of user >> roles to server functions). >> >> >> An IPA terminology refresher for reference: >> - ACI: The DS-level permission. >> - Permission: IPA object that encapsulates one ACI. Example: "add user". >> Permissions aren't as flexible as raw ACIs. >> - Privilege: IPA object that groups several permissions, e.g. with a >> "manage users" privilege you can "add user", "modify user", ... >> - Role: IPA object that groups privileges, e.g. an "User Administrator" >> can manage users and groups. Roles are assigned to users/groups/hosts. >> >> >> # Permission structure >> >> I think it would be best to have two permissions for each object, one >> for the entries and one for the container. This keeps the ACIs >> manageable with existing permission API: >> >> aci: (target = "ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX")(version >> 3.0;acl "permission:Read Groups";allow (read,search,compare) groupdn = >> "ldap:///cn=Read Groups,cn=permissions,cn=pbac,$SUFFIX";) >> >> aci: (target = "ldap:///cn=groups,cn=accounts,$SUFFIX")(version 3.0;acl >> "permission:Read Group Container";allow (read,search,compare) groupdn = >> "ldap:///cn=Read Group Container,cn=permissions,cn=pbac,$SUFFIX";) >> >> These would be combined in a "Group Readers" privilege. >> >> All the privileges would be granted to a role called "Users", which >> would contain ipausers and admins. > > I'm not sure I follow, what are you trying to achieve here? The more ACIs the > slower the processing. One of the main reason for this feature is to get rid of the global allowing ACI: aci: (targetfilter = "(&(!(objectClass=ipaToken))(!(objectClass=ipatokenTOTP))(!(objectClass=ipatokenRadiusConfiguration)))")(target != "ldap:///idnsname=*,cn=dns,$SUFFIX")(targetattr != "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming")(version 3.0; acl "Enable Anonymous access"; allow (read, search, compare) userdn = "ldap:///anyone";) ... as this ACI does not scale and adds burden for developers or plugin author wishing to add an attribute that should not be visible by default. Number of ACIs should still be kept low, that's true. > >> # External users & system accounts >> >> I'm not sure how to handle external users here, since they're not added >> to any group. Either we'll need a special ACI for them, or somehow make >> it possible to add non-group sets of users to Roles. >> >> The same goes for system accounts, except those aren't even implemented >> in IPA yet (https://fedorahosted.org/freeipa/ticket/2801). > > I think they would have to be part of a group. Otherwise 389-ds has nothing to > evaluate against (and even with groups I'm not 100% sure it'll work). > >> >> # Protected attributes >> >> How to handle passwords and other non-public attributes? I'm thinking >> about keeping a global list of such attributes, and applying it to each >> read permission ACI on normal operations and upgrades; either generating >> a (targetfilter != ...) clause or filtering the (targetfilter = ...) one. >> Possibly that list would be configurable and stored in LDAP. >> >> For reference, we currently exclude these in the anonymous read rule: >> "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword >> || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || >> ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming" > > It could get ugly real fast, and potentially cause a lot of extra processing. I > think the object(s) for each attribute should be considered so these wouldn't > have to be applied to every ACI but only those that are affected. We don't need > to worry about userPassword in groups, for example. I think that a decision that a param should not be included in default read rule should be included in the param object itself, see below. > >> >> # Compat tree >> >> Do we want to reuse the read privileges for the compat tree, or create >> extra ones? > > I don't think so. > >> >> >> # Combining read rights >> >> I think (read, search, compare) should be exposed in permission objects >> as a single right. Or is there a reason to keep it split? > > Yes, they are separate for a reason. Using only search and compare isn't > common, but it isn't unheard of either. For example, to be able to detect the > presence of an attribute you can provide just the search permission. Wouldn't most users use the (read, search, compare) triple? It would lower our number of ACIs significantly if we do not have 3 permissions per each object. > >> >> # P.S. >> >> I believe that we should strive to put our info about default >> permissions, containers, settings, and the schema for each plugin in the >> actual plugin module, rather than it all being split across several >> ldif/update files. This would make this data more manageable, >> introspectable and consistent, expose dependencies between plugins, and >> make it possible to actually write self-contained plugins. >> This should be done when the time comes for a new version of the >> ldap-updater. > > I don't think we really have any problems having a more or less monolithic set > up now. I think this would just add complexity. I actually think this could be a killer feature for the refactored ACI system. Let's take a host object as an example: class host(LDAPObject): """ Host object. """ ... takes_params = ( Str('fqdn', _hostname_validator, Str('description?', Str('l?', Str('nshostlocation?', Str('nshardwareplatform?', Str('nsosversion?', Str('userpassword?', Flag('random?', Str('randompassword?', Bytes('usercertificate?', validate_certificate, Str('krbprincipalname?', Str('macaddress*', Str('ipasshpubkey*', validate_sshpubkey_no_options, Str('userclass*', ) + ticket_flags_params ... It has the following standard default ACIs: aci: (target = "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX")(version 3.0;acl "permission:Add Hosts";allow (add) groupdn = "ldap:///cn=Add Hosts,cn=permissions,cn=pbac,$SUFFIX";) aci: (target = "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX")(version 3.0;acl "permission:Remove Hosts";allow (delete) groupdn = "ldap:///cn=Remove Hosts,cn=permissions,cn=pbac,$SUFFIX";) aci: (targetattr = "description || l || nshostlocation || nshardwareplatform || nsosversion")(target = "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX")(version 3.0;acl "permission:Modify Hosts";allow (write) groupdn = "ldap:///cn=Modify Hosts,cn=permissions,cn=pbac,$SUFFIX";) Out of those: - Add hosts is standard and can be generated automatically from host container and host primary key. - Remove Hosts is also standard and can be generated - Modify Hosts is a bit tricky as we have a list of host attributes that can be updated by default. Right now, this list is not maintained as it lies somewhere in delegation.ldif or some of our *.update file. - New Read Hosts could be also generated, we would just need to filter out attributes we do not want to be read (this should be recorded in the Param object itself, see even more below). This leads to outdated permissions not allowing privileged users to modify some parts of the host entry. Just to demonstrate, I found these 2 missing rights when testing a regular user with "Host Administrators" privilege: # kinit fbar # ipa host-add foo.example.com --force # ipa host-mod foo.example.com --macaddress=00:11:22:33:44:55 ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'macAddress' attribute of entry 'fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. # ipa host-mod foo.example.com --class foo ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'userClass' attribute of entry 'fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. If the basic set of host ACI would be part of the host LDAPObject, we would have everything in one place and avoid issues like that. Default write privilege could be generated out of the takes_params. We would just need to filter out parameters that we do not want to be writable in default ACI, for example ipasshpubkey where we have a separate permission. We could mark this in the param: ... Str('ipasshpubkey*', validate_sshpubkey_no_options, ... default_aci=False ), ... and define a custom ACIs handling it and other special ACIs. Something like: class host(LDAPObject): """ Host object. """ ... extra_aci = [ ACI( dn=api.env.container_computers, name="Hosts can modify their own SSH public keys", attrs=['ipasshpubkey'], rights=['write'], bind='userdn = "ldap:///self"' ), ACI( dn=api.env.container_computers, name="Hosts can modify their own certs and keytabs", attrs=['usercertificate', 'krblastpwdchange', 'description', 'l', 'nshostlocation', 'nshardwareplatform', 'nsosversion'], rights=['write'], bind='userdn = "ldap:///self"' ), ACI( dn=api.env.container_computers, name="Hosts can manage other host Certificates and kerberos keys", attrs=['userCertificate', 'krbPrincipalKey'], rights=['write'], bind='userdn = "userattr = "parent[0,1].managedby#USERDN""' ), ... ] IMHO, this would have several benefits: 1) It would place Host entry, params and ACIs to one single location -> easier maintenance 2) It would make delegation.ldif and default-aci.ldif and *.update files shorter given that all these default ACIs would be removed 3) It would make lives easier for plugin authors which would not have to deploy LDIFs or *.update files to deploy a new plugin or modify functionality of an existing one. Makes sense? Martin From abokovoy at redhat.com Fri Sep 6 08:35:49 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 6 Sep 2013 11:35:49 +0300 Subject: [Freeipa-devel] [PATCHES] 0270-0271 Support for Pylint 1.0 In-Reply-To: <52283B41.1050103@redhat.com> References: <5211F39F.2010606@redhat.com> <5226E87D.7000005@redhat.com> <20130905060804.GK21212@redhat.com> <52283B41.1050103@redhat.com> Message-ID: <20130906083548.GR21212@redhat.com> On Thu, 05 Sep 2013, Petr Viktorin wrote: >On 09/05/2013 08:08 AM, Alexander Bokovoy wrote: >>On Wed, 04 Sep 2013, Petr Viktorin wrote: >>>On 08/19/2013 12:29 PM, Petr Viktorin wrote: >>>>Hello, >>>>The first patch fixes a minor problem that Pylint 1.0 finds in our code. >>>> >>>>The second patch makes make-lint compatible with Pylint 1.0. It contains >>>>a workaround for a Pylint bug; before pushing this we should wait for a >>>>while to see if a fixed Pylint is released. >>>> >>> >>>A fixed version of Pylint was released, bug workarounds are no longer >>>necessary. >>> >>>Updated patches attached. >>> >>>https://fedorahosted.org/freeipa/ticket/3865 >>I tried the patches and still see an error on up to date Fedora 19 >>(including updates-testing): >> >>./make-lint Traceback (most recent call last): >[...] >>TypeError: unbound method infer() must be called with Tuple instance as >>first argument (got InferenceContext instance instead) >> >> >>At this point I'm not sure whether it is astroid's issue or ours... >>Astroid did change from 0.24 to 1.0 on August 13th in Fedora (even in >>Fedora 19 where version updates after release are generally >>discouraged, especially in case of ABI change). > >Hello, >Please use Pylint 1.0.0-2. It seems it hasn't reached the mirrors >yet, you have the earlier buggy version. I do have pylint 1.0.0-2.fc19 and yet it fails with the same error message. Nothing works, I had to disable make-lint call in Makefile to continue development. -- / Alexander Bokovoy From pviktori at redhat.com Fri Sep 6 09:50:47 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Sep 2013 11:50:47 +0200 Subject: [Freeipa-devel] [PATCHES] 0270-0271 Support for Pylint 1.0 In-Reply-To: <20130906083548.GR21212@redhat.com> References: <5211F39F.2010606@redhat.com> <5226E87D.7000005@redhat.com> <20130905060804.GK21212@redhat.com> <52283B41.1050103@redhat.com> <20130906083548.GR21212@redhat.com> Message-ID: <5229A577.1040104@redhat.com> On 09/06/2013 10:35 AM, Alexander Bokovoy wrote: > On Thu, 05 Sep 2013, Petr Viktorin wrote: >> On 09/05/2013 08:08 AM, Alexander Bokovoy wrote: >>> On Wed, 04 Sep 2013, Petr Viktorin wrote: >>>> On 08/19/2013 12:29 PM, Petr Viktorin wrote: >>>>> Hello, >>>>> The first patch fixes a minor problem that Pylint 1.0 finds in our >>>>> code. >>>>> >>>>> The second patch makes make-lint compatible with Pylint 1.0. It >>>>> contains >>>>> a workaround for a Pylint bug; before pushing this we should wait >>>>> for a >>>>> while to see if a fixed Pylint is released. >>>>> >>>> >>>> A fixed version of Pylint was released, bug workarounds are no longer >>>> necessary. >>>> >>>> Updated patches attached. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3865 >>> I tried the patches and still see an error on up to date Fedora 19 >>> (including updates-testing): >>> >>> ./make-lint Traceback (most recent call last): >> [...] >>> TypeError: unbound method infer() must be called with Tuple instance as >>> first argument (got InferenceContext instance instead) >>> >>> >>> At this point I'm not sure whether it is astroid's issue or ours... >>> Astroid did change from 0.24 to 1.0 on August 13th in Fedora (even in >>> Fedora 19 where version updates after release are generally >>> discouraged, especially in case of ABI change). >> >> Hello, >> Please use Pylint 1.0.0-2. It seems it hasn't reached the mirrors yet, >> you have the earlier buggy version. > I do have pylint 1.0.0-2.fc19 and yet it fails with the same error > message. Nothing works, I had to disable make-lint call in Makefile to > continue development. > That is strange; I've confirmed on several machines that the -2.fc19 release fixes this bug. If you run pylint on the following code, do you also get the "unbound method infer()" error? (It's the upstream bug reproducer) import collections Point = collections.namedtuple('Point', ['x', 'y']) p = Point(x=1.0, y=2.0) print "Area: %.1f" % (p.x * p.y,) Can you check the FILE in `pydoc pylint` to make sure you're running pylint from the RPM? -- Petr? From pviktori at redhat.com Fri Sep 6 11:48:43 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Sep 2013 13:48:43 +0200 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <5229839E.9070105@redhat.com> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> <5229839E.9070105@redhat.com> Message-ID: <5229C11B.6060707@redhat.com> On 09/06/2013 09:26 AM, Martin Kosek wrote: > On 09/05/2013 07:48 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> Hello, >>> I have some notes and questions on >>> https://fedorahosted.org/freeipa/ticket/3566 (Control access of user >>> roles to server functions). [...] >>> >>> >>> # Permission structure >>> >>> I think it would be best to have two permissions for each object, one >>> for the entries and one for the container. This keeps the ACIs >>> manageable with existing permission API: >>> >>> aci: (target = "ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX")(version >>> 3.0;acl "permission:Read Groups";allow (read,search,compare) groupdn = >>> "ldap:///cn=Read Groups,cn=permissions,cn=pbac,$SUFFIX";) >>> >>> aci: (target = "ldap:///cn=groups,cn=accounts,$SUFFIX")(version 3.0;acl >>> "permission:Read Group Container";allow (read,search,compare) groupdn = >>> "ldap:///cn=Read Group Container,cn=permissions,cn=pbac,$SUFFIX";) >>> >>> These would be combined in a "Group Readers" privilege. >>> >>> All the privileges would be granted to a role called "Users", which >>> would contain ipausers and admins. >> >> I'm not sure I follow, what are you trying to achieve here? The more ACIs the >> slower the processing. Yes, but with a feature request for fine-grained read permissions, I don't see how we can get away without increasing the number of ACIs. If we want the ACIs to be manageable, we need two ACIs per object type - one for the object itself, one for the container. Alternatively we could combine the two with some clever filter tricks and build a smart UI on top to manage them. I don't want to go this route. We might be able to get away with one global system ACI to cover all containers, so each object type would only have one read ACI, but that's also quite ugly. A potential way to get performance back is to move ACIs from $SUFFIX to the actual container they apply to. What is the reason we put our ACIs on $SUFFIX? Is it so that we can easily find/list them later? > One of the main reason for this feature is to get rid of the global allowing ACI: > > aci: (targetfilter = > "(&(!(objectClass=ipaToken))(!(objectClass=ipatokenTOTP))(!(objectClass=ipatokenRadiusConfiguration)))")(target > != "ldap:///idnsname=*,cn=dns,$SUFFIX")(targetattr != "userPassword || > krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || > krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutgoing || > ipaNTTrustAuthIncoming")(version 3.0; acl "Enable Anonymous access"; allow > (read, search, compare) userdn = "ldap:///anyone";) > > ... as this ACI does not scale and adds burden for developers or plugin author > wishing to add an attribute that should not be visible by default. Number of > ACIs should still be kept low, that's true. > >> >>> # External users & system accounts >>> >>> I'm not sure how to handle external users here, since they're not added >>> to any group. Either we'll need a special ACI for them, or somehow make >>> it possible to add non-group sets of users to Roles. >>> >>> The same goes for system accounts, except those aren't even implemented >>> in IPA yet (https://fedorahosted.org/freeipa/ticket/2801). >> >> I think they would have to be part of a group. Otherwise 389-ds has nothing to >> evaluate against (and even with groups I'm not 100% sure it'll work). >> >>> >>> # Protected attributes >>> >>> How to handle passwords and other non-public attributes? I'm thinking >>> about keeping a global list of such attributes, and applying it to each >>> read permission ACI on normal operations and upgrades; either generating >>> a (targetfilter != ...) clause or filtering the (targetfilter = ...) one. >>> Possibly that list would be configurable and stored in LDAP. >>> >>> For reference, we currently exclude these in the anonymous read rule: >>> "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword >>> || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || >>> ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming" >> >> It could get ugly real fast, and potentially cause a lot of extra processing. I >> think the object(s) for each attribute should be considered so these wouldn't >> have to be applied to every ACI but only those that are affected. We don't need >> to worry about userPassword in groups, for example. There are two considerations in play: - We want users to be able to add or remove attributes to the ACIs. - We need to be able to update the ACIs on upgrade (and on user-initiated config changes, e.g. ipauserobjectclasses), so that attributes from new added object classes are added The hard part: merging the user changes back in after an upgrade. The only solutions to this that I found require us tracking more data than we are tracking now: either attribute lists from past IPA versions, or records of the user's actions. I plan to go with the latter. > I think that a decision that a param should not be included in default read > rule should be included in the param object itself, see below. > >>> # Compat tree >>> >>> Do we want to reuse the read privileges for the compat tree, or create >>> extra ones? >> >> I don't think so. Can you disambiguate? :) >>> # Combining read rights >>> >>> I think (read, search, compare) should be exposed in permission objects >>> as a single right. Or is there a reason to keep it split? >> >> Yes, they are separate for a reason. Using only search and compare isn't >> common, but it isn't unheard of either. For example, to be able to detect the >> presence of an attribute you can provide just the search permission. True. But, FreeIPA is in the business of simplifying administration; in a way we're shielding the user from the complexities of LDAP. Our permission objects are, by design, dumbed down so that they're easier to manage. To rephrase: Would an admin want to allow, *to a user*, detecting the presence of an attribute but not reading? If it's not for users, it would IMO be better handled by plugins, raw ACIs, and System permissions. > Wouldn't most users use the (read, search, compare) triple? It would lower our > number of ACIs significantly if we do not have 3 permissions per each object. You can have all the rights in a single ACI; this is merely about simplifying administration. >>> # P.S. >>> >>> I believe that we should strive to put our info about default >>> permissions, containers, settings, and the schema for each plugin in the >>> actual plugin module, rather than it all being split across several >>> ldif/update files. This would make this data more manageable, >>> introspectable and consistent, expose dependencies between plugins, and >>> make it possible to actually write self-contained plugins. >>> This should be done when the time comes for a new version of the >>> ldap-updater. >> >> I don't think we really have any problems having a more or less monolithic set >> up now. I think this would just add complexity. I beg to differ. Our ldif and update files are growing out of sync. Some data (and even schema!) is now only in updates. (And some is in plugins, of course.) You can see our permission names are wildly inconsistent in things like capitalization and use of plurals. It's trivial but it doesn't look very professional. And as Martin points out below, some functional mistakes have crept in too. If we stick to ldif+update files, with this feature I will add lots of data generated automatically by a script. In two slightly altered copies. To files that will be hand-edited later, with largely incomprehensible 1000+ character lines routinely added for regular changes. Whenever we (or anyone!) adds a new object to IPA, that data will be copied by hand, with the proper names and DNs substituted. I don't see how we are not having any problems here. I know it must look different to you -- and I don't blame you! But from the outside point of view, the ldif+update system is really not ideal. > I actually think this could be a killer feature for the refactored ACI system. > Let's take a host object as an example: > > class host(LDAPObject): > """ > Host object. > """ > ... > takes_params = ( > Str('fqdn', _hostname_validator, > Str('description?', > Str('l?', > Str('nshostlocation?', > Str('nshardwareplatform?', > Str('nsosversion?', > Str('userpassword?', > Flag('random?', > Str('randompassword?', > Bytes('usercertificate?', validate_certificate, > Str('krbprincipalname?', > Str('macaddress*', > Str('ipasshpubkey*', validate_sshpubkey_no_options, > Str('userclass*', > ) + ticket_flags_params > ... > > It has the following standard default ACIs: > > aci: (target = "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX")(version > 3.0;acl "permission:Add Hosts";allow (add) groupdn = "ldap:///cn=Add > Hosts,cn=permissions,cn=pbac,$SUFFIX";) > > aci: (target = "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX")(version > 3.0;acl "permission:Remove Hosts";allow (delete) groupdn = "ldap:///cn=Remove > Hosts,cn=permissions,cn=pbac,$SUFFIX";) > > aci: (targetattr = "description || l || nshostlocation || nshardwareplatform || > nsosversion")(target = > "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX")(version 3.0;acl > "permission:Modify Hosts";allow (write) groupdn = "ldap:///cn=Modify > Hosts,cn=permissions,cn=pbac,$SUFFIX";) > > Out of those: > - Add hosts is standard and can be generated automatically from host container > and host primary key. > - Remove Hosts is also standard and can be generated > - Modify Hosts is a bit tricky as we have a list of host attributes that can be > updated by default. Right now, this list is not maintained as it lies somewhere > in delegation.ldif or some of our *.update file. > - New Read Hosts could be also generated, we would just need to filter out > attributes we do not want to be read (this should be recorded in the Param > object itself, see even more below). > > This leads to outdated permissions not allowing privileged users to modify some > parts of the host entry. Just to demonstrate, I found these 2 missing rights > when testing a regular user with "Host Administrators" privilege: > > # kinit fbar > # ipa host-add foo.example.com --force > # ipa host-mod foo.example.com --macaddress=00:11:22:33:44:55 > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the > 'macAddress' attribute of entry > 'fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. > # ipa host-mod foo.example.com --class foo > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the > 'userClass' attribute of entry > 'fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. > > If the basic set of host ACI would be part of the host LDAPObject, we would > have everything in one place and avoid issues like that. Default write > privilege could be generated out of the takes_params. We would just need to > filter out parameters that we do not want to be writable in default ACI, for > example ipasshpubkey where we have a separate permission. > > We could mark this in the param: > > ... > Str('ipasshpubkey*', validate_sshpubkey_no_options, > ... > default_aci=False > ), > ... > > and define a custom ACIs handling it and other special ACIs. Something like: > > class host(LDAPObject): > """ > Host object. > """ > ... > extra_aci = [ > ACI( > dn=api.env.container_computers, > name="Hosts can modify their own SSH public keys", > attrs=['ipasshpubkey'], > rights=['write'], > bind='userdn = "ldap:///self"' > ), > ACI( > dn=api.env.container_computers, > name="Hosts can modify their own certs and keytabs", > attrs=['usercertificate', 'krblastpwdchange', 'description', 'l', > 'nshostlocation', 'nshardwareplatform', 'nsosversion'], > rights=['write'], > bind='userdn = "ldap:///self"' > ), > ACI( > dn=api.env.container_computers, > name="Hosts can manage other host Certificates and kerberos keys", > attrs=['userCertificate', 'krbPrincipalKey'], > rights=['write'], > bind='userdn = "userattr = "parent[0,1].managedby#USERDN""' > ), > ... > ] Originally I thought we should generally aim for this in the long term, but discussion with the Brno team has led me to the conclusion that I want this done, for the ACIs, for 3.4. > IMHO, this would have several benefits: > 1) It would place Host entry, params and ACIs to one single location -> easier > maintenance > 2) It would make delegation.ldif and default-aci.ldif and *.update files > shorter given that all these default ACIs would be removed > 3) It would make lives easier for plugin authors which would not have to deploy > LDIFs or *.update files to deploy a new plugin or modify functionality of an > existing one. For 3) you'd also need schema, containers, configuration, etc. in the plugins. But ACIs are a good first step. -- Petr? From abokovoy at redhat.com Fri Sep 6 12:22:48 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 6 Sep 2013 15:22:48 +0300 Subject: [Freeipa-devel] [PATCHES] 0270-0271 Support for Pylint 1.0 In-Reply-To: <5229A577.1040104@redhat.com> References: <5211F39F.2010606@redhat.com> <5226E87D.7000005@redhat.com> <20130905060804.GK21212@redhat.com> <52283B41.1050103@redhat.com> <20130906083548.GR21212@redhat.com> <5229A577.1040104@redhat.com> Message-ID: <20130906122248.GS21212@redhat.com> On Fri, 06 Sep 2013, Petr Viktorin wrote: >On 09/06/2013 10:35 AM, Alexander Bokovoy wrote: >>On Thu, 05 Sep 2013, Petr Viktorin wrote: >>>On 09/05/2013 08:08 AM, Alexander Bokovoy wrote: >>>>On Wed, 04 Sep 2013, Petr Viktorin wrote: >>>>>On 08/19/2013 12:29 PM, Petr Viktorin wrote: >>>>>>Hello, >>>>>>The first patch fixes a minor problem that Pylint 1.0 finds in our >>>>>>code. >>>>>> >>>>>>The second patch makes make-lint compatible with Pylint 1.0. It >>>>>>contains >>>>>>a workaround for a Pylint bug; before pushing this we should wait >>>>>>for a >>>>>>while to see if a fixed Pylint is released. >>>>>> >>>>> >>>>>A fixed version of Pylint was released, bug workarounds are no longer >>>>>necessary. >>>>> >>>>>Updated patches attached. >>>>> >>>>>https://fedorahosted.org/freeipa/ticket/3865 >>>>I tried the patches and still see an error on up to date Fedora 19 >>>>(including updates-testing): >>>> >>>>./make-lint Traceback (most recent call last): >>>[...] >>>>TypeError: unbound method infer() must be called with Tuple instance as >>>>first argument (got InferenceContext instance instead) >>>> >>>> >>>>At this point I'm not sure whether it is astroid's issue or ours... >>>>Astroid did change from 0.24 to 1.0 on August 13th in Fedora (even in >>>>Fedora 19 where version updates after release are generally >>>>discouraged, especially in case of ABI change). >>> >>>Hello, >>>Please use Pylint 1.0.0-2. It seems it hasn't reached the mirrors yet, >>>you have the earlier buggy version. >>I do have pylint 1.0.0-2.fc19 and yet it fails with the same error >>message. Nothing works, I had to disable make-lint call in Makefile to >>continue development. >> > >That is strange; I've confirmed on several machines that the -2.fc19 >release fixes this bug. > >If you run pylint on the following code, do you also get the "unbound >method infer()" error? (It's the upstream bug reproducer) > >import collections >Point = collections.namedtuple('Point', ['x', 'y']) >p = Point(x=1.0, y=2.0) >print "Area: %.1f" % (p.x * p.y,) Here is clean Fedora 19 VM, created few hours ago: # rpm -q pylint python-astroid pylint-1.0.0-2.fc19.noarch python-astroid-1.0.0-2.fc19.noarch # pylint test.py No config file found, using default configuration ************* Module test C: 1, 0: Missing module docstring (missing-docstring) C: 3, 0: Invalid constant name "p" (invalid-name) Traceback (most recent call last): File "/usr/bin/pylint", line 9, in load_entry_point('pylint==1.0.0', 'console_scripts', 'pylint')() File "/usr/lib/python2.7/site-packages/pylint/__init__.py", line 21, in run_pylint Run(sys.argv[1:]) File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 1010, in __init__ linter.check(args) File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 599, in check self.check_astroid_module(astroid, walker, rawcheckers, tokencheckers) File "/usr/lib/python2.7/site-packages/pylint/lint.py", line 685, in check_astroid_module walker.walk(astroid) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 662, in walk self.walk(child) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 662, in walk self.walk(child) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 662, in walk self.walk(child) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 662, in walk self.walk(child) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 662, in walk self.walk(child) File "/usr/lib/python2.7/site-packages/pylint/utils.py", line 659, in walk cb(astroid) File "/usr/lib/python2.7/site-packages/pylint/checkers/typecheck.py", line 174, in visit_getattr if is_super(owner) or getattr(owner, 'type', None) == 'metaclass': File "/usr/lib/python2.7/site-packages/astroid/bases.py", line 51, in __getattr__ return getattr(self._proxied, name) File "/usr/lib/python2.7/site-packages/astroid/scoped_nodes.py", line 680, in _class_type for base in klass.ancestors(recurs=False): File "/usr/lib/python2.7/site-packages/astroid/scoped_nodes.py", line 801, in ancestors for baseobj in stmt.infer(context): TypeError: unbound method infer() must be called with Tuple instance as first argument (got InferenceContext instance instead) Then I've ran 'yum upgrade' again, and python-astroid-1.0.0-3.fc19.noarch was installed which finally fixed the problem. So the actual problem was split across both pylint and python-astroid. That means ACK for your patches. -- / Alexander Bokovoy From pvoborni at redhat.com Fri Sep 6 12:30:25 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 06 Sep 2013 14:30:25 +0200 Subject: [Freeipa-devel] [PATCH] 450 Fix redirection on deletion of last dns record entry Message-ID: <5229CAE1.6020003@redhat.com> https://fedorahosted.org/freeipa/ticket/3907 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0450-Fix-redirection-on-deletion-of-last-dns-record-entry.patch Type: text/x-patch Size: 2437 bytes Desc: not available URL: From akrivoka at redhat.com Fri Sep 6 12:58:19 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 06 Sep 2013 14:58:19 +0200 Subject: [Freeipa-devel] [PATCH] 0066 Do not crash if DS is down during server uninstall Message-ID: <5229D16B.8070405@redhat.com> Hello, This patch fixes the regression introduced by the original fix for ticket #3867. https://fedorahosted.org/freeipa/ticket/3867 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0066-Do-not-crash-if-DS-is-down-during-server-uninstall.patch Type: text/x-patch Size: 4563 bytes Desc: not available URL: From rcritten at redhat.com Fri Sep 6 13:05:38 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Sep 2013 09:05:38 -0400 Subject: [Freeipa-devel] FreeIPA server package group In-Reply-To: <522975AC.9020308@redhat.com> References: <521B09B2.3080907@redhat.com> <521B0DD9.4000209@redhat.com> <521B0E6A.1080709@redhat.com> <521DC6F7.8030409@redhat.com> <521DCAD6.7090800@redhat.com> <521DCEF2.1040405@redhat.com> <521F1AA5.1030500@redhat.com> <521F20F0.4060605@redhat.com> <5224B194.1060909@redhat.com> <5228C44A.60407@redhat.com> <522975AC.9020308@redhat.com> Message-ID: <5229D322.5040902@redhat.com> Martin Kosek wrote: > On 09/05/2013 07:50 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 08/29/2013 12:22 PM, Tomas Babej wrote: >>>> On 08/29/2013 11:55 AM, Petr Viktorin wrote: >>>>> On 08/28/2013 12:20 PM, Tomas Babej wrote: >>>>>> On 08/28/2013 12:03 PM, Petr Viktorin wrote: >>>>>>> On 08/28/2013 11:46 AM, Tomas Babej wrote: >>>>>>>> On 08/26/2013 10:14 AM, Tomas Babej wrote: >>>>>>>>> On Mon 26 Aug 2013 10:12:09 AM CEST, Petr Vobornik wrote: >>>>>>>>>> On 08/26/2013 09:54 AM, Tomas Babej wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I cooked up a patch for comps that adds a FreeIPA package group. >>>>>>>>>>> >>>>>>>>>>> Please chime in if you're OK with package selection / description. >>>>>>>>>>> >>>>>>>>>>> For illustration, see the attached image. FreeIPA will be added as an >>>>>>>>>>> add-on in an installer under the Infrastructure server environment, >>>>>>>>>>> that means, in the included images it will be at the same level >>>>>>>>>>> as DNS or FTP server. >>>>>>>>>>> >>>>>>>>>>> It will also appear in the Software Selection tool (PackageKit). >>>>>>>>>>> >>>>>>>>>>> It should also be available under as yum groupinstall "FreeIPA >>>>>>>>>>> server", >>>>>>>>>>> and in PackageKit, as I understand comps is also source for that too. >>>>>>>>>>> >>>>>>>>>>> https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3630 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> IMO the Audit part in the description is false advertisement. Same >>>>>>>>>> issue is in package descriptions. >>>>>>>>> >>>>>>>>> I know, it's taken directly from there. >>>>>>>>> >>>>>>>>> I'd rather have it consistent, if we're going to change it here, we >>>>>>>>> should do >>>>>>>>> there too, so that we do not end up with multiple (seemingly >>>>>>>>> incomplete) >>>>>>>>> descriptions at various places. >>>>>>>> >>>>>>>> Anybody else does have any other concerns? We need to move with this >>>>>>>> effort since string freeze for F20 is coming. >>>>>>>> >>>>>>>> I'm particulary dubious about including the freeipa-tests package. >>>>>>> >>>>>>> I don't think that should be included, developer tests are unnecessary >>>>>>> for a server. >>>>>>> >>>>>> It was marked as optional in the initial proposal, but I agree it's >>>>>> unnecessary for >>>>>> it to be there at all. >>>>>>>> We discussed the A (as Audit) part in the description with Rob. The >>>>>>>> fact is >>>>>>>> that this is taken from the freeipa-server package description and >>>>>>>> nobody >>>>>>>> complained in 7 years. >>>>>>> >>>>>> >>>>>> Updated tests attached. >>>>>> >>>>> >>>>> Oh, one more thing I remembered just now -- is it too late? >>>>> We should include bind-dyndb-ldap (which pulls in bind). Preferably as >>>>> default. >>>>> >>>> >>>> I included it there. >>>> >>>> If anyone else wants to chime in, please do now, I'll create a ticket with >>>> rel-eng at the end of the day. >>>> >>> >>> Thanks for this effort. What is the status of the bug - did you create the >>> request already? >>> >>> We will need to do one more change and remove freeipa-server-strict package as >>> up on the decision on today's developer meeting we decided to drop this >>> subpackage in Fedora 20 and later and depend on our new FreeIPA Continuous >>> Integration system instead. >> >> I missed that meeting so maybe I'm re-hashing things, but I don't see how CI >> solves the problem that the strict subpackage does. Sure, it won't be as much a >> surprise to us when other packages are updated, but this doesn't prevent a user >> from also updating to the package. The strict package prevents upgrade until >> we've confirmed that things are actually working. CI does not. > > CI should prevent problems at the begging, before they happen - right when the > new Dogtag/Kerberos/389-ds-base is in updates-testing. That gives a change to > give negative Karma and have that package fixed before it hits stable updates. > > IMO freeipa-server-strict subpackage is too heavy weight and does not provide > the benefit we would want. So far, IMHO, it was rather a burden for maintainers > and broke quite frequently. I'm not a huge fan of the strict package, I resisted it for a long time. But it does serve its intended purpose: stability for users. I agree it is a pain, particularly in rawhide. I guess I'm just not convinced that CI is going to catch everything. rob From rcritten at redhat.com Fri Sep 6 12:46:53 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Sep 2013 08:46:53 -0400 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <5229839E.9070105@redhat.com> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> <5229839E.9070105@redhat.com> Message-ID: <5229CEBD.7070705@redhat.com> Martin Kosek wrote: > On 09/05/2013 07:48 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> Hello, >>> I have some notes and questions on >>> https://fedorahosted.org/freeipa/ticket/3566 (Control access of user >>> roles to server functions). >>> >>> >>> An IPA terminology refresher for reference: >>> - ACI: The DS-level permission. >>> - Permission: IPA object that encapsulates one ACI. Example: "add user". >>> Permissions aren't as flexible as raw ACIs. >>> - Privilege: IPA object that groups several permissions, e.g. with a >>> "manage users" privilege you can "add user", "modify user", ... >>> - Role: IPA object that groups privileges, e.g. an "User Administrator" >>> can manage users and groups. Roles are assigned to users/groups/hosts. >>> >>> >>> # Permission structure >>> >>> I think it would be best to have two permissions for each object, one >>> for the entries and one for the container. This keeps the ACIs >>> manageable with existing permission API: >>> >>> aci: (target = "ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX")(version >>> 3.0;acl "permission:Read Groups";allow (read,search,compare) groupdn = >>> "ldap:///cn=Read Groups,cn=permissions,cn=pbac,$SUFFIX";) >>> >>> aci: (target = "ldap:///cn=groups,cn=accounts,$SUFFIX")(version 3.0;acl >>> "permission:Read Group Container";allow (read,search,compare) groupdn = >>> "ldap:///cn=Read Group Container,cn=permissions,cn=pbac,$SUFFIX";) >>> >>> These would be combined in a "Group Readers" privilege. >>> >>> All the privileges would be granted to a role called "Users", which >>> would contain ipausers and admins. >> >> I'm not sure I follow, what are you trying to achieve here? The more ACIs the >> slower the processing. > > One of the main reason for this feature is to get rid of the global allowing ACI: > > aci: (targetfilter = > "(&(!(objectClass=ipaToken))(!(objectClass=ipatokenTOTP))(!(objectClass=ipatokenRadiusConfiguration)))")(target > != "ldap:///idnsname=*,cn=dns,$SUFFIX")(targetattr != "userPassword || > krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || > krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutgoing || > ipaNTTrustAuthIncoming")(version 3.0; acl "Enable Anonymous access"; allow > (read, search, compare) userdn = "ldap:///anyone";) > > ... as this ACI does not scale and adds burden for developers or plugin author > wishing to add an attribute that should not be visible by default. Number of > ACIs should still be kept low, that's true. Right, I just want to know why it was proposed to add 2 ACIs for every container. >> >>> # External users & system accounts >>> >>> I'm not sure how to handle external users here, since they're not added >>> to any group. Either we'll need a special ACI for them, or somehow make >>> it possible to add non-group sets of users to Roles. >>> >>> The same goes for system accounts, except those aren't even implemented >>> in IPA yet (https://fedorahosted.org/freeipa/ticket/2801). >> >> I think they would have to be part of a group. Otherwise 389-ds has nothing to >> evaluate against (and even with groups I'm not 100% sure it'll work). >> >>> >>> # Protected attributes >>> >>> How to handle passwords and other non-public attributes? I'm thinking >>> about keeping a global list of such attributes, and applying it to each >>> read permission ACI on normal operations and upgrades; either generating >>> a (targetfilter != ...) clause or filtering the (targetfilter = ...) one. >>> Possibly that list would be configurable and stored in LDAP. >>> >>> For reference, we currently exclude these in the anonymous read rule: >>> "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword >>> || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || >>> ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming" >> >> It could get ugly real fast, and potentially cause a lot of extra processing. I >> think the object(s) for each attribute should be considered so these wouldn't >> have to be applied to every ACI but only those that are affected. We don't need >> to worry about userPassword in groups, for example. > > I think that a decision that a param should not be included in default read > rule should be included in the param object itself, see below. > >> >>> >>> # Compat tree >>> >>> Do we want to reuse the read privileges for the compat tree, or create >>> extra ones? >> >> I don't think so. >> >>> >>> >>> # Combining read rights >>> >>> I think (read, search, compare) should be exposed in permission objects >>> as a single right. Or is there a reason to keep it split? >> >> Yes, they are separate for a reason. Using only search and compare isn't >> common, but it isn't unheard of either. For example, to be able to detect the >> presence of an attribute you can provide just the search permission. > > Wouldn't most users use the (read, search, compare) triple? It would lower our > number of ACIs significantly if we do not have 3 permissions per each object. There is nothing to prevent an ACI from containing multiple permissions. I wasn't proposing that. But rolling these three logically into the same thing in IPA I think is short-sighted. >> >>> >>> # P.S. >>> >>> I believe that we should strive to put our info about default >>> permissions, containers, settings, and the schema for each plugin in the >>> actual plugin module, rather than it all being split across several >>> ldif/update files. This would make this data more manageable, >>> introspectable and consistent, expose dependencies between plugins, and >>> make it possible to actually write self-contained plugins. >>> This should be done when the time comes for a new version of the >>> ldap-updater. >> >> I don't think we really have any problems having a more or less monolithic set >> up now. I think this would just add complexity. > > I actually think this could be a killer feature for the refactored ACI system. > Let's take a host object as an example: > > class host(LDAPObject): > """ > Host object. > """ > ... > takes_params = ( > Str('fqdn', _hostname_validator, > Str('description?', > Str('l?', > Str('nshostlocation?', > Str('nshardwareplatform?', > Str('nsosversion?', > Str('userpassword?', > Flag('random?', > Str('randompassword?', > Bytes('usercertificate?', validate_certificate, > Str('krbprincipalname?', > Str('macaddress*', > Str('ipasshpubkey*', validate_sshpubkey_no_options, > Str('userclass*', > ) + ticket_flags_params > ... > > It has the following standard default ACIs: > > aci: (target = "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX")(version > 3.0;acl "permission:Add Hosts";allow (add) groupdn = "ldap:///cn=Add > Hosts,cn=permissions,cn=pbac,$SUFFIX";) > > aci: (target = "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX")(version > 3.0;acl "permission:Remove Hosts";allow (delete) groupdn = "ldap:///cn=Remove > Hosts,cn=permissions,cn=pbac,$SUFFIX";) > > aci: (targetattr = "description || l || nshostlocation || nshardwareplatform || > nsosversion")(target = > "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX")(version 3.0;acl > "permission:Modify Hosts";allow (write) groupdn = "ldap:///cn=Modify > Hosts,cn=permissions,cn=pbac,$SUFFIX";) > > Out of those: > - Add hosts is standard and can be generated automatically from host container > and host primary key. > - Remove Hosts is also standard and can be generated > - Modify Hosts is a bit tricky as we have a list of host attributes that can be > updated by default. Right now, this list is not maintained as it lies somewhere > in delegation.ldif or some of our *.update file. > - New Read Hosts could be also generated, we would just need to filter out > attributes we do not want to be read (this should be recorded in the Param > object itself, see even more below). > > This leads to outdated permissions not allowing privileged users to modify some > parts of the host entry. Just to demonstrate, I found these 2 missing rights > when testing a regular user with "Host Administrators" privilege: > > # kinit fbar > # ipa host-add foo.example.com --force > # ipa host-mod foo.example.com --macaddress=00:11:22:33:44:55 > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the > 'macAddress' attribute of entry > 'fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. > # ipa host-mod foo.example.com --class foo > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the > 'userClass' attribute of entry > 'fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. > > If the basic set of host ACI would be part of the host LDAPObject, we would > have everything in one place and avoid issues like that. Default write > privilege could be generated out of the takes_params. We would just need to > filter out parameters that we do not want to be writable in default ACI, for > example ipasshpubkey where we have a separate permission. > > We could mark this in the param: > > ... > Str('ipasshpubkey*', validate_sshpubkey_no_options, > ... > default_aci=False > ), > ... > > and define a custom ACIs handling it and other special ACIs. Something like: > > class host(LDAPObject): > """ > Host object. > """ > ... > extra_aci = [ > ACI( > dn=api.env.container_computers, > name="Hosts can modify their own SSH public keys", > attrs=['ipasshpubkey'], > rights=['write'], > bind='userdn = "ldap:///self"' > ), > ACI( > dn=api.env.container_computers, > name="Hosts can modify their own certs and keytabs", > attrs=['usercertificate', 'krblastpwdchange', 'description', 'l', > 'nshostlocation', 'nshardwareplatform', 'nsosversion'], > rights=['write'], > bind='userdn = "ldap:///self"' > ), > ACI( > dn=api.env.container_computers, > name="Hosts can manage other host Certificates and kerberos keys", > attrs=['userCertificate', 'krbPrincipalKey'], > rights=['write'], > bind='userdn = "userattr = "parent[0,1].managedby#USERDN""' > ), > ... > ] > > IMHO, this would have several benefits: > 1) It would place Host entry, params and ACIs to one single location -> easier > maintenance > 2) It would make delegation.ldif and default-aci.ldif and *.update files > shorter given that all these default ACIs would be removed > 3) It would make lives easier for plugin authors which would not have to deploy > LDIFs or *.update files to deploy a new plugin or modify functionality of an > existing one. > > Makes sense? Well, my alarm bells are going off. This would require some significant review each and every time any object is updated. Consider how many times API.txt is overlooked, and it has no security implications. I can't say I'm a fan of programmatic ACI generation. rob From mkosek at redhat.com Fri Sep 6 13:23:15 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Sep 2013 15:23:15 +0200 Subject: [Freeipa-devel] FreeIPA server package group In-Reply-To: <5229D322.5040902@redhat.com> References: <521B09B2.3080907@redhat.com> <521B0DD9.4000209@redhat.com> <521B0E6A.1080709@redhat.com> <521DC6F7.8030409@redhat.com> <521DCAD6.7090800@redhat.com> <521DCEF2.1040405@redhat.com> <521F1AA5.1030500@redhat.com> <521F20F0.4060605@redhat.com> <5224B194.1060909@redhat.com> <5228C44A.60407@redhat.com> <522975AC.9020308@redhat.com> <5229D322.5040902@redhat.com> Message-ID: <5229D743.60805@redhat.com> On 09/06/2013 03:05 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 09/05/2013 07:50 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 08/29/2013 12:22 PM, Tomas Babej wrote: >>>>> On 08/29/2013 11:55 AM, Petr Viktorin wrote: >>>>>> On 08/28/2013 12:20 PM, Tomas Babej wrote: >>>>>>> On 08/28/2013 12:03 PM, Petr Viktorin wrote: >>>>>>>> On 08/28/2013 11:46 AM, Tomas Babej wrote: >>>>>>>>> On 08/26/2013 10:14 AM, Tomas Babej wrote: >>>>>>>>>> On Mon 26 Aug 2013 10:12:09 AM CEST, Petr Vobornik wrote: >>>>>>>>>>> On 08/26/2013 09:54 AM, Tomas Babej wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I cooked up a patch for comps that adds a FreeIPA package group. >>>>>>>>>>>> >>>>>>>>>>>> Please chime in if you're OK with package selection / description. >>>>>>>>>>>> >>>>>>>>>>>> For illustration, see the attached image. FreeIPA will be added as an >>>>>>>>>>>> add-on in an installer under the Infrastructure server environment, >>>>>>>>>>>> that means, in the included images it will be at the same level >>>>>>>>>>>> as DNS or FTP server. >>>>>>>>>>>> >>>>>>>>>>>> It will also appear in the Software Selection tool (PackageKit). >>>>>>>>>>>> >>>>>>>>>>>> It should also be available under as yum groupinstall "FreeIPA >>>>>>>>>>>> server", >>>>>>>>>>>> and in PackageKit, as I understand comps is also source for that too. >>>>>>>>>>>> >>>>>>>>>>>> https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3630 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> IMO the Audit part in the description is false advertisement. Same >>>>>>>>>>> issue is in package descriptions. >>>>>>>>>> >>>>>>>>>> I know, it's taken directly from there. >>>>>>>>>> >>>>>>>>>> I'd rather have it consistent, if we're going to change it here, we >>>>>>>>>> should do >>>>>>>>>> there too, so that we do not end up with multiple (seemingly >>>>>>>>>> incomplete) >>>>>>>>>> descriptions at various places. >>>>>>>>> >>>>>>>>> Anybody else does have any other concerns? We need to move with this >>>>>>>>> effort since string freeze for F20 is coming. >>>>>>>>> >>>>>>>>> I'm particulary dubious about including the freeipa-tests package. >>>>>>>> >>>>>>>> I don't think that should be included, developer tests are unnecessary >>>>>>>> for a server. >>>>>>>> >>>>>>> It was marked as optional in the initial proposal, but I agree it's >>>>>>> unnecessary for >>>>>>> it to be there at all. >>>>>>>>> We discussed the A (as Audit) part in the description with Rob. The >>>>>>>>> fact is >>>>>>>>> that this is taken from the freeipa-server package description and >>>>>>>>> nobody >>>>>>>>> complained in 7 years. >>>>>>>> >>>>>>> >>>>>>> Updated tests attached. >>>>>>> >>>>>> >>>>>> Oh, one more thing I remembered just now -- is it too late? >>>>>> We should include bind-dyndb-ldap (which pulls in bind). Preferably as >>>>>> default. >>>>>> >>>>> >>>>> I included it there. >>>>> >>>>> If anyone else wants to chime in, please do now, I'll create a ticket with >>>>> rel-eng at the end of the day. >>>>> >>>> >>>> Thanks for this effort. What is the status of the bug - did you create the >>>> request already? >>>> >>>> We will need to do one more change and remove freeipa-server-strict package as >>>> up on the decision on today's developer meeting we decided to drop this >>>> subpackage in Fedora 20 and later and depend on our new FreeIPA Continuous >>>> Integration system instead. >>> >>> I missed that meeting so maybe I'm re-hashing things, but I don't see how CI >>> solves the problem that the strict subpackage does. Sure, it won't be as much a >>> surprise to us when other packages are updated, but this doesn't prevent a user >>> from also updating to the package. The strict package prevents upgrade until >>> we've confirmed that things are actually working. CI does not. >> >> CI should prevent problems at the begging, before they happen - right when the >> new Dogtag/Kerberos/389-ds-base is in updates-testing. That gives a change to >> give negative Karma and have that package fixed before it hits stable updates. >> >> IMO freeipa-server-strict subpackage is too heavy weight and does not provide >> the benefit we would want. So far, IMHO, it was rather a burden for maintainers >> and broke quite frequently. > > I'm not a huge fan of the strict package, I resisted it for a long time. But it > does serve its intended purpose: stability for users. I agree it is a pain, > particularly in rawhide. Yeah, this is exactly a point where I am not sure if it serves it's purpose. We do not have some policy or official testing of new DS/CS/KRB releases. So I just do not know when exactly should be update the strict package. After the new DS version is used for a month in a community? Or after a smoke/unit test performed ad-hoc by somebody in the team? I do not know. But until we do that, we will have broken dependency. > > I guess I'm just not convinced that CI is going to catch everything. I am not sure if the strict versioning makes a difference, given that version is also bumped by a human/package maintainer who cannot catch everything either. Martin From pviktori at redhat.com Fri Sep 6 13:32:35 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Sep 2013 15:32:35 +0200 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <5229CEBD.7070705@redhat.com> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> <5229839E.9070105@redhat.com> <5229CEBD.7070705@redhat.com> Message-ID: <5229D973.2080106@redhat.com> On 09/06/2013 02:46 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 09/05/2013 07:48 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> Hello, >>>> I have some notes and questions on >>>> https://fedorahosted.org/freeipa/ticket/3566 (Control access of user >>>> roles to server functions). [...] > Right, I just want to know why it was proposed to add 2 ACIs for every > container. One for the container itself, one for the objects beneath it. I don't see a straightforward way to allow access to both in a single permission. (Currently, permissions need to be at $SUFFIX, so their subtrees are specified by target.) [...] >>>> # Combining read rights >>>> >>>> I think (read, search, compare) should be exposed in permission objects >>>> as a single right. Or is there a reason to keep it split? >>> >>> Yes, they are separate for a reason. Using only search and compare isn't >>> common, but it isn't unheard of either. For example, to be able to >>> detect the >>> presence of an attribute you can provide just the search permission. >> >> Wouldn't most users use the (read, search, compare) triple? It would >> lower our >> number of ACIs significantly if we do not have 3 permissions per each >> object. > > There is nothing to prevent an ACI from containing multiple permissions. > I wasn't proposing that. But rolling these three logically into the same > thing in IPA I think is short-sighted. See my other e-mail with my reasoning. I don't particularly care about this issue, though. > >>> >>>> >>>> # P.S. >>>> >>>> I believe that we should strive to put our info about default >>>> permissions, containers, settings, and the schema for each plugin in >>>> the >>>> actual plugin module, rather than it all being split across several >>>> ldif/update files. This would make this data more manageable, >>>> introspectable and consistent, expose dependencies between plugins, and >>>> make it possible to actually write self-contained plugins. >>>> This should be done when the time comes for a new version of the >>>> ldap-updater. [...] > > Well, my alarm bells are going off. This would require some significant > review each and every time any object is updated. Consider how many > times API.txt is overlooked, and it has no security implications. Consider how many times the ldif or update files were overlooked. API.txt is checked during every build, whereas ldif/update files not, and are tedious to check. We can of course add a similar file for ACIs, in fact I was planning to do so. Any changes can be then reviewed both in the source and (like now) in the resulting ldif. Also, the information would be in one place, rather than in ldif (which doesn't apply on upgrades) and in update files. I believe it would actually be better for security. > I can't say I'm a fan of programmatic ACI generation. Well, I'm sure not going to write the ACIs for this feature by hand. It would help I could actually polish, commit and integrate the script that generates them. In my book, programmatic generation is much better than copy+paste. -- Petr? From pviktori at redhat.com Fri Sep 6 13:40:31 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Sep 2013 15:40:31 +0200 Subject: [Freeipa-devel] [PATCH 0003] Add timestamps to named debug logs in /var/named/data/named.run In-Reply-To: <52289536.3040801@redhat.com> References: <52289470.4020806@redhat.com> <52289536.3040801@redhat.com> Message-ID: <5229DB4F.6070101@redhat.com> On 09/05/2013 04:29 PM, Tomas Babej wrote: > On 09/05/2013 04:25 PM, Petr Spacek wrote: >> Hello, >> >> Add timestamps to named debug logs in /var/named/data/named.run. >> >> >> Tomas Babej and I spent more than hour with debugging bind-dyndb-ldap >> and timestamps were invaluable. >> > > ACK > Thanks, pushed to master: 0924177ab03d39a09bb8e9885f5d2a2f586a1eda ipa-3-3: b9e44e22e1ce60fda524e772ade118b8674cf205 -- Petr? From pviktori at redhat.com Fri Sep 6 13:44:46 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Sep 2013 15:44:46 +0200 Subject: [Freeipa-devel] [PATCHES] 0270-0271 Support for Pylint 1.0 In-Reply-To: <20130906122248.GS21212@redhat.com> References: <5211F39F.2010606@redhat.com> <5226E87D.7000005@redhat.com> <20130905060804.GK21212@redhat.com> <52283B41.1050103@redhat.com> <20130906083548.GR21212@redhat.com> <5229A577.1040104@redhat.com> <20130906122248.GS21212@redhat.com> Message-ID: <5229DC4E.5010908@redhat.com> On 09/06/2013 02:22 PM, Alexander Bokovoy wrote: > On Fri, 06 Sep 2013, Petr Viktorin wrote: >> On 09/06/2013 10:35 AM, Alexander Bokovoy wrote: >>> On Thu, 05 Sep 2013, Petr Viktorin wrote: >>>> On 09/05/2013 08:08 AM, Alexander Bokovoy wrote: >>>>> On Wed, 04 Sep 2013, Petr Viktorin wrote: >>>>>> On 08/19/2013 12:29 PM, Petr Viktorin wrote: >>>>>>> Hello, >>>>>>> The first patch fixes a minor problem that Pylint 1.0 finds in our >>>>>>> code. >>>>>>> >>>>>>> The second patch makes make-lint compatible with Pylint 1.0. It >>>>>>> contains >>>>>>> a workaround for a Pylint bug; before pushing this we should wait >>>>>>> for a >>>>>>> while to see if a fixed Pylint is released. >>>>>>> >>>>>> >>>>>> A fixed version of Pylint was released, bug workarounds are no longer >>>>>> necessary. >>>>>> >>>>>> Updated patches attached. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3865 >>>>> I tried the patches and still see an error on up to date Fedora 19 >>>>> (including updates-testing): >>>>> >>>>> ./make-lint Traceback (most recent call last): >>>> [...] >>>>> TypeError: unbound method infer() must be called with Tuple >>>>> instance as >>>>> first argument (got InferenceContext instance instead) >>>>> >>>>> >>>>> At this point I'm not sure whether it is astroid's issue or ours... >>>>> Astroid did change from 0.24 to 1.0 on August 13th in Fedora (even in >>>>> Fedora 19 where version updates after release are generally >>>>> discouraged, especially in case of ABI change). >>>> >>>> Hello, >>>> Please use Pylint 1.0.0-2. It seems it hasn't reached the mirrors yet, >>>> you have the earlier buggy version. >>> I do have pylint 1.0.0-2.fc19 and yet it fails with the same error >>> message. Nothing works, I had to disable make-lint call in Makefile to >>> continue development. >>> >> >> That is strange; I've confirmed on several machines that the -2.fc19 >> release fixes this bug. >> >> If you run pylint on the following code, do you also get the "unbound >> method infer()" error? (It's the upstream bug reproducer) >> >> import collections >> Point = collections.namedtuple('Point', ['x', 'y']) >> p = Point(x=1.0, y=2.0) >> print "Area: %.1f" % (p.x * p.y,) > Here is clean Fedora 19 VM, created few hours ago: > # rpm -q pylint python-astroid > pylint-1.0.0-2.fc19.noarch > python-astroid-1.0.0-2.fc19.noarch > # pylint test.py No config file found, using default configuration > ************* Module test > C: 1, 0: Missing module docstring (missing-docstring) > C: 3, 0: Invalid constant name "p" (invalid-name) > Traceback (most recent call last): > File "/usr/bin/pylint", line 9, in > load_entry_point('pylint==1.0.0', 'console_scripts', 'pylint')() [...] > TypeError: unbound method infer() must be called with Tuple instance as > first argument (got InferenceContext instance instead) > > Then I've ran 'yum upgrade' again, and > python-astroid-1.0.0-3.fc19.noarch was > installed which finally fixed the problem. > > So the actual problem was split across both pylint and python-astroid. > > That means ACK for your patches. > I'm glad that got cleared up. Thanks for the review, pushed to master: a9225be0fa7bb834cd78609603300d81dcc4d3c9 ipa-3-3: 41c255a8e91942377f00d85ed93a0b7afb617266 -- Petr? From rcritten at redhat.com Fri Sep 6 13:59:55 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Sep 2013 09:59:55 -0400 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <5229D973.2080106@redhat.com> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> <5229839E.9070105@redhat.com> <5229CEBD.7070705@redhat.com> <5229D973.2080106@redhat.com> Message-ID: <5229DFDB.7060605@redhat.com> Petr Viktorin wrote: > On 09/06/2013 02:46 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 09/05/2013 07:48 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> Hello, >>>>> I have some notes and questions on >>>>> https://fedorahosted.org/freeipa/ticket/3566 (Control access of user >>>>> roles to server functions). > [...] >> Right, I just want to know why it was proposed to add 2 ACIs for every >> container. > > One for the container itself, one for the objects beneath it. > > I don't see a straightforward way to allow access to both in a single > permission. (Currently, permissions need to be at $SUFFIX, so their > subtrees are specified by target.) > > [...] Right. I'm not sure you need to grant read,search,compare to the container. Have you tested that? >>>>> # Combining read rights >>>>> >>>>> I think (read, search, compare) should be exposed in permission >>>>> objects >>>>> as a single right. Or is there a reason to keep it split? >>>> >>>> Yes, they are separate for a reason. Using only search and compare >>>> isn't >>>> common, but it isn't unheard of either. For example, to be able to >>>> detect the >>>> presence of an attribute you can provide just the search permission. >>> >>> Wouldn't most users use the (read, search, compare) triple? It would >>> lower our >>> number of ACIs significantly if we do not have 3 permissions per each >>> object. >> >> There is nothing to prevent an ACI from containing multiple permissions. >> I wasn't proposing that. But rolling these three logically into the same >> thing in IPA I think is short-sighted. > > See my other e-mail with my reasoning. I don't particularly care about > this issue, though. > >> >>>> >>>>> >>>>> # P.S. >>>>> >>>>> I believe that we should strive to put our info about default >>>>> permissions, containers, settings, and the schema for each plugin in >>>>> the >>>>> actual plugin module, rather than it all being split across several >>>>> ldif/update files. This would make this data more manageable, >>>>> introspectable and consistent, expose dependencies between plugins, >>>>> and >>>>> make it possible to actually write self-contained plugins. >>>>> This should be done when the time comes for a new version of the >>>>> ldap-updater. > [...] >> >> Well, my alarm bells are going off. This would require some significant >> review each and every time any object is updated. Consider how many >> times API.txt is overlooked, and it has no security implications. > > Consider how many times the ldif or update files were overlooked. > API.txt is checked during every build, whereas ldif/update files not, > and are tedious to check. > > We can of course add a similar file for ACIs, in fact I was planning to > do so. Any changes can be then reviewed both in the source and (like > now) in the resulting ldif. Also, the information would be in one place, > rather than in ldif (which doesn't apply on upgrades) and in update files. > I believe it would actually be better for security. The plan at the time updates were added was to move absolutely everything out of ldif and into updates. It just never happened. >> I can't say I'm a fan of programmatic ACI generation. > > Well, I'm sure not going to write the ACIs for this feature by hand. It > would help I could actually polish, commit and integrate the script that > generates them. > In my book, programmatic generation is much better than copy+paste. > On the other hand, it becomes very easy to just rely on it and not closely examine the output. rob From pviktori at redhat.com Fri Sep 6 14:11:40 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Sep 2013 16:11:40 +0200 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <5229DFDB.7060605@redhat.com> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> <5229839E.9070105@redhat.com> <5229CEBD.7070705@redhat.com> <5229D973.2080106@redhat.com> <5229DFDB.7060605@redhat.com> Message-ID: <5229E29C.20404@redhat.com> On 09/06/2013 03:59 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 09/06/2013 02:46 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 09/05/2013 07:48 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> Hello, >>>>>> I have some notes and questions on >>>>>> https://fedorahosted.org/freeipa/ticket/3566 (Control access of user >>>>>> roles to server functions). >> [...] >>> Right, I just want to know why it was proposed to add 2 ACIs for every >>> container. >> >> One for the container itself, one for the objects beneath it. >> >> I don't see a straightforward way to allow access to both in a single >> permission. (Currently, permissions need to be at $SUFFIX, so their >> subtrees are specified by target.) >> >> [...] > > Right. I'm not sure you need to grant read,search,compare to the > container. Have you tested that? To be honest, I assumed some from the bug description. I'll test it. If it's not necessary there'll be one ACI per object type. [...] >>>>> >>>>>> >>>>>> # P.S. >>>>>> >>>>>> I believe that we should strive to put our info about default >>>>>> permissions, containers, settings, and the schema for each plugin in >>>>>> the >>>>>> actual plugin module, rather than it all being split across several >>>>>> ldif/update files. This would make this data more manageable, >>>>>> introspectable and consistent, expose dependencies between plugins, >>>>>> and >>>>>> make it possible to actually write self-contained plugins. >>>>>> This should be done when the time comes for a new version of the >>>>>> ldap-updater. >> [...] >>> >>> Well, my alarm bells are going off. This would require some significant >>> review each and every time any object is updated. Consider how many >>> times API.txt is overlooked, and it has no security implications. >> >> Consider how many times the ldif or update files were overlooked. >> API.txt is checked during every build, whereas ldif/update files not, >> and are tedious to check. >> >> We can of course add a similar file for ACIs, in fact I was planning to >> do so. Any changes can be then reviewed both in the source and (like >> now) in the resulting ldif. Also, the information would be in one place, >> rather than in ldif (which doesn't apply on upgrades) and in update >> files. >> I believe it would actually be better for security. > > The plan at the time updates were added was to move absolutely > everything out of ldif and into updates. It just never happened. Good to know. Is it still the plan? Do I only need to change the update files? >>> I can't say I'm a fan of programmatic ACI generation. >> >> Well, I'm sure not going to write the ACIs for this feature by hand. It >> would help I could actually polish, commit and integrate the script that >> generates them. >> In my book, programmatic generation is much better than copy+paste. >> > > On the other hand, it becomes very easy to just rely on it and not > closely examine the output. That is a question of checking the changes. Frankly I don't see that much difference between not checking after updates and not checking after copy+pasting. If nothing, the existence of an ACI.txt should remind us that security is at stake. Also, if the objectclasses change this will alert us that ACIs need changing as well. -- Petr? From rcritten at redhat.com Fri Sep 6 14:41:36 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 Sep 2013 10:41:36 -0400 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <5229E29C.20404@redhat.com> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> <5229839E.9070105@redhat.com> <5229CEBD.7070705@redhat.com> <5229D973.2080106@redhat.com> <5229DFDB.7060605@redhat.com> <5229E29C.20404@redhat.com> Message-ID: <5229E9A0.2050709@redhat.com> Petr Viktorin wrote: > On 09/06/2013 03:59 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 09/06/2013 02:46 PM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On 09/05/2013 07:48 PM, Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>>>> Hello, >>>>>>> I have some notes and questions on >>>>>>> https://fedorahosted.org/freeipa/ticket/3566 (Control access of user >>>>>>> roles to server functions). >>> [...] >>>> Right, I just want to know why it was proposed to add 2 ACIs for every >>>> container. >>> >>> One for the container itself, one for the objects beneath it. >>> >>> I don't see a straightforward way to allow access to both in a single >>> permission. (Currently, permissions need to be at $SUFFIX, so their >>> subtrees are specified by target.) >>> >>> [...] >> >> Right. I'm not sure you need to grant read,search,compare to the >> container. Have you tested that? > > To be honest, I assumed some from the bug description. I'll test it. If > it's not necessary there'll be one ACI per object type. > > [...] >>>>>> >>>>>>> >>>>>>> # P.S. >>>>>>> >>>>>>> I believe that we should strive to put our info about default >>>>>>> permissions, containers, settings, and the schema for each plugin in >>>>>>> the >>>>>>> actual plugin module, rather than it all being split across several >>>>>>> ldif/update files. This would make this data more manageable, >>>>>>> introspectable and consistent, expose dependencies between plugins, >>>>>>> and >>>>>>> make it possible to actually write self-contained plugins. >>>>>>> This should be done when the time comes for a new version of the >>>>>>> ldap-updater. >>> [...] >>>> >>>> Well, my alarm bells are going off. This would require some significant >>>> review each and every time any object is updated. Consider how many >>>> times API.txt is overlooked, and it has no security implications. >>> >>> Consider how many times the ldif or update files were overlooked. >>> API.txt is checked during every build, whereas ldif/update files not, >>> and are tedious to check. >>> >>> We can of course add a similar file for ACIs, in fact I was planning to >>> do so. Any changes can be then reviewed both in the source and (like >>> now) in the resulting ldif. Also, the information would be in one place, >>> rather than in ldif (which doesn't apply on upgrades) and in update >>> files. >>> I believe it would actually be better for security. >> >> The plan at the time updates were added was to move absolutely >> everything out of ldif and into updates. It just never happened. > > Good to know. Is it still the plan? Do I only need to change the update > files? It would be my preference. It goes beyond only changing one set of files. The existing ldif that duplicate things need to be deprecated. We can't get to a zero-ldif install, but it can be reduced significantly. > >>>> I can't say I'm a fan of programmatic ACI generation. >>> >>> Well, I'm sure not going to write the ACIs for this feature by hand. It >>> would help I could actually polish, commit and integrate the script that >>> generates them. >>> In my book, programmatic generation is much better than copy+paste. >>> >> >> On the other hand, it becomes very easy to just rely on it and not >> closely examine the output. > > That is a question of checking the changes. Frankly I don't see that > much difference between not checking after updates and not checking > after copy+pasting. > If nothing, the existence of an ACI.txt should remind us that security > is at stake. > Also, if the objectclasses change this will alert us that ACIs need > changing as well. > Well, there was little copy+pasting before. The majority of the current ACIs were generated by permission-add. The difference is that ACI changes may be automatically spawned by an update to the plugin. Right now the risk is that attributes won't be added to a write list, so there is limited potential damage. It is just annoying. If instead it will potentially grant both read and write access the scope of harm grows. rob From akrivoka at redhat.com Fri Sep 6 14:47:11 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 06 Sep 2013 16:47:11 +0200 Subject: [Freeipa-devel] [PATCH] 450 Fix redirection on deletion of last dns record entry In-Reply-To: <5229CAE1.6020003@redhat.com> References: <5229CAE1.6020003@redhat.com> Message-ID: <5229EAEF.8070008@redhat.com> On 09/06/2013 02:30 PM, Petr Vobornik wrote: > https://fedorahosted.org/freeipa/ticket/3907 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Fri Sep 6 15:06:03 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 06 Sep 2013 17:06:03 +0200 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <5229E9A0.2050709@redhat.com> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> <5229839E.9070105@redhat.com> <5229CEBD.7070705@redhat.com> <5229D973.2080106@redhat.com> <5229DFDB.7060605@redhat.com> <5229E29C.20404@redhat.com> <5229E9A0.2050709@redhat.com> Message-ID: <5229EF5B.1050206@redhat.com> On 09/06/2013 04:41 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 09/06/2013 03:59 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 09/06/2013 02:46 PM, Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> On 09/05/2013 07:48 PM, Rob Crittenden wrote: >>>>>>> Petr Viktorin wrote: [...] >>>>>>>> # P.S. >>>>>>>> >>>>>>>> I believe that we should strive to put our info about default >>>>>>>> permissions, containers, settings, and the schema for each >>>>>>>> plugin in >>>>>>>> the >>>>>>>> actual plugin module, rather than it all being split across several >>>>>>>> ldif/update files. This would make this data more manageable, >>>>>>>> introspectable and consistent, expose dependencies between plugins, >>>>>>>> and >>>>>>>> make it possible to actually write self-contained plugins. >>>>>>>> This should be done when the time comes for a new version of the >>>>>>>> ldap-updater. >>>> [...] >>>>> >>>>> Well, my alarm bells are going off. This would require some >>>>> significant >>>>> review each and every time any object is updated. Consider how many >>>>> times API.txt is overlooked, and it has no security implications. >>>> >>>> Consider how many times the ldif or update files were overlooked. >>>> API.txt is checked during every build, whereas ldif/update files not, >>>> and are tedious to check. >>>> >>>> We can of course add a similar file for ACIs, in fact I was planning to >>>> do so. Any changes can be then reviewed both in the source and (like >>>> now) in the resulting ldif. Also, the information would be in one >>>> place, >>>> rather than in ldif (which doesn't apply on upgrades) and in update >>>> files. >>>> I believe it would actually be better for security. >>> >>> The plan at the time updates were added was to move absolutely >>> everything out of ldif and into updates. It just never happened. >> >> Good to know. Is it still the plan? Do I only need to change the update >> files? > > It would be my preference. It goes beyond only changing one set of > files. The existing ldif that duplicate things need to be deprecated. We > can't get to a zero-ldif install, but it can be reduced significantly. Thanks, I'll keep it in mind. >>>>> I can't say I'm a fan of programmatic ACI generation. >>>> >>>> Well, I'm sure not going to write the ACIs for this feature by hand. It >>>> would help I could actually polish, commit and integrate the script >>>> that >>>> generates them. >>>> In my book, programmatic generation is much better than copy+paste. >>>> >>> >>> On the other hand, it becomes very easy to just rely on it and not >>> closely examine the output. >> >> That is a question of checking the changes. Frankly I don't see that >> much difference between not checking after updates and not checking >> after copy+pasting. >> If nothing, the existence of an ACI.txt should remind us that security >> is at stake. >> Also, if the objectclasses change this will alert us that ACIs need >> changing as well. >> > > Well, there was little copy+pasting before. The majority of the current > ACIs were generated by permission-add. > > The difference is that ACI changes may be automatically spawned by an > update to the plugin. Right now the risk is that attributes won't be > added to a write list, so there is limited potential damage. It is just > annoying. If instead it will potentially grant both read and write > access the scope of harm grows. We have two cases here: 1. A core IPA plugin is changed. In this case the change is reflected in our ACI.txt file and vetted by developers. 2. A third-party plugin is changed. Currently third-party plugins needed to either change core IPA update files (which I doubt plugin authors will want to do), or have their own mechanism for granting permissions (yes, plugins can be bent to do anything, including installing their own updates). It would actually be more secure if we provided a tested mechanism to them. Also, read ACIs that would get deployed on install and then *only* changed by the user would mean that we can either: - Never add new hidden/password attributes, for (targetattr != ...), or - Never add new normal attributes, for (targetattr == ...), - Or (as we IMO do now) assume admins will manually update anything they have changed. -- Petr? From dpal at redhat.com Fri Sep 6 15:18:10 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 06 Sep 2013 11:18:10 -0400 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <5229E29C.20404@redhat.com> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> <5229839E.9070105@redhat.com> <5229CEBD.7070705@redhat.com> <5229D973.2080106@redhat.com> <5229DFDB.7060605@redhat.com> <5229E29C.20404@redhat.com> Message-ID: <5229F232.4090507@redhat.com> On 09/06/2013 10:11 AM, Petr Viktorin wrote: > On 09/06/2013 03:59 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 09/06/2013 02:46 PM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On 09/05/2013 07:48 PM, Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>>>> Hello, >>>>>>> I have some notes and questions on >>>>>>> https://fedorahosted.org/freeipa/ticket/3566 (Control access of >>>>>>> user >>>>>>> roles to server functions). >>> [...] >>>> Right, I just want to know why it was proposed to add 2 ACIs for every >>>> container. >>> >>> One for the container itself, one for the objects beneath it. >>> >>> I don't see a straightforward way to allow access to both in a single >>> permission. (Currently, permissions need to be at $SUFFIX, so their >>> subtrees are specified by target.) >>> >>> [...] >> >> Right. I'm not sure you need to grant read,search,compare to the >> container. Have you tested that? > > To be honest, I assumed some from the bug description. I'll test it. > If it's not necessary there'll be one ACI per object type. > > [...] >>>>>> >>>>>>> >>>>>>> # P.S. >>>>>>> >>>>>>> I believe that we should strive to put our info about default >>>>>>> permissions, containers, settings, and the schema for each >>>>>>> plugin in >>>>>>> the >>>>>>> actual plugin module, rather than it all being split across several >>>>>>> ldif/update files. This would make this data more manageable, >>>>>>> introspectable and consistent, expose dependencies between plugins, >>>>>>> and >>>>>>> make it possible to actually write self-contained plugins. >>>>>>> This should be done when the time comes for a new version of the >>>>>>> ldap-updater. >>> [...] >>>> >>>> Well, my alarm bells are going off. This would require some >>>> significant >>>> review each and every time any object is updated. Consider how many >>>> times API.txt is overlooked, and it has no security implications. >>> >>> Consider how many times the ldif or update files were overlooked. >>> API.txt is checked during every build, whereas ldif/update files not, >>> and are tedious to check. >>> >>> We can of course add a similar file for ACIs, in fact I was planning to >>> do so. Any changes can be then reviewed both in the source and (like >>> now) in the resulting ldif. Also, the information would be in one >>> place, >>> rather than in ldif (which doesn't apply on upgrades) and in update >>> files. >>> I believe it would actually be better for security. >> >> The plan at the time updates were added was to move absolutely >> everything out of ldif and into updates. It just never happened. > > Good to know. Is it still the plan? Do I only need to change the > update files? > >>>> I can't say I'm a fan of programmatic ACI generation. >>> >>> Well, I'm sure not going to write the ACIs for this feature by hand. It >>> would help I could actually polish, commit and integrate the script >>> that >>> generates them. >>> In my book, programmatic generation is much better than copy+paste. >>> >> >> On the other hand, it becomes very easy to just rely on it and not >> closely examine the output. > > That is a question of checking the changes. Frankly I don't see that > much difference between not checking after updates and not checking > after copy+pasting. > If nothing, the existence of an ACI.txt should remind us that security > is at stake. > Also, if the objectclasses change this will alert us that ACIs need > changing as well. > We probably can add some sort of a check to a patch apply command that if a file that does ACI part is added or modified in a patch and the corresponding ACI.txt file is not updated the patch apply operation would abort. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From akrivoka at redhat.com Fri Sep 6 18:42:21 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 06 Sep 2013 20:42:21 +0200 Subject: [Freeipa-devel] [PATCH] IPA-CLIENT: NSS test needs to check against the domain name In-Reply-To: <5228C08F.80902@redhat.com> References: <5228C08F.80902@redhat.com> Message-ID: <522A220D.60209@redhat.com> On 09/05/2013 07:34 PM, Stephen Gallagher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In situations where the FreeIPA server is configured with > different domain and realm values, we will fail to test for the > admin account in the ipa-client-install script. With this patch, > we will correctly run 'getent passwd admin at DOMAIN' > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.14 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlIowI8ACgkQeiVVYja6o6ORiwCgnX1uVtWTktYpKdrVxuVTyQjZ > WCsAn0ULhTR0TsfcCsEpknVwgkAN0d7F > =KpH4 > -----END PGP SIGNATURE----- > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel You should also replace 'cli_realm' with 'cli_domain' in the 'if not found:' block that follows. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gh.mdgh at gmail.com Sat Sep 7 14:17:42 2013 From: gh.mdgh at gmail.com (Mahmoud) Date: Sat, 7 Sep 2013 18:47:42 +0430 Subject: [Freeipa-devel] Change Kerberos krb5kdc code Message-ID: Hello, I would like to change krb5kdc action. I install FreeIPA, then download kerberos source code and change its kdc source code and replace /usr/sbin/krb5kdc with /usr/local/sbin/krb5kdc. when I restart the kerberos, following error occurred: krb5kdc: cannot initialize realm EXAMPLE.COM I think kerberos can not connect to 389 directory. Could you help me, please? Thank you very much for your time and attention Best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Sat Sep 7 14:45:07 2013 From: simo at redhat.com (Simo Sorce) Date: Sat, 07 Sep 2013 10:45:07 -0400 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <5229CEBD.7070705@redhat.com> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> <5229839E.9070105@redhat.com> <5229CEBD.7070705@redhat.com> Message-ID: <1378565107.2804.1122.camel@willson.li.ssimo.org> Sorry to come late to this thread. I think I like some of Petr plan, but not all of it. On Fri, 2013-09-06 at 08:46 -0400, Rob Crittenden wrote: > Martin Kosek wrote: > > On 09/05/2013 07:48 PM, Rob Crittenden wrote: > >> Petr Viktorin wrote: > >>> Hello, > >>> I have some notes and questions on > >>> https://fedorahosted.org/freeipa/ticket/3566 (Control access of user > >>> roles to server functions). > >>> > >>> > >>> An IPA terminology refresher for reference: > >>> - ACI: The DS-level permission. > >>> - Permission: IPA object that encapsulates one ACI. Example: "add user". > >>> Permissions aren't as flexible as raw ACIs. > >>> - Privilege: IPA object that groups several permissions, e.g. with a > >>> "manage users" privilege you can "add user", "modify user", ... > >>> - Role: IPA object that groups privileges, e.g. an "User Administrator" > >>> can manage users and groups. Roles are assigned to users/groups/hosts. > >>> > >>> > >>> # Permission structure > >>> > >>> I think it would be best to have two permissions for each object, one > >>> for the entries and one for the container. This keeps the ACIs > >>> manageable with existing permission API: > >>> > >>> aci: (target = "ldap:///cn=*,cn=groups,cn=accounts,$SUFFIX")(version > >>> 3.0;acl "permission:Read Groups";allow (read,search,compare) groupdn = > >>> "ldap:///cn=Read Groups,cn=permissions,cn=pbac,$SUFFIX";) > >>> > >>> aci: (target = "ldap:///cn=groups,cn=accounts,$SUFFIX")(version 3.0;acl > >>> "permission:Read Group Container";allow (read,search,compare) groupdn = > >>> "ldap:///cn=Read Group Container,cn=permissions,cn=pbac,$SUFFIX";) > >>> > >>> These would be combined in a "Group Readers" privilege. > >>> > >>> All the privileges would be granted to a role called "Users", which > >>> would contain ipausers and admins. > >> > >> I'm not sure I follow, what are you trying to achieve here? The more ACIs the > >> slower the processing. > > > > One of the main reason for this feature is to get rid of the global allowing ACI: And this is good, one-size-fit-all, doesn't work anymore, however we need to try to keep the number of ACIs low anyway, this can be done my smartly and programmatically generate ACIs, however we need a very complete test suite and in order to have a complete one, we need enough information to know what is the intended behavior. Plus I think for robustness the test suite should be generated from different code, so that bugs in the ACI generation code does not also cause blind spots in the ACI testing code. > > aci: (targetfilter = > > "(&(!(objectClass=ipaToken))(!(objectClass=ipatokenTOTP))(!(objectClass=ipatokenRadiusConfiguration)))")(target > > != "ldap:///idnsname=*,cn=dns,$SUFFIX")(targetattr != "userPassword || > > krbPrincipalKey || sambaLMPassword || sambaNTPassword || passwordHistory || > > krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutgoing || > > ipaNTTrustAuthIncoming")(version 3.0; acl "Enable Anonymous access"; allow > > (read, search, compare) userdn = "ldap:///anyone";) > > > > ... as this ACI does not scale and adds burden for developers or plugin author > > wishing to add an attribute that should not be visible by default. Number of > > ACIs should still be kept low, that's true. > > Right, I just want to know why it was proposed to add 2 ACIs for every > container. I am puzzled as well. > >> > >>> # External users & system accounts > >>> > >>> I'm not sure how to handle external users here, since they're not added > >>> to any group. Either we'll need a special ACI for them, or somehow make > >>> it possible to add non-group sets of users to Roles. > >>> > >>> The same goes for system accounts, except those aren't even implemented > >>> in IPA yet (https://fedorahosted.org/freeipa/ticket/2801). > >> > >> I think they would have to be part of a group. Otherwise 389-ds has nothing to > >> evaluate against (and even with groups I'm not 100% sure it'll work). > >> > >>> > >>> # Protected attributes > >>> > >>> How to handle passwords and other non-public attributes? I'm thinking > >>> about keeping a global list of such attributes, and applying it to each > >>> read permission ACI on normal operations and upgrades; either generating > >>> a (targetfilter != ...) clause or filtering the (targetfilter = ...) one. > >>> Possibly that list would be configurable and stored in LDAP. > >>> > >>> For reference, we currently exclude these in the anonymous read rule: > >>> "userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword > >>> || passwordHistory || krbMKey || userPKCS12 || ipaNTHash || > >>> ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming" No I will veto anything that overhauls ACIs and keeps negative filtering lists. Any big change to the ACIs system *MUST* get rid of ( targetattr != list ). We already risked many times of exposing data and a few years ago had to issue a CVE because of this. We do not want to keep doing it. Especially if you are building this system to allow plugins to change permissions you do not want to rely on the authors to remember to add negative entries. > >> It could get ugly real fast, and potentially cause a lot of extra processing. I > >> think the object(s) for each attribute should be considered so these wouldn't > >> have to be applied to every ACI but only those that are affected. We don't need > >> to worry about userPassword in groups, for example. > > > > I think that a decision that a param should not be included in default read > > rule should be included in the param object itself, see below. I really do not want to see the ACI templates/definition/call it how you want int the framework, because the framework will need to change with versions of IPA but the data may remain in LDAP for long. therefore any ACI template should be stored in LDAP, probably under cn=etc,$suffix. It may make sense to have cn=aci-templates,cn=etc,$suffix, and then within that container (accessible only by security admins) we have one template per object/container, that is used to generate ACIs. Something like: dn: cn=users,cn=aci-templates,cn=etc,$suffix objectclass: ipaAciTemplate anonReadAttributes: authReadAttributes: selfReadAttributes: selfWriteAttributes: and so on. These are the defaults, only attributes that must be disclosed are listed, *no* negative lists, the default is changed globaly to deny all, and if there is no allow ACI an attribute is inaccessible by default. This allows easy customization, if someone decides 'description' should be kept confidential, all he needs to do is to remove it from the right list (and perhaps add it to a privileged list), and just run a tool that regenerates and changes the default ACIs for the container. * No need to modify framework code anywhere. * > >> > >>> > >>> # Compat tree > >>> > >>> Do we want to reuse the read privileges for the compat tree, or create > >>> extra ones? > >> > >> I don't think so. Why not ? > >>> > >>> > >>> # Combining read rights > >>> > >>> I think (read, search, compare) should be exposed in permission objects > >>> as a single right. Or is there a reason to keep it split? > >> > >> Yes, they are separate for a reason. Using only search and compare isn't > >> common, but it isn't unheard of either. For example, to be able to detect the > >> presence of an attribute you can provide just the search permission. > > > > Wouldn't most users use the (read, search, compare) triple? It would lower our > > number of ACIs significantly if we do not have 3 permissions per each object. > > There is nothing to prevent an ACI from containing multiple permissions. > I wasn't proposing that. But rolling these three logically into the same > thing in IPA I think is short-sighted. I think it would make sense for an optimizer ACI generator to come later at a second stage, where we go through the generated list and combine ACIs together. Ie the first version could generate three distinct ACIs for read, search and compare, and later on we add an optimizer that consolidates them into a single ACI. > >>> # P.S. > >>> > >>> I believe that we should strive to put our info about default > >>> permissions, containers, settings, and the schema for each plugin in the > >>> actual plugin module, rather than it all being split across several > >>> ldif/update files. This would make this data more manageable, > >>> introspectable and consistent, expose dependencies between plugins, and > >>> make it possible to actually write self-contained plugins. > >>> This should be done when the time comes for a new version of the > >>> ldap-updater. I agree with the above. > >> I don't think we really have any problems having a more or less monolithic set > >> up now. I think this would just add complexity. It also adds enormous flexibility. > > I actually think this could be a killer feature for the refactored ACI system. > > Let's take a host object as an example: > > > > class host(LDAPObject): > > """ > > Host object. > > """ > > ... > > takes_params = ( > > Str('fqdn', _hostname_validator, > > Str('description?', > > Str('l?', > > Str('nshostlocation?', > > Str('nshardwareplatform?', > > Str('nsosversion?', > > Str('userpassword?', > > Flag('random?', > > Str('randompassword?', > > Bytes('usercertificate?', validate_certificate, > > Str('krbprincipalname?', > > Str('macaddress*', > > Str('ipasshpubkey*', validate_sshpubkey_no_options, > > Str('userclass*', > > ) + ticket_flags_params > > ... > > > > It has the following standard default ACIs: > > > > aci: (target = "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX")(version > > 3.0;acl "permission:Add Hosts";allow (add) groupdn = "ldap:///cn=Add > > Hosts,cn=permissions,cn=pbac,$SUFFIX";) > > > > aci: (target = "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX")(version > > 3.0;acl "permission:Remove Hosts";allow (delete) groupdn = "ldap:///cn=Remove > > Hosts,cn=permissions,cn=pbac,$SUFFIX";) > > > > aci: (targetattr = "description || l || nshostlocation || nshardwareplatform || > > nsosversion")(target = > > "ldap:///fqdn=*,cn=computers,cn=accounts,$SUFFIX")(version 3.0;acl > > "permission:Modify Hosts";allow (write) groupdn = "ldap:///cn=Modify > > Hosts,cn=permissions,cn=pbac,$SUFFIX";) > > > > Out of those: > > - Add hosts is standard and can be generated automatically from host container > > and host primary key. > > - Remove Hosts is also standard and can be generated > > - Modify Hosts is a bit tricky as we have a list of host attributes that can be > > updated by default. Right now, this list is not maintained as it lies somewhere > > in delegation.ldif or some of our *.update file. > > - New Read Hosts could be also generated, we would just need to filter out > > attributes we do not want to be read (this should be recorded in the Param > > object itself, see even more below). If we put this information in simple attributes lists in LDAP (see above) and then generate out the defaults I think we'll get in a much better situation. > > This leads to outdated permissions not allowing privileged users to modify some > > parts of the host entry. Just to demonstrate, I found these 2 missing rights > > when testing a regular user with "Host Administrators" privilege: > > > > # kinit fbar > > # ipa host-add foo.example.com --force > > # ipa host-mod foo.example.com --macaddress=00:11:22:33:44:55 > > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the > > 'macAddress' attribute of entry > > 'fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. > > # ipa host-mod foo.example.com --class foo > > ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the > > 'userClass' attribute of entry > > 'fqdn=foo.example.com,cn=computers,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'. > > > > If the basic set of host ACI would be part of the host LDAPObject, we would > > have everything in one place and avoid issues like that. And we may fail to set the right ACIs on different replicas of slightly different versions. I agree with the idea, but the attribute lists should be in the LDAP tree not in the framework. As another example, if they are in LDAP you can remove an older plugin but the data related to it will not have its ACIs disappear, because even if we remove the related objects from the framework, we still have the default lists in LDAP (thin of upgrade situations too). > Default write > > privilege could be generated out of the takes_params. We would just need to > > filter out parameters that we do not want to be writable in default ACI, for > > example ipasshpubkey where we have a separate permission. > > > > We could mark this in the param: > > > > ... > > Str('ipasshpubkey*', validate_sshpubkey_no_options, > > ... > > default_aci=False > > ), > > ... > > > > and define a custom ACIs handling it and other special ACIs. Something like: > > > > class host(LDAPObject): > > """ > > Host object. > > """ > > ... > > extra_aci = [ > > ACI( > > dn=api.env.container_computers, > > name="Hosts can modify their own SSH public keys", > > attrs=['ipasshpubkey'], > > rights=['write'], > > bind='userdn = "ldap:///self"' > > ), > > ACI( > > dn=api.env.container_computers, > > name="Hosts can modify their own certs and keytabs", > > attrs=['usercertificate', 'krblastpwdchange', 'description', 'l', > > 'nshostlocation', 'nshardwareplatform', 'nsosversion'], > > rights=['write'], > > bind='userdn = "ldap:///self"' > > ), > > ACI( > > dn=api.env.container_computers, > > name="Hosts can manage other host Certificates and kerberos keys", > > attrs=['userCertificate', 'krbPrincipalKey'], > > rights=['write'], > > bind='userdn = "userattr = "parent[0,1].managedby#USERDN""' > > ), > > ... > > ] > > > > IMHO, this would have several benefits: > > 1) It would place Host entry, params and ACIs to one single location -> easier > > maintenance very brittle across versions. > > 2) It would make delegation.ldif and default-aci.ldif and *.update files > > shorter given that all these default ACIs would be removed harder to inspect, you have to go chase objects all around the code base, nack > > 3) It would make lives easier for plugin authors which would not have to deploy > > LDIFs or *.update files to deploy a new plugin or modify functionality of an > > existing one. Again even harder to inspect and if the admin 'disables' a plugin, now suddenly there is data in the LDAP server (that was added by the plugin) but no way for the system to know what are the default ACIs to apply. > > Makes sense? As a general plan yes, but I am deadset against having the defaults in framework code. They need to stay where the data is, and the actual ACIs are, in LDAP. > Well, my alarm bells are going off. This would require some significant > review each and every time any object is updated. Consider how many > times API.txt is overlooked, and it has no security implications. I agree this is an issue, we can get much more confidence (than we have even now) we a testing framework. Automated tests beats any dreadful review, for some things. I am not saying review shouldn't be very careful of course. > I can't say I'm a fan of programmatic ACI generation. Here I strongly disagree, we certainly need to be very confident of the generation code, but staring at an ACI that spans 6+ lines on the screen is extremely hard. It is *much* simpler to look at a list of attributes in an ldif/update file and see which ones are marked for read or write or add or delete or search, etc... If we are confident those list translate to ACI correctly it is a huge review win. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Sat Sep 7 14:47:27 2013 From: simo at redhat.com (Simo Sorce) Date: Sat, 07 Sep 2013 10:47:27 -0400 Subject: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created In-Reply-To: <20130905144406.GO21212@redhat.com> References: <20130905144406.GO21212@redhat.com> Message-ID: <1378565247.2804.1125.camel@willson.li.ssimo.org> On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: > + enctypes = KERB_ENCTYPE_DES_CBC_CRC | > + KERB_ENCTYPE_DES_CBC_MD5 | > + KERB_ENCTYPE_RC4_HMAC_MD5 | > + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | > + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; Why are we hardcoding support for *DES* enctype, we disable DES by default and also Windows never uses it by default. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Sat Sep 7 16:24:34 2013 From: simo at redhat.com (Simo Sorce) Date: Sat, 07 Sep 2013 12:24:34 -0400 Subject: [Freeipa-devel] Change Kerberos krb5kdc code In-Reply-To: References: Message-ID: <1378571074.2804.1224.camel@willson.li.ssimo.org> On Sat, 2013-09-07 at 18:47 +0430, Mahmoud wrote: > Hello, > > > I would like to change krb5kdc action. I install FreeIPA, then > download kerberos source code and change its kdc source code and > replace /usr/sbin/krb5kdc with /usr/local/sbin/krb5kdc. when I restart > the kerberos, following error occurred: > krb5kdc: cannot initialize realm EXAMPLE.COM > > > I think kerberos can not connect to 389 directory. > Could you help me, please? > FreeIPa uses itown plugin for the database backed, if you install the krb5kdc in a different location you probably also need to put the ipadb.so plugin somewhere under /usr/local Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Sat Sep 7 16:28:09 2013 From: simo at redhat.com (Simo Sorce) Date: Sat, 07 Sep 2013 12:28:09 -0400 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <1378355905.19352.35.camel@localhost> References: <1378355153.19352.29.camel@localhost> <1378355905.19352.35.camel@localhost> Message-ID: <1378571289.2804.1230.camel@willson.li.ssimo.org> On Thu, 2013-09-05 at 00:38 -0400, Nathaniel McCallum wrote: > On Thu, 2013-09-05 at 00:25 -0400, Nathaniel McCallum wrote: > > This patch has a few problems that I'd like some help with. There are a > > few notes here as well. > > > > 1. The handling of the 'key' option is insecure. It should probably be > > treated like a password (hidden from logs, etc). However, in this case, > > it is binary, so I'm not quite sure how to do that. Passing it as a > > command line option may be nice for scripting, but is potentially a > > security problem if it ends up in bash.history. It would also be nice if > > the encoding were base32 instead of base64, since nearly all the OTP > > tools use this encoding. > > > > 2. The 'key' option also appears in otp-find. I'd like to suppress this. > > How? > > > > 3. I had to make the 'id' option optional to make the uuid > > autogeneration work in otp-add. However, this has the side-effect that > > 'id' is now optional in all the other commands. This is particularly bad > > in the case of otp-del, where calling this command with no ID > > transparently removes all tokens. How can I make this optional for > > otp-add but required for all other commands? > > > > 4. otp-import is not implemented. I spent a few hours looking and I > > didn't find any otp tool that actually uses this xml format for > > exporting. Should we implement this now or wait until someone can > > actually export data to us? > > > > 5. otp-del happily deletes the last token for a user. How can I find out > > the dn of the user executing the command? Also, what is the right > > exception to throw in pre_callback()? > > > > 6. user-show does not list the associated tokens for this user. Do we > > care? It is a single search: otp-find --owner npmccallum. > > > > 7. otp-add only prints the qr code if the --qrcode option is specified. > > This is for two reasons. First, and most importantly, the qr code > > doesn't fit on a standard 24x80 terminal. I wanted to avoid dumping > > garbage on people's screens by default. Second, you may not always want > > the qr code output (like for a hard token or manual code entry). > > 8. If a user is deleted, the user's assigned tokens are left unmodified. > That is *not* to say they are orphaned. The owner attribute retains a dn > to an invalid user. This also means that otp-find --owner=deletedUser > will fail since we can't look up the deleted user. How does dirsrv > handle this for other relationships? Elsewhere we use the referential integrity plugin, but I am not entirely sure it will work here ? Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Sat Sep 7 18:01:59 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 7 Sep 2013 21:01:59 +0300 Subject: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created In-Reply-To: <1378565247.2804.1125.camel@willson.li.ssimo.org> References: <20130905144406.GO21212@redhat.com> <1378565247.2804.1125.camel@willson.li.ssimo.org> Message-ID: <20130907180158.GU21212@redhat.com> On Sat, 07 Sep 2013, Simo Sorce wrote: >On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: >> + enctypes = KERB_ENCTYPE_DES_CBC_CRC | >> + KERB_ENCTYPE_DES_CBC_MD5 | >> + KERB_ENCTYPE_RC4_HMAC_MD5 | >> + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | >> + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; > >Why are we hardcoding support for *DES* enctype, we disable DES by >default and also Windows never uses it by default. This is actually a copy of the same statement from fill_pdb_trusted_domain(). Should I remove it? RC4 enctype will be the only one available for Windows 2003 trusts then... -- / Alexander Bokovoy From simo at redhat.com Sat Sep 7 18:23:05 2013 From: simo at redhat.com (Simo Sorce) Date: Sat, 07 Sep 2013 14:23:05 -0400 Subject: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created In-Reply-To: <20130907180158.GU21212@redhat.com> References: <20130905144406.GO21212@redhat.com> <1378565247.2804.1125.camel@willson.li.ssimo.org> <20130907180158.GU21212@redhat.com> Message-ID: <1378578185.2804.1353.camel@willson.li.ssimo.org> On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: > On Sat, 07 Sep 2013, Simo Sorce wrote: > >On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: > >> + enctypes = KERB_ENCTYPE_DES_CBC_CRC | > >> + KERB_ENCTYPE_DES_CBC_MD5 | > >> + KERB_ENCTYPE_RC4_HMAC_MD5 | > >> + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | > >> + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; > > > >Why are we hardcoding support for *DES* enctype, we disable DES by > >default and also Windows never uses it by default. > This is actually a copy of the same statement from > fill_pdb_trusted_domain(). > > Should I remove it? Yes please remove DES types, is there any chance we can make this list configurable ? (not a hard requirement, only if ti is something easy to do, maybe as a further enhancement down the road). > RC4 enctype will be the only one available for > Windows 2003 trusts then... It's the only one 2003 enables by default anyway and the only one that we can use as DES is disabled on FreeIPA. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Sat Sep 7 18:32:59 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 7 Sep 2013 21:32:59 +0300 Subject: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created In-Reply-To: <1378578185.2804.1353.camel@willson.li.ssimo.org> References: <20130905144406.GO21212@redhat.com> <1378565247.2804.1125.camel@willson.li.ssimo.org> <20130907180158.GU21212@redhat.com> <1378578185.2804.1353.camel@willson.li.ssimo.org> Message-ID: <20130907183259.GV21212@redhat.com> On Sat, 07 Sep 2013, Simo Sorce wrote: >On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: >> On Sat, 07 Sep 2013, Simo Sorce wrote: >> >On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: >> >> + enctypes = KERB_ENCTYPE_DES_CBC_CRC | >> >> + KERB_ENCTYPE_DES_CBC_MD5 | >> >> + KERB_ENCTYPE_RC4_HMAC_MD5 | >> >> + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | >> >> + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; >> > >> >Why are we hardcoding support for *DES* enctype, we disable DES by >> >default and also Windows never uses it by default. >> This is actually a copy of the same statement from >> fill_pdb_trusted_domain(). >> >> Should I remove it? > >Yes please remove DES types, is there any chance we can make this list >configurable ? (not a hard requirement, only if ti is something easy to >do, maybe as a further enhancement down the road). If you can point me to some place in cn=config or $SUFFIX that could be read by cifs/fqdn on ipa-sam module init, I can look in fetching that. But I suspect it is much harder to deduce exact list of supported types. > >> RC4 enctype will be the only one available for >> Windows 2003 trusts then... > >It's the only one 2003 enables by default anyway and the only one that >we can use as DES is disabled on FreeIPA. Since admin could enable DES on FreeIPA manually, right now ipa-sam would allow using DES to Windows 2003. If we remove DES enctypes unconditionally, it would not be possible. -- / Alexander Bokovoy From simo at redhat.com Sat Sep 7 18:41:17 2013 From: simo at redhat.com (Simo Sorce) Date: Sat, 07 Sep 2013 14:41:17 -0400 Subject: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created In-Reply-To: <20130907183259.GV21212@redhat.com> References: <20130905144406.GO21212@redhat.com> <1378565247.2804.1125.camel@willson.li.ssimo.org> <20130907180158.GU21212@redhat.com> <1378578185.2804.1353.camel@willson.li.ssimo.org> <20130907183259.GV21212@redhat.com> Message-ID: <1378579277.2804.1360.camel@willson.li.ssimo.org> On Sat, 2013-09-07 at 21:32 +0300, Alexander Bokovoy wrote: > On Sat, 07 Sep 2013, Simo Sorce wrote: > >On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: > >> On Sat, 07 Sep 2013, Simo Sorce wrote: > >> >On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: > >> >> + enctypes = KERB_ENCTYPE_DES_CBC_CRC | > >> >> + KERB_ENCTYPE_DES_CBC_MD5 | > >> >> + KERB_ENCTYPE_RC4_HMAC_MD5 | > >> >> + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | > >> >> + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; > >> > > >> >Why are we hardcoding support for *DES* enctype, we disable DES by > >> >default and also Windows never uses it by default. > >> This is actually a copy of the same statement from > >> fill_pdb_trusted_domain(). > >> > >> Should I remove it? > > > >Yes please remove DES types, is there any chance we can make this list > >configurable ? (not a hard requirement, only if ti is something easy to > >do, maybe as a further enhancement down the road). > If you can point me to some place in cn=config or $SUFFIX that could be > read by cifs/fqdn on ipa-sam module init, I can look in fetching that. > But I suspect it is much harder to deduce exact list of supported types. Look in: cn=REALM.NAME,cn=kerberos,$SUFFIX there we have 2 lists: krbDefaultEncSaltTypes <- use this krbSupportedEncSaltTypes in util/ipa_krb5.c we have then the funciton parse_bval_key_sal_tuples() that can covert strings to enctypes. > >> RC4 enctype will be the only one available for > >> Windows 2003 trusts then... > > > >It's the only one 2003 enables by default anyway and the only one that > >we can use as DES is disabled on FreeIPA. > Since admin could enable DES on FreeIPA manually, right now ipa-sam > would allow using DES to Windows 2003. If we remove DES enctypes > unconditionally, it would not be possible. If you look at the attributes I pointed you at above, then you have a way to support DES by simply changing the defaults and restarting FreeIPA. DES is dead anyway and not sufficiently secure for cross-realm keys anymore, even if we do not support it at all I think we are just fine. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Mon Sep 9 07:03:31 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Sep 2013 09:03:31 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <1378571289.2804.1230.camel@willson.li.ssimo.org> References: <1378355153.19352.29.camel@localhost> <1378355905.19352.35.camel@localhost> <1378571289.2804.1230.camel@willson.li.ssimo.org> Message-ID: <522D72C3.8040200@redhat.com> On 09/07/2013 06:28 PM, Simo Sorce wrote: > On Thu, 2013-09-05 at 00:38 -0400, Nathaniel McCallum wrote: >> On Thu, 2013-09-05 at 00:25 -0400, Nathaniel McCallum wrote: >>> This patch has a few problems that I'd like some help with. There are a >>> few notes here as well. >>> >>> 1. The handling of the 'key' option is insecure. It should probably be >>> treated like a password (hidden from logs, etc). However, in this case, >>> it is binary, so I'm not quite sure how to do that. Passing it as a >>> command line option may be nice for scripting, but is potentially a >>> security problem if it ends up in bash.history. It would also be nice if >>> the encoding were base32 instead of base64, since nearly all the OTP >>> tools use this encoding. >>> >>> 2. The 'key' option also appears in otp-find. I'd like to suppress this. >>> How? >>> >>> 3. I had to make the 'id' option optional to make the uuid >>> autogeneration work in otp-add. However, this has the side-effect that >>> 'id' is now optional in all the other commands. This is particularly bad >>> in the case of otp-del, where calling this command with no ID >>> transparently removes all tokens. How can I make this optional for >>> otp-add but required for all other commands? >>> >>> 4. otp-import is not implemented. I spent a few hours looking and I >>> didn't find any otp tool that actually uses this xml format for >>> exporting. Should we implement this now or wait until someone can >>> actually export data to us? >>> >>> 5. otp-del happily deletes the last token for a user. How can I find out >>> the dn of the user executing the command? Also, what is the right >>> exception to throw in pre_callback()? >>> >>> 6. user-show does not list the associated tokens for this user. Do we >>> care? It is a single search: otp-find --owner npmccallum. >>> >>> 7. otp-add only prints the qr code if the --qrcode option is specified. >>> This is for two reasons. First, and most importantly, the qr code >>> doesn't fit on a standard 24x80 terminal. I wanted to avoid dumping >>> garbage on people's screens by default. Second, you may not always want >>> the qr code output (like for a hard token or manual code entry). >> >> 8. If a user is deleted, the user's assigned tokens are left unmodified. >> That is *not* to say they are orphaned. The owner attribute retains a dn >> to an invalid user. This also means that otp-find --owner=deletedUser >> will fail since we can't look up the deleted user. How does dirsrv >> handle this for other relationships? > > Elsewhere we use the referential integrity plugin, but I am not entirely > sure it will work here ? > > Simo. IMO it should. We will probably also need to add new indices in order to let Referential Integrity work efficiently. See https://fedorahosted.org/freeipa/ticket/2866 for more information how was this done in the past. Related thread on freeipa-devel: http://www.redhat.com/archives/freeipa-devel/2012-September/msg00027.html I can provide more information if needed. Martin From jcholast at redhat.com Mon Sep 9 09:17:02 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 09 Sep 2013 11:17:02 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <52161568.7060702@redhat.com> References: <52161568.7060702@redhat.com> Message-ID: <522D920E.4040703@redhat.com> Another question: Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive set of trusted CAs, or is using one set for everything good enough? Using distinctive sets would allow granular control over what CA is trusted for what service (e.g. trust CA1 to issue certificates for LDAP and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm not sure how useful that would be in the real world. Honza -- Jan Cholasta From pviktori at redhat.com Mon Sep 9 11:00:01 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Sep 2013 13:00:01 +0200 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <1378565107.2804.1122.camel@willson.li.ssimo.org> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> <5229839E.9070105@redhat.com> <5229CEBD.7070705@redhat.com> <1378565107.2804.1122.camel@willson.li.ssimo.org> Message-ID: <522DAA31.20900@redhat.com> On 09/07/2013 04:45 PM, Simo Sorce wrote: > Sorry to come late to this thread. > > I think I like some of Petr plan, but not all of it. > > On Fri, 2013-09-06 at 08:46 -0400, Rob Crittenden wrote: [...] >>>> I'm not sure I follow, what are you trying to achieve here? The more ACIs the >>>> slower the processing. >>> >>> One of the main reason for this feature is to get rid of the global allowing ACI: > > And this is good, one-size-fit-all, doesn't work anymore, however we > need to try to keep the number of ACIs low anyway, this can be done my > smartly and programmatically generate ACIs, however we need a very > complete test suite and in order to have a complete one, we need enough > information to know what is the intended behavior. Plus I think for > robustness the test suite should be generated from different code, so > that bugs in the ACI generation code does not also cause blind spots in > the ACI testing code. I don't want to build a "smart" system; it should rather be simple and straightforward. Other than that I agree, good tests are always necessary. [...] >> Right, I just want to know why it was proposed to add 2 ACIs for every >> container. > > I am puzzled as well. Consider that point dropped; I trusted the bug description without checking. >>>>> How to handle passwords and other non-public attributes? I'm thinking >>>>> about keeping a global list [...] > > No I will veto anything that overhauls ACIs and keeps negative filtering > lists. > Any big change to the ACIs system *MUST* get rid of ( targetattr != > list ). > > We already risked many times of exposing data and a few years ago had to > issue a CVE because of this. We do not want to keep doing it. Especially > if you are building this system to allow plugins to change permissions > you do not want to rely on the authors to remember to add negative > entries. +1, a negative list doesn't make sense any more. >>>> It could get ugly real fast, and potentially cause a lot of extra processing. I >>>> think the object(s) for each attribute should be considered so these wouldn't >>>> have to be applied to every ACI but only those that are affected. We don't need >>>> to worry about userPassword in groups, for example. >>> >>> I think that a decision that a param should not be included in default read >>> rule should be included in the param object itself, see below. > > I really do not want to see the ACI templates/definition/call it how you > want int the framework, because the framework will need to change with > versions of IPA but the data may remain in LDAP for long. therefore any > ACI template should be stored in LDAP, probably under cn=etc,$suffix. > > It may make sense to have cn=aci-templates,cn=etc,$suffix, and then > within that container (accessible only by security admins) we have one > template per object/container, that is used to generate ACIs. > > Something like: > > dn: cn=users,cn=aci-templates,cn=etc,$suffix > objectclass: ipaAciTemplate > anonReadAttributes: > authReadAttributes: > selfReadAttributes: > selfWriteAttributes: > > and so on. > These are the defaults, only attributes that must be disclosed are > listed, *no* negative lists, the default is changed globaly to deny all, > and if there is no allow ACI an attribute is inaccessible by default. > > This allows easy customization, if someone decides 'description' should > be kept confidential, all he needs to do is to remove it from the right > list (and perhaps add it to a privileged list), and just run a tool that > regenerates and changes the default ACIs for the container. > * No need to modify framework code anywhere. * +1 to storing the attribute lists in LDAP. I don't like the Template idea though. First, on IPA upgrades, we need to be able to add attributes to the ACIs. Automatically. We cannot make the IPA-generated lists user-modifiable. If some past upgrade added a readable 'description' attribute, but the admin decides that it should not be readable, the next upgrade should not re-add it. So we need to store the IPA defaults and user changes separately. Second, we already have a place where users can customize ACIs: the permissions. I don't see the point of another layer. The only thing we're adding here over regular permissions is the aforementioned ability to auto-add new attributes on upgrades. We just need a special "managed" permission for each object's "anon read", "auth read", "self read", "self write", etc. I propose a new Permission type with three lists: attributes added by IPA, attributes added by the admin, and attributes removed by the admin. On IPA updates, new items can be added to the first list, and the ACI gets regenerated from all three. This ensures that an admin's changes get preserved across updates. If we mark a Permission as SYSTEM, old IPA versions won't try to locate or touch its ACI, but they'll still be able to add it to privileges and roles using the existing API/CLI/UI. So we'd have something like: cn=Read Users,cn=permissions,cn=pbac,$SUFFIX objectclass: ipaPermission objectclass: ipaManagedPermission ipaDefaultAttributes: ipaAdminAddedAttributes: ipaAdminExcludedAttributes: ipaPermissionType: SYSTEM Admins that don't want IPA updates messing with their ACIs can just remove the permission from privileges and add custom plain permissions instead. (Or possibly even convert the default permission to non-managed, or delete it -- if we write UI to do+undo these actions.) >>>>> # Combining read rights >>>>> >>>>> I think (read, search, compare) should be exposed in permission objects >>>>> as a single right. Or is there a reason to keep it split? >>>> >>>> Yes, they are separate for a reason. Using only search and compare isn't >>>> common, but it isn't unheard of either. For example, to be able to detect the >>>> presence of an attribute you can provide just the search permission. >>> >>> Wouldn't most users use the (read, search, compare) triple? It would lower our >>> number of ACIs significantly if we do not have 3 permissions per each object. >> >> There is nothing to prevent an ACI from containing multiple permissions. >> I wasn't proposing that. But rolling these three logically into the same >> thing in IPA I think is short-sighted. > > I think it would make sense for an optimizer ACI generator to come later > at a second stage, where we go through the generated list and combine > ACIs together. > > Ie the first version could generate three distinct ACIs for read, search > and compare, and later on we add an optimizer that consolidates them > into a single ACI. For the default permissions I'd rather generate ACIs with all three. Admins (or IPA if needed) can add an additional permission if some attribute only needs search. -- Petr? From pviktori at redhat.com Mon Sep 9 11:38:25 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Sep 2013 13:38:25 +0200 Subject: [Freeipa-devel] [PATCH] 0062 Replace ntpdate calls with ntpd In-Reply-To: <52273566.2040405@redhat.com> References: <5224A94F.6070605@redhat.com> <5225C4EC.8060605@redhat.com> <52273566.2040405@redhat.com> Message-ID: <522DB331.9060105@redhat.com> On 09/04/2013 03:28 PM, Ana Krivokapic wrote: > On 09/03/2013 01:15 PM, Petr Viktorin wrote: >> On 09/02/2013 05:05 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch addresses tickethttps://fedorahosted.org/freeipa/ticket/3797. >>> >> >> Thanks! I have a question. >> >>> - # retry several times -- logic follows /etc/init.d/ntpdate >>> - # implementation >>> + # retry several times >>> for retry in range(0, 3): >> >> What's the reason to try several times? Is it still necessary with ntpd? >> I checked /etc/init.d/ntpdate in RHEL (since Fedora doesn't have it any more) >> and I didn't see any repeating. >> > > I am not sure what the reason for trying several times was. My testing didn't > reveal any need for that, but I left the code there mainly because it returns > immediately after successful sync, so there is no harm. > > Attached is a version of the patch without the repetition. > Thanks, ACK, pushed to master: 28144e358c38e1c27eeb332b02d8470f18913af6 -- Petr? From pviktori at redhat.com Mon Sep 9 12:21:53 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Sep 2013 14:21:53 +0200 Subject: [Freeipa-devel] [PATCH] 0064 Fix invocations of FileError in ipa-client-install In-Reply-To: <52274021.808@redhat.com> References: <52274021.808@redhat.com> Message-ID: <522DBD61.3090702@redhat.com> On 09/04/2013 04:13 PM, Ana Krivokapic wrote: > Hello, > > This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3758. Thanks, ACK, pushed to master: 66242e6ab0ab21eb39f3fbdaa586e8e38663faae -- Petr? From pviktori at redhat.com Mon Sep 9 13:35:07 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Sep 2013 15:35:07 +0200 Subject: [Freeipa-devel] [PATCH 0015] Add support for managing user auth types In-Reply-To: <1378353865.19352.9.camel@localhost> References: <1378353865.19352.9.camel@localhost> Message-ID: <522DCE8B.9040009@redhat.com> On 09/05/2013 06:04 AM, Nathaniel McCallum wrote: > patch attached Thanks, some comments below. Git complains about trailing whitespace in the patch, please strip it. > freeipa-npmccallum-0015-Add-support-for-managing-user-auth-types.patch > > >>From 757436ccc431d26a3e62de830dad0b107a6c48ff Mon Sep 17 00:00:00 2001 > From: Nathaniel McCallum > Date: Wed, 4 Sep 2013 23:35:36 -0400 > Subject: [PATCH] Add support for managing user auth types > > https://fedorahosted.org/freeipa/ticket/3368 > --- > ipalib/plugins/config.py | 16 ++++++++++++++++ > ipalib/plugins/user.py | 32 ++++++++++++++++++++++---------- > 2 files changed, 38 insertions(+), 10 deletions(-) > > diff --git a/ipalib/plugins/config.py b/ipalib/plugins/config.py > index b9cf05016bf80cd48134cca5a50cdca7db423ca9..692ca22db70eb9a81a49eab6dc1e23284c8a9946 100644 > @@ -210,6 +218,14 @@ class config_mod(LDAPUpdate): > > def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): > assert isinstance(dn, DN) > + > + if 'ipauserauthtype' in entry_attrs: > + if 'objectclass' not in entry_attrs: > + (_dn, _entry_attrs) = ldap.get_entry(dn, ['objectclass']) > + entry_attrs['objectclass'] = _entry_attrs['objectclass'] > + if 'ipauserauthtypeclass' not in entry_attrs['objectclass']: > + entry_attrs['objectclass'].append('ipauserauthtypeclass') Shouldn't we rather add ipaUserAuthType to the ipaGuiConfig objectclass? If not, we should still update ipaConfig on IPA update update rather than here; install/updates/50-ipaconfig.update would be a good place. > diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py > index 471981f48204209753eda2fb994d4c653dca0fa2..02f62120d281a873dfd9c21e1b855b112cca05a4 100644 [...] > @@ -633,14 +640,19 @@ class user_mod(LDAPUpdate): > entry_attrs['userpassword'] = ipa_generate_password(user_pwdchars) > # save the password so it can be displayed in post_callback > setattr(context, 'randompassword', entry_attrs['userpassword']) > + > + if 'objectclass' not in entry_attrs: > + (_dn, _entry_attrs) = ldap.get_entry(dn, ['objectclass']) > + entry_attrs['objectclass'] = _entry_attrs['objectclass'] The framework is forcing some pretty ugly code here. I've filed https://fedorahosted.org/freeipa/ticket/3914 to simplify this in the future. Just a note, it's no longer necessary to use (_dn, _entry_attrs) here; ldap.get_entry() now returns a dict-like entry directly so you can use: _entry = ldap.get_entry(dn, ['objectclass']) entry_attrs['objectclass'] = _entry['objectclass'] In fact, unpacking the entry into a tuple returns the DN and the entry object itself. This: (dn, entry) = ldap.get_entry(...) is exactly equivalent to: entry = ldap.get_entry(...) dn = entry.dn but the former is deprecated. -- Petr? From simo at redhat.com Mon Sep 9 13:36:54 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 09 Sep 2013 09:36:54 -0400 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <522D920E.4040703@redhat.com> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> Message-ID: <1378733814.2804.1425.camel@willson.li.ssimo.org> On Mon, 2013-09-09 at 11:17 +0200, Jan Cholasta wrote: > Another question: > > Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive > set of trusted CAs, or is using one set for everything good enough? > Using distinctive sets would allow granular control over what CA is > trusted for what service (e.g. trust CA1 to issue certificates for LDAP > and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm > not sure how useful that would be in the real world. Seem very complicated. At most I would see as sort of useful to be able to set a different CA just for HTTP (due to default browsers list of CA), but not for anything else. But for this case I would rather write instructions on how to create a frontend on a *different* server, that just proxies in all requests to FreeIPA, just for people that want to use browsers w/o distributing the FreeIPA CA cert. That will solve their problem w/o complicating ours. We could also explain how to configure SNI (easier than proxy, but depends on whether mod_nss supports it, mod_ssl does), so that people can use a public cert with a 'public' name and keep FreeIPA own certs for internal management and joins etc... Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Sep 9 13:46:28 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 09 Sep 2013 09:46:28 -0400 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <522DAA31.20900@redhat.com> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> <5229839E.9070105@redhat.com> <5229CEBD.7070705@redhat.com> <1378565107.2804.1122.camel@willson.li.ssimo.org> <522DAA31.20900@redhat.com> Message-ID: <1378734388.2804.1435.camel@willson.li.ssimo.org> On Mon, 2013-09-09 at 13:00 +0200, Petr Viktorin wrote: > On 09/07/2013 04:45 PM, Simo Sorce wrote: > > Sorry to come late to this thread. > > > > I think I like some of Petr plan, but not all of it. > > > > On Fri, 2013-09-06 at 08:46 -0400, Rob Crittenden wrote: > [...] > >>>> I'm not sure I follow, what are you trying to achieve here? The more ACIs the > >>>> slower the processing. > >>> > >>> One of the main reason for this feature is to get rid of the global allowing ACI: > > > > And this is good, one-size-fit-all, doesn't work anymore, however we > > need to try to keep the number of ACIs low anyway, this can be done my > > smartly and programmatically generate ACIs, however we need a very > > complete test suite and in order to have a complete one, we need enough > > information to know what is the intended behavior. Plus I think for > > robustness the test suite should be generated from different code, so > > that bugs in the ACI generation code does not also cause blind spots in > > the ACI testing code. > > I don't want to build a "smart" system; it should rather be simple and > straightforward. Other than that I agree, good tests are always necessary. I guess it depends on how you define 'smart', but we agree it shouldn't be smarter than it needs to be. > [...] > >> Right, I just want to know why it was proposed to add 2 ACIs for every > >> container. > > > > I am puzzled as well. > > Consider that point dropped; I trusted the bug description without checking. > > > >>>>> How to handle passwords and other non-public attributes? I'm thinking > >>>>> about keeping a global list [...] > > > > No I will veto anything that overhauls ACIs and keeps negative filtering > > lists. > > Any big change to the ACIs system *MUST* get rid of ( targetattr != > > list ). > > > > We already risked many times of exposing data and a few years ago had to > > issue a CVE because of this. We do not want to keep doing it. Especially > > if you are building this system to allow plugins to change permissions > > you do not want to rely on the authors to remember to add negative > > entries. > > +1, a negative list doesn't make sense any more. > > > >>>> It could get ugly real fast, and potentially cause a lot of extra processing. I > >>>> think the object(s) for each attribute should be considered so these wouldn't > >>>> have to be applied to every ACI but only those that are affected. We don't need > >>>> to worry about userPassword in groups, for example. > >>> > >>> I think that a decision that a param should not be included in default read > >>> rule should be included in the param object itself, see below. > > > > I really do not want to see the ACI templates/definition/call it how you > > want int the framework, because the framework will need to change with > > versions of IPA but the data may remain in LDAP for long. therefore any > > ACI template should be stored in LDAP, probably under cn=etc,$suffix. > > > > It may make sense to have cn=aci-templates,cn=etc,$suffix, and then > > within that container (accessible only by security admins) we have one > > template per object/container, that is used to generate ACIs. > > > > Something like: > > > > dn: cn=users,cn=aci-templates,cn=etc,$suffix > > objectclass: ipaAciTemplate > > anonReadAttributes: > > authReadAttributes: > > selfReadAttributes: > > selfWriteAttributes: > > > > and so on. > > These are the defaults, only attributes that must be disclosed are > > listed, *no* negative lists, the default is changed globaly to deny all, > > and if there is no allow ACI an attribute is inaccessible by default. > > > > This allows easy customization, if someone decides 'description' should > > be kept confidential, all he needs to do is to remove it from the right > > list (and perhaps add it to a privileged list), and just run a tool that > > regenerates and changes the default ACIs for the container. > > * No need to modify framework code anywhere. * > > +1 to storing the attribute lists in LDAP. I don't like the Template > idea though. The template is just an example, we can negotiate on it :) > First, on IPA upgrades, we need to be able to add attributes to the > ACIs. Automatically. > We cannot make the IPA-generated lists user-modifiable. If some past > upgrade added a readable 'description' attribute, but the admin decides > that it should not be readable, the next upgrade should not re-add it. > So we need to store the IPA defaults and user changes separately. We solved this problem in the past for LDAP updates, I agree it is a problem we need to address, and I agree the way we have done in the past with .update files may not be up to task for the ACI system, so let's talk. > Second, we already have a place where users can customize ACIs: the > permissions. I don't see the point of another layer. Well, you want a 'blueprint' for the permissions, where you set the system defaults, I called it template. > The only thing we're adding here over regular permissions is the > aforementioned ability to auto-add new attributes on upgrades. > We just need a special "managed" permission for each object's "anon > read", "auth read", "self read", "self write", etc. > > > I propose a new Permission type with three lists: > attributes added by IPA, ^^^ this is equivalent to what I called 'template', only you make it read-only for admins > attributes added by the admin, and attributes removed by the admin. ^^^ and this sounds like a read-write, second order version of a template. I am not entirely sure I like the complexity of layered templates, but I do understand the proposal, and will think a little bit more about it, I am not opposed in principle to your scheme. > On IPA updates, new items can be added to the first list, and the ACI > gets regenerated from all three. This ensures that an admin's changes > get preserved across updates. How do you handle a case where we add 'read-only by admin' for an attribute that was not in the default ACI list at all previously, but the admin already added 'read by everyone' in the custom ACI ? This is the kind of thing that makes me dislike the 2 separate sets, now you need intra-set conflict resolution. > If we mark a Permission as SYSTEM, old IPA versions won't try to locate > or touch its ACI, but they'll still be able to add it to privileges and > roles using the existing API/CLI/UI. I do not understand the nuances of this SYSTEM permission, can you explain why we want it, and why it should't "locate or touch its ACI" whatever it really means ? > So we'd have something like: > > cn=Read Users,cn=permissions,cn=pbac,$SUFFIX > objectclass: ipaPermission > objectclass: ipaManagedPermission > ipaDefaultAttributes: > ipaAdminAddedAttributes: > ipaAdminExcludedAttributes: > ipaPermissionType: SYSTEM > > Admins that don't want IPA updates messing with their ACIs can just > remove the permission from privileges and add custom plain permissions > instead. > (Or possibly even convert the default permission to non-managed, or > delete it -- if we write UI to do+undo these actions.) Sounds a bit fragile, I think you never want to remove system defaults, because you will always want to be able to go back to a known state if you mess up. Maybe we can mark something as DISABLED and preserve things. > >>>>> # Combining read rights > >>>>> > >>>>> I think (read, search, compare) should be exposed in permission objects > >>>>> as a single right. Or is there a reason to keep it split? > >>>> > >>>> Yes, they are separate for a reason. Using only search and compare isn't > >>>> common, but it isn't unheard of either. For example, to be able to detect the > >>>> presence of an attribute you can provide just the search permission. > >>> > >>> Wouldn't most users use the (read, search, compare) triple? It would lower our > >>> number of ACIs significantly if we do not have 3 permissions per each object. > >> > >> There is nothing to prevent an ACI from containing multiple permissions. > >> I wasn't proposing that. But rolling these three logically into the same > >> thing in IPA I think is short-sighted. > > > > I think it would make sense for an optimizer ACI generator to come later > > at a second stage, where we go through the generated list and combine > > ACIs together. > > > > Ie the first version could generate three distinct ACIs for read, search > > and compare, and later on we add an optimizer that consolidates them > > into a single ACI. > > For the default permissions I'd rather generate ACIs with all three. > Admins (or IPA if needed) can add an additional permission if some > attribute only needs search. I do not have a strong opinion here (yet). Simo. -- Simo Sorce * Red Hat, Inc * New York From nalin at redhat.com Mon Sep 9 14:02:21 2013 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 9 Sep 2013 10:02:21 -0400 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <522D920E.4040703@redhat.com> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> Message-ID: <20130909140221.GA2855@redhat.com> On Mon, Sep 09, 2013 at 11:17:02AM +0200, Jan Cholasta wrote: > Should each IPA service (LDAP, HTTP, PKINIT) have its own > distinctive set of trusted CAs, or is using one set for everything > good enough? Using distinctive sets would allow granular control > over what CA is trusted for what service (e.g. trust CA1 to issue > certificates for LDAP and HTTP, but trust CA2 only to issue > certificates for HTTP), but I'm not sure how useful that would be in > the real world. I'd expect it to depend heavily on whether or not you're chaining up to an external CA. Personally, I'd very much want to keep a different set of trust anchors for PKINIT in that situation. HTH, Nalin From jdennis at redhat.com Mon Sep 9 14:02:50 2013 From: jdennis at redhat.com (John Dennis) Date: Mon, 09 Sep 2013 10:02:50 -0400 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <522D920E.4040703@redhat.com> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> Message-ID: <522DD50A.9090606@redhat.com> On 09/09/2013 05:17 AM, Jan Cholasta wrote: > Another question: > > Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive > set of trusted CAs, or is using one set for everything good enough? > Using distinctive sets would allow granular control over what CA is > trusted for what service (e.g. trust CA1 to issue certificates for LDAP > and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm > not sure how useful that would be in the real world. That would complicate things quickly. Managing CA certs is already challenging enough. Exploding this via combinations does not seem to present enough real value for the complexity. In the real world most deployments boil down to a single CA and that trust model been effective. Don't forget you can always revoke any cert issued by a CA. Having granular control over individual CA's does not seem to present value, just complications. If your CA is compromised you've got big things to worry about, having it be 1 in N does not seem to change that equation radically. If one CA got compromised you've got a lot of work to do to replace the trusted CA list everywhere. If one is compromised why aren't the other CA's? Having to update just one CA trust rather than potentially N is better. -- John From jdennis at redhat.com Mon Sep 9 14:05:59 2013 From: jdennis at redhat.com (John Dennis) Date: Mon, 09 Sep 2013 10:05:59 -0400 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <20130909140221.GA2855@redhat.com> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <20130909140221.GA2855@redhat.com> Message-ID: <522DD5C7.6000809@redhat.com> On 09/09/2013 10:02 AM, Nalin Dahyabhai wrote: > On Mon, Sep 09, 2013 at 11:17:02AM +0200, Jan Cholasta wrote: >> Should each IPA service (LDAP, HTTP, PKINIT) have its own >> distinctive set of trusted CAs, or is using one set for everything >> good enough? Using distinctive sets would allow granular control >> over what CA is trusted for what service (e.g. trust CA1 to issue >> certificates for LDAP and HTTP, but trust CA2 only to issue >> certificates for HTTP), but I'm not sure how useful that would be in >> the real world. > > I'd expect it to depend heavily on whether or not you're chaining up to > an external CA. Personally, I'd very much want to keep a different set > of trust anchors for PKINIT in that situation. If you've got an external CA you still effectively have one trust anchor that can be revoked because we create a sub-CA from the external CA. Or perhaps I misunderstood what you were suggesting. -- John From jcholast at redhat.com Mon Sep 9 14:19:42 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 09 Sep 2013 16:19:42 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <1378733814.2804.1425.camel@willson.li.ssimo.org> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <1378733814.2804.1425.camel@willson.li.ssimo.org> Message-ID: <522DD8FE.7030300@redhat.com> On 9.9.2013 15:36, Simo Sorce wrote: > On Mon, 2013-09-09 at 11:17 +0200, Jan Cholasta wrote: >> Another question: >> >> Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive >> set of trusted CAs, or is using one set for everything good enough? >> Using distinctive sets would allow granular control over what CA is >> trusted for what service (e.g. trust CA1 to issue certificates for LDAP >> and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm >> not sure how useful that would be in the real world. > > Seem very complicated. Well, code-wise it isn't very complicated, actually it's what I have now. I'm just pondering whether to put it in the final design or not. > > At most I would see as sort of useful to be able to set a different CA > just for HTTP (due to default browsers list of CA), but not for anything > else. But for this case I would rather write instructions on how to > create a frontend on a *different* server, that just proxies in all > requests to FreeIPA, just for people that want to use browsers w/o > distributing the FreeIPA CA cert. That will solve their problem w/o > complicating ours. It seems we are talking about slightly different perspectives on the issue. Consider the following situation: User wants to install new HTTP certificate using ipa-server-certinstall. Currently, the certificate must be signed by the CA that was used for IPA install (be it IPA CA or CA-less). In it was requested that the CA cert of the HTTP cert should be uploaded to LDAP (and as a result, distributed to clients). Should this be allowed? If it should, should the newly uploaded CA cert be trusted to issue only HTTP certs, or any (HTTP/LDAP/PKINIT) certs? > > We could also explain how to configure SNI (easier than proxy, but > depends on whether mod_nss supports it, mod_ssl does), so that people > can use a public cert with a 'public' name and keep FreeIPA own certs > for internal management and joins etc... > > Simo. > -- Jan Cholasta From jcholast at redhat.com Mon Sep 9 14:21:39 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 09 Sep 2013 16:21:39 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <522DD5C7.6000809@redhat.com> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <20130909140221.GA2855@redhat.com> <522DD5C7.6000809@redhat.com> Message-ID: <522DD973.6040703@redhat.com> On 9.9.2013 16:05, John Dennis wrote: > On 09/09/2013 10:02 AM, Nalin Dahyabhai wrote: >> On Mon, Sep 09, 2013 at 11:17:02AM +0200, Jan Cholasta wrote: >>> Should each IPA service (LDAP, HTTP, PKINIT) have its own >>> distinctive set of trusted CAs, or is using one set for everything >>> good enough? Using distinctive sets would allow granular control >>> over what CA is trusted for what service (e.g. trust CA1 to issue >>> certificates for LDAP and HTTP, but trust CA2 only to issue >>> certificates for HTTP), but I'm not sure how useful that would be in >>> the real world. >> >> I'd expect it to depend heavily on whether or not you're chaining up to >> an external CA. Personally, I'd very much want to keep a different set >> of trust anchors for PKINIT in that situation. > > If you've got an external CA you still effectively have one trust anchor > that can be revoked because we create a sub-CA from the external CA. Or > perhaps I misunderstood what you were suggesting. > Don't forget about CA-less, you can theoretically have more than one trust anchor in that case. -- Jan Cholasta From nalin at redhat.com Mon Sep 9 14:24:04 2013 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 9 Sep 2013 10:24:04 -0400 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <522DD5C7.6000809@redhat.com> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <20130909140221.GA2855@redhat.com> <522DD5C7.6000809@redhat.com> Message-ID: <20130909142404.GB2855@redhat.com> On Mon, Sep 09, 2013 at 10:05:59AM -0400, John Dennis wrote: > On 09/09/2013 10:02 AM, Nalin Dahyabhai wrote: > > I'd expect it to depend heavily on whether or not you're chaining up to > > an external CA. Personally, I'd very much want to keep a different set > > of trust anchors for PKINIT in that situation. > > If you've got an external CA you still effectively have one trust anchor > that can be revoked because we create a sub-CA from the external CA. Or > perhaps I misunderstood what you were suggesting. My main concern is that the external CA, having issued one sub CA to us, can do so again for another customer, and trusting certificates because they chain up to that CA also allows that CA's other clients to issue certificates that we'd then also automatically trust. We can't revoke such certificates (which is done by noting the combination of issuer and serial number) until we know about them, and we'll only know about one of them after someone's used it to attempt to authenticate, possibly successfully. Cheers, Nalin From jdennis at redhat.com Mon Sep 9 14:32:08 2013 From: jdennis at redhat.com (John Dennis) Date: Mon, 09 Sep 2013 10:32:08 -0400 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <20130909142404.GB2855@redhat.com> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <20130909140221.GA2855@redhat.com> <522DD5C7.6000809@redhat.com> <20130909142404.GB2855@redhat.com> Message-ID: <522DDBE8.90209@redhat.com> On 09/09/2013 10:24 AM, Nalin Dahyabhai wrote: > On Mon, Sep 09, 2013 at 10:05:59AM -0400, John Dennis wrote: >> On 09/09/2013 10:02 AM, Nalin Dahyabhai wrote: >>> I'd expect it to depend heavily on whether or not you're chaining up to >>> an external CA. Personally, I'd very much want to keep a different set >>> of trust anchors for PKINIT in that situation. >> >> If you've got an external CA you still effectively have one trust anchor >> that can be revoked because we create a sub-CA from the external CA. Or >> perhaps I misunderstood what you were suggesting. > > My main concern is that the external CA, having issued one sub CA to us, > can do so again for another customer, and trusting certificates because > they chain up to that CA also allows that CA's other clients to issue > certificates that we'd then also automatically trust. > > We can't revoke such certificates (which is done by noting the > combination of issuer and serial number) until we know about them, and > we'll only know about one of them after someone's used it to attempt to > authenticate, possibly successfully. Good point. Isn't there an X509 extension (possibly part of PKIX?) which restricts membership in the chain path to a criteria. In other words you can require your sub-CA to be present in the chain. Sorry, but my memory is a bit fuzzy on this. -- John From jcholast at redhat.com Mon Sep 9 14:39:16 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 09 Sep 2013 16:39:16 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <522DD50A.9090606@redhat.com> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <522DD50A.9090606@redhat.com> Message-ID: <522DDD94.1050000@redhat.com> On 9.9.2013 16:02, John Dennis wrote: > On 09/09/2013 05:17 AM, Jan Cholasta wrote: >> Another question: >> >> Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive >> set of trusted CAs, or is using one set for everything good enough? >> Using distinctive sets would allow granular control over what CA is >> trusted for what service (e.g. trust CA1 to issue certificates for LDAP >> and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm >> not sure how useful that would be in the real world. > > That would complicate things quickly. Managing CA certs is already > challenging enough. Exploding this via combinations does not seem to > present enough real value for the complexity. > > In the real world most deployments boil down to a single CA and that > trust model been effective. Don't forget you can always revoke any cert > issued by a CA. Having granular control over individual CA's does not > seem to present value, just complications. If your CA is compromised > you've got big things to worry about, having it be 1 in N does not seem > to change that equation radically. If one CA got compromised you've got > a lot of work to do to replace the trusted CA list everywhere. If one is > compromised why aren't the other CA's? Having to update just one CA > trust rather than potentially N is better. I'm not suggesting *controlling* multiple CAs, but being able to manage what individual external CAs are trusted to do. This is probably only relevant to CA-less install. When IPA internal CA is installed, there is just that one CA, which is trusted for everything. -- Jan Cholasta From rcritten at redhat.com Mon Sep 9 14:40:35 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Sep 2013 10:40:35 -0400 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <522DDD94.1050000@redhat.com> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <522DD50A.9090606@redhat.com> <522DDD94.1050000@redhat.com> Message-ID: <522DDDE3.3030308@redhat.com> Jan Cholasta wrote: > On 9.9.2013 16:02, John Dennis wrote: >> On 09/09/2013 05:17 AM, Jan Cholasta wrote: >>> Another question: >>> >>> Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive >>> set of trusted CAs, or is using one set for everything good enough? >>> Using distinctive sets would allow granular control over what CA is >>> trusted for what service (e.g. trust CA1 to issue certificates for LDAP >>> and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm >>> not sure how useful that would be in the real world. >> >> That would complicate things quickly. Managing CA certs is already >> challenging enough. Exploding this via combinations does not seem to >> present enough real value for the complexity. >> >> In the real world most deployments boil down to a single CA and that >> trust model been effective. Don't forget you can always revoke any cert >> issued by a CA. Having granular control over individual CA's does not >> seem to present value, just complications. If your CA is compromised >> you've got big things to worry about, having it be 1 in N does not seem >> to change that equation radically. If one CA got compromised you've got >> a lot of work to do to replace the trusted CA list everywhere. If one is >> compromised why aren't the other CA's? Having to update just one CA >> trust rather than potentially N is better. > > I'm not suggesting *controlling* multiple CAs, but being able to manage > what individual external CAs are trusted to do. This is probably only > relevant to CA-less install. When IPA internal CA is installed, there is > just that one CA, which is trusted for everything. > We've fielded questions from people wanting to replace the cert in the web server even while maintaining the IPA CA. Granted this was prior to the CA-less option. The impetus seems to be not requiring all users to trust the IPA CA. I think if that became easier then wanting to use another CA would be less of an issue. rob From pviktori at redhat.com Mon Sep 9 14:40:49 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Sep 2013 16:40:49 +0200 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <1378734388.2804.1435.camel@willson.li.ssimo.org> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> <5229839E.9070105@redhat.com> <5229CEBD.7070705@redhat.com> <1378565107.2804.1122.camel@willson.li.ssimo.org> <522DAA31.20900@redhat.com> <1378734388.2804.1435.camel@willson.li.ssimo.org> Message-ID: <522DDDF1.5000208@redhat.com> On 09/09/2013 03:46 PM, Simo Sorce wrote: > On Mon, 2013-09-09 at 13:00 +0200, Petr Viktorin wrote: >> On 09/07/2013 04:45 PM, Simo Sorce wrote: >>> Sorry to come late to this thread. >>> >>> I think I like some of Petr plan, but not all of it. >>> [...] >>>>>> It could get ugly real fast, and potentially cause a lot of extra processing. I >>>>>> think the object(s) for each attribute should be considered so these wouldn't >>>>>> have to be applied to every ACI but only those that are affected. We don't need >>>>>> to worry about userPassword in groups, for example. >>>>> >>>>> I think that a decision that a param should not be included in default read >>>>> rule should be included in the param object itself, see below. >>> >>> I really do not want to see the ACI templates/definition/call it how you >>> want int the framework, because the framework will need to change with >>> versions of IPA but the data may remain in LDAP for long. therefore any >>> ACI template should be stored in LDAP, probably under cn=etc,$suffix. >>> >>> It may make sense to have cn=aci-templates,cn=etc,$suffix, and then >>> within that container (accessible only by security admins) we have one >>> template per object/container, that is used to generate ACIs. >>> >>> Something like: >>> >>> dn: cn=users,cn=aci-templates,cn=etc,$suffix >>> objectclass: ipaAciTemplate >>> anonReadAttributes: >>> authReadAttributes: >>> selfReadAttributes: >>> selfWriteAttributes: >>> >>> and so on. >>> These are the defaults, only attributes that must be disclosed are >>> listed, *no* negative lists, the default is changed globaly to deny all, >>> and if there is no allow ACI an attribute is inaccessible by default. >>> >>> This allows easy customization, if someone decides 'description' should >>> be kept confidential, all he needs to do is to remove it from the right >>> list (and perhaps add it to a privileged list), and just run a tool that >>> regenerates and changes the default ACIs for the container. >>> * No need to modify framework code anywhere. * >> >> +1 to storing the attribute lists in LDAP. I don't like the Template >> idea though. > > The template is just an example, we can negotiate on it :) > >> First, on IPA upgrades, we need to be able to add attributes to the >> ACIs. Automatically. >> We cannot make the IPA-generated lists user-modifiable. If some past >> upgrade added a readable 'description' attribute, but the admin decides >> that it should not be readable, the next upgrade should not re-add it. >> So we need to store the IPA defaults and user changes separately. > > We solved this problem in the past for LDAP updates, I agree it is a > problem we need to address, and I agree the way we have done in the past > with .update files may not be up to task for the ACI system, so let's > talk. How have we solved it? AFAIK, currently if the LDAP updater sees a state that used to be default in an old IPA version but changed, it will overwrite it with the new state. So if the current IPA version adds an attribute that you don't want, you're out of luck: removing it reverts to the old state, which will get updated next time you upgrade. Also, if you *add* an attribute, the resulting ACI no longer matches the default so the LDAP updater won't ever touch it again. >> Second, we already have a place where users can customize ACIs: the >> permissions. I don't see the point of another layer. > > Well, you want a 'blueprint' for the permissions, where you set the > system defaults, I called it template. > >> The only thing we're adding here over regular permissions is the >> aforementioned ability to auto-add new attributes on upgrades. >> We just need a special "managed" permission for each object's "anon >> read", "auth read", "self read", "self write", etc. >> >> >> I propose a new Permission type with three lists: > >> attributes added by IPA, > ^^^ this is equivalent to what I called 'template', only you make it > read-only for admins > >> attributes added by the admin, and attributes removed by the admin. > ^^^ and this sounds like a read-write, second order version of a > template. > > I am not entirely sure I like the complexity of layered templates, but I > do understand the proposal, and will think a little bit more about it, I > am not opposed in principle to your scheme. > >> On IPA updates, new items can be added to the first list, and the ACI >> gets regenerated from all three. This ensures that an admin's changes >> get preserved across updates. > > How do you handle a case where we add 'read-only by admin' for an > attribute that was not in the default ACI list at all previously, but > the admin already added 'read by everyone' in the custom ACI ? > This is the kind of thing that makes me dislike the 2 separate sets, now > you need intra-set conflict resolution. There would be two permissions: "read by admin" and "read by everyone". Both would now allow reading the attribute, so it would be readable by anyone -- as the admin wanted. I don't see any need for intra-set conflict resolution. The algorithm is simple -- take IPA defaults, add admin-added attributes, filter out admin-excluded attributes, allow the resulting set. Recompute whenever any of the lists changes. >> If we mark a Permission as SYSTEM, old IPA versions won't try to locate >> or touch its ACI, but they'll still be able to add it to privileges and >> roles using the existing API/CLI/UI. > > I do not understand the nuances of this SYSTEM permission, can you > explain why we want it, and why it should't "locate or touch its ACI" > whatever it really means ? Permissions are IPA objects that encapsulate the underlying ACIs and make them easier to manage. Permissions are less flexible than raw ACIs. Sometimes they need more power than what the Permission UI exposes, so we mark them as SYSTEM. The CLI/UI then doesn't read or update the underlying ACI. If we add permissions that work differently than the existing ones, we can mark them SYSTEM so *old IPA* doesn't try to manipulate the underlying ACIs. (And we need to add some kind of permision versioning, in case the functionality changes again.) >> So we'd have something like: >> >> cn=Read Users,cn=permissions,cn=pbac,$SUFFIX >> objectclass: ipaPermission >> objectclass: ipaManagedPermission >> ipaDefaultAttributes: >> ipaAdminAddedAttributes: >> ipaAdminExcludedAttributes: >> ipaPermissionType: SYSTEM >> >> Admins that don't want IPA updates messing with their ACIs can just >> remove the permission from privileges and add custom plain permissions >> instead. >> (Or possibly even convert the default permission to non-managed, or >> delete it -- if we write UI to do+undo these actions.) > > Sounds a bit fragile, I think you never want to remove system defaults, > because you will always want to be able to go back to a known state if > you mess up. Maybe we can mark something as DISABLED and preserve > things. Removing the permission from the privilege is like disabling, you can always add it back. We just need to make sure IPA doesn't overwrite the admin's choice on updates. -- Petr? From rcritten at redhat.com Mon Sep 9 14:44:14 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 Sep 2013 10:44:14 -0400 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <522DDDF1.5000208@redhat.com> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> <5229839E.9070105@redhat.com> <5229CEBD.7070705@redhat.com> <1378565107.2804.1122.camel@willson.li.ssimo.org> <522DAA31.20900@redhat.com> <1378734388.2804.1435.camel@willson.li.ssimo.org> <522DDDF1.5000208@redhat.com> Message-ID: <522DDEBE.3040502@redhat.com> Petr Viktorin wrote: > On 09/09/2013 03:46 PM, Simo Sorce wrote: >> On Mon, 2013-09-09 at 13:00 +0200, Petr Viktorin wrote: >>> On 09/07/2013 04:45 PM, Simo Sorce wrote: >>>> Sorry to come late to this thread. >>>> >>>> I think I like some of Petr plan, but not all of it. >>>> > [...] >>>>>>> It could get ugly real fast, and potentially cause a lot of extra >>>>>>> processing. I >>>>>>> think the object(s) for each attribute should be considered so >>>>>>> these wouldn't >>>>>>> have to be applied to every ACI but only those that are affected. >>>>>>> We don't need >>>>>>> to worry about userPassword in groups, for example. >>>>>> >>>>>> I think that a decision that a param should not be included in >>>>>> default read >>>>>> rule should be included in the param object itself, see below. >>>> >>>> I really do not want to see the ACI templates/definition/call it how >>>> you >>>> want int the framework, because the framework will need to change with >>>> versions of IPA but the data may remain in LDAP for long. therefore any >>>> ACI template should be stored in LDAP, probably under cn=etc,$suffix. >>>> >>>> It may make sense to have cn=aci-templates,cn=etc,$suffix, and then >>>> within that container (accessible only by security admins) we have one >>>> template per object/container, that is used to generate ACIs. >>>> >>>> Something like: >>>> >>>> dn: cn=users,cn=aci-templates,cn=etc,$suffix >>>> objectclass: ipaAciTemplate >>>> anonReadAttributes: >>>> authReadAttributes: >>>> selfReadAttributes: >>>> selfWriteAttributes: >>>> >>>> and so on. >>>> These are the defaults, only attributes that must be disclosed are >>>> listed, *no* negative lists, the default is changed globaly to deny >>>> all, >>>> and if there is no allow ACI an attribute is inaccessible by default. >>>> >>>> This allows easy customization, if someone decides 'description' should >>>> be kept confidential, all he needs to do is to remove it from the right >>>> list (and perhaps add it to a privileged list), and just run a tool >>>> that >>>> regenerates and changes the default ACIs for the container. >>>> * No need to modify framework code anywhere. * >>> >>> +1 to storing the attribute lists in LDAP. I don't like the Template >>> idea though. >> >> The template is just an example, we can negotiate on it :) >> >>> First, on IPA upgrades, we need to be able to add attributes to the >>> ACIs. Automatically. >>> We cannot make the IPA-generated lists user-modifiable. If some past >>> upgrade added a readable 'description' attribute, but the admin decides >>> that it should not be readable, the next upgrade should not re-add it. >>> So we need to store the IPA defaults and user changes separately. >> >> We solved this problem in the past for LDAP updates, I agree it is a >> problem we need to address, and I agree the way we have done in the past >> with .update files may not be up to task for the ACI system, so let's >> talk. > > How have we solved it? AFAIK, currently if the LDAP updater sees a state > that used to be default in an old IPA version but changed, it will > overwrite it with the new state. > > So if the current IPA version adds an attribute that you don't want, > you're out of luck: removing it reverts to the old state, which will get > updated next time you upgrade. > > Also, if you *add* an attribute, the resulting ACI no longer matches the > default so the LDAP updater won't ever touch it again. There needs to be some mechanism for us for force-replace existing ACIs in the case of a security issue. > >>> Second, we already have a place where users can customize ACIs: the >>> permissions. I don't see the point of another layer. >> >> Well, you want a 'blueprint' for the permissions, where you set the >> system defaults, I called it template. >> >>> The only thing we're adding here over regular permissions is the >>> aforementioned ability to auto-add new attributes on upgrades. >>> We just need a special "managed" permission for each object's "anon >>> read", "auth read", "self read", "self write", etc. >>> >>> >>> I propose a new Permission type with three lists: >> >>> attributes added by IPA, >> ^^^ this is equivalent to what I called 'template', only you make it >> read-only for admins >> >>> attributes added by the admin, and attributes removed by the admin. >> ^^^ and this sounds like a read-write, second order version of a >> template. >> >> I am not entirely sure I like the complexity of layered templates, but I >> do understand the proposal, and will think a little bit more about it, I >> am not opposed in principle to your scheme. >> >>> On IPA updates, new items can be added to the first list, and the ACI >>> gets regenerated from all three. This ensures that an admin's changes >>> get preserved across updates. >> >> How do you handle a case where we add 'read-only by admin' for an >> attribute that was not in the default ACI list at all previously, but >> the admin already added 'read by everyone' in the custom ACI ? >> This is the kind of thing that makes me dislike the 2 separate sets, now >> you need intra-set conflict resolution. > > There would be two permissions: "read by admin" and "read by everyone". > Both would now allow reading the attribute, so it would be readable by > anyone -- as the admin wanted. > > I don't see any need for intra-set conflict resolution. The algorithm is > simple -- take IPA defaults, add admin-added attributes, filter out > admin-excluded attributes, allow the resulting set. Recompute whenever > any of the lists changes. > >>> If we mark a Permission as SYSTEM, old IPA versions won't try to locate >>> or touch its ACI, but they'll still be able to add it to privileges and >>> roles using the existing API/CLI/UI. >> >> I do not understand the nuances of this SYSTEM permission, can you >> explain why we want it, and why it should't "locate or touch its ACI" >> whatever it really means ? > > Permissions are IPA objects that encapsulate the underlying ACIs and > make them easier to manage. Permissions are less flexible than raw ACIs. > Sometimes they need more power than what the Permission UI exposes, so > we mark them as SYSTEM. The CLI/UI then doesn't read or update the > underlying ACI. > If we add permissions that work differently than the existing ones, we > can mark them SYSTEM so *old IPA* doesn't try to manipulate the > underlying ACIs. > (And we need to add some kind of permision versioning, in case the > functionality changes again.) > >>> So we'd have something like: >>> >>> cn=Read Users,cn=permissions,cn=pbac,$SUFFIX >>> objectclass: ipaPermission >>> objectclass: ipaManagedPermission >>> ipaDefaultAttributes: >>> ipaAdminAddedAttributes: >>> ipaAdminExcludedAttributes: >>> ipaPermissionType: SYSTEM >>> >>> Admins that don't want IPA updates messing with their ACIs can just >>> remove the permission from privileges and add custom plain permissions >>> instead. >>> (Or possibly even convert the default permission to non-managed, or >>> delete it -- if we write UI to do+undo these actions.) >> >> Sounds a bit fragile, I think you never want to remove system defaults, >> because you will always want to be able to go back to a known state if >> you mess up. Maybe we can mark something as DISABLED and preserve >> things. > > Removing the permission from the privilege is like disabling, you can > always add it back. > We just need to make sure IPA doesn't overwrite the admin's choice on > updates. > > From pviktori at redhat.com Mon Sep 9 14:51:08 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Sep 2013 16:51:08 +0200 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <522DDEBE.3040502@redhat.com> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> <5229839E.9070105@redhat.com> <5229CEBD.7070705@redhat.com> <1378565107.2804.1122.camel@willson.li.ssimo.org> <522DAA31.20900@redhat.com> <1378734388.2804.1435.camel@willson.li.ssimo.org> <522DDDF1.5000208@redhat.com> <522DDEBE.3040502@redhat.com> Message-ID: <522DE05C.903@redhat.com> On 09/09/2013 04:44 PM, Rob Crittenden wrote: > Petr Viktorin wrote: [...] > > There needs to be some mechanism for us for force-replace existing ACIs > in the case of a security issue. Under my proposal, we can just remove the offending attribute from the default list, and trust that the admin didn't for some reason explicitly add it. (This would differ from a normal update in that it would actively remove the attribute instead of ignoring pre-existing entries.) If that's not enough, then this affects *all* ACI, not just ones added by IPA by default. We'd need to have an update plugin that crawls through all existing permissions (or even all ACIs) and fixes them. -- Petr? From gh.mdgh at gmail.com Mon Sep 9 14:55:51 2013 From: gh.mdgh at gmail.com (Mahmoud) Date: Mon, 9 Sep 2013 19:25:51 +0430 Subject: [Freeipa-devel] ipadb.so In-Reply-To: <1378733458.2804.1419.camel@willson.li.ssimo.org> References: <1378654817.2804.1370.camel@willson.li.ssimo.org> <522CC1CA.5080502@redhat.com> <6F7CE3CF-EBFC-4EDA-A823-EF8350AF1F1B@padl.com> <1378733458.2804.1419.camel@willson.li.ssimo.org> Message-ID: Hello, Thank you very much for your time and attention. I changed client side code (kinit.c) but it requires to change all clients. Now, I decided to change server side code. I thought it may be better choice. Should I change policy.c file to change ticket policies? It does not require recompiling krb5kdc? I install FreeIPA on Fedora 18, When I execute klist -V command, hence get following result: Kerberos 5 version 1.10.3 Best regards. On Mon, Sep 9, 2013 at 6:00 PM, Simo Sorce wrote: > On Mon, 2013-09-09 at 08:07 +0430, Mahmoud wrote: > > Hello Simo > > > > > > The previous problem occurred due to installing krb5-1.11.3. I install > > krb5-1.10.6 and copy ipadb.so in appropriate directory, hence the > > problem has been solved. Is it all right? > > > No it is not, we require 1.11.3 for OTP support in the latest FreeIPA. > > Seriously, chaingin the KDC is the last thing you want to do to solve > your problem. > > Have you looked into creating custom ticket policies for your users ? > > Why do you need to change the KDC to do that ? > > Simo. > > > > Thank you. > > > > Best regards. > > > > > > > > On Mon, Sep 9, 2013 at 7:47 AM, Luke Howard wrote: > > > > On 09/09/2013, at 1:08 PM, Mahmoud wrote: > > > > > I thought FreeIpa uses krb5-1.10.3, but I use klist -V get > > following result: > > > Kerberos 5 version 1.10.3 > > > > > > Aren't these the same thing? > > > > -- Luke > > > > > > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon Sep 9 15:02:58 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 09 Sep 2013 17:02:58 +0200 Subject: [Freeipa-devel] [PATCH] 168 Fix nsslapdPlugin object class after initial replication Message-ID: <522DE322.3000101@redhat.com> Hi, the attached patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-168.1-Fix-nsslapdPlugin-object-class-after-initial-replica.patch Type: text/x-patch Size: 4163 bytes Desc: not available URL: From pviktori at redhat.com Mon Sep 9 15:26:00 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 09 Sep 2013 17:26:00 +0200 Subject: [Freeipa-devel] [PATCH] 0066 Do not crash if DS is down during server uninstall In-Reply-To: <5229D16B.8070405@redhat.com> References: <5229D16B.8070405@redhat.com> Message-ID: <522DE888.2010900@redhat.com> On 09/06/2013 02:58 PM, Ana Krivokapic wrote: > Hello, > > This patch fixes the regression introduced by the original fix for ticket #3867. > > https://fedorahosted.org/freeipa/ticket/3867 Thank, ACK, pushed to: master: a70b08e9aea891555ebee512de196748a835acb8 ipa-3-3: 658e734d2c453381a04e9ed72ea6ee9d50cea097 Tiny nitpicks below. > + msg = ("\nWARNING: Failed to connect to Directory Server to find " > + "information about replication agreements. Uninstallation " > + "will continue dispite the possible existing replication " ^^^^^^ Typo, fixed before pushing > + "agreements.\n\n") [...] > + if not (options.unattended or user_input("Are you sure you " > + "want to continue " > + "with the uninstall " > + "procedure?", > + False)): This looks funny :) On a more rational note, unnecessarily breaking up strings makes them harder to grep. In the future you can use the `msg` trick you used for the WARNING above. -- Petr? From dpal at redhat.com Mon Sep 9 15:43:35 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 09 Sep 2013 11:43:35 -0400 Subject: [Freeipa-devel] ipadb.so In-Reply-To: References: <1378654817.2804.1370.camel@willson.li.ssimo.org> <522CC1CA.5080502@redhat.com> <6F7CE3CF-EBFC-4EDA-A823-EF8350AF1F1B@padl.com> <1378733458.2804.1419.camel@willson.li.ssimo.org> Message-ID: <522DECA7.1070200@redhat.com> On 09/09/2013 10:55 AM, Mahmoud wrote: > Hello, > > Thank you very much for your time and attention. > > I changed client side code (kinit.c) but it requires to change all > clients. Now, I decided to change server side code. It seems that you should try to contribute code upstream if you want to end up with any kind of support of your enhancements, otherwise you would have to maintain your own version. > I thought it may be better choice. Should I change policy.c file to > change ticket policies? What policies do you want to change and why? You might have described your intent on some other thread in some other list but not here. > It does not require recompiling krb5kdc? I suspect it does... > I install FreeIPA on Fedora 18, When I execute klist -V command, hence > get following result: > Kerberos 5 version 1.10.3 > Fedora 19 has 1.11 IMO the best would be to have a details explanation of what you are trying to accomplish. This way we would be able to help you with the right approach. But it seems that building custom code might not be best option. Thanks Dmitri > Best regards. > > On Mon, Sep 9, 2013 at 6:00 PM, Simo Sorce > wrote: > > On Mon, 2013-09-09 at 08:07 +0430, Mahmoud wrote: > > Hello Simo > > > > > > The previous problem occurred due to installing krb5-1.11.3. I > install > > krb5-1.10.6 and copy ipadb.so in appropriate directory, hence the > > problem has been solved. Is it all right? > > > No it is not, we require 1.11.3 for OTP support in the latest FreeIPA. > > Seriously, chaingin the KDC is the last thing you want to do to solve > your problem. > > Have you looked into creating custom ticket policies for your users ? > > Why do you need to change the KDC to do that ? > > Simo. > > > > Thank you. > > > > Best regards. > > > > > > > > On Mon, Sep 9, 2013 at 7:47 AM, Luke Howard > wrote: > > > > On 09/09/2013, at 1:08 PM, Mahmoud > wrote: > > > > > I thought FreeIpa uses krb5-1.10.3, but I use klist -V get > > following result: > > > Kerberos 5 version 1.10.3 > > > > > > Aren't these the same thing? > > > > -- Luke > > > > > > > -- > Simo Sorce * Red Hat, Inc * New York > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- 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 9 15:54:45 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 09 Sep 2013 11:54:45 -0400 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <522DDDE3.3030308@redhat.com> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <522DD50A.9090606@redhat.com> <522DDD94.1050000@redhat.com> <522DDDE3.3030308@redhat.com> Message-ID: <1378742085.2804.1451.camel@willson.li.ssimo.org> On Mon, 2013-09-09 at 10:40 -0400, Rob Crittenden wrote: > Jan Cholasta wrote: > > On 9.9.2013 16:02, John Dennis wrote: > >> On 09/09/2013 05:17 AM, Jan Cholasta wrote: > >>> Another question: > >>> > >>> Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive > >>> set of trusted CAs, or is using one set for everything good enough? > >>> Using distinctive sets would allow granular control over what CA is > >>> trusted for what service (e.g. trust CA1 to issue certificates for LDAP > >>> and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm > >>> not sure how useful that would be in the real world. > >> > >> That would complicate things quickly. Managing CA certs is already > >> challenging enough. Exploding this via combinations does not seem to > >> present enough real value for the complexity. > >> > >> In the real world most deployments boil down to a single CA and that > >> trust model been effective. Don't forget you can always revoke any cert > >> issued by a CA. Having granular control over individual CA's does not > >> seem to present value, just complications. If your CA is compromised > >> you've got big things to worry about, having it be 1 in N does not seem > >> to change that equation radically. If one CA got compromised you've got > >> a lot of work to do to replace the trusted CA list everywhere. If one is > >> compromised why aren't the other CA's? Having to update just one CA > >> trust rather than potentially N is better. > > > > I'm not suggesting *controlling* multiple CAs, but being able to manage > > what individual external CAs are trusted to do. This is probably only > > relevant to CA-less install. When IPA internal CA is installed, there is > > just that one CA, which is trusted for everything. > > > > We've fielded questions from people wanting to replace the cert in the > web server even while maintaining the IPA CA. Granted this was prior to > the CA-less option. > The impetus seems to be not requiring all users to trust the IPA CA. I > think if that became easier then wanting to use another CA would be less > of an issue. And I really think this would be better served with an SNI setup, where we have 2 SSL certs for the web server only (a public one and an IPA one). While everything else must use the IPA CA, esp for PKINIT. Simo. -- Simo Sorce * Red Hat, Inc * New York From nalin at redhat.com Mon Sep 9 16:02:30 2013 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 9 Sep 2013 12:02:30 -0400 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <522DDBE8.90209@redhat.com> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <20130909140221.GA2855@redhat.com> <522DD5C7.6000809@redhat.com> <20130909142404.GB2855@redhat.com> <522DDBE8.90209@redhat.com> Message-ID: <20130909160229.GC2855@redhat.com> On Mon, Sep 09, 2013 at 10:32:08AM -0400, John Dennis wrote: > Good point. Isn't there an X509 extension (possibly part of PKIX?) which > restricts membership in the chain path to a criteria. In other words you > can require your sub-CA to be present in the chain. Sorry, but my memory > is a bit fuzzy on this. If you're talking about Name Constraints, they seem to be geared more toward allowing a CA to limit what a sub CA that it issues can be trusted to do, and not the other way around. I don't think I know of anything that deals with this that doesn't eventually end up setting up library-specific configuration for the library that's going to be verifying the certificate. Nalin From simo at redhat.com Mon Sep 9 16:24:36 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 09 Sep 2013 12:24:36 -0400 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <522DD8FE.7030300@redhat.com> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <1378733814.2804.1425.camel@willson.li.ssimo.org> <522DD8FE.7030300@redhat.com> Message-ID: <1378743876.2804.1458.camel@willson.li.ssimo.org> On Mon, 2013-09-09 at 16:19 +0200, Jan Cholasta wrote: > On 9.9.2013 15:36, Simo Sorce wrote: > > On Mon, 2013-09-09 at 11:17 +0200, Jan Cholasta wrote: > >> Another question: > >> > >> Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive > >> set of trusted CAs, or is using one set for everything good enough? > >> Using distinctive sets would allow granular control over what CA is > >> trusted for what service (e.g. trust CA1 to issue certificates for LDAP > >> and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm > >> not sure how useful that would be in the real world. > > > > Seem very complicated. > > Well, code-wise it isn't very complicated, actually it's what I have > now. I'm just pondering whether to put it in the final design or not. > > > > > At most I would see as sort of useful to be able to set a different CA > > just for HTTP (due to default browsers list of CA), but not for anything > > else. But for this case I would rather write instructions on how to > > create a frontend on a *different* server, that just proxies in all > > requests to FreeIPA, just for people that want to use browsers w/o > > distributing the FreeIPA CA cert. That will solve their problem w/o > > complicating ours. > > It seems we are talking about slightly different perspectives on the > issue. Consider the following situation: User wants to install new HTTP > certificate using ipa-server-certinstall. Currently, the certificate > must be signed by the CA that was used for IPA install (be it IPA CA or > CA-less). In it was > requested that the CA cert of the HTTP cert should be uploaded to LDAP > (and as a result, distributed to clients). Should this be allowed? If it > should, should the newly uploaded CA cert be trusted to issue only HTTP > certs, or any (HTTP/LDAP/PKINIT) certs? See the point below, the reason people want to use a cert is to avoid the hassle of installing a private CA on web browser for all users (that may have personal machine, tablets and whatnot. I think the solution is to change the way we tell them to do it. Instead of installing a separate set of public certs, allow SNI setup and have them create a separate name for public use. It will make for a much better/easier experience for all involved and will keep the whole solution more secure wrt Nalin concerns for example. > > > > We could also explain how to configure SNI (easier than proxy, but > > depends on whether mod_nss supports it, mod_ssl does), so that people > > can use a public cert with a 'public' name and keep FreeIPA own certs > > for internal management and joins etc... > > > > Simo. > > > > -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Sep 9 16:31:40 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 09 Sep 2013 12:31:40 -0400 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <522DDDF1.5000208@redhat.com> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> <5229839E.9070105@redhat.com> <5229CEBD.7070705@redhat.com> <1378565107.2804.1122.camel@willson.li.ssimo.org> <522DAA31.20900@redhat.com> <1378734388.2804.1435.camel@willson.li.ssimo.org> <522DDDF1.5000208@redhat.com> Message-ID: <1378744300.2804.1463.camel@willson.li.ssimo.org> On Mon, 2013-09-09 at 16:40 +0200, Petr Viktorin wrote: > On 09/09/2013 03:46 PM, Simo Sorce wrote: > > On Mon, 2013-09-09 at 13:00 +0200, Petr Viktorin wrote: > >> On 09/07/2013 04:45 PM, Simo Sorce wrote: > >>> Sorry to come late to this thread. > >>> > >>> I think I like some of Petr plan, but not all of it. > >>> > [...] > >>>>>> It could get ugly real fast, and potentially cause a lot of extra processing. I > >>>>>> think the object(s) for each attribute should be considered so these wouldn't > >>>>>> have to be applied to every ACI but only those that are affected. We don't need > >>>>>> to worry about userPassword in groups, for example. > >>>>> > >>>>> I think that a decision that a param should not be included in default read > >>>>> rule should be included in the param object itself, see below. > >>> > >>> I really do not want to see the ACI templates/definition/call it how you > >>> want int the framework, because the framework will need to change with > >>> versions of IPA but the data may remain in LDAP for long. therefore any > >>> ACI template should be stored in LDAP, probably under cn=etc,$suffix. > >>> > >>> It may make sense to have cn=aci-templates,cn=etc,$suffix, and then > >>> within that container (accessible only by security admins) we have one > >>> template per object/container, that is used to generate ACIs. > >>> > >>> Something like: > >>> > >>> dn: cn=users,cn=aci-templates,cn=etc,$suffix > >>> objectclass: ipaAciTemplate > >>> anonReadAttributes: > >>> authReadAttributes: > >>> selfReadAttributes: > >>> selfWriteAttributes: > >>> > >>> and so on. > >>> These are the defaults, only attributes that must be disclosed are > >>> listed, *no* negative lists, the default is changed globaly to deny all, > >>> and if there is no allow ACI an attribute is inaccessible by default. > >>> > >>> This allows easy customization, if someone decides 'description' should > >>> be kept confidential, all he needs to do is to remove it from the right > >>> list (and perhaps add it to a privileged list), and just run a tool that > >>> regenerates and changes the default ACIs for the container. > >>> * No need to modify framework code anywhere. * > >> > >> +1 to storing the attribute lists in LDAP. I don't like the Template > >> idea though. > > > > The template is just an example, we can negotiate on it :) > > > >> First, on IPA upgrades, we need to be able to add attributes to the > >> ACIs. Automatically. > >> We cannot make the IPA-generated lists user-modifiable. If some past > >> upgrade added a readable 'description' attribute, but the admin decides > >> that it should not be readable, the next upgrade should not re-add it. > >> So we need to store the IPA defaults and user changes separately. > > > > We solved this problem in the past for LDAP updates, I agree it is a > > problem we need to address, and I agree the way we have done in the past > > with .update files may not be up to task for the ACI system, so let's > > talk. > > How have we solved it? AFAIK, currently if the LDAP updater sees a state > that used to be default in an old IPA version but changed, it will > overwrite it with the new state. > > So if the current IPA version adds an attribute that you don't want, > you're out of luck: removing it reverts to the old state, which will get > updated next time you upgrade. > > Also, if you *add* an attribute, the resulting ACI no longer matches the > default so the LDAP updater won't ever touch it again. As I said, it may not be sufficient :) > >> Second, we already have a place where users can customize ACIs: the > >> permissions. I don't see the point of another layer. > > > > Well, you want a 'blueprint' for the permissions, where you set the > > system defaults, I called it template. > > > >> The only thing we're adding here over regular permissions is the > >> aforementioned ability to auto-add new attributes on upgrades. > >> We just need a special "managed" permission for each object's "anon > >> read", "auth read", "self read", "self write", etc. > >> > >> > >> I propose a new Permission type with three lists: > > > >> attributes added by IPA, > > ^^^ this is equivalent to what I called 'template', only you make it > > read-only for admins > > > >> attributes added by the admin, and attributes removed by the admin. > > ^^^ and this sounds like a read-write, second order version of a > > template. > > > > I am not entirely sure I like the complexity of layered templates, but I > > do understand the proposal, and will think a little bit more about it, I > > am not opposed in principle to your scheme. > > > >> On IPA updates, new items can be added to the first list, and the ACI > >> gets regenerated from all three. This ensures that an admin's changes > >> get preserved across updates. > > > > How do you handle a case where we add 'read-only by admin' for an > > attribute that was not in the default ACI list at all previously, but > > the admin already added 'read by everyone' in the custom ACI ? > > This is the kind of thing that makes me dislike the 2 separate sets, now > > you need intra-set conflict resolution. > > There would be two permissions: "read by admin" and "read by everyone". > Both would now allow reading the attribute, so it would be readable by > anyone -- as the admin wanted. > > I don't see any need for intra-set conflict resolution. The algorithm is > simple -- take IPA defaults, add admin-added attributes, filter out > admin-excluded attributes, allow the resulting set. Recompute whenever > any of the lists changes. Actually this make sense, I was mostly thinking in terms of adding deny ACIs, but the most positive outcome here will happen if we finally remove the dreadful deny ACI, so I think we are mostly ok. I can still think of a scenario that may not be optimal. Admin adds attribute for read by admin only and IPA update adds a read-by-all permission. I think this is unlikely to happen, but probably we need to add a rule that any such change on IPA part must be reviewed by at least 2 experienced members before it is approved, so that more than one head reviews and vets such a change. > >> If we mark a Permission as SYSTEM, old IPA versions won't try to locate > >> or touch its ACI, but they'll still be able to add it to privileges and > >> roles using the existing API/CLI/UI. > > > > I do not understand the nuances of this SYSTEM permission, can you > > explain why we want it, and why it should't "locate or touch its ACI" > > whatever it really means ? > > Permissions are IPA objects that encapsulate the underlying ACIs and > make them easier to manage. Permissions are less flexible than raw ACIs. > Sometimes they need more power than what the Permission UI exposes, so > we mark them as SYSTEM. The CLI/UI then doesn't read or update the > underlying ACI. > If we add permissions that work differently than the existing ones, we > can mark them SYSTEM so *old IPA* doesn't try to manipulate the > underlying ACIs. > (And we need to add some kind of permision versioning, in case the > functionality changes again.) Ok, now I get it, SYSTEM was your way to name 'low level ACIs we set directly'. > >> So we'd have something like: > >> > >> cn=Read Users,cn=permissions,cn=pbac,$SUFFIX > >> objectclass: ipaPermission > >> objectclass: ipaManagedPermission > >> ipaDefaultAttributes: > >> ipaAdminAddedAttributes: > >> ipaAdminExcludedAttributes: > >> ipaPermissionType: SYSTEM > >> > >> Admins that don't want IPA updates messing with their ACIs can just > >> remove the permission from privileges and add custom plain permissions > >> instead. > >> (Or possibly even convert the default permission to non-managed, or > >> delete it -- if we write UI to do+undo these actions.) > > > > Sounds a bit fragile, I think you never want to remove system defaults, > > because you will always want to be able to go back to a known state if > > you mess up. Maybe we can mark something as DISABLED and preserve > > things. > > Removing the permission from the privilege is like disabling, you can > always add it back. > We just need to make sure IPA doesn't overwrite the admin's choice on > updates. Right. And it will be really fun for you to find out how to upgrade from the current scheme to the final state here (which is critical, no 'start from scratch' strategies here ok ?) but I think it is quite doable. Simo. -- Simo Sorce * Red Hat, Inc * New York From gh.mdgh at gmail.com Mon Sep 9 16:49:22 2013 From: gh.mdgh at gmail.com (Mahmoud) Date: Mon, 9 Sep 2013 21:19:22 +0430 Subject: [Freeipa-devel] ipadb.so In-Reply-To: <522DECA7.1070200@redhat.com> References: <1378654817.2804.1370.camel@willson.li.ssimo.org> <522CC1CA.5080502@redhat.com> <6F7CE3CF-EBFC-4EDA-A823-EF8350AF1F1B@padl.com> <1378733458.2804.1419.camel@willson.li.ssimo.org> <522DECA7.1070200@redhat.com> Message-ID: Hello Mr. Dmitri Pal Thank you very much for your help. I tried to change source code to have more option. It was difficult for me to understand FreeIPA source code. Hence, I decided to change Kerberos source code. I want to add more features to Kerberos. For example, I like to have two (or several) types of ticket expiration. Thanks Best regards On Mon, Sep 9, 2013 at 8:13 PM, Dmitri Pal wrote: > On 09/09/2013 10:55 AM, Mahmoud wrote: > > Hello, > > Thank you very much for your time and attention. > > I changed client side code (kinit.c) but it requires to change all > clients. Now, I decided to change server side code. > > > It seems that you should try to contribute code upstream if you want to > end up with any kind of support of your enhancements, otherwise you would > have to maintain your own version. > > > I thought it may be better choice. Should I change policy.c file to > change ticket policies? > > > What policies do you want to change and why? You might have described your > intent on some other thread in some other list but not here. > > > It does not require recompiling krb5kdc? > > > I suspect it does... > > > I install FreeIPA on Fedora 18, When I execute klist -V command, hence > get following result: > Kerberos 5 version 1.10.3 > > Fedora 19 has 1.11 > > IMO the best would be to have a details explanation of what you are trying > to accomplish. > This way we would be able to help you with the right approach. > But it seems that building custom code might not be best option. > > Thanks > Dmitri > > > Best regards. > > On Mon, Sep 9, 2013 at 6:00 PM, Simo Sorce wrote: > >> On Mon, 2013-09-09 at 08:07 +0430, Mahmoud wrote: >> > Hello Simo >> > >> > >> > The previous problem occurred due to installing krb5-1.11.3. I install >> > krb5-1.10.6 and copy ipadb.so in appropriate directory, hence the >> > problem has been solved. Is it all right? >> >> >> No it is not, we require 1.11.3 for OTP support in the latest FreeIPA. >> >> Seriously, chaingin the KDC is the last thing you want to do to solve >> your problem. >> >> Have you looked into creating custom ticket policies for your users ? >> >> Why do you need to change the KDC to do that ? >> >> Simo. >> > >> > Thank you. >> > >> > Best regards. >> > >> > >> > >> > On Mon, Sep 9, 2013 at 7:47 AM, Luke Howard wrote: >> > >> > On 09/09/2013, at 1:08 PM, Mahmoud wrote: >> > >> > > I thought FreeIpa uses krb5-1.10.3, but I use klist -V get >> > following result: >> > > Kerberos 5 version 1.10.3 >> > >> > >> > Aren't these the same thing? >> > >> > -- Luke >> > >> > >> >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> > > > _______________________________________________ > Freeipa-devel mailing listFreeipa-devel at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-devel > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hotz at jpl.nasa.gov Mon Sep 9 20:07:09 2013 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Mon, 9 Sep 2013 13:07:09 -0700 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <20130909160229.GC2855@redhat.com> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <20130909140221.GA2855@redhat.com> <522DD5C7.6000809@redhat.com> <20130909142404.GB2855@redhat.com> <522DDBE8.90209@redhat.com> <20130909160229.GC2855@redhat.com> Message-ID: <57B66740-A398-470E-91DC-EDFA3959633B@jpl.nasa.gov> Aren't the implementations of name constrains generally buggy, and therefore not usable in real life? On Sep 9, 2013, at 9:02 AM, Nalin Dahyabhai wrote: > On Mon, Sep 09, 2013 at 10:32:08AM -0400, John Dennis wrote: >> Good point. Isn't there an X509 extension (possibly part of PKIX?) which >> restricts membership in the chain path to a criteria. In other words you >> can require your sub-CA to be present in the chain. Sorry, but my memory >> is a bit fuzzy on this. > > If you're talking about Name Constraints, they seem to be geared more > toward allowing a CA to limit what a sub CA that it issues can be > trusted to do, and not the other way around. > > I don't think I know of anything that deals with this that doesn't > eventually end up setting up library-specific configuration for the > library that's going to be verifying the certificate. > > Nalin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu From hotz at jpl.nasa.gov Mon Sep 9 20:10:29 2013 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Mon, 9 Sep 2013 13:10:29 -0700 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <20130909140221.GA2855@redhat.com> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <20130909140221.GA2855@redhat.com> Message-ID: <7EB02322-3FB6-48ED-A0E3-B920930505CE@jpl.nasa.gov> I would strongly argue for a separate CA list for PKINIT (service or workstation login) vice HTTP (web browsing of semi-unknown sites). The trust models are fundamentally different. In the former case you are saying who is allowed to issue (conceivably fraudulent) client certs that allow (conceivably fraudulent) users to access local services or workstations. In my case I have PIV cards with certs issued by one of a number of US Gov organizations that mostly trace to the Federal Bridge. Allowing certs issued by a hostile foreign government is clearly a very bad idea. In the latter case you are probably dealing with the a general desire to know that there is some attestation by someone that the web site you are visiting is actually what you intended. You may be visiting the web site of an agency of a hostile foreign government, in which case that government's CA is exactly what you want to "trust". You might even want a control that prohibits any "friendly" CA from issuing certs for that web site. Large lists of trusted CAs represent attack surface, however convenient they may make some things. Whatever the defaults are, we need tools that allow us to model our actual trust for the specific operations we are performing. In an Enterprise environment accessing local services should only be allowed if they use the corresponding local CA. On Sep 9, 2013, at 7:02 AM, Nalin Dahyabhai wrote: > On Mon, Sep 09, 2013 at 11:17:02AM +0200, Jan Cholasta wrote: >> Should each IPA service (LDAP, HTTP, PKINIT) have its own >> distinctive set of trusted CAs, or is using one set for everything >> good enough? Using distinctive sets would allow granular control >> over what CA is trusted for what service (e.g. trust CA1 to issue >> certificates for LDAP and HTTP, but trust CA2 only to issue >> certificates for HTTP), but I'm not sure how useful that would be in >> the real world. > > I'd expect it to depend heavily on whether or not you're chaining up to > an external CA. Personally, I'd very much want to keep a different set > of trust anchors for PKINIT in that situation. > > HTH, > > Nalin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu From nalin at redhat.com Mon Sep 9 20:54:00 2013 From: nalin at redhat.com (Nalin Dahyabhai) Date: Mon, 9 Sep 2013 16:54:00 -0400 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <57B66740-A398-470E-91DC-EDFA3959633B@jpl.nasa.gov> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <20130909140221.GA2855@redhat.com> <522DD5C7.6000809@redhat.com> <20130909142404.GB2855@redhat.com> <522DDBE8.90209@redhat.com> <20130909160229.GC2855@redhat.com> <57B66740-A398-470E-91DC-EDFA3959633B@jpl.nasa.gov> Message-ID: <20130909205400.GD2855@redhat.com> On Mon, Sep 09, 2013 at 01:07:09PM -0700, Henry B. Hotz wrote: > On Sep 9, 2013, at 9:02 AM, Nalin Dahyabhai wrote: > > On Mon, Sep 09, 2013 at 10:32:08AM -0400, John Dennis wrote: > >> Good point. Isn't there an X509 extension (possibly part of PKIX?) which > >> restricts membership in the chain path to a criteria. In other words you > >> can require your sub-CA to be present in the chain. Sorry, but my memory > >> is a bit fuzzy on this. > > > > If you're talking about Name Constraints, they seem to be geared more > > toward allowing a CA to limit what a sub CA that it issues can be > > trusted to do, and not the other way around. > > Aren't the implementations of name constrains generally buggy, and therefore not usable in real life? Yes, ISTR hearing that library support for them was not as widespread as I'd have hoped. There's also the secondary problem that the standards don't specify how to express Name Constraints on AnotherName values, for example Kerberos principal names. Though it's possible I just haven't found where that was done. Cheers, Nalin From dpal at redhat.com Tue Sep 10 00:54:17 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 09 Sep 2013 20:54:17 -0400 Subject: [Freeipa-devel] ipadb.so In-Reply-To: References: <1378654817.2804.1370.camel@willson.li.ssimo.org> <522CC1CA.5080502@redhat.com> <6F7CE3CF-EBFC-4EDA-A823-EF8350AF1F1B@padl.com> <1378733458.2804.1419.camel@willson.li.ssimo.org> <522DECA7.1070200@redhat.com> Message-ID: <522E6DB9.7080103@redhat.com> On 09/09/2013 12:49 PM, Mahmoud wrote: > Hello Mr. Dmitri Pal > > Thank you very much for your help. > > I tried to change source code to have more option. It was difficult > for me to understand FreeIPA source code. Hence, I decided to change > Kerberos source code. I want to add more features to Kerberos. For > example, I like to have two (or several) types of ticket expiration. What do you mean by several types of ticket expiration? Can you please give an example? > > Thanks > Best regards > > > On Mon, Sep 9, 2013 at 8:13 PM, Dmitri Pal > wrote: > > On 09/09/2013 10:55 AM, Mahmoud wrote: >> Hello, >> >> Thank you very much for your time and attention. >> >> I changed client side code (kinit.c) but it requires to change >> all clients. Now, I decided to change server side code. > > It seems that you should try to contribute code upstream if you > want to end up with any kind of support of your enhancements, > otherwise you would have to maintain your own version. > > >> I thought it may be better choice. Should I change policy.c file >> to change ticket policies? > > What policies do you want to change and why? You might have > described your intent on some other thread in some other list but > not here. > > >> It does not require recompiling krb5kdc? > > I suspect it does... > > >> I install FreeIPA on Fedora 18, When I execute klist -V command, >> hence get following result: >> Kerberos 5 version 1.10.3 >> > Fedora 19 has 1.11 > > IMO the best would be to have a details explanation of what you > are trying to accomplish. > This way we would be able to help you with the right approach. > But it seems that building custom code might not be best option. > > Thanks > Dmitri > > >> Best regards. >> >> On Mon, Sep 9, 2013 at 6:00 PM, Simo Sorce > > wrote: >> >> On Mon, 2013-09-09 at 08:07 +0430, Mahmoud wrote: >> > Hello Simo >> > >> > >> > The previous problem occurred due to installing >> krb5-1.11.3. I install >> > krb5-1.10.6 and copy ipadb.so in appropriate directory, >> hence the >> > problem has been solved. Is it all right? >> >> >> No it is not, we require 1.11.3 for OTP support in the latest >> FreeIPA. >> >> Seriously, chaingin the KDC is the last thing you want to do >> to solve >> your problem. >> >> Have you looked into creating custom ticket policies for your >> users ? >> >> Why do you need to change the KDC to do that ? >> >> Simo. >> > >> > Thank you. >> > >> > Best regards. >> > >> > >> > >> > On Mon, Sep 9, 2013 at 7:47 AM, Luke Howard > > wrote: >> > >> > On 09/09/2013, at 1:08 PM, Mahmoud >> > wrote: >> > >> > > I thought FreeIpa uses krb5-1.10.3, but I use >> klist -V get >> > following result: >> > > Kerberos 5 version 1.10.3 >> > >> > >> > Aren't these the same thing? >> > >> > -- Luke >> > >> > >> >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- 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 alee at redhat.com Tue Sep 10 01:02:07 2013 From: alee at redhat.com (Ade Lee) Date: Mon, 09 Sep 2013 21:02:07 -0400 Subject: [Freeipa-devel] Announcing the release of Dogtag 10.0.5 Message-ID: <1378774927.2412.36.camel@aleeredhat.laptop> The Dogtag team is proud to announce the fifth errata build for Dogtag 10.0. Builds are available for Fedora 18 and Fedora 19 in the updates-testing repositories. Please try them out and provide karma to move them to the F18 and F19 stable repositories. Karma can be provided at https://admin.fedoraproject.org/updates for each package. == Build Versions == pki-core-10.0.5-1 pki-ra-10.0.5-1 pki-tps-10.0.5-1 dogtag-pki-10.0.5-1 dogtag-pki-theme-10.0.5-1 pki-console-10.0.5-1 == Highlights since Dogtag 10.0.4 == * Due to changes in systemd, restarting Dogtag 10 instances using systemctl restart pki-tomcatd.target failed. Changes have been made to the systemd startup configuration to ensure that this works correctly. In addition, configuration has been added to require systemd to accept an exit status of 143 (a correct exit status for the JVM) as valid, so this exit value will no longer be reported in the system logs. * Due to changes in the python-requests, a new exception (ProxyError) was returned when attempting to connect to a server that is not yet available. This affected pkispawn installation code when we wait for a server to restart. The code has been modified to handle this (and other) exceptions. * In a case following a bad restart, the CS.cfg for an instance appeared to be cleared or truncated. The code has been changed to not write server status to the CS.cfg on startup, but rather to use an in-memory variable. * Fixed LDAP search filter code to no longer return certificates expired for both reason 1 and reason 10 when searching only for reason 1. == Detailed Changes since Dogtag 10.0.4 == alee (5): #712 pki cert-find --revocationReason 1 finds certs expired for reason 1 and reason 10 #714 CS.cfg cleared #716 pki-tomcatd at pki-tomcat.service does not start when pki-tomcatd.target is started #717 Proxy error while getting status when spawning CA #719 Incorrect value in CS,cfg for manager.ldif location From gh.mdgh at gmail.com Tue Sep 10 05:19:48 2013 From: gh.mdgh at gmail.com (Mahmoud) Date: Tue, 10 Sep 2013 09:49:48 +0430 Subject: [Freeipa-devel] ipadb.so In-Reply-To: <522E6DB9.7080103@redhat.com> References: <1378654817.2804.1370.camel@willson.li.ssimo.org> <522CC1CA.5080502@redhat.com> <6F7CE3CF-EBFC-4EDA-A823-EF8350AF1F1B@padl.com> <1378733458.2804.1419.camel@willson.li.ssimo.org> <522DECA7.1070200@redhat.com> <522E6DB9.7080103@redhat.com> Message-ID: Hello, Thank you for your response. When a user get tgt ticket, he can get service tickets without typing password. I like to have several level of users. As high level users have more access to resources, I want to grant a ticket with less validation time. In other word, I want to have several ticket life time due to user levels. Best regards On Tue, Sep 10, 2013 at 5:24 AM, Dmitri Pal wrote: > On 09/09/2013 12:49 PM, Mahmoud wrote: > > Hello Mr. Dmitri Pal > > Thank you very much for your help. > > I tried to change source code to have more option. It was difficult for > me to understand FreeIPA source code. Hence, I decided to change Kerberos > source code. I want to add more features to Kerberos. For example, I like > to have two (or several) types of ticket expiration. > > > What do you mean by several types of ticket expiration? > Can you please give an example? > > > > Thanks > Best regards > > > On Mon, Sep 9, 2013 at 8:13 PM, Dmitri Pal wrote: > >> On 09/09/2013 10:55 AM, Mahmoud wrote: >> >> Hello, >> >> Thank you very much for your time and attention. >> >> I changed client side code (kinit.c) but it requires to change all >> clients. Now, I decided to change server side code. >> >> >> It seems that you should try to contribute code upstream if you want to >> end up with any kind of support of your enhancements, otherwise you would >> have to maintain your own version. >> >> >> I thought it may be better choice. Should I change policy.c file to >> change ticket policies? >> >> >> What policies do you want to change and why? You might have described >> your intent on some other thread in some other list but not here. >> >> >> It does not require recompiling krb5kdc? >> >> >> I suspect it does... >> >> >> I install FreeIPA on Fedora 18, When I execute klist -V command, >> hence get following result: >> Kerberos 5 version 1.10.3 >> >> Fedora 19 has 1.11 >> >> IMO the best would be to have a details explanation of what you are >> trying to accomplish. >> This way we would be able to help you with the right approach. >> But it seems that building custom code might not be best option. >> >> Thanks >> Dmitri >> >> >> Best regards. >> >> On Mon, Sep 9, 2013 at 6:00 PM, Simo Sorce wrote: >> >>> On Mon, 2013-09-09 at 08:07 +0430, Mahmoud wrote: >>> > Hello Simo >>> > >>> > >>> > The previous problem occurred due to installing krb5-1.11.3. I install >>> > krb5-1.10.6 and copy ipadb.so in appropriate directory, hence the >>> > problem has been solved. Is it all right? >>> >>> >>> No it is not, we require 1.11.3 for OTP support in the latest FreeIPA. >>> >>> Seriously, chaingin the KDC is the last thing you want to do to solve >>> your problem. >>> >>> Have you looked into creating custom ticket policies for your users ? >>> >>> Why do you need to change the KDC to do that ? >>> >>> Simo. >>> > >>> > Thank you. >>> > >>> > Best regards. >>> > >>> > >>> > >>> > On Mon, Sep 9, 2013 at 7:47 AM, Luke Howard wrote: >>> > >>> > On 09/09/2013, at 1:08 PM, Mahmoud wrote: >>> > >>> > > I thought FreeIpa uses krb5-1.10.3, but I use klist -V get >>> > following result: >>> > > Kerberos 5 version 1.10.3 >>> > >>> > >>> > Aren't these the same thing? >>> > >>> > -- Luke >>> > >>> > >>> >>> >>> -- >>> Simo Sorce * Red Hat, Inc * New York >>> >>> >> >> >> _______________________________________________ >> Freeipa-devel mailing listFreeipa-devel at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs?www.redhat.com/carveoutcosts/ >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > > > -- > 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 gh.mdgh at gmail.com Tue Sep 10 06:54:04 2013 From: gh.mdgh at gmail.com (Mahmoud) Date: Tue, 10 Sep 2013 11:24:04 +0430 Subject: [Freeipa-devel] ipadb.so In-Reply-To: References: <1378654817.2804.1370.camel@willson.li.ssimo.org> <522CC1CA.5080502@redhat.com> <6F7CE3CF-EBFC-4EDA-A823-EF8350AF1F1B@padl.com> <1378733458.2804.1419.camel@willson.li.ssimo.org> <522DECA7.1070200@redhat.com> <522E6DB9.7080103@redhat.com> Message-ID: Hello, I installed Fedora 19. Each time I change /usr/sbin/krb5kdc, it will not start again. I get following error: krb5kdc: Server error - while fetching master key K/M for realm EXAMPLE.COM Via reinstalling IPA, the problem will be fixed but I would like to fix it without reinstalling IPA. When I reinstalled IPA, all previous stored data has been deleted. Is there any way to reconfigure Kerberos without deleting database data? Could you help me, please? On Tue, Sep 10, 2013 at 9:49 AM, Mahmoud wrote: > Hello, > > Thank you for your response. > When a user get tgt ticket, he can get service tickets without typing > password. I like to have several level of users. As high level users have > more access to resources, I want to grant a ticket with less validation > time. In other word, I want to have several ticket life time due to user > levels. > > Best regards > > > On Tue, Sep 10, 2013 at 5:24 AM, Dmitri Pal wrote: > >> On 09/09/2013 12:49 PM, Mahmoud wrote: >> >> Hello Mr. Dmitri Pal >> >> Thank you very much for your help. >> >> I tried to change source code to have more option. It was difficult for >> me to understand FreeIPA source code. Hence, I decided to change Kerberos >> source code. I want to add more features to Kerberos. For example, I like >> to have two (or several) types of ticket expiration. >> >> >> What do you mean by several types of ticket expiration? >> Can you please give an example? >> >> >> >> Thanks >> Best regards >> >> >> On Mon, Sep 9, 2013 at 8:13 PM, Dmitri Pal wrote: >> >>> On 09/09/2013 10:55 AM, Mahmoud wrote: >>> >>> Hello, >>> >>> Thank you very much for your time and attention. >>> >>> I changed client side code (kinit.c) but it requires to change all >>> clients. Now, I decided to change server side code. >>> >>> >>> It seems that you should try to contribute code upstream if you want to >>> end up with any kind of support of your enhancements, otherwise you would >>> have to maintain your own version. >>> >>> >>> I thought it may be better choice. Should I change policy.c file to >>> change ticket policies? >>> >>> >>> What policies do you want to change and why? You might have described >>> your intent on some other thread in some other list but not here. >>> >>> >>> It does not require recompiling krb5kdc? >>> >>> >>> I suspect it does... >>> >>> >>> I install FreeIPA on Fedora 18, When I execute klist -V command, >>> hence get following result: >>> Kerberos 5 version 1.10.3 >>> >>> Fedora 19 has 1.11 >>> >>> IMO the best would be to have a details explanation of what you are >>> trying to accomplish. >>> This way we would be able to help you with the right approach. >>> But it seems that building custom code might not be best option. >>> >>> Thanks >>> Dmitri >>> >>> >>> Best regards. >>> >>> On Mon, Sep 9, 2013 at 6:00 PM, Simo Sorce wrote: >>> >>>> On Mon, 2013-09-09 at 08:07 +0430, Mahmoud wrote: >>>> > Hello Simo >>>> > >>>> > >>>> > The previous problem occurred due to installing krb5-1.11.3. I install >>>> > krb5-1.10.6 and copy ipadb.so in appropriate directory, hence the >>>> > problem has been solved. Is it all right? >>>> >>>> >>>> No it is not, we require 1.11.3 for OTP support in the latest FreeIPA. >>>> >>>> Seriously, chaingin the KDC is the last thing you want to do to solve >>>> your problem. >>>> >>>> Have you looked into creating custom ticket policies for your users ? >>>> >>>> Why do you need to change the KDC to do that ? >>>> >>>> Simo. >>>> > >>>> > Thank you. >>>> > >>>> > Best regards. >>>> > >>>> > >>>> > >>>> > On Mon, Sep 9, 2013 at 7:47 AM, Luke Howard wrote: >>>> > >>>> > On 09/09/2013, at 1:08 PM, Mahmoud wrote: >>>> > >>>> > > I thought FreeIpa uses krb5-1.10.3, but I use klist -V get >>>> > following result: >>>> > > Kerberos 5 version 1.10.3 >>>> > >>>> > >>>> > Aren't these the same thing? >>>> > >>>> > -- Luke >>>> > >>>> > >>>> >>>> >>>> -- >>>> Simo Sorce * Red Hat, Inc * New York >>>> >>>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing listFreeipa-devel at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager for IdM portfolio >>> Red Hat Inc. >>> >>> >>> ------------------------------- >>> Looking to carve out IT costs?www.redhat.com/carveoutcosts/ >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >> >> >> >> -- >> 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 pviktori at redhat.com Tue Sep 10 07:50:51 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 10 Sep 2013 09:50:51 +0200 Subject: [Freeipa-devel] [PATCH] 168 Fix nsslapdPlugin object class after initial replication In-Reply-To: <522DE322.3000101@redhat.com> References: <522DE322.3000101@redhat.com> Message-ID: <522ECF5B.3040503@redhat.com> On 09/09/2013 05:02 PM, Jan Cholasta wrote: > Hi, > > the attached patch fixes . > > Honza ACK, this allowed me to install a replica from IPA 3.0.0 (RHEL 6.4). Removed trailing whitespace and pushed to: master: e380acdc1c15af63413b7ac0d27ddea513535a5d ipa-3-3: 9d8d0bb697868df801bbc150583e553eca7acd56 -- Petr? From jcholast at redhat.com Tue Sep 10 08:30:55 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 10 Sep 2013 10:30:55 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <1378742085.2804.1451.camel@willson.li.ssimo.org> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <522DD50A.9090606@redhat.com> <522DDD94.1050000@redhat.com> <522DDDE3.3030308@redhat.com> <1378742085.2804.1451.camel@willson.li.ssimo.org> Message-ID: <522ED8BF.1000602@redhat.com> On 9.9.2013 17:54, Simo Sorce wrote: > On Mon, 2013-09-09 at 10:40 -0400, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 9.9.2013 16:02, John Dennis wrote: >>>> On 09/09/2013 05:17 AM, Jan Cholasta wrote: >>>>> Another question: >>>>> >>>>> Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive >>>>> set of trusted CAs, or is using one set for everything good enough? >>>>> Using distinctive sets would allow granular control over what CA is >>>>> trusted for what service (e.g. trust CA1 to issue certificates for LDAP >>>>> and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm >>>>> not sure how useful that would be in the real world. >>>> >>>> That would complicate things quickly. Managing CA certs is already >>>> challenging enough. Exploding this via combinations does not seem to >>>> present enough real value for the complexity. >>>> >>>> In the real world most deployments boil down to a single CA and that >>>> trust model been effective. Don't forget you can always revoke any cert >>>> issued by a CA. Having granular control over individual CA's does not >>>> seem to present value, just complications. If your CA is compromised >>>> you've got big things to worry about, having it be 1 in N does not seem >>>> to change that equation radically. If one CA got compromised you've got >>>> a lot of work to do to replace the trusted CA list everywhere. If one is >>>> compromised why aren't the other CA's? Having to update just one CA >>>> trust rather than potentially N is better. >>> >>> I'm not suggesting *controlling* multiple CAs, but being able to manage >>> what individual external CAs are trusted to do. This is probably only >>> relevant to CA-less install. When IPA internal CA is installed, there is >>> just that one CA, which is trusted for everything. >>> >> >> We've fielded questions from people wanting to replace the cert in the >> web server even while maintaining the IPA CA. Granted this was prior to >> the CA-less option. > >> The impetus seems to be not requiring all users to trust the IPA CA. I >> think if that became easier then wanting to use another CA would be less >> of an issue. > > And I really think this would be better served with an SNI setup, where > we have 2 SSL certs for the web server only (a public one and an IPA > one). While everything else must use the IPA CA, esp for PKINIT. What if there is no IPA CA (CA-less)? Should we assume that the user has their own CA in control and allow only certs signed by that single CA? Regarding SNI, it apparently is not supported in server-side NSS (https://bugzilla.mozilla.org/show_bug.cgi?id=360421) and Python 2.x (http://bugs.python.org/issue5639). These seem like blockers to me, correct me if I'm wrong. > > Simo. > -- Jan Cholasta From gim.spb at gmail.com Tue Sep 10 10:23:24 2013 From: gim.spb at gmail.com (Gorbachev Ivan) Date: Tue, 10 Sep 2013 14:23:24 +0400 Subject: [Freeipa-devel] ipa api Message-ID: Hello! Can you help me, how to authenticate in ipa from code (C++) ? -- With Best Regards Gorbachev Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Tue Sep 10 10:46:03 2013 From: sbose at redhat.com (Sumit Bose) Date: Tue, 10 Sep 2013 12:46:03 +0200 Subject: [Freeipa-devel] ipa api In-Reply-To: References: Message-ID: <20130910104603.GH6165@localhost.localdomain> On Tue, Sep 10, 2013 at 02:23:24PM +0400, Gorbachev Ivan wrote: > Hello! Can you help me, how to authenticate in ipa from code (C++) ? It depends a bit on what you are looking for but typically applications are using PAM (http://en.wikipedia.org/wiki/Pluggable_authentication_module) for authentication. HTH bye, Sumit > > -- > With Best Regards > Gorbachev Ivan > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pviktori at redhat.com Tue Sep 10 11:53:47 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 10 Sep 2013 13:53:47 +0200 Subject: [Freeipa-devel] Notes and questions for fine-grained read permissions In-Reply-To: <1378744300.2804.1463.camel@willson.li.ssimo.org> References: <5228BA5D.8090702@redhat.com> <5228C3F5.5000505@redhat.com> <5229839E.9070105@redhat.com> <5229CEBD.7070705@redhat.com> <1378565107.2804.1122.camel@willson.li.ssimo.org> <522DAA31.20900@redhat.com> <1378734388.2804.1435.camel@willson.li.ssimo.org> <522DDDF1.5000208@redhat.com> <1378744300.2804.1463.camel@willson.li.ssimo.org> Message-ID: <522F084B.4020500@redhat.com> On 09/09/2013 06:31 PM, Simo Sorce wrote: > On Mon, 2013-09-09 at 16:40 +0200, Petr Viktorin wrote: >> On 09/09/2013 03:46 PM, Simo Sorce wrote: [...] >>> How do you handle a case where we add 'read-only by admin' for an >>> attribute that was not in the default ACI list at all previously, but >>> the admin already added 'read by everyone' in the custom ACI ? >>> This is the kind of thing that makes me dislike the 2 separate sets, now >>> you need intra-set conflict resolution. >> >> There would be two permissions: "read by admin" and "read by everyone". >> Both would now allow reading the attribute, so it would be readable by >> anyone -- as the admin wanted. >> >> I don't see any need for intra-set conflict resolution. The algorithm is >> simple -- take IPA defaults, add admin-added attributes, filter out >> admin-excluded attributes, allow the resulting set. Recompute whenever >> any of the lists changes. > > Actually this make sense, I was mostly thinking in terms of adding deny > ACIs, but the most positive outcome here will happen if we finally > remove the dreadful deny ACI, so I think we are mostly ok. > > I can still think of a scenario that may not be optimal. > > Admin adds attribute for read by admin only and IPA update adds a > read-by-all permission. > > I think this is unlikely to happen, but probably we need to add a rule > that any such change on IPA part must be reviewed by at least 2 > experienced members before it is approved, so that more than one head > reviews and vets such a change. Any time we add a new attribute to an existing object, there's a chance that some users were already using it. Especially with our configurable user/group objectclasses. A reasonable review rule is fine. I think we should also add all permission changes to release notes. >>>> If we mark a Permission as SYSTEM, old IPA versions won't try to locate >>>> or touch its ACI, but they'll still be able to add it to privileges and >>>> roles using the existing API/CLI/UI. >>> >>> I do not understand the nuances of this SYSTEM permission, can you >>> explain why we want it, and why it should't "locate or touch its ACI" >>> whatever it really means ? >> >> Permissions are IPA objects that encapsulate the underlying ACIs and >> make them easier to manage. Permissions are less flexible than raw ACIs. >> Sometimes they need more power than what the Permission UI exposes, so >> we mark them as SYSTEM. The CLI/UI then doesn't read or update the >> underlying ACI. >> If we add permissions that work differently than the existing ones, we >> can mark them SYSTEM so *old IPA* doesn't try to manipulate the >> underlying ACIs. >> (And we need to add some kind of permision versioning, in case the >> functionality changes again.) > > Ok, now I get it, SYSTEM was your way to name 'low level ACIs we set > directly'. Yes and no. Users can still add SYSTEM permissions to privileges to grant them to specific users. Currently we use them for replication management, where the ACIs are somewhere in cn=config as opposed to $SUFFIX, and for DNS read rights (permissions currently don't handle read rights). ACIs we set directly, like hardcoded ACIs for the admins group, or the dreaded anonymous allow all rule, don't have an associated Permission object and aren't visible in the UI. [...] > And it will be really fun for you to find out how to upgrade from the > current scheme to the final state here (which is critical, no 'start > from scratch' strategies here ok ?) but I think it is quite doable. Challenge accepted :) -- Petr? From rcritten at redhat.com Tue Sep 10 12:45:28 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Sep 2013 08:45:28 -0400 Subject: [Freeipa-devel] ipa api In-Reply-To: <20130910104603.GH6165@localhost.localdomain> References: <20130910104603.GH6165@localhost.localdomain> Message-ID: <522F1468.7060506@redhat.com> Sumit Bose wrote: > On Tue, Sep 10, 2013 at 02:23:24PM +0400, Gorbachev Ivan wrote: >> Hello! Can you help me, how to authenticate in ipa from code (C++) ? > > It depends a bit on what you are looking for but typically applications > are using PAM > (http://en.wikipedia.org/wiki/Pluggable_authentication_module) for > authentication. I guess I would add: authenticate whom, to what? rob From simo at redhat.com Tue Sep 10 12:49:45 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 10 Sep 2013 08:49:45 -0400 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <522ED8BF.1000602@redhat.com> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <522DD50A.9090606@redhat.com> <522DDD94.1050000@redhat.com> <522DDDE3.3030308@redhat.com> <1378742085.2804.1451.camel@willson.li.ssimo.org> <522ED8BF.1000602@redhat.com> Message-ID: <1378817385.2804.1534.camel@willson.li.ssimo.org> On Tue, 2013-09-10 at 10:30 +0200, Jan Cholasta wrote: > On 9.9.2013 17:54, Simo Sorce wrote: > > On Mon, 2013-09-09 at 10:40 -0400, Rob Crittenden wrote: > >> Jan Cholasta wrote: > >>> On 9.9.2013 16:02, John Dennis wrote: > >>>> On 09/09/2013 05:17 AM, Jan Cholasta wrote: > >>>>> Another question: > >>>>> > >>>>> Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive > >>>>> set of trusted CAs, or is using one set for everything good enough? > >>>>> Using distinctive sets would allow granular control over what CA is > >>>>> trusted for what service (e.g. trust CA1 to issue certificates for LDAP > >>>>> and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm > >>>>> not sure how useful that would be in the real world. > >>>> > >>>> That would complicate things quickly. Managing CA certs is already > >>>> challenging enough. Exploding this via combinations does not seem to > >>>> present enough real value for the complexity. > >>>> > >>>> In the real world most deployments boil down to a single CA and that > >>>> trust model been effective. Don't forget you can always revoke any cert > >>>> issued by a CA. Having granular control over individual CA's does not > >>>> seem to present value, just complications. If your CA is compromised > >>>> you've got big things to worry about, having it be 1 in N does not seem > >>>> to change that equation radically. If one CA got compromised you've got > >>>> a lot of work to do to replace the trusted CA list everywhere. If one is > >>>> compromised why aren't the other CA's? Having to update just one CA > >>>> trust rather than potentially N is better. > >>> > >>> I'm not suggesting *controlling* multiple CAs, but being able to manage > >>> what individual external CAs are trusted to do. This is probably only > >>> relevant to CA-less install. When IPA internal CA is installed, there is > >>> just that one CA, which is trusted for everything. > >>> > >> > >> We've fielded questions from people wanting to replace the cert in the > >> web server even while maintaining the IPA CA. Granted this was prior to > >> the CA-less option. > > > >> The impetus seems to be not requiring all users to trust the IPA CA. I > >> think if that became easier then wanting to use another CA would be less > >> of an issue. > > > > And I really think this would be better served with an SNI setup, where > > we have 2 SSL certs for the web server only (a public one and an IPA > > one). While everything else must use the IPA CA, esp for PKINIT. > > What if there is no IPA CA (CA-less)? Should we assume that the user has > their own CA in control and allow only certs signed by that single CA? > > Regarding SNI, it apparently is not supported in server-side NSS > (https://bugzilla.mozilla.org/show_bug.cgi?id=360421) We need to either push for a solution to this or allow to switch to mod_ssl. > and Python 2.x > (http://bugs.python.org/issue5639). This issue seem for python 3.2, do we actually use python code to perform SSL connections to HTTP servers ? I am not sure we do. > These seem like blockers to me, > correct me if I'm wrong. Yes they are blockers, so we need to either solve them ourselves or work around. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Sep 10 13:29:17 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 10 Sep 2013 09:29:17 -0400 Subject: [Freeipa-devel] ipadb.so In-Reply-To: References: <1378654817.2804.1370.camel@willson.li.ssimo.org> <522CC1CA.5080502@redhat.com> <6F7CE3CF-EBFC-4EDA-A823-EF8350AF1F1B@padl.com> <1378733458.2804.1419.camel@willson.li.ssimo.org> <522DECA7.1070200@redhat.com> <522E6DB9.7080103@redhat.com> Message-ID: <1378819757.2804.1554.camel@willson.li.ssimo.org> On Tue, 2013-09-10 at 11:24 +0430, Mahmoud wrote: > Hello, > > > I installed Fedora 19. > Each time I change /usr/sbin/krb5kdc, it will not start again. I get > following error: > krb5kdc: Server error - while fetching master key K/M for realm > EXAMPLE.COM > If you get this error it means your krb5kdc binary does not find nor loads ipadb.so > Via reinstalling IPA, the problem will be fixed but I would like to > fix it without reinstalling IPA. What I suspect is happening is that by reinstalling IPA you get a bdb based database in kerberos. That will not work. > When I reinstalled IPA, all previous stored data has been deleted. > Is there any way to reconfigure Kerberos without deleting database > data? No, there is no need to 'reconfigure kerberos', it's already configured properly in LDAP, krb5.conf and kdc.conf, you are just replacing a binary, if you get errors it's because you failed to properly build the binary. I strongly suggest, if you really need to, that you build the new binary as an rpm so that all ./configure options are correct for the target machine. Simo. -- Simo Sorce * Red Hat, Inc * New York From gh.mdgh at gmail.com Tue Sep 10 13:52:08 2013 From: gh.mdgh at gmail.com (Mahmoud) Date: Tue, 10 Sep 2013 18:22:08 +0430 Subject: [Freeipa-devel] ipadb.so In-Reply-To: <1378819757.2804.1554.camel@willson.li.ssimo.org> References: <1378654817.2804.1370.camel@willson.li.ssimo.org> <522CC1CA.5080502@redhat.com> <6F7CE3CF-EBFC-4EDA-A823-EF8350AF1F1B@padl.com> <1378733458.2804.1419.camel@willson.li.ssimo.org> <522DECA7.1070200@redhat.com> <522E6DB9.7080103@redhat.com> <1378819757.2804.1554.camel@willson.li.ssimo.org> Message-ID: Hello Mr. Simo Sorce Thank you very much for your time and attention. Best regards. On Tue, Sep 10, 2013 at 5:59 PM, Simo Sorce wrote: > On Tue, 2013-09-10 at 11:24 +0430, Mahmoud wrote: > > Hello, > > > > > > I installed Fedora 19. > > Each time I change /usr/sbin/krb5kdc, it will not start again. I get > > following error: > > krb5kdc: Server error - while fetching master key K/M for realm > > EXAMPLE.COM > > > If you get this error it means your krb5kdc binary does not find nor > loads ipadb.so > > > Via reinstalling IPA, the problem will be fixed but I would like to > > fix it without reinstalling IPA. > > What I suspect is happening is that by reinstalling IPA you get a bdb > based database in kerberos. That will not work. > > > When I reinstalled IPA, all previous stored data has been deleted. > > Is there any way to reconfigure Kerberos without deleting database > > data? > > No, there is no need to 'reconfigure kerberos', it's already configured > properly in LDAP, krb5.conf and kdc.conf, you are just replacing a > binary, if you get errors it's because you failed to properly build the > binary. I strongly suggest, if you really need to, that you build the > new binary as an rpm so that all ./configure options are correct for the > target machine. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Sep 10 14:58:26 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 10 Sep 2013 10:58:26 -0400 Subject: [Freeipa-devel] ipadb.so In-Reply-To: References: <1378654817.2804.1370.camel@willson.li.ssimo.org> <522CC1CA.5080502@redhat.com> <6F7CE3CF-EBFC-4EDA-A823-EF8350AF1F1B@padl.com> <1378733458.2804.1419.camel@willson.li.ssimo.org> <522DECA7.1070200@redhat.com> <522E6DB9.7080103@redhat.com> Message-ID: <522F3392.5040805@redhat.com> On 09/10/2013 01:19 AM, Mahmoud wrote: > Hello, > > Thank you for your response. > When a user get tgt ticket, he can get service tickets without typing > password. I like to have several level of users. As high level users > have more access to resources, I want to grant a ticket with less > validation time. In other word, I want to have several ticket life > time due to user levels. If you use IPA then you can use default policy to set the default value. The attribute you care is: krbMaxTicketLife You can use the realm entry to set the default policy for the majority of principals dn: cn=EXAMPLE.COM,cn=kerberos,dc=gsslab,dc=rdu,dc=redhat,dc=com cn: EXAMPLE.COM objectClass: top objectClass: krbrealmcontainer objectClass: krbticketpolicyaux krbSubTrees: dc=gsslab,dc=rdu,dc=redhat,dc=com krbSearchScope: 2 krbSupportedEncSaltTypes: aes256-cts:normal krbSupportedEncSaltTypes: aes128-cts:normal krbSupportedEncSaltTypes: des3-hmac-sha1:normal krbSupportedEncSaltTypes: arcfour-hmac:normal krbSupportedEncSaltTypes: des-hmac-sha1:normal krbSupportedEncSaltTypes: des-cbc-md5:normal krbSupportedEncSaltTypes: des-cbc-crc:normal krbSupportedEncSaltTypes: des-cbc-crc:v4 krbSupportedEncSaltTypes: des-cbc-crc:afs3 krbDefaultEncSaltTypes: aes256-cts:normal krbDefaultEncSaltTypes: aes128-cts:normal krbDefaultEncSaltTypes: des3-hmac-sha1:normal krbDefaultEncSaltTypes: arcfour-hmac:normal krbDefaultEncSaltTypes: des-hmac-sha1:normal krbDefaultEncSaltTypes: des-cbc-md5:normal krbMKey:: GFFFYTUYFUYFHJJJHGJGJHGJHGJ Set krbMaxTicketLife to value in seconds. Then on per principal you can set it to a specific value you need based on the type of the user. There is no need to recompile any code. You can also look at the password policies feature in IPA. We added ability to define a policy per group. If you want to manage krbMaxTicketLife per group you might do a similar thing. Let me know if you are interested in contributing this feature to IPA. Thanks Dmitri > > > On Tue, Sep 10, 2013 at 5:24 AM, Dmitri Pal > wrote: > > On 09/09/2013 12:49 PM, Mahmoud wrote: >> Hello Mr. Dmitri Pal >> >> Thank you very much for your help. >> >> I tried to change source code to have more option. It was >> difficult for me to understand FreeIPA source code. Hence, I >> decided to change Kerberos source code. I want to add more >> features to Kerberos. For example, I like to have two (or >> several) types of ticket expiration. > > What do you mean by several types of ticket expiration? > Can you please give an example? > > >> >> Thanks >> Best regards >> >> >> On Mon, Sep 9, 2013 at 8:13 PM, Dmitri Pal > > wrote: >> >> On 09/09/2013 10:55 AM, Mahmoud wrote: >>> Hello, >>> >>> Thank you very much for your time and attention. >>> >>> I changed client side code (kinit.c) but it requires to >>> change all clients. Now, I decided to change server side code. >> >> It seems that you should try to contribute code upstream if >> you want to end up with any kind of support of your >> enhancements, otherwise you would have to maintain your own >> version. >> >> >>> I thought it may be better choice. Should I change policy.c >>> file to change ticket policies? >> >> What policies do you want to change and why? You might have >> described your intent on some other thread in some other list >> but not here. >> >> >>> It does not require recompiling krb5kdc? >> >> I suspect it does... >> >> >>> I install FreeIPA on Fedora 18, When I execute klist -V >>> command, hence get following result: >>> Kerberos 5 version 1.10.3 >>> >> Fedora 19 has 1.11 >> >> IMO the best would be to have a details explanation of what >> you are trying to accomplish. >> This way we would be able to help you with the right approach. >> But it seems that building custom code might not be best option. >> >> Thanks >> Dmitri >> >> >>> Best regards. >>> >>> On Mon, Sep 9, 2013 at 6:00 PM, Simo Sorce >> > wrote: >>> >>> On Mon, 2013-09-09 at 08:07 +0430, Mahmoud wrote: >>> > Hello Simo >>> > >>> > >>> > The previous problem occurred due to installing >>> krb5-1.11.3. I install >>> > krb5-1.10.6 and copy ipadb.so in appropriate >>> directory, hence the >>> > problem has been solved. Is it all right? >>> >>> >>> No it is not, we require 1.11.3 for OTP support in the >>> latest FreeIPA. >>> >>> Seriously, chaingin the KDC is the last thing you want >>> to do to solve >>> your problem. >>> >>> Have you looked into creating custom ticket policies for >>> your users ? >>> >>> Why do you need to change the KDC to do that ? >>> >>> Simo. >>> > >>> > Thank you. >>> > >>> > Best regards. >>> > >>> > >>> > >>> > On Mon, Sep 9, 2013 at 7:47 AM, Luke Howard >>> > wrote: >>> > >>> > On 09/09/2013, at 1:08 PM, Mahmoud >>> > wrote: >>> > >>> > > I thought FreeIpa uses krb5-1.10.3, but I >>> use klist -V get >>> > following result: >>> > > Kerberos 5 version 1.10.3 >>> > >>> > >>> > Aren't these the same thing? >>> > >>> > -- Luke >>> > >>> > >>> >>> >>> -- >>> Simo Sorce * Red Hat, Inc * New York >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> > > > -- > 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 dpal at redhat.com Tue Sep 10 15:00:50 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 10 Sep 2013 11:00:50 -0400 Subject: [Freeipa-devel] ipadb.so In-Reply-To: References: <1378654817.2804.1370.camel@willson.li.ssimo.org> <522CC1CA.5080502@redhat.com> <6F7CE3CF-EBFC-4EDA-A823-EF8350AF1F1B@padl.com> <1378733458.2804.1419.camel@willson.li.ssimo.org> <522DECA7.1070200@redhat.com> <522E6DB9.7080103@redhat.com> Message-ID: <522F3422.4030407@redhat.com> On 09/10/2013 02:54 AM, Mahmoud wrote: > Hello, > > I installed Fedora 19. > Each time I change /usr/sbin/krb5kdc, it will not start again. I get > following error: > krb5kdc: Server error - while fetching master key K/M for realm > EXAMPLE.COM > > Via reinstalling IPA, the problem will be fixed but I would like to > fix it without reinstalling IPA. When I reinstalled IPA, all previous > stored data has been deleted. Is there any way to reconfigure > Kerberos without deleting database data? > Could you help me, please? I am not sure what you are trying to do. It seems that you are trying to have Kerberos with DB and IPA at the same time on the same machine. I am not sure that would work. > > > On Tue, Sep 10, 2013 at 9:49 AM, Mahmoud > wrote: > > Hello, > > Thank you for your response. > When a user get tgt ticket, he can get service tickets without > typing password. I like to have several level of users. As high > level users have more access to resources, I want to grant a > ticket with less validation time. In other word, I want to have > several ticket life time due to user levels. > > Best regards > > > On Tue, Sep 10, 2013 at 5:24 AM, Dmitri Pal > wrote: > > On 09/09/2013 12:49 PM, Mahmoud wrote: >> Hello Mr. Dmitri Pal >> >> Thank you very much for your help. >> >> I tried to change source code to have more option. It was >> difficult for me to understand FreeIPA source code. Hence, I >> decided to change Kerberos source code. I want to add more >> features to Kerberos. For example, I like to have two (or >> several) types of ticket expiration. > > What do you mean by several types of ticket expiration? > Can you please give an example? > > >> >> Thanks >> Best regards >> >> >> On Mon, Sep 9, 2013 at 8:13 PM, Dmitri Pal > > wrote: >> >> On 09/09/2013 10:55 AM, Mahmoud wrote: >>> Hello, >>> >>> Thank you very much for your time and attention. >>> >>> I changed client side code (kinit.c) but it requires to >>> change all clients. Now, I decided to change server side >>> code. >> >> It seems that you should try to contribute code upstream >> if you want to end up with any kind of support of your >> enhancements, otherwise you would have to maintain your >> own version. >> >> >>> I thought it may be better choice. Should I change >>> policy.c file to change ticket policies? >> >> What policies do you want to change and why? You might >> have described your intent on some other thread in some >> other list but not here. >> >> >>> It does not require recompiling krb5kdc? >> >> I suspect it does... >> >> >>> I install FreeIPA on Fedora 18, When I execute klist -V >>> command, hence get following result: >>> Kerberos 5 version 1.10.3 >>> >> Fedora 19 has 1.11 >> >> IMO the best would be to have a details explanation of >> what you are trying to accomplish. >> This way we would be able to help you with the right >> approach. >> But it seems that building custom code might not be best >> option. >> >> Thanks >> Dmitri >> >> >>> Best regards. >>> >>> On Mon, Sep 9, 2013 at 6:00 PM, Simo Sorce >>> > wrote: >>> >>> On Mon, 2013-09-09 at 08:07 +0430, Mahmoud wrote: >>> > Hello Simo >>> > >>> > >>> > The previous problem occurred due to installing >>> krb5-1.11.3. I install >>> > krb5-1.10.6 and copy ipadb.so in appropriate >>> directory, hence the >>> > problem has been solved. Is it all right? >>> >>> >>> No it is not, we require 1.11.3 for OTP support in >>> the latest FreeIPA. >>> >>> Seriously, chaingin the KDC is the last thing you >>> want to do to solve >>> your problem. >>> >>> Have you looked into creating custom ticket policies >>> for your users ? >>> >>> Why do you need to change the KDC to do that ? >>> >>> Simo. >>> > >>> > Thank you. >>> > >>> > Best regards. >>> > >>> > >>> > >>> > On Mon, Sep 9, 2013 at 7:47 AM, Luke Howard >>> > wrote: >>> > >>> > On 09/09/2013, at 1:08 PM, Mahmoud >>> > wrote: >>> > >>> > > I thought FreeIpa uses krb5-1.10.3, but >>> I use klist -V get >>> > following result: >>> > > Kerberos 5 version 1.10.3 >>> > >>> > >>> > Aren't these the same thing? >>> > >>> > -- Luke >>> > >>> > >>> >>> >>> -- >>> Simo Sorce * Red Hat, Inc * New York >>> >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> > > > -- > 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 dpal at redhat.com Tue Sep 10 15:05:05 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 10 Sep 2013 11:05:05 -0400 Subject: [Freeipa-devel] ipa api In-Reply-To: <522F1468.7060506@redhat.com> References: <20130910104603.GH6165@localhost.localdomain> <522F1468.7060506@redhat.com> Message-ID: <522F3521.5040506@redhat.com> On 09/10/2013 08:45 AM, Rob Crittenden wrote: > Sumit Bose wrote: >> On Tue, Sep 10, 2013 at 02:23:24PM +0400, Gorbachev Ivan wrote: >>> Hello! Can you help me, how to authenticate in ipa from code (C++) ? >> >> It depends a bit on what you are looking for but typically applications >> are using PAM >> (http://en.wikipedia.org/wiki/Pluggable_authentication_module) for >> authentication. > > I guess I would add: authenticate whom, to what? > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I think the question is about our JSON/RPC API. The answer is: use some kind of kerberos authentication (SSSD, kinit or similar). The user running client side executable will be mapped on the client side to kerberos principal and his ticket will be used automatically from the kerberos cache. There are is not user name and password argument in the API if this is what you are looking for. HTH. -- 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 Tue Sep 10 15:10:25 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 10 Sep 2013 11:10:25 -0400 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <1378817385.2804.1534.camel@willson.li.ssimo.org> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <522DD50A.9090606@redhat.com> <522DDD94.1050000@redhat.com> <522DDDE3.3030308@redhat.com> <1378742085.2804.1451.camel@willson.li.ssimo.org> <522ED8BF.1000602@redhat.com> <1378817385.2804.1534.camel@willson.li.ssimo.org> Message-ID: <522F3661.4030205@redhat.com> On 09/10/2013 08:49 AM, Simo Sorce wrote: > > What if there is no IPA CA (CA-less)? Should we assume that the user has > their own CA in control and allow only certs signed by that single CA? > > Regarding SNI, it apparently is not supported in server-side NSS > (https://bugzilla.mozilla.org/show_bug.cgi?id=360421) > We need to either push for a solution to this or allow to switch to > mod_ssl. Jan Pazdziora investigated us switching to mod_ssl. It is not trivial. Also I would check with Kai. Based on his last comment in the bug there might be some work happening there. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Tue Sep 10 16:31:37 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 10 Sep 2013 19:31:37 +0300 Subject: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created In-Reply-To: <1378579277.2804.1360.camel@willson.li.ssimo.org> References: <20130905144406.GO21212@redhat.com> <1378565247.2804.1125.camel@willson.li.ssimo.org> <20130907180158.GU21212@redhat.com> <1378578185.2804.1353.camel@willson.li.ssimo.org> <20130907183259.GV21212@redhat.com> <1378579277.2804.1360.camel@willson.li.ssimo.org> Message-ID: <20130910163137.GA21212@redhat.com> On Sat, 07 Sep 2013, Simo Sorce wrote: >On Sat, 2013-09-07 at 21:32 +0300, Alexander Bokovoy wrote: >> On Sat, 07 Sep 2013, Simo Sorce wrote: >> >On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: >> >> On Sat, 07 Sep 2013, Simo Sorce wrote: >> >> >On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: >> >> >> + enctypes = KERB_ENCTYPE_DES_CBC_CRC | >> >> >> + KERB_ENCTYPE_DES_CBC_MD5 | >> >> >> + KERB_ENCTYPE_RC4_HMAC_MD5 | >> >> >> + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | >> >> >> + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; >> >> > >> >> >Why are we hardcoding support for *DES* enctype, we disable DES by >> >> >default and also Windows never uses it by default. >> >> This is actually a copy of the same statement from >> >> fill_pdb_trusted_domain(). >> >> >> >> Should I remove it? >> > >> >Yes please remove DES types, is there any chance we can make this list >> >configurable ? (not a hard requirement, only if ti is something easy to >> >do, maybe as a further enhancement down the road). >> If you can point me to some place in cn=config or $SUFFIX that could be >> read by cifs/fqdn on ipa-sam module init, I can look in fetching that. >> But I suspect it is much harder to deduce exact list of supported types. > >Look in: >cn=REALM.NAME,cn=kerberos,$SUFFIX > >there we have 2 lists: >krbDefaultEncSaltTypes <- use this >krbSupportedEncSaltTypes > >in util/ipa_krb5.c we have then the funciton parse_bval_key_sal_tuples() >that can covert strings to enctypes. > >> >> RC4 enctype will be the only one available for >> >> Windows 2003 trusts then... >> > >> >It's the only one 2003 enables by default anyway and the only one that >> >we can use as DES is disabled on FreeIPA. >> Since admin could enable DES on FreeIPA manually, right now ipa-sam >> would allow using DES to Windows 2003. If we remove DES enctypes >> unconditionally, it would not be possible. > >If you look at the attributes I pointed you at above, then you have a >way to support DES by simply changing the defaults and restarting >FreeIPA. > >DES is dead anyway and not sufficiently secure for cross-realm keys >anymore, even if we do not support it at all I think we are just fine. Ok, attached three patches 0114-0116 is a new revision that implements also fetching encryption types from the Kerberos configuration container. The patches depend on each other in that order. -- / Alexander Bokovoy -------------- next part -------------- From 875c3f5dff578962352fe3673b3a6bcf82014976 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 5 Sep 2013 08:13:53 +0300 Subject: [PATCH 1/3] ipa-sam: do not modify objectclass when trust object already created When trust is established, last step done by IPA framework is to set encryption types associated with the trust. This operation fails due to ipa-sam attempting to modify object classes in trust object entry which is not allowed by ACI. Additionally, wrong handle was used by dcerpc.py code when executing SetInformationTrustedDomain() against IPA smbd which prevented even to reach the point where ipa-sam would be asked to modify the trust object. --- daemons/ipa-sam/ipa_sam.c | 112 +++++++++++++++++++++++++-------------- install/updates/60-trusts.update | 1 + ipaserver/dcerpc.py | 9 ++++ 3 files changed, 81 insertions(+), 41 deletions(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 4a2fca5..cf39bb9 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -2229,11 +2229,14 @@ static NTSTATUS ipasam_set_trusted_domain(struct pdb_methods *methods, LDAPMod **mods; bool res; char *trusted_dn = NULL; - int ret, i; + int ret, i, count; NTSTATUS status; TALLOC_CTX *tmp_ctx; char *trustpw; char *sid; + char **in_blacklist = NULL; + char **out_blacklist = NULL; + uint32_t enctypes, trust_offset; DEBUG(10, ("ipasam_set_trusted_domain called for domain %s\n", domain)); @@ -2250,10 +2253,12 @@ static NTSTATUS ipasam_set_trusted_domain(struct pdb_methods *methods, } mods = NULL; - smbldap_make_mod(priv2ld(ldap_state), entry, &mods, "objectClass", - LDAP_OBJ_TRUSTED_DOMAIN); - smbldap_make_mod(priv2ld(ldap_state), entry, &mods, "objectClass", - LDAP_OBJ_ID_OBJECT); + if (entry == NULL) { + smbldap_make_mod(priv2ld(ldap_state), entry, &mods, "objectClass", + LDAP_OBJ_TRUSTED_DOMAIN); + smbldap_make_mod(priv2ld(ldap_state), entry, &mods, "objectClass", + LDAP_OBJ_ID_OBJECT); + } if (entry != NULL) { sid = get_single_attribute(tmp_ctx, priv2ld(ldap_state), entry, @@ -2314,26 +2319,37 @@ static NTSTATUS ipasam_set_trusted_domain(struct pdb_methods *methods, } } + trust_offset = 0; if (td->trust_posix_offset != NULL) { - res = smbldap_make_mod_uint32_t(priv2ld(ldap_state), entry, - &mods, - LDAP_ATTRIBUTE_TRUST_POSIX_OFFSET, - *td->trust_posix_offset); - if (!res) { - status = NT_STATUS_UNSUCCESSFUL; - goto done; - } + trust_offset = *td->trust_posix_offset; } + res = smbldap_make_mod_uint32_t(priv2ld(ldap_state), entry, + &mods, + LDAP_ATTRIBUTE_TRUST_POSIX_OFFSET, + trust_offset); + if (!res) { + status = NT_STATUS_UNSUCCESSFUL; + goto done; + } + + enctypes = KERB_ENCTYPE_DES_CBC_CRC | + KERB_ENCTYPE_DES_CBC_MD5 | + KERB_ENCTYPE_RC4_HMAC_MD5 | + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; + if (td->supported_enc_type != NULL) { - res = smbldap_make_mod_uint32_t(priv2ld(ldap_state), entry, - &mods, - LDAP_ATTRIBUTE_SUPPORTED_ENC_TYPE, - *td->supported_enc_type); - if (!res) { - status = NT_STATUS_UNSUCCESSFUL; - goto done; - } + enctypes = *td->supported_enc_type; + } + + res = smbldap_make_mod_uint32_t(priv2ld(ldap_state), entry, + &mods, + LDAP_ATTRIBUTE_SUPPORTED_ENC_TYPE, + enctypes); + if (!res) { + status = NT_STATUS_UNSUCCESSFUL; + goto done; } if (td->trust_auth_outgoing.data != NULL) { @@ -2354,31 +2370,45 @@ static NTSTATUS ipasam_set_trusted_domain(struct pdb_methods *methods, &td->trust_forest_trust_info); } + + /* Only add default blacklists for incoming and outgoing SIDs but don't modify existing ones */ + in_blacklist = get_attribute_values(tmp_ctx, ldap_state->smbldap_state->ldap_struct, entry, + LDAP_ATTRIBUTE_SID_BLACKLIST_INCOMING, &count); + out_blacklist = get_attribute_values(tmp_ctx, ldap_state->smbldap_state->ldap_struct, entry, + LDAP_ATTRIBUTE_SID_BLACKLIST_OUTGOING, &count); + for (i = 0; ipa_mspac_well_known_sids[i]; i++) { - smbldap_make_mod(priv2ld(ldap_state), entry, &mods, - LDAP_ATTRIBUTE_SID_BLACKLIST_INCOMING, - ipa_mspac_well_known_sids[i]); - smbldap_make_mod(priv2ld(ldap_state), entry, &mods, - LDAP_ATTRIBUTE_SID_BLACKLIST_OUTGOING, - ipa_mspac_well_known_sids[i]); + if (in_blacklist == NULL) { + smbldap_make_mod(priv2ld(ldap_state), entry, &mods, + LDAP_ATTRIBUTE_SID_BLACKLIST_INCOMING, + ipa_mspac_well_known_sids[i]); + } + if (out_blacklist == NULL) { + smbldap_make_mod(priv2ld(ldap_state), entry, &mods, + LDAP_ATTRIBUTE_SID_BLACKLIST_OUTGOING, + ipa_mspac_well_known_sids[i]); + } } smbldap_talloc_autofree_ldapmod(tmp_ctx, mods); - trusted_dn = trusted_domain_dn(tmp_ctx, ldap_state, domain); - if (trusted_dn == NULL) { - status = NT_STATUS_NO_MEMORY; - goto done; - } - if (entry == NULL) { - ret = smbldap_add(ldap_state->smbldap_state, trusted_dn, mods); - } else { - ret = smbldap_modify(ldap_state->smbldap_state, trusted_dn, mods); - } - if (ret != LDAP_SUCCESS) { - DEBUG(1, ("error writing trusted domain data!\n")); - status = NT_STATUS_UNSUCCESSFUL; - goto done; + if (mods != NULL) { + trusted_dn = trusted_domain_dn(tmp_ctx, ldap_state, domain); + if (trusted_dn == NULL) { + status = NT_STATUS_NO_MEMORY; + goto done; + } + + if (entry == NULL) { + ret = smbldap_add(ldap_state->smbldap_state, trusted_dn, mods); + } else { + ret = smbldap_modify(ldap_state->smbldap_state, trusted_dn, mods); + } + if (ret != LDAP_SUCCESS) { + DEBUG(1, ("error writing trusted domain data!\n")); + status = NT_STATUS_UNSUCCESSFUL; + goto done; + } } if (entry == NULL) { /* FIXME: allow password updates here */ diff --git a/install/updates/60-trusts.update b/install/updates/60-trusts.update index 1b25115..46de01a 100644 --- a/install/updates/60-trusts.update +++ b/install/updates/60-trusts.update @@ -54,6 +54,7 @@ default: cn: trusts # 2. cn=trust admins,cn=groups,cn=accounts,$SUFFIX can manage trusts (via ipa tools) dn: cn=trusts,$SUFFIX add:aci: '(target = "ldap:///cn=trusts,$SUFFIX")(targetattr = "ipaNTTrustType || ipaNTTrustAttributes || ipaNTTrustDirection || ipaNTTrustPartner || ipaNTFlatName || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming || ipaNTSecurityIdentifier || ipaNTTrustForestTrustInfo || ipaNTTrustPosixOffset || ipaNTSupportedEncryptionTypes || krbPrincipalName || krbLastPwdChange || krbTicketFlags || krbLoginFailedCount || krbExtraData || krbPrincipalKey")(version 3.0;acl "Allow trust system user to create and delete trust accounts and cross realm principals"; allow (read,write,add,delete) groupdn="ldap:///cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX";)' +replace:aci:'(target = "ldap:///cn=trusts,$SUFFIX")(targetattr = "ipaNTTrustType || ipaNTTrustAttributes || ipaNTTrustDirection || ipaNTTrustPartner || ipaNTFlatName || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming || ipaNTSecurityIdentifier || ipaNTTrustForestTrustInfo || ipaNTTrustPosixOffset || ipaNTSupportedEncryptionTypes || krbPrincipalName || krbLastPwdChange || krbTicketFlags || krbLoginFailedCount || krbExtraData || krbPrincipalKey")(version 3.0;acl "Allow trust system user to create and delete trust accounts and cross realm principals"; allow (read,write,add,delete) groupdn="ldap:///cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX";)::(target = "ldap:///cn=trusts,$SUFFIX")(targetattr = "ipaNTTrustType || ipaNTTrustAttributes || ipaNTTrustDirection || ipaNTTrustPartner || ipaNTFlatName || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming || ipaNTSecurityIdentifier || ipaNTTrustForestTrustInfo || ipaNTTrustPosixOffset || ipaNTSupportedEncryptionTypes || ipaNTSIDBlacklistIncoming || ipaNTSIDBlacklistOutgoing || krbPrincipalName || krbLastPwdChange || krbTicketFlags || krbLoginFailedCount || krbExtraData || krbPrincipalKey")(version 3.0;acl "Allow trust system user to create and delete trust accounts and cross realm principals"; allow (read,write,add,delete) groupdn="ldap:///cn=adtrust agents,cn=sysaccounts,cn=etc,$SUFFIX";)' replace:aci:'(target = "ldap:///cn=trusts,$SUFFIX")(targetattr = "ipaNTTrustType || ipaNTTrustAttributes || ipaNTTrustDirection || ipaNTTrustPartner || ipaNTFlatName || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming || ipaNTSecurityIdentifier || ipaNTTrustForestTrustInfo || ipaNTTrustPosixOffset || ipaNTSupportedEncryptionTypes")(version 3.0;acl "Allow trust admins manage trust accounts"; allow (read,write,add,delete) groupdn="ldap:///cn=trust admins,cn=groups,cn=accounts,$SUFFIX";)::(target = "ldap:///cn=trusts,$SUFFIX")(targetattr = "ipaNTTrustType || ipaNTTrustAttributes || ipaNTTrustDirection || ipaNTTrustPartner || ipaNTFlatName || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming || ipaNTSecurityIdentifier || ipaNTTrustForestTrustInfo || ipaNTTrustPosixOffset || ipaNTSupportedEncryptionTypes || ipaNTSIDBlacklistIncoming || ipaNTSIDBlacklistOutgoing")(version 3.0;acl "Allow trust admins manage trust accounts"; allow (read,write,add,delete) groupdn="ldap:///cn=trust admins,cn=groups,cn=accounts,$SUFFIX";)' add:aci: '(target = "ldap:///cn=trusts,$SUFFIX")(targetattr = "ipaNTTrustType || ipaNTTrustAttributes || ipaNTTrustDirection || ipaNTTrustPartner || ipaNTFlatName || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming || ipaNTSecurityIdentifier || ipaNTTrustForestTrustInfo || ipaNTTrustPosixOffset || ipaNTSupportedEncryptionTypes || ipaNTSIDBlacklistIncoming || ipaNTSIDBlacklistOutgoing")(version 3.0;acl "Allow trust admins manage trust accounts"; allow (read,write,add,delete) groupdn="ldap:///cn=trust admins,cn=groups,cn=accounts,$SUFFIX";)' diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index a27a64d..bd8f5aa 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -912,12 +912,21 @@ class TrustDomainInstance(object): raise assess_dcerpc_exception(num=num, message=message) try: + # We should use proper trustdom handle in order to modify the + # trust settings. Samba insists this has to be done with LSA + # OpenTrustedDomain* calls, it is not enough to have a handle + # returned by the CreateTrustedDomainEx2 call. + trustdom_handle = self._pipe.OpenTrustedDomainByName(self._policy_handle, dname, security.SEC_FLAG_MAXIMUM_ALLOWED) infoclass = lsa.TrustDomainInfoSupportedEncTypes() infoclass.enc_types = security.KERB_ENCTYPE_RC4_HMAC_MD5 infoclass.enc_types |= security.KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 infoclass.enc_types |= security.KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96 self._pipe.SetInformationTrustedDomain(trustdom_handle, lsa.LSA_TRUSTED_DOMAIN_SUPPORTED_ENCRYPTION_TYPES, infoclass) except RuntimeError, e: + # We can ignore the error here -- changing enctypes is for + # improved security but the trust will work with default values as + # well. In particular, the call may fail against Windows 2003 + # server as that one doesn't support AES encryption types pass def verify_trust(self, another_domain): -- 1.8.3.1 -------------- next part -------------- >From 4bd9901d0e3336dcd7e19e2b426ad0140ca3efb5 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 9 Sep 2013 15:52:17 +0300 Subject: [PATCH 2/3] ipa-sam: do not leak LDAPMessage on ipa-sam initialization We used to handle some of code paths to free memory allocated by the LDAP library but there are few more unhandled. In addition, search result wasn't freed on successful initialization, leaking for long time. https://fedorahosted.org/freeipa/ticket/3913 --- daemons/ipa-sam/ipa_sam.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index cf39bb9..b4d1a32 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -4273,6 +4273,7 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, if (ldap_state->ipasam_privates->flat_name == NULL) { DEBUG(0, ("Missing mandatory attribute %s.\n", LDAP_ATTRIBUTE_FLAT_NAME)); + ldap_msgfree(result); return NT_STATUS_INVALID_PARAMETER; } @@ -4280,8 +4281,9 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, idmap_talloc_free, &ldap_state->ipasam_privates->idmap_ctx); if (err != IDMAP_SUCCESS) { - DEBUG(1, ("Failed to setup idmap context.\n")); - return NT_STATUS_UNSUCCESSFUL; + DEBUG(1, ("Failed to setup idmap context.\n")); + ldap_msgfree(result); + return NT_STATUS_UNSUCCESSFUL; } fallback_group_sid = get_fallback_group_sid(ldap_state, @@ -4290,6 +4292,7 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, result); if (fallback_group_sid == NULL) { DEBUG(0, ("Cannot find SID of fallback group.\n")); + ldap_msgfree(result); return NT_STATUS_INVALID_PARAMETER; } sid_copy(&ldap_state->ipasam_privates->fallback_primary_group, @@ -4319,10 +4322,12 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, status = save_sid_to_secret(ldap_state); if (!NT_STATUS_IS_OK(status)) { + ldap_msgfree(result); return status; } } + ldap_msgfree(result); (*pdb_method)->getsampwnam = ldapsam_getsampwnam; (*pdb_method)->search_users = ldapsam_search_users; (*pdb_method)->search_groups = ldapsam_search_groups; -- 1.8.3.1 -------------- next part -------------- >From 450ea23bc89b9614a50a093f876903c3a6a92701 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 10 Sep 2013 11:56:40 +0300 Subject: [PATCH 3/3] ipa-sam: report supported enctypes based on Kerberos realm configuration We store Kerberos realm configuration in cn=REALM,cn=kerberos,$SUFFIX. Along other configuration options, this container has list of default supported encryption types, in krbDefaultEncSaltTypes. Fetch krbDefaultEncSaltTypes value on ipa-sam initialization and convert discovered list to the mask of supported encryption types according to security.idl from Samba: typedef [public,bitmap32bit] bitmap { KERB_ENCTYPE_DES_CBC_CRC = 0x00000001, KERB_ENCTYPE_DES_CBC_MD5 = 0x00000002, KERB_ENCTYPE_RC4_HMAC_MD5 = 0x00000004, KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 = 0x00000008, KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96 = 0x00000010 } kerb_EncTypes; Part of https://fedorahosted.org/freeipa/ticket/3898 --- daemons/ipa-sam/ipa_sam.c | 129 +++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 117 insertions(+), 12 deletions(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index b4d1a32..a535c0f 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -170,6 +170,7 @@ struct ipasam_privates { char *server_princ; char *client_princ; struct sss_idmap_ctx *idmap_ctx; + uint32_t supported_enctypes; }; @@ -2062,11 +2063,7 @@ static bool fill_pdb_trusted_domain(TALLOC_CTX *mem_ctx, return false; } if (*td->supported_enc_type == 0) { - *td->supported_enc_type = KERB_ENCTYPE_DES_CBC_CRC | - KERB_ENCTYPE_DES_CBC_MD5 | - KERB_ENCTYPE_RC4_HMAC_MD5 | - KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | - KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; + *td->supported_enc_type = ldap_state->ipasam_privates->supported_enctypes; } if (!smbldap_talloc_single_blob(td, priv2ld(ldap_state), entry, @@ -2333,12 +2330,7 @@ static NTSTATUS ipasam_set_trusted_domain(struct pdb_methods *methods, goto done; } - enctypes = KERB_ENCTYPE_DES_CBC_CRC | - KERB_ENCTYPE_DES_CBC_MD5 | - KERB_ENCTYPE_RC4_HMAC_MD5 | - KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | - KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; - + enctypes = ldap_state->ipasam_privates->supported_enctypes; if (td->supported_enc_type != NULL) { enctypes = *td->supported_enc_type; } @@ -3606,6 +3598,106 @@ static NTSTATUS ipasam_get_domain_name(struct ldapsam_privates *ldap_state, return NT_STATUS_OK; } +static NTSTATUS ipasam_get_enctypes(struct ldapsam_privates *ldap_state, + TALLOC_CTX *mem_ctx, + uint32_t *enctypes) +{ + int ret; + LDAPMessage *result; + LDAPMessage *entry = NULL; + int count, i; + char **enctype_list, *dn; + krb5_enctype enctype; + krb5_error_code err; + struct smbldap_state *smbldap_state = ldap_state->smbldap_state; + const char *attr_list[] = { + "krbDefaultEncSaltTypes", + NULL + }; + + dn = talloc_asprintf(mem_ctx, "cn=%s,cn=kerberos,%s", + ldap_state->ipasam_privates->realm, + ldap_state->ipasam_privates->base_dn); + + if (dn == NULL) { + DEBUG(1, ("Failed to construct DN to the realm's kerberos container\n")); + return NT_STATUS_UNSUCCESSFUL; + } + + ret = smbldap_search(smbldap_state, dn, LDAP_SCOPE_BASE, + "objectclass=krbrealmcontainer", attr_list, 0, + &result); + if (ret != LDAP_SUCCESS) { + DEBUG(1, ("Failed to get kerberos realm encryption types: %s\n", + ldap_err2string (ret))); + talloc_free(dn); + return NT_STATUS_UNSUCCESSFUL; + } + + count = ldap_count_entries(smbldap_state->ldap_struct, result); + + if (count != 1) { + DEBUG(1, ("Unexpected number of results [%d] for realm " + "search.\n", count)); + ldap_msgfree(result); + talloc_free(dn); + return NT_STATUS_UNSUCCESSFUL; + } + + entry = ldap_first_entry(smbldap_state->ldap_struct, result); + if (entry == NULL) { + DEBUG(0, ("Could not get krbrealmcontainer entry\n")); + ldap_msgfree(result); + talloc_free(dn); + return NT_STATUS_UNSUCCESSFUL; + } + + enctype_list = get_attribute_values(dn, smbldap_state->ldap_struct, entry, + "krbDefaultEncSaltTypes", &count); + ldap_msgfree(result); + if (enctype_list == NULL) { + talloc_free(dn); + return NT_STATUS_UNSUCCESSFUL; + } + + *enctypes = 0; + for (i = 0; i < count ; i++) { + char *enc = strchr(enctype_list[i], ':'); + if (enc != NULL) { + *enc = '\0'; + } + err = krb5_string_to_enctype(enctype_list[i], &enctype); + if (enc != NULL) { + *enc = ':'; + } + if (err) { + continue; + } + switch (enctype) { + case ENCTYPE_DES_CBC_CRC: + *enctypes |= KERB_ENCTYPE_DES_CBC_CRC; + break; + case ENCTYPE_DES_CBC_MD5: + *enctypes |= KERB_ENCTYPE_DES_CBC_MD5; + break; + case ENCTYPE_ARCFOUR_HMAC: + *enctypes |= KERB_ENCTYPE_RC4_HMAC_MD5; + break; + case ENCTYPE_AES128_CTS_HMAC_SHA1_96: + *enctypes |= KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96; + break; + case ENCTYPE_AES256_CTS_HMAC_SHA1_96: + *enctypes |= KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; + break; + default: + break; + } + } + + talloc_free(dn); + return NT_STATUS_OK; +} + static NTSTATUS ipasam_get_realm(struct ldapsam_privates *ldap_state, TALLOC_CTX *mem_ctx, char **realm) @@ -4135,7 +4227,6 @@ done: return status; } - static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, const char *location) { @@ -4151,6 +4242,7 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, LDAPMessage *result = NULL; LDAPMessage *entry = NULL; enum idmap_error_code err; + uint32_t enctypes = 0; status = make_pdb_method(pdb_method); if (!NT_STATUS_IS_OK(status)) { @@ -4328,6 +4420,19 @@ static NTSTATUS pdb_init_ipasam(struct pdb_methods **pdb_method, } ldap_msgfree(result); + + status = ipasam_get_enctypes(ldap_state, + ldap_state->ipasam_privates, + &enctypes); + + if (!NT_STATUS_IS_OK(status)) { + enctypes = KERB_ENCTYPE_RC4_HMAC_MD5 | + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; + } + + ldap_state->ipasam_privates->supported_enctypes = enctypes; + (*pdb_method)->getsampwnam = ldapsam_getsampwnam; (*pdb_method)->search_users = ldapsam_search_users; (*pdb_method)->search_groups = ldapsam_search_groups; -- 1.8.3.1 From simo at redhat.com Tue Sep 10 19:12:29 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 10 Sep 2013 15:12:29 -0400 Subject: [Freeipa-devel] [PATCH] #3901 Message-ID: <1378840349.2804.1572.camel@willson.li.ssimo.org> I think the attached (untested) patch should solve the issue. Is it sufficient or do we want to change framework code somehow ? Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-krbticketPolicyAux-objectclass-if-needed.patch Type: text/x-patch Size: 2957 bytes Desc: not available URL: From jpazdziora at redhat.com Wed Sep 11 07:39:00 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 11 Sep 2013 15:39:00 +0800 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <522F3661.4030205@redhat.com> References: <52161568.7060702@redhat.com> <522D920E.4040703@redhat.com> <522DD50A.9090606@redhat.com> <522DDD94.1050000@redhat.com> <522DDDE3.3030308@redhat.com> <1378742085.2804.1451.camel@willson.li.ssimo.org> <522ED8BF.1000602@redhat.com> <1378817385.2804.1534.camel@willson.li.ssimo.org> <522F3661.4030205@redhat.com> Message-ID: <20130911073859.GF31208@redhat.com> On Tue, Sep 10, 2013 at 11:10:25AM -0400, Dmitri Pal wrote: > > > > Regarding SNI, it apparently is not supported in server-side NSS > > (https://bugzilla.mozilla.org/show_bug.cgi?id=360421) > > We need to either push for a solution to this or allow to switch to > > mod_ssl. > > Jan Pazdziora investigated us switching to mod_ssl. It is not trivial. But to achieve the basic functionality, it was not awfully hard either: https://wiki.idm.lab.bos.redhat.com/export/idmwiki/IPA/Integration/mod_nss_ssl -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From pvoborni at redhat.com Wed Sep 11 10:44:53 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 11 Sep 2013 12:44:53 +0200 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation Message-ID: <523049A5.10208@redhat.com> Hello, This is a part of documentation effort which started couple month ago. Attached patches improves devel documentation of Web UI. Mostly by annotating source code and then processing it by JSDuck tool[1]. The documentation is not complete - most plugins and member of some core widgets and facets are not annotated yet. I'm sending it now because I need to focus on more pressing tickets. You can see current state at my fedorapeople page [2]. I also converted 5 guides/articles which I wrote some time ago. Guides are also part of the JSDuck app [3]. The idea is to regularly generate the doc and place it on docs.freeipa.org (not in production at the moment) so all doc would be on one place. Installation of JSDuck is documented on their page [4]. Basically it requires ruby and JSDuck gem. Usage: $ cd install/ui/doc $ make Documentation is generated into: install/ui/build/code_doc directory [1] https://github.com/senchalabs/jsduck [2] http://pvoborni.fedorapeople.org/doc [3] http://pvoborni.fedorapeople.org/doc/#!/guide [4] https://github.com/senchalabs/jsduck/wiki/Installation -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0451-Removal-of-unused-code.patch Type: text/x-patch Size: 1211 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0452-Web-UI-source-code-annotation.patch Type: text/x-patch Size: 316040 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0453-Configuration-for-JSDuck-documentation-generator.patch Type: text/x-patch Size: 9529 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0454-Phases-Guide.patch Type: text/x-patch Size: 9671 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0455-Debugging-Web-UI-guide.patch Type: text/x-patch Size: 6324 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0456-Plugin-Infrastructure-Guide.patch Type: text/x-patch Size: 5022 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0457-Navigation-Guide.patch Type: text/x-patch Size: 15630 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0458-Registries-and-Build-Guide.patch Type: text/x-patch Size: 12664 bytes Desc: not available URL: From simo at redhat.com Wed Sep 11 13:51:42 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Sep 2013 09:51:42 -0400 Subject: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created In-Reply-To: <20130910163137.GA21212@redhat.com> References: <20130905144406.GO21212@redhat.com> <1378565247.2804.1125.camel@willson.li.ssimo.org> <20130907180158.GU21212@redhat.com> <1378578185.2804.1353.camel@willson.li.ssimo.org> <20130907183259.GV21212@redhat.com> <1378579277.2804.1360.camel@willson.li.ssimo.org> <20130910163137.GA21212@redhat.com> Message-ID: <1378907502.2804.1589.camel@willson.li.ssimo.org> On Tue, 2013-09-10 at 19:31 +0300, Alexander Bokovoy wrote: > On Sat, 07 Sep 2013, Simo Sorce wrote: > >On Sat, 2013-09-07 at 21:32 +0300, Alexander Bokovoy wrote: > >> On Sat, 07 Sep 2013, Simo Sorce wrote: > >> >On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: > >> >> On Sat, 07 Sep 2013, Simo Sorce wrote: > >> >> >On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: > >> >> >> + enctypes = KERB_ENCTYPE_DES_CBC_CRC | > >> >> >> + KERB_ENCTYPE_DES_CBC_MD5 | > >> >> >> + KERB_ENCTYPE_RC4_HMAC_MD5 | > >> >> >> + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | > >> >> >> + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; > >> >> > > >> >> >Why are we hardcoding support for *DES* enctype, we disable DES by > >> >> >default and also Windows never uses it by default. > >> >> This is actually a copy of the same statement from > >> >> fill_pdb_trusted_domain(). > >> >> > >> >> Should I remove it? > >> > > >> >Yes please remove DES types, is there any chance we can make this list > >> >configurable ? (not a hard requirement, only if ti is something easy to > >> >do, maybe as a further enhancement down the road). > >> If you can point me to some place in cn=config or $SUFFIX that could be > >> read by cifs/fqdn on ipa-sam module init, I can look in fetching that. > >> But I suspect it is much harder to deduce exact list of supported types. > > > >Look in: > >cn=REALM.NAME,cn=kerberos,$SUFFIX > > > >there we have 2 lists: > >krbDefaultEncSaltTypes <- use this > >krbSupportedEncSaltTypes > > > >in util/ipa_krb5.c we have then the funciton parse_bval_key_sal_tuples() > >that can covert strings to enctypes. > > > >> >> RC4 enctype will be the only one available for > >> >> Windows 2003 trusts then... > >> > > >> >It's the only one 2003 enables by default anyway and the only one that > >> >we can use as DES is disabled on FreeIPA. > >> Since admin could enable DES on FreeIPA manually, right now ipa-sam > >> would allow using DES to Windows 2003. If we remove DES enctypes > >> unconditionally, it would not be possible. > > > >If you look at the attributes I pointed you at above, then you have a > >way to support DES by simply changing the defaults and restarting > >FreeIPA. > > > >DES is dead anyway and not sufficiently secure for cross-realm keys > >anymore, even if we do not support it at all I think we are just fine. > Ok, attached three patches 0114-0116 is a new revision that implements also > fetching encryption types from the Kerberos configuration container. > > The patches depend on each other in that order. > I think you should explictly add cn= to the filter when seraching the kerberos container in the 3rd patch. But beyond that the patches look sane to me (I haven't tested them though). Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Sep 11 16:28:00 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 11 Sep 2013 12:28:00 -0400 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <523049A5.10208@redhat.com> References: <523049A5.10208@redhat.com> Message-ID: <1378916880.2804.1612.camel@willson.li.ssimo.org> On Wed, 2013-09-11 at 12:44 +0200, Petr Vobornik wrote: > Hello, > > This is a part of documentation effort which started couple month > ago. > Attached patches improves devel documentation of Web UI. Mostly by > annotating source code and then processing it by JSDuck tool[1]. > > The documentation is not complete - most plugins and member of some > core > widgets and facets are not annotated yet. I'm sending it now because > I > need to focus on more pressing tickets. > > You can see current state at my fedorapeople page [2]. > > I also converted 5 guides/articles which I wrote some time ago. > Guides > are also part of the JSDuck app [3]. > > The idea is to regularly generate the doc and place it on > docs.freeipa.org (not in production at the moment) so all doc would > be > on one place. > > Installation of JSDuck is documented on their page [4]. Basically it > requires ruby and JSDuck gem. > > Usage: > $ cd install/ui/doc > $ make > > Documentation is generated into: install/ui/build/code_doc directory > > [1] https://github.com/senchalabs/jsduck > [2] http://pvoborni.fedorapeople.org/doc > [3] http://pvoborni.fedorapeople.org/doc/#!/guide > [4] https://github.com/senchalabs/jsduck/wiki/Installation I would rather not grow a dependency on Ruby in the freeIPA project. Are there any alternatives ? Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Wed Sep 11 19:12:34 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 11 Sep 2013 22:12:34 +0300 Subject: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created In-Reply-To: <1378907502.2804.1589.camel@willson.li.ssimo.org> References: <20130905144406.GO21212@redhat.com> <1378565247.2804.1125.camel@willson.li.ssimo.org> <20130907180158.GU21212@redhat.com> <1378578185.2804.1353.camel@willson.li.ssimo.org> <20130907183259.GV21212@redhat.com> <1378579277.2804.1360.camel@willson.li.ssimo.org> <20130910163137.GA21212@redhat.com> <1378907502.2804.1589.camel@willson.li.ssimo.org> Message-ID: <20130911191234.GH21212@redhat.com> On Wed, 11 Sep 2013, Simo Sorce wrote: >On Tue, 2013-09-10 at 19:31 +0300, Alexander Bokovoy wrote: >> On Sat, 07 Sep 2013, Simo Sorce wrote: >> >On Sat, 2013-09-07 at 21:32 +0300, Alexander Bokovoy wrote: >> >> On Sat, 07 Sep 2013, Simo Sorce wrote: >> >> >On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: >> >> >> On Sat, 07 Sep 2013, Simo Sorce wrote: >> >> >> >On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: >> >> >> >> + enctypes = KERB_ENCTYPE_DES_CBC_CRC | >> >> >> >> + KERB_ENCTYPE_DES_CBC_MD5 | >> >> >> >> + KERB_ENCTYPE_RC4_HMAC_MD5 | >> >> >> >> + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | >> >> >> >> + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; >> >> >> > >> >> >> >Why are we hardcoding support for *DES* enctype, we disable DES by >> >> >> >default and also Windows never uses it by default. >> >> >> This is actually a copy of the same statement from >> >> >> fill_pdb_trusted_domain(). >> >> >> >> >> >> Should I remove it? >> >> > >> >> >Yes please remove DES types, is there any chance we can make this list >> >> >configurable ? (not a hard requirement, only if ti is something easy to >> >> >do, maybe as a further enhancement down the road). >> >> If you can point me to some place in cn=config or $SUFFIX that could be >> >> read by cifs/fqdn on ipa-sam module init, I can look in fetching that. >> >> But I suspect it is much harder to deduce exact list of supported types. >> > >> >Look in: >> >cn=REALM.NAME,cn=kerberos,$SUFFIX >> > >> >there we have 2 lists: >> >krbDefaultEncSaltTypes <- use this >> >krbSupportedEncSaltTypes >> > >> >in util/ipa_krb5.c we have then the funciton parse_bval_key_sal_tuples() >> >that can covert strings to enctypes. >> > >> >> >> RC4 enctype will be the only one available for >> >> >> Windows 2003 trusts then... >> >> > >> >> >It's the only one 2003 enables by default anyway and the only one that >> >> >we can use as DES is disabled on FreeIPA. >> >> Since admin could enable DES on FreeIPA manually, right now ipa-sam >> >> would allow using DES to Windows 2003. If we remove DES enctypes >> >> unconditionally, it would not be possible. >> > >> >If you look at the attributes I pointed you at above, then you have a >> >way to support DES by simply changing the defaults and restarting >> >FreeIPA. >> > >> >DES is dead anyway and not sufficiently secure for cross-realm keys >> >anymore, even if we do not support it at all I think we are just fine. >> Ok, attached three patches 0114-0116 is a new revision that implements also >> fetching encryption types from the Kerberos configuration container. >> >> The patches depend on each other in that order. >> > >I think you should explictly add cn= to the filter when >seraching the kerberos container in the 3rd patch. >But beyond that the patches look sane to me (I haven't tested them >though). I'm already searching on cn=,cn=kerberos,$SUFFIX with a base scope so this is pretty tight, no need to expand the filter. (Simo agreed to this argument on IRC) -- / Alexander Bokovoy From dpal at redhat.com Wed Sep 11 21:24:40 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Sep 2013 17:24:40 -0400 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <1378916880.2804.1612.camel@willson.li.ssimo.org> References: <523049A5.10208@redhat.com> <1378916880.2804.1612.camel@willson.li.ssimo.org> Message-ID: <5230DF98.1040501@redhat.com> On 09/11/2013 12:28 PM, Simo Sorce wrote: > On Wed, 2013-09-11 at 12:44 +0200, Petr Vobornik wrote: >> Hello, >> >> This is a part of documentation effort which started couple month >> ago. >> Attached patches improves devel documentation of Web UI. Mostly by >> annotating source code and then processing it by JSDuck tool[1]. >> >> The documentation is not complete - most plugins and member of some >> core >> widgets and facets are not annotated yet. I'm sending it now because >> I >> need to focus on more pressing tickets. >> >> You can see current state at my fedorapeople page [2]. >> >> I also converted 5 guides/articles which I wrote some time ago. >> Guides >> are also part of the JSDuck app [3]. >> >> The idea is to regularly generate the doc and place it on >> docs.freeipa.org (not in production at the moment) so all doc would >> be >> on one place. >> >> Installation of JSDuck is documented on their page [4]. Basically it >> requires ruby and JSDuck gem. >> >> Usage: >> $ cd install/ui/doc >> $ make >> >> Documentation is generated into: install/ui/build/code_doc directory >> >> [1] https://github.com/senchalabs/jsduck >> [2] http://pvoborni.fedorapeople.org/doc >> [3] http://pvoborni.fedorapeople.org/doc/#!/guide >> [4] https://github.com/senchalabs/jsduck/wiki/Installation > > I would rather not grow a dependency on Ruby in the freeIPA project. > Are there any alternatives ? > > Simo. > Is it dev side dependency? We might have issues if we need gems during build process that are not a part of distro. -- 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 Thu Sep 12 05:50:52 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Sep 2013 07:50:52 +0200 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <5230DF98.1040501@redhat.com> References: <523049A5.10208@redhat.com> <1378916880.2804.1612.camel@willson.li.ssimo.org> <5230DF98.1040501@redhat.com> Message-ID: <5231563C.8090203@redhat.com> On 09/11/2013 11:24 PM, Dmitri Pal wrote: > On 09/11/2013 12:28 PM, Simo Sorce wrote: >> On Wed, 2013-09-11 at 12:44 +0200, Petr Vobornik wrote: >>> Hello, >>> >>> This is a part of documentation effort which started couple month >>> ago. >>> Attached patches improves devel documentation of Web UI. Mostly by >>> annotating source code and then processing it by JSDuck tool[1]. >>> >>> The documentation is not complete - most plugins and member of some >>> core >>> widgets and facets are not annotated yet. I'm sending it now because >>> I >>> need to focus on more pressing tickets. >>> >>> You can see current state at my fedorapeople page [2]. >>> >>> I also converted 5 guides/articles which I wrote some time ago. >>> Guides >>> are also part of the JSDuck app [3]. >>> >>> The idea is to regularly generate the doc and place it on >>> docs.freeipa.org (not in production at the moment) so all doc would >>> be >>> on one place. >>> >>> Installation of JSDuck is documented on their page [4]. Basically it >>> requires ruby and JSDuck gem. >>> >>> Usage: >>> $ cd install/ui/doc >>> $ make >>> >>> Documentation is generated into: install/ui/build/code_doc directory >>> >>> [1] https://github.com/senchalabs/jsduck >>> [2] http://pvoborni.fedorapeople.org/doc >>> [3] http://pvoborni.fedorapeople.org/doc/#!/guide >>> [4] https://github.com/senchalabs/jsduck/wiki/Installation >> >> I would rather not grow a dependency on Ruby in the freeIPA project. >> Are there any alternatives ? >> >> Simo. >> > Is it dev side dependency? We might have issues if we need gems during > build process that are not a part of distro. This a UI Doc building dependency, i.e. not needed when package is installed. So someone/something doing a release and releasing the doc will need the ruby + respective rubygem installed. If we want to automate the build and let the doc be built for example on koji, I am afraid we would have to step back from using jsDuck, or let Petr package it in Fedora since he used it despite my previous warnings :-) Petr, we should think if we should keep UI doc and articles in devel repo or if leave just the anonated code there and move all development articles and guides to our new doc repo http://www.freeipa.org/page/Contribute/Documentation Martin From pvoborni at redhat.com Thu Sep 12 09:02:19 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 12 Sep 2013 11:02:19 +0200 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <5231563C.8090203@redhat.com> References: <523049A5.10208@redhat.com> <1378916880.2804.1612.camel@willson.li.ssimo.org> <5230DF98.1040501@redhat.com> <5231563C.8090203@redhat.com> Message-ID: <5231831B.6090707@redhat.com> On 09/12/2013 07:50 AM, Martin Kosek wrote: > On 09/11/2013 11:24 PM, Dmitri Pal wrote: >> On 09/11/2013 12:28 PM, Simo Sorce wrote: >>> On Wed, 2013-09-11 at 12:44 +0200, Petr Vobornik wrote: >>>> Hello, >>>> >>>> This is a part of documentation effort which started couple month >>>> ago. >>>> Attached patches improves devel documentation of Web UI. Mostly by >>>> annotating source code and then processing it by JSDuck tool[1]. >>>> >>>> The documentation is not complete - most plugins and member of some >>>> core >>>> widgets and facets are not annotated yet. I'm sending it now because >>>> I >>>> need to focus on more pressing tickets. >>>> >>>> You can see current state at my fedorapeople page [2]. >>>> >>>> I also converted 5 guides/articles which I wrote some time ago. >>>> Guides >>>> are also part of the JSDuck app [3]. >>>> >>>> The idea is to regularly generate the doc and place it on >>>> docs.freeipa.org (not in production at the moment) so all doc would >>>> be >>>> on one place. >>>> >>>> Installation of JSDuck is documented on their page [4]. Basically it >>>> requires ruby and JSDuck gem. >>>> >>>> Usage: >>>> $ cd install/ui/doc >>>> $ make >>>> >>>> Documentation is generated into: install/ui/build/code_doc directory >>>> >>>> [1] https://github.com/senchalabs/jsduck >>>> [2] http://pvoborni.fedorapeople.org/doc >>>> [3] http://pvoborni.fedorapeople.org/doc/#!/guide >>>> [4] https://github.com/senchalabs/jsduck/wiki/Installation >>> >>> I would rather not grow a dependency on Ruby in the freeIPA project. >>> Are there any alternatives ? >>> >>> Simo. >>> >> Is it dev side dependency? We might have issues if we need gems during >> build process that are not a part of distro. > > This a UI Doc building dependency, i.e. not needed when package is installed. > So someone/something doing a release and releasing the doc will need the ruby + > respective rubygem installed. > > If we want to automate the build and let the doc be built for example on koji, > I am afraid we would have to step back from using jsDuck, or let Petr package > it in Fedora since he used it despite my previous warnings :-) The question is if we want to include these docs into some freeipa-doc package. I don't think it's necessary. The important thing is to have it on the web. Short overview of other JavaScript doc tools JSDoc - runs on rhino or can be downloaded by npm - doc comments need to be too verbose (problems with introspection of old class system) - output is much worse then jsduck (can't find online example, the one which I generated is already gone) - slow ScriptDoc/AjaxDoc http://ajaxdoc.codeplex.com/ - requires .NET YUIDoc http://developer.yahoo.com/yui/yuidoc/ - requires node.js + nice output - doesn't do code introspection - every information has to be in doc comment NaturalDocs http://www.naturaldocs.org/ + packaged - only basic JavaScript support (no code introspection) - don't like the output Doxygen + packaged (not sure about JS support) - the output is pretty bad Dojo Doc - output requires php + nice output ~ not sure about code introspection, most likely works only with Dojo classes JSDuck - ruby + IMO best output + sufficient code introspection - Works with older and new code + fast (compare to JSDoc) Subjective comparison in specific areas: - Writing doc comments: JSDuck > YUIDoc | DojoDoc | NaturalDocs > JSDoc > Doxygen - Output (UX) JSDuck > YUIDoc | DojoDoc > NaturalDocs > JSDoc > Doxygen - Packaging NaturalDocs | Doxygen > JSDuck | YUIDoc > JSDoc > DojoDoc > > Petr, we should think if we should keep UI doc and articles in devel repo or if > leave just the anonated code there and move all development articles and guides > to our new doc repo > http://www.freeipa.org/page/Contribute/Documentation > Martin > The move can be considered only if we want to package the code doc. And we might then require freeipa repo for doc generation which is not good. To avoid it we would have to remove guides from the output app. It's bad because it would break or make more difficult links from code [1] to guides and vice versa. [1] https://github.com/senchalabs/jsduck/wiki/%40aside -- Petr Vobornik From pvoborni at redhat.com Thu Sep 12 11:28:38 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 12 Sep 2013 13:28:38 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <1378355153.19352.29.camel@localhost> References: <1378355153.19352.29.camel@localhost> Message-ID: <5231A566.30904@redhat.com> I've started the work on OTP UI and found few issues in this patch: 1. api.txt is not regenerated. Run ./makeapi. Same issue is in patch #15 and #16. 2. python-qrcode is missing in BuildRequires 3. minor: would be nice if attribute names in `takes_params` and `default_attributes` would have same casing. 4. 'OTP token' prefix in each param label seems redundant to me. We don't use it in other commands and it makes labels unnecessary long. 5. Tried to run: $ ipa otp-add fbarkey4 --owner fbar --type=totp --raw --all while kinit-ed as user fbar and got: ipa: ERROR: Insufficient access: Insufficient 'add' privilege to add the entry 'ipatokenuniqueid=fbarkey4,cn=otp,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'. running it as admin works. Qs: a. Do we have some use cases for adding internal OTP? I wonder which otp-add options are essential (ipatokenvendor, ipatokenmodel, ipatokenserial, ipatokenotpkey, ipatokenotpalgorithm, ipatokenotpdigits, ipatokentotpclockoffset, ipatokentotptimestep?) and which are less important (ipatokennotbefore, ipatokennotafter ?). From user perspective it seems that the best thing is to enter the token id and then run with defaults. On 09/05/2013 06:25 AM, Nathaniel McCallum wrote: > This patch has a few problems that I'd like some help with. There are a > few notes here as well. > > 1. The handling of the 'key' option is insecure. It should probably be > treated like a password (hidden from logs, etc). However, in this case, > it is binary, so I'm not quite sure how to do that. Passing it as a > command line option may be nice for scripting, but is potentially a > security problem if it ends up in bash.history. It would also be nice if > the encoding were base32 instead of base64, since nearly all the OTP > tools use this encoding. > > 2. The 'key' option also appears in otp-find. I'd like to suppress this. > How? > > 3. I had to make the 'id' option optional to make the uuid > autogeneration work in otp-add. However, this has the side-effect that > 'id' is now optional in all the other commands. This is particularly bad > in the case of otp-del, where calling this command with no ID > transparently removes all tokens. How can I make this optional for > otp-add but required for all other commands? > > 4. otp-import is not implemented. I spent a few hours looking and I > didn't find any otp tool that actually uses this xml format for > exporting. Should we implement this now or wait until someone can > actually export data to us? > > 5. otp-del happily deletes the last token for a user. How can I find out > the dn of the user executing the command? Also, what is the right > exception to throw in pre_callback()? > > 6. user-show does not list the associated tokens for this user. Do we > care? It is a single search: otp-find --owner npmccallum. > > 7. otp-add only prints the qr code if the --qrcode option is specified. > This is for two reasons. First, and most importantly, the qr code > doesn't fit on a standard 24x80 terminal. I wanted to avoid dumping > garbage on people's screens by default. Second, you may not always want > the qr code output (like for a hard token or manual code entry). > > Nathaniel > -- Petr Vobornik From pviktori at redhat.com Thu Sep 12 11:48:14 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 12 Sep 2013 13:48:14 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <1378387917.19352.43.camel@localhost> References: <1378355153.19352.29.camel@localhost> <1378355905.19352.35.camel@localhost> <52285AA5.3010309@redhat.com> <1378387917.19352.43.camel@localhost> Message-ID: <5231A9FE.7090109@redhat.com> I'm sorry for the late reply, I got caught up in other work and forgot about this thread. On 09/05/2013 03:31 PM, Nathaniel McCallum wrote: > On Thu, 2013-09-05 at 12:19 +0200, Petr Viktorin wrote: >> On 09/05/2013 06:38 AM, Nathaniel McCallum wrote: >>> On Thu, 2013-09-05 at 00:25 -0400, Nathaniel McCallum wrote: >>>> This patch has a few problems that I'd like some help with. There are a >>>> few notes here as well. >>>> >>>> 1. The handling of the 'key' option is insecure. It should probably be >>>> treated like a password (hidden from logs, etc). However, in this case, >>>> it is binary, so I'm not quite sure how to do that. Passing it as a >>>> command line option may be nice for scripting, but is potentially a >>>> security problem if it ends up in bash.history. It would also be nice if >>>> the encoding were base32 instead of base64, since nearly all the OTP >>>> tools use this encoding. >> >> Not only in bash_history; anyone can see command line parameters of >> running programs. >> We'll need to modify the framework to support more another password >> parameter type. >> The base32 on input/output can be added to that new type. > > To clarify, by scripting I meant calling this from a python script. In > this case, the argument wouldn't show up in the argv. Sorry my wording > wasn't clear here. > > The primary case where this will apply is in otp-import (if we implement > it). We will parse the XML and call self.api.Command.otp_add() for each > token found, including the key. > > So it would be good to have this option available in python but not the > shell. In Python you can just use the base64 module to convert between base64 and base32. I don't think we need to go out of our way to make this easier. >>>> 5. otp-del happily deletes the last token for a user. How can I find out >>>> the dn of the user executing the command? Also, what is the right >>>> exception to throw in pre_callback()? >> >> Don't you want to check the token's owner rather than the current user? >> You could use LastMemberError here, or make your own error. > > If the executing user has permissions to remove another user's token, we > assume they are an admin and know what they are doing. So this case only > arises if the executing user is removing his/her own tokens. For > instance: > > if executor == owner and tokenCount(owner) == 1: > raise LastMemberError() That's a non-intuitive assumption. I wouldn't base the behavior on it if it's not necessary (even if it was easy to get the executing user). IMO, an admin should get the same safeguards as a regular user here. If we want to allow users that know what they are doing to remove their last token, we should a --force option. >>>> 7. otp-add only prints the qr code if the --qrcode option is specified. >>>> This is for two reasons. First, and most importantly, the qr code >>>> doesn't fit on a standard 24x80 terminal. I wanted to avoid dumping >>>> garbage on people's screens by default. Second, you may not always want >>>> the qr code output (like for a hard token or manual code entry). >> >> Would it make sense to add --qrcode to otp-show as well? If otp-add is >> the only opportunity to get the QR code, it's is easy to miss. > > Only admins have permission to read 'key' from LDAP after creation. > Standard users can create the OTP token object with a 'key', but cannot > read back the key. Hence, the URI is only available at creation > (provisioning) time. OK If you miss this chance, you can just delete that OTP and make another one, right? -- Petr? From abokovoy at redhat.com Thu Sep 12 13:14:01 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 12 Sep 2013 16:14:01 +0300 Subject: [Freeipa-devel] [PATCH] 0117 ipaserver/dcerpc.py: populate forest trust information Message-ID: <20130912131401.GI21212@redhat.com> Hi! Attached patch does the magic of enabling all domains associated with our realm in AD when we establish the trust relationship. LsarSetForestTrustInformation RPC call is used to set the forest trust information. Currently only top level names are exposed as we don't have any domain name/SID/NetBIOS exclusion support yet. I decided to avoid updating full TDO object as there is some problem with memory handling of a domain sid object in lsa.ForestTrustRecord Python binding for that type -- even assigned value gets immediately destroyed unless I ndr_print the record. The patch also moves string_to_array() helper to the top level as it is useful for quite few RPC calls where instead of a structured record one needs to use ndr_pack() and string_to_array() of the result. While it is not used right now, there will be updates coming related to subdomains handling that will require it anyway. https://fedorahosted.org/freeipa/ticket/3919 -- / Alexander Bokovoy -------------- next part -------------- >From a1ae5d0c7635e76d083bb89db0fa705d2102686e Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 11 Sep 2013 21:34:55 +0300 Subject: [PATCH 4/4] ipaserver/dcerpc.py: populate forest trust information using realmdomains Use realmdomains information to prepopulate forest trust info. As result, all additional domains should now be enabled from the beginning, unless they really conflict with existing DNS domains on AD side. https://fedorahosted.org/freeipa/ticket/3919 --- ipaserver/dcerpc.py | 113 +++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 95 insertions(+), 18 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index bd8f5aa..c24230b 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -39,7 +39,7 @@ import uuid from samba import param from samba import credentials from samba.dcerpc import security, lsa, drsblobs, nbt, netlogon -from samba.ndr import ndr_pack +from samba.ndr import ndr_pack, ndr_print from samba import net import samba import random @@ -684,6 +684,12 @@ class DomainValidator(object): self._info[domain] = info return info +def string_to_array(what): + blob = [0] * len(what) + + for i in range(len(what)): + blob[i] = ord(what[i]) + return blob class TrustDomainInstance(object): @@ -698,6 +704,7 @@ class TrustDomainInstance(object): self._pipe = None self._policy_handle = None self.read_only = False + self.ftinfo_records = None def __gen_lsa_connection(self, binding): if self.creds is None: @@ -827,12 +834,6 @@ class TrustDomainInstance(object): def arcfour_encrypt(key, data): c = RC4.RC4(key) return c.update(data) - def string_to_array(what): - blob = [0] * len(what) - - for i in range(len(what)): - blob[i] = ord(what[i]) - return blob password_blob = string_to_array(trustdom_secret.encode('utf-16-le')) @@ -876,6 +877,53 @@ class TrustDomainInstance(object): self.auth_info = auth_info + def generate_ftinfo(self, another_domain): + """ + Generates TrustDomainInfoFullInfo2Internal structure + This structure allows to pass information about all domains associated + with the another domain's realm. + + Only top level name and top level name exclusions are handled here. + """ + if not another_domain.ftinfo_records: + return + + ftinfo_records = [] + info = lsa.ForestTrustInformation() + + for rec in another_domain.ftinfo_records: + record = lsa.ForestTrustRecord() + record.flags = 0 + record.time = rec['rec_time'] + record.type = rec['rec_type'] + record.forest_trust_data.string = rec['rec_name'] + ftinfo_records.append(record) + + info.count = len(ftinfo_records) + info.entries = ftinfo_records + return info + + def update_ftinfo(self, another_domain): + """ + Updates forest trust information in this forest corresponding + to the another domain's information. + """ + try: + if another_domain.ftinfo_records: + ftinfo = self.generate_ftinfo(another_domain) + # Set forest trust information -- we do it only against AD DC as + # smbd already has the information about itself + ldname = lsa.StringLarge() + ldname.string = another_domain.info['dns_domain'] + collision_info = self._pipe.lsaRSetForestTrustInformation(self._policy_handle, + ldname, + lsa.LSA_FOREST_TRUST_DOMAIN_INFO, + ftinfo, 0) + if collision_info: + root_logger.error("When setting forest trust information, got collision info back:\n%s" % (ndr_print(collision_info))) + except RuntimeError, e: + # We can ignore the error here -- setting up name suffix routes may fail + pass def establish_trust(self, another_domain, trustdom_secret): """ @@ -883,6 +931,12 @@ class TrustDomainInstance(object): Input: another_domain -- instance of TrustDomainInstance, initialized with #retrieve call trustdom_secret -- shared secred used for the trust """ + if self.info['name'] == another_domain.info['name']: + # Check that NetBIOS names do not clash + raise errors.ValidationError(name=u'AD Trust Setup', + error=_('the IPA server and the remote domain cannot share the same ' + 'NetBIOS name: %s') % self.info['name']) + self.generate_auth(trustdom_secret) info = lsa.TrustDomainInfoInfoEx() @@ -893,12 +947,6 @@ class TrustDomainInstance(object): info.trust_type = lsa.LSA_TRUST_TYPE_UPLEVEL info.trust_attributes = lsa.LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE - if self.info['name'] == info.netbios_name.string: - # Check that NetBIOS names do not clash - raise errors.ValidationError(name=u'AD Trust Setup', - error=_('the IPA server and the remote domain cannot share the same ' - 'NetBIOS name: %s') % self.info['name']) - try: dname = lsa.String() dname.string = another_domain.info['dns_domain'] @@ -911,12 +959,14 @@ class TrustDomainInstance(object): except RuntimeError, (num, message): raise assess_dcerpc_exception(num=num, message=message) + self.update_ftinfo(another_domain) + + # We should use proper trustdom handle in order to modify the + # trust settings. Samba insists this has to be done with LSA + # OpenTrustedDomain* calls, it is not enough to have a handle + # returned by the CreateTrustedDomainEx2 call. + trustdom_handle = self._pipe.OpenTrustedDomainByName(self._policy_handle, dname, security.SEC_FLAG_MAXIMUM_ALLOWED) try: - # We should use proper trustdom handle in order to modify the - # trust settings. Samba insists this has to be done with LSA - # OpenTrustedDomain* calls, it is not enough to have a handle - # returned by the CreateTrustedDomainEx2 call. - trustdom_handle = self._pipe.OpenTrustedDomainByName(self._policy_handle, dname, security.SEC_FLAG_MAXIMUM_ALLOWED) infoclass = lsa.TrustDomainInfoSupportedEncTypes() infoclass.enc_types = security.KERB_ENCTYPE_RC4_HMAC_MD5 infoclass.enc_types |= security.KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 @@ -1016,6 +1066,32 @@ class TrustDomainJoins(object): # Otherwise, use anonymously obtained data self.remote_domain = rd + def get_realmdomains(self): + """ + Generate list of records for forest trust information about + our realm domains. Note that the list generated currently + includes only top level domains, no exclusion domains, and no TDO objects + as we handle the latter in a separte way + """ + if self.local_domain.read_only: + return + + self.local_domain.ftinfo_records = [] + + realm_domains = self.api.Command.realmdomains_show()['result'] + trustconfig = self.api.Command.trustconfig_show()['result'] + # Use realmdomains' modification timestamp to judge records last update time + (dn, entry_attrs) = self.api.Backend.ldap2.get_entry(realm_domains['dn'], ['modifyTimestamp']) + # Convert the timestamp to Windows 64-bit timestamp format + trust_timestamp = long(time.mktime(time.strptime(entry_attrs['modifytimestamp'][0][:14], "%Y%m%d%H%M%S"))*1e7+116444736000000000) + + for dom in realm_domains['associateddomain']: + ftinfo = dict() + ftinfo['rec_name'] = dom + ftinfo['rec_time'] = trust_timestamp + ftinfo['rec_type'] = lsa.LSA_FOREST_TRUST_TOP_LEVEL_NAME + self.local_domain.ftinfo_records.append(ftinfo) + def join_ad_full_credentials(self, realm, realm_server, realm_admin, realm_passwd): if not self.configured: return None @@ -1030,6 +1106,7 @@ class TrustDomainJoins(object): if not self.remote_domain.read_only: trustdom_pass = samba.generate_random_password(128, 128) + self.get_realmdomains() self.remote_domain.establish_trust(self.local_domain, trustdom_pass) self.local_domain.establish_trust(self.remote_domain, trustdom_pass) result = self.remote_domain.verify_trust(self.local_domain) -- 1.8.3.1 From simo at redhat.com Thu Sep 12 13:14:30 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Sep 2013 09:14:30 -0400 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <5231563C.8090203@redhat.com> References: <523049A5.10208@redhat.com> <1378916880.2804.1612.camel@willson.li.ssimo.org> <5230DF98.1040501@redhat.com> <5231563C.8090203@redhat.com> Message-ID: <1378991670.2804.1893.camel@willson.li.ssimo.org> On Thu, 2013-09-12 at 07:50 +0200, Martin Kosek wrote: > On 09/11/2013 11:24 PM, Dmitri Pal wrote: > > On 09/11/2013 12:28 PM, Simo Sorce wrote: > >> On Wed, 2013-09-11 at 12:44 +0200, Petr Vobornik wrote: > >>> Hello, > >>> > >>> This is a part of documentation effort which started couple month > >>> ago. > >>> Attached patches improves devel documentation of Web UI. Mostly by > >>> annotating source code and then processing it by JSDuck tool[1]. > >>> > >>> The documentation is not complete - most plugins and member of some > >>> core > >>> widgets and facets are not annotated yet. I'm sending it now because > >>> I > >>> need to focus on more pressing tickets. > >>> > >>> You can see current state at my fedorapeople page [2]. > >>> > >>> I also converted 5 guides/articles which I wrote some time ago. > >>> Guides > >>> are also part of the JSDuck app [3]. > >>> > >>> The idea is to regularly generate the doc and place it on > >>> docs.freeipa.org (not in production at the moment) so all doc would > >>> be > >>> on one place. > >>> > >>> Installation of JSDuck is documented on their page [4]. Basically it > >>> requires ruby and JSDuck gem. > >>> > >>> Usage: > >>> $ cd install/ui/doc > >>> $ make > >>> > >>> Documentation is generated into: install/ui/build/code_doc directory > >>> > >>> [1] https://github.com/senchalabs/jsduck > >>> [2] http://pvoborni.fedorapeople.org/doc > >>> [3] http://pvoborni.fedorapeople.org/doc/#!/guide > >>> [4] https://github.com/senchalabs/jsduck/wiki/Installation > >> > >> I would rather not grow a dependency on Ruby in the freeIPA project. > >> Are there any alternatives ? > >> > >> Simo. > >> > > Is it dev side dependency? We might have issues if we need gems during > > build process that are not a part of distro. This is only one of the problems. > This a UI Doc building dependency, i.e. not needed when package is installed. > So someone/something doing a release and releasing the doc will need the ruby + > respective rubygem installed. > > If we want to automate the build and let the doc be built for example on koji, > I am afraid we would have to step back from using jsDuck, or let Petr package > it in Fedora since he used it despite my previous warnings :-) The problem is that ruby is still a fast moving target, and we do not want to waste time fighiting it when (not if) it will break and you find it just right before a release where you want to build docs. I really would like to avoid dependencies in Ruby in this project completely as long as possible. > Petr, we should think if we should keep UI doc and articles in devel repo or if > leave just the anonated code there and move all development articles and guides > to our new doc repo > http://www.freeipa.org/page/Contribute/Documentation moving to the doc repo does not solve the problem, really, we are still depending on a) ruby for generating docs, b) someone knowing Ruby to fix things when they will break. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Thu Sep 12 13:38:20 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 12 Sep 2013 09:38:20 -0400 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <5231A9FE.7090109@redhat.com> References: <1378355153.19352.29.camel@localhost> <1378355905.19352.35.camel@localhost> <52285AA5.3010309@redhat.com> <1378387917.19352.43.camel@localhost> <5231A9FE.7090109@redhat.com> Message-ID: <1378993100.1749.12.camel@localhost> On Thu, 2013-09-12 at 13:48 +0200, Petr Viktorin wrote: > I'm sorry for the late reply, I got caught up in other work and forgot > about this thread. > > On 09/05/2013 03:31 PM, Nathaniel McCallum wrote: > > On Thu, 2013-09-05 at 12:19 +0200, Petr Viktorin wrote: > >> On 09/05/2013 06:38 AM, Nathaniel McCallum wrote: > >>> On Thu, 2013-09-05 at 00:25 -0400, Nathaniel McCallum wrote: > >>>> This patch has a few problems that I'd like some help with. There are a > >>>> few notes here as well. > >>>> > >>>> 1. The handling of the 'key' option is insecure. It should probably be > >>>> treated like a password (hidden from logs, etc). However, in this case, > >>>> it is binary, so I'm not quite sure how to do that. Passing it as a > >>>> command line option may be nice for scripting, but is potentially a > >>>> security problem if it ends up in bash.history. It would also be nice if > >>>> the encoding were base32 instead of base64, since nearly all the OTP > >>>> tools use this encoding. > >> > >> Not only in bash_history; anyone can see command line parameters of > >> running programs. > >> We'll need to modify the framework to support more another password > >> parameter type. > >> The base32 on input/output can be added to that new type. > > > > To clarify, by scripting I meant calling this from a python script. In > > this case, the argument wouldn't show up in the argv. Sorry my wording > > wasn't clear here. > > > > The primary case where this will apply is in otp-import (if we implement > > it). We will parse the XML and call self.api.Command.otp_add() for each > > token found, including the key. > > > > So it would be good to have this option available in python but not the > > shell. > > In Python you can just use the base64 module to convert between base64 > and base32. I don't think we need to go out of our way to make this easier. We need to pass the key as an argument in python. The format of this argument is irrelevant (base32/base64). When *displaying* the key to the user as the result of the otp-add operation, base32 should be used. Most soft-token products do input in base32 since it is easier to type and read. > >>>> 5. otp-del happily deletes the last token for a user. How can I find out > >>>> the dn of the user executing the command? Also, what is the right > >>>> exception to throw in pre_callback()? > >> > >> Don't you want to check the token's owner rather than the current user? > >> You could use LastMemberError here, or make your own error. > > > > If the executing user has permissions to remove another user's token, we > > assume they are an admin and know what they are doing. So this case only > > arises if the executing user is removing his/her own tokens. For > > instance: > > > > if executor == owner and tokenCount(owner) == 1: > > raise LastMemberError() > > That's a non-intuitive assumption. I wouldn't base the behavior on it if > it's not necessary (even if it was easy to get the executing user). > IMO, an admin should get the same safeguards as a regular user here. If > we want to allow users that know what they are doing to remove their > last token, we should a --force option. Okay, that makes sense. > >>>> 7. otp-add only prints the qr code if the --qrcode option is specified. > >>>> This is for two reasons. First, and most importantly, the qr code > >>>> doesn't fit on a standard 24x80 terminal. I wanted to avoid dumping > >>>> garbage on people's screens by default. Second, you may not always want > >>>> the qr code output (like for a hard token or manual code entry). > >> > >> Would it make sense to add --qrcode to otp-show as well? If otp-add is > >> the only opportunity to get the QR code, it's is easy to miss. > > > > Only admins have permission to read 'key' from LDAP after creation. > > Standard users can create the OTP token object with a 'key', but cannot > > read back the key. Hence, the URI is only available at creation > > (provisioning) time. > > OK > If you miss this chance, you can just delete that OTP and make another > one, right? Yes. From simo at redhat.com Thu Sep 12 13:47:47 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Sep 2013 09:47:47 -0400 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <5231831B.6090707@redhat.com> References: <523049A5.10208@redhat.com> <1378916880.2804.1612.camel@willson.li.ssimo.org> <5230DF98.1040501@redhat.com> <5231563C.8090203@redhat.com> <5231831B.6090707@redhat.com> Message-ID: <1378993667.2804.1907.camel@willson.li.ssimo.org> On Thu, 2013-09-12 at 11:02 +0200, Petr Vobornik wrote: > On 09/12/2013 07:50 AM, Martin Kosek wrote: > > On 09/11/2013 11:24 PM, Dmitri Pal wrote: > >> On 09/11/2013 12:28 PM, Simo Sorce wrote: > >>> On Wed, 2013-09-11 at 12:44 +0200, Petr Vobornik wrote: > >>>> Hello, > >>>> > >>>> This is a part of documentation effort which started couple month > >>>> ago. > >>>> Attached patches improves devel documentation of Web UI. Mostly by > >>>> annotating source code and then processing it by JSDuck tool[1]. > >>>> > >>>> The documentation is not complete - most plugins and member of some > >>>> core > >>>> widgets and facets are not annotated yet. I'm sending it now because > >>>> I > >>>> need to focus on more pressing tickets. > >>>> > >>>> You can see current state at my fedorapeople page [2]. > >>>> > >>>> I also converted 5 guides/articles which I wrote some time ago. > >>>> Guides > >>>> are also part of the JSDuck app [3]. > >>>> > >>>> The idea is to regularly generate the doc and place it on > >>>> docs.freeipa.org (not in production at the moment) so all doc would > >>>> be > >>>> on one place. > >>>> > >>>> Installation of JSDuck is documented on their page [4]. Basically it > >>>> requires ruby and JSDuck gem. > >>>> > >>>> Usage: > >>>> $ cd install/ui/doc > >>>> $ make > >>>> > >>>> Documentation is generated into: install/ui/build/code_doc directory > >>>> > >>>> [1] https://github.com/senchalabs/jsduck > >>>> [2] http://pvoborni.fedorapeople.org/doc > >>>> [3] http://pvoborni.fedorapeople.org/doc/#!/guide > >>>> [4] https://github.com/senchalabs/jsduck/wiki/Installation > >>> > >>> I would rather not grow a dependency on Ruby in the freeIPA project. > >>> Are there any alternatives ? > >>> > >>> Simo. > >>> > >> Is it dev side dependency? We might have issues if we need gems during > >> build process that are not a part of distro. > > > > This a UI Doc building dependency, i.e. not needed when package is installed. > > So someone/something doing a release and releasing the doc will need the ruby + > > respective rubygem installed. > > > > If we want to automate the build and let the doc be built for example on koji, > > I am afraid we would have to step back from using jsDuck, or let Petr package > > it in Fedora since he used it despite my previous warnings :-) > > The question is if we want to include these docs into some freeipa-doc > package. I don't think it's necessary. The important thing is to have it > on the web. > > Short overview of other JavaScript doc tools > > JSDoc > - runs on rhino or can be downloaded by npm > - doc comments need to be too verbose (problems with introspection of > old class system) > - output is much worse then jsduck (can't find online example, the one > which I generated is already gone) > - slow > > ScriptDoc/AjaxDoc http://ajaxdoc.codeplex.com/ > - requires .NET > > YUIDoc http://developer.yahoo.com/yui/yuidoc/ > - requires node.js > + nice output > - doesn't do code introspection - every information has to be in doc comment > > NaturalDocs http://www.naturaldocs.org/ > + packaged > - only basic JavaScript support (no code introspection) > - don't like the output > > Doxygen > + packaged (not sure about JS support) > - the output is pretty bad > > Dojo Doc > - output requires php > + nice output > ~ not sure about code introspection, most likely works only with Dojo > classes > > JSDuck > - ruby > + IMO best output > + sufficient code introspection - Works with older and new code > + fast (compare to JSDoc) > > > Subjective comparison in specific areas: > > - Writing doc comments: > JSDuck > YUIDoc | DojoDoc | NaturalDocs > JSDoc > Doxygen > > - Output (UX) > JSDuck > YUIDoc | DojoDoc > NaturalDocs > JSDoc > Doxygen > > - Packaging > NaturalDocs | Doxygen > JSDuck | YUIDoc > JSDoc > DojoDoc > To be honest, I would go with the old and tried doxygen, maybe we can find a way to make the output not look too bad ? The output you link up there is the worst thing I have ever seen, but it is not what I have seen in most other doxygen generated outputs. This one doesn't look bad: https://talloc.samba.org/talloc/doc/html/group__talloc__ref.html This is also generated by doxygen and looks ok to me: http://dbus.freedesktop.org/doc/api/html/index.html > > > > Petr, we should think if we should keep UI doc and articles in devel repo or if > > leave just the anonated code there and move all development articles and guides > > to our new doc repo > > http://www.freeipa.org/page/Contribute/Documentation > > Martin > > > > The move can be considered only if we want to package the code doc. And > we might then require freeipa repo for doc generation which is not good. > > To avoid it we would have to remove guides from the output app. It's bad > because it would break or make more difficult links from code [1] to > guides and vice versa. > > [1] https://github.com/senchalabs/jsduck/wiki/%40aside I am not sure to what case the 'bad' and 'have to remove' comemnts apply to here, can you be more explicit ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Thu Sep 12 14:01:24 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 12 Sep 2013 16:01:24 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <1378993100.1749.12.camel@localhost> References: <1378355153.19352.29.camel@localhost> <1378355905.19352.35.camel@localhost> <52285AA5.3010309@redhat.com> <1378387917.19352.43.camel@localhost> <5231A9FE.7090109@redhat.com> <1378993100.1749.12.camel@localhost> Message-ID: <5231C934.4090506@redhat.com> On 09/12/2013 03:38 PM, Nathaniel McCallum wrote: > On Thu, 2013-09-12 at 13:48 +0200, Petr Viktorin wrote: >> I'm sorry for the late reply, I got caught up in other work and forgot >> about this thread. >> >> On 09/05/2013 03:31 PM, Nathaniel McCallum wrote: >>> On Thu, 2013-09-05 at 12:19 +0200, Petr Viktorin wrote: >>>> On 09/05/2013 06:38 AM, Nathaniel McCallum wrote: >>>>> On Thu, 2013-09-05 at 00:25 -0400, Nathaniel McCallum wrote: >>>>>> This patch has a few problems that I'd like some help with. There are a >>>>>> few notes here as well. >>>>>> >>>>>> 1. The handling of the 'key' option is insecure. It should probably be >>>>>> treated like a password (hidden from logs, etc). However, in this case, >>>>>> it is binary, so I'm not quite sure how to do that. Passing it as a >>>>>> command line option may be nice for scripting, but is potentially a >>>>>> security problem if it ends up in bash.history. It would also be nice if >>>>>> the encoding were base32 instead of base64, since nearly all the OTP >>>>>> tools use this encoding. >>>> >>>> Not only in bash_history; anyone can see command line parameters of >>>> running programs. >>>> We'll need to modify the framework to support more another password >>>> parameter type. >>>> The base32 on input/output can be added to that new type. >>> >>> To clarify, by scripting I meant calling this from a python script. In >>> this case, the argument wouldn't show up in the argv. Sorry my wording >>> wasn't clear here. >>> >>> The primary case where this will apply is in otp-import (if we implement >>> it). We will parse the XML and call self.api.Command.otp_add() for each >>> token found, including the key. >>> >>> So it would be good to have this option available in python but not the >>> shell. >> >> In Python you can just use the base64 module to convert between base64 >> and base32. I don't think we need to go out of our way to make this easier. > > We need to pass the key as an argument in python. The format of this > argument is irrelevant (base32/base64). > > When *displaying* the key to the user as the result of the otp-add > operation, base32 should be used. Most soft-token products do input in > base32 since it is easier to type and read. > Ah, I see. Then you can make a new Output and put the base32-encoded data there (see e.g. `output_params` and `set_certificate_attrs` in the service plugin for an example). -- Petr? From mkosek at redhat.com Thu Sep 12 14:30:43 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Sep 2013 16:30:43 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <1378355153.19352.29.camel@localhost> References: <1378355153.19352.29.camel@localhost> Message-ID: <5231D013.10807@redhat.com> On 09/05/2013 06:25 AM, Nathaniel McCallum wrote: > This patch has a few problems that I'd like some help with. There are a > few notes here as well. > > 1. The handling of the 'key' option is insecure. It should probably be > treated like a password (hidden from logs, etc). However, in this case, > it is binary, so I'm not quite sure how to do that. Passing it as a > command line option may be nice for scripting, but is potentially a > security problem if it ends up in bash.history. It would also be nice if > the encoding were base32 instead of base64, since nearly all the OTP > tools use this encoding. > > 2. The 'key' option also appears in otp-find. I'd like to suppress this. > How? > > 3. I had to make the 'id' option optional to make the uuid > autogeneration work in otp-add. However, this has the side-effect that > 'id' is now optional in all the other commands. This is particularly bad > in the case of otp-del, where calling this command with no ID > transparently removes all tokens. How can I make this optional for > otp-add but required for all other commands? > > 4. otp-import is not implemented. I spent a few hours looking and I > didn't find any otp tool that actually uses this xml format for > exporting. Should we implement this now or wait until someone can > actually export data to us? > > 5. otp-del happily deletes the last token for a user. How can I find out > the dn of the user executing the command? Also, what is the right > exception to throw in pre_callback()? > > 6. user-show does not list the associated tokens for this user. Do we > care? It is a single search: otp-find --owner npmccallum. > > 7. otp-add only prints the qr code if the --qrcode option is specified. > This is for two reasons. First, and most importantly, the qr code > doesn't fit on a standard 24x80 terminal. I wanted to avoid dumping > garbage on people's screens by default. Second, you may not always want > the qr code output (like for a hard token or manual code entry). > > Nathaniel I just noticed you use few sub-optimal calls which could slower the calls: + if owner is not None: + result = self.api.Command.user_show(owner)['result'] + entry_attrs['ipatokenowner'] = result['dn'] + return dn ... + if owner is not None: + result = self.api.Command.user_show(owner)['result'] + filters = filters.replace("(ipatokenowner=%s)" % owner, + "(ipatokenowner=%s)" % result['dn']) + These commands will load the entire user, loads all the membership etc. etc., so it may result into several LDAP searches. But you use just the DN. This call should be much faster: # get DN of user object dn = self.api.Object['group'].get_dn_if_exists(owner) Not a functionality blocker, just a something that I would like to next patch iteration. Martin From pvoborni at redhat.com Thu Sep 12 17:11:11 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 12 Sep 2013 19:11:11 +0200 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <1378993667.2804.1907.camel@willson.li.ssimo.org> References: <523049A5.10208@redhat.com> <1378916880.2804.1612.camel@willson.li.ssimo.org> <5230DF98.1040501@redhat.com> <5231563C.8090203@redhat.com> <5231831B.6090707@redhat.com> <1378993667.2804.1907.camel@willson.li.ssimo.org> Message-ID: <5231F5AF.9000409@redhat.com> On 09/12/2013 03:47 PM, Simo Sorce wrote: > On Thu, 2013-09-12 at 11:02 +0200, Petr Vobornik wrote: >> On 09/12/2013 07:50 AM, Martin Kosek wrote: >>> On 09/11/2013 11:24 PM, Dmitri Pal wrote: >>>> On 09/11/2013 12:28 PM, Simo Sorce wrote: >>>>> On Wed, 2013-09-11 at 12:44 +0200, Petr Vobornik wrote: >>>>>> >>>>>> [1] https://github.com/senchalabs/jsduck >>>>>> [2] http://pvoborni.fedorapeople.org/doc >>>>>> [3] http://pvoborni.fedorapeople.org/doc/#!/guide >>>>>> [4] https://github.com/senchalabs/jsduck/wiki/Installation >>>>> >>>>> I would rather not grow a dependency on Ruby in the freeIPA project. >>>>> Are there any alternatives ? >>>>> >>>>> Simo. >>>>> >>>> Is it dev side dependency? We might have issues if we need gems during >>>> build process that are not a part of distro. >>> >>> This a UI Doc building dependency, i.e. not needed when package is installed. >>> So someone/something doing a release and releasing the doc will need the ruby + >>> respective rubygem installed. >>> >>> If we want to automate the build and let the doc be built for example on koji, >>> I am afraid we would have to step back from using jsDuck, or let Petr package >>> it in Fedora since he used it despite my previous warnings :-) >> >> The question is if we want to include these docs into some freeipa-doc >> package. I don't think it's necessary. The important thing is to have it >> on the web. >> >> Short overview of other JavaScript doc tools >> >> JSDoc >> - runs on rhino or can be downloaded by npm >> - doc comments need to be too verbose (problems with introspection of >> old class system) >> - output is much worse then jsduck (can't find online example, the one >> which I generated is already gone) >> - slow >> >> ScriptDoc/AjaxDoc http://ajaxdoc.codeplex.com/ >> - requires .NET >> >> YUIDoc http://developer.yahoo.com/yui/yuidoc/ >> - requires node.js >> + nice output >> - doesn't do code introspection - every information has to be in doc comment >> >> NaturalDocs http://www.naturaldocs.org/ >> + packaged >> - only basic JavaScript support (no code introspection) >> - don't like the output >> >> Doxygen >> + packaged (not sure about JS support) >> - the output is pretty bad >> >> Dojo Doc >> - output requires php >> + nice output >> ~ not sure about code introspection, most likely works only with Dojo >> classes >> >> JSDuck >> - ruby >> + IMO best output >> + sufficient code introspection - Works with older and new code >> + fast (compare to JSDoc) >> >> >> Subjective comparison in specific areas: >> >> - Writing doc comments: >> JSDuck > YUIDoc | DojoDoc | NaturalDocs > JSDoc > Doxygen >> >> - Output (UX) >> JSDuck > YUIDoc | DojoDoc > NaturalDocs > JSDoc > Doxygen >> >> - Packaging >> NaturalDocs | Doxygen > JSDuck | YUIDoc > JSDoc > DojoDoc >> > > To be honest, I would go with the old and tried doxygen, maybe we can > find a way to make the output not look too bad ? > The output you link up there is the worst thing I have ever seen, but it > is not what I have seen in most other doxygen generated outputs. > > This one doesn't look bad: > https://talloc.samba.org/talloc/doc/html/group__talloc__ref.html > > This is also generated by doxygen and looks ok to me: > http://dbus.freedesktop.org/doc/api/html/index.html I investigated JS support in doxygen little further and I don't think that it would work for us. The support is provided by js2doxy.pl [1][2] script. This script converts JS code into C++ code which is then processes by doxygen. One of the requirements is that class members are recognized by assigning them into constructor's prototype [3]. We don't use this method of class definition at all. [1] http://svn.berlios.de/wsvn/jsunit/trunk/jsunit/util/js2doxy.pl?op=file&rev=0&sc=0 [2] http://www.stack.nl/~dimitri/doxygen/helpers.html#doxfilt_js [3] http://jsunit.berlios.de/internal.html > The problem is that ruby is still a fast moving target, and we do not > want to waste time fighiting it when (not if) it will break and you find > it just right before a release where you want to build docs. > > I really would like to avoid dependencies in Ruby in this project > completely as long as possible. I would not propose Ruby for any core part of IPA. This doc generation is pretty self contained unless we want to include it the doc package. Which I assume we don't. Or do we? So if ruby breaks we could just generate the doc on any system with not-broken(older) ruby and put it on the web. Btw JSDuck is developed and used by Sencha, one of the, I would say, enterprise Web App components companies. Documentation is a core part of their product so I assume that they would fix it as soon as possible. From usability perspective jsDuck seems to be the best. At almost the same level is YUIdoc but there is similar problem as it requires Node.js. Please let us avoid to do compromises on UX part. > >>> >>> Petr, we should think if we should keep UI doc and articles in devel repo or if >>> leave just the anonated code there and move all development articles and guides >>> to our new doc repo >>> http://www.freeipa.org/page/Contribute/Documentation >>> Martin >>> >> >> The move can be considered only if we want to package the code doc. And >> we might then require freeipa repo for doc generation which is not good. >> >> To avoid it we would have to remove guides from the output app. It's bad >> because it would break or make more difficult links from code [1] to >> guides and vice versa. >> >> [1] https://github.com/senchalabs/jsduck/wiki/%40aside > > I am not sure to what case the 'bad' and 'have to remove' comemnts apply > to here, can you be more explicit ? I assume that if we would move the guides to doc repo and would like to avoid requiring the other repo for build, then we would not be able to use the guides in the code doc app. In other words, guides would be removed from the output code doc and that is the thing I don't like (bad). Keeping the code doc and guides together will allow easier cross linking. You can see example of the linkage in ExtJS doc: http://docs.sencha.com/extjs/4.2.1/#!/guide/mvc_pt2 > > Simo. > -- Petr Vobornik From akrivoka at redhat.com Thu Sep 12 17:59:05 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 12 Sep 2013 19:59:05 +0200 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership Message-ID: <523200E9.5010304@redhat.com> Hello, The design document for $SUBJECT can be found at: http://www.freeipa.org/page/V3/Automember_rebuild_membership Related tickets: https://fedorahosted.org/freeipa/ticket/3752 https://fedorahosted.org/freeipa/ticket/3928 Thoughts, comments, questions welcome. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From dpal at redhat.com Thu Sep 12 18:54:32 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 12 Sep 2013 14:54:32 -0400 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <1378991670.2804.1893.camel@willson.li.ssimo.org> References: <523049A5.10208@redhat.com> <1378916880.2804.1612.camel@willson.li.ssimo.org> <5230DF98.1040501@redhat.com> <5231563C.8090203@redhat.com> <1378991670.2804.1893.camel@willson.li.ssimo.org> Message-ID: <52320DE8.7050401@redhat.com> On 09/12/2013 09:14 AM, Simo Sorce wrote: > On Thu, 2013-09-12 at 07:50 +0200, Martin Kosek wrote: >> On 09/11/2013 11:24 PM, Dmitri Pal wrote: >>> On 09/11/2013 12:28 PM, Simo Sorce wrote: >>>> On Wed, 2013-09-11 at 12:44 +0200, Petr Vobornik wrote: >>>>> Hello, >>>>> >>>>> This is a part of documentation effort which started couple month >>>>> ago. >>>>> Attached patches improves devel documentation of Web UI. Mostly by >>>>> annotating source code and then processing it by JSDuck tool[1]. >>>>> >>>>> The documentation is not complete - most plugins and member of some >>>>> core >>>>> widgets and facets are not annotated yet. I'm sending it now because >>>>> I >>>>> need to focus on more pressing tickets. >>>>> >>>>> You can see current state at my fedorapeople page [2]. >>>>> >>>>> I also converted 5 guides/articles which I wrote some time ago. >>>>> Guides >>>>> are also part of the JSDuck app [3]. >>>>> >>>>> The idea is to regularly generate the doc and place it on >>>>> docs.freeipa.org (not in production at the moment) so all doc would >>>>> be >>>>> on one place. >>>>> >>>>> Installation of JSDuck is documented on their page [4]. Basically it >>>>> requires ruby and JSDuck gem. >>>>> >>>>> Usage: >>>>> $ cd install/ui/doc >>>>> $ make >>>>> >>>>> Documentation is generated into: install/ui/build/code_doc directory >>>>> >>>>> [1] https://github.com/senchalabs/jsduck >>>>> [2] http://pvoborni.fedorapeople.org/doc >>>>> [3] http://pvoborni.fedorapeople.org/doc/#!/guide >>>>> [4] https://github.com/senchalabs/jsduck/wiki/Installation >>>> I would rather not grow a dependency on Ruby in the freeIPA project. >>>> Are there any alternatives ? >>>> >>>> Simo. >>>> >>> Is it dev side dependency? We might have issues if we need gems during >>> build process that are not a part of distro. > This is only one of the problems. > >> This a UI Doc building dependency, i.e. not needed when package is installed. >> So someone/something doing a release and releasing the doc will need the ruby + >> respective rubygem installed. >> >> If we want to automate the build and let the doc be built for example on koji, >> I am afraid we would have to step back from using jsDuck, or let Petr package >> it in Fedora since he used it despite my previous warnings :-) > The problem is that ruby is still a fast moving target, and we do not > want to waste time fighiting it when (not if) it will break and you find > it just right before a release where you want to build docs. > > I really would like to avoid dependencies in Ruby in this project > completely as long as possible. > >> Petr, we should think if we should keep UI doc and articles in devel repo or if >> leave just the anonated code there and move all development articles and guides >> to our new doc repo >> http://www.freeipa.org/page/Contribute/Documentation > moving to the doc repo does not solve the problem, really, we are still > depending on a) ruby for generating docs, b) someone knowing Ruby to fix > things when they will break. > > Simo. > It seems that doxygen does not work for JS for us. So it is node.js vs. ruby vs. no generated docs. Since we always can get back to "no docs" if things go really wrong I do not see it as an option here. I do not like either of the other two alternatives. And I do not know which one would be best if any. -- 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 Thu Sep 12 19:11:15 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 12 Sep 2013 15:11:15 -0400 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <523200E9.5010304@redhat.com> References: <523200E9.5010304@redhat.com> Message-ID: <523211D3.3080504@redhat.com> On 09/12/2013 01:59 PM, Ana Krivokapic wrote: > Hello, > > The design document for $SUBJECT can be found at: > http://www.freeipa.org/page/V3/Automember_rebuild_membership > > Related tickets: > https://fedorahosted.org/freeipa/ticket/3752 > https://fedorahosted.org/freeipa/ticket/3928 > > Thoughts, comments, questions welcome. > The names for commands are a bit long. I am not sure we need all the commands. $ ipa automember-rebuild-membership --type=group I do not understand why type is "group". If you say that all the user group memberships will be rebuilt then the type is "user". But then you can really not have the command at all and use just: ipa user-automembership and ipa host-automembership If in future we have other objects we would add another command for those objects. so ipa user-automembership --update will update group memberships for all users, or may be it should be ipa user-automembership --update * (I do not know what are the rules in the framework, we should follow them) ipa user-automember --update LOGIN will update group memberships for a specific user Now we need to differentiate --update and --reset --update should update group membership based on the existing filters, i.e. based on the automember plugin configuration only add missing memberships (if any) --reset should clean existing memberships and rebuild them based only the default groups + automember. It should pretty much mean "make group memberships as if the user was just added". Makes sense or I am missing something? -- 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 Thu Sep 12 19:15:59 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 12 Sep 2013 15:15:59 -0400 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <5231A566.30904@redhat.com> References: <1378355153.19352.29.camel@localhost> <5231A566.30904@redhat.com> Message-ID: <523212EF.7030302@redhat.com> On 09/12/2013 07:28 AM, Petr Vobornik wrote: > Qs: > > a. Do we have some use cases for adding internal OTP? I wonder which > otp-add options are essential (ipatokenvendor, ipatokenmodel, > ipatokenserial, ipatokenotpkey, ipatokenotpalgorithm, > ipatokenotpdigits, ipatokentotpclockoffset, ipatokentotptimestep?) and > which are less important (ipatokennotbefore, ipatokennotafter ?). > Can you rephrase? The use cases were covered pretty much on the design page. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Thu Sep 12 19:22:43 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 12 Sep 2013 15:22:43 -0400 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <52320DE8.7050401@redhat.com> References: <523049A5.10208@redhat.com> <1378916880.2804.1612.camel@willson.li.ssimo.org> <5230DF98.1040501@redhat.com> <5231563C.8090203@redhat.com> <1378991670.2804.1893.camel@willson.li.ssimo.org> <52320DE8.7050401@redhat.com> Message-ID: <1379013764.2804.1948.camel@willson.li.ssimo.org> On Thu, 2013-09-12 at 14:54 -0400, Dmitri Pal wrote: > On 09/12/2013 09:14 AM, Simo Sorce wrote: > > On Thu, 2013-09-12 at 07:50 +0200, Martin Kosek wrote: > >> On 09/11/2013 11:24 PM, Dmitri Pal wrote: > >>> On 09/11/2013 12:28 PM, Simo Sorce wrote: > >>>> On Wed, 2013-09-11 at 12:44 +0200, Petr Vobornik wrote: > >>>>> Hello, > >>>>> > >>>>> This is a part of documentation effort which started couple month > >>>>> ago. > >>>>> Attached patches improves devel documentation of Web UI. Mostly by > >>>>> annotating source code and then processing it by JSDuck tool[1]. > >>>>> > >>>>> The documentation is not complete - most plugins and member of some > >>>>> core > >>>>> widgets and facets are not annotated yet. I'm sending it now because > >>>>> I > >>>>> need to focus on more pressing tickets. > >>>>> > >>>>> You can see current state at my fedorapeople page [2]. > >>>>> > >>>>> I also converted 5 guides/articles which I wrote some time ago. > >>>>> Guides > >>>>> are also part of the JSDuck app [3]. > >>>>> > >>>>> The idea is to regularly generate the doc and place it on > >>>>> docs.freeipa.org (not in production at the moment) so all doc would > >>>>> be > >>>>> on one place. > >>>>> > >>>>> Installation of JSDuck is documented on their page [4]. Basically it > >>>>> requires ruby and JSDuck gem. > >>>>> > >>>>> Usage: > >>>>> $ cd install/ui/doc > >>>>> $ make > >>>>> > >>>>> Documentation is generated into: install/ui/build/code_doc directory > >>>>> > >>>>> [1] https://github.com/senchalabs/jsduck > >>>>> [2] http://pvoborni.fedorapeople.org/doc > >>>>> [3] http://pvoborni.fedorapeople.org/doc/#!/guide > >>>>> [4] https://github.com/senchalabs/jsduck/wiki/Installation > >>>> I would rather not grow a dependency on Ruby in the freeIPA project. > >>>> Are there any alternatives ? > >>>> > >>>> Simo. > >>>> > >>> Is it dev side dependency? We might have issues if we need gems during > >>> build process that are not a part of distro. > > This is only one of the problems. > > > >> This a UI Doc building dependency, i.e. not needed when package is installed. > >> So someone/something doing a release and releasing the doc will need the ruby + > >> respective rubygem installed. > >> > >> If we want to automate the build and let the doc be built for example on koji, > >> I am afraid we would have to step back from using jsDuck, or let Petr package > >> it in Fedora since he used it despite my previous warnings :-) > > The problem is that ruby is still a fast moving target, and we do not > > want to waste time fighiting it when (not if) it will break and you find > > it just right before a release where you want to build docs. > > > > I really would like to avoid dependencies in Ruby in this project > > completely as long as possible. > > > >> Petr, we should think if we should keep UI doc and articles in devel repo or if > >> leave just the anonated code there and move all development articles and guides > >> to our new doc repo > >> http://www.freeipa.org/page/Contribute/Documentation > > moving to the doc repo does not solve the problem, really, we are still > > depending on a) ruby for generating docs, b) someone knowing Ruby to fix > > things when they will break. > > > > Simo. > > > It seems that doxygen does not work for JS for us. > So it is node.js vs. ruby vs. no generated docs. > Since we always can get back to "no docs" if things go really wrong I do > not see it as an option here. > I do not like either of the other two alternatives. And I do not know > which one would be best if any. the probelm, if I understood it correctly is that each of this systems have a different markup language, so switching later would mean also changing all the markup language in the code, high churn and lot of wasted work. I am assuming you use javadoc with javascript with doxygen, what does jsduck uses ? Or are we trying to generate just lists of functions from the actual code ? What is the value if there is no associated description of what the function does ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Sep 12 19:23:46 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Sep 2013 15:23:46 -0400 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <523211D3.3080504@redhat.com> References: <523200E9.5010304@redhat.com> <523211D3.3080504@redhat.com> Message-ID: <523214C2.2070401@redhat.com> Dmitri Pal wrote: > On 09/12/2013 01:59 PM, Ana Krivokapic wrote: >> Hello, >> >> The design document for $SUBJECT can be found at: >> http://www.freeipa.org/page/V3/Automember_rebuild_membership >> >> Related tickets: >> https://fedorahosted.org/freeipa/ticket/3752 >> https://fedorahosted.org/freeipa/ticket/3928 >> >> Thoughts, comments, questions welcome. >> > The names for commands are a bit long. > I am not sure we need all the commands. > > $ ipa automember-rebuild-membership --type=group > > I do not understand why type is "group". > If you say that all the user group memberships will be rebuilt then the > type is "user". > But then you can really not have the command at all and use just: > > ipa user-automembership > and > ipa host-automembership > > If in future we have other objects we would add another command for > those objects. > > so > ipa user-automembership --update > will update group memberships for all users, or may be it should be > ipa user-automembership --update * > (I do not know what are the rules in the framework, we should follow them) > > ipa user-automember --update LOGIN > will update group memberships for a specific user > > Now we need to differentiate --update and --reset > --update should update group membership based on the existing filters, > i.e. based on the automember plugin configuration only add missing > memberships (if any) > --reset should clean existing memberships and rebuild them based only > the default groups + automember. It should pretty much mean "make group > memberships as if the user was just added". > > Makes sense or I am missing something? Her design is consistent with the current automember commands. I think I'd drop the -membership part though, automember-rebuild is sufficient. For user/host perhaps user-automember-rebuild. I disagree with your update/reset suggestions. Unless a user is doing ALL of its group/hostgroup management via automember rules then the reset command will almost always do the wrong thing. This could raise all sorts of strange permission issues too, as we'd have to use the currently bound user to do the group membership removal. We can separately add delegation to create an automember rebuild task, and that runs as DM IIRC. I think I prefer rebuild to update, though update is probably a better description to what is happening under the hood. rob From dpal at redhat.com Thu Sep 12 19:46:51 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 12 Sep 2013 15:46:51 -0400 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <523214C2.2070401@redhat.com> References: <523200E9.5010304@redhat.com> <523211D3.3080504@redhat.com> <523214C2.2070401@redhat.com> Message-ID: <52321A2B.60302@redhat.com> On 09/12/2013 03:23 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 09/12/2013 01:59 PM, Ana Krivokapic wrote: >>> Hello, >>> >>> The design document for $SUBJECT can be found at: >>> http://www.freeipa.org/page/V3/Automember_rebuild_membership >>> >>> Related tickets: >>> https://fedorahosted.org/freeipa/ticket/3752 >>> https://fedorahosted.org/freeipa/ticket/3928 >>> >>> Thoughts, comments, questions welcome. >>> >> The names for commands are a bit long. >> I am not sure we need all the commands. >> >> $ ipa automember-rebuild-membership --type=group >> >> I do not understand why type is "group". >> If you say that all the user group memberships will be rebuilt then the >> type is "user". >> But then you can really not have the command at all and use just: >> >> ipa user-automembership >> and >> ipa host-automembership >> >> If in future we have other objects we would add another command for >> those objects. >> >> so >> ipa user-automembership --update >> will update group memberships for all users, or may be it should be >> ipa user-automembership --update * >> (I do not know what are the rules in the framework, we should follow >> them) >> >> ipa user-automember --update LOGIN >> will update group memberships for a specific user >> >> Now we need to differentiate --update and --reset >> --update should update group membership based on the existing filters, >> i.e. based on the automember plugin configuration only add missing >> memberships (if any) >> --reset should clean existing memberships and rebuild them based only >> the default groups + automember. It should pretty much mean "make group >> memberships as if the user was just added". >> >> Makes sense or I am missing something? > > Her design is consistent with the current automember commands. What are they? > > I think I'd drop the -membership part though, automember-rebuild is > sufficient. For user/host perhaps user-automember-rebuild. > > I disagree with your update/reset suggestions. We can have a separate RFE for reset but I think it would make sense for the cases when user moves from one org unit to another or moves from intern to full time. In this case I expect something like 1) Update user "class" attribute 2) Run automember reset > > Unless a user is doing ALL of its group/hostgroup management via > automember rules then the reset command will almost always do the > wrong thing. No it is need for the case when you need to get to the state as if this user was just added without actually deleting and re-addign the user. Use case like I mentioned above are examples. > This could raise all sorts of strange permission issues too, as we'd > have to use the currently bound user to do the group membership > removal. We can separately add delegation to create an automember > rebuild task, and that runs as DM IIRC. I agree that this would probably be a different task, like delete and rebuild. This I think we should create a separate ticket for reset and file and RFE with DS. It is not urgent but will become handy when we start supporting user lifecycle management and provisioning > > I think I prefer rebuild to update, though update is probably a better > description to what is happening under the hood. I do not have a preference. > > 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 Thu Sep 12 19:48:10 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 12 Sep 2013 15:48:10 -0400 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <1379013764.2804.1948.camel@willson.li.ssimo.org> References: <523049A5.10208@redhat.com> <1378916880.2804.1612.camel@willson.li.ssimo.org> <5230DF98.1040501@redhat.com> <5231563C.8090203@redhat.com> <1378991670.2804.1893.camel@willson.li.ssimo.org> <52320DE8.7050401@redhat.com> <1379013764.2804.1948.camel@willson.li.ssimo.org> Message-ID: <52321A7A.6040108@redhat.com> On 09/12/2013 03:22 PM, Simo Sorce wrote: > On Thu, 2013-09-12 at 14:54 -0400, Dmitri Pal wrote: >> On 09/12/2013 09:14 AM, Simo Sorce wrote: >>> On Thu, 2013-09-12 at 07:50 +0200, Martin Kosek wrote: >>>> On 09/11/2013 11:24 PM, Dmitri Pal wrote: >>>>> On 09/11/2013 12:28 PM, Simo Sorce wrote: >>>>>> On Wed, 2013-09-11 at 12:44 +0200, Petr Vobornik wrote: >>>>>>> Hello, >>>>>>> >>>>>>> This is a part of documentation effort which started couple month >>>>>>> ago. >>>>>>> Attached patches improves devel documentation of Web UI. Mostly by >>>>>>> annotating source code and then processing it by JSDuck tool[1]. >>>>>>> >>>>>>> The documentation is not complete - most plugins and member of some >>>>>>> core >>>>>>> widgets and facets are not annotated yet. I'm sending it now because >>>>>>> I >>>>>>> need to focus on more pressing tickets. >>>>>>> >>>>>>> You can see current state at my fedorapeople page [2]. >>>>>>> >>>>>>> I also converted 5 guides/articles which I wrote some time ago. >>>>>>> Guides >>>>>>> are also part of the JSDuck app [3]. >>>>>>> >>>>>>> The idea is to regularly generate the doc and place it on >>>>>>> docs.freeipa.org (not in production at the moment) so all doc would >>>>>>> be >>>>>>> on one place. >>>>>>> >>>>>>> Installation of JSDuck is documented on their page [4]. Basically it >>>>>>> requires ruby and JSDuck gem. >>>>>>> >>>>>>> Usage: >>>>>>> $ cd install/ui/doc >>>>>>> $ make >>>>>>> >>>>>>> Documentation is generated into: install/ui/build/code_doc directory >>>>>>> >>>>>>> [1] https://github.com/senchalabs/jsduck >>>>>>> [2] http://pvoborni.fedorapeople.org/doc >>>>>>> [3] http://pvoborni.fedorapeople.org/doc/#!/guide >>>>>>> [4] https://github.com/senchalabs/jsduck/wiki/Installation >>>>>> I would rather not grow a dependency on Ruby in the freeIPA project. >>>>>> Are there any alternatives ? >>>>>> >>>>>> Simo. >>>>>> >>>>> Is it dev side dependency? We might have issues if we need gems during >>>>> build process that are not a part of distro. >>> This is only one of the problems. >>> >>>> This a UI Doc building dependency, i.e. not needed when package is installed. >>>> So someone/something doing a release and releasing the doc will need the ruby + >>>> respective rubygem installed. >>>> >>>> If we want to automate the build and let the doc be built for example on koji, >>>> I am afraid we would have to step back from using jsDuck, or let Petr package >>>> it in Fedora since he used it despite my previous warnings :-) >>> The problem is that ruby is still a fast moving target, and we do not >>> want to waste time fighiting it when (not if) it will break and you find >>> it just right before a release where you want to build docs. >>> >>> I really would like to avoid dependencies in Ruby in this project >>> completely as long as possible. >>> >>>> Petr, we should think if we should keep UI doc and articles in devel repo or if >>>> leave just the anonated code there and move all development articles and guides >>>> to our new doc repo >>>> http://www.freeipa.org/page/Contribute/Documentation >>> moving to the doc repo does not solve the problem, really, we are still >>> depending on a) ruby for generating docs, b) someone knowing Ruby to fix >>> things when they will break. >>> >>> Simo. >>> >> It seems that doxygen does not work for JS for us. >> So it is node.js vs. ruby vs. no generated docs. >> Since we always can get back to "no docs" if things go really wrong I do >> not see it as an option here. >> I do not like either of the other two alternatives. And I do not know >> which one would be best if any. > the probelm, if I understood it correctly is that each of this systems > have a different markup language, so switching later would mean also > changing all the markup language in the code, high churn and lot of > wasted work. I am assuming you use javadoc with javascript with doxygen, > what does jsduck uses ? > > Or are we trying to generate just lists of functions from the actual > code ? What is the value if there is no associated description of what > the function does ? I think there are comments that he already added that come with functions that he is trying to extract. > > Simo. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From npmccallum at redhat.com Thu Sep 12 20:47:35 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 12 Sep 2013 16:47:35 -0400 Subject: [Freeipa-devel] [PATCH 0015] Add support for managing user auth types In-Reply-To: <1378353865.19352.9.camel@localhost> References: <1378353865.19352.9.camel@localhost> Message-ID: <1379018855.2210.0.camel@localhost> On Thu, 2013-09-05 at 00:04 -0400, Nathaniel McCallum wrote: > patch attached Update for ./makeapi attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0015-2-Add-support-for-managing-user-auth-types.patch Type: text/x-patch Size: 11248 bytes Desc: not available URL: From npmccallum at redhat.com Thu Sep 12 20:48:00 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 12 Sep 2013 16:48:00 -0400 Subject: [Freeipa-devel] [PATCH 0016] Add RADIUS proxy support to ipalib CLI In-Reply-To: <1378353973.19352.11.camel@localhost> References: <1378353973.19352.11.camel@localhost> Message-ID: <1379018880.2210.1.camel@localhost> On Thu, 2013-09-05 at 00:06 -0400, Nathaniel McCallum wrote: > patch attached Update for ./makeapi attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0016-2-Add-RADIUS-proxy-support-to-ipalib-CLI.patch Type: text/x-patch Size: 24763 bytes Desc: not available URL: From jcholast at redhat.com Fri Sep 13 07:21:33 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 13 Sep 2013 09:21:33 +0200 Subject: [Freeipa-devel] [PATCH 0016] Add RADIUS proxy support to ipalib CLI In-Reply-To: <1379018880.2210.1.camel@localhost> References: <1378353973.19352.11.camel@localhost> <1379018880.2210.1.camel@localhost> Message-ID: <5232BCFD.506@redhat.com> Hi, On 12.9.2013 22:48, Nathaniel McCallum wrote: > On Thu, 2013-09-05 at 00:06 -0400, Nathaniel McCallum wrote: >> patch attached > > Update for ./makeapi attached. > + if 'ipatokenradiusconfiglink' in entry_attrs: + cl = entry_attrs['ipatokenradiusconfiglink'] + if not cl: + entry_attrs['ipatokenradiususername'] = None + if 'ipatokenradiusproxyuser' in entry_attrs['objectclass']: + entry_attrs['objectclass'].remove('ipatokenradiusproxyuser') Is there are particular reason to remove the object class? I think you can just leave it there, that is what we do in other plugins. + else: + if 'ipatokenradiusproxyuser' not in entry_attrs['objectclass']: + entry_attrs['objectclass'].append('ipatokenradiusproxyuser') + + answer = self.api.Command.radius_show(cl) + entry_attrs['ipatokenradiusconfiglink'] = answer['result']['dn'] Please use self.api.Object.radius.get_dn_if_exists(cl) to get the DN instead of radius_show. The whole code block should be added to user_add as well. + radius = options.get('ipatokenradiusconfiglink', None) + if radius is not None: + answer = self.api.Command.radius_show(radius) + filter = filter.replace('(ipatokenradiusconfiglink=%s)' % radius, + '(ipatokenradiusconfiglink=%s)' % answer['result']['dn']) Again, use get_dn_if_exists instead of radius_show to get the DN. As for the filter processing, I think it would be safer to override args_options_2_entry in user_find and do it in there: def args_options_2_entry(self, *keys, **options): if 'ipatokenradiusconfiglink' in options: options['ipatokenradiusconfiglink'] = self.api.Object.radius.get_dn(options['ipatokenradiusconfiglink']) return super(user_find, self).args_options_2_entry( Honza -- Jan Cholasta From pspacek at redhat.com Fri Sep 13 07:29:32 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Sep 2013 09:29:32 +0200 Subject: [Freeipa-devel] DNS improvements: Should we add some sanity checking? In-Reply-To: <20130913070214.GU10627@redhat.com> References: <20130913070214.GU10627@redhat.com> Message-ID: <5232BEDC.5000000@redhat.com> Hello list, Jan Pazdziora proposed that 'ipa dns*' commands should do some sanity checking/waiting after the record is added to LDAP. I think that it could be valuable and I would like to get opinions from freeipa-devel list. === The problem === ipa dnsrecord-add and similar commands add the data to LDAP, but it doesn't mean that the data are *immediately* resolvable via DNS protocol. Note that data from LDAP are *asynchronously* read and processed by Named and the time when records are available is not predictable. A mismatch between LDAP can be caused by some connection problem between DNS and LDAP servers, LDAP or DNS server restart, or simply by a bug in DNS<->LDAP synchronization code. (This is becomming more and more important if we consider the whole DNSSEC effort and related re-factoring.) My experience is that users are very confused if the ipa dnsrecord-add command says 'record added' but it is still not available via DNS. It is really hard to debug when you see the problem first 10 times :-) === The proposal === 1. Let FreeIPA framework to change DNS data in LDAP as we do now. 2. After each change, do DNS queries for changed record and wait until the new data are available. IMHO it is very cheap operation (in usual cases 1 DNS packet back and forth) and it would save a lot of headaches to users and support. This will naturally catch the case where named crashes after the change etc. === Expected outcome === There will not be any failure like this: $ ipa-adtrust-install $ ipa dnszone-add $AD_DOMAIN --name-server=advm.$AD_DOMAIN --admin-email="hostmaster@$AD_DOMAIN.com" --force --forwarder=$AD_IP --forward-policy=only --ip-address=$AD_IP Zone name: dom123.example.com [...] $ ipa trust-add --type=ad DOM123.EXAMPLE.COM --admin Administrator --password Password for admin at DOM123.EXAMPLE.COM: ipa: ERROR: Cannot find specified domain or server name -- Petr^2 Spacek From jcholast at redhat.com Fri Sep 13 08:07:12 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 13 Sep 2013 10:07:12 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <1378355153.19352.29.camel@localhost> References: <1378355153.19352.29.camel@localhost> Message-ID: <5232C7B0.7090009@redhat.com> On 5.9.2013 06:25, Nathaniel McCallum wrote: > This patch has a few problems that I'd like some help with. There are a > few notes here as well. > > 1. The handling of the 'key' option is insecure. It should probably be > treated like a password (hidden from logs, etc). However, in this case, > it is binary, so I'm not quite sure how to do that. Passing it as a > command line option may be nice for scripting, but is potentially a > security problem if it ends up in bash.history. It would also be nice if > the encoding were base32 instead of base64, since nearly all the OTP > tools use this encoding. > > 2. The 'key' option also appears in otp-find. I'd like to suppress this. > How? > > 3. I had to make the 'id' option optional to make the uuid > autogeneration work in otp-add. However, this has the side-effect that > 'id' is now optional in all the other commands. This is particularly bad > in the case of otp-del, where calling this command with no ID > transparently removes all tokens. How can I make this optional for > otp-add but required for all other commands? > > 4. otp-import is not implemented. I spent a few hours looking and I > didn't find any otp tool that actually uses this xml format for > exporting. Should we implement this now or wait until someone can > actually export data to us? > > 5. otp-del happily deletes the last token for a user. How can I find out > the dn of the user executing the command? Also, what is the right > exception to throw in pre_callback()? > > 6. user-show does not list the associated tokens for this user. Do we > care? It is a single search: otp-find --owner npmccallum. > > 7. otp-add only prints the qr code if the --qrcode option is specified. > This is for two reasons. First, and most importantly, the qr code > doesn't fit on a standard 24x80 terminal. I wanted to avoid dumping > garbage on people's screens by default. Second, you may not always want > the qr code output (like for a hard token or manual code entry). > > Nathaniel > First, a nitpick: - values=(u'password', u'radius'), + values=(u'password', u'radius', u'otp'), + at register() +class otp(LDAPObject): IMO naming the authentication type and plugin just "otp" is confusing. We already support one time passwords for users (and hosts as well), so "otp" is ambiguous. I think you should at least rename the plugin to "otptoken". + # Resolve the user's dn + owner = entry_attrs.get('ipatokenowner', None) + if owner is not None: + result = self.api.Command.user_show(owner)['result'] + owner = entry_attrs['ipatokenowner'] = result['dn'] I think you can rewrite the above as: + # Resolve the user's dn + owner = entry_attrs.get('ipatokenowner', None) + if owner is not None: + owner = self.api.Object.user.get_dn(owner) + entry_attrs['ipatokenowner'] = owner This will save you several LDAP searches. You don't have to use get_dn_if_exists here, because if the user does not exist, it will be catched later in the "Get the issuer for the URI" block. + self.uri = "otpauth://totp/%s:%s?%s" % (args['issuer'], label, parameters) You can't do this, because plugins are singletons. See the user and host plugins for how they handle the randompassword virtual attribute for inspiration. + entry_attrs['uri'] = self.uri Please add a proper param to otp_add's output_params for "uri". + filters = filters.replace("(ipatokenowner=%s)" % owner, + "(ipatokenowner=%s)" % result['dn']) Please do this in opt_find.args_options_2_entry (see my reply to your radius CLI patches for details). Honza -- Jan Cholasta From mkosek at redhat.com Fri Sep 13 08:16:58 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Sep 2013 10:16:58 +0200 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <52321A2B.60302@redhat.com> References: <523200E9.5010304@redhat.com> <523211D3.3080504@redhat.com> <523214C2.2070401@redhat.com> <52321A2B.60302@redhat.com> Message-ID: <5232C9FA.1020904@redhat.com> On 09/12/2013 09:46 PM, Dmitri Pal wrote: > On 09/12/2013 03:23 PM, Rob Crittenden wrote: >> Dmitri Pal wrote: >>> On 09/12/2013 01:59 PM, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> The design document for $SUBJECT can be found at: >>>> http://www.freeipa.org/page/V3/Automember_rebuild_membership >>>> >>>> Related tickets: >>>> https://fedorahosted.org/freeipa/ticket/3752 >>>> https://fedorahosted.org/freeipa/ticket/3928 >>>> >>>> Thoughts, comments, questions welcome. >>>> >>> The names for commands are a bit long. >>> I am not sure we need all the commands. >>> >>> $ ipa automember-rebuild-membership --type=group >>> >>> I do not understand why type is "group". >>> If you say that all the user group memberships will be rebuilt then the >>> type is "user". >>> But then you can really not have the command at all and use just: >>> >>> ipa user-automembership >>> and >>> ipa host-automembership >>> >>> If in future we have other objects we would add another command for >>> those objects. >>> >>> so >>> ipa user-automembership --update >>> will update group memberships for all users, or may be it should be >>> ipa user-automembership --update * >>> (I do not know what are the rules in the framework, we should follow >>> them) >>> >>> ipa user-automember --update LOGIN >>> will update group memberships for a specific user >>> >>> Now we need to differentiate --update and --reset >>> --update should update group membership based on the existing filters, >>> i.e. based on the automember plugin configuration only add missing >>> memberships (if any) >>> --reset should clean existing memberships and rebuild them based only >>> the default groups + automember. It should pretty much mean "make group >>> memberships as if the user was just added". >>> >>> Makes sense or I am missing something? >> >> Her design is consistent with the current automember commands. > > What are they? ipa automember-show --type=hostgroup webservers ipa automember-add --type=group devel > >> >> I think I'd drop the -membership part though, automember-rebuild is >> sufficient. For user/host perhaps user-automember-rebuild. +1, this is shorter. >> >> I disagree with your update/reset suggestions. > > We can have a separate RFE for reset but I think it would make sense for > the cases when user moves from one org unit to another or moves from > intern to full time. > In this case I expect something like > 1) Update user "class" attribute > 2) Run automember reset Hmm, I must say I do not like the reset option very much too. Someone may not realize what is the real scope or meaning of the option and find out all his membership is gone. Nothing prevents Administrator to explicitly remove all user membership before moving to other role/function. It is a matter of 3 clicks in Web UI. > >> >> Unless a user is doing ALL of its group/hostgroup management via >> automember rules then the reset command will almost always do the >> wrong thing. > > No it is need for the case when you need to get to the state as if this > user was just added without actually deleting and re-addign the user. > Use case like I mentioned above are examples. > >> This could raise all sorts of strange permission issues too, as we'd >> have to use the currently bound user to do the group membership >> removal. We can separately add delegation to create an automember >> rebuild task, and that runs as DM IIRC. > > I agree that this would probably be a different task, like delete and > rebuild. This I think we should create a separate ticket for reset and > file and RFE with DS. It is not urgent but will become handy when we > start supporting user lifecycle management and provisioning Still not convinced this the way we should go and that life-cycle management would require rinsing all membership data. Martin From tbabej at redhat.com Fri Sep 13 08:18:10 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 13 Sep 2013 10:18:10 +0200 Subject: [Freeipa-devel] DNS improvements: Should we add some sanity checking? In-Reply-To: <5232BEDC.5000000@redhat.com> References: <20130913070214.GU10627@redhat.com> <5232BEDC.5000000@redhat.com> Message-ID: <5232CA42.2000406@redhat.com> On 09/13/2013 09:29 AM, Petr Spacek wrote: > Hello list, > > Jan Pazdziora proposed that 'ipa dns*' > commands should do some sanity checking/waiting after the record is > added to LDAP. > > I think that it could be valuable and I would like to get opinions > from freeipa-devel list. > > +1! > === The problem === > ipa dnsrecord-add and similar commands add the data to LDAP, but it > doesn't mean that the data are *immediately* resolvable via DNS > protocol. Note that data from LDAP are *asynchronously* read and > processed by Named and the time when records are available is not > predictable. > > A mismatch between LDAP can be caused by some connection problem > between DNS and LDAP servers, LDAP or DNS server restart, or simply by > a bug in DNS<->LDAP synchronization code. (This is becomming more and > more important if we consider the whole DNSSEC effort and related > re-factoring.) > > My experience is that users are very confused if the ipa dnsrecord-add > command says 'record added' but it is still not available via DNS. It > is really hard to debug when you see the problem first 10 times :-) > > > === The proposal === > 1. Let FreeIPA framework to change DNS data in LDAP as we do now. > 2. After each change, do DNS queries for changed record and wait until > the new data are available. > > IMHO it is very cheap operation (in usual cases 1 DNS packet back and > forth) and it would save a lot of headaches to users and support. We should make sure that we do not wait indefinitely here in case there's something else wrong with the named. We could wait for DNS data to be made available up to small reasonable timeout. If the check succeeds, we can output "Verified: Yes" along with the usual ipa dns(whatever) command output. Otherwise, we could print out "Verified: No" $ ipa dnszone-add $AD_DOMAIN --name-server=advm.$AD_DOMAIN --admin-email="hostmaster@$AD_DOMAIN.com" --force --forwarder=$AD_IP --forward-policy=only --ip-address=$AD_IP Zone name: tbad.ipa.com Authoritative nameserver: advm.tbad.ipa.com Administrator e-mail address: hostmaster.tbad.ipa.com.com. SOA serial: 1378285614 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant DOM007.TBAD.IPA.COM krb5-self * A; grant DOM007.TBAD.IPA.COM krb5-self * AAAA; grant DOM007.TBAD.IPA.COM krb5-self * SSHFP; Active zone: TRUE Dynamic update: FALSE Allow query: any; Allow transfer: none; Zone forwarders: 192.168.122.20 Forward policy: only Verified: Yes However, it would be nice to print out "Verified: No" in a somewhat emphasized manner. I created the following ticket: https://fedorahosted.org/freeipa/ticket/3930 > > This will naturally catch the case where named crashes after the > change etc. > > > === Expected outcome === > There will not be any failure like this: > We debugged this with Petr few days ago as part of CI testing for trusts, I'll just provide detailed explanation here: > $ ipa-adtrust-install Ipa-adtrust-install restarts Directory Server as one of the installation steps. Named looses connection to the LDAP server and by default reconnects in 60 seconds. > > $ ipa dnszone-add $AD_DOMAIN --name-server=advm.$AD_DOMAIN > --admin-email="hostmaster@$AD_DOMAIN.com" --force --forwarder=$AD_IP > --forward-policy=only --ip-address=$AD_IP > Zone name: dom123.example.com > [...] > Ipa dnszone-add writes to LDAP and reports success. > $ ipa trust-add --type=ad DOM123.EXAMPLE.COM --admin Administrator > --password > Password for admin at DOM123.EXAMPLE.COM: > ipa: ERROR: Cannot find specified domain or server name > Named is unable to find the domain, since the connection is down. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Sep 13 08:26:38 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Sep 2013 10:26:38 +0200 Subject: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments Message-ID: <5232CC3E.1010401@redhat.com> Hello list, FreeIPA deployments in cloud environments do not work very well because 'clouds' break some assumptions we made during FreeIPA's design. We should fix it somehow :-) === Problems === - A machine has two host names in DNS: -- The first name is internal to the cloud and resolvable only from inside of the cloud. --- This name should be used for communication inside cloud. --- E.g. 'ipa.cust1.cloud.' --- Internal name is mapped to internal IP address, see below. -- The second name is external to the cloud and should be used for communication between the Internet and cloud. --- E.g. 'ipa.example.com.' --- External name maps to external IP address, see below. - A machine has two IP addresses: -- Internal, private IP address configured at the machine's interface --- Typically the only IP address known to the machine. --- E.g. 192.0.2.22 --- IP address can change dynamically, at least after a machine reboot. -- External, public IP address: --- Typically mapped to internal address at cloud boundary (NAT). --- E.g. 203.0.113.113 --- IP address can change dynamically, at least after a machine reboot. Related tickets: https://fedorahosted.org/freeipa/ticket/2648 https://fedorahosted.org/freeipa/ticket/2715 The natural request is to add support for DNS views/split horizon DNS into FreeIPA, so different names and IP addresses can be served to clients inside and outside of the cloud. Is it enough? What else should we change to make FreeIPA reliable in clouds? What are use cases? Do we want to support clients *outside* of the cloud connecting to FreeIPA servers *inside* of the cloud? What about PKI certificates? Should we put two names to each certificate? What we should do after host name change? (I do not have enough information when the host name changes.) What about Kerberos? How it will play with host name change? How should we handle the fact that internal and external names are different? Should we use some sort of referral mechanism? Cloud users, please speak now :-) Opinions are more than welcome! -- Petr^2 Spacek From mkosek at redhat.com Fri Sep 13 08:48:39 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Sep 2013 10:48:39 +0200 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <523200E9.5010304@redhat.com> References: <523200E9.5010304@redhat.com> Message-ID: <5232D167.30201@redhat.com> On 09/12/2013 07:59 PM, Ana Krivokapic wrote: > Hello, > > The design document for $SUBJECT can be found at: > http://www.freeipa.org/page/V3/Automember_rebuild_membership > > Related tickets: > https://fedorahosted.org/freeipa/ticket/3752 > https://fedorahosted.org/freeipa/ticket/3928 > > Thoughts, comments, questions welcome. > Besides membership reset discussion happening in second thread I other comments. 1) I think we should also design permission&ACIs for the automember rebuild task creation (cn=automember rebuild membership,cn=tasks,cn=config container). You can talk to Petr3 about that as he is current working on redesigning ACIs. Just so that you are in sync. 2) About the "Implementation" part and "automember rebuild membership" I do not think this is good approach. I do not know how do you plan doing the confirmation I do not think this workflow would work with our framework. We do not have support for confirming except if you would implement it in interactive_prompt_callback. But then the functionality would not be available for Web UI. I would rather add an option --dry-run or --test for all new automember commands which would return how would the updated entry look like. BTW, did the automember export updates task work for you? I tried this LDIF and /tmp/automember.ldif was empty: dn: cn=my export task 1, cn=automember export updates,cn=tasks,cn=config changetype: add objectClass: top objectClass: extensibleObject cn: my export task 1 basedn: cn=accounts,dc=example,dc=com filter: (uid=*) scope: sub ldif: /tmp/automember.ldif Adding Mark to CC in case if he has any advise for utilizing the export task in FreeIPA. By the way, using this approach I think we would also hit issues with permissions on the resulting LDIF, given it is created by DS and would be read by Apache. SELinux would be complaining as well. To sum it up, I am not sure this will be that easy and straightforward. Martin From jcholast at redhat.com Fri Sep 13 08:51:24 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 13 Sep 2013 10:51:24 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <522840B4.30709@redhat.com> References: <52161568.7060702@redhat.com> <52245136.1090804@redhat.com> <52260B6B.7050906@redhat.com> <522840B4.30709@redhat.com> Message-ID: <5232D20C.9050204@redhat.com> On 5.9.2013 10:28, Jan Cholasta wrote: > On 3.9.2013 18:16, Dmitri Pal wrote: >> On 09/02/2013 04:49 AM, Petr Spacek wrote: >>> On 22.8.2013 15:43, Jan Cholasta wrote: >>>> Hi, >>>> >>>> I'm currently investigating support for multiple CA certificates in >>>> LDAP >>>> (, >>>> ). This will be useful >>>> for CA >>>> certificate renewal (, >>>> ) and using >>>> certificates issued >>>> by custom CAs for IPA HTTP and directory server instances >>>> (). >>>> >>>> The biggest issue is how to make IPA clients aware of CA certificate >>>> changes. >>>> One of the tickets suggests polling the LDAP server from SSSD. Would >>>> that be >>>> sufficient? Perhaps a combination of polling and detecting >>>> certificate changes >>>> when connecting to LDAP would be better? >>>> >>>> Another issue is how to handle updating IPA systems with new CA >>>> certificate(s). On clients it is probably sufficient to store the >>>> certificate(s) in /etc/ipa/ca.crt, but on servers there are multiple >>>> places >>>> where the update needs to be done (HTTP and directory server NSS >>>> databases, >>>> KDC pkinit_anchors file, etc.). IMO doing all this from SSSD is >>>> unrealistic, >>>> so there should be a way to do this externally. The simplest thing >>>> that comes >>>> to mind is that SSSD would execute an external script to do the >>>> update when it >>>> detects changes, but I'm not sure how well would that work with >>>> SELinux in the >>>> picture. Is there a better way to do this? >>> >>> It reminds me problems with key-rotation for DNSSEC. >>> >>> Could we find common problems and use the same/similar solution for >>> both problems? >>> >>> An extension for certmonger? Oddjob? Or a completely new daemon? >>> >> Certmonger already has a way to: >> 1) Check things periodically >> 2) Hand certs in different places >> 3) Run post op scripts >> >> IMO it is a good candidate but I would leave it to Nalin to chime in. >> > > I would expect more things that require periodic checking on clients > beyond certificates to come in the future, so I'm not sure if doing this > in certmonger is the right thing to do. Also, SSSD already does a > similar thing for realm domains, right? > > Honza > So, does anyone have any strong opinions on this? -- Jan Cholasta From mkosek at redhat.com Fri Sep 13 08:53:36 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Sep 2013 10:53:36 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <5232D20C.9050204@redhat.com> References: <52161568.7060702@redhat.com> <52245136.1090804@redhat.com> <52260B6B.7050906@redhat.com> <522840B4.30709@redhat.com> <5232D20C.9050204@redhat.com> Message-ID: <5232D290.40504@redhat.com> On 09/13/2013 10:51 AM, Jan Cholasta wrote: > On 5.9.2013 10:28, Jan Cholasta wrote: >> On 3.9.2013 18:16, Dmitri Pal wrote: >>> On 09/02/2013 04:49 AM, Petr Spacek wrote: >>>> On 22.8.2013 15:43, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> I'm currently investigating support for multiple CA certificates in >>>>> LDAP >>>>> (, >>>>> ). This will be useful >>>>> for CA >>>>> certificate renewal (, >>>>> ) and using >>>>> certificates issued >>>>> by custom CAs for IPA HTTP and directory server instances >>>>> (). >>>>> >>>>> The biggest issue is how to make IPA clients aware of CA certificate >>>>> changes. >>>>> One of the tickets suggests polling the LDAP server from SSSD. Would >>>>> that be >>>>> sufficient? Perhaps a combination of polling and detecting >>>>> certificate changes >>>>> when connecting to LDAP would be better? >>>>> >>>>> Another issue is how to handle updating IPA systems with new CA >>>>> certificate(s). On clients it is probably sufficient to store the >>>>> certificate(s) in /etc/ipa/ca.crt, but on servers there are multiple >>>>> places >>>>> where the update needs to be done (HTTP and directory server NSS >>>>> databases, >>>>> KDC pkinit_anchors file, etc.). IMO doing all this from SSSD is >>>>> unrealistic, >>>>> so there should be a way to do this externally. The simplest thing >>>>> that comes >>>>> to mind is that SSSD would execute an external script to do the >>>>> update when it >>>>> detects changes, but I'm not sure how well would that work with >>>>> SELinux in the >>>>> picture. Is there a better way to do this? >>>> >>>> It reminds me problems with key-rotation for DNSSEC. >>>> >>>> Could we find common problems and use the same/similar solution for >>>> both problems? >>>> >>>> An extension for certmonger? Oddjob? Or a completely new daemon? >>>> >>> Certmonger already has a way to: >>> 1) Check things periodically >>> 2) Hand certs in different places >>> 3) Run post op scripts >>> >>> IMO it is a good candidate but I would leave it to Nalin to chime in. >>> >> >> I would expect more things that require periodic checking on clients >> beyond certificates to come in the future, so I'm not sure if doing this >> in certmonger is the right thing to do. Also, SSSD already does a >> similar thing for realm domains, right? Are you suggesting extending SSSD to handle that? >> >> Honza >> > > So, does anyone have any strong opinions on this? Not at this point. BTW, is there any reason why we cannot go the simple way and just utilize cron and a script? Previously we just dropped conf to /etc/cron.d for ipa-compliance script and it worked quite well. Martin From jcholast at redhat.com Fri Sep 13 09:05:39 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 13 Sep 2013 11:05:39 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <5232D290.40504@redhat.com> References: <52161568.7060702@redhat.com> <52245136.1090804@redhat.com> <52260B6B.7050906@redhat.com> <522840B4.30709@redhat.com> <5232D20C.9050204@redhat.com> <5232D290.40504@redhat.com> Message-ID: <5232D563.3050500@redhat.com> On 13.9.2013 10:53, Martin Kosek wrote: > On 09/13/2013 10:51 AM, Jan Cholasta wrote: >> On 5.9.2013 10:28, Jan Cholasta wrote: >>> On 3.9.2013 18:16, Dmitri Pal wrote: >>>> On 09/02/2013 04:49 AM, Petr Spacek wrote: >>>>> It reminds me problems with key-rotation for DNSSEC. >>>>> >>>>> Could we find common problems and use the same/similar solution for >>>>> both problems? >>>>> >>>>> An extension for certmonger? Oddjob? Or a completely new daemon? >>>>> >>>> Certmonger already has a way to: >>>> 1) Check things periodically >>>> 2) Hand certs in different places >>>> 3) Run post op scripts >>>> >>>> IMO it is a good candidate but I would leave it to Nalin to chime in. >>>> >>> >>> I would expect more things that require periodic checking on clients >>> beyond certificates to come in the future, so I'm not sure if doing this >>> in certmonger is the right thing to do. Also, SSSD already does a >>> similar thing for realm domains, right? > > Are you suggesting extending SSSD to handle that? Yes. > >>> >>> Honza >>> >> >> So, does anyone have any strong opinions on this? > > Not at this point. BTW, is there any reason why we cannot go the simple way and > just utilize cron and a script? Previously we just dropped conf to /etc/cron.d > for ipa-compliance script and it worked quite well. Hmm, that's so simple it might just work. At least until there is a better way. > > Martin > -- Jan Cholasta From jhrozek at redhat.com Fri Sep 13 11:47:11 2013 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 13 Sep 2013 13:47:11 +0200 Subject: [Freeipa-devel] Multiple CA certificates in LDAP, questions In-Reply-To: <522840B4.30709@redhat.com> References: <52161568.7060702@redhat.com> <52245136.1090804@redhat.com> <52260B6B.7050906@redhat.com> <522840B4.30709@redhat.com> Message-ID: <20130913114711.GG2954@hendrix.brq.redhat.com> On Thu, Sep 05, 2013 at 10:28:36AM +0200, Jan Cholasta wrote: > On 3.9.2013 18:16, Dmitri Pal wrote: > >On 09/02/2013 04:49 AM, Petr Spacek wrote: > >>On 22.8.2013 15:43, Jan Cholasta wrote: > >>>Hi, > >>> > >>>I'm currently investigating support for multiple CA certificates in LDAP > >>>(, > >>>). This will be useful > >>>for CA > >>>certificate renewal (, > >>>) and using > >>>certificates issued > >>>by custom CAs for IPA HTTP and directory server instances > >>>(). > >>> > >>>The biggest issue is how to make IPA clients aware of CA certificate > >>>changes. > >>>One of the tickets suggests polling the LDAP server from SSSD. Would > >>>that be > >>>sufficient? Perhaps a combination of polling and detecting > >>>certificate changes > >>>when connecting to LDAP would be better? > >>> > >>>Another issue is how to handle updating IPA systems with new CA > >>>certificate(s). On clients it is probably sufficient to store the > >>>certificate(s) in /etc/ipa/ca.crt, but on servers there are multiple > >>>places > >>>where the update needs to be done (HTTP and directory server NSS > >>>databases, > >>>KDC pkinit_anchors file, etc.). IMO doing all this from SSSD is > >>>unrealistic, > >>>so there should be a way to do this externally. The simplest thing > >>>that comes > >>>to mind is that SSSD would execute an external script to do the > >>>update when it > >>>detects changes, but I'm not sure how well would that work with > >>>SELinux in the > >>>picture. Is there a better way to do this? > >> > >>It reminds me problems with key-rotation for DNSSEC. > >> > >>Could we find common problems and use the same/similar solution for > >>both problems? > >> > >>An extension for certmonger? Oddjob? Or a completely new daemon? > >> > >Certmonger already has a way to: > >1) Check things periodically > >2) Hand certs in different places > >3) Run post op scripts > > > >IMO it is a good candidate but I would leave it to Nalin to chime in. > > > > I would expect more things that require periodic checking on clients > beyond certificates to come in the future, so I'm not sure if doing > this in certmonger is the right thing to do. Also, SSSD already does > a similar thing for realm domains, right? > > Honza Sorry, didn't notice the "sssd" keyword until now. Yes, we re-check and update domains every 30 seconds and right after startup as well. From pvoborni at redhat.com Fri Sep 13 11:54:06 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 13 Sep 2013 13:54:06 +0200 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <1379013764.2804.1948.camel@willson.li.ssimo.org> References: <523049A5.10208@redhat.com> <1378916880.2804.1612.camel@willson.li.ssimo.org> <5230DF98.1040501@redhat.com> <5231563C.8090203@redhat.com> <1378991670.2804.1893.camel@willson.li.ssimo.org> <52320DE8.7050401@redhat.com> <1379013764.2804.1948.camel@willson.li.ssimo.org> Message-ID: <5232FCDE.1020804@redhat.com> On 09/12/2013 09:22 PM, Simo Sorce wrote: > On Thu, 2013-09-12 at 14:54 -0400, Dmitri Pal wrote: >> On 09/12/2013 09:14 AM, Simo Sorce wrote: >>> On Thu, 2013-09-12 at 07:50 +0200, Martin Kosek wrote: >>>> On 09/11/2013 11:24 PM, Dmitri Pal wrote: >>>>> On 09/11/2013 12:28 PM, Simo Sorce wrote: >>>>>> On Wed, 2013-09-11 at 12:44 +0200, Petr Vobornik wrote: >>>>>>> Hello, >>>>>>> >>>>>>> This is a part of documentation effort which started couple month >>>>>>> ago. >>>>>>> Attached patches improves devel documentation of Web UI. Mostly by >>>>>>> annotating source code and then processing it by JSDuck tool[1]. >>>>>>> >>>>>>> The documentation is not complete - most plugins and member of some >>>>>>> core >>>>>>> widgets and facets are not annotated yet. I'm sending it now because >>>>>>> I >>>>>>> need to focus on more pressing tickets. >>>>>>> >>>>>>> You can see current state at my fedorapeople page [2]. >>>>>>> >>>>>>> I also converted 5 guides/articles which I wrote some time ago. >>>>>>> Guides >>>>>>> are also part of the JSDuck app [3]. >>>>>>> >>>>>>> The idea is to regularly generate the doc and place it on >>>>>>> docs.freeipa.org (not in production at the moment) so all doc would >>>>>>> be >>>>>>> on one place. >>>>>>> >>>>>>> Installation of JSDuck is documented on their page [4]. Basically it >>>>>>> requires ruby and JSDuck gem. >>>>>>> >>>>>>> Usage: >>>>>>> $ cd install/ui/doc >>>>>>> $ make >>>>>>> >>>>>>> Documentation is generated into: install/ui/build/code_doc directory >>>>>>> >>>>>>> [1] https://github.com/senchalabs/jsduck >>>>>>> [2] http://pvoborni.fedorapeople.org/doc >>>>>>> [3] http://pvoborni.fedorapeople.org/doc/#!/guide >>>>>>> [4] https://github.com/senchalabs/jsduck/wiki/Installation >>>>>> I would rather not grow a dependency on Ruby in the freeIPA project. >>>>>> Are there any alternatives ? >>>>>> >>>>>> Simo. >>>>>> >>>>> Is it dev side dependency? We might have issues if we need gems during >>>>> build process that are not a part of distro. >>> This is only one of the problems. >>> >>>> This a UI Doc building dependency, i.e. not needed when package is installed. >>>> So someone/something doing a release and releasing the doc will need the ruby + >>>> respective rubygem installed. >>>> >>>> If we want to automate the build and let the doc be built for example on koji, >>>> I am afraid we would have to step back from using jsDuck, or let Petr package >>>> it in Fedora since he used it despite my previous warnings :-) >>> The problem is that ruby is still a fast moving target, and we do not >>> want to waste time fighiting it when (not if) it will break and you find >>> it just right before a release where you want to build docs. >>> >>> I really would like to avoid dependencies in Ruby in this project >>> completely as long as possible. >>> >>>> Petr, we should think if we should keep UI doc and articles in devel repo or if >>>> leave just the anonated code there and move all development articles and guides >>>> to our new doc repo >>>> http://www.freeipa.org/page/Contribute/Documentation >>> moving to the doc repo does not solve the problem, really, we are still >>> depending on a) ruby for generating docs, b) someone knowing Ruby to fix >>> things when they will break. >>> >>> Simo. >>> >> It seems that doxygen does not work for JS for us. >> So it is node.js vs. ruby vs. no generated docs. >> Since we always can get back to "no docs" if things go really wrong I do >> not see it as an option here. >> I do not like either of the other two alternatives. And I do not know >> which one would be best if any. > > the probelm, if I understood it correctly is that each of this systems > have a different markup language, so switching later would mean also > changing all the markup language in the code, high churn and lot of > wasted work. I am assuming you use javadoc with javascript with doxygen, > what does jsduck uses ? jsduck, yuidoc, jsdoc and doxygen use some flavor of javadoc. They are not compatible though. With regular expressions, existing comments can be easily converted ie. into yuidoc. But it would still require some additional work because jsduck leverages code introspection, but most of the others doesn't so one would have to add the missing information. > > Or are we trying to generate just lists of functions from the actual > code ? What is the value if there is no associated description of what > the function does ? > > Simo. > It's not just list of members. Added values (general and some jsduck specific): - list of classes grouped by usage (main page) - list of events which might not be regular member (just a documented one) - descriptions for functions and properties where purpose is not clear from their name - examples of usage for some classes/members - inheritance chain parent class, mixin classes, subclasses - info about which parent's method was overridden by a method - search (classes, members; doesn't require server side) - filter by member name - filter by member type: deprecated/protected/public/inherited - guides where you can write: 'classname.membername' and it will automatically make you a link do relevant doc Doc build checks: - check if documented type is declared - check if member has description - check if annotation has correct format - check if member belongs to declared class - check if overriden member exists - duplicate members, params Not sure if I should elaborate more on usecases (experiences devel vs web ui newbie, ...). -- Petr Vobornik From akrivoka at redhat.com Fri Sep 13 12:53:25 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 13 Sep 2013 14:53:25 +0200 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <5232D167.30201@redhat.com> References: <523200E9.5010304@redhat.com> <5232D167.30201@redhat.com> Message-ID: <52330AC5.2000708@redhat.com> On 09/13/2013 10:48 AM, Martin Kosek wrote: > On 09/12/2013 07:59 PM, Ana Krivokapic wrote: >> Hello, >> >> The design document for $SUBJECT can be found at: >> http://www.freeipa.org/page/V3/Automember_rebuild_membership >> >> Related tickets: >> https://fedorahosted.org/freeipa/ticket/3752 >> https://fedorahosted.org/freeipa/ticket/3928 >> >> Thoughts, comments, questions welcome. >> > Besides membership reset discussion happening in second thread I other comments. > > 1) I think we should also design permission&ACIs for the automember rebuild > task creation (cn=automember rebuild membership,cn=tasks,cn=config container). > You can talk to Petr3 about that as he is current working on redesigning ACIs. > Just so that you are in sync. > > 2) About the "Implementation" part and "automember rebuild membership" > > I do not think this is good approach. I do not know how do you plan doing the > confirmation > > I do not think this workflow would work with our framework. We do not have > support for confirming except if you would implement it in > interactive_prompt_callback. But then the functionality would not be available > for Web UI. > > I would rather add an option --dry-run or --test for all new automember > commands which would return how would the updated entry look like. My plan was to use the interactive_prompt_callback for the CLI, but the approach with --dry-run sounds better. So effectively, the --dry-run option would invoke the automember export updates task, while the command without --dry-run would invoke the automember rebuild membership task. In the web UI, a click on the "rebuild membership" button/link would present the user with the list of candidate entries (command with --dry-run is called), and then after confirmation, the command without --dry-run would be called. Does it make sense? > BTW, did the > automember export updates task work for you? I tried this LDIF and > /tmp/automember.ldif was empty: > > dn: cn=my export task 1, cn=automember export updates,cn=tasks,cn=config > changetype: add > objectClass: top > objectClass: extensibleObject > cn: my export task 1 > basedn: cn=accounts,dc=example,dc=com > filter: (uid=*) > scope: sub > ldif: /tmp/automember.ldif > > Adding Mark to CC in case if he has any advise for utilizing the export task in > FreeIPA. I came across this issue while doing initial investigation, and reported it here: https://fedorahosted.org/389/ticket/47507. As a workaround, Mark suggested to use a different value for the basedn parameter in the above ldif: cn=computers,cn=accounts,dc=example,dc=com - for hosts cn=users,cn=accounts,dc=example,dc=com - for users This worked for me, but seemed to cause a hang of the DS server when the ldif is executed. The issue seems to be in the schema compat plugin. Bugzillas have been open to address this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1007451 https://bugzilla.redhat.com/show_bug.cgi?id=1007453 To work around _this_ problem, disabling the schema compat plugin seems to do the trick: $ ipa-compat-manage disable To sum it up, in order to test the automember tasks, you need to: 1. Change the 'basedn' parameter in the above ldif (as described above) 2. Disable the schema compat plugin > > By the way, using this approach I think we would also hit issues with > permissions on the resulting LDIF, given it is created by DS and would be read > by Apache. SELinux would be complaining as well. To sum it up, I am not sure > this will be that easy and straightforward. > > Martin -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From akrivoka at redhat.com Fri Sep 13 13:01:14 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 13 Sep 2013 15:01:14 +0200 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <5232C9FA.1020904@redhat.com> References: <523200E9.5010304@redhat.com> <523211D3.3080504@redhat.com> <523214C2.2070401@redhat.com> <52321A2B.60302@redhat.com> <5232C9FA.1020904@redhat.com> Message-ID: <52330C9A.80208@redhat.com> On 09/13/2013 10:16 AM, Martin Kosek wrote: > On 09/12/2013 09:46 PM, Dmitri Pal wrote: >> On 09/12/2013 03:23 PM, Rob Crittenden wrote: >>> Dmitri Pal wrote: >>>> On 09/12/2013 01:59 PM, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> The design document for $SUBJECT can be found at: >>>>> http://www.freeipa.org/page/V3/Automember_rebuild_membership >>>>> >>>>> Related tickets: >>>>> https://fedorahosted.org/freeipa/ticket/3752 >>>>> https://fedorahosted.org/freeipa/ticket/3928 >>>>> >>>>> Thoughts, comments, questions welcome. >>>>> >>>> The names for commands are a bit long. >>>> I am not sure we need all the commands. >>>> >>>> $ ipa automember-rebuild-membership --type=group >>>> >>>> I do not understand why type is "group". >>>> If you say that all the user group memberships will be rebuilt then the >>>> type is "user". >>>> But then you can really not have the command at all and use just: >>>> >>>> ipa user-automembership >>>> and >>>> ipa host-automembership >>>> >>>> If in future we have other objects we would add another command for >>>> those objects. >>>> >>>> so >>>> ipa user-automembership --update >>>> will update group memberships for all users, or may be it should be >>>> ipa user-automembership --update * >>>> (I do not know what are the rules in the framework, we should follow >>>> them) >>>> >>>> ipa user-automember --update LOGIN >>>> will update group memberships for a specific user >>>> >>>> Now we need to differentiate --update and --reset >>>> --update should update group membership based on the existing filters, >>>> i.e. based on the automember plugin configuration only add missing >>>> memberships (if any) >>>> --reset should clean existing memberships and rebuild them based only >>>> the default groups + automember. It should pretty much mean "make group >>>> memberships as if the user was just added". >>>> >>>> Makes sense or I am missing something? >>> Her design is consistent with the current automember commands. >> What are they? > ipa automember-show --type=hostgroup webservers > ipa automember-add --type=group devel > >>> I think I'd drop the -membership part though, automember-rebuild is >>> sufficient. For user/host perhaps user-automember-rebuild. > +1, this is shorter. +1, I changed the names of commands to: ipa automember-rebuild ipa user-automember-rebuild ipa host-automember-rebuild > >>> I disagree with your update/reset suggestions. >> We can have a separate RFE for reset but I think it would make sense for >> the cases when user moves from one org unit to another or moves from >> intern to full time. >> In this case I expect something like >> 1) Update user "class" attribute >> 2) Run automember reset > Hmm, I must say I do not like the reset option very much too. Someone may not > realize what is the real scope or meaning of the option and find out all his > membership is gone. > > Nothing prevents Administrator to explicitly remove all user membership before > moving to other role/function. It is a matter of 3 clicks in Web UI. I agree with Martin and Rob here. Adding the reset option would only introduce unnecessary risk. > >>> Unless a user is doing ALL of its group/hostgroup management via >>> automember rules then the reset command will almost always do the >>> wrong thing. >> No it is need for the case when you need to get to the state as if this >> user was just added without actually deleting and re-addign the user. >> Use case like I mentioned above are examples. >> >>> This could raise all sorts of strange permission issues too, as we'd >>> have to use the currently bound user to do the group membership >>> removal. We can separately add delegation to create an automember >>> rebuild task, and that runs as DM IIRC. >> I agree that this would probably be a different task, like delete and >> rebuild. This I think we should create a separate ticket for reset and >> file and RFE with DS. It is not urgent but will become handy when we >> start supporting user lifecycle management and provisioning > Still not convinced this the way we should go and that life-cycle management > would require rinsing all membership data. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From abokovoy at redhat.com Fri Sep 13 13:01:54 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 13 Sep 2013 16:01:54 +0300 Subject: [Freeipa-devel] [PATCH] Add delegation info to MS-PAC In-Reply-To: <1360273346.2299.15.camel@willson.li.ssimo.org> References: <1360273346.2299.15.camel@willson.li.ssimo.org> Message-ID: <20130913130154.GM21212@redhat.com> On Thu, 07 Feb 2013, Simo Sorce wrote: >This information is not strictly required but is part of the MS-PAC >specification and I had some time to kill on the plane on my last trip >back. > >I tested it briefly with cross-realm trusts and it seem to work fine. >Neither IPA nor AD2012 complained when looking at PACs, do far. Reviving. It is actually required part as without it smbd will deny our attempt to establish local part of the trust in some cases by misinterpreting what we put in the PAC and thinking that a service impersonating original user is the actual user but taking original user name as an account name. With this patch everything works fine. ACK. -- / Alexander Bokovoy From simo at redhat.com Fri Sep 13 13:08:10 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 13 Sep 2013 09:08:10 -0400 Subject: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments In-Reply-To: <5232CC3E.1010401@redhat.com> References: <5232CC3E.1010401@redhat.com> Message-ID: <1379077690.2804.1976.camel@willson.li.ssimo.org> On Fri, 2013-09-13 at 10:26 +0200, Petr Spacek wrote: > Hello list, > > FreeIPA deployments in cloud environments do not work very well because > 'clouds' break some assumptions we made during FreeIPA's design. > > We should fix it somehow :-) > > === Problems === > - A machine has two host names in DNS: > -- The first name is internal to the cloud and resolvable only from inside of > the cloud. > --- This name should be used for communication inside cloud. > --- E.g. 'ipa.cust1.cloud.' > --- Internal name is mapped to internal IP address, see below. > > -- The second name is external to the cloud and should be used for > communication between the Internet and cloud. > --- E.g. 'ipa.example.com.' > --- External name maps to external IP address, see below. > > - A machine has two IP addresses: > -- Internal, private IP address configured at the machine's interface > --- Typically the only IP address known to the machine. > --- E.g. 192.0.2.22 > --- IP address can change dynamically, at least after a machine reboot. > > -- External, public IP address: > --- Typically mapped to internal address at cloud boundary (NAT). > --- E.g. 203.0.113.113 > --- IP address can change dynamically, at least after a machine reboot. > > Related tickets: > https://fedorahosted.org/freeipa/ticket/2648 > https://fedorahosted.org/freeipa/ticket/2715 > > The natural request is to add support for DNS views/split horizon DNS into > FreeIPA, so different names and IP addresses can be served to clients inside > and outside of the cloud. > > Is it enough? What else should we change to make FreeIPA reliable in clouds? I do not understand what's the use of views in this case. Views are used when you want to assign different IP addresses to the same name depending on where the query comes from. But here we have different names pointing to different addresses and the machine actually know nothing about the external name/IP. So what is the point of a view here ? >From the FreeIPA pov, if you use it for infrastructure you should just care about internal names. For the rare case where you want to have some client use the external name to access a machine then what we need to do is to make it easy (it is possible but not exposed now) to assign aliases to hosts so that you get an alias for each host/ and other service principals in the kerberos database and you get alternate names in the x509 certs. But I still do not see any issues with DNS, except for the fact that the network manager service of the cloud provider needs to be able to maintain the DNS records according to how it assigns IPs to names. > What are use cases? > > Do we want to support clients *outside* of the cloud connecting to FreeIPA > servers *inside* of the cloud? I think we should give the option, see above. > What about PKI certificates? Should we put two names to each certificate? What > we should do after host name change? (I do not have enough information when > the host name changes.) A change in host name will require a new certificate. But if the name is stable then we just need to populate certs with aliases > What about Kerberos? How it will play with host name change? How should we > handle the fact that internal and external names are different? Should we use > some sort of referral mechanism? Uhmm a referral may also work in future, but we could simply uses aliases, not all applications may work properly (some insist on a specific name, but a lot of apps these days can be configured to use just the service name and then accept tickets as long as they can be decrypted (key is the same). > Cloud users, please speak now :-) Opinions are more than welcome! Indeed, if you see any wrong assumption in here, it would be *really* nice to have a heads up. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Sep 13 13:12:58 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 13 Sep 2013 09:12:58 -0400 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <5232FCDE.1020804@redhat.com> References: <523049A5.10208@redhat.com> <1378916880.2804.1612.camel@willson.li.ssimo.org> <5230DF98.1040501@redhat.com> <5231563C.8090203@redhat.com> <1378991670.2804.1893.camel@willson.li.ssimo.org> <52320DE8.7050401@redhat.com> <1379013764.2804.1948.camel@willson.li.ssimo.org> <5232FCDE.1020804@redhat.com> Message-ID: <1379077978.2804.1978.camel@willson.li.ssimo.org> On Fri, 2013-09-13 at 13:54 +0200, Petr Vobornik wrote: > On 09/12/2013 09:22 PM, Simo Sorce wrote: > > On Thu, 2013-09-12 at 14:54 -0400, Dmitri Pal wrote: > >> On 09/12/2013 09:14 AM, Simo Sorce wrote: > >>> On Thu, 2013-09-12 at 07:50 +0200, Martin Kosek wrote: > >>>> On 09/11/2013 11:24 PM, Dmitri Pal wrote: > >>>>> On 09/11/2013 12:28 PM, Simo Sorce wrote: > >>>>>> On Wed, 2013-09-11 at 12:44 +0200, Petr Vobornik wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> This is a part of documentation effort which started couple month > >>>>>>> ago. > >>>>>>> Attached patches improves devel documentation of Web UI. Mostly by > >>>>>>> annotating source code and then processing it by JSDuck tool[1]. > >>>>>>> > >>>>>>> The documentation is not complete - most plugins and member of some > >>>>>>> core > >>>>>>> widgets and facets are not annotated yet. I'm sending it now because > >>>>>>> I > >>>>>>> need to focus on more pressing tickets. > >>>>>>> > >>>>>>> You can see current state at my fedorapeople page [2]. > >>>>>>> > >>>>>>> I also converted 5 guides/articles which I wrote some time ago. > >>>>>>> Guides > >>>>>>> are also part of the JSDuck app [3]. > >>>>>>> > >>>>>>> The idea is to regularly generate the doc and place it on > >>>>>>> docs.freeipa.org (not in production at the moment) so all doc would > >>>>>>> be > >>>>>>> on one place. > >>>>>>> > >>>>>>> Installation of JSDuck is documented on their page [4]. Basically it > >>>>>>> requires ruby and JSDuck gem. > >>>>>>> > >>>>>>> Usage: > >>>>>>> $ cd install/ui/doc > >>>>>>> $ make > >>>>>>> > >>>>>>> Documentation is generated into: install/ui/build/code_doc directory > >>>>>>> > >>>>>>> [1] https://github.com/senchalabs/jsduck > >>>>>>> [2] http://pvoborni.fedorapeople.org/doc > >>>>>>> [3] http://pvoborni.fedorapeople.org/doc/#!/guide > >>>>>>> [4] https://github.com/senchalabs/jsduck/wiki/Installation > >>>>>> I would rather not grow a dependency on Ruby in the freeIPA project. > >>>>>> Are there any alternatives ? > >>>>>> > >>>>>> Simo. > >>>>>> > >>>>> Is it dev side dependency? We might have issues if we need gems during > >>>>> build process that are not a part of distro. > >>> This is only one of the problems. > >>> > >>>> This a UI Doc building dependency, i.e. not needed when package is installed. > >>>> So someone/something doing a release and releasing the doc will need the ruby + > >>>> respective rubygem installed. > >>>> > >>>> If we want to automate the build and let the doc be built for example on koji, > >>>> I am afraid we would have to step back from using jsDuck, or let Petr package > >>>> it in Fedora since he used it despite my previous warnings :-) > >>> The problem is that ruby is still a fast moving target, and we do not > >>> want to waste time fighiting it when (not if) it will break and you find > >>> it just right before a release where you want to build docs. > >>> > >>> I really would like to avoid dependencies in Ruby in this project > >>> completely as long as possible. > >>> > >>>> Petr, we should think if we should keep UI doc and articles in devel repo or if > >>>> leave just the anonated code there and move all development articles and guides > >>>> to our new doc repo > >>>> http://www.freeipa.org/page/Contribute/Documentation > >>> moving to the doc repo does not solve the problem, really, we are still > >>> depending on a) ruby for generating docs, b) someone knowing Ruby to fix > >>> things when they will break. > >>> > >>> Simo. > >>> > >> It seems that doxygen does not work for JS for us. > >> So it is node.js vs. ruby vs. no generated docs. > >> Since we always can get back to "no docs" if things go really wrong I do > >> not see it as an option here. > >> I do not like either of the other two alternatives. And I do not know > >> which one would be best if any. > > > > the probelm, if I understood it correctly is that each of this systems > > have a different markup language, so switching later would mean also > > changing all the markup language in the code, high churn and lot of > > wasted work. I am assuming you use javadoc with javascript with doxygen, > > what does jsduck uses ? > > jsduck, yuidoc, jsdoc and doxygen use some flavor of javadoc. They are > not compatible though. With regular expressions, existing comments can > be easily converted ie. into yuidoc. But it would still require some > additional work because jsduck leverages code introspection, but most of > the others doesn't so one would have to add the missing information. > > > > > Or are we trying to generate just lists of functions from the actual > > code ? What is the value if there is no associated description of what > > the function does ? > > > > Simo. > > > It's not just list of members. Added values (general and some jsduck > specific): > > - list of classes grouped by usage (main page) > - list of events which might not be regular member (just a documented one) > - descriptions for functions and properties where purpose is not clear > from their name > - examples of usage for some classes/members > - inheritance chain parent class, mixin classes, subclasses > - info about which parent's method was overridden by a method > - search (classes, members; doesn't require server side) > - filter by member name > - filter by member type: deprecated/protected/public/inherited > - guides where you can write: 'classname.membername' and it will > automatically make you a link do relevant doc > Doc build checks: > - check if documented type is declared > - check if member has description > - check if annotation has correct format > - check if member belongs to declared class > - check if overriden member exists > - duplicate members, params > > Not sure if I should elaborate more on usecases (experiences devel vs > web ui newbie, ...). Well my concern remains that if we want to change later it will take some effort, but I guess it is better to have improved docs now and take care of the 'ruby' problem later if it becomes an issue. I find it amusing we have to use ruby to document javascript though, you would think javascript is a good enough language to do that :-D Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Fri Sep 13 13:31:47 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 13 Sep 2013 15:31:47 +0200 Subject: [Freeipa-devel] [PATCH 0186-0191] Replace LDAP cache with RBTDB In-Reply-To: <520B9755.70503@redhat.com> References: <51FA694C.1000302@redhat.com> <520B9373.1070707@redhat.com> <520B9755.70503@redhat.com> Message-ID: <523313C3.8070306@redhat.com> On 14.8.2013 16:42, Petr Spacek wrote: > On 14.8.2013 16:25, Petr Spacek wrote: >> On 1.8.2013 15:57, Petr Spacek wrote: >>> Hello, >>> >>> attached monster patches replace our internal cache/database with RBTDB >>> implementation. See commit messages and comments inside. >>> >>> This patch set provides very basic functionality (including DNS support for >>> updates). Error handling definitely needs more love, but it should be enough >>> for rapid DNSSEC prototyping. >> >> Patch 186 v2: The code now applies incremental changes in LDAP to the >> in-memory database. Commit message was modified to mention that wildcards are >> now supported. >> >> Patch 187 v2: The code was re-worked and now it respects serial_autoincrement >> option. >> >> Patch 188 v2: Minor comment clean-up and rebase on top of patch 187 v2. >> >> Patch 189 v2: Call to deleterdataset() nested in substractrdataset() was >> deleted. This code was meant only for testing purposes. >> >> These patch set is now ready for review. Please see commit messages! Some >> functionality is missing intentionally, but it will be fixed by separate >> patches. > > It would be too easy! > > Patch 186 v3: Commit message was extended with information that LDAP MODRDN > operation is not supported at the moment. > > Patch 187 v3: Missing file ldap_driver.h was added. This extended patch set handles correctly object deletion from LDAP. Patches 186-189 contain very minor changes, only moving code from one place to the other. See commit messages for patches 190 and 191. This should be testable. I would recommend to test the whole patch set at once, most probably it doesn't make much sense to test patches separately. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0186-4-Use-RBTDB-instead-of-internal-LDAP-cache.patch Type: text/x-patch Size: 87972 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0187-4-Update-serial-after-each-change-in-zone.patch Type: text/x-patch Size: 8513 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0188-3-Drop-old-LDAP-cache.patch Type: text/x-patch Size: 19653 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0189-3-Add-support-for-write-back-to-LDAP-after-a-DNS-updat.patch Type: text/x-patch Size: 11102 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0190-Improve-logging-of-LDAP-entries-without-a-supported.patch Type: text/x-patch Size: 951 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0191-Handle-object-deletion.patch Type: text/x-patch Size: 10376 bytes Desc: not available URL: From tbabej at redhat.com Fri Sep 13 14:12:05 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 13 Sep 2013 16:12:05 +0200 Subject: [Freeipa-devel] [PATCHES] 0094-0099 Make Fuzzy objects available for the whole ipatests module Message-ID: <52331D35.7010900@redhat.com> Hi, The following patches move and extend the functionality of Fuzzy objects. This is necessary to use them from within integration tests. Details in the commit messages. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0094-ipatests-Make-basestring-default-type-for-Fuzzy-when.patch Type: text/x-patch Size: 1215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0095-ipatests-Add-line_unbound_regex-property-to-Fuzzy-ob.patch Type: text/x-patch Size: 968 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0096-ipatests-Move-generic-fuzzy-expressions-to-ipatests-.patch Type: text/x-patch Size: 201882 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0097-ipatests-Add-u-property-to-the-Fuzzy-object.patch Type: text/x-patch Size: 1685 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0098-ipatests-Add-unit-tests-for-u-and-line_unbound_regex.patch Type: text/x-patch Size: 3508 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0099-ipatests-Restrict-fuzzy-objects-in-unit-tests-to-uni.patch Type: text/x-patch Size: 94530 bytes Desc: not available URL: From dpal at redhat.com Fri Sep 13 14:52:42 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 13 Sep 2013 10:52:42 -0400 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <5232C9FA.1020904@redhat.com> References: <523200E9.5010304@redhat.com> <523211D3.3080504@redhat.com> <523214C2.2070401@redhat.com> <52321A2B.60302@redhat.com> <5232C9FA.1020904@redhat.com> Message-ID: <523326BA.7080207@redhat.com> On 09/13/2013 04:16 AM, Martin Kosek wrote: > On 09/12/2013 09:46 PM, Dmitri Pal wrote: >> On 09/12/2013 03:23 PM, Rob Crittenden wrote: >>> Dmitri Pal wrote: >>>> On 09/12/2013 01:59 PM, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> The design document for $SUBJECT can be found at: >>>>> http://www.freeipa.org/page/V3/Automember_rebuild_membership >>>>> >>>>> Related tickets: >>>>> https://fedorahosted.org/freeipa/ticket/3752 >>>>> https://fedorahosted.org/freeipa/ticket/3928 >>>>> >>>>> Thoughts, comments, questions welcome. >>>>> >>>> The names for commands are a bit long. >>>> I am not sure we need all the commands. >>>> >>>> $ ipa automember-rebuild-membership --type=group >>>> >>>> I do not understand why type is "group". >>>> If you say that all the user group memberships will be rebuilt then the >>>> type is "user". >>>> But then you can really not have the command at all and use just: >>>> >>>> ipa user-automembership >>>> and >>>> ipa host-automembership >>>> >>>> If in future we have other objects we would add another command for >>>> those objects. >>>> >>>> so >>>> ipa user-automembership --update >>>> will update group memberships for all users, or may be it should be >>>> ipa user-automembership --update * >>>> (I do not know what are the rules in the framework, we should follow >>>> them) >>>> >>>> ipa user-automember --update LOGIN >>>> will update group memberships for a specific user >>>> >>>> Now we need to differentiate --update and --reset >>>> --update should update group membership based on the existing filters, >>>> i.e. based on the automember plugin configuration only add missing >>>> memberships (if any) >>>> --reset should clean existing memberships and rebuild them based only >>>> the default groups + automember. It should pretty much mean "make group >>>> memberships as if the user was just added". >>>> >>>> Makes sense or I am missing something? >>> Her design is consistent with the current automember commands. >> What are they? > ipa automember-show --type=hostgroup webservers > ipa automember-add --type=group devel > >>> I think I'd drop the -membership part though, automember-rebuild is >>> sufficient. For user/host perhaps user-automember-rebuild. > +1, this is shorter. > >>> I disagree with your update/reset suggestions. >> We can have a separate RFE for reset but I think it would make sense for >> the cases when user moves from one org unit to another or moves from >> intern to full time. >> In this case I expect something like >> 1) Update user "class" attribute >> 2) Run automember reset > Hmm, I must say I do not like the reset option very much too. Someone may not > realize what is the real scope or meaning of the option and find out all his > membership is gone. > > Nothing prevents Administrator to explicitly remove all user membership before > moving to other role/function. It is a matter of 3 clicks in Web UI. > >>> Unless a user is doing ALL of its group/hostgroup management via >>> automember rules then the reset command will almost always do the >>> wrong thing. >> No it is need for the case when you need to get to the state as if this >> user was just added without actually deleting and re-addign the user. >> Use case like I mentioned above are examples. >> >>> This could raise all sorts of strange permission issues too, as we'd >>> have to use the currently bound user to do the group membership >>> removal. We can separately add delegation to create an automember >>> rebuild task, and that runs as DM IIRC. >> I agree that this would probably be a different task, like delete and >> rebuild. This I think we should create a separate ticket for reset and >> file and RFE with DS. It is not urgent but will become handy when we >> start supporting user lifecycle management and provisioning > Still not convinced this the way we should go and that life-cycle management > would require rinsing all membership data. > > Martin OK, would not argue. Let us punt on the 'reset'. -- 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 Fri Sep 13 15:39:54 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 13 Sep 2013 17:39:54 +0200 Subject: [Freeipa-devel] DNS improvements: Should we add some sanity checking? In-Reply-To: <5232CA42.2000406@redhat.com> References: <20130913070214.GU10627@redhat.com> <5232BEDC.5000000@redhat.com> <5232CA42.2000406@redhat.com> Message-ID: <523331CA.7000707@redhat.com> On 09/13/2013 10:18 AM, Tomas Babej wrote: > On 09/13/2013 09:29 AM, Petr Spacek wrote: >> Hello list, >> >> Jan Pazdziora proposed that 'ipa dns*' >> commands should do some sanity checking/waiting after the record is >> added to LDAP. >> >> I think that it could be valuable and I would like to get opinions >> from freeipa-devel list. >> >> > +1! > >> === The problem === >> ipa dnsrecord-add and similar commands add the data to LDAP, but it >> doesn't mean that the data are *immediately* resolvable via DNS >> protocol. Note that data from LDAP are *asynchronously* read and >> processed by Named and the time when records are available is not >> predictable. >> >> A mismatch between LDAP can be caused by some connection problem >> between DNS and LDAP servers, LDAP or DNS server restart, or simply by >> a bug in DNS<->LDAP synchronization code. (This is becomming more and >> more important if we consider the whole DNSSEC effort and related >> re-factoring.) >> >> My experience is that users are very confused if the ipa dnsrecord-add >> command says 'record added' but it is still not available via DNS. It >> is really hard to debug when you see the problem first 10 times :-) >> >> >> === The proposal === >> 1. Let FreeIPA framework to change DNS data in LDAP as we do now. >> 2. After each change, do DNS queries for changed record and wait until >> the new data are available. >> >> IMHO it is very cheap operation (in usual cases 1 DNS packet back and >> forth) and it would save a lot of headaches to users and support. > > We should make sure that we do not wait indefinitely here in case > there's something else wrong with the named. > > We could wait for DNS data to be made available up to small reasonable > timeout. If the check succeeds, we can output "Verified: Yes" along with > the usual ipa dns(whatever) command output. Otherwise, we could print > out "Verified: No" I think we should rather add an error message to the output: http://www.freeipa.org/page/V3/Messages > However, it would be nice to print out "Verified: No" in a somewhat > emphasized manner. I created the following ticket: > > https://fedorahosted.org/freeipa/ticket/3930 Messages should already stand out so they won't get lost in the output. (Which doesn't mean we can't also make them red, if someone wants to do contribute that.) -- Petr? From pvoborni at redhat.com Fri Sep 13 15:55:31 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 13 Sep 2013 17:55:31 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <1378355153.19352.29.camel@localhost> References: <1378355153.19352.29.camel@localhost> Message-ID: <52333573.5020702@redhat.com> On 09/05/2013 06:25 AM, Nathaniel McCallum wrote: > This patch has a few problems that I'd like some help with. There are a > few notes here as well. > snip Some additional findings: 1. Inconsistency: 'ipatokenowner' in command output should be normalized the same way as 'manager' in user plugin or 'seealso' in selinuxusermap. See _normalize_manager and _convert_manager methods. Question for all: Why don't we have general methods for such task? 2. Inconsistency: IntEnum doesn't convert input value as Int does. It should also allow to specify int in a form of unicode string (IMO). 3. IDK how OTP matching works internally, so the following might not be an issue, it just looks suspicious to me: I'm talking about handling of default values for ipatokenotpalgorithm, ipatokenotpdigits and ipatokentotptimestep. - Defaults are hardcoded in otp_add.pre_callback and the same in auth.c. - when values are not supplied, OTP token configuration uri is created with the defaults. - the values are not saved to LDAP What will happen when these defaults will change (ie. when we want to use more secure hashing algorithm)? I assume that OTP daemon will use its defaults if there are no values in LDAP. After such change the defaults are different than the values the token was configured with so the evaluation process will fail. Should we save the values to LDAP? Or can we be sure that the defaults won't change? Or am I completely wrong? 4. When I pass incorrectly formatted values for options ipatokennotbefore and ipatokennotafter i will get an error message saying: "ipatokenNotBefore: value #0 invalid per syntax: Invalid syntax." This message doesn't tell me what's is the correct format nor there is any description. -- Petr Vobornik From pviktori at redhat.com Fri Sep 13 15:57:03 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 13 Sep 2013 17:57:03 +0200 Subject: [Freeipa-devel] [PATCHES] 0094-0099 Make Fuzzy objects available for the whole ipatests module In-Reply-To: <52331D35.7010900@redhat.com> References: <52331D35.7010900@redhat.com> Message-ID: <523335CF.8030000@redhat.com> On 09/13/2013 04:12 PM, Tomas Babej wrote: > Hi, > > The following patches move and extend the functionality of Fuzzy > objects. This is necessary to use them from within integration tests. -1 to the idea. I'm not a fan of the Fuzzy objects; they basically exist so that you can use regex matching in the Declarative tests. As you've probably noticed Fuzzy is quite specific to the framework and its test suite -- see the strict bytes/unicode separation and the amount of changes it takes to tear them out. I'm also not a fan of having a generic "Match anything using some rules" object where everybody adds behavior specific to their use case. Each addition increases the complexity and number of corner cases, and the complete intended functionality can never be achieved. Using regular expressions directly should actually be easier and less error-prone in most cases. If you disagree, I'd like to see your use case. -- Petr? From pviktori at redhat.com Fri Sep 13 16:06:06 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 13 Sep 2013 18:06:06 +0200 Subject: [Freeipa-devel] [PATCH] Add delegation info to MS-PAC In-Reply-To: <20130913130154.GM21212@redhat.com> References: <1360273346.2299.15.camel@willson.li.ssimo.org> <20130913130154.GM21212@redhat.com> Message-ID: <523337EE.8@redhat.com> On 09/13/2013 03:01 PM, Alexander Bokovoy wrote: > On Thu, 07 Feb 2013, Simo Sorce wrote: >> This information is not strictly required but is part of the MS-PAC >> specification and I had some time to kill on the plane on my last trip >> back. >> >> I tested it briefly with cross-realm trusts and it seem to work fine. >> Neither IPA nor AD2012 complained when looking at PACs, do far. > Reviving. > > It is actually required part as without it smbd will deny our attempt to > establish local part of the trust in some cases by misinterpreting what > we put in the PAC and thinking that a service impersonating original > user is the actual user but taking original user name as an account > name. > > With this patch everything works fine. ACK. > I've added the ticket link to the commit message, and pushed to master: 5157fd450fb33a7a3b68525a255d2976dbb0840a -- Petr? From simo at redhat.com Fri Sep 13 16:17:51 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 13 Sep 2013 12:17:51 -0400 Subject: [Freeipa-devel] DNS improvements: Should we add some sanity checking? In-Reply-To: <5232BEDC.5000000@redhat.com> References: <20130913070214.GU10627@redhat.com> <5232BEDC.5000000@redhat.com> Message-ID: <1379089071.2804.1987.camel@willson.li.ssimo.org> On Fri, 2013-09-13 at 09:29 +0200, Petr Spacek wrote: > Hello list, > > Jan Pazdziora proposed that 'ipa dns*' commands should > do some sanity checking/waiting after the record is added to LDAP. > > I think that it could be valuable and I would like to get opinions from > freeipa-devel list. > > > === The problem === > ipa dnsrecord-add and similar commands add the data to LDAP, but it doesn't > mean that the data are *immediately* resolvable via DNS protocol. Note that > data from LDAP are *asynchronously* read and processed by Named and the time > when records are available is not predictable. > > A mismatch between LDAP can be caused by some connection problem between DNS > and LDAP servers, LDAP or DNS server restart, or simply by a bug in DNS<->LDAP > synchronization code. (This is becomming more and more important if we > consider the whole DNSSEC effort and related re-factoring.) > > My experience is that users are very confused if the ipa dnsrecord-add command > says 'record added' but it is still not available via DNS. It is really hard > to debug when you see the problem first 10 times :-) > > > === The proposal === > 1. Let FreeIPA framework to change DNS data in LDAP as we do now. > 2. After each change, do DNS queries for changed record and wait until the new > data are available. > > IMHO it is very cheap operation (in usual cases 1 DNS packet back and forth) > and it would save a lot of headaches to users and support. > > This will naturally catch the case where named crashes after the change etc. > > > === Expected outcome === > There will not be any failure like this: > > $ ipa-adtrust-install > > $ ipa dnszone-add $AD_DOMAIN --name-server=advm.$AD_DOMAIN > --admin-email="hostmaster@$AD_DOMAIN.com" --force --forwarder=$AD_IP > --forward-policy=only --ip-address=$AD_IP > Zone name: dom123.example.com > [...] > > $ ipa trust-add --type=ad DOM123.EXAMPLE.COM --admin Administrator --password > Password for admin at DOM123.EXAMPLE.COM: > ipa: ERROR: Cannot find specified domain or server name > Would it make sense to change the code to use dynDNS update to add records ? Wouldn't that force named to be in sync ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Fri Sep 13 16:19:32 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 13 Sep 2013 18:19:32 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <523212EF.7030302@redhat.com> References: <1378355153.19352.29.camel@localhost> <5231A566.30904@redhat.com> <523212EF.7030302@redhat.com> Message-ID: <52333B14.7030403@redhat.com> On 09/12/2013 09:15 PM, Dmitri Pal wrote: > On 09/12/2013 07:28 AM, Petr Vobornik wrote: >> Qs: >> >> a. Do we have some use cases for adding internal OTP? I wonder which >> otp-add options are essential (ipatokenvendor, ipatokenmodel, >> ipatokenserial, ipatokenotpkey, ipatokenotpalgorithm, >> ipatokenotpdigits, ipatokentotpclockoffset, ipatokentotptimestep?) and >> which are less important (ipatokennotbefore, ipatokennotafter ?). >> > Can you rephrase? The use cases were covered pretty much on the design page. > Use cases cover that user should be able to add token for himself, and admin for anybody. They don't say anything about what are the usual parameters which has to be configured for various kinds of tokens. otp-add command has a lot of optional options. It would be nice to simplify UI adder dialog as much as possible. For example LinOTP interface has a page for adding google auth token and a page for adding general totp token. The google auth token page is very simple. User can click only on 'create token' button and nothing else. The topt page is targeted for advanced users/admins so it's much more complex. One can enter whole buch of options. So I wonder what are the use cases for common user in IPA. It will tell us if we can present the user only simple one-click UI, or if there should be possibilities to specify additional options. -- Petr Vobornik From nkinder at redhat.com Fri Sep 13 16:22:40 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 13 Sep 2013 09:22:40 -0700 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <5232D167.30201@redhat.com> References: <523200E9.5010304@redhat.com> <5232D167.30201@redhat.com> Message-ID: <52333BD0.4010700@redhat.com> On 09/13/2013 01:48 AM, Martin Kosek wrote: > On 09/12/2013 07:59 PM, Ana Krivokapic wrote: >> Hello, >> >> The design document for $SUBJECT can be found at: >> http://www.freeipa.org/page/V3/Automember_rebuild_membership >> >> Related tickets: >> https://fedorahosted.org/freeipa/ticket/3752 >> https://fedorahosted.org/freeipa/ticket/3928 >> >> Thoughts, comments, questions welcome. >> > Besides membership reset discussion happening in second thread I other comments. > > 1) I think we should also design permission&ACIs for the automember rebuild > task creation (cn=automember rebuild membership,cn=tasks,cn=config container). > You can talk to Petr3 about that as he is current working on redesigning ACIs. > Just so that you are in sync. > > 2) About the "Implementation" part and "automember rebuild membership" > > I do not think this is good approach. I do not know how do you plan doing the > confirmation > > I do not think this workflow would work with our framework. We do not have > support for confirming except if you would implement it in > interactive_prompt_callback. But then the functionality would not be available > for Web UI. > > I would rather add an option --dry-run or --test for all new automember > commands which would return how would the updated entry look like. BTW, did the > automember export updates task work for you? I tried this LDIF and > /tmp/automember.ldif was empty: > > dn: cn=my export task 1, cn=automember export updates,cn=tasks,cn=config > changetype: add > objectClass: top > objectClass: extensibleObject > cn: my export task 1 > basedn: cn=accounts,dc=example,dc=com > filter: (uid=*) > scope: sub > ldif: /tmp/automember.ldif > > Adding Mark to CC in case if he has any advise for utilizing the export task in > FreeIPA. You forgot to CC Mark. :) I've added him to the thread. -NGK > > By the way, using this approach I think we would also hit issues with > permissions on the resulting LDIF, given it is created by DS and would be read > by Apache. SELinux would be complaining as well. To sum it up, I am not sure > this will be that easy and straightforward. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pviktori at redhat.com Fri Sep 13 16:24:09 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 13 Sep 2013 18:24:09 +0200 Subject: [Freeipa-devel] [PATCH] 0274 test_simple_replication: Fix waiting for replication Message-ID: <52333C29.1070907@redhat.com> The "simple replication" test is failing intermittently. It's quite hard to manually verify if this patch fixes that completely, but my testing says it does make a positive difference. See commit message for details. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0273-test_simple_replication-Fix-waiting-for-replication.patch Type: text/x-patch Size: 2215 bytes Desc: not available URL: From pviktori at redhat.com Fri Sep 13 16:44:05 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 13 Sep 2013 18:44:05 +0200 Subject: [Freeipa-devel] [PATCHES] 0258-0265 Add schema updater based on IPA schema files In-Reply-To: <51FA7645.6090702@redhat.com> References: <51FA7645.6090702@redhat.com> Message-ID: <523340D5.4090505@redhat.com> On 08/01/2013 04:52 PM, Petr Viktorin wrote: > Hello, > With these patches, schema updates will be based on the ldif files we > use for installation. > > https://fedorahosted.org/freeipa/ticket/3454 > > This is a RFE, here is the design doc: > http://www.freeipa.org/page/V3/Improved_schema_updater > I found and filed a bug in python-ldap[0]: it sometimes ignores parts of schema LDIFs when parsing them. Patch 0275 works around the bug. Please apply on top of 0258-0265 (they still apply cleanly). [0] https://bugzilla.redhat.com/show_bug.cgi?id=1007820 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0275-Unify-capitalization-of-attribute-names-in-schema-fi.patch Type: text/x-patch Size: 11040 bytes Desc: not available URL: From rcritten at redhat.com Fri Sep 13 17:04:39 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Sep 2013 13:04:39 -0400 Subject: [Freeipa-devel] [PATCHES] 0094-0099 Make Fuzzy objects available for the whole ipatests module In-Reply-To: <523335CF.8030000@redhat.com> References: <52331D35.7010900@redhat.com> <523335CF.8030000@redhat.com> Message-ID: <523345A7.1080303@redhat.com> Petr Viktorin wrote: > On 09/13/2013 04:12 PM, Tomas Babej wrote: >> Hi, >> >> The following patches move and extend the functionality of Fuzzy >> objects. This is necessary to use them from within integration tests. > > -1 to the idea. > I'm not a fan of the Fuzzy objects; they basically exist so that you can > use regex matching in the Declarative tests. > As you've probably noticed Fuzzy is quite specific to the framework and > its test suite -- see the strict bytes/unicode separation and the amount > of changes it takes to tear them out. > > I'm also not a fan of having a generic "Match anything using some rules" > object where everybody adds behavior specific to their use case. Each > addition increases the complexity and number of corner cases, and the > complete intended functionality can never be achieved. > > Using regular expressions directly should actually be easier and less > error-prone in most cases. > If you disagree, I'd like to see your use case. I'm not sure what the objection is, Fuzzy is just an abstraction. It lets one do in-line regex which is the reason it was introduced (initially for uid and gid because they are non-deterministic). Replacing it would either a) replicate its functionality almost completely or b) spread duplicate regex code all over the place. That isn't to say that Fuzzy isn't being abused, but that is also the responsibility of the reviewers to be strict about. rob From pviktori at redhat.com Fri Sep 13 17:53:54 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 13 Sep 2013 19:53:54 +0200 Subject: [Freeipa-devel] [PATCHES] 0094-0099 Make Fuzzy objects available for the whole ipatests module In-Reply-To: <523345A7.1080303@redhat.com> References: <52331D35.7010900@redhat.com> <523335CF.8030000@redhat.com> <523345A7.1080303@redhat.com> Message-ID: <52335132.8020603@redhat.com> On 09/13/2013 07:04 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 09/13/2013 04:12 PM, Tomas Babej wrote: >>> Hi, >>> >>> The following patches move and extend the functionality of Fuzzy >>> objects. This is necessary to use them from within integration tests. >> >> -1 to the idea. >> I'm not a fan of the Fuzzy objects; they basically exist so that you can >> use regex matching in the Declarative tests. >> As you've probably noticed Fuzzy is quite specific to the framework and >> its test suite -- see the strict bytes/unicode separation and the amount >> of changes it takes to tear them out. >> >> I'm also not a fan of having a generic "Match anything using some rules" >> object where everybody adds behavior specific to their use case. Each >> addition increases the complexity and number of corner cases, and the >> complete intended functionality can never be achieved. >> >> Using regular expressions directly should actually be easier and less >> error-prone in most cases. >> If you disagree, I'd like to see your use case. > > I'm not sure what the objection is, Fuzzy is just an abstraction. It > lets one do in-line regex which is the reason it was introduced > (initially for uid and gid because they are non-deterministic). Yes. "In-line" is the key here. It lets you do regex matching via the == operator, which is what Declarative tests need, but elsewhere the abstraction is completely unnecessary. > Replacing it would either a) replicate its functionality almost > completely or b) spread duplicate regex code all over the place. I'd go for b; spreading this code: import re some_regex = re.compile('some.*regex$') ... assert some_regex.search(x) instead of: from wherever import Fuzzy warm_fuzzy = Fuzzy('some.*regex$') ... assert x == warm_fuzzy all over the place is fine in my book. And you can even, say, add custom flags to the regex without complicating shared code. The rest of Fuzzy functionality consists of strict type checking (which isn't really necessary in integration tests), and the ability to call arbitrary callables (which is just the scope creep I was talking about). By the way, in current tests these features are hardly ever used in combination. Even if this extra functionality is necessary, it's orthogonal to regex matching and can be more cleanly done with several separate asserts. Unless you need a single declarative object to compare against, of course. > That isn't to say that Fuzzy isn't being abused, but that is also the > responsibility of the reviewers to be strict about. Then perhaps I'm too strict, but I say that using it outside of the declarative tests is abuse. Especially if it takes six patches with hundreds of changed lines to repurpose Fuzzy for integration tests (but that's not part of "-1 to the idea"). -- Petr? From dpal at redhat.com Fri Sep 13 18:26:14 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 13 Sep 2013 14:26:14 -0400 Subject: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments In-Reply-To: <1379077690.2804.1976.camel@willson.li.ssimo.org> References: <5232CC3E.1010401@redhat.com> <1379077690.2804.1976.camel@willson.li.ssimo.org> Message-ID: <523358C6.8050804@redhat.com> On 09/13/2013 09:08 AM, Simo Sorce wrote: > On Fri, 2013-09-13 at 10:26 +0200, Petr Spacek wrote: >> Hello list, >> >> FreeIPA deployments in cloud environments do not work very well because >> 'clouds' break some assumptions we made during FreeIPA's design. >> >> We should fix it somehow :-) >> >> === Problems === >> - A machine has two host names in DNS: >> -- The first name is internal to the cloud and resolvable only from inside of >> the cloud. >> --- This name should be used for communication inside cloud. >> --- E.g. 'ipa.cust1.cloud.' >> --- Internal name is mapped to internal IP address, see below. >> >> -- The second name is external to the cloud and should be used for >> communication between the Internet and cloud. >> --- E.g. 'ipa.example.com.' >> --- External name maps to external IP address, see below. >> >> - A machine has two IP addresses: >> -- Internal, private IP address configured at the machine's interface >> --- Typically the only IP address known to the machine. >> --- E.g. 192.0.2.22 >> --- IP address can change dynamically, at least after a machine reboot. >> >> -- External, public IP address: >> --- Typically mapped to internal address at cloud boundary (NAT). >> --- E.g. 203.0.113.113 >> --- IP address can change dynamically, at least after a machine reboot. >> >> Related tickets: >> https://fedorahosted.org/freeipa/ticket/2648 >> https://fedorahosted.org/freeipa/ticket/2715 >> >> The natural request is to add support for DNS views/split horizon DNS into >> FreeIPA, so different names and IP addresses can be served to clients inside >> and outside of the cloud. >> >> Is it enough? What else should we change to make FreeIPA reliable in clouds? > I do not understand what's the use of views in this case. > > Views are used when you want to assign different IP addresses to the > same name depending on where the query comes from. > > But here we have different names pointing to different addresses and the > machine actually know nothing about the external name/IP. > > So what is the point of a view here ? > > >From the FreeIPA pov, if you use it for infrastructure you should just > care about internal names. > For the rare case where you want to have some client use the external > name to access a machine then what we need to do is to make it easy (it > is possible but not exposed now) to assign aliases to hosts so that you > get an alias for each host/ and other service principals in the kerberos > database and you get alternate names in the x509 certs. > But I still do not see any issues with DNS, except for the fact that the > network manager service of the cloud provider needs to be able to > maintain the DNS records according to how it assigns IPs to names. > >> What are use cases? >> >> Do we want to support clients *outside* of the cloud connecting to FreeIPA >> servers *inside* of the cloud? > I think we should give the option, see above. > >> What about PKI certificates? Should we put two names to each certificate? What >> we should do after host name change? (I do not have enough information when >> the host name changes.) > A change in host name will require a new certificate. But if the name is > stable then we just need to populate certs with aliases > >> What about Kerberos? How it will play with host name change? How should we >> handle the fact that internal and external names are different? Should we use >> some sort of referral mechanism? > Uhmm a referral may also work in future, but we could simply uses > aliases, not all applications may work properly (some insist on a > specific name, but a lot of apps these days can be configured to use > just the service name and then accept tickets as long as they can be > decrypted (key is the same). > >> Cloud users, please speak now :-) Opinions are more than welcome! > Indeed, if you see any wrong assumption in here, it would be *really* > nice to have a heads up. > > Simo. > Do we have an RFE about aliases? Do we need several? One for Kerberos part another for PKI? May be more than that? For client checks may be? -- 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:31:13 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 13 Sep 2013 14:31:13 -0400 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <1379077978.2804.1978.camel@willson.li.ssimo.org> References: <523049A5.10208@redhat.com> <1378916880.2804.1612.camel@willson.li.ssimo.org> <5230DF98.1040501@redhat.com> <5231563C.8090203@redhat.com> <1378991670.2804.1893.camel@willson.li.ssimo.org> <52320DE8.7050401@redhat.com> <1379013764.2804.1948.camel@willson.li.ssimo.org> <5232FCDE.1020804@redhat.com> <1379077978.2804.1978.camel@willson.li.ssimo.org> Message-ID: <523359F1.6030002@redhat.com> On 09/13/2013 09:12 AM, Simo Sorce wrote: > On Fri, 2013-09-13 at 13:54 +0200, Petr Vobornik wrote: >> On 09/12/2013 09:22 PM, Simo Sorce wrote: >>> On Thu, 2013-09-12 at 14:54 -0400, Dmitri Pal wrote: >>>> On 09/12/2013 09:14 AM, Simo Sorce wrote: >>>>> On Thu, 2013-09-12 at 07:50 +0200, Martin Kosek wrote: >>>>>> On 09/11/2013 11:24 PM, Dmitri Pal wrote: >>>>>>> On 09/11/2013 12:28 PM, Simo Sorce wrote: >>>>>>>> On Wed, 2013-09-11 at 12:44 +0200, Petr Vobornik wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> This is a part of documentation effort which started couple month >>>>>>>>> ago. >>>>>>>>> Attached patches improves devel documentation of Web UI. Mostly by >>>>>>>>> annotating source code and then processing it by JSDuck tool[1]. >>>>>>>>> >>>>>>>>> The documentation is not complete - most plugins and member of some >>>>>>>>> core >>>>>>>>> widgets and facets are not annotated yet. I'm sending it now because >>>>>>>>> I >>>>>>>>> need to focus on more pressing tickets. >>>>>>>>> >>>>>>>>> You can see current state at my fedorapeople page [2]. >>>>>>>>> >>>>>>>>> I also converted 5 guides/articles which I wrote some time ago. >>>>>>>>> Guides >>>>>>>>> are also part of the JSDuck app [3]. >>>>>>>>> >>>>>>>>> The idea is to regularly generate the doc and place it on >>>>>>>>> docs.freeipa.org (not in production at the moment) so all doc would >>>>>>>>> be >>>>>>>>> on one place. >>>>>>>>> >>>>>>>>> Installation of JSDuck is documented on their page [4]. Basically it >>>>>>>>> requires ruby and JSDuck gem. >>>>>>>>> >>>>>>>>> Usage: >>>>>>>>> $ cd install/ui/doc >>>>>>>>> $ make >>>>>>>>> >>>>>>>>> Documentation is generated into: install/ui/build/code_doc directory >>>>>>>>> >>>>>>>>> [1] https://github.com/senchalabs/jsduck >>>>>>>>> [2] http://pvoborni.fedorapeople.org/doc >>>>>>>>> [3] http://pvoborni.fedorapeople.org/doc/#!/guide >>>>>>>>> [4] https://github.com/senchalabs/jsduck/wiki/Installation >>>>>>>> I would rather not grow a dependency on Ruby in the freeIPA project. >>>>>>>> Are there any alternatives ? >>>>>>>> >>>>>>>> Simo. >>>>>>>> >>>>>>> Is it dev side dependency? We might have issues if we need gems during >>>>>>> build process that are not a part of distro. >>>>> This is only one of the problems. >>>>> >>>>>> This a UI Doc building dependency, i.e. not needed when package is installed. >>>>>> So someone/something doing a release and releasing the doc will need the ruby + >>>>>> respective rubygem installed. >>>>>> >>>>>> If we want to automate the build and let the doc be built for example on koji, >>>>>> I am afraid we would have to step back from using jsDuck, or let Petr package >>>>>> it in Fedora since he used it despite my previous warnings :-) >>>>> The problem is that ruby is still a fast moving target, and we do not >>>>> want to waste time fighiting it when (not if) it will break and you find >>>>> it just right before a release where you want to build docs. >>>>> >>>>> I really would like to avoid dependencies in Ruby in this project >>>>> completely as long as possible. >>>>> >>>>>> Petr, we should think if we should keep UI doc and articles in devel repo or if >>>>>> leave just the anonated code there and move all development articles and guides >>>>>> to our new doc repo >>>>>> http://www.freeipa.org/page/Contribute/Documentation >>>>> moving to the doc repo does not solve the problem, really, we are still >>>>> depending on a) ruby for generating docs, b) someone knowing Ruby to fix >>>>> things when they will break. >>>>> >>>>> Simo. >>>>> >>>> It seems that doxygen does not work for JS for us. >>>> So it is node.js vs. ruby vs. no generated docs. >>>> Since we always can get back to "no docs" if things go really wrong I do >>>> not see it as an option here. >>>> I do not like either of the other two alternatives. And I do not know >>>> which one would be best if any. >>> the probelm, if I understood it correctly is that each of this systems >>> have a different markup language, so switching later would mean also >>> changing all the markup language in the code, high churn and lot of >>> wasted work. I am assuming you use javadoc with javascript with doxygen, >>> what does jsduck uses ? >> jsduck, yuidoc, jsdoc and doxygen use some flavor of javadoc. They are >> not compatible though. With regular expressions, existing comments can >> be easily converted ie. into yuidoc. But it would still require some >> additional work because jsduck leverages code introspection, but most of >> the others doesn't so one would have to add the missing information. >> >>> Or are we trying to generate just lists of functions from the actual >>> code ? What is the value if there is no associated description of what >>> the function does ? >>> >>> Simo. >>> >> It's not just list of members. Added values (general and some jsduck >> specific): >> >> - list of classes grouped by usage (main page) >> - list of events which might not be regular member (just a documented one) >> - descriptions for functions and properties where purpose is not clear >> from their name >> - examples of usage for some classes/members >> - inheritance chain parent class, mixin classes, subclasses >> - info about which parent's method was overridden by a method >> - search (classes, members; doesn't require server side) >> - filter by member name >> - filter by member type: deprecated/protected/public/inherited >> - guides where you can write: 'classname.membername' and it will >> automatically make you a link do relevant doc >> Doc build checks: >> - check if documented type is declared >> - check if member has description >> - check if annotation has correct format >> - check if member belongs to declared class >> - check if overriden member exists >> - duplicate members, params >> >> Not sure if I should elaborate more on usecases (experiences devel vs >> web ui newbie, ...). > Well my concern remains that if we want to change later it will take > some effort, but I guess it is better to have improved docs now and take > care of the 'ruby' problem later if it becomes an issue. > > I find it amusing we have to use ruby to document javascript though, you > would think javascript is a good enough language to do that :-D > > Simo. > I take this as an ack for JSDuck. -- 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:38:36 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 13 Sep 2013 14:38:36 -0400 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <52333B14.7030403@redhat.com> References: <1378355153.19352.29.camel@localhost> <5231A566.30904@redhat.com> <523212EF.7030302@redhat.com> <52333B14.7030403@redhat.com> Message-ID: <52335BAC.3020100@redhat.com> On 09/13/2013 12:19 PM, Petr Vobornik wrote: > ipatokenvendor will be us > , ipatokenmodel, IPA? > ipatokenserial Generated > , ipatokenotpkey Generated > , ipatokenotpalgorithm Uses default TOTP we do not support more for now. In future it will be a global policy I assume. > , > ipatokenotpdigits Should be based on a global policy: do we have a default for that? > , ipatokentotpclockoffset Internal > , ipatokentotptimestep Should be based on a global policy: do we have a default for that? > ?) and > which are less important (ipatokennotbefore IMO for the self created tokens they should be valid from the moment they are created to the moment in future governed by a default global policy. For example 3 years. Do we have an attribute for that? > , ipatokennotafter ?) Derive from previous + lifetime So for normal user to create a token it should be just a button with no parameters. -- 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:39:33 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 13 Sep 2013 14:39:33 -0400 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <52333573.5020702@redhat.com> References: <1378355153.19352.29.camel@localhost> <52333573.5020702@redhat.com> Message-ID: <52335BE5.6060402@redhat.com> On 09/13/2013 11:55 AM, Petr Vobornik wrote: > On 09/05/2013 06:25 AM, Nathaniel McCallum wrote: >> This patch has a few problems that I'd like some help with. There are a >> few notes here as well. >> > snip > > Some additional findings: > > 1. Inconsistency: 'ipatokenowner' in command output should be > normalized the same way as 'manager' in user plugin or 'seealso' in > selinuxusermap. See _normalize_manager and _convert_manager methods. > Question for all: Why don't we have general methods for such task? RFE? > > 2. Inconsistency: IntEnum doesn't convert input value as Int does. It > should also allow to specify int in a form of unicode string (IMO). > > 3. IDK how OTP matching works internally, so the following might not > be an issue, it just looks suspicious to me: I'm talking about > handling of default values for ipatokenotpalgorithm, ipatokenotpdigits > and ipatokentotptimestep. > - Defaults are hardcoded in otp_add.pre_callback and the same in auth.c. > - when values are not supplied, OTP token configuration uri is created > with the defaults. > - the values are not saved to LDAP > What will happen when these defaults will change (ie. when we want to > use more secure hashing algorithm)? I assume that OTP daemon will use > its defaults if there are no values in LDAP. After such change the > defaults are different than the values the token was configured with > so the evaluation process will fail. > > Should we save the values to LDAP? Or can we be sure that the defaults > won't change? Or am I completely wrong? > > 4. When I pass incorrectly formatted values for options > ipatokennotbefore and ipatokennotafter > i will get an error message saying: > "ipatokenNotBefore: value #0 invalid per syntax: Invalid syntax." > This message doesn't tell me what's is the correct format nor there is > any description. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From hotz at jpl.nasa.gov Fri Sep 13 22:06:34 2013 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Fri, 13 Sep 2013 15:06:34 -0700 Subject: [Freeipa-devel] Off Topic, was: [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <52335BAC.3020100@redhat.com> References: <1378355153.19352.29.camel@localhost> <5231A566.30904@redhat.com> <523212EF.7030302@redhat.com> <52333B14.7030403@redhat.com> <52335BAC.3020100@redhat.com> Message-ID: On Sep 13, 2013, at 11:38 AM, Dmitri Pal wrote: >> , ipatokenotpalgorithm > > Uses default TOTP we do not support more for now. In future it will be a > global policy I assume. This is just me, like the sig says. I would advocate for HOTP, with a bunch of special processing for token counter regression. If the token seed and current counter are stolen by a bad guy, and actually used, then at some point the bad guy or the real user are going to attempt an authentication using a value that's "old". This presents an opportunity to detect that the theft took place. I regard this as a real, useful security feature which is not possible with time-based tokens, provided the verification infrastructure is set up to do the detection, and to take some action when the detection occurs. If the theft is done by a smart-enough adversary, there may be nothing to prevent them from resynchronizing the legitimate copy of the soft-token when they use it, but it still seems like a worthwhile capability. It would detect the most obvious token-theft scenarios. Obviously, this is out-of-scope for any of your current efforts, but I wanted to throw it in the mix for possible future work. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu From jcholast at redhat.com Sat Sep 14 06:16:49 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Sat, 14 Sep 2013 08:16:49 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <5232C7B0.7090009@redhat.com> References: <1378355153.19352.29.camel@localhost> <5232C7B0.7090009@redhat.com> Message-ID: <5233FF51.5000907@redhat.com> On 13.9.2013 10:07, Jan Cholasta wrote: > On 5.9.2013 06:25, Nathaniel McCallum wrote: >> This patch has a few problems that I'd like some help with. There are a >> few notes here as well. >> >> 1. The handling of the 'key' option is insecure. It should probably be >> treated like a password (hidden from logs, etc). However, in this case, >> it is binary, so I'm not quite sure how to do that. Passing it as a >> command line option may be nice for scripting, but is potentially a >> security problem if it ends up in bash.history. It would also be nice if >> the encoding were base32 instead of base64, since nearly all the OTP >> tools use this encoding. >> >> 2. The 'key' option also appears in otp-find. I'd like to suppress this. >> How? >> >> 3. I had to make the 'id' option optional to make the uuid >> autogeneration work in otp-add. However, this has the side-effect that >> 'id' is now optional in all the other commands. This is particularly bad >> in the case of otp-del, where calling this command with no ID >> transparently removes all tokens. How can I make this optional for >> otp-add but required for all other commands? >> >> 4. otp-import is not implemented. I spent a few hours looking and I >> didn't find any otp tool that actually uses this xml format for >> exporting. Should we implement this now or wait until someone can >> actually export data to us? >> >> 5. otp-del happily deletes the last token for a user. How can I find out >> the dn of the user executing the command? Also, what is the right >> exception to throw in pre_callback()? >> >> 6. user-show does not list the associated tokens for this user. Do we >> care? It is a single search: otp-find --owner npmccallum. >> >> 7. otp-add only prints the qr code if the --qrcode option is specified. >> This is for two reasons. First, and most importantly, the qr code >> doesn't fit on a standard 24x80 terminal. I wanted to avoid dumping >> garbage on people's screens by default. Second, you may not always want >> the qr code output (like for a hard token or manual code entry). >> >> Nathaniel >> > > First, a nitpick: > > - values=(u'password', u'radius'), > + values=(u'password', u'radius', u'otp'), > > + at register() > +class otp(LDAPObject): > > IMO naming the authentication type and plugin just "otp" is confusing. > We already support one time passwords for users (and hosts as well), so > "otp" is ambiguous. I think you should at least rename the plugin to > "otptoken". > > > + # Resolve the user's dn > + owner = entry_attrs.get('ipatokenowner', None) > + if owner is not None: > + result = self.api.Command.user_show(owner)['result'] > + owner = entry_attrs['ipatokenowner'] = result['dn'] > > I think you can rewrite the above as: > > + # Resolve the user's dn > + owner = entry_attrs.get('ipatokenowner', None) > + if owner is not None: > + owner = self.api.Object.user.get_dn(owner) > + entry_attrs['ipatokenowner'] = owner > > This will save you several LDAP searches. You don't have to use > get_dn_if_exists here, because if the user does not exist, it will be > catched later in the "Get the issuer for the URI" block. > > > + self.uri = "otpauth://totp/%s:%s?%s" % (args['issuer'], label, > parameters) > > You can't do this, because plugins are singletons. See the user and host > plugins for how they handle the randompassword virtual attribute for > inspiration. > > > + entry_attrs['uri'] = self.uri > > Please add a proper param to otp_add's output_params for "uri". > > > + filters = filters.replace("(ipatokenowner=%s)" % owner, > + "(ipatokenowner=%s)" % result['dn']) > > Please do this in opt_find.args_options_2_entry (see my reply to your > radius CLI patches for details). > > > Honza > + # Generate a random uuid + if not entry_attrs.get('ipatokenuniqueid', None): + entry_attrs['ipatokenuniqueid'] = str(uuid.uuid4()) + dn = DN("ipatokenuniqueid=%s" % entry_attrs['ipatokenuniqueid'], dn) + + # Set a random key by default + if not entry_attrs.get('ipatokenotpkey', None): + key = random.SystemRandom().sample(range(255), KEY_LENGTH) + entry_attrs['ipatokenotpkey'] = "".join(map(chr, key)) This is not how default values are done, see the default_from keyword argument of Param. + def post_callback(self, ldap, dn, entry_attrs, *keys, **options): + entry_attrs['uri'] = self.uri + return LDAPCreate.post_callback(self, ldap, dn, entry_attrs, *keys, **options) "return dn" is OK here. Honza -- Jan Cholasta From jcholast at redhat.com Sat Sep 14 06:22:34 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Sat, 14 Sep 2013 08:22:34 +0200 Subject: [Freeipa-devel] [PATCH 0016] Add RADIUS proxy support to ipalib CLI In-Reply-To: <5232BCFD.506@redhat.com> References: <1378353973.19352.11.camel@localhost> <1379018880.2210.1.camel@localhost> <5232BCFD.506@redhat.com> Message-ID: <523400AA.9080700@redhat.com> On 13.9.2013 09:21, Jan Cholasta wrote: > Hi, > > On 12.9.2013 22:48, Nathaniel McCallum wrote: >> On Thu, 2013-09-05 at 00:06 -0400, Nathaniel McCallum wrote: >>> patch attached >> >> Update for ./makeapi attached. >> > > + if 'ipatokenradiusconfiglink' in entry_attrs: > + cl = entry_attrs['ipatokenradiusconfiglink'] > + if not cl: > + entry_attrs['ipatokenradiususername'] = None > + if 'ipatokenradiusproxyuser' in > entry_attrs['objectclass']: > + entry_attrs['objectclass'].remove('ipatokenradiusproxyuser') > > Is there are particular reason to remove the object class? I think you > can just leave it there, that is what we do in other plugins. > > + else: > + if 'ipatokenradiusproxyuser' not in > entry_attrs['objectclass']: > + entry_attrs['objectclass'].append('ipatokenradiusproxyuser') > + > + answer = self.api.Command.radius_show(cl) > + entry_attrs['ipatokenradiusconfiglink'] = > answer['result']['dn'] > > Please use self.api.Object.radius.get_dn_if_exists(cl) to get the DN > instead of radius_show. > > The whole code block should be added to user_add as well. > > > + radius = options.get('ipatokenradiusconfiglink', None) > + if radius is not None: > + answer = self.api.Command.radius_show(radius) > + filter = filter.replace('(ipatokenradiusconfiglink=%s)' % > radius, > + '(ipatokenradiusconfiglink=%s)' % > answer['result']['dn']) > > Again, use get_dn_if_exists instead of radius_show to get the DN. > > As for the filter processing, I think it would be safer to override > args_options_2_entry in user_find and do it in there: > > def args_options_2_entry(self, *keys, **options): > if 'ipatokenradiusconfiglink' in options: > options['ipatokenradiusconfiglink'] = > self.api.Object.radius.get_dn(options['ipatokenradiusconfiglink']) > return super(user_find, self).args_options_2_entry( ... or you can do this in user_find.execute, as there already is something similar done for the "manager" attribute. > > > Honza > BTW, I think you should configure the referential integrity plugin so that when a radius object is deleted, all ipatokenradiusconfiglink's to it are deleted as well. Honza -- Jan Cholasta From simo at redhat.com Sat Sep 14 17:25:33 2013 From: simo at redhat.com (Simo Sorce) Date: Sat, 14 Sep 2013 13:25:33 -0400 Subject: [Freeipa-devel] Off Topic, was: [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: References: <1378355153.19352.29.camel@localhost> <5231A566.30904@redhat.com> <523212EF.7030302@redhat.com> <52333B14.7030403@redhat.com> <52335BAC.3020100@redhat.com> Message-ID: <1379179533.2804.2008.camel@willson.li.ssimo.org> On Fri, 2013-09-13 at 15:06 -0700, Henry B. Hotz wrote: > On Sep 13, 2013, at 11:38 AM, Dmitri Pal wrote: > > >> , ipatokenotpalgorithm > > > > Uses default TOTP we do not support more for now. In future it will be a > > global policy I assume. > > This is just me, like the sig says. > > I would advocate for HOTP, with a bunch of special processing for > token counter regression. > > If the token seed and current counter are stolen by a bad guy, and > actually used, then at some point the bad guy or the real user are > going to attempt an authentication using a value that's "old". This > presents an opportunity to detect that the theft took place. > > I regard this as a real, useful security feature which is not possible > with time-based tokens, provided the verification infrastructure is > set up to do the detection, and to take some action when the detection > occurs. If the theft is done by a smart-enough adversary, there may > be nothing to prevent them from resynchronizing the legitimate copy of > the soft-token when they use it, but it still seems like a worthwhile > capability. It would detect the most obvious token-theft scenarios. > > Obviously, this is out-of-scope for any of your current efforts, but I > wanted to throw it in the mix for possible future work. Henry, Thanks a lot for bringing this up. I have to say that I never liked HOTP due to the burden it takes to correctly manage them compared to TOTP and the hardest work around synchronization. The worst part of it being the need to write AND synchronize across the infrastructure at every authentication attempt (replication). Something that could easily bring the whole infrastructure to its knees at busy hours. However HOTP has obvious advantages when it comes to identifying attack attempts, so I'll start thinking hard how to deal with it wrt performance. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Sat Sep 14 17:27:20 2013 From: simo at redhat.com (Simo Sorce) Date: Sat, 14 Sep 2013 13:27:20 -0400 Subject: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments In-Reply-To: <523358C6.8050804@redhat.com> References: <5232CC3E.1010401@redhat.com> <1379077690.2804.1976.camel@willson.li.ssimo.org> <523358C6.8050804@redhat.com> Message-ID: <1379179640.2804.2009.camel@willson.li.ssimo.org> On Fri, 2013-09-13 at 14:26 -0400, Dmitri Pal wrote: > On 09/13/2013 09:08 AM, Simo Sorce wrote: > > On Fri, 2013-09-13 at 10:26 +0200, Petr Spacek wrote: > >> Hello list, > >> > >> FreeIPA deployments in cloud environments do not work very well because > >> 'clouds' break some assumptions we made during FreeIPA's design. > >> > >> We should fix it somehow :-) > >> > >> === Problems === > >> - A machine has two host names in DNS: > >> -- The first name is internal to the cloud and resolvable only from inside of > >> the cloud. > >> --- This name should be used for communication inside cloud. > >> --- E.g. 'ipa.cust1.cloud.' > >> --- Internal name is mapped to internal IP address, see below. > >> > >> -- The second name is external to the cloud and should be used for > >> communication between the Internet and cloud. > >> --- E.g. 'ipa.example.com.' > >> --- External name maps to external IP address, see below. > >> > >> - A machine has two IP addresses: > >> -- Internal, private IP address configured at the machine's interface > >> --- Typically the only IP address known to the machine. > >> --- E.g. 192.0.2.22 > >> --- IP address can change dynamically, at least after a machine reboot. > >> > >> -- External, public IP address: > >> --- Typically mapped to internal address at cloud boundary (NAT). > >> --- E.g. 203.0.113.113 > >> --- IP address can change dynamically, at least after a machine reboot. > >> > >> Related tickets: > >> https://fedorahosted.org/freeipa/ticket/2648 > >> https://fedorahosted.org/freeipa/ticket/2715 > >> > >> The natural request is to add support for DNS views/split horizon DNS into > >> FreeIPA, so different names and IP addresses can be served to clients inside > >> and outside of the cloud. > >> > >> Is it enough? What else should we change to make FreeIPA reliable in clouds? > > I do not understand what's the use of views in this case. > > > > Views are used when you want to assign different IP addresses to the > > same name depending on where the query comes from. > > > > But here we have different names pointing to different addresses and the > > machine actually know nothing about the external name/IP. > > > > So what is the point of a view here ? > > > > >From the FreeIPA pov, if you use it for infrastructure you should just > > care about internal names. > > For the rare case where you want to have some client use the external > > name to access a machine then what we need to do is to make it easy (it > > is possible but not exposed now) to assign aliases to hosts so that you > > get an alias for each host/ and other service principals in the kerberos > > database and you get alternate names in the x509 certs. > > But I still do not see any issues with DNS, except for the fact that the > > network manager service of the cloud provider needs to be able to > > maintain the DNS records according to how it assigns IPs to names. > > > >> What are use cases? > >> > >> Do we want to support clients *outside* of the cloud connecting to FreeIPA > >> servers *inside* of the cloud? > > I think we should give the option, see above. > > > >> What about PKI certificates? Should we put two names to each certificate? What > >> we should do after host name change? (I do not have enough information when > >> the host name changes.) > > A change in host name will require a new certificate. But if the name is > > stable then we just need to populate certs with aliases > > > >> What about Kerberos? How it will play with host name change? How should we > >> handle the fact that internal and external names are different? Should we use > >> some sort of referral mechanism? > > Uhmm a referral may also work in future, but we could simply uses > > aliases, not all applications may work properly (some insist on a > > specific name, but a lot of apps these days can be configured to use > > just the service name and then accept tickets as long as they can be > > decrypted (key is the same). > > > >> Cloud users, please speak now :-) Opinions are more than welcome! > > Indeed, if you see any wrong assumption in here, it would be *really* > > nice to have a heads up. > > > > Simo. > > > Do we have an RFE about aliases? We should have one for kerberos, the LDAP/kdb part is already capable of supporting aliases. > Do we need several? One for Kerberos part another for PKI? May be more > than that? For client checks may be? We should have a separate one for x509 certs, yes. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Sun Sep 15 18:17:36 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 15 Sep 2013 14:17:36 -0400 Subject: [Freeipa-devel] Off Topic, was: [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: References: <1378355153.19352.29.camel@localhost> <5231A566.30904@redhat.com> <523212EF.7030302@redhat.com> <52333B14.7030403@redhat.com> <52335BAC.3020100@redhat.com> Message-ID: <5235F9C0.4020309@redhat.com> On 09/13/2013 06:06 PM, Henry B. Hotz wrote: > On Sep 13, 2013, at 11:38 AM, Dmitri Pal wrote: > >>> , ipatokenotpalgorithm >> Uses default TOTP we do not support more for now. In future it will be a >> global policy I assume. > This is just me, like the sig says. > > I would advocate for HOTP, with a bunch of special processing for token counter regression. > > If the token seed and current counter are stolen by a bad guy, and actually used, then at some point the bad guy or the real user are going to attempt an authentication using a value that's "old". This presents an opportunity to detect that the theft took place. > > I regard this as a real, useful security feature which is not possible with time-based tokens, provided the verification infrastructure is set up to do the detection, and to take some action when the detection occurs. If the theft is done by a smart-enough adversary, there may be nothing to prevent them from resynchronizing the legitimate copy of the soft-token when they use it, but it still seems like a worthwhile capability. It would detect the most obvious token-theft scenarios. > > Obviously, this is out-of-scope for any of your current efforts, but I wanted to throw it in the mix for possible future work. Count creates an overhead in the replicated environment. Effectively you need to replicate count on every authentication, this is a big cost. While it is more secure for the case you suggest it does not seem to be a good enough justification for the replication overhead. If stolen the chance that it will be used some tine later is really slim. It most likely will be used right away so the old code detection will be irrelevant. But we anticipate that there will be cases when HOTP will be needed, so we do not preclude implementing it in future but on the other hand do not see it as an immediate goal either. > > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu > -- 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 Sun Sep 15 18:19:09 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 15 Sep 2013 14:19:09 -0400 Subject: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments In-Reply-To: <1379179640.2804.2009.camel@willson.li.ssimo.org> References: <5232CC3E.1010401@redhat.com> <1379077690.2804.1976.camel@willson.li.ssimo.org> <523358C6.8050804@redhat.com> <1379179640.2804.2009.camel@willson.li.ssimo.org> Message-ID: <5235FA1D.2010600@redhat.com> On 09/14/2013 01:27 PM, Simo Sorce wrote: > On Fri, 2013-09-13 at 14:26 -0400, Dmitri Pal wrote: >> On 09/13/2013 09:08 AM, Simo Sorce wrote: >>> On Fri, 2013-09-13 at 10:26 +0200, Petr Spacek wrote: >>>> Hello list, >>>> >>>> FreeIPA deployments in cloud environments do not work very well because >>>> 'clouds' break some assumptions we made during FreeIPA's design. >>>> >>>> We should fix it somehow :-) >>>> >>>> === Problems === >>>> - A machine has two host names in DNS: >>>> -- The first name is internal to the cloud and resolvable only from inside of >>>> the cloud. >>>> --- This name should be used for communication inside cloud. >>>> --- E.g. 'ipa.cust1.cloud.' >>>> --- Internal name is mapped to internal IP address, see below. >>>> >>>> -- The second name is external to the cloud and should be used for >>>> communication between the Internet and cloud. >>>> --- E.g. 'ipa.example.com.' >>>> --- External name maps to external IP address, see below. >>>> >>>> - A machine has two IP addresses: >>>> -- Internal, private IP address configured at the machine's interface >>>> --- Typically the only IP address known to the machine. >>>> --- E.g. 192.0.2.22 >>>> --- IP address can change dynamically, at least after a machine reboot. >>>> >>>> -- External, public IP address: >>>> --- Typically mapped to internal address at cloud boundary (NAT). >>>> --- E.g. 203.0.113.113 >>>> --- IP address can change dynamically, at least after a machine reboot. >>>> >>>> Related tickets: >>>> https://fedorahosted.org/freeipa/ticket/2648 >>>> https://fedorahosted.org/freeipa/ticket/2715 >>>> >>>> The natural request is to add support for DNS views/split horizon DNS into >>>> FreeIPA, so different names and IP addresses can be served to clients inside >>>> and outside of the cloud. >>>> >>>> Is it enough? What else should we change to make FreeIPA reliable in clouds? >>> I do not understand what's the use of views in this case. >>> >>> Views are used when you want to assign different IP addresses to the >>> same name depending on where the query comes from. >>> >>> But here we have different names pointing to different addresses and the >>> machine actually know nothing about the external name/IP. >>> >>> So what is the point of a view here ? >>> >>> >From the FreeIPA pov, if you use it for infrastructure you should just >>> care about internal names. >>> For the rare case where you want to have some client use the external >>> name to access a machine then what we need to do is to make it easy (it >>> is possible but not exposed now) to assign aliases to hosts so that you >>> get an alias for each host/ and other service principals in the kerberos >>> database and you get alternate names in the x509 certs. >>> But I still do not see any issues with DNS, except for the fact that the >>> network manager service of the cloud provider needs to be able to >>> maintain the DNS records according to how it assigns IPs to names. >>> >>>> What are use cases? >>>> >>>> Do we want to support clients *outside* of the cloud connecting to FreeIPA >>>> servers *inside* of the cloud? >>> I think we should give the option, see above. >>> >>>> What about PKI certificates? Should we put two names to each certificate? What >>>> we should do after host name change? (I do not have enough information when >>>> the host name changes.) >>> A change in host name will require a new certificate. But if the name is >>> stable then we just need to populate certs with aliases >>> >>>> What about Kerberos? How it will play with host name change? How should we >>>> handle the fact that internal and external names are different? Should we use >>>> some sort of referral mechanism? >>> Uhmm a referral may also work in future, but we could simply uses >>> aliases, not all applications may work properly (some insist on a >>> specific name, but a lot of apps these days can be configured to use >>> just the service name and then accept tickets as long as they can be >>> decrypted (key is the same). >>> >>>> Cloud users, please speak now :-) Opinions are more than welcome! >>> Indeed, if you see any wrong assumption in here, it would be *really* >>> nice to have a heads up. >>> >>> Simo. >>> >> Do we have an RFE about aliases? > We should have one for kerberos, the LDAP/kdb part is already capable of > supporting aliases. > >> Do we need several? One for Kerberos part another for PKI? May be more >> than that? For client checks may be? > We should have a separate one for x509 certs, yes. > > Simo. > Please open. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From purpleidea at gmail.com Mon Sep 16 04:32:41 2013 From: purpleidea at gmail.com (James) Date: Mon, 16 Sep 2013 00:32:41 -0400 Subject: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments In-Reply-To: <5232CC3E.1010401@redhat.com> References: <5232CC3E.1010401@redhat.com> Message-ID: On Fri, Sep 13, 2013 at 4:26 AM, Petr Spacek wrote: > Hello list, Hey > > FreeIPA deployments in cloud environments do not work very well because > 'clouds' break some assumptions we made during FreeIPA's design. > > We should fix it somehow :-) Agreed ! > > === Problems === > - A machine has two host names in DNS: > -- The first name is internal to the cloud and resolvable only from inside > of the cloud. > --- This name should be used for communication inside cloud. > --- E.g. 'ipa.cust1.cloud.' > --- Internal name is mapped to internal IP address, see below. > > -- The second name is external to the cloud and should be used for > communication between the Internet and cloud. > --- E.g. 'ipa.example.com.' > --- External name maps to external IP address, see below. > > - A machine has two IP addresses: > -- Internal, private IP address configured at the machine's interface > --- Typically the only IP address known to the machine. > --- E.g. 192.0.2.22 > --- IP address can change dynamically, at least after a machine reboot. In my situation, the IP's are always constant. > > -- External, public IP address: > --- Typically mapped to internal address at cloud boundary (NAT). > --- E.g. 203.0.113.113 > --- IP address can change dynamically, at least after a machine reboot. > > Related tickets: > https://fedorahosted.org/freeipa/ticket/2648 > https://fedorahosted.org/freeipa/ticket/2715 > > The natural request is to add support for DNS views/split horizon DNS into > FreeIPA, so different names and IP addresses can be served to clients inside > and outside of the cloud. I've asked about split view DNS support before. It would be extremely valuable! > > Is it enough? What else should we change to make FreeIPA reliable in clouds? > > What are use cases? As described above, my particular use case is one machine with one consistent hostname, but with multiple IP addresses. Internally the VM sees itself as say 10.10.10.1, but externally it might have one or more different addresses that are used to NAT directly to it for example. > > Do we want to support clients *outside* of the cloud connecting to FreeIPA > servers *inside* of the cloud? > > What about PKI certificates? Should we put two names to each certificate? > What we should do after host name change? (I do not have enough information > when the host name changes.) I never have any issues about different host names. All are consistent. > > What about Kerberos? How it will play with host name change? How should we > handle the fact that internal and external names are different? Should we > use some sort of referral mechanism? > > > Cloud users, please speak now :-) Opinions are more than welcome! Some comments are given above. Please keep me in the loop. Once this is cooking, I'd love to add puppet-ipa support to match. https://github.com/purpleidea/puppet-ipa I'm happy to answer any questions you have. > > -- > Petr^2 Spacek Thanks, James > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From mkosek at redhat.com Mon Sep 16 07:06:02 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Sep 2013 09:06:02 +0200 Subject: [Freeipa-devel] DNS improvements: Should we add some sanity checking? In-Reply-To: <1379089071.2804.1987.camel@willson.li.ssimo.org> References: <20130913070214.GU10627@redhat.com> <5232BEDC.5000000@redhat.com> <1379089071.2804.1987.camel@willson.li.ssimo.org> Message-ID: <5236ADDA.7000700@redhat.com> On 09/13/2013 06:17 PM, Simo Sorce wrote: > On Fri, 2013-09-13 at 09:29 +0200, Petr Spacek wrote: >> Hello list, >> >> Jan Pazdziora proposed that 'ipa dns*' commands should >> do some sanity checking/waiting after the record is added to LDAP. >> >> I think that it could be valuable and I would like to get opinions from >> freeipa-devel list. >> >> >> === The problem === >> ipa dnsrecord-add and similar commands add the data to LDAP, but it doesn't >> mean that the data are *immediately* resolvable via DNS protocol. Note that >> data from LDAP are *asynchronously* read and processed by Named and the time >> when records are available is not predictable. >> >> A mismatch between LDAP can be caused by some connection problem between DNS >> and LDAP servers, LDAP or DNS server restart, or simply by a bug in DNS<->LDAP >> synchronization code. (This is becomming more and more important if we >> consider the whole DNSSEC effort and related re-factoring.) >> >> My experience is that users are very confused if the ipa dnsrecord-add command >> says 'record added' but it is still not available via DNS. It is really hard >> to debug when you see the problem first 10 times :-) >> >> >> === The proposal === >> 1. Let FreeIPA framework to change DNS data in LDAP as we do now. >> 2. After each change, do DNS queries for changed record and wait until the new >> data are available. >> >> IMHO it is very cheap operation (in usual cases 1 DNS packet back and forth) >> and it would save a lot of headaches to users and support. >> >> This will naturally catch the case where named crashes after the change etc. >> >> >> === Expected outcome === >> There will not be any failure like this: >> >> $ ipa-adtrust-install >> >> $ ipa dnszone-add $AD_DOMAIN --name-server=advm.$AD_DOMAIN >> --admin-email="hostmaster@$AD_DOMAIN.com" --force --forwarder=$AD_IP >> --forward-policy=only --ip-address=$AD_IP >> Zone name: dom123.example.com >> [...] >> >> $ ipa trust-add --type=ad DOM123.EXAMPLE.COM --admin Administrator --password >> Password for admin at DOM123.EXAMPLE.COM: >> ipa: ERROR: Cannot find specified domain or server name >> > > Would it make sense to change the code to use dynDNS update to add > records ? > > Wouldn't that force named to be in sync ? > > Simo. Switching from LDAP modify operation to dynDNS update seems as a too big change to me. If nothing else, it would not fly with our LDAP ACI/permission system and ability to delegate DNS read/write rights to somebody else. Martin From mkosek at redhat.com Mon Sep 16 07:07:25 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Sep 2013 09:07:25 +0200 Subject: [Freeipa-devel] [PATCH] Add delegation info to MS-PAC In-Reply-To: <20130913130154.GM21212@redhat.com> References: <1360273346.2299.15.camel@willson.li.ssimo.org> <20130913130154.GM21212@redhat.com> Message-ID: <5236AE2D.9010906@redhat.com> On 09/13/2013 03:01 PM, Alexander Bokovoy wrote: > On Thu, 07 Feb 2013, Simo Sorce wrote: >> This information is not strictly required but is part of the MS-PAC >> specification and I had some time to kill on the plane on my last trip >> back. >> >> I tested it briefly with cross-realm trusts and it seem to work fine. >> Neither IPA nor AD2012 complained when looking at PACs, do far. > Reviving. > > It is actually required part as without it smbd will deny our attempt to > establish local part of the trust in some cases by misinterpreting what > we put in the PAC and thinking that a service impersonating original > user is the actual user but taking original user name as an account > name. > > With this patch everything works fine. ACK. > Is this fix required also for FreeIPA 3.3 and it's features? I did not understand that from the bug description. Martin From mkosek at redhat.com Mon Sep 16 07:12:44 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Sep 2013 09:12:44 +0200 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <523359F1.6030002@redhat.com> References: <523049A5.10208@redhat.com> <1378916880.2804.1612.camel@willson.li.ssimo.org> <5230DF98.1040501@redhat.com> <5231563C.8090203@redhat.com> <1378991670.2804.1893.camel@willson.li.ssimo.org> <52320DE8.7050401@redhat.com> <1379013764.2804.1948.camel@willson.li.ssimo.org> <5232FCDE.1020804@redhat.com> <1379077978.2804.1978.camel@willson.li.ssimo.org> <523359F1.6030002@redhat.com> Message-ID: <5236AF6C.8070905@redhat.com> On 09/13/2013 08:31 PM, Dmitri Pal wrote: > On 09/13/2013 09:12 AM, Simo Sorce wrote: >> On Fri, 2013-09-13 at 13:54 +0200, Petr Vobornik wrote: ... >> Well my concern remains that if we want to change later it will take >> some effort, but I guess it is better to have improved docs now and take >> care of the 'ruby' problem later if it becomes an issue. >> >> I find it amusing we have to use ruby to document javascript though, you >> would think javascript is a good enough language to do that :-D >> >> Simo. >> > I take this as an ack for JSDuck. Right. Until we find that using ruby is indeed a blocker or until we find some way to get rid of ruby without degrading Web UI docs quality... Martin From abokovoy at redhat.com Mon Sep 16 07:14:01 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 16 Sep 2013 10:14:01 +0300 Subject: [Freeipa-devel] [PATCH] Add delegation info to MS-PAC In-Reply-To: <5236AE2D.9010906@redhat.com> References: <1360273346.2299.15.camel@willson.li.ssimo.org> <20130913130154.GM21212@redhat.com> <5236AE2D.9010906@redhat.com> Message-ID: <20130916071401.GO21212@redhat.com> On Mon, 16 Sep 2013, Martin Kosek wrote: >On 09/13/2013 03:01 PM, Alexander Bokovoy wrote: >> On Thu, 07 Feb 2013, Simo Sorce wrote: >>> This information is not strictly required but is part of the MS-PAC >>> specification and I had some time to kill on the plane on my last trip >>> back. >>> >>> I tested it briefly with cross-realm trusts and it seem to work fine. >>> Neither IPA nor AD2012 complained when looking at PACs, do far. >> Reviving. >> >> It is actually required part as without it smbd will deny our attempt to >> establish local part of the trust in some cases by misinterpreting what >> we put in the PAC and thinking that a service impersonating original >> user is the actual user but taking original user name as an account >> name. >> >> With this patch everything works fine. ACK. >> > >Is this fix required also for FreeIPA 3.3 and it's features? I did not >understand that from the bug description. Yes. It is one of fixes to the issues Tomas was seeing with his test automation scripts. -- / Alexander Bokovoy From mkosek at redhat.com Mon Sep 16 07:29:10 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Sep 2013 09:29:10 +0200 Subject: [Freeipa-devel] [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <52335BE5.6060402@redhat.com> References: <1378355153.19352.29.camel@localhost> <52333573.5020702@redhat.com> <52335BE5.6060402@redhat.com> Message-ID: <5236B346.7060608@redhat.com> On 09/13/2013 08:39 PM, Dmitri Pal wrote: > On 09/13/2013 11:55 AM, Petr Vobornik wrote: >> On 09/05/2013 06:25 AM, Nathaniel McCallum wrote: >>> This patch has a few problems that I'd like some help with. There are a >>> few notes here as well. >>> >> snip >> >> Some additional findings: >> >> 1. Inconsistency: 'ipatokenowner' in command output should be >> normalized the same way as 'manager' in user plugin or 'seealso' in >> selinuxusermap. See _normalize_manager and _convert_manager methods. >> Question for all: Why don't we have general methods for such task? > > RFE? +1. https://fedorahosted.org/freeipa/ticket/3932 Martin From pspacek at redhat.com Mon Sep 16 07:31:47 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 16 Sep 2013 09:31:47 +0200 Subject: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments In-Reply-To: <5235FA1D.2010600@redhat.com> References: <5232CC3E.1010401@redhat.com> <1379077690.2804.1976.camel@willson.li.ssimo.org> <523358C6.8050804@redhat.com> <1379179640.2804.2009.camel@willson.li.ssimo.org> <5235FA1D.2010600@redhat.com> Message-ID: <5236B3E3.4090809@redhat.com> On 15.9.2013 20:19, Dmitri Pal wrote: > On 09/14/2013 01:27 PM, Simo Sorce wrote: >> >On Fri, 2013-09-13 at 14:26 -0400, Dmitri Pal wrote: >>> >>On 09/13/2013 09:08 AM, Simo Sorce wrote: >>>> >>>On Fri, 2013-09-13 at 10:26 +0200, Petr Spacek wrote: >>>>> >>>>Hello list, >>>>> >>>> >>>>> >>>>FreeIPA deployments in cloud environments do not work very well because >>>>> >>>>'clouds' break some assumptions we made during FreeIPA's design. >>>>> >>>> >>>>> >>>>We should fix it somehow:-) >>>>> >>>> >>>>> >>>>=== Problems === >>>>> >>>>- A machine has two host names in DNS: >>>>> >>>>-- The first name is internal to the cloud and resolvable only from inside of >>>>> >>>>the cloud. >>>>> >>>>--- This name should be used for communication inside cloud. >>>>> >>>>--- E.g. 'ipa.cust1.cloud.' >>>>> >>>>--- Internal name is mapped to internal IP address, see below. >>>>> >>>> >>>>> >>>>-- The second name is external to the cloud and should be used for >>>>> >>>>communication between the Internet and cloud. >>>>> >>>>--- E.g. 'ipa.example.com.' >>>>> >>>>--- External name maps to external IP address, see below. >>>>> >>>> >>>>> >>>>- A machine has two IP addresses: >>>>> >>>>-- Internal, private IP address configured at the machine's interface >>>>> >>>>--- Typically the only IP address known to the machine. >>>>> >>>>--- E.g. 192.0.2.22 >>>>> >>>>--- IP address can change dynamically, at least after a machine reboot. >>>>> >>>> >>>>> >>>>-- External, public IP address: >>>>> >>>>--- Typically mapped to internal address at cloud boundary (NAT). >>>>> >>>>--- E.g. 203.0.113.113 >>>>> >>>>--- IP address can change dynamically, at least after a machine reboot. >>>>> >>>> >>>>> >>>>Related tickets: >>>>> >>>>https://fedorahosted.org/freeipa/ticket/2648 >>>>> >>>>https://fedorahosted.org/freeipa/ticket/2715 >>>>> >>>> >>>>> >>>>The natural request is to add support for DNS views/split horizon DNS into >>>>> >>>>FreeIPA, so different names and IP addresses can be served to clients inside >>>>> >>>>and outside of the cloud. >>>>> >>>> >>>>> >>>>Is it enough? What else should we change to make FreeIPA reliable in clouds? >>>> >>>I do not understand what's the use of views in this case. >>>> >>> >>>> >>>Views are used when you want to assign different IP addresses to the >>>> >>>same name depending on where the query comes from. You are right, the scenario described by me doesn't require views. Please see reply from James in another part of this thread - his setup has shared host name (internal = external) but different IP addresses for internal and external usage. The question is if DNS is the right layer to solve the problem. Some oddities like this could be solved on IP routing level: I.e. use 'external'/public IP address everywhere and route packets with this 'external IP' to the right part of the internal network. Solution on routing layer can be technically feasible, but it doesn't mean that it is politically acceptable. People usually don't want to touch routing unless absolutely necessary :-) -- Petr^2 Spacek From pspacek at redhat.com Mon Sep 16 07:45:41 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 16 Sep 2013 09:45:41 +0200 Subject: [Freeipa-devel] DNS improvements: Should we add some sanity checking? In-Reply-To: <5236ADDA.7000700@redhat.com> References: <20130913070214.GU10627@redhat.com> <5232BEDC.5000000@redhat.com> <1379089071.2804.1987.camel@willson.li.ssimo.org> <5236ADDA.7000700@redhat.com> Message-ID: <5236B725.7040705@redhat.com> On 16.9.2013 09:06, Martin Kosek wrote: > On 09/13/2013 06:17 PM, Simo Sorce wrote: >> On Fri, 2013-09-13 at 09:29 +0200, Petr Spacek wrote: >>> Hello list, >>> >>> Jan Pazdziora proposed that 'ipa dns*' commands should >>> do some sanity checking/waiting after the record is added to LDAP. >>> >>> I think that it could be valuable and I would like to get opinions from >>> freeipa-devel list. >>> >>> >>> === The problem === >>> ipa dnsrecord-add and similar commands add the data to LDAP, but it doesn't >>> mean that the data are *immediately* resolvable via DNS protocol. Note that >>> data from LDAP are *asynchronously* read and processed by Named and the time >>> when records are available is not predictable. >>> >>> A mismatch between LDAP can be caused by some connection problem between DNS >>> and LDAP servers, LDAP or DNS server restart, or simply by a bug in DNS<->LDAP >>> synchronization code. (This is becomming more and more important if we >>> consider the whole DNSSEC effort and related re-factoring.) >>> >>> My experience is that users are very confused if the ipa dnsrecord-add command >>> says 'record added' but it is still not available via DNS. It is really hard >>> to debug when you see the problem first 10 times :-) >>> >>> >>> === The proposal === >>> 1. Let FreeIPA framework to change DNS data in LDAP as we do now. >>> 2. After each change, do DNS queries for changed record and wait until the new >>> data are available. >>> >>> IMHO it is very cheap operation (in usual cases 1 DNS packet back and forth) >>> and it would save a lot of headaches to users and support. >>> >>> This will naturally catch the case where named crashes after the change etc. >>> >>> >>> === Expected outcome === >>> There will not be any failure like this: >>> >>> $ ipa-adtrust-install >>> >>> $ ipa dnszone-add $AD_DOMAIN --name-server=advm.$AD_DOMAIN >>> --admin-email="hostmaster@$AD_DOMAIN.com" --force --forwarder=$AD_IP >>> --forward-policy=only --ip-address=$AD_IP >>> Zone name: dom123.example.com >>> [...] >>> >>> $ ipa trust-add --type=ad DOM123.EXAMPLE.COM --admin Administrator --password >>> Password for admin at DOM123.EXAMPLE.COM: >>> ipa: ERROR: Cannot find specified domain or server name >>> >> >> Would it make sense to change the code to use dynDNS update to add >> records ? >> >> Wouldn't that force named to be in sync ? >> >> Simo. > > Switching from LDAP modify operation to dynDNS update seems as a too big change > to me. If nothing else, it would not fly with our LDAP ACI/permission system > and ability to delegate DNS read/write rights to somebody else. I can see pros and cons for both ways: LDAP: + we have the code :-) + ACI magic - works only with bind-dyndb-ldap - can get out of sync (bugs, timeouts etc.) Standard DNS updates: + can work with any DNS server + with AD integration, we could use existing AD DNS infrastructure: i.e. manage DNS records for FreeIPA servers and host without deploying a new DNS server and related 'politics' + bind-dyndb-ldap is not necessary (ouh, my work is useless now :-)) - we don't have the code in FreeIPA framework - ACI magic is not available (in reality, it depends on the DNS server) - reading of current state could be more complex for user interface (On the other hand, current user interface doesn't show real state of thing because LDAP != DNS.) -- Petr^2 Spacek From pviktori at redhat.com Mon Sep 16 07:54:51 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Sep 2013 09:54:51 +0200 Subject: [Freeipa-devel] [PATCH] Add delegation info to MS-PAC In-Reply-To: <20130916071401.GO21212@redhat.com> References: <1360273346.2299.15.camel@willson.li.ssimo.org> <20130913130154.GM21212@redhat.com> <5236AE2D.9010906@redhat.com> <20130916071401.GO21212@redhat.com> Message-ID: <5236B94B.7060509@redhat.com> On 09/16/2013 09:14 AM, Alexander Bokovoy wrote: > On Mon, 16 Sep 2013, Martin Kosek wrote: >> On 09/13/2013 03:01 PM, Alexander Bokovoy wrote: >>> On Thu, 07 Feb 2013, Simo Sorce wrote: >>>> This information is not strictly required but is part of the MS-PAC >>>> specification and I had some time to kill on the plane on my last trip >>>> back. >>>> >>>> I tested it briefly with cross-realm trusts and it seem to work fine. >>>> Neither IPA nor AD2012 complained when looking at PACs, do far. >>> Reviving. >>> >>> It is actually required part as without it smbd will deny our attempt to >>> establish local part of the trust in some cases by misinterpreting what >>> we put in the PAC and thinking that a service impersonating original >>> user is the actual user but taking original user name as an account >>> name. >>> >>> With this patch everything works fine. ACK. >>> >> >> Is this fix required also for FreeIPA 3.3 and it's features? I did not >> understand that from the bug description. > Yes. It is one of fixes to the issues Tomas was seeing with his test > automation scripts. I've also pushed it to ipa-3-3: 7de103739172e4d3690d71fb686addc4edae027e -- Petr? From pspacek at redhat.com Mon Sep 16 07:58:42 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 16 Sep 2013 09:58:42 +0200 Subject: [Freeipa-devel] [PATCH] Coverity fixes for slapi-nis In-Reply-To: <20130902135813.GF21212@redhat.com> References: <20130902135813.GF21212@redhat.com> Message-ID: <5236BA32.5030302@redhat.com> On 2.9.2013 15:58, Alexander Bokovoy wrote: > Hi Nalin, > > attached please find two patches that fix minor Coverity issues. > > The first patch is for issue 11937 which is a false positive but caught > up wrong use of the helper method -- the method map_data_set_entry() > passes key and value length arguments through to map_data_save_list() > which expects them to be arrays but we pass pointer to the variable. > Luckily, in our case map_data_save_list() never goes beyond element 0 of > the array so the fix is mostly cosmetic. > > The second fix is in PAM wrapper in the tests and minor too -- we would > leak a memory if PAM wrapper wasn't called under wrapping condition. > > The same patches are in my Fedora people slapi-nis tree, branch > 'coverity': > http://fedorapeople.org/cgit/abbra/public_git/slapi-nis.git/log/?h=coverity ACK -- Petr^2 Spacek From tbabej at redhat.com Mon Sep 16 08:18:52 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 16 Sep 2013 10:18:52 +0200 Subject: [Freeipa-devel] [PATCHES] 0094-0099 Make Fuzzy objects available for the whole ipatests module In-Reply-To: <52335132.8020603@redhat.com> References: <52331D35.7010900@redhat.com> <523335CF.8030000@redhat.com> <523345A7.1080303@redhat.com> <52335132.8020603@redhat.com> Message-ID: <5236BEEC.20201@redhat.com> On 09/13/2013 07:53 PM, Petr Viktorin wrote: > On 09/13/2013 07:04 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 09/13/2013 04:12 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> The following patches move and extend the functionality of Fuzzy >>>> objects. This is necessary to use them from within integration tests. >>> >>> -1 to the idea. >>> I'm not a fan of the Fuzzy objects; they basically exist so that you >>> can >>> use regex matching in the Declarative tests. >>> As you've probably noticed Fuzzy is quite specific to the framework and >>> its test suite -- see the strict bytes/unicode separation and the >>> amount >>> of changes it takes to tear them out. >>> >>> I'm also not a fan of having a generic "Match anything using some >>> rules" >>> object where everybody adds behavior specific to their use case. Each >>> addition increases the complexity and number of corner cases, and the >>> complete intended functionality can never be achieved. >>> >>> Using regular expressions directly should actually be easier and less >>> error-prone in most cases. >>> If you disagree, I'd like to see your use case. >> >> I'm not sure what the objection is, Fuzzy is just an abstraction. It >> lets one do in-line regex which is the reason it was introduced >> (initially for uid and gid because they are non-deterministic). > > Yes. "In-line" is the key here. It lets you do regex matching via the > == operator, which is what Declarative tests need, but elsewhere the > abstraction is completely unnecessary. > >> Replacing it would either a) replicate its functionality almost >> completely or b) spread duplicate regex code all over the place. > > I'd go for b; spreading this code: > import re > some_regex = re.compile('some.*regex$') > ... > assert some_regex.search(x) > instead of: > from wherever import Fuzzy > warm_fuzzy = Fuzzy('some.*regex$') > ... > assert x == warm_fuzzy > all over the place is fine in my book. And you can even, say, add > custom flags to the regex without complicating shared code. > > The rest of Fuzzy functionality consists of strict type checking > (which isn't really necessary in integration tests), and the ability > to call arbitrary callables (which is just the scope creep I was > talking about). > By the way, in current tests these features are hardly ever used in > combination. > Even if this extra functionality is necessary, it's orthogonal to > regex matching and can be more cleanly done with several separate > asserts. Unless you need a single declarative object to compare > against, of course. > >> That isn't to say that Fuzzy isn't being abused, but that is also the >> responsibility of the reviewers to be strict about. > > Then perhaps I'm too strict, but I say that using it outside of the > declarative tests is abuse. > Especially if it takes six patches with hundreds of changed lines to > repurpose Fuzzy for integration tests (but that's not part of "-1 to > the idea"). > While I have no strong opinions on using Fuzzy or regex directly in the integration tests, I wouldn't deprecate the idea of moving the Fuzzy object and its instances to a separate module. We can make this part of test_xmlrpc module, and that would drive the message that Fuzzy should be used only within declarative tests home much more than the current state, when we have the functionality implemented at several levels (instances in ipatests.test_xmlrpc.xmlrpc_test, class in ipatests.util). Patches also add some neat functionality, as enabling stacking regex Fuzzy objects together, or removing the counter-intuitive restriction for unicode type with regex (replaced by the explicit usage of the 'u' property, which is better than the implicit requirement). Attached patches move the Fuzzy functionality to the ipatests.test_xmlrpc.fuzzy module. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0094-2-ipatests-Make-basestring-default-type-for-Fuzzy-when.patch Type: text/x-patch Size: 1215 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0095-2-ipatests-Add-line_unbound_regex-property-to-Fuzzy-ob.patch Type: text/x-patch Size: 968 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0096-2-ipatests-Move-generic-fuzzy-expressions-to-ipatests-.patch Type: text/x-patch Size: 201952 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0097-2-ipatests-Add-u-property-to-the-Fuzzy-object.patch Type: text/x-patch Size: 1745 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0098-2-ipatests-Add-unit-tests-for-u-and-line_unbound_regex.patch Type: text/x-patch Size: 3572 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0099-2-ipatests-Restrict-fuzzy-objects-in-unit-tests-to-uni.patch Type: text/x-patch Size: 94578 bytes Desc: not available URL: From pviktori at redhat.com Mon Sep 16 10:36:47 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Sep 2013 12:36:47 +0200 Subject: [Freeipa-devel] [PATCH] 0063 Do not show unexpected error in ipa-ldap-updater In-Reply-To: <5225BE75.5070501@redhat.com> References: <5225BE75.5070501@redhat.com> Message-ID: <5236DF3F.9060100@redhat.com> On 09/03/2013 12:48 PM, Ana Krivokapic wrote: > Hello, > > This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3825. > ACK, pushed to master: 15cc9740c0ae7d4715df97a1b9ec0166d47c30c2 -- Petr? From pviktori at redhat.com Mon Sep 16 11:40:30 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Sep 2013 13:40:30 +0200 Subject: [Freeipa-devel] [PATCH] 0065 Follow tmpfiles.d packaging guidelines In-Reply-To: <52275F8A.4080105@redhat.com> References: <52275F8A.4080105@redhat.com> Message-ID: <5236EE2E.2060306@redhat.com> On 09/04/2013 06:27 PM, Ana Krivokapic wrote: > Hello, > > This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3881. > Thank you! ACK, pushed to: master: 7c22b852c73b94148043dd35636e2dd21a80d531 ipa-3-3: 771511fd2597c907fc5293ce1289070551240a91 -- Petr? From pviktori at redhat.com Mon Sep 16 11:58:14 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Sep 2013 13:58:14 +0200 Subject: [Freeipa-devel] [PATCH] 450 Fix redirection on deletion of last dns record entry In-Reply-To: <5229EAEF.8070008@redhat.com> References: <5229CAE1.6020003@redhat.com> <5229EAEF.8070008@redhat.com> Message-ID: <5236F256.3020309@redhat.com> On 09/06/2013 04:47 PM, Ana Krivokapic wrote: > On 09/06/2013 02:30 PM, Petr Vobornik wrote: >> https://fedorahosted.org/freeipa/ticket/3907 >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK > Pushed to: master: 5c4a72de59840b84a128c8649c8d7b4333344993 ipa-3-3: ac5447f57953dd022f63f9f801c5628df3e4b832 -- Petr? From rcritten at redhat.com Mon Sep 16 12:36:26 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Sep 2013 08:36:26 -0400 Subject: [Freeipa-devel] [PATCHES] 0094-0099 Make Fuzzy objects available for the whole ipatests module In-Reply-To: <52335132.8020603@redhat.com> References: <52331D35.7010900@redhat.com> <523335CF.8030000@redhat.com> <523345A7.1080303@redhat.com> <52335132.8020603@redhat.com> Message-ID: <5236FB4A.2030903@redhat.com> Petr Viktorin wrote: > On 09/13/2013 07:04 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 09/13/2013 04:12 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> The following patches move and extend the functionality of Fuzzy >>>> objects. This is necessary to use them from within integration tests. >>> >>> -1 to the idea. >>> I'm not a fan of the Fuzzy objects; they basically exist so that you can >>> use regex matching in the Declarative tests. >>> As you've probably noticed Fuzzy is quite specific to the framework and >>> its test suite -- see the strict bytes/unicode separation and the amount >>> of changes it takes to tear them out. >>> >>> I'm also not a fan of having a generic "Match anything using some rules" >>> object where everybody adds behavior specific to their use case. Each >>> addition increases the complexity and number of corner cases, and the >>> complete intended functionality can never be achieved. >>> >>> Using regular expressions directly should actually be easier and less >>> error-prone in most cases. >>> If you disagree, I'd like to see your use case. >> >> I'm not sure what the objection is, Fuzzy is just an abstraction. It >> lets one do in-line regex which is the reason it was introduced >> (initially for uid and gid because they are non-deterministic). > > Yes. "In-line" is the key here. It lets you do regex matching via the == > operator, which is what Declarative tests need, but elsewhere the > abstraction is completely unnecessary. > >> Replacing it would either a) replicate its functionality almost >> completely or b) spread duplicate regex code all over the place. > > I'd go for b; spreading this code: > import re > some_regex = re.compile('some.*regex$') > ... > assert some_regex.search(x) > instead of: > from wherever import Fuzzy > warm_fuzzy = Fuzzy('some.*regex$') > ... > assert x == warm_fuzzy > all over the place is fine in my book. And you can even, say, add custom > flags to the regex without complicating shared code. Right, and it's all duplicate. Just look in his patch how many times fuzzy.digits is used. What's going to happen is someone is going to come along later and say "Geez, we have a ton of some_regex = re.compile('\d+'), I should make a macro thinger out of this" and we're back where we started. > The rest of Fuzzy functionality consists of strict type checking (which > isn't really necessary in integration tests), and the ability to call > arbitrary callables (which is just the scope creep I was talking about). > By the way, in current tests these features are hardly ever used in > combination. Here we agree. I'd prefer to keep Fuzzy limited to just simple regex and woudln't object to delegating the other enforcement to something else. > Even if this extra functionality is necessary, it's orthogonal to regex > matching and can be more cleanly done with several separate asserts. > Unless you need a single declarative object to compare against, of course. Yup. > >> That isn't to say that Fuzzy isn't being abused, but that is also the >> responsibility of the reviewers to be strict about. > > Then perhaps I'm too strict, but I say that using it outside of the > declarative tests is abuse. > Especially if it takes six patches with hundreds of changed lines to > repurpose Fuzzy for integration tests (but that's not part of "-1 to the > idea"). That is hardly fair. The bulk of the patches just change imports. So to summarize, I think: - Fuzzy should remain as a regex should remain as a regex shortcut - The non-regex features can be moved elsewhere - I don't really have a handle on how he intended to use this for integration testing, so I don't have an opinion here. But I'd expect that most integration tests depend more on return values than comparing against "known good". rob From purpleidea at gmail.com Mon Sep 16 12:51:21 2013 From: purpleidea at gmail.com (James) Date: Mon, 16 Sep 2013 08:51:21 -0400 Subject: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments In-Reply-To: <5236B3E3.4090809@redhat.com> References: <5232CC3E.1010401@redhat.com> <1379077690.2804.1976.camel@willson.li.ssimo.org> <523358C6.8050804@redhat.com> <1379179640.2804.2009.camel@willson.li.ssimo.org> <5235FA1D.2010600@redhat.com> <5236B3E3.4090809@redhat.com> Message-ID: <1379335881.5437.2.camel@freed> On Mon, 2013-09-16 at 09:31 +0200, Petr Spacek wrote: > You are right, the scenario described by me doesn't require views. > Please see > reply from James in another part of this thread - his setup has shared > host > name (internal = external) but different IP addresses for internal > and > external usage. > > The question is if DNS is the right layer to solve the problem. Yep. See below. > Some oddities > like this could be solved on IP routing level: I.e. use > 'external'/public IP > address everywhere and route packets with this 'external IP' to the > right part > of the internal network. > > Solution on routing layer can be technically feasible, but it doesn't > mean > that it is politically acceptable. People usually don't want to touch > routing > unless absolutely necessary :-) FWIW, I completely agree, although I do not having a problem with the routing solution, in certain setups it can add much more complexity which may not be required or even possible to do. Eg: conntrackd setups could get hairy or impossible. Let's do this in DNS. James PS: If anyone wants to meet to talk about this, I'm at Linuxcon New Orleans this week if I can be of any help. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From pviktori at redhat.com Mon Sep 16 13:04:02 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Sep 2013 15:04:02 +0200 Subject: [Freeipa-devel] [PATCHES] 0094-0099 Make Fuzzy objects available for the whole ipatests module In-Reply-To: <5236FB4A.2030903@redhat.com> References: <52331D35.7010900@redhat.com> <523335CF.8030000@redhat.com> <523345A7.1080303@redhat.com> <52335132.8020603@redhat.com> <5236FB4A.2030903@redhat.com> Message-ID: <523701C2.1050402@redhat.com> On 09/16/2013 02:36 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 09/13/2013 07:04 PM, Rob Crittenden wrote: [...] >>> Replacing it would either a) replicate its functionality almost >>> completely or b) spread duplicate regex code all over the place. >> >> I'd go for b; spreading this code: >> import re >> some_regex = re.compile('some.*regex$') >> ... >> assert some_regex.search(x) >> instead of: >> from wherever import Fuzzy >> warm_fuzzy = Fuzzy('some.*regex$') >> ... >> assert x == warm_fuzzy >> all over the place is fine in my book. And you can even, say, add custom >> flags to the regex without complicating shared code. > > Right, and it's all duplicate. Just look in his patch how many times > fuzzy.digits is used. What's going to happen is someone is going to come > along later and say "Geez, we have a ton of some_regex = > re.compile('\d+'), I should make a macro thinger out of this" and we're > back where we started. The first two lines only need to be there once, in the other files you can just import some_regex, the same way you can import the Fuzzy object. >> The rest of Fuzzy functionality consists of strict type checking (which >> isn't really necessary in integration tests), and the ability to call >> arbitrary callables (which is just the scope creep I was talking about). >> By the way, in current tests these features are hardly ever used in >> combination. > > Here we agree. I'd prefer to keep Fuzzy limited to just simple regex and > woudln't object to delegating the other enforcement to something else. The type checking is actually a big part of Fuzzy functionality, since in the API we want all non-binary strings to be unicode and not str. >>> That isn't to say that Fuzzy isn't being abused, but that is also the >>> responsibility of the reviewers to be strict about. >> >> Then perhaps I'm too strict, but I say that using it outside of the >> declarative tests is abuse. >> Especially if it takes six patches with hundreds of changed lines to >> repurpose Fuzzy for integration tests (but that's not part of "-1 to the >> idea"). > > That is hardly fair. The bulk of the patches just change imports. The patches make Fuzzy enforce basestring type by default, instead of unicode. But in the IPA API we normally want only unicode, so almost all *usages* of Fuzzy are then changed to enforce unicode. That is bad because IMO Fuzzy is specific to the declarative API tests and should have defaults made for them. > So to summarize, I think: > > - Fuzzy should remain as a regex should remain as a regex shortcut > - The non-regex features can be moved elsewhere > - I don't really have a handle on how he intended to use this for > integration testing, so I don't have an opinion here. But I'd expect > that most integration tests depend more on return values than comparing > against "known good". We're getting closer to an agreement :) - Fuzzy should remain as a regex should remain as a regex shortcut *for our declarative tests which need type-checking* - The non-regex *and non-typechecking* features can be moved elsewhere (they actually are: assert_deepequal allows plain callables, it's just a matter of using that in the tests and then removing the functionality from Fuzzy) - In integration testing, if we do need to check the output of commands, we don't really care about the bytes/unicode distinction, so the re module is enough. -- Petr? From simo at redhat.com Mon Sep 16 13:32:18 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 16 Sep 2013 09:32:18 -0400 Subject: [Freeipa-devel] DNS improvements: Should we add some sanity checking? In-Reply-To: <5236B725.7040705@redhat.com> References: <20130913070214.GU10627@redhat.com> <5232BEDC.5000000@redhat.com> <1379089071.2804.1987.camel@willson.li.ssimo.org> <5236ADDA.7000700@redhat.com> <5236B725.7040705@redhat.com> Message-ID: <1379338338.3902.33.camel@willson.li.ssimo.org> On Mon, 2013-09-16 at 09:45 +0200, Petr Spacek wrote: > On 16.9.2013 09:06, Martin Kosek wrote: > > On 09/13/2013 06:17 PM, Simo Sorce wrote: > >> On Fri, 2013-09-13 at 09:29 +0200, Petr Spacek wrote: > >>> Hello list, > >>> > >>> Jan Pazdziora proposed that 'ipa dns*' commands should > >>> do some sanity checking/waiting after the record is added to LDAP. > >>> > >>> I think that it could be valuable and I would like to get opinions from > >>> freeipa-devel list. > >>> > >>> > >>> === The problem === > >>> ipa dnsrecord-add and similar commands add the data to LDAP, but it doesn't > >>> mean that the data are *immediately* resolvable via DNS protocol. Note that > >>> data from LDAP are *asynchronously* read and processed by Named and the time > >>> when records are available is not predictable. > >>> > >>> A mismatch between LDAP can be caused by some connection problem between DNS > >>> and LDAP servers, LDAP or DNS server restart, or simply by a bug in DNS<->LDAP > >>> synchronization code. (This is becomming more and more important if we > >>> consider the whole DNSSEC effort and related re-factoring.) > >>> > >>> My experience is that users are very confused if the ipa dnsrecord-add command > >>> says 'record added' but it is still not available via DNS. It is really hard > >>> to debug when you see the problem first 10 times :-) > >>> > >>> > >>> === The proposal === > >>> 1. Let FreeIPA framework to change DNS data in LDAP as we do now. > >>> 2. After each change, do DNS queries for changed record and wait until the new > >>> data are available. > >>> > >>> IMHO it is very cheap operation (in usual cases 1 DNS packet back and forth) > >>> and it would save a lot of headaches to users and support. > >>> > >>> This will naturally catch the case where named crashes after the change etc. > >>> > >>> > >>> === Expected outcome === > >>> There will not be any failure like this: > >>> > >>> $ ipa-adtrust-install > >>> > >>> $ ipa dnszone-add $AD_DOMAIN --name-server=advm.$AD_DOMAIN > >>> --admin-email="hostmaster@$AD_DOMAIN.com" --force --forwarder=$AD_IP > >>> --forward-policy=only --ip-address=$AD_IP > >>> Zone name: dom123.example.com > >>> [...] > >>> > >>> $ ipa trust-add --type=ad DOM123.EXAMPLE.COM --admin Administrator --password > >>> Password for admin at DOM123.EXAMPLE.COM: > >>> ipa: ERROR: Cannot find specified domain or server name > >>> > >> > >> Would it make sense to change the code to use dynDNS update to add > >> records ? > >> > >> Wouldn't that force named to be in sync ? > >> > >> Simo. > > > > Switching from LDAP modify operation to dynDNS update seems as a too big change > > to me. If nothing else, it would not fly with our LDAP ACI/permission system > > and ability to delegate DNS read/write rights to somebody else. > > I can see pros and cons for both ways: > > LDAP: > + we have the code :-) > + ACI magic > - works only with bind-dyndb-ldap > - can get out of sync (bugs, timeouts etc.) > > Standard DNS updates: > + can work with any DNS server > + with AD integration, we could use existing AD DNS infrastructure: i.e. > manage DNS records for FreeIPA servers and host without deploying a new DNS > server and related 'politics' > + bind-dyndb-ldap is not necessary (ouh, my work is useless now :-)) > - we don't have the code in FreeIPA framework > - ACI magic is not available (in reality, it depends on the DNS server) > - reading of current state could be more complex for user interface (On the > other hand, current user interface doesn't show real state of thing because > LDAP != DNS.) > I forgot one thing that breaks, we cannot create new zones via dyndns, so we'd still have a mixed set. But I was thinking about your pros too, esp being able to use an AD DNS if necessary (evil but doable). I do not want to insist, because I also agree with Martin, but we should think about it. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbabej at redhat.com Mon Sep 16 13:45:52 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 16 Sep 2013 15:45:52 +0200 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests Message-ID: <52370B90.2030009@redhat.com> Hi, this set of patches extends ipatests module to support integration testing with Active Directory, as well as provides an basic (working without artificial sleeps!) trust test case. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0100-ipatests-Add-Active-Directory-support-to-configurati.patch Type: text/x-patch Size: 3966 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0101-ipatests-Extend-domain-object-with-ad-role-support-a.patch Type: text/x-patch Size: 3293 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0102-ipatests-Extend-IntegrationTest-with-multiple-AD-dom.patch Type: text/x-patch Size: 2699 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0103-ipatests-Add-WinHost-class.patch Type: text/x-patch Size: 2652 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0104-ipatests-Add-wait_assert-method-to-tasks-suite.patch Type: text/x-patch Size: 1881 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0105-ipatests-Add-AD-integration-related-tasks.patch Type: text/x-patch Size: 6859 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0106-ipatests-Add-AD-integration-test-case.patch Type: text/x-patch Size: 6855 bytes Desc: not available URL: From isaev at fintech.ru Mon Sep 16 14:46:49 2013 From: isaev at fintech.ru (=?koi8-r?B?6dPBxdcg98nUwczJyiDhzsHUz8zYxdfJ3g==?=) Date: Mon, 16 Sep 2013 14:46:49 +0000 Subject: [Freeipa-devel] Newcomer's question Message-ID: <69303615BE133645963548DD4A3BFCB3A1F5E3@E2K7.fintech.ru> Dear Free IPA developers, Our team is working on the project based on the RHEL Virtualization and RHEL IdM server. It's planned to run our software in enclosed internal enterprise network, and we would like to assign all the authentication and authorization tasks to the FreeIPA Python API. In fact we have already written this part of project on plain C; dialog with IdM server has been implemented over SSH interaction (libssh API + GNU flex). But some time ago we discovered FreeIPA API and since then we really want to migrate from C to Python. So the time has come, but the problem is our complete ignorance of the Python programming language. We faced a problem trying to modify the tutorial script free-ipa-3.3.1/doc/python-api.py: ldap2 was refused to import. Which module should be included in this case? We use RHEL 6.4 desktop, all the IPA packages has 3.0.0-25 version. #!/usr/bin/python # -*- coding: utf-8 -*- from ipalib import api, errors from ipalib import Command from ipalib import Object from ipalib import Str from ipalib import output from ipalib.plugins import baseldap #Load environment api.finalize() if api.env.in_server: api.Backend.ldap2.connect( ccache=api.Backend.krb.default_ccname() ) else: api.Backend.xmlclient.connect() #Execute command dn = api.Backend.ldap2.make_dn_from_attr(u'python_dev3', loginshell=u'/bin/sh', givenname=u'Python', sn=u'User', userpassword=u'redhat') try: api.Backend.user_add(dn) except errors.DuplicateEntry: print("Possibly duplicate...") else: print("User added...") Errors: ipa: INFO: trying https://ipa.dev.ru/ipa/xml Traceback (most recent call last): File "./test.py", line 22, in dn = api.Backend.ldap2.make_dn_from_attr(u'python_dev3', loginshell=u'/bin/sh', givenname=u'Python', sn=u'User', userpassword=u'redhat') AttributeError: 'NameSpace' object has no attribute 'ldap2' Thank you, ??????? ????? ???????-??????????? ?????? ?????????? ? ????????? ???? ??????????? ?????????????? ???????????? ??? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Sep 16 15:13:04 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Sep 2013 17:13:04 +0200 Subject: [Freeipa-devel] [PATCHES] 0276-0277 Break long doc strings for translations Message-ID: <52372000.3080804@redhat.com> Hello, The first patch allow concatenating LazyText objects using `+`. This means we can break up long docstrings into multiple parts. Translators can then work on each part separately, and the whole translation is not lost when a small part is changed or added. The second patch splits up the docstring for Host*. I chose Host because it was updated since last release, so translators would have to-retranslate the text. In the future, whenever a long docstring is changed it should be broken up like this. The patch also updates translations, and adds the broken-up texts for French and Ukraininan. You can test by viewing Host help in one of these languages -- only the new section should be untranslated. https://fedorahosted.org/freeipa/ticket/3587 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0276-Add-ConcatenatedLazyText-object.patch Type: text/x-patch Size: 5755 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0277-Break-long-doc-string-in-the-Host-plugin.patch Type: text/x-patch Size: 104772 bytes Desc: not available URL: From rcritten at redhat.com Mon Sep 16 15:18:32 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Sep 2013 11:18:32 -0400 Subject: [Freeipa-devel] Newcomer's question In-Reply-To: <69303615BE133645963548DD4A3BFCB3A1F5E3@E2K7.fintech.ru> References: <69303615BE133645963548DD4A3BFCB3A1F5E3@E2K7.fintech.ru> Message-ID: <52372148.2060000@redhat.com> ????? ??????? ??????????? wrote: > Dear Free IPA developers, > > Our team is working on the project based on the RHEL Virtualization and > RHEL IdM server. It?s planned to run our software in enclosed internal > enterprise network, and we would like to assign all the authentication > and authorization tasks to the FreeIPA Python API. In fact we have > already written this part of project on plain C; dialog with IdM server > has been implemented over SSH interaction (libssh API + GNU flex). But > some time ago we discovered FreeIPA API and since then we really want to > migrate from C to Python. > > So the time has come, but the problem is our complete ignorance of the > Python programming language. We faced a problem trying to modify the > tutorial script */free-ipa-3.3.1/doc/python-api.py: /*ldap2 was refused > to import. Which module should be included in this case? > > We use RHEL 6.4 desktop, all the IPA packages has 3.0.0-25 version. > > #!/usr/bin/python > > # -*- coding: utf-8 -*- > > from ipalib import api, errors > > from ipalib import Command > > from ipalib import Object > > from ipalib import Str > > from ipalib import output > > from ipalib.plugins import baseldap > > #Load environment > > api.finalize() > > if api.env.in_server: > > api.Backend.ldap2.connect( > > ccache=api.Backend.krb.default_ccname() > > ) > > else: > > api.Backend.xmlclient.connect() > > #Execute command > > dn = api.Backend.ldap2.make_dn_from_attr(u'python_dev3', > loginshell=u'/bin/sh', givenname=u'Python', sn=u'User', > userpassword=u'redhat') > > try: > > api.Backend.user_add(dn) > > excepterrors.DuplicateEntry: > > print("Possibly duplicate?") > > else: > > print("User added?") > > Errors: > > ipa: INFO: trying https://ipa.dev.ru/ipa/xml > > Traceback (most recent call last): > > File "./test.py", line 22, in > > dn = api.Backend.ldap2.make_dn_from_attr(u'python_dev3', > loginshell=u'/bin/sh', givenname=u'Python', sn=u'User', > userpassword=u'redhat') > > AttributeError: 'NameSpace' object has no attribute 'ldap2' Try this: from ipalib import api from ipalib import errors api.bootstrap(context='cli') api.finalize() api.Backend.xmlclient.connect() try: api.Command['user_add'](u'testuser', givenname=u'Test', sn=u'User', loginshell=u'/bin/sh') except errors.DuplicateEntry: print "user already exists" else: print "User added" From akrivoka at redhat.com Mon Sep 16 15:24:19 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 16 Sep 2013 17:24:19 +0200 Subject: [Freeipa-devel] [PATCH] 451-458 Web UI devel and source code documentation In-Reply-To: <523049A5.10208@redhat.com> References: <523049A5.10208@redhat.com> Message-ID: <523722A3.7060700@redhat.com> On 09/11/2013 12:44 PM, Petr Vobornik wrote: > Hello, > > This is a part of documentation effort which started couple month ago. > Attached patches improves devel documentation of Web UI. Mostly by annotating > source code and then processing it by JSDuck tool[1]. > > The documentation is not complete - most plugins and member of some core > widgets and facets are not annotated yet. I'm sending it now because I need to > focus on more pressing tickets. > > You can see current state at my fedorapeople page [2]. > > I also converted 5 guides/articles which I wrote some time ago. Guides are > also part of the JSDuck app [3]. > > The idea is to regularly generate the doc and place it on docs.freeipa.org > (not in production at the moment) so all doc would be on one place. > > Installation of JSDuck is documented on their page [4]. Basically it requires > ruby and JSDuck gem. > > Usage: > $ cd install/ui/doc > $ make > > Documentation is generated into: install/ui/build/code_doc directory > > [1] https://github.com/senchalabs/jsduck > [2] http://pvoborni.fedorapeople.org/doc > [3] http://pvoborni.fedorapeople.org/doc/#!/guide > [4] https://github.com/senchalabs/jsduck/wiki/Installation > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I looked into the documentation effort and (ruby dependency discussion aside) I don't have any major objections. I like how the generated pages look, and they are intuitive and easy to navigate. A couple of nitpicks: 1) There are some spelling mistakes (e.g. Apllication_controller) 2) Bulleted lists are not rendered nicely in the html output (see for example the doc string for _base.Builder property 'string_mode'. I think a list needs to look like this in the source code: /** * This is a list: * * - 'element1' * - 'element2' * */ as opposed to this: /** * This is a list: * - 'element1' * - 'element2' */ -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Sep 16 15:38:34 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 16 Sep 2013 17:38:34 +0200 Subject: [Freeipa-devel] =?iso-8859-1?q?=5BPATCH=5D=A0Debian_client_suppor?= =?iso-8859-1?q?t?= In-Reply-To: <5225A517.80302@redhat.com> References: <5225066B.3010003@ubuntu.com> <5225A517.80302@redhat.com> Message-ID: <523725FA.6000407@redhat.com> On 09/03/2013 11:00 AM, Petr Viktorin wrote: > On 09/02/2013 11:43 PM, Timo Aaltonen wrote: >> >> This fixes https://fedorahosted.org/freeipa/ticket/1887 >> and >> https://fedorahosted.org/freeipa/ticket/2455 > > Thank you! > >> the first three patches fix some bugs in how python is used > > These look okay, I'll check when other build errors are fixed. > [...] > >> fifth fixes some compilation warnings > > Looks good to my eyes, perhaps a C expert can look at this one too. > I wonder why these warnings aren't enabled in our builds, though. > I've built and checked patches 1, 2, 3, 5 now, and found no regressions. I've asked Rob about why IPA explicitly disallowed to load plugins from symlinks. That code's author is not around anymore. The reason seems to be vague concerns about security, but I think we have better things to worry about than admins (or distros) that symlink from /usr/lib/** to untrusted places. (For the record: AFAIK, Debian uses symlinks for all Python modules, so distro-installed plugins will be symlinks.) ACK to those 4 patches, pushed to master: 8c03b1dbcdf75ba76b96ccfcc148afe0e134e2d3 -- Petr? From hotz at jpl.nasa.gov Mon Sep 16 22:04:23 2013 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Mon, 16 Sep 2013 15:04:23 -0700 Subject: [Freeipa-devel] Off Topic, was: [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <1379179533.2804.2008.camel@willson.li.ssimo.org> References: <1378355153.19352.29.camel@localhost> <5231A566.30904@redhat.com> <523212EF.7030302@redhat.com> <52333B14.7030403@redhat.com> <52335BAC.3020100@redhat.com> <1379179533.2804.2008.camel@willson.li.ssimo.org> Message-ID: <4F1B69B6-1E27-4AC6-818F-D4FA36948674@jpl.nasa.gov> On Sep 14, 2013, at 10:25 AM, Simo Sorce wrote: > On Fri, 2013-09-13 at 15:06 -0700, Henry B. Hotz wrote: >> On Sep 13, 2013, at 11:38 AM, Dmitri Pal wrote: >> >>>> , ipatokenotpalgorithm >>> >>> Uses default TOTP we do not support more for now. In future it will be a >>> global policy I assume. >> >> This is just me, like the sig says. >> >> I would advocate for HOTP, with a bunch of special processing for >> token counter regression. >> >> If the token seed and current counter are stolen by a bad guy, and >> actually used, then at some point the bad guy or the real user are >> going to attempt an authentication using a value that's "old". This >> presents an opportunity to detect that the theft took place. >> >> I regard this as a real, useful security feature which is not possible >> with time-based tokens, provided the verification infrastructure is >> set up to do the detection, and to take some action when the detection >> occurs. If the theft is done by a smart-enough adversary, there may >> be nothing to prevent them from resynchronizing the legitimate copy of >> the soft-token when they use it, but it still seems like a worthwhile >> capability. It would detect the most obvious token-theft scenarios. >> >> Obviously, this is out-of-scope for any of your current efforts, but I >> wanted to throw it in the mix for possible future work. > > Henry, > Thanks a lot for bringing this up. > > I have to say that I never liked HOTP due to the burden it takes to > correctly manage them compared to TOTP and the hardest work around > synchronization. The worst part of it being the need to write AND > synchronize across the infrastructure at every authentication attempt > (replication). Something that could easily bring the whole > infrastructure to its knees at busy hours. I won't pretend that's not a big issue. However if you want to prevent re-use of time-based tokens, then you have the same problem. RSA allows you to prevent re-use. However I've been told it doesn't scale well, performance wise. In particular you can't distinguish an automatic retry (like kinit would do after 1 second), from a hostile re-use (steal token in transit and use it yourself before it expires). I've also been told by people who did it that if you wanted to actually deploy the old SAM protocol you realistically had to configure RSA to allow re-use. Otherwise the client might retry before the first response arrived, and all subsequent responses would be failures. Substituting FAST/OTP for SAM doesn't change anything in the back-end exchange and performance. Someone commented that using TCP instead of UDP was useful for exactly those reasons, and that wasn't available back then. > However HOTP has obvious advantages when it comes to identifying attack > attempts, so I'll start thinking hard how to deal with it wrt > performance. > > Simo. There seems to be some interest in dealing with it in Heimdal. I'd like to build the OTP service directly into the kdc so you can use {H,T}OTP directly with the old timestamp or FAST/encrypted challenge, but I seem to be a serious minority on this point. If you export the OTP processing, then you export the performance/synchronization issues. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu From hotz at jpl.nasa.gov Mon Sep 16 22:10:05 2013 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Mon, 16 Sep 2013 15:10:05 -0700 Subject: [Freeipa-devel] Off Topic, was: [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <5235F9C0.4020309@redhat.com> References: <1378355153.19352.29.camel@localhost> <5231A566.30904@redhat.com> <523212EF.7030302@redhat.com> <52333B14.7030403@redhat.com> <52335BAC.3020100@redhat.com> <5235F9C0.4020309@redhat.com> Message-ID: <3B8AF396-C9A8-43A2-BABE-A50B9EBA9EAC@jpl.nasa.gov> On Sep 15, 2013, at 11:17 AM, Dmitri Pal wrote: > On 09/13/2013 06:06 PM, Henry B. Hotz wrote: >> On Sep 13, 2013, at 11:38 AM, Dmitri Pal wrote: >> >>>> , ipatokenotpalgorithm >>> Uses default TOTP we do not support more for now. In future it will be a >>> global policy I assume. >> This is just me, like the sig says. >> >> I would advocate for HOTP, with a bunch of special processing for token counter regression. >> >> If the token seed and current counter are stolen by a bad guy, and actually used, then at some point the bad guy or the real user are going to attempt an authentication using a value that's "old". This presents an opportunity to detect that the theft took place. >> >> I regard this as a real, useful security feature which is not possible with time-based tokens, provided the verification infrastructure is set up to do the detection, and to take some action when the detection occurs. If the theft is done by a smart-enough adversary, there may be nothing to prevent them from resynchronizing the legitimate copy of the soft-token when they use it, but it still seems like a worthwhile capability. It would detect the most obvious token-theft scenarios. >> >> Obviously, this is out-of-scope for any of your current efforts, but I wanted to throw it in the mix for possible future work. > > Count creates an overhead in the replicated environment. Effectively you > need to replicate count on every authentication, this is a big cost. > While it is more secure for the case you suggest it does not seem to be > a good enough justification for the replication overhead. If stolen the > chance that it will be used some tine later is really slim. It most > likely will be used right away so the old code detection will be > irrelevant. But we anticipate that there will be cases when HOTP will be > needed, so we do not preclude implementing it in future but on the other > hand do not see it as an immediate goal either. If the bad guy uses the stolen seed immediately, yes it works. However it advances the service's counter so the legitimate user will trip the monitor whenever he/she next uses the token. In other words the monitor will tell you of a problem, but it won't tell you if the user that demonstrated the problem was the good guy or the bad guy. It also won't help if the good guy never uses the token at all after the theft. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu From dpal at redhat.com Tue Sep 17 02:34:23 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 16 Sep 2013 22:34:23 -0400 Subject: [Freeipa-devel] DNS improvements: Should we add some sanity checking? In-Reply-To: <1379338338.3902.33.camel@willson.li.ssimo.org> References: <20130913070214.GU10627@redhat.com> <5232BEDC.5000000@redhat.com> <1379089071.2804.1987.camel@willson.li.ssimo.org> <5236ADDA.7000700@redhat.com> <5236B725.7040705@redhat.com> <1379338338.3902.33.camel@willson.li.ssimo.org> Message-ID: <5237BFAF.1070704@redhat.com> On 09/16/2013 09:32 AM, Simo Sorce wrote: > On Mon, 2013-09-16 at 09:45 +0200, Petr Spacek wrote: >> On 16.9.2013 09:06, Martin Kosek wrote: >>> On 09/13/2013 06:17 PM, Simo Sorce wrote: >>>> On Fri, 2013-09-13 at 09:29 +0200, Petr Spacek wrote: >>>>> Hello list, >>>>> >>>>> Jan Pazdziora proposed that 'ipa dns*' commands should >>>>> do some sanity checking/waiting after the record is added to LDAP. >>>>> >>>>> I think that it could be valuable and I would like to get opinions from >>>>> freeipa-devel list. >>>>> >>>>> >>>>> === The problem === >>>>> ipa dnsrecord-add and similar commands add the data to LDAP, but it doesn't >>>>> mean that the data are *immediately* resolvable via DNS protocol. Note that >>>>> data from LDAP are *asynchronously* read and processed by Named and the time >>>>> when records are available is not predictable. >>>>> >>>>> A mismatch between LDAP can be caused by some connection problem between DNS >>>>> and LDAP servers, LDAP or DNS server restart, or simply by a bug in DNS<->LDAP >>>>> synchronization code. (This is becomming more and more important if we >>>>> consider the whole DNSSEC effort and related re-factoring.) >>>>> >>>>> My experience is that users are very confused if the ipa dnsrecord-add command >>>>> says 'record added' but it is still not available via DNS. It is really hard >>>>> to debug when you see the problem first 10 times :-) >>>>> >>>>> >>>>> === The proposal === >>>>> 1. Let FreeIPA framework to change DNS data in LDAP as we do now. >>>>> 2. After each change, do DNS queries for changed record and wait until the new >>>>> data are available. >>>>> >>>>> IMHO it is very cheap operation (in usual cases 1 DNS packet back and forth) >>>>> and it would save a lot of headaches to users and support. >>>>> >>>>> This will naturally catch the case where named crashes after the change etc. >>>>> >>>>> >>>>> === Expected outcome === >>>>> There will not be any failure like this: >>>>> >>>>> $ ipa-adtrust-install >>>>> >>>>> $ ipa dnszone-add $AD_DOMAIN --name-server=advm.$AD_DOMAIN >>>>> --admin-email="hostmaster@$AD_DOMAIN.com" --force --forwarder=$AD_IP >>>>> --forward-policy=only --ip-address=$AD_IP >>>>> Zone name: dom123.example.com >>>>> [...] >>>>> >>>>> $ ipa trust-add --type=ad DOM123.EXAMPLE.COM --admin Administrator --password >>>>> Password for admin at DOM123.EXAMPLE.COM: >>>>> ipa: ERROR: Cannot find specified domain or server name >>>>> >>>> Would it make sense to change the code to use dynDNS update to add >>>> records ? >>>> >>>> Wouldn't that force named to be in sync ? >>>> >>>> Simo. >>> Switching from LDAP modify operation to dynDNS update seems as a too big change >>> to me. If nothing else, it would not fly with our LDAP ACI/permission system >>> and ability to delegate DNS read/write rights to somebody else. >> I can see pros and cons for both ways: >> >> LDAP: >> + we have the code :-) >> + ACI magic >> - works only with bind-dyndb-ldap >> - can get out of sync (bugs, timeouts etc.) >> >> Standard DNS updates: >> + can work with any DNS server >> + with AD integration, we could use existing AD DNS infrastructure: i.e. >> manage DNS records for FreeIPA servers and host without deploying a new DNS >> server and related 'politics' >> + bind-dyndb-ldap is not necessary (ouh, my work is useless now :-)) >> - we don't have the code in FreeIPA framework >> - ACI magic is not available (in reality, it depends on the DNS server) >> - reading of current state could be more complex for user interface (On the >> other hand, current user interface doesn't show real state of thing because >> LDAP != DNS.) >> > I forgot one thing that breaks, we cannot create new zones via dyndns, > so we'd still have a mixed set. But I was thinking about your pros too, > esp being able to use an AD DNS if necessary (evil but doable). > > I do not want to insist, because I also agree with Martin, but we should > think about it. ... and not rush > > Simo. > -- 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 Tue Sep 17 02:44:06 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 16 Sep 2013 22:44:06 -0400 Subject: [Freeipa-devel] Off Topic, was: [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <4F1B69B6-1E27-4AC6-818F-D4FA36948674@jpl.nasa.gov> References: <1378355153.19352.29.camel@localhost> <5231A566.30904@redhat.com> <523212EF.7030302@redhat.com> <52333B14.7030403@redhat.com> <52335BAC.3020100@redhat.com> <1379179533.2804.2008.camel@willson.li.ssimo.org> <4F1B69B6-1E27-4AC6-818F-D4FA36948674@jpl.nasa.gov> Message-ID: <5237C1F6.4010702@redhat.com> On 09/16/2013 06:04 PM, Henry B. Hotz wrote: > On Sep 14, 2013, at 10:25 AM, Simo Sorce wrote: > >> On Fri, 2013-09-13 at 15:06 -0700, Henry B. Hotz wrote: >>> On Sep 13, 2013, at 11:38 AM, Dmitri Pal wrote: >>> >>>>> , ipatokenotpalgorithm >>>> Uses default TOTP we do not support more for now. In future it will be a >>>> global policy I assume. >>> This is just me, like the sig says. >>> >>> I would advocate for HOTP, with a bunch of special processing for >>> token counter regression. >>> >>> If the token seed and current counter are stolen by a bad guy, and >>> actually used, then at some point the bad guy or the real user are >>> going to attempt an authentication using a value that's "old". This >>> presents an opportunity to detect that the theft took place. >>> >>> I regard this as a real, useful security feature which is not possible >>> with time-based tokens, provided the verification infrastructure is >>> set up to do the detection, and to take some action when the detection >>> occurs. If the theft is done by a smart-enough adversary, there may >>> be nothing to prevent them from resynchronizing the legitimate copy of >>> the soft-token when they use it, but it still seems like a worthwhile >>> capability. It would detect the most obvious token-theft scenarios. >>> >>> Obviously, this is out-of-scope for any of your current efforts, but I >>> wanted to throw it in the mix for possible future work. >> Henry, >> Thanks a lot for bringing this up. >> >> I have to say that I never liked HOTP due to the burden it takes to >> correctly manage them compared to TOTP and the hardest work around >> synchronization. The worst part of it being the need to write AND >> synchronize across the infrastructure at every authentication attempt >> (replication). Something that could easily bring the whole >> infrastructure to its knees at busy hours. > I won't pretend that's not a big issue. However if you want to prevent re-use of time-based tokens, then you have the same problem. > > RSA allows you to prevent re-use. RSA used Lock Manager (6.x) or Adjudicator (7.x). The idea is the same: fast replication of the interval that the code corresponds to. Other replicas have to check before trying to lock the same interval. It scales more or less but very complex. > However I've been told it doesn't scale well, performance wise. In particular you can't distinguish an automatic retry (like kinit would do after 1 second), from a hostile re-use (steal token in transit and use it yourself before it expires). We changed the kerberos client library to have longer retries. > > I've also been told by people who did it that if you wanted to actually deploy the old SAM protocol you realistically had to configure RSA to allow re-use. Otherwise the client might retry before the first response arrived, and all subsequent responses would be failures. Yes so we fixed the kerberos client to not retry that quickly in TCP case. This patch was submitted last spring. > Substituting FAST/OTP for SAM doesn't change anything in the back-end exchange and performance. I do not remember the details of the patch described above, i.e. was it generic or for OTP case only. > Someone commented that using TCP instead of UDP was useful for exactly those reasons, and that wasn't available back then. Now it is. > >> However HOTP has obvious advantages when it comes to identifying attack >> attempts, so I'll start thinking hard how to deal with it wrt >> performance. >> >> Simo. > > There seems to be some interest in dealing with it in Heimdal. I'd like to build the OTP service directly into the kdc so you can use {H,T}OTP directly with the old timestamp or FAST/encrypted challenge, but I seem to be a serious minority on this point. > > If you export the OTP processing, then you export the performance/synchronization issues. > ------------------------------------------------------ > The opinions expressed in this message are mine, > not those of Caltech, JPL, NASA, or the US Government. > Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From isaev at fintech.ru Tue Sep 17 08:19:01 2013 From: isaev at fintech.ru (=?utf-8?B?0JjRgdCw0LXQsiDQktC40YLQsNC70LjQuSDQkNC90LDRgtC+0LvRjNC10LI=?= =?utf-8?B?0LjRhw==?=) Date: Tue, 17 Sep 2013 08:19:01 +0000 Subject: [Freeipa-devel] Newcomer's question In-Reply-To: <52372148.2060000@redhat.com> References: <69303615BE133645963548DD4A3BFCB3A1F5E3@E2K7.fintech.ru> <52372148.2060000@redhat.com> Message-ID: <69303615BE133645963548DD4A3BFCB3A1F636@E2K7.fintech.ru> Thanks, it has worked! Could you please explain what is the most convenient way to construct complex argument variables like this: (u'testuser', givenname=u'Test', sn=u'User', loginshell=u'/bin/sh') to pass them to commands with a variable number of args, such as 'user-add', 'group-add', 'config-mod' etc? Thank you, ??????? ????? ???????-??????????? ?????? ?????????? ? ????????? ???? ??????????? ?????????????? ???????????? ??? ???????? -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Monday, September 16, 2013 7:19 PM To: ????? ??????? ???????????; freeipa-devel at redhat.com Subject: Re: [Freeipa-devel] Newcomer's question ????? ??????? ??????????? wrote: > Dear Free IPA developers, > > Our team is working on the project based on the RHEL Virtualization > and RHEL IdM server. It?s planned to run our software in enclosed > internal enterprise network, and we would like to assign all the > authentication and authorization tasks to the FreeIPA Python API. In > fact we have already written this part of project on plain C; dialog > with IdM server has been implemented over SSH interaction (libssh API > + GNU flex). But some time ago we discovered FreeIPA API and since > then we really want to migrate from C to Python. > > So the time has come, but the problem is our complete ignorance of the > Python programming language. We faced a problem trying to modify the > tutorial script */free-ipa-3.3.1/doc/python-api.py: /*ldap2 was > refused to import. Which module should be included in this case? > > We use RHEL 6.4 desktop, all the IPA packages has 3.0.0-25 version. > > #!/usr/bin/python > > # -*- coding: utf-8 -*- > > from ipalib import api, errors > > from ipalib import Command > > from ipalib import Object > > from ipalib import Str > > from ipalib import output > > from ipalib.plugins import baseldap > > #Load environment > > api.finalize() > > if api.env.in_server: > > api.Backend.ldap2.connect( > > ccache=api.Backend.krb.default_ccname() > > ) > > else: > > api.Backend.xmlclient.connect() > > #Execute command > > dn = api.Backend.ldap2.make_dn_from_attr(u'python_dev3', > loginshell=u'/bin/sh', givenname=u'Python', sn=u'User', > userpassword=u'redhat') > > try: > > api.Backend.user_add(dn) > > excepterrors.DuplicateEntry: > > print("Possibly duplicate?") > > else: > > print("User added?") > > Errors: > > ipa: INFO: trying https://ipa.dev.ru/ipa/xml > > Traceback (most recent call last): > > File "./test.py", line 22, in > > dn = api.Backend.ldap2.make_dn_from_attr(u'python_dev3', > loginshell=u'/bin/sh', givenname=u'Python', sn=u'User', > userpassword=u'redhat') > > AttributeError: 'NameSpace' object has no attribute 'ldap2' Try this: from ipalib import api from ipalib import errors api.bootstrap(context='cli') api.finalize() api.Backend.xmlclient.connect() try: api.Command['user_add'](u'testuser', givenname=u'Test', sn=u'User', loginshell=u'/bin/sh') except errors.DuplicateEntry: print "user already exists" else: print "User added" From pviktori at redhat.com Tue Sep 17 08:43:17 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 17 Sep 2013 10:43:17 +0200 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests In-Reply-To: <52370B90.2030009@redhat.com> References: <52370B90.2030009@redhat.com> Message-ID: <52381625.3010607@redhat.com> On 09/16/2013 03:45 PM, Tomas Babej wrote: > Hi, > > this set of patches extends ipatests module to support integration > testing with Active Directory, > as well as provides an basic (working without artificial sleeps!) trust > test case. Thanks, this is great news! I haven't testes the test yet. Here are my comments from reading them. Patch 100: Please document the new configuration options. There are two places: - ipa-test-config man page - http://www.freeipa.org/page/V3/Integration_testing#Test_configuration (or if you end up writing a separate design page for AD tests, link to it) Patch 101: The `if role == 'ad':` block should rather be in the `Host.from_env` factory. Patch 102: Thanks for cleaning that up! You could go one step further with cls.replicas = get_resources(domain.replicas, 'replicas', cls.num_replicas) and `return container[:num_needed]` there Patch 103: This patch should come before 101 which uses it. Ideally there would be a BaseHost with common functionality, and concrete Host and WinHost subclassing it. I'll be making changes here for #3890; please concentrate on other parts for now to avoid conflicts. I'll take Windows hosts into consideration. Raise instances rather than the exception classes: raise NotImplementedError() Patch 104: Instead of stdout_re, allow the user to pass in a checking function. For example, `lambda result: re.search(sid_regex, result.stdout_text)` This makes wait_assert complete, you won't need to add other cases to it when you need to check stderr or evaluate some condition a regex is too weak for. Pass `raiseonerr` to run_command directly, not by setting it in kwargs. That way wait_assert will fail if it gets raiseonerr. Also, run_command's arguments except `command` are supposed to be keyword-only. (This is only not enforced because that's awkward to do in Python 2.) Don't accept or pass along *args. Use parentheses instead of \ for line continuation (see PEP8). I'd prefer to keep the function in test_trust.py until we see there's a wider scope for it. And rename it to run_repeatedly or some other name that describes it better. Patch 105: Please add these tasks to ipa-test-task (and its man page) as well. The instructions in the docstring in configure_dns_for_trust should go to a test design document. I think just starting a section in Integration_testing would be fine if you mark it as not implemented yet (and link to the ticket). Use parentheses instead of \ for line continuation (see PEP8). Patch 106: The instructions in the TestADTrust docstring should go to a test design document. Please use the SID regex from a shared location. You'll need to assign it to a variable and make the Fuzzy from that, so that variable can be imported and used with the standard re module. Avoid commented-out code in patches for review. No need to import fuzzy. test_user_gid_uid_resolution_in_nonposix_trust: - For a one-off regex, compile() is unnecessary: assert re.search(testuser_regex, result.stdout_text) - Whenever substituting a literal string into a regex, please use re.escape(). Use parentheses instead of \ for line continuation (see PEP8). -- Petr? From mkosek at redhat.com Tue Sep 17 09:03:19 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 17 Sep 2013 11:03:19 +0200 Subject: [Freeipa-devel] Newcomer's question In-Reply-To: <69303615BE133645963548DD4A3BFCB3A1F636@E2K7.fintech.ru> References: <69303615BE133645963548DD4A3BFCB3A1F5E3@E2K7.fintech.ru> <52372148.2060000@redhat.com> <69303615BE133645963548DD4A3BFCB3A1F636@E2K7.fintech.ru> Message-ID: <52381AD7.3020809@redhat.com> I would use Python dictionaries for that. user_kw = dict(givenname=u'Test', sn=u'User') user_kw['loginshell'] = u'/bin/sh' api.Command['user_add'](u'testuser', **user_kw) HTH, Martin On 09/17/2013 10:19 AM, ????? ??????? ??????????? wrote: > Thanks, it has worked! Could you please explain what is the most convenient way to construct complex argument variables like this: (u'testuser', givenname=u'Test', sn=u'User', loginshell=u'/bin/sh') to pass them to commands with a variable number of args, such as 'user-add', 'group-add', 'config-mod' etc? > > Thank you, > ??????? ????? > ???????-??????????? > ?????? ?????????? ? ????????? ???? > ??????????? ?????????????? ???????????? > ??? ???????? > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Monday, September 16, 2013 7:19 PM > To: ????? ??????? ???????????; freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] Newcomer's question > > ????? ??????? ??????????? wrote: >> Dear Free IPA developers, >> >> Our team is working on the project based on the RHEL Virtualization >> and RHEL IdM server. It?s planned to run our software in enclosed >> internal enterprise network, and we would like to assign all the >> authentication and authorization tasks to the FreeIPA Python API. In >> fact we have already written this part of project on plain C; dialog >> with IdM server has been implemented over SSH interaction (libssh API >> + GNU flex). But some time ago we discovered FreeIPA API and since >> then we really want to migrate from C to Python. >> >> So the time has come, but the problem is our complete ignorance of the >> Python programming language. We faced a problem trying to modify the >> tutorial script */free-ipa-3.3.1/doc/python-api.py: /*ldap2 was >> refused to import. Which module should be included in this case? >> >> We use RHEL 6.4 desktop, all the IPA packages has 3.0.0-25 version. >> >> #!/usr/bin/python >> >> # -*- coding: utf-8 -*- >> >> from ipalib import api, errors >> >> from ipalib import Command >> >> from ipalib import Object >> >> from ipalib import Str >> >> from ipalib import output >> >> from ipalib.plugins import baseldap >> >> #Load environment >> >> api.finalize() >> >> if api.env.in_server: >> >> api.Backend.ldap2.connect( >> >> ccache=api.Backend.krb.default_ccname() >> >> ) >> >> else: >> >> api.Backend.xmlclient.connect() >> >> #Execute command >> >> dn = api.Backend.ldap2.make_dn_from_attr(u'python_dev3', >> loginshell=u'/bin/sh', givenname=u'Python', sn=u'User', >> userpassword=u'redhat') >> >> try: >> >> api.Backend.user_add(dn) >> >> excepterrors.DuplicateEntry: >> >> print("Possibly duplicate?") >> >> else: >> >> print("User added?") >> >> Errors: >> >> ipa: INFO: trying https://ipa.dev.ru/ipa/xml >> >> Traceback (most recent call last): >> >> File "./test.py", line 22, in >> >> dn = api.Backend.ldap2.make_dn_from_attr(u'python_dev3', >> loginshell=u'/bin/sh', givenname=u'Python', sn=u'User', >> userpassword=u'redhat') >> >> AttributeError: 'NameSpace' object has no attribute 'ldap2' > > Try this: > > from ipalib import api > from ipalib import errors > > api.bootstrap(context='cli') > api.finalize() > api.Backend.xmlclient.connect() > > try: > api.Command['user_add'](u'testuser', > givenname=u'Test', sn=u'User', > loginshell=u'/bin/sh') except errors.DuplicateEntry: > print "user already exists" > else: > print "User added" > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > From dpal at redhat.com Tue Sep 17 14:06:09 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 17 Sep 2013 10:06:09 -0400 Subject: [Freeipa-devel] Newcomer's question In-Reply-To: <52381AD7.3020809@redhat.com> References: <69303615BE133645963548DD4A3BFCB3A1F5E3@E2K7.fintech.ru> <52372148.2060000@redhat.com> <69303615BE133645963548DD4A3BFCB3A1F636@E2K7.fintech.ru> <52381AD7.3020809@redhat.com> Message-ID: <523861D1.9050604@redhat.com> On 09/17/2013 05:03 AM, Martin Kosek wrote: > I would use Python dictionaries for that. > > user_kw = dict(givenname=u'Test', sn=u'User') > user_kw['loginshell'] = u'/bin/sh' > > api.Command['user_add'](u'testuser', **user_kw) Can we put this somewhere on the wiki close to the API guide? I suspect this would help others too. I mean your comment and Rob's. > > HTH, > Martin > > On 09/17/2013 10:19 AM, ????? ??????? ??????????? wrote: >> Thanks, it has worked! Could you please explain what is the most convenient way to construct complex argument variables like this: (u'testuser', givenname=u'Test', sn=u'User', loginshell=u'/bin/sh') to pass them to commands with a variable number of args, such as 'user-add', 'group-add', 'config-mod' etc? >> >> Thank you, >> ??????? ????? >> ???????-??????????? >> ?????? ?????????? ? ????????? ???? >> ??????????? ?????????????? ???????????? >> ??? ???????? >> >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Monday, September 16, 2013 7:19 PM >> To: ????? ??????? ???????????; freeipa-devel at redhat.com >> Subject: Re: [Freeipa-devel] Newcomer's question >> >> ????? ??????? ??????????? wrote: >>> Dear Free IPA developers, >>> >>> Our team is working on the project based on the RHEL Virtualization >>> and RHEL IdM server. It?s planned to run our software in enclosed >>> internal enterprise network, and we would like to assign all the >>> authentication and authorization tasks to the FreeIPA Python API. In >>> fact we have already written this part of project on plain C; dialog >>> with IdM server has been implemented over SSH interaction (libssh API >>> + GNU flex). But some time ago we discovered FreeIPA API and since >>> then we really want to migrate from C to Python. >>> >>> So the time has come, but the problem is our complete ignorance of the >>> Python programming language. We faced a problem trying to modify the >>> tutorial script */free-ipa-3.3.1/doc/python-api.py: /*ldap2 was >>> refused to import. Which module should be included in this case? >>> >>> We use RHEL 6.4 desktop, all the IPA packages has 3.0.0-25 version. >>> >>> #!/usr/bin/python >>> >>> # -*- coding: utf-8 -*- >>> >>> from ipalib import api, errors >>> >>> from ipalib import Command >>> >>> from ipalib import Object >>> >>> from ipalib import Str >>> >>> from ipalib import output >>> >>> from ipalib.plugins import baseldap >>> >>> #Load environment >>> >>> api.finalize() >>> >>> if api.env.in_server: >>> >>> api.Backend.ldap2.connect( >>> >>> ccache=api.Backend.krb.default_ccname() >>> >>> ) >>> >>> else: >>> >>> api.Backend.xmlclient.connect() >>> >>> #Execute command >>> >>> dn = api.Backend.ldap2.make_dn_from_attr(u'python_dev3', >>> loginshell=u'/bin/sh', givenname=u'Python', sn=u'User', >>> userpassword=u'redhat') >>> >>> try: >>> >>> api.Backend.user_add(dn) >>> >>> excepterrors.DuplicateEntry: >>> >>> print("Possibly duplicate?") >>> >>> else: >>> >>> print("User added?") >>> >>> Errors: >>> >>> ipa: INFO: trying https://ipa.dev.ru/ipa/xml >>> >>> Traceback (most recent call last): >>> >>> File "./test.py", line 22, in >>> >>> dn = api.Backend.ldap2.make_dn_from_attr(u'python_dev3', >>> loginshell=u'/bin/sh', givenname=u'Python', sn=u'User', >>> userpassword=u'redhat') >>> >>> AttributeError: 'NameSpace' object has no attribute 'ldap2' >> Try this: >> >> from ipalib import api >> from ipalib import errors >> >> api.bootstrap(context='cli') >> api.finalize() >> api.Backend.xmlclient.connect() >> >> try: >> api.Command['user_add'](u'testuser', >> givenname=u'Test', sn=u'User', >> loginshell=u'/bin/sh') except errors.DuplicateEntry: >> print "user already exists" >> else: >> print "User added" >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From tbabej at redhat.com Tue Sep 17 14:35:02 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 17 Sep 2013 16:35:02 +0200 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests In-Reply-To: <52381625.3010607@redhat.com> References: <52370B90.2030009@redhat.com> <52381625.3010607@redhat.com> Message-ID: <52386896.3000909@redhat.com> On 09/17/2013 10:43 AM, Petr Viktorin wrote: > On 09/16/2013 03:45 PM, Tomas Babej wrote: >> Hi, >> >> this set of patches extends ipatests module to support integration >> testing with Active Directory, >> as well as provides an basic (working without artificial sleeps!) trust >> test case. > > Thanks, this is great news! > I haven't testes the test yet. Here are my comments from reading them. > > > Patch 100: > Please document the new configuration options. There are two places: > - ipa-test-config man page > - > http://www.freeipa.org/page/V3/Integration_testing#Test_configuration > (or if you end up writing a separate design page for AD tests, link to > it) > I added the options to the the man page. > > Patch 101: > The `if role == 'ad':` block should rather be in the `Host.from_env` > factory. > Moved. > > Patch 102: > Thanks for cleaning that up! > You could go one step further with > cls.replicas = get_resources(domain.replicas, 'replicas', > cls.num_replicas) > and `return container[:num_needed]` there You're welcome, refactoring part expanded. > > > Patch 103: > This patch should come before 101 which uses it. > We can push this in the correct order if this is an issue, right? Patches are independent (meaning they do not touch the same source code, so they should apply cleanly). > Ideally there would be a BaseHost with common functionality, and > concrete Host and WinHost subclassing it. Yes, I agree, that's what we discussed. > I'll be making changes here for #3890; please concentrate on other > parts for now to avoid conflicts. I'll take Windows hosts into > consideration. > > Raise instances rather than the exception classes: raise > NotImplementedError() Fixed. > > > Patch 104: > Instead of stdout_re, allow the user to pass in a checking function. > For example, `lambda result: re.search(sid_regex, result.stdout_text)` > This makes wait_assert complete, you won't need to add other cases to > it when you need to check stderr or evaluate some condition a regex is > too weak for. +1, improved. > > Pass `raiseonerr` to run_command directly, not by setting it in > kwargs. That way wait_assert will fail if it gets raiseonerr. > Also, run_command's arguments except `command` are supposed to be > keyword-only. (This is only not enforced because that's awkward to do > in Python 2.) Don't accept or pass along *args. > Agreed, fixed. > Use parentheses instead of \ for line continuation (see PEP8). > > I'd prefer to keep the function in test_trust.py until we see there's > a wider scope for it. > And rename it to run_repeatedly or some other name that describes it > better. > I renamed the function. Why do you think there's not scope for it? I'd rather keep it in tasks, since it addresses a general use case of waiting in a loop until a command returns expected output. This can happen with any command that starts asynchronous actions and we want to make sure that the changes are propagated before continuing (such as DNS updates via our CLI). I wouldn't consider this being specific for AD trust testing. > > > Patch 105: > Please add these tasks to ipa-test-task (and its man page) as well. > The instructions in the docstring in configure_dns_for_trust should go > to a test design document. I think just starting a section in > Integration_testing would be fine if you mark it as not implemented > yet (and link to the ticket). > > Use parentheses instead of \ for line continuation (see PEP8). I don't really like wrapping arbitrary expressions in parentheses, particularly when assigning the result to a variable: result = (something or something_completely_else) To me, the following looks better: result = something or \ something completely else I checked with PEP8. I remember there was a section that backslash can be used in cases it produces nicer results, but it's gone now. Backslash is still recommended in some cases. Still (but no strong opinions here), I would not consider this a violation unless it happens between brackets (in which case it is redundant). > > Patch 106: > The instructions in the TestADTrust docstring should go to a test > design document. > > Please use the SID regex from a shared location. You'll need to assign > it to a variable and make the Fuzzy from that, so that variable can be > imported and used with the standard re module. > This is something that I tried to address with the Fuzzy refactoring. This is a temporary solution, once we resolve that patchset, of course, the test will use the shared location. I added a comment there, I'd rather not create conflicts. > Avoid commented-out code in patches for review. > No need to import fuzzy. Fixed. > > test_user_gid_uid_resolution_in_nonposix_trust: > - For a one-off regex, compile() is unnecessary: > assert re.search(testuser_regex, result.stdout_text) > - Whenever substituting a literal string into a regex, please use > re.escape(). > Fixed. > Use parentheses instead of \ for line continuation (see PEP8). > > Design will follow soon. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0100-2-ipatests-Add-Active-Directory-support-to-configurati.patch Type: text/x-patch Size: 5280 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0101-2-ipatests-Extend-domain-object-with-ad-role-support-a.patch Type: text/x-patch Size: 3078 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0102-2-ipatests-Extend-IntegrationTest-with-multiple-AD-dom.patch Type: text/x-patch Size: 2786 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0103-2-ipatests-Add-WinHost-class.patch Type: text/x-patch Size: 3024 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0104-2-ipatests-Add-wait_assert-method-to-tasks-suite.patch Type: text/x-patch Size: 1813 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0105-2-ipatests-Add-AD-integration-related-tasks.patch Type: text/x-patch Size: 6859 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0106-2-ipatests-Add-AD-integration-test-case.patch Type: text/x-patch Size: 6817 bytes Desc: not available URL: From jcholast at redhat.com Tue Sep 17 15:13:43 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 17 Sep 2013 17:13:43 +0200 Subject: [Freeipa-devel] [PATCHES] 0177-0179 Add missing dict methods to CIDict In-Reply-To: <5124FBBB.6080801@redhat.com> References: <51113B3F.3070808@redhat.com> <51237565.1040404@redhat.com> <5124FBBB.6080801@redhat.com> Message-ID: <523871A7.9050506@redhat.com> On 20.2.2013 17:37, Petr Viktorin wrote: > On 02/19/2013 01:51 PM, Jan Cholasta wrote: >> Hi, >> >> On 5.2.2013 18:02, Petr Viktorin wrote: >>> CIDict, our case-insensitive dictionary, inherits from dict but did not >>> reimplement the full dict interface. Calling the missing methods >>> silently invoked case-sensitive behavior. Our code seems to avoid that, >>> but it's a bit of a minefield for new development. >>> >>> Patch 119 adds the missing dict methods (except >>> view{items,keys,values}(), which now raise errors), and adds tests. >> >> Can you please also add the (obj, **kwargs) and (**kwargs) variants of >> __init__ and update? > > Added, thanks for the catch. > >> >>> >>> >>> Patches 117-118 modernize the testsuite a bit (these have been sitting >>> in my queue for a while, I think now is a good time to submit them): >>> The first one moves some old tests from the main code tree to tests/. >>> (The adtrust_install test wasn't run before, this move makes nose notice >>> it). >>> The second converts CIDict's unittest-based suite to nose. >>> >> >> Honza >> > > Whoa, I totally forgot about these patches! Can you please rebase them? One more comment: Document that CIDict.copy() returns a plain dict. Why does it return a plain dict? I think it should return a CIDict, otherwise it is not actually a copy, right? Honza -- Jan Cholasta From jcholast at redhat.com Tue Sep 17 15:26:47 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 17 Sep 2013 17:26:47 +0200 Subject: [Freeipa-devel] [PATCH] #3901 In-Reply-To: <1378840349.2804.1572.camel@willson.li.ssimo.org> References: <1378840349.2804.1572.camel@willson.li.ssimo.org> Message-ID: <523874B7.3070800@redhat.com> On 10.9.2013 21:12, Simo Sorce wrote: > I think the attached (untested) patch should solve the issue. > > Is it sufficient or do we want to change framework code somehow ? > > Simo. > I think no changes to the framework are necessary. It already adds krbTicketPolicyAux when krbTicketFlags is touched in host-add and host-mod. Honza -- Jan Cholasta From hotz at jpl.nasa.gov Tue Sep 17 18:26:13 2013 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Tue, 17 Sep 2013 11:26:13 -0700 Subject: [Freeipa-devel] Off Topic, was: [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <5237C1F6.4010702@redhat.com> References: <1378355153.19352.29.camel@localhost> <5231A566.30904@redhat.com> <523212EF.7030302@redhat.com> <52333B14.7030403@redhat.com> <52335BAC.3020100@redhat.com> <1379179533.2804.2008.camel@willson.li.ssimo.org> <4F1B69B6-1E27-4AC6-818F-D4FA36948674@jpl.nasa.gov> <5237C1F6.4010702@redhat.com> Message-ID: <899A0066-BB09-4B09-BC41-F2C57922C48D@jpl.nasa.gov> Thanks for the update. Obviously my info is old, though I have seen issues with our RSA deployment that suggest things haven't effectively changed much in their product. On Sep 16, 2013, at 7:44 PM, Dmitri Pal wrote: >> Substituting FAST/OTP for SAM doesn't change anything in the back-end exchange and performance. > I do not remember the details of the patch described above, i.e. was it > generic or for OTP case only. The SAM client code was in MIT since sometime before 1.2. They never added the server side, though I think they deployed a local version sometime a few years ago. The server code was available IIRC as part of MRL's "monster patch". Only deployed by a few supercomputing sites. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu From hotz at jpl.nasa.gov Tue Sep 17 18:50:54 2013 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Tue, 17 Sep 2013 11:50:54 -0700 Subject: [Freeipa-devel] Off Topic, was: [PATCH 0017] Add OTP support to ipalib CLI In-Reply-To: <899A0066-BB09-4B09-BC41-F2C57922C48D@jpl.nasa.gov> References: <1378355153.19352.29.camel@localhost> <5231A566.30904@redhat.com> <523212EF.7030302@redhat.com> <52333B14.7030403@redhat.com> <52335BAC.3020100@redhat.com> <1379179533.2804.2008.camel@willson.li.ssimo.org> <4F1B69B6-1E27-4AC6-818F-D4FA36948674@jpl.nasa.gov> <5237C1F6.4010702@redhat.com> <899A0066-BB09-4B09-BC41-F2C57922C48D@jpl.nasa.gov> Message-ID: <7856AE19-D3B2-4951-91EE-74ECE2A34FC2@jpl.nasa.gov> On Sep 17, 2013, at 11:26 AM, "Henry B. Hotz" wrote: > MRL's Gaaa. Spelling mis-correction. That should have been NRL, as in Naval Research Lab where Ken Hornstein worked. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu From pviktori at redhat.com Wed Sep 18 10:30:13 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 18 Sep 2013 12:30:13 +0200 Subject: [Freeipa-devel] [PATCHES] 0278-0279 Make it possible to run integration tests without Paramiko Message-ID: <523980B5.8030300@redhat.com> Hello, These patches take the SSH2 bits out of the integration tests' Host class into a Transport class, and add a new Transport that uses /usr/bin/ssh to talk with remote hosts. The Host class is broken up to help adding AD trust tests (see Tom??'s patches 100-106, the WinHost addition can be simplified now; in the future adding e.g. a telnet transport should be easier). The spec file is not changed, I believe Paramiko is a better default for Fedora. The OpenSSH transport can be selected by setting IPA_TEST_SSH_TRANSPORT=openssh. https://fedorahosted.org/freeipa/ticket/3890 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0278-test_integration.host-Move-transport-related-functio.patch Type: text/x-patch Size: 27909 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0279-test_integration-Add-OpenSSHTransport-used-if-parami.patch Type: text/x-patch Size: 7647 bytes Desc: not available URL: From akrivoka at redhat.com Wed Sep 18 11:37:11 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 18 Sep 2013 13:37:11 +0200 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <5232D167.30201@redhat.com> References: <523200E9.5010304@redhat.com> <5232D167.30201@redhat.com> Message-ID: <52399067.1080901@redhat.com> On 09/13/2013 10:48 AM, Martin Kosek wrote: > On 09/12/2013 07:59 PM, Ana Krivokapic wrote: >> Hello, >> >> The design document for $SUBJECT can be found at: >> http://www.freeipa.org/page/V3/Automember_rebuild_membership >> >> Related tickets: >> https://fedorahosted.org/freeipa/ticket/3752 >> https://fedorahosted.org/freeipa/ticket/3928 >> >> Thoughts, comments, questions welcome. >> > Besides membership reset discussion happening in second thread I other comments. > > 1) I think we should also design permission&ACIs for the automember rebuild > task creation (cn=automember rebuild membership,cn=tasks,cn=config container). > You can talk to Petr3 about that as he is current working on redesigning ACIs. > Just so that you are in sync. I discussed this with Petr. We agreed that since the new redesign of ACIs will not be implemented for some time, I should use the old way to add the ACIs for automember tasks. I added a section to the design document to address ACIs, permissions and privileges: http://www.freeipa.org/page/V3/Automember_rebuild_membership#Updates_and_Upgrades > > 2) About the "Implementation" part and "automember rebuild membership" > > I do not think this is good approach. I do not know how do you plan doing the > confirmation > > I do not think this workflow would work with our framework. We do not have > support for confirming except if you would implement it in > interactive_prompt_callback. But then the functionality would not be available > for Web UI. > > I would rather add an option --dry-run or --test for all new automember > commands which would return how would the updated entry look like. BTW, did the > automember export updates task work for you? I tried this LDIF and > /tmp/automember.ldif was empty: > > dn: cn=my export task 1, cn=automember export updates,cn=tasks,cn=config > changetype: add > objectClass: top > objectClass: extensibleObject > cn: my export task 1 > basedn: cn=accounts,dc=example,dc=com > filter: (uid=*) > scope: sub > ldif: /tmp/automember.ldif > > Adding Mark to CC in case if he has any advise for utilizing the export task in > FreeIPA. > > By the way, using this approach I think we would also hit issues with > permissions on the resulting LDIF, given it is created by DS and would be read > by Apache. SELinux would be complaining as well. To sum it up, I am not sure > this will be that easy and straightforward. You are right about this. I haven't been able to find a way to make this work. Namely, the resulting LDIF is created by dirsrv user and is not readable by apache user. Any ideas/pointers here would be very much appreciated. > > Martin -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From pviktori at redhat.com Wed Sep 18 12:00:43 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 18 Sep 2013 14:00:43 +0200 Subject: [Freeipa-devel] [PATCHES] 0177-0179 Add missing dict methods to CIDict In-Reply-To: <523871A7.9050506@redhat.com> References: <51113B3F.3070808@redhat.com> <51237565.1040404@redhat.com> <5124FBBB.6080801@redhat.com> <523871A7.9050506@redhat.com> Message-ID: <523995EB.9010706@redhat.com> On 09/17/2013 05:13 PM, Jan Cholasta wrote: > On 20.2.2013 17:37, Petr Viktorin wrote: >> On 02/19/2013 01:51 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 5.2.2013 18:02, Petr Viktorin wrote: >>>> CIDict, our case-insensitive dictionary, inherits from dict but did not >>>> reimplement the full dict interface. Calling the missing methods >>>> silently invoked case-sensitive behavior. Our code seems to avoid that, >>>> but it's a bit of a minefield for new development. >>>> >>>> Patch 119 adds the missing dict methods (except >>>> view{items,keys,values}(), which now raise errors), and adds tests. >>> >>> Can you please also add the (obj, **kwargs) and (**kwargs) variants of >>> __init__ and update? >> >> Added, thanks for the catch. >> >>> >>>> >>>> >>>> Patches 117-118 modernize the testsuite a bit (these have been sitting >>>> in my queue for a while, I think now is a good time to submit them): >>>> The first one moves some old tests from the main code tree to tests/. >>>> (The adtrust_install test wasn't run before, this move makes nose >>>> notice >>>> it). >>>> The second converts CIDict's unittest-based suite to nose. >>>> >>> >>> Honza >>> >> >> > > Whoa, I totally forgot about these patches! > > Can you please rebase them? Sure! > One more comment: > > Document that CIDict.copy() returns a plain dict. > > Why does it return a plain dict? I think it should return a CIDict, > otherwise it is not actually a copy, right? I wanted to keep the existing (intended) functionality. But since we don't actually use CIDict.copy() anywhere any more, I've made the change. P.S. I recently came across a bug in python-ldap where something like CIDict({'cn': ['name1', 'name2'], 'cN': ['name3']}) will throw away some of the values. This is expected at the CIDict level, but if you're working with dicts of lists it's something to keep an eye out for. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0177.3-Move-tests-to-test-directories.patch Type: text/x-patch Size: 38431 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0178.3-Convert-test_ipautil-from-unittest-to-nose.patch Type: text/x-patch Size: 17710 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0179.3-Add-missing-dict-methods-to-CIDict.patch Type: text/x-patch Size: 9309 bytes Desc: not available URL: From mkosek at redhat.com Wed Sep 18 14:26:59 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 18 Sep 2013 16:26:59 +0200 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <52399067.1080901@redhat.com> References: <523200E9.5010304@redhat.com> <5232D167.30201@redhat.com> <52399067.1080901@redhat.com> Message-ID: <5239B833.3050108@redhat.com> On 09/18/2013 01:37 PM, Ana Krivokapic wrote: > On 09/13/2013 10:48 AM, Martin Kosek wrote: >> On 09/12/2013 07:59 PM, Ana Krivokapic wrote: ... >> >> I would rather add an option --dry-run or --test for all new automember >> commands which would return how would the updated entry look like. BTW, did the >> automember export updates task work for you? I tried this LDIF and >> /tmp/automember.ldif was empty: >> >> dn: cn=my export task 1, cn=automember export updates,cn=tasks,cn=config >> changetype: add >> objectClass: top >> objectClass: extensibleObject >> cn: my export task 1 >> basedn: cn=accounts,dc=example,dc=com >> filter: (uid=*) >> scope: sub >> ldif: /tmp/automember.ldif >> >> Adding Mark to CC in case if he has any advise for utilizing the export task in >> FreeIPA. >> >> By the way, using this approach I think we would also hit issues with >> permissions on the resulting LDIF, given it is created by DS and would be read >> by Apache. SELinux would be complaining as well. To sum it up, I am not sure >> this will be that easy and straightforward. > > You are right about this. I haven't been able to find a way to make this work. > Namely, the resulting LDIF is created by dirsrv user and is not readable by > apache user. Any ideas/pointers here would be very much appreciated. Right. I would try asking 389-ds guys, Mark, Nathan (CCed) or Rich about that. If we do not find a better way to transfer the resulting LDIF to Apache, we will need to leave the --dry-run part until we do. Martin From mbasti at redhat.com Wed Sep 18 15:07:28 2013 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Sep 2013 17:07:28 +0200 Subject: [Freeipa-devel] [DOC] Chapter 4 screenshots Message-ID: <1379516848.9269.3.camel@unused-4-145.brq.redhat.com> Patch adds new screen-shots for chapter 4 Basic Usage NOTE: Patch doesn't cover part 4.3 Logging with web UI -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0003-Chapter_4_screenshots.patch Type: text/x-patch Size: 757280 bytes Desc: not available URL: From mbasti at redhat.com Wed Sep 18 15:10:57 2013 From: mbasti at redhat.com (Martin Basti) Date: Wed, 18 Sep 2013 17:10:57 +0200 Subject: [Freeipa-devel] [DOC] Chapter 4 text Message-ID: <1379517057.9269.7.camel@unused-4-145.brq.redhat.com> Patch fix examples in chapter 4, adds new examples, fix out of date information. NOTE: Patch doesn't cover part 4.3 Logging with web UI -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0004-chapter_4_text.patch Type: text/x-patch Size: 9020 bytes Desc: not available URL: From akrivoka at redhat.com Wed Sep 18 16:42:13 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 18 Sep 2013 18:42:13 +0200 Subject: [Freeipa-devel] [PATCH] 0067 Use fqdn when creating msdcs SRV records Message-ID: <5239D7E5.2090401@redhat.com> Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3908. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0067-Use-fqdn-when-creating-msdcs-SRV-records.patch Type: text/x-patch Size: 1189 bytes Desc: not available URL: From nkinder at redhat.com Wed Sep 18 16:51:17 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 18 Sep 2013 09:51:17 -0700 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <5239B833.3050108@redhat.com> References: <523200E9.5010304@redhat.com> <5232D167.30201@redhat.com> <52399067.1080901@redhat.com> <5239B833.3050108@redhat.com> Message-ID: <5239DA05.3010509@redhat.com> On 09/18/2013 07:26 AM, Martin Kosek wrote: > On 09/18/2013 01:37 PM, Ana Krivokapic wrote: >> On 09/13/2013 10:48 AM, Martin Kosek wrote: >>> On 09/12/2013 07:59 PM, Ana Krivokapic wrote: > ... >>> I would rather add an option --dry-run or --test for all new automember >>> commands which would return how would the updated entry look like. BTW, did the >>> automember export updates task work for you? I tried this LDIF and >>> /tmp/automember.ldif was empty: >>> >>> dn: cn=my export task 1, cn=automember export updates,cn=tasks,cn=config >>> changetype: add >>> objectClass: top >>> objectClass: extensibleObject >>> cn: my export task 1 >>> basedn: cn=accounts,dc=example,dc=com >>> filter: (uid=*) >>> scope: sub >>> ldif: /tmp/automember.ldif >>> >>> Adding Mark to CC in case if he has any advise for utilizing the export task in >>> FreeIPA. >>> >>> By the way, using this approach I think we would also hit issues with >>> permissions on the resulting LDIF, given it is created by DS and would be read >>> by Apache. SELinux would be complaining as well. To sum it up, I am not sure >>> this will be that easy and straightforward. >> You are right about this. I haven't been able to find a way to make this work. >> Namely, the resulting LDIF is created by dirsrv user and is not readable by >> apache user. Any ideas/pointers here would be very much appreciated. > Right. I would try asking 389-ds guys, Mark, Nathan (CCed) or Rich about that. > If we do not find a better way to transfer the resulting LDIF to Apache, we > will need to leave the --dry-run part until we do. I don't see an easy way of solving this without changes to 389 DS that offer alternate methods for exporting the automember updates, such as making them available via LDAP. I'm not even sure if this is a good idea since the export could be quite sizable. Another approach would be to allow the task to specify the mode to use when creating the export file. This still isn't ideal, as you either have to open the file up to everyone, or you have to have the httpd and 389 DS users in the same group (which opens up other permission issues). Thanks, -NGK > > Martin From npmccallum at redhat.com Wed Sep 18 19:51:10 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 18 Sep 2013 15:51:10 -0400 Subject: [Freeipa-devel] [PATCH 0015] Add support for managing user auth types In-Reply-To: <522DCE8B.9040009@redhat.com> References: <1378353865.19352.9.camel@localhost> <522DCE8B.9040009@redhat.com> Message-ID: <1379533870.1629.5.camel@localhost> On Mon, 2013-09-09 at 15:35 +0200, Petr Viktorin wrote: > On 09/05/2013 06:04 AM, Nathaniel McCallum wrote: > > patch attached > > Thanks, some comments below. > > Git complains about trailing whitespace in the patch, please strip it. Fixed. > > freeipa-npmccallum-0015-Add-support-for-managing-user-auth-types.patch > > > > > >>From 757436ccc431d26a3e62de830dad0b107a6c48ff Mon Sep 17 00:00:00 2001 > > From: Nathaniel McCallum > > Date: Wed, 4 Sep 2013 23:35:36 -0400 > > Subject: [PATCH] Add support for managing user auth types > > > > https://fedorahosted.org/freeipa/ticket/3368 > > --- > > ipalib/plugins/config.py | 16 ++++++++++++++++ > > ipalib/plugins/user.py | 32 ++++++++++++++++++++++---------- > > 2 files changed, 38 insertions(+), 10 deletions(-) > > > > diff --git a/ipalib/plugins/config.py b/ipalib/plugins/config.py > > index b9cf05016bf80cd48134cca5a50cdca7db423ca9..692ca22db70eb9a81a49eab6dc1e23284c8a9946 100644 > > @@ -210,6 +218,14 @@ class config_mod(LDAPUpdate): > > > > def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): > > assert isinstance(dn, DN) > > + > > + if 'ipauserauthtype' in entry_attrs: > > + if 'objectclass' not in entry_attrs: > > + (_dn, _entry_attrs) = ldap.get_entry(dn, ['objectclass']) > > + entry_attrs['objectclass'] = _entry_attrs['objectclass'] > > + if 'ipauserauthtypeclass' not in entry_attrs['objectclass']: > > + entry_attrs['objectclass'].append('ipauserauthtypeclass') > > Shouldn't we rather add ipaUserAuthType to the ipaGuiConfig objectclass? No. The ipaUserAuthTypeClass is generic and will be used several places. > If not, we should still update ipaConfig on IPA update update rather > than here; install/updates/50-ipaconfig.update would be a good place. Fixed. > > diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py > > index 471981f48204209753eda2fb994d4c653dca0fa2..02f62120d281a873dfd9c21e1b855b112cca05a4 100644 > [...] > > @@ -633,14 +640,19 @@ class user_mod(LDAPUpdate): > > entry_attrs['userpassword'] = ipa_generate_password(user_pwdchars) > > # save the password so it can be displayed in post_callback > > setattr(context, 'randompassword', entry_attrs['userpassword']) > > + > > + if 'objectclass' not in entry_attrs: > > + (_dn, _entry_attrs) = ldap.get_entry(dn, ['objectclass']) > > + entry_attrs['objectclass'] = _entry_attrs['objectclass'] > > The framework is forcing some pretty ugly code here. > I've filed https://fedorahosted.org/freeipa/ticket/3914 to simplify this > in the future. > > > Just a note, it's no longer necessary to use (_dn, _entry_attrs) here; > ldap.get_entry() now returns a dict-like entry directly so you can use: > > _entry = ldap.get_entry(dn, ['objectclass']) > entry_attrs['objectclass'] = _entry['objectclass'] > > In fact, unpacking the entry into a tuple returns the DN and the entry > object itself. This: > (dn, entry) = ldap.get_entry(...) > is exactly equivalent to: > entry = ldap.get_entry(...) > dn = entry.dn > but the former is deprecated. Fixed. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0015-3-Add-support-for-managing-user-auth-types.patch Type: text/x-patch Size: 10235 bytes Desc: not available URL: From akrivoka at redhat.com Thu Sep 19 09:00:05 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 19 Sep 2013 11:00:05 +0200 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <5239DA05.3010509@redhat.com> References: <523200E9.5010304@redhat.com> <5232D167.30201@redhat.com> <52399067.1080901@redhat.com> <5239B833.3050108@redhat.com> <5239DA05.3010509@redhat.com> Message-ID: <523ABD15.7070200@redhat.com> On 09/18/2013 06:51 PM, Nathan Kinder wrote: > On 09/18/2013 07:26 AM, Martin Kosek wrote: >> On 09/18/2013 01:37 PM, Ana Krivokapic wrote: >>> On 09/13/2013 10:48 AM, Martin Kosek wrote: >>>> On 09/12/2013 07:59 PM, Ana Krivokapic wrote: >> ... >>>> I would rather add an option --dry-run or --test for all new automember >>>> commands which would return how would the updated entry look like. BTW, did >>>> the >>>> automember export updates task work for you? I tried this LDIF and >>>> /tmp/automember.ldif was empty: >>>> >>>> dn: cn=my export task 1, cn=automember export updates,cn=tasks,cn=config >>>> changetype: add >>>> objectClass: top >>>> objectClass: extensibleObject >>>> cn: my export task 1 >>>> basedn: cn=accounts,dc=example,dc=com >>>> filter: (uid=*) >>>> scope: sub >>>> ldif: /tmp/automember.ldif >>>> >>>> Adding Mark to CC in case if he has any advise for utilizing the export >>>> task in >>>> FreeIPA. >>>> >>>> By the way, using this approach I think we would also hit issues with >>>> permissions on the resulting LDIF, given it is created by DS and would be read >>>> by Apache. SELinux would be complaining as well. To sum it up, I am not sure >>>> this will be that easy and straightforward. >>> You are right about this. I haven't been able to find a way to make this work. >>> Namely, the resulting LDIF is created by dirsrv user and is not readable by >>> apache user. Any ideas/pointers here would be very much appreciated. >> Right. I would try asking 389-ds guys, Mark, Nathan (CCed) or Rich about that. >> If we do not find a better way to transfer the resulting LDIF to Apache, we >> will need to leave the --dry-run part until we do. > I don't see an easy way of solving this without changes to 389 DS that offer > alternate methods for exporting the automember updates, such as making them > available via LDAP. I'm not even sure if this is a good idea since the export > could be quite sizable. > > Another approach would be to allow the task to specify the mode to use when > creating the export file. This still isn't ideal, as you either have to open > the file up to everyone, or you have to have the httpd and 389 DS users in the > same group (which opens up other permission issues). > > Thanks, > -NGK >> >> Martin > Thanks Nathan for your input. I opened this ticket to allow a better way of accessing results of the automember export updates task: https://fedorahosted.org/389/ticket/47518. After further conversation with Nathan on IRC, we both agreed that at this point, the --dry-run option seems to be more trouble than it's worth. So I will leave it out for now (until the above ticket is implemented in 389). -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From tbabej at redhat.com Thu Sep 19 09:57:25 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 19 Sep 2013 11:57:25 +0200 Subject: [Freeipa-devel] [PATCH 107] Do not add trust to AD in case of IPA realm-domain mismatch Message-ID: <523ACA85.5050808@redhat.com> Hi, Make sure that trust-add command fails when admin attempts to add an Active Directory trust when the realm name and the domain name of the IPA server do not match. https://fedorahosted.org/freeipa/ticket/3923 -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0107-Do-not-add-trust-to-AD-in-case-of-IPA-realm-domain-m.patch Type: text/x-patch Size: 1607 bytes Desc: not available URL: From tbabej at redhat.com Thu Sep 19 09:58:32 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 19 Sep 2013 11:58:32 +0200 Subject: [Freeipa-devel] [PATCH 108] Warn user about realm-domain mismatch in install scripts Message-ID: <523ACAC8.2030707@redhat.com> Hi, If the IPA server is setup with non-matching domain and realm names, it will not be able to estabilish trust with the Active Directory. Adds warnings to the ipa-server-install and warning to the ipa-adtrust-install (which has to be confirmed). Man pages for the ipa-server-install and ipa-adtrust-install were updated with the relevant notes. https://fedorahosted.org/freeipa/ticket/3924 -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0108-Warn-user-about-realm-domain-mismatch-in-install-scr.patch Type: text/x-patch Size: 4833 bytes Desc: not available URL: From tbabej at redhat.com Thu Sep 19 09:59:20 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 19 Sep 2013 11:59:20 +0200 Subject: [Freeipa-devel] [PATCH 109] Use getent admin@domain for nss check in, ipa-client-install Message-ID: <523ACAF8.5010802@redhat.com> Hi, Use 'getent admin at domain' rather than 'getent admin at REALM' to check if nss is working properly since admin at REALM check fails in case the domain and the realm name does not match. https://fedorahosted.org/freeipa/ticket/3906 -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0109-Use-getent-admin-domain-for-nss-check-in-ipa-client-.patch Type: text/x-patch Size: 1332 bytes Desc: not available URL: From tbabej at redhat.com Thu Sep 19 10:00:49 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 19 Sep 2013 12:00:49 +0200 Subject: [Freeipa-devel] [PATCH 110] ipa-sam: Fix memory leaks Message-ID: <523ACB51.3020903@redhat.com> Hi, this fixes a memory leak in ipa-sam plugin. https://fedorahosted.org/freeipa/ticket/3913 -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0110-ipa-sam-Fix-memory-leaks.patch Type: text/x-patch Size: 1781 bytes Desc: not available URL: From mkosek at redhat.com Thu Sep 19 10:01:12 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Sep 2013 06:01:12 -0400 (EDT) Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <523ABD15.7070200@redhat.com> References: <523200E9.5010304@redhat.com> <5232D167.30201@redhat.com> <52399067.1080901@redhat.com> <5239B833.3050108@redhat.com> <5239DA05.3010509@redhat.com> <523ABD15.7070200@redhat.com> Message-ID: <2119175130.15172453.1379584872374.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Ana Krivokapic" > To: "Nathan Kinder" > Cc: "Martin Kosek" , "freeipa-devel" , "Mark Reynolds" > > Sent: Thursday, September 19, 2013 11:00:05 AM > Subject: Re: [Freeipa-devel] [RFE] Support for automember rebuild membership > > On 09/18/2013 06:51 PM, Nathan Kinder wrote: > > On 09/18/2013 07:26 AM, Martin Kosek wrote: > >> On 09/18/2013 01:37 PM, Ana Krivokapic wrote: > >>> On 09/13/2013 10:48 AM, Martin Kosek wrote: > >>>> On 09/12/2013 07:59 PM, Ana Krivokapic wrote: > >> ... > >>>> I would rather add an option --dry-run or --test for all new automember > >>>> commands which would return how would the updated entry look like. BTW, > >>>> did > >>>> the > >>>> automember export updates task work for you? I tried this LDIF and > >>>> /tmp/automember.ldif was empty: > >>>> > >>>> dn: cn=my export task 1, cn=automember export updates,cn=tasks,cn=config > >>>> changetype: add > >>>> objectClass: top > >>>> objectClass: extensibleObject > >>>> cn: my export task 1 > >>>> basedn: cn=accounts,dc=example,dc=com > >>>> filter: (uid=*) > >>>> scope: sub > >>>> ldif: /tmp/automember.ldif > >>>> > >>>> Adding Mark to CC in case if he has any advise for utilizing the export > >>>> task in > >>>> FreeIPA. > >>>> > >>>> By the way, using this approach I think we would also hit issues with > >>>> permissions on the resulting LDIF, given it is created by DS and would > >>>> be read > >>>> by Apache. SELinux would be complaining as well. To sum it up, I am not > >>>> sure > >>>> this will be that easy and straightforward. > >>> You are right about this. I haven't been able to find a way to make this > >>> work. > >>> Namely, the resulting LDIF is created by dirsrv user and is not readable > >>> by > >>> apache user. Any ideas/pointers here would be very much appreciated. > >> Right. I would try asking 389-ds guys, Mark, Nathan (CCed) or Rich about > >> that. > >> If we do not find a better way to transfer the resulting LDIF to Apache, > >> we > >> will need to leave the --dry-run part until we do. > > I don't see an easy way of solving this without changes to 389 DS that > > offer > > alternate methods for exporting the automember updates, such as making them > > available via LDAP. I'm not even sure if this is a good idea since the > > export > > could be quite sizable. > > > > Another approach would be to allow the task to specify the mode to use when > > creating the export file. This still isn't ideal, as you either have to > > open > > the file up to everyone, or you have to have the httpd and 389 DS users in > > the > > same group (which opens up other permission issues). > > > > Thanks, > > -NGK > >> > >> Martin > > > > Thanks Nathan for your input. I opened this ticket to allow a better way of > accessing results of the automember export updates task: > https://fedorahosted.org/389/ticket/47518. After further conversation with > Nathan on IRC, we both agreed that at this point, the --dry-run option seems > to > be more trouble than it's worth. So I will leave it out for now (until the > above > ticket is implemented in 389). ACK! Please also create FreeIPA RFE ticket pointing to the 389 ticket so that we do no forget about it. Martin From tbabej at redhat.com Thu Sep 19 10:14:38 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 19 Sep 2013 12:14:38 +0200 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests In-Reply-To: <52386896.3000909@redhat.com> References: <52370B90.2030009@redhat.com> <52381625.3010607@redhat.com> <52386896.3000909@redhat.com> Message-ID: <523ACE8E.2060102@redhat.com> On 09/17/2013 04:35 PM, Tomas Babej wrote: > On 09/17/2013 10:43 AM, Petr Viktorin wrote: >> On 09/16/2013 03:45 PM, Tomas Babej wrote: >>> Hi, >>> >>> this set of patches extends ipatests module to support integration >>> testing with Active Directory, >>> as well as provides an basic (working without artificial sleeps!) trust >>> test case. >> >> Thanks, this is great news! >> I haven't testes the test yet. Here are my comments from reading them. >> >> >> Patch 100: >> Please document the new configuration options. There are two places: >> - ipa-test-config man page >> - >> http://www.freeipa.org/page/V3/Integration_testing#Test_configuration >> (or if you end up writing a separate design page for AD tests, link >> to it) >> > > I added the options to the the man page. > >> >> Patch 101: >> The `if role == 'ad':` block should rather be in the `Host.from_env` >> factory. >> > > Moved. > >> >> Patch 102: >> Thanks for cleaning that up! >> You could go one step further with >> cls.replicas = get_resources(domain.replicas, 'replicas', >> cls.num_replicas) >> and `return container[:num_needed]` there > > You're welcome, refactoring part expanded. > >> >> >> Patch 103: >> This patch should come before 101 which uses it. >> > > We can push this in the correct order if this is an issue, right? > Patches are independent (meaning they do not touch the same source > code, so they should apply cleanly). > >> Ideally there would be a BaseHost with common functionality, and >> concrete Host and WinHost subclassing it. > > Yes, I agree, that's what we discussed. > >> I'll be making changes here for #3890; please concentrate on other >> parts for now to avoid conflicts. I'll take Windows hosts into >> consideration. >> >> Raise instances rather than the exception classes: raise >> NotImplementedError() > Fixed. > >> >> >> Patch 104: >> Instead of stdout_re, allow the user to pass in a checking function. >> For example, `lambda result: re.search(sid_regex, result.stdout_text)` >> This makes wait_assert complete, you won't need to add other cases to >> it when you need to check stderr or evaluate some condition a regex >> is too weak for. > +1, improved. > >> >> Pass `raiseonerr` to run_command directly, not by setting it in >> kwargs. That way wait_assert will fail if it gets raiseonerr. >> Also, run_command's arguments except `command` are supposed to be >> keyword-only. (This is only not enforced because that's awkward to do >> in Python 2.) Don't accept or pass along *args. >> > Agreed, fixed. > >> Use parentheses instead of \ for line continuation (see PEP8). >> >> I'd prefer to keep the function in test_trust.py until we see there's >> a wider scope for it. >> And rename it to run_repeatedly or some other name that describes it >> better. >> > > I renamed the function. > > Why do you think there's not scope for it? I'd rather keep it in > tasks, since it addresses > a general use case of waiting in a loop until a command returns > expected output. > > This can happen with any command that starts asynchronous actions and > we want to make > sure that the changes are propagated before continuing (such as DNS > updates via our CLI). > > I wouldn't consider this being specific for AD trust testing. > >> >> >> Patch 105: >> Please add these tasks to ipa-test-task (and its man page) as well. >> The instructions in the docstring in configure_dns_for_trust should >> go to a test design document. I think just starting a section in >> Integration_testing would be fine if you mark it as not implemented >> yet (and link to the ticket). >> >> Use parentheses instead of \ for line continuation (see PEP8). > > I don't really like wrapping arbitrary expressions in parentheses, > particularly when assigning the result to a variable: > > result = (something or > something_completely_else) > > To me, the following looks better: > > result = something or \ > something completely else > > I checked with PEP8. I remember there was a section that backslash can > be used in cases it produces nicer results, but it's gone now. > Backslash is still recommended in some cases. > > Still (but no strong opinions here), I would not consider this a > violation unless it happens between brackets (in which case it is > redundant). > >> >> Patch 106: >> The instructions in the TestADTrust docstring should go to a test >> design document. >> >> Please use the SID regex from a shared location. You'll need to >> assign it to a variable and make the Fuzzy from that, so that >> variable can be imported and used with the standard re module. >> > > This is something that I tried to address with the Fuzzy refactoring. > This is a temporary solution, once we resolve that patchset, of > course, the test will use the shared location. > I added a comment there, I'd rather not create conflicts. > >> Avoid commented-out code in patches for review. >> No need to import fuzzy. > > Fixed. > >> >> test_user_gid_uid_resolution_in_nonposix_trust: >> - For a one-off regex, compile() is unnecessary: >> assert re.search(testuser_regex, result.stdout_text) >> - Whenever substituting a literal string into a regex, please use >> re.escape(). >> > Fixed. > >> Use parentheses instead of \ for line continuation (see PEP8). >> >> > > Design will follow soon. > I actually noticed that some of the fixes that address issues above stayed hidden in my git stash. Updated patches attached. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0100-3-ipatests-Add-Active-Directory-support-to-configurati.patch Type: text/x-patch Size: 5280 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0101-3-ipatests-Extend-domain-object-with-ad-role-support-a.patch Type: text/x-patch Size: 3078 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0102-3-ipatests-Extend-IntegrationTest-with-multiple-AD-dom.patch Type: text/x-patch Size: 2786 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0103-3-ipatests-Add-WinHost-class.patch Type: text/x-patch Size: 3024 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0104-3-ipatests-Add-wait_assert-method-to-tasks-suite.patch Type: text/x-patch Size: 1813 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0105-3-ipatests-Add-AD-integration-related-tasks.patch Type: text/x-patch Size: 6930 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0106-3-ipatests-Add-AD-integration-test-case.patch Type: text/x-patch Size: 6844 bytes Desc: not available URL: From akrivoka at redhat.com Thu Sep 19 10:19:28 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 19 Sep 2013 12:19:28 +0200 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <2119175130.15172453.1379584872374.JavaMail.root@redhat.com> References: <523200E9.5010304@redhat.com> <5232D167.30201@redhat.com> <52399067.1080901@redhat.com> <5239B833.3050108@redhat.com> <5239DA05.3010509@redhat.com> <523ABD15.7070200@redhat.com> <2119175130.15172453.1379584872374.JavaMail.root@redhat.com> Message-ID: <523ACFB0.6010902@redhat.com> On 09/19/2013 12:01 PM, Martin Kosek wrote: > ----- Original Message ----- >> From: "Ana Krivokapic" >> To: "Nathan Kinder" >> Cc: "Martin Kosek" , "freeipa-devel" , "Mark Reynolds" >> >> Sent: Thursday, September 19, 2013 11:00:05 AM >> Subject: Re: [Freeipa-devel] [RFE] Support for automember rebuild membership >> >> On 09/18/2013 06:51 PM, Nathan Kinder wrote: >>> On 09/18/2013 07:26 AM, Martin Kosek wrote: >>>> On 09/18/2013 01:37 PM, Ana Krivokapic wrote: >>>>> On 09/13/2013 10:48 AM, Martin Kosek wrote: >>>>>> On 09/12/2013 07:59 PM, Ana Krivokapic wrote: >>>> ... >>>>>> I would rather add an option --dry-run or --test for all new automember >>>>>> commands which would return how would the updated entry look like. BTW, >>>>>> did >>>>>> the >>>>>> automember export updates task work for you? I tried this LDIF and >>>>>> /tmp/automember.ldif was empty: >>>>>> >>>>>> dn: cn=my export task 1, cn=automember export updates,cn=tasks,cn=config >>>>>> changetype: add >>>>>> objectClass: top >>>>>> objectClass: extensibleObject >>>>>> cn: my export task 1 >>>>>> basedn: cn=accounts,dc=example,dc=com >>>>>> filter: (uid=*) >>>>>> scope: sub >>>>>> ldif: /tmp/automember.ldif >>>>>> >>>>>> Adding Mark to CC in case if he has any advise for utilizing the export >>>>>> task in >>>>>> FreeIPA. >>>>>> >>>>>> By the way, using this approach I think we would also hit issues with >>>>>> permissions on the resulting LDIF, given it is created by DS and would >>>>>> be read >>>>>> by Apache. SELinux would be complaining as well. To sum it up, I am not >>>>>> sure >>>>>> this will be that easy and straightforward. >>>>> You are right about this. I haven't been able to find a way to make this >>>>> work. >>>>> Namely, the resulting LDIF is created by dirsrv user and is not readable >>>>> by >>>>> apache user. Any ideas/pointers here would be very much appreciated. >>>> Right. I would try asking 389-ds guys, Mark, Nathan (CCed) or Rich about >>>> that. >>>> If we do not find a better way to transfer the resulting LDIF to Apache, >>>> we >>>> will need to leave the --dry-run part until we do. >>> I don't see an easy way of solving this without changes to 389 DS that >>> offer >>> alternate methods for exporting the automember updates, such as making them >>> available via LDAP. I'm not even sure if this is a good idea since the >>> export >>> could be quite sizable. >>> >>> Another approach would be to allow the task to specify the mode to use when >>> creating the export file. This still isn't ideal, as you either have to >>> open >>> the file up to everyone, or you have to have the httpd and 389 DS users in >>> the >>> same group (which opens up other permission issues). >>> >>> Thanks, >>> -NGK >>>> Martin >> Thanks Nathan for your input. I opened this ticket to allow a better way of >> accessing results of the automember export updates task: >> https://fedorahosted.org/389/ticket/47518. After further conversation with >> Nathan on IRC, we both agreed that at this point, the --dry-run option seems >> to >> be more trouble than it's worth. So I will leave it out for now (until the >> above >> ticket is implemented in 389). > ACK! Please also create FreeIPA RFE ticket pointing to the 389 ticket so that we do no forget about it. > > Martin https://fedorahosted.org/freeipa/ticket/3936 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From jcholast at redhat.com Thu Sep 19 13:26:58 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 19 Sep 2013 15:26:58 +0200 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <523200E9.5010304@redhat.com> References: <523200E9.5010304@redhat.com> Message-ID: <523AFBA2.9070000@redhat.com> Hi, On 12.9.2013 19:59, Ana Krivokapic wrote: > Hello, > > The design document for $SUBJECT can be found at: > http://www.freeipa.org/page/V3/Automember_rebuild_membership > > Related tickets: > https://fedorahosted.org/freeipa/ticket/3752 > https://fedorahosted.org/freeipa/ticket/3928 > > Thoughts, comments, questions welcome. > I don't think naming the commands user-automember-rebuild and host-automember-rebuild commands is correct. The names imply they are methods of user/host, but they don't directly do anything to user/host objects. I would prefer if they were kept in the automember namespace where they logically belong (automember-rebuild-user and automember-rebuild-host perhaps?) Honza -- Jan Cholasta From akrivoka at redhat.com Thu Sep 19 13:29:02 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 19 Sep 2013 15:29:02 +0200 Subject: [Freeipa-devel] [PATCHES] 0068-0070 Automember rebuild membership Message-ID: <523AFC1E.4080005@redhat.com> Hello, This patch set adds automember rebuild membership functionality to IPA CLI. Design: http://www.freeipa.org/page/V3/Automember_rebuild_membership Ticket: https://fedorahosted.org/freeipa/ticket/3752 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0068-Add-automember-rebuild-commands.patch Type: text/x-patch Size: 11138 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0069-Add-permissions-for-automember-rebuild-commands.patch Type: text/x-patch Size: 2390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0070-Add-unit-tests-for-automember-rebuild-commands.patch Type: text/x-patch Size: 20917 bytes Desc: not available URL: From akrivoka at redhat.com Thu Sep 19 13:43:46 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 19 Sep 2013 15:43:46 +0200 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <523AFBA2.9070000@redhat.com> References: <523200E9.5010304@redhat.com> <523AFBA2.9070000@redhat.com> Message-ID: <523AFF92.6070805@redhat.com> On 09/19/2013 03:26 PM, Jan Cholasta wrote: > Hi, > > On 12.9.2013 19:59, Ana Krivokapic wrote: >> Hello, >> >> The design document for $SUBJECT can be found at: >> http://www.freeipa.org/page/V3/Automember_rebuild_membership >> >> Related tickets: >> https://fedorahosted.org/freeipa/ticket/3752 >> https://fedorahosted.org/freeipa/ticket/3928 >> >> Thoughts, comments, questions welcome. >> > > I don't think naming the commands user-automember-rebuild and > host-automember-rebuild commands is correct. The names imply they are methods > of user/host, but they don't directly do anything to user/host objects. I > would prefer if they were kept in the automember namespace where they > logically belong (automember-rebuild-user and automember-rebuild-host perhaps?) > > Honza > That makes sense... I don't have a strong preference one way or other. So if other agree with this suggestion, I will change it. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From tbabej at redhat.com Thu Sep 19 14:33:14 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 19 Sep 2013 16:33:14 +0200 Subject: [Freeipa-devel] [PATCH 109] Use getent admin@domain for nss check in, ipa-client-install In-Reply-To: <523ACAF8.5010802@redhat.com> References: <523ACAF8.5010802@redhat.com> Message-ID: <523B0B2A.5070206@redhat.com> On 09/19/2013 11:59 AM, Tomas Babej wrote: > Hi, > > Use 'getent admin at domain' rather than 'getent admin at REALM' to check if > nss > is working properly since admin at REALM check fails in case the domain > and the realm > name does not match. > > https://fedorahosted.org/freeipa/ticket/3906 > > Thanks to Ana for telling me I basically copied Stephen's patch: https://www.redhat.com/archives/freeipa-devel/2013-September/msg00085.html And I did the same mistake. Fixed patched attached. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0109-2-Use-getent-admin-domain-for-nss-check-in-ipa-client-.patch Type: text/x-patch Size: 1775 bytes Desc: not available URL: From akrivoka at redhat.com Thu Sep 19 14:41:04 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 19 Sep 2013 16:41:04 +0200 Subject: [Freeipa-devel] [PATCH 109] Use getent admin@domain for nss check in, ipa-client-install In-Reply-To: <523B0B2A.5070206@redhat.com> References: <523ACAF8.5010802@redhat.com> <523B0B2A.5070206@redhat.com> Message-ID: <523B0D00.7000501@redhat.com> On 09/19/2013 04:33 PM, Tomas Babej wrote: > On 09/19/2013 11:59 AM, Tomas Babej wrote: >> Hi, >> >> Use 'getent admin at domain' rather than 'getent admin at REALM' to check if nss >> is working properly since admin at REALM check fails in case the domain and the >> realm >> name does not match. >> >> https://fedorahosted.org/freeipa/ticket/3906 >> >> > > Thanks to Ana for telling me I basically copied Stephen's patch: > > https://www.redhat.com/archives/freeipa-devel/2013-September/msg00085.html > > And I did the same mistake. Fixed patched attached. > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Thu Sep 19 15:58:07 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 19 Sep 2013 17:58:07 +0200 Subject: [Freeipa-devel] [PATCHES 100-106] Initial implementation of AD integration tests In-Reply-To: <52386896.3000909@redhat.com> References: <52370B90.2030009@redhat.com> <52381625.3010607@redhat.com> <52386896.3000909@redhat.com> Message-ID: <523B1F0F.3010101@redhat.com> On 09/17/2013 04:35 PM, Tomas Babej wrote: > On 09/17/2013 10:43 AM, Petr Viktorin wrote: >> On 09/16/2013 03:45 PM, Tomas Babej wrote: >>> Hi, >>> >>> this set of patches extends ipatests module to support integration >>> testing with Active Directory, >>> as well as provides an basic (working without artificial sleeps!) trust >>> test case. >> >> Thanks, this is great news! >> I haven't testes the test yet. Here are my comments from reading them. >> >> >> Patch 100: >> Please document the new configuration options. There are two places: >> - ipa-test-config man page >> - >> http://www.freeipa.org/page/V3/Integration_testing#Test_configuration >> (or if you end up writing a separate design page for AD tests, link to >> it) >> > > I added the options to the the man page. Looks good. >> Patch 101: >> The `if role == 'ad':` block should rather be in the `Host.from_env` >> factory. >> > > Moved. Looks good. With my patches for #3890, this should use BaseHost.from_env. >> Patch 102: >> Thanks for cleaning that up! >> You could go one step further with >> cls.replicas = get_resources(domain.replicas, 'replicas', >> cls.num_replicas) >> and `return container[:num_needed]` there > > You're welcome, refactoring part expanded. Looks good. >> Patch 103: >> This patch should come before 101 which uses it. >> > > We can push this in the correct order if this is an issue, right? > Patches are independent (meaning they do not touch the same source code, > so they should apply cleanly). Sure. >> Ideally there would be a BaseHost with common functionality, and >> concrete Host and WinHost subclassing it. > > Yes, I agree, that's what we discussed. > >> I'll be making changes here for #3890; please concentrate on other >> parts for now to avoid conflicts. I'll take Windows hosts into >> consideration. My patches are on the list. Conflicts should be minimal; withthem WinHost should end up empty. >> Raise instances rather than the exception classes: raise >> NotImplementedError() > Fixed. >> Patch 104: [...] >> I'd prefer to keep the function in test_trust.py until we see there's >> a wider scope for it. >> And rename it to run_repeatedly or some other name that describes it >> better. >> > > I renamed the function. Thanks > Why do you think there's not scope for it? I'd rather keep it in tasks, > since it addresses > a general use case of waiting in a loop until a command returns expected > output. > > This can happen with any command that starts asynchronous actions and we > want to make > sure that the changes are propagated before continuing (such as DNS > updates via our CLI). > > I wouldn't consider this being specific for AD trust testing. I'd like to keep tasks to high-level operations, the kind that ipa-test-task would do. (Putting wait_for_replication there was, in hindsight, a mistake.) We can add an util module later. It's easy to move things to a shared module when needed, but if we do it too early and often the module will be hard to maintain. Predicting the future in this respect hasn't worked very well for me :) >> Patch 105: >> Please add these tasks to ipa-test-task (and its man page) as well. >> The instructions in the docstring in configure_dns_for_trust should go >> to a test design document. I think just starting a section in >> Integration_testing would be fine if you mark it as not implemented >> yet (and link to the ticket). This still needs some work (unfortunately I haven't found a way to make it less tedious). >> Use parentheses instead of \ for line continuation (see PEP8). > > I don't really like wrapping arbitrary expressions in parentheses, > particularly when assigning the result to a variable: > > result = (something or > something_completely_else) > > To me, the following looks better: > > result = something or \ > something completely else > > I checked with PEP8. I remember there was a section that backslash can > be used in cases it produces nicer results, but it's gone now. > Backslash is still recommended in some cases. > > Still (but no strong opinions here), I would not consider this a > violation unless it happens between brackets (in which case it is > redundant). Personal opinions aside, the PEP8 is pretty clear on this, sorry. It lists `with` and `assert` statements where you can't use parentheses around everything after the keyword, but that's not case here. >> Patch 106: >> The instructions in the TestADTrust docstring should go to a test >> design document. >> >> Please use the SID regex from a shared location. You'll need to assign >> it to a variable and make the Fuzzy from that, so that variable can be >> imported and used with the standard re module. >> > > This is something that I tried to address with the Fuzzy refactoring. > This is a temporary solution, once we resolve that patchset, of course, > the test will use the shared location. > I added a comment there, I'd rather not create conflicts. OK, let's worry about this later. [...] >> test_user_gid_uid_resolution_in_nonposix_trust: >> - For a one-off regex, compile() is unnecessary: >> assert re.search(testuser_regex, result.stdout_text) >> - Whenever substituting a literal string into a regex, please use >> re.escape(). >> > Fixed. Sorry, I meant non-literal and wrote exactly the opposite! This is suboptimal: self.ad.domain.name.replace('.', '\.') This is better: re.escape(self.ad.domain.name) > >> Use parentheses instead of \ for line continuation (see PEP8). >> >> > > Design will follow soon. Perfect! -- Petr? From abokovoy at redhat.com Thu Sep 19 19:08:37 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 Sep 2013 22:08:37 +0300 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains Message-ID: <20130919190837.GC4216@redhat.com> Hi! Attached patch adds IPA CLI to manage trust subdomains. ipa trust-domain-fetch -- fetch list of subdomains from AD side and add new ones to IPA ipa trust-domain-find -- show all available subdomains ipa trust-domain-del -- remove subdomain from IPA view about ipa trust-domain-mod -- modify subdomain parameters (work in progress) IPA KDC needs also information for authentication paths to subdomains in case they are not hierarchical under AD forest trust root. This information is managed via capaths section in krb5.conf. SSSD should be able to generate it once ticket https://fedorahosted.org/sssd/ticket/2093 is resolved. part of https://fedorahosted.org/freeipa/ticket/3909 The patch implements some dark magic to get around IPA framework limitations: -- CLI commands belong to 'trust' family but operate on 'subdomain' object -- 'subdomain' objects are stored under trust container, thus making container_dn dependent on a particular trust: cn=,cn=,cn=ad,cn=trusts,$SUFFIX The latter is a design decision since our KDC driver loads all objects with objectclass=ipaNTTrustedDomain from cn=ad,cn=trusts,$SUFFIX using subtree scope. With this design no changes were needed in ipa-kdb at all to support subdomains. -- / Alexander Bokovoy -------------- next part -------------- >From bf6145368cd517557f9839586cae32160291964e Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 18 Sep 2013 17:04:19 +0200 Subject: [PATCH 5/5] trusts: support subdomains in a forest Add IPA CLI to manage trust subdomains. ipa trust-domain-fetch -- fetch list of subdomains from AD side and add new ones to IPA ipa trust-domain-find -- show all available subdomains ipa trust-domain-del -- remove subdomain from IPA view about ipa trust-domain-mod -- modify subdomain parameters (work in progress) IPA KDC needs also information for authentication paths to subdomains in case they are not hierarchical under AD forest trust root. This information is managed via capaths section in krb5.conf. SSSD should be able to generate it once ticket https://fedorahosted.org/sssd/ticket/2093 is resolved. part of https://fedorahosted.org/freeipa/ticket/3909 --- API.txt | 67 ++++++++++++++++++ ipalib/plugins/trust.py | 176 +++++++++++++++++++++++++++++++++++++++++++++++- ipaserver/dcerpc.py | 54 +++++++++++++++ 3 files changed, 295 insertions(+), 2 deletions(-) diff --git a/API.txt b/API.txt index 761d1d1..a7c97e0 100644 --- a/API.txt +++ b/API.txt @@ -3423,6 +3423,73 @@ option: Str('version?', exclude='webui') output: Output('result', , None) output: Output('summary', (, ), None) output: Output('value', , None) +command: trust_domain_create +args: 2,9,3 +arg: Str('trust?') +arg: Str('cn?', cli_name='domain', primary_key=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('ipantflatname', attribute=True, cli_name='flat_name', multivalue=False, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, cli_name='sid', multivalue=False, required=False) +option: Str('ipanttrustpartner?') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', values=(u'ad',)) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trust_domain_del +args: 2,2,3 +arg: Str('trust?') +arg: Str('cn?', cli_name='domain', primary_key=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trust_domain_fetch +args: 1,4,2 +arg: Str('trust?') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +command: trust_domain_find +args: 2,8,4 +arg: Str('criteria?', noextrawhitespace=False) +arg: Str('trust?') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn?', cli_name='domain', primary_key=True) +option: Str('ipantflatname', attribute=True, autofill=False, cli_name='flat_name', multivalue=False, query=True, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='sid', multivalue=False, query=True, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: trust_domain_mod +args: 2,10,3 +arg: Str('trust?') +arg: Str('cn?', cli_name='domain', primary_key=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('ipantflatname', attribute=True, autofill=False, cli_name='flat_name', multivalue=False, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='sid', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', values=(u'ad',)) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('value', , None) command: trust_find args: 1,11,4 arg: Str('criteria?', noextrawhitespace=False) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 3c117b4..6ffe119 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -245,7 +245,7 @@ def make_trust_dn(env, trust_type, dn): assert isinstance(dn, DN) if trust_type in trust.trust_types: container_dn = DN(('cn', trust_type), env.container_trusts, env.basedn) - return DN(dn[0], container_dn) + return DN(dn, container_dn) return dn class trust_add(LDAPCreate): @@ -738,7 +738,7 @@ class trust_show(LDAPRetrieve): def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): assert isinstance(dn, DN) if 'trust_show_type' in options: - return make_trust_dn(self.env, options['trust_show_type'], dn) + return make_trust_dn(self.env, options['trust_show_type'], DN(dn[0])) return dn @@ -1078,3 +1078,175 @@ class sidgen_was_run(Command): return dict(result=True) api.register(sidgen_was_run) + +class subdomain(LDAPObject): + """ + Object representing a domain of the AD trust. + """ + trust_type_idx = {'2':u'ad'} + object_name = _('trust domain') + object_name_plural = _('trust domains') + object_class = ['ipaNTTrustedDomain'] + default_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', 'ipanttrustdirection', 'ipanttrustpartner'] + search_display_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', ] + + label = _('Trusted domains') + label_singular = _('Trusted domain') + + subdomain_args = ( + Str('trust?', + label=_('AD trust'), + flags=('virtual_attribute',), + ), + Str('cn?', + label=_('Domain name'), + cli_name='domain', + primary_key=True, + flags=('req_update','req_create',), + ), + ) + + takes_params = ( + Str('ipantflatname?', + cli_name='flat_name', + label=_('Domain NetBIOS name'), + ), + Str('ipanttrusteddomainsid?', + cli_name='sid', + label=_('Domain Security Identifier'), + ), + ) + + container_dn = api.env.container_trusts + def get_dn(self, *keys, **kwargs): + if len(keys) == 1: + return self.api.Object.trust.get_dn(*keys, **kwargs) + dn=make_trust_dn(self.env, getattr(kwargs, 'trust_type', u'ad'), DN(('cn', keys[1]), ('cn', keys[0]))) + return dn + +api.register(subdomain) + +class trust_domain_find(LDAPSearch): + __doc__ = _('Search subdomains of the trust') + + obj_name = 'subdomain' + + takes_args = subdomain.subdomain_args[0] + takes_options = LDAPSearch.takes_options + (subdomain.subdomain_args[1],) + def pre_callback(self, ldap, filters, attrs_list, base_dn, scope, *args, **options): + assert isinstance(base_dn, DN) + if not args[0]: + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name is required to search subdomains')) + + base_dn = DN(self.api.Command.trust_show(args[0])['result']['dn']) + return (filters, base_dn, ldap.SCOPE_SUBTREE) +api.register(trust_domain_find) + +class trust_domain_mod(LDAPUpdate): + __doc__ = _('Modify subdomain of the trust') + + obj_name = 'subdomain' + + takes_args = subdomain.subdomain_args + takes_options = LDAPUpdate.takes_options + (_trust_type_option,) + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + if len(keys) != 2: + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name and subdomain name are required to modify the subdomain')) + return dn +api.register(trust_domain_mod) + +class trust_domain_create(LDAPCreate): + __doc__ = _('Create subdomain of the trust') + NO_CLI = True + obj_name = 'subdomain' + + takes_args = subdomain.subdomain_args + takes_options = LDAPCreate.takes_options + (_trust_type_option, + Str('ipanttrustpartner?', + label=_('Trusted domain partner'), + ), + ) + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + if len(keys) != 2: + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name and subdomain name are required to create the subdomain')) + assert isinstance(dn, DN) + if 'ipanttrustpartner' in options: + entry_attrs['ipanttrustpartner'] = [options['ipanttrustpartner']] + self.log.error('trust_domain_create(%s,%s), entry attrs %s' % (keys,options,entry_attrs)) + return dn +api.register(trust_domain_create) + +class trust_domain_del(LDAPDelete): + __doc__ = _('Delete a subdomain of the trust.') + + obj_name = 'subdomain' + msg_summary = _('Deleted subdomain "%(value)s"') + + takes_args = subdomain.subdomain_args + def pre_callback(self, ldap, dn, *keys, **options): + if len(keys) != 2: + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name and subdomain name are required to delete the subdomain')) + try: + result = self.api.Command.trust_show(keys[0], raw=True) + except errors.NotFound, e: + self.obj.handle_not_found(*keys) + options['trust_type'] = self.obj.trust_type_idx[result['result']['ipanttrusttype'][0]] + return make_trust_dn(self.env, options['trust_type'], DN(('cn', keys[1]), ('cn', keys[0]))) +api.register(trust_domain_del) + +class trust_domain_fetch(LDAPRetrieve): + __doc__ = _('Refresh list of subdomains associated with the trust') + obj_name = 'subdomain' + + takes_args = (subdomain.subdomain_args[0]) + + has_output = ( + output.ListOfEntries('result'), + output.summary + ) + def execute(self, *keys, **options): + if not _bindings_installed: + raise errors.NotFound( + name=_('AD Trust setup'), + reason=_( + 'Cannot perform join operation without Samba 4 support ' + 'installed. Make sure you have installed server-trust-ad ' + 'sub-package of IPA' + ) + ) + if len(keys) != 1: + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name is required to search subdomains')) + + trust = self.api.Command.trust_show(keys[0], raw=True)['result'] + + trustinstance = ipaserver.dcerpc.TrustDomainJoins(self.api) + if not trustinstance.configured: + raise errors.NotFound( + name=_('AD Trust setup'), + reason=_( + 'Cannot perform join operation without own domain ' + 'configured. Make sure you have run ipa-adtrust-install ' + 'on the IPA server first' + ) + ) + domains = ipaserver.dcerpc.fetch_domains(self.api, trustinstance.local_flatname, trust['cn'][0]) + result = dict(result=[]) + if not domains: + result['summary'] = unicode(_('No sudomains were detected during refresh')) + return result + + for dom in domains: + dom['trust_type'] = self.obj.trust_type_idx[trust['ipanttrusttype'][0]] + try: + res = self.api.Command.trust_domain_create(trust['cn'][0], **dom) + result['result'].append(res['result']) + except errors.DuplicateEntry: + # Ignore updating duplicate entries + pass + if len(result['result']) > 0: + result['summary'] = unicode(_('Subdomains successfully refreshed')) + else: + result['summary'] = unicode(_('No new subdomains were found')) + return result +api.register(trust_domain_fetch) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 33e7e07..fcfedc4 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -992,6 +992,60 @@ class TrustDomainInstance(object): return True return False +def fetch_domains(api, mydomain, trustdomain): + trust_flags = dict( + NETR_TRUST_FLAG_IN_FOREST = 0x00000001, + NETR_TRUST_FLAG_OUTBOUND = 0x00000002, + NETR_TRUST_FLAG_TREEROOT = 0x00000004, + NETR_TRUST_FLAG_PRIMARY = 0x00000008, + NETR_TRUST_FLAG_NATIVE = 0x00000010, + NETR_TRUST_FLAG_INBOUND = 0x00000020, + NETR_TRUST_FLAG_MIT_KRB5 = 0x00000080, + NETR_TRUST_FLAG_AES = 0x00000100) + + trust_attributes = dict( + NETR_TRUST_ATTRIBUTE_NON_TRANSITIVE = 0x00000001, + NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x00000002, + NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x00000004, + NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x00000008, + NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x00000010, + NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x00000020, + NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x00000040) + + domval = DomainValidator(api) + (ccache_name, principal) = domval.kinit_as_http(trustdomain) + if ccache_name: + with installutils.private_ccache(path=ccache_name): + td = TrustDomainInstance('') + td.parm.set('workgroup', mydomain) + td.creds = credentials.Credentials() + td.creds.set_kerberos_state(credentials.MUST_USE_KERBEROS) + td.creds.guess(td.parm) + netrc = net.Net(creds=td.creds, lp=td.parm) + try: + result = netrc.finddc(domain=trustdomain, flags=nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_DS) + except RuntimeError, e: + raise assess_dcerpc_exception(message=str(e)) + if not result: + return None + td.retrieve(unicode(result.pdc_dns_name)) + + netr_pipe = netlogon.netlogon(td.binding, td.parm, td.creds) + domains = netr_pipe.netr_DsrEnumerateDomainTrusts(td.binding, 1) + + result = [] + for t in domains.array: + if ((t.trust_attributes & trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and + (t.trust_flags & trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): + res = dict() + res['cn'] = unicode(t.dns_name) + res['ipantflatname'] = unicode(t.netbios_name) + res['ipanttrusteddomainsid'] = unicode(t.sid) + res['ipanttrustpartner'] = res['cn'] + result.append(res) + return result + + class TrustDomainJoins(object): def __init__(self, api): self.api = api -- 1.8.3.1 From abokovoy at redhat.com Thu Sep 19 19:17:07 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 Sep 2013 22:17:07 +0300 Subject: [Freeipa-devel] [PATCH 110] ipa-sam: Fix memory leaks In-Reply-To: <523ACB51.3020903@redhat.com> References: <523ACB51.3020903@redhat.com> Message-ID: <20130919191707.GD4216@redhat.com> On Thu, 19 Sep 2013, Tomas Babej wrote: > Hi, > > this fixes a memory leak in ipa-sam plugin. > > https://fedorahosted.org/freeipa/ticket/3913 This patch is in conflict with my patch 0115 because I already fixed these leaks in 0114-0116 series. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Sep 19 19:18:57 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 19 Sep 2013 22:18:57 +0300 Subject: [Freeipa-devel] [PATCH] 0117 ipaserver/dcerpc.py: populate forest trust information In-Reply-To: <20130912131401.GI21212@redhat.com> References: <20130912131401.GI21212@redhat.com> Message-ID: <20130919191857.GE4216@redhat.com> On Thu, 12 Sep 2013, Alexander Bokovoy wrote: > Hi! > > Attached patch does the magic of enabling all domains associated with > our realm in AD when we establish the trust relationship. > > LsarSetForestTrustInformation RPC call is used to set the forest trust > information. Currently only top level names are exposed as we don't have > any domain name/SID/NetBIOS exclusion support yet. I decided to avoid > updating full TDO object as there is some problem with memory handling > of a domain sid object in lsa.ForestTrustRecord Python binding for that > type -- even assigned value gets immediately destroyed unless I > ndr_print the record. > > The patch also moves string_to_array() helper to the top level as it is > useful for quite few RPC calls where instead of a structured record one > needs to use ndr_pack() and string_to_array() of the result. While it is > not used right now, there will be updates coming related to subdomains > handling that will require it anyway. > > https://fedorahosted.org/freeipa/ticket/3919 Patch updated with few more fixes found by pylint and code simplification. -- / Alexander Bokovoy -------------- next part -------------- >From d850941399811a98ed68e77438b3c67412f5e99d Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 11 Sep 2013 21:34:55 +0300 Subject: [PATCH 4/5] ipaserver/dcerpc.py: populate forest trust information using realmdomains Use realmdomains information to prepopulate forest trust info. As result, all additional domains should now be enabled from the beginning, unless they really conflict with existing DNS domains on AD side. --- ipaserver/dcerpc.py | 72 +++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 65 insertions(+), 7 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index bd8f5aa..33e7e07 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -698,6 +698,7 @@ class TrustDomainInstance(object): self._pipe = None self._policy_handle = None self.read_only = False + self.ftinfo_records = None def __gen_lsa_connection(self, binding): if self.creds is None: @@ -876,6 +877,41 @@ class TrustDomainInstance(object): self.auth_info = auth_info + def generate_ftinfo(self, another_domain): + """ + Generates TrustDomainInfoFullInfo2Internal structure + This structure allows to pass informationa bout all domains associated + with our realm. + """ + info = lsa.TrustDomainInfoFullInfo2Internal() + info.info_ex.domain_name.string = another_domain.info['dns_domain'] + info.info_ex.netbios_name.string = another_domain.info['name'] + info.info_ex.sid = security.dom_sid(another_domain.info['sid']) + info.info_ex.trust_direction = lsa.LSA_TRUST_DIRECTION_INBOUND | lsa.LSA_TRUST_DIRECTION_OUTBOUND + info.info_ex.trust_type = lsa.LSA_TRUST_TYPE_UPLEVEL + info.info_ex.trust_attributes = lsa.LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE + + ftinfo = drsblobs.ForestTrustInfo() + ftinfo.version = 1 + ftinfo_records = [] + + for rec in self.ftinfo_records: + record = drsblobs.ForestTrustInfoRecordArmor() + record.record.flags = 0 + record.record.timestamp = 0 + record.record.type = rec['rec_type'] + if rec.rec_type in [1,2]: + record.record.data.name.string = rec['rec_name'] + elif rec.rec_type == 2: + record.record.data.info.sid = rec['rec_sid'] + record.record.data.info.dns_name.string = rec['rec_name'] + record.record.data.info.netbios_name.string = rec['rec_nbtname'] + ftinfo_records.append(record) + + ftinfo.records = ftinfo_records + info.forest_trust_data = ndr_pack(ftinfo) + return info + def establish_trust(self, another_domain, trustdom_secret): """ @@ -885,13 +921,17 @@ class TrustDomainInstance(object): """ self.generate_auth(trustdom_secret) - info = lsa.TrustDomainInfoInfoEx() - info.domain_name.string = another_domain.info['dns_domain'] - info.netbios_name.string = another_domain.info['name'] - info.sid = security.dom_sid(another_domain.info['sid']) - info.trust_direction = lsa.LSA_TRUST_DIRECTION_INBOUND | lsa.LSA_TRUST_DIRECTION_OUTBOUND - info.trust_type = lsa.LSA_TRUST_TYPE_UPLEVEL - info.trust_attributes = lsa.LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE + + if self.ftinfo_records: + info = self.generate_ftinfo(another_domain) + else: + info = lsa.TrustDomainInfoInfoEx() + info.domain_name.string = another_domain.info['dns_domain'] + info.netbios_name.string = another_domain.info['name'] + info.sid = security.dom_sid(another_domain.info['sid']) + info.trust_direction = lsa.LSA_TRUST_DIRECTION_INBOUND | lsa.LSA_TRUST_DIRECTION_OUTBOUND + info.trust_type = lsa.LSA_TRUST_TYPE_UPLEVEL + info.trust_attributes = lsa.LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE if self.info['name'] == info.netbios_name.string: # Check that NetBIOS names do not clash @@ -1016,6 +1056,23 @@ class TrustDomainJoins(object): # Otherwise, use anonymously obtained data self.remote_domain = rd + def get_realmdomains(self): + if self.remote_domain.read_only: + return + realm_domains = self.api.Command.realmdomains_show()['result']['associateddomain'] + trustconfig = self.api.Command.trustconfig_show()['result'] + for dom in realm_domains: + ftinfo = dict() + ftinfo['rec_name'] = dom + if dom == trustconfig['cn'][0]: + ftinfo['rec_type'] = drsblobs.FOREST_TRUST_DOMAIN_INFO + ftinfo['rec_sid'] = security.dom_sid(trustconfig['ipantsecurityidentifier']) + ftinfo['rec_nbtname'] = trustconfig['ipantflatname'] + else: + ftinfo['rec_type'] = drsblobs.FOREST_TRUST_TOP_LEVEL_NAME + self.remote_domain.ftinfo_records.append(ftinfo) + + def join_ad_full_credentials(self, realm, realm_server, realm_admin, realm_passwd): if not self.configured: return None @@ -1030,6 +1087,7 @@ class TrustDomainJoins(object): if not self.remote_domain.read_only: trustdom_pass = samba.generate_random_password(128, 128) + self.get_realmdomains() self.remote_domain.establish_trust(self.local_domain, trustdom_pass) self.local_domain.establish_trust(self.remote_domain, trustdom_pass) result = self.remote_domain.verify_trust(self.local_domain) -- 1.8.3.1 From jcholast at redhat.com Fri Sep 20 07:19:17 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 20 Sep 2013 09:19:17 +0200 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <20130919190837.GC4216@redhat.com> References: <20130919190837.GC4216@redhat.com> Message-ID: <523BF6F5.1040803@redhat.com> On 19.9.2013 21:08, Alexander Bokovoy wrote: > Hi! > > Attached patch adds IPA CLI to manage trust subdomains. > > ipa trust-domain-fetch -- fetch list of subdomains from AD > side and add new ones to IPA > ipa trust-domain-find -- show all available subdomains ipa > trust-domain-del -- remove subdomain from IPA view > about > ipa trust-domain-mod -- modify subdomain parameters > (work in progress) > > IPA KDC needs also information for authentication paths to subdomains in > case they are not hierarchical under AD forest trust root. This > information is managed via capaths section in krb5.conf. SSSD should be > able to generate it once ticket > https://fedorahosted.org/sssd/ticket/2093 is resolved. > > part of https://fedorahosted.org/freeipa/ticket/3909 > > The patch implements some dark magic to get around IPA framework > limitations: > > -- CLI commands belong to 'trust' family but operate on 'subdomain' > object > -- 'subdomain' objects are stored under trust container, thus making > container_dn dependent on a particular trust: > cn=,cn=,cn=ad,cn=trusts,$SUFFIX > > The latter is a design decision since our KDC driver loads all objects > with objectclass=ipaNTTrustedDomain from cn=ad,cn=trusts,$SUFFIX using > subtree scope. With this design no changes were needed in ipa-kdb at all > to support subdomains. > NACK, this patch breaks several conventions we use in the framework: 1) The object is named "subdomain", but the commands are named "trust_domain_*". Please use the object name as the base for command names. I would suggest renaming the object to "trustdomain", as the framework does not allow underscores in object names, and "subdomain" sounds a little bit too generic. 2) There is already support for objects inside objects in the framework, there's no need to reinvent this. See the parent_object attribute of LDAPObject and the dns plugin for practical example. 3) Create commands are usually named "*_add", not "*_create". 4) The "trust_domain_fetch" command gives the impression it operates on top of a trust domain, but it actually operates on top of a trust. I think it should be renamed to better reflect this. Honza -- Jan Cholasta From tbabej at redhat.com Fri Sep 20 07:23:22 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 20 Sep 2013 09:23:22 +0200 Subject: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created In-Reply-To: <20130911191234.GH21212@redhat.com> References: <20130905144406.GO21212@redhat.com> <1378565247.2804.1125.camel@willson.li.ssimo.org> <20130907180158.GU21212@redhat.com> <1378578185.2804.1353.camel@willson.li.ssimo.org> <20130907183259.GV21212@redhat.com> <1378579277.2804.1360.camel@willson.li.ssimo.org> <20130910163137.GA21212@redhat.com> <1378907502.2804.1589.camel@willson.li.ssimo.org> <20130911191234.GH21212@redhat.com> Message-ID: <523BF7EA.9080301@redhat.com> On 09/11/2013 09:12 PM, Alexander Bokovoy wrote: > On Wed, 11 Sep 2013, Simo Sorce wrote: >> On Tue, 2013-09-10 at 19:31 +0300, Alexander Bokovoy wrote: >>> On Sat, 07 Sep 2013, Simo Sorce wrote: >>> >On Sat, 2013-09-07 at 21:32 +0300, Alexander Bokovoy wrote: >>> >> On Sat, 07 Sep 2013, Simo Sorce wrote: >>> >> >On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: >>> >> >> On Sat, 07 Sep 2013, Simo Sorce wrote: >>> >> >> >On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: >>> >> >> >> + enctypes = KERB_ENCTYPE_DES_CBC_CRC | >>> >> >> >> + KERB_ENCTYPE_DES_CBC_MD5 | >>> >> >> >> + KERB_ENCTYPE_RC4_HMAC_MD5 | >>> >> >> >> + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | >>> >> >> >> + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; >>> >> >> > >>> >> >> >Why are we hardcoding support for *DES* enctype, we disable >>> DES by >>> >> >> >default and also Windows never uses it by default. >>> >> >> This is actually a copy of the same statement from >>> >> >> fill_pdb_trusted_domain(). >>> >> >> >>> >> >> Should I remove it? >>> >> > >>> >> >Yes please remove DES types, is there any chance we can make >>> this list >>> >> >configurable ? (not a hard requirement, only if ti is something >>> easy to >>> >> >do, maybe as a further enhancement down the road). >>> >> If you can point me to some place in cn=config or $SUFFIX that >>> could be >>> >> read by cifs/fqdn on ipa-sam module init, I can look in fetching >>> that. >>> >> But I suspect it is much harder to deduce exact list of supported >>> types. >>> > >>> >Look in: >>> >cn=REALM.NAME,cn=kerberos,$SUFFIX >>> > >>> >there we have 2 lists: >>> >krbDefaultEncSaltTypes <- use this >>> >krbSupportedEncSaltTypes >>> > >>> >in util/ipa_krb5.c we have then the funciton >>> parse_bval_key_sal_tuples() >>> >that can covert strings to enctypes. >>> > >>> >> >> RC4 enctype will be the only one available for >>> >> >> Windows 2003 trusts then... >>> >> > >>> >> >It's the only one 2003 enables by default anyway and the only >>> one that >>> >> >we can use as DES is disabled on FreeIPA. >>> >> Since admin could enable DES on FreeIPA manually, right now ipa-sam >>> >> would allow using DES to Windows 2003. If we remove DES enctypes >>> >> unconditionally, it would not be possible. >>> > >>> >If you look at the attributes I pointed you at above, then you have a >>> >way to support DES by simply changing the defaults and restarting >>> >FreeIPA. >>> > >>> >DES is dead anyway and not sufficiently secure for cross-realm keys >>> >anymore, even if we do not support it at all I think we are just fine. >>> Ok, attached three patches 0114-0116 is a new revision that >>> implements also >>> fetching encryption types from the Kerberos configuration container. >>> >>> The patches depend on each other in that order. >>> >> >> I think you should explictly add cn= to the filter when >> seraching the kerberos container in the 3rd patch. >> But beyond that the patches look sane to me (I haven't tested them >> though). > I'm already searching on cn=,cn=kerberos,$SUFFIX with a base > scope so this is pretty tight, no need to expand the filter. > > (Simo agreed to this argument on IRC) > ACK -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From abokovoy at redhat.com Fri Sep 20 07:36:06 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 20 Sep 2013 10:36:06 +0300 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <523BF6F5.1040803@redhat.com> References: <20130919190837.GC4216@redhat.com> <523BF6F5.1040803@redhat.com> Message-ID: <20130920073606.GF4216@redhat.com> On Fri, 20 Sep 2013, Jan Cholasta wrote: >On 19.9.2013 21:08, Alexander Bokovoy wrote: >>Hi! >> >>Attached patch adds IPA CLI to manage trust subdomains. >> >>ipa trust-domain-fetch -- fetch list of subdomains from AD >>side and add new ones to IPA >>ipa trust-domain-find -- show all available subdomains ipa >>trust-domain-del -- remove subdomain from IPA view >>about >>ipa trust-domain-mod -- modify subdomain parameters >>(work in progress) >> >>IPA KDC needs also information for authentication paths to subdomains in >>case they are not hierarchical under AD forest trust root. This >>information is managed via capaths section in krb5.conf. SSSD should be >>able to generate it once ticket >>https://fedorahosted.org/sssd/ticket/2093 is resolved. >> >>part of https://fedorahosted.org/freeipa/ticket/3909 >> >>The patch implements some dark magic to get around IPA framework >>limitations: >> >> -- CLI commands belong to 'trust' family but operate on 'subdomain' >>object >> -- 'subdomain' objects are stored under trust container, thus making >> container_dn dependent on a particular trust: >> cn=,cn=,cn=ad,cn=trusts,$SUFFIX >> >>The latter is a design decision since our KDC driver loads all objects >>with objectclass=ipaNTTrustedDomain from cn=ad,cn=trusts,$SUFFIX using >>subtree scope. With this design no changes were needed in ipa-kdb at all >>to support subdomains. >> > >NACK, this patch breaks several conventions we use in the framework: Have you read the reasoning first? >1) The object is named "subdomain", but the commands are named >"trust_domain_*". Please use the object name as the base for command >names. I would suggest renaming the object to "trustdomain", as the >framework does not allow underscores in object names, and "subdomain" >sounds a little bit too generic. subdomains as objects are not visible to users. Users cannot operate on subdomains themselves. I do not want to give you impression we are having separate trust and domains. Instead, we deal with trusts and subdomains are simply internal components of it. The fact that you currently see these commands in 'ipa trust-*' family reflects the situation. -mod command is intended to be internal as well, it will not be visible in CLI in the end. The only command available to users will be 'ipa trust-domain-fetch'. >2) There is already support for objects inside objects in the >framework, there's no need to reinvent this. See the parent_object >attribute of LDAPObject and the dns plugin for practical example. It does not work in this case properly. Feel free to try to implement it, really. I have spent good deal of last two weeks trying all options possible. > >3) Create commands are usually named "*_add", not "*_create". The command is internal, see NO_CLI there. I'm not tied to particular naming but it is not visible to users. >4) The "trust_domain_fetch" command gives the impression it operates >on top of a trust domain, but it actually operates on top of a trust. >I think it should be renamed to better reflect this. It operates on the trust. We don't have 'trust domains' at all. We have trusts and always had only trusts. Subdomains represent internal structure of the trust which is only visible to user for diagnostic purposes but practically users will not be able to modify them, only reference them for idranges. -- / Alexander Bokovoy From pviktori at redhat.com Fri Sep 20 07:57:46 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 20 Sep 2013 09:57:46 +0200 Subject: [Freeipa-devel] [PATCH 109] Use getent admin@domain for nss check in, ipa-client-install In-Reply-To: <523B0D00.7000501@redhat.com> References: <523ACAF8.5010802@redhat.com> <523B0B2A.5070206@redhat.com> <523B0D00.7000501@redhat.com> Message-ID: <523BFFFA.4050501@redhat.com> On 09/19/2013 04:41 PM, Ana Krivokapic wrote: > On 09/19/2013 04:33 PM, Tomas Babej wrote: >> On 09/19/2013 11:59 AM, Tomas Babej wrote: >>> Hi, >>> >>> Use 'getent admin at domain' rather than 'getent admin at REALM' to check >>> if nss >>> is working properly since admin at REALM check fails in case the domain >>> and the realm >>> name does not match. >>> >>> https://fedorahosted.org/freeipa/ticket/3906 >>> >>> >> >> Thanks to Ana for telling me I basically copied Stephen's patch: >> >> https://www.redhat.com/archives/freeipa-devel/2013-September/msg00085.html >> >> >> And I did the same mistake. Fixed patched attached. >> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK > Pushed to: master: 316a9c215982527814089dc02be95fe14e635006 ipa-3-3: b0b7335cbaf104ba582c12b49e908c280d332cf6 -- Petr? From pviktori at redhat.com Fri Sep 20 08:04:00 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 20 Sep 2013 10:04:00 +0200 Subject: [Freeipa-devel] [PATCH] 0114 ipa-sam: fix setting encryption type for trust object already created In-Reply-To: <523BF7EA.9080301@redhat.com> References: <20130905144406.GO21212@redhat.com> <1378565247.2804.1125.camel@willson.li.ssimo.org> <20130907180158.GU21212@redhat.com> <1378578185.2804.1353.camel@willson.li.ssimo.org> <20130907183259.GV21212@redhat.com> <1378579277.2804.1360.camel@willson.li.ssimo.org> <20130910163137.GA21212@redhat.com> <1378907502.2804.1589.camel@willson.li.ssimo.org> <20130911191234.GH21212@redhat.com> <523BF7EA.9080301@redhat.com> Message-ID: <523C0170.5060905@redhat.com> On 09/20/2013 09:23 AM, Tomas Babej wrote: > On 09/11/2013 09:12 PM, Alexander Bokovoy wrote: >> On Wed, 11 Sep 2013, Simo Sorce wrote: >>> On Tue, 2013-09-10 at 19:31 +0300, Alexander Bokovoy wrote: >>>> On Sat, 07 Sep 2013, Simo Sorce wrote: >>>> >On Sat, 2013-09-07 at 21:32 +0300, Alexander Bokovoy wrote: >>>> >> On Sat, 07 Sep 2013, Simo Sorce wrote: >>>> >> >On Sat, 2013-09-07 at 21:01 +0300, Alexander Bokovoy wrote: >>>> >> >> On Sat, 07 Sep 2013, Simo Sorce wrote: >>>> >> >> >On Thu, 2013-09-05 at 17:44 +0300, Alexander Bokovoy wrote: >>>> >> >> >> + enctypes = KERB_ENCTYPE_DES_CBC_CRC | >>>> >> >> >> + KERB_ENCTYPE_DES_CBC_MD5 | >>>> >> >> >> + KERB_ENCTYPE_RC4_HMAC_MD5 | >>>> >> >> >> + KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 | >>>> >> >> >> + KERB_ENCTYPE_AES256_CTS_HMAC_SHA1_96; >>>> >> >> > >>>> >> >> >Why are we hardcoding support for *DES* enctype, we disable >>>> DES by >>>> >> >> >default and also Windows never uses it by default. >>>> >> >> This is actually a copy of the same statement from >>>> >> >> fill_pdb_trusted_domain(). >>>> >> >> >>>> >> >> Should I remove it? >>>> >> > >>>> >> >Yes please remove DES types, is there any chance we can make >>>> this list >>>> >> >configurable ? (not a hard requirement, only if ti is something >>>> easy to >>>> >> >do, maybe as a further enhancement down the road). >>>> >> If you can point me to some place in cn=config or $SUFFIX that >>>> could be >>>> >> read by cifs/fqdn on ipa-sam module init, I can look in fetching >>>> that. >>>> >> But I suspect it is much harder to deduce exact list of supported >>>> types. >>>> > >>>> >Look in: >>>> >cn=REALM.NAME,cn=kerberos,$SUFFIX >>>> > >>>> >there we have 2 lists: >>>> >krbDefaultEncSaltTypes <- use this >>>> >krbSupportedEncSaltTypes >>>> > >>>> >in util/ipa_krb5.c we have then the funciton >>>> parse_bval_key_sal_tuples() >>>> >that can covert strings to enctypes. >>>> > >>>> >> >> RC4 enctype will be the only one available for >>>> >> >> Windows 2003 trusts then... >>>> >> > >>>> >> >It's the only one 2003 enables by default anyway and the only >>>> one that >>>> >> >we can use as DES is disabled on FreeIPA. >>>> >> Since admin could enable DES on FreeIPA manually, right now ipa-sam >>>> >> would allow using DES to Windows 2003. If we remove DES enctypes >>>> >> unconditionally, it would not be possible. >>>> > >>>> >If you look at the attributes I pointed you at above, then you have a >>>> >way to support DES by simply changing the defaults and restarting >>>> >FreeIPA. >>>> > >>>> >DES is dead anyway and not sufficiently secure for cross-realm keys >>>> >anymore, even if we do not support it at all I think we are just fine. >>>> Ok, attached three patches 0114-0116 is a new revision that >>>> implements also >>>> fetching encryption types from the Kerberos configuration container. >>>> >>>> The patches depend on each other in that order. >>>> >>> >>> I think you should explictly add cn= to the filter when >>> seraching the kerberos container in the 3rd patch. >>> But beyond that the patches look sane to me (I haven't tested them >>> though). >> I'm already searching on cn=,cn=kerberos,$SUFFIX with a base >> scope so this is pretty tight, no need to expand the filter. >> >> (Simo agreed to this argument on IRC) >> > > ACK > Pushed to: master: a9843d6918f73c2236d0083b1e8adf54ca34eb0d ipa-3-3: de5ec4fbd916c52e7474f1e4dae3b69c80eb497a -- Petr? From akrivoka at redhat.com Fri Sep 20 10:36:23 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 20 Sep 2013 12:36:23 +0200 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: References: <523200E9.5010304@redhat.com> <523AFBA2.9070000@redhat.com> <523AFF92.6070805@redhat.com> Message-ID: <523C2527.9040700@redhat.com> On 09/19/2013 07:34 PM, JR Aquino wrote: > Does the rebuild support the notion of members belonging to multiple groups via automember rules? Yes, all memberships are rebuilt. > > "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 19, 2013, at 6:43 AM, Ana Krivokapic > wrote: > > On 09/19/2013 03:26 PM, Jan Cholasta wrote: > Hi, > > On 12.9.2013 19:59, Ana Krivokapic wrote: > Hello, > > The design document for $SUBJECT can be found at: > http://www.freeipa.org/page/V3/Automember_rebuild_membership > > Related tickets: > https://fedorahosted.org/freeipa/ticket/3752 > https://fedorahosted.org/freeipa/ticket/3928 > > Thoughts, comments, questions welcome. > > > I don't think naming the commands user-automember-rebuild and > host-automember-rebuild commands is correct. The names imply they are methods > of user/host, but they don't directly do anything to user/host objects. I > would prefer if they were kept in the automember namespace where they > logically belong (automember-rebuild-user and automember-rebuild-host perhaps?) > > Honza > > > That makes sense... I don't have a strong preference one way or other. So if > other agree with this suggestion, I will change it. > > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From jcholast at redhat.com Fri Sep 20 10:39:41 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 20 Sep 2013 12:39:41 +0200 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <20130920073606.GF4216@redhat.com> References: <20130919190837.GC4216@redhat.com> <523BF6F5.1040803@redhat.com> <20130920073606.GF4216@redhat.com> Message-ID: <523C25ED.3010702@redhat.com> On 20.9.2013 09:36, Alexander Bokovoy wrote: > On Fri, 20 Sep 2013, Jan Cholasta wrote: >> On 19.9.2013 21:08, Alexander Bokovoy wrote: >>> Hi! >>> >>> Attached patch adds IPA CLI to manage trust subdomains. >>> >>> ipa trust-domain-fetch -- fetch list of subdomains from AD >>> side and add new ones to IPA >>> ipa trust-domain-find -- show all available subdomains ipa >>> trust-domain-del -- remove subdomain from IPA view >>> about >>> ipa trust-domain-mod -- modify subdomain parameters >>> (work in progress) >>> >>> IPA KDC needs also information for authentication paths to subdomains in >>> case they are not hierarchical under AD forest trust root. This >>> information is managed via capaths section in krb5.conf. SSSD should be >>> able to generate it once ticket >>> https://fedorahosted.org/sssd/ticket/2093 is resolved. >>> >>> part of https://fedorahosted.org/freeipa/ticket/3909 >>> >>> The patch implements some dark magic to get around IPA framework >>> limitations: >>> >>> -- CLI commands belong to 'trust' family but operate on 'subdomain' >>> object >>> -- 'subdomain' objects are stored under trust container, thus making >>> container_dn dependent on a particular trust: >>> cn=,cn=,cn=ad,cn=trusts,$SUFFIX >>> >>> The latter is a design decision since our KDC driver loads all objects >>> with objectclass=ipaNTTrustedDomain from cn=ad,cn=trusts,$SUFFIX using >>> subtree scope. With this design no changes were needed in ipa-kdb at all >>> to support subdomains. >>> >> >> NACK, this patch breaks several conventions we use in the framework: > Have you read the reasoning first? Yes. > >> 1) The object is named "subdomain", but the commands are named >> "trust_domain_*". Please use the object name as the base for command >> names. I would suggest renaming the object to "trustdomain", as the >> framework does not allow underscores in object names, and "subdomain" >> sounds a little bit too generic. > subdomains as objects are not visible to users. Users cannot operate on > subdomains themselves. I do not want to give you impression we are > having separate trust and domains. Instead, we deal with trusts and > subdomains are simply internal components of it. They are part of the API, whether they are visible to users or not, and they should follow the same convention as the rest of the API. From the framework perspective, subdomains are child objects of trusts, no different to how DNS records are child objects of DNS zones, except they are internal and not visible to users. You even implemented them this way in the patch, I just don't like how hackily it is done. > > The fact that you currently see these commands in 'ipa trust-*' family > reflects the situation. -mod command is intended to be internal as well, > it will not be visible in CLI in the end. The only command available to > users will be 'ipa trust-domain-fetch'. All the more reason for following the usual convention. > >> 2) There is already support for objects inside objects in the >> framework, there's no need to reinvent this. See the parent_object >> attribute of LDAPObject and the dns plugin for practical example. > It does not work in this case properly. Feel free to try to implement > it, really. I have spent good deal of last two weeks trying all options > possible. Why does it not work? The functionality of parent_object is pretty straightforward, so I can't imagine what might go wrong. >> >> 3) Create commands are usually named "*_add", not "*_create". > The command is internal, see NO_CLI there. I'm not tied to particular > naming but it is not visible to users. > >> 4) The "trust_domain_fetch" command gives the impression it operates >> on top of a trust domain, but it actually operates on top of a trust. >> I think it should be renamed to better reflect this. > It operates on the trust. We don't have 'trust domains' at all. We have > trusts and always had only trusts. Subdomains represent internal > structure of the trust which is only visible to user for diagnostic > purposes but practically users will not be able to modify them, only > reference them for idranges. Again, it doesn't matter whether it's internal or not, it should still follow the usual convention, for consistency, maintainability and code readability. If trust_domain_fetch is the only one visible to users, I guess there's no harm in keeping the name. Honza -- Jan Cholasta From abokovoy at redhat.com Fri Sep 20 10:55:16 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 20 Sep 2013 13:55:16 +0300 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <523C25ED.3010702@redhat.com> References: <20130919190837.GC4216@redhat.com> <523BF6F5.1040803@redhat.com> <20130920073606.GF4216@redhat.com> <523C25ED.3010702@redhat.com> Message-ID: <20130920105516.GH4216@redhat.com> On Fri, 20 Sep 2013, Jan Cholasta wrote: >>>>part of https://fedorahosted.org/freeipa/ticket/3909 >>>> >>>>The patch implements some dark magic to get around IPA framework >>>>limitations: >>>> >>>> -- CLI commands belong to 'trust' family but operate on 'subdomain' >>>>object >>>> -- 'subdomain' objects are stored under trust container, thus making >>>> container_dn dependent on a particular trust: >>>> cn=,cn=,cn=ad,cn=trusts,$SUFFIX >>>> >>>>The latter is a design decision since our KDC driver loads all objects >>>>with objectclass=ipaNTTrustedDomain from cn=ad,cn=trusts,$SUFFIX using >>>>subtree scope. With this design no changes were needed in ipa-kdb at all >>>>to support subdomains. >>>> >>> >>>NACK, this patch breaks several conventions we use in the framework: >>Have you read the reasoning first? > >Yes. > >> >>>1) The object is named "subdomain", but the commands are named >>>"trust_domain_*". Please use the object name as the base for command >>>names. I would suggest renaming the object to "trustdomain", as the >>>framework does not allow underscores in object names, and "subdomain" >>>sounds a little bit too generic. >>subdomains as objects are not visible to users. Users cannot operate on >>subdomains themselves. I do not want to give you impression we are >>having separate trust and domains. Instead, we deal with trusts and >>subdomains are simply internal components of it. > >They are part of the API, whether they are visible to users or not, >and they should follow the same convention as the rest of the API. > >From the framework perspective, subdomains are child objects of >trusts, no different to how DNS records are child objects of DNS >zones, except they are internal and not visible to users. You even >implemented them this way in the patch, I just don't like how hackily >it is done. The difference is that with DNS records and zones you have explicit mapping -- record is under zone and zone is under dns container. The DN is explicitly defined by input under static DNS container DN. With trusts there are few possible containers and input does not define the DN fully. We have trust type which means whenever trust is created, type is either default or explicitly set, yet for any other operation on the trust its type is not specified and has to be looked up. With subdomains under trusts we get another level of indirection. Had subdomains and trusts be based on a static DN, it could have worked. However, we don't have trust type available so it needs to discovered every time. This doesn't play well with the framework, it is simply not expecting dynamic containers. >>The fact that you currently see these commands in 'ipa trust-*' family >>reflects the situation. -mod command is intended to be internal as well, >>it will not be visible in CLI in the end. The only command available to >>users will be 'ipa trust-domain-fetch'. > >All the more reason for following the usual convention. I don't follow you here. With a single visible command added to the trust family why it should be 'ipa trustdomain-fetch' instead of 'ipa trust-domain-fetch'? What is the reason for inconsistency. Current way framework lays down object-verb system is due to implementation convenience, not because this is a really required from CLI point of view. I believe I have reasonable arguments to not fall into trap of having multiple objects visible to CLI. CLI should be simple to use, it should not expose too much of internal complexity where not required. >>>2) There is already support for objects inside objects in the >>>framework, there's no need to reinvent this. See the parent_object >>>attribute of LDAPObject and the dns plugin for practical example. >>It does not work in this case properly. Feel free to try to implement >>it, really. I have spent good deal of last two weeks trying all options >>possible. > >Why does it not work? The functionality of parent_object is pretty >straightforward, so I can't imagine what might go wrong. See above. It is not designed for the use case of dynamic container DNs which involves components not derived from the input. -- / Alexander Bokovoy From jcholast at redhat.com Fri Sep 20 11:59:10 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 20 Sep 2013 13:59:10 +0200 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <20130920105516.GH4216@redhat.com> References: <20130919190837.GC4216@redhat.com> <523BF6F5.1040803@redhat.com> <20130920073606.GF4216@redhat.com> <523C25ED.3010702@redhat.com> <20130920105516.GH4216@redhat.com> Message-ID: <523C388E.2050008@redhat.com> On 20.9.2013 12:55, Alexander Bokovoy wrote: >>>> 1) The object is named "subdomain", but the commands are named >>>> "trust_domain_*". Please use the object name as the base for command >>>> names. I would suggest renaming the object to "trustdomain", as the >>>> framework does not allow underscores in object names, and "subdomain" >>>> sounds a little bit too generic. >>> subdomains as objects are not visible to users. Users cannot operate on >>> subdomains themselves. I do not want to give you impression we are >>> having separate trust and domains. Instead, we deal with trusts and >>> subdomains are simply internal components of it. >> >> They are part of the API, whether they are visible to users or not, >> and they should follow the same convention as the rest of the API. >> >> From the framework perspective, subdomains are child objects of >> trusts, no different to how DNS records are child objects of DNS >> zones, except they are internal and not visible to users. You even >> implemented them this way in the patch, I just don't like how hackily >> it is done. > The difference is that with DNS records and zones you have explicit > mapping -- record is under zone and zone is under dns container. The DN > is explicitly defined by input under static DNS container DN. > > With trusts there are few possible containers and input does not define > the DN fully. We have trust type which means whenever trust is created, > type is either default or explicitly set, yet for any other operation on > the trust its type is not specified and has to be looked up. > > With subdomains under trusts we get another level of indirection. Had > subdomains and trusts be based on a static DN, it could have worked. > However, we don't have trust type available so it needs to discovered > every time. This doesn't play well with the framework, it is simply not > expecting dynamic containers. This doesn't sound like a big obstacle to me. Right now the trust_type lookup is done in trust_show.execute() for some reason, which is not the best place to do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to make parent_object work. > >>> The fact that you currently see these commands in 'ipa trust-*' family >>> reflects the situation. -mod command is intended to be internal as well, >>> it will not be visible in CLI in the end. The only command available to >>> users will be 'ipa trust-domain-fetch'. >> >> All the more reason for following the usual convention. > I don't follow you here. With a single visible command added to the > trust family why it should be 'ipa trustdomain-fetch' instead of 'ipa > trust-domain-fetch'? What is the reason for inconsistency. Sorry, I should have been more specific - trust-domain-fetch is OK and the rest of the commands are not visible in the CLI, so naming them trustdomain-* will not confuse anyone. > > Current way framework lays down object-verb system is due to > implementation convenience, not because this is a really required from > CLI point of view. I believe I have reasonable arguments to not fall > into trap of having multiple objects visible to CLI. CLI should be > simple to use, it should not expose too much of internal complexity > where not required. I agree with this. As I said above, I am not suggesting making the trust domain objects visible to users. > > >>>> 2) There is already support for objects inside objects in the >>>> framework, there's no need to reinvent this. See the parent_object >>>> attribute of LDAPObject and the dns plugin for practical example. >>> It does not work in this case properly. Feel free to try to implement >>> it, really. I have spent good deal of last two weeks trying all options >>> possible. >> >> Why does it not work? The functionality of parent_object is pretty >> straightforward, so I can't imagine what might go wrong. > See above. It is not designed for the use case of dynamic container DNs > which involves components not derived from the input. Honza -- Jan Cholasta From mbasti at redhat.com Fri Sep 20 14:00:45 2013 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Sep 2013 16:00:45 +0200 Subject: [Freeipa-devel] [DOC] Chapter 4 screenshots In-Reply-To: <1379516848.9269.3.camel@unused-4-145.brq.redhat.com> References: <1379516848.9269.3.camel@unused-4-145.brq.redhat.com> Message-ID: <1379685645.2094.1.camel@unused-4-145.brq.redhat.com> On Wed, 2013-09-18 at 17:07 +0200, Martin Basti wrote: > Patch adds new screen-shots for chapter 4 Basic Usage > > NOTE: Patch doesn't cover part 4.3 Logging with web UI > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Sorry, I forgot to update one image -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0003-2-Chapter_4_screenshots.patch Type: text/x-patch Size: 823414 bytes Desc: not available URL: From mbasti at redhat.com Fri Sep 20 14:06:15 2013 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Sep 2013 16:06:15 +0200 Subject: [Freeipa-devel] [DOC] 0005 Updated chapter 4 - login into web UI Message-ID: <1379685975.2094.5.camel@unused-4-145.brq.redhat.com> Logging into web UI and configuring web browser sections were outdated -- Martin Basti -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mbasti-0005-Update-Chapter-4-login-into-Web-UI-section.patch Type: text/x-patch Size: 370602 bytes Desc: not available URL: From akrivoka at redhat.com Fri Sep 20 14:48:59 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 20 Sep 2013 16:48:59 +0200 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: References: <523200E9.5010304@redhat.com> <523AFBA2.9070000@redhat.com> <523AFF92.6070805@redhat.com> , <523C2527.9040700@redhat.com> Message-ID: <523C605B.6010504@redhat.com> On 09/20/2013 04:25 PM, JR Aquino wrote: > Great work on this. > > I've longed to revisit my code and provide a way to refresh/update. > > I think it got left off with rich and Nathan as something that should be a 389 plugin mod. > > Thanks for working on this! > > "You cannot hope to secure that which you do not understand" > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Jr Aquino > Sr. Information Security Specialist, Technical Operations > Sans: GXPN, GCIH, GWAPT > T: +1 805 690 3478 | M: +1 805 717 0365 | F: +1 805 403 9399 > Jr.Aquino at citrix.com > > Powering mobile workstyles and cloud services > >> On Sep 20, 2013, at 3:37 AM, "Ana Krivokapic" wrote: >> >>> On 09/19/2013 07:34 PM, JR Aquino wrote: >>> Does the rebuild support the notion of members belonging to multiple groups via automember rules? >> Yes, all memberships are rebuilt. >> >>> "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 19, 2013, at 6:43 AM, Ana Krivokapic > wrote: >>> >>> On 09/19/2013 03:26 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 12.9.2013 19:59, Ana Krivokapic wrote: >>> Hello, >>> >>> The design document for $SUBJECT can be found at: >>> http://www.freeipa.org/page/V3/Automember_rebuild_membership >>> >>> Related tickets: >>> https://fedorahosted.org/freeipa/ticket/3752 >>> https://fedorahosted.org/freeipa/ticket/3928 >>> >>> Thoughts, comments, questions welcome. >>> >>> >>> I don't think naming the commands user-automember-rebuild and >>> host-automember-rebuild commands is correct. The names imply they are methods >>> of user/host, but they don't directly do anything to user/host objects. I >>> would prefer if they were kept in the automember namespace where they >>> logically belong (automember-rebuild-user and automember-rebuild-host perhaps?) >>> >>> Honza >>> >>> >>> That makes sense... I don't have a strong preference one way or other. So if >>> other agree with this suggestion, I will change it. >>> >>> -- >>> Regards, >>> >>> Ana Krivokapic >>> Associate Software Engineer >>> FreeIPA team >>> Red Hat Inc. >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> -- >> Regards, >> >> Ana Krivokapic >> Associate Software Engineer >> FreeIPA team >> Red Hat Inc. >> You are welcome, I'm glad you find it useful! :) BTW, patches are already on the list (minus the web UI part - coming soon), you can check them out if you want: https://www.redhat.com/archives/freeipa-devel/2013-September/msg00295.html -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From sbose at redhat.com Fri Sep 20 15:40:05 2013 From: sbose at redhat.com (Sumit Bose) Date: Fri, 20 Sep 2013 17:40:05 +0200 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <20130919190837.GC4216@redhat.com> References: <20130919190837.GC4216@redhat.com> Message-ID: <20130920154005.GP25628@localhost.localdomain> On Thu, Sep 19, 2013 at 10:08:37PM +0300, Alexander Bokovoy wrote: > Hi! > > Attached patch adds IPA CLI to manage trust subdomains. > > ipa trust-domain-fetch -- fetch list of subdomains from AD side and add new ones to IPA > ipa trust-domain-find -- show all available subdomains > ipa trust-domain-del -- remove subdomain from IPA > view about > ipa trust-domain-mod -- modify subdomain parameters (work in progress) > > IPA KDC needs also information for authentication paths to subdomains in > case they are not hierarchical under AD forest trust root. This > information is managed via capaths section in krb5.conf. SSSD should be > able to generate it once ticket https://fedorahosted.org/sssd/ticket/2093 is resolved. I just want to let you know that I successfully tested you patch with sssd in a setup with the hierarchical case, i.e. the DNS name of the subdomain is a child of the DNS name of the forest root. I also didn't need to change the realm-domain mapping (https://fedorahosted.org/sssd/ticket/2080) in this case. I will test again with a non-hierarchical setup. bye, Sumit > > part of https://fedorahosted.org/freeipa/ticket/3909 > > The patch implements some dark magic to get around IPA framework > limitations: > > -- CLI commands belong to 'trust' family but operate on 'subdomain' object > -- 'subdomain' objects are stored under trust container, thus making > container_dn dependent on a particular trust: > cn=,cn=,cn=ad,cn=trusts,$SUFFIX > > The latter is a design decision since our KDC driver loads all objects > with objectclass=ipaNTTrustedDomain from cn=ad,cn=trusts,$SUFFIX using > subtree scope. With this design no changes were needed in ipa-kdb at all > to support subdomains. > > -- > / Alexander Bokovoy > >From bf6145368cd517557f9839586cae32160291964e Mon Sep 17 00:00:00 2001 > From: Alexander Bokovoy > Date: Wed, 18 Sep 2013 17:04:19 +0200 > Subject: [PATCH 5/5] trusts: support subdomains in a forest > > Add IPA CLI to manage trust subdomains. > > ipa trust-domain-fetch -- fetch list of subdomains from AD side and add new ones to IPA > ipa trust-domain-find -- show all available subdomains > ipa trust-domain-del -- remove subdomain from IPA view about > ipa trust-domain-mod -- modify subdomain parameters (work in progress) > > IPA KDC needs also information for authentication paths to subdomains in case they > are not hierarchical under AD forest trust root. This information is managed via capaths > section in krb5.conf. SSSD should be able to generate it once > ticket https://fedorahosted.org/sssd/ticket/2093 is resolved. > > part of https://fedorahosted.org/freeipa/ticket/3909 > --- > API.txt | 67 ++++++++++++++++++ > ipalib/plugins/trust.py | 176 +++++++++++++++++++++++++++++++++++++++++++++++- > ipaserver/dcerpc.py | 54 +++++++++++++++ > 3 files changed, 295 insertions(+), 2 deletions(-) > > diff --git a/API.txt b/API.txt > index 761d1d1..a7c97e0 100644 > --- a/API.txt > +++ b/API.txt > @@ -3423,6 +3423,73 @@ option: Str('version?', exclude='webui') > output: Output('result', , None) > output: Output('summary', (, ), None) > output: Output('value', , None) > +command: trust_domain_create > +args: 2,9,3 > +arg: Str('trust?') > +arg: Str('cn?', cli_name='domain', primary_key=True) > +option: Str('addattr*', cli_name='addattr', exclude='webui') > +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') > +option: Str('ipantflatname', attribute=True, cli_name='flat_name', multivalue=False, required=False) > +option: Str('ipanttrusteddomainsid', attribute=True, cli_name='sid', multivalue=False, required=False) > +option: Str('ipanttrustpartner?') > +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') > +option: Str('setattr*', cli_name='setattr', exclude='webui') > +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', values=(u'ad',)) > +option: Str('version?', exclude='webui') > +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) > +output: Output('summary', (, ), None) > +output: Output('value', , None) > +command: trust_domain_del > +args: 2,2,3 > +arg: Str('trust?') > +arg: Str('cn?', cli_name='domain', primary_key=True) > +option: Flag('continue', autofill=True, cli_name='continue', default=False) > +option: Str('version?', exclude='webui') > +output: Output('result', , None) > +output: Output('summary', (, ), None) > +output: Output('value', , None) > +command: trust_domain_fetch > +args: 1,4,2 > +arg: Str('trust?') > +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') > +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') > +option: Flag('rights', autofill=True, default=False) > +option: Str('version?', exclude='webui') > +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) > +output: Output('summary', (, ), None) > +command: trust_domain_find > +args: 2,8,4 > +arg: Str('criteria?', noextrawhitespace=False) > +arg: Str('trust?') > +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') > +option: Str('cn?', cli_name='domain', primary_key=True) > +option: Str('ipantflatname', attribute=True, autofill=False, cli_name='flat_name', multivalue=False, query=True, required=False) > +option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='sid', multivalue=False, query=True, required=False) > +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') > +option: Int('sizelimit?', autofill=False, minvalue=0) > +option: Int('timelimit?', autofill=False, minvalue=0) > +option: Str('version?', exclude='webui') > +output: Output('count', , None) > +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) > +output: Output('summary', (, ), None) > +output: Output('truncated', , None) > +command: trust_domain_mod > +args: 2,10,3 > +arg: Str('trust?') > +arg: Str('cn?', cli_name='domain', primary_key=True) > +option: Str('addattr*', cli_name='addattr', exclude='webui') > +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') > +option: Str('delattr*', cli_name='delattr', exclude='webui') > +option: Str('ipantflatname', attribute=True, autofill=False, cli_name='flat_name', multivalue=False, required=False) > +option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='sid', multivalue=False, required=False) > +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') > +option: Flag('rights', autofill=True, default=False) > +option: Str('setattr*', cli_name='setattr', exclude='webui') > +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', values=(u'ad',)) > +option: Str('version?', exclude='webui') > +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) > +output: Output('summary', (, ), None) > +output: Output('value', , None) > command: trust_find > args: 1,11,4 > arg: Str('criteria?', noextrawhitespace=False) > diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py > index 3c117b4..6ffe119 100644 > --- a/ipalib/plugins/trust.py > +++ b/ipalib/plugins/trust.py > @@ -245,7 +245,7 @@ def make_trust_dn(env, trust_type, dn): > assert isinstance(dn, DN) > if trust_type in trust.trust_types: > container_dn = DN(('cn', trust_type), env.container_trusts, env.basedn) > - return DN(dn[0], container_dn) > + return DN(dn, container_dn) > return dn > > class trust_add(LDAPCreate): > @@ -738,7 +738,7 @@ class trust_show(LDAPRetrieve): > def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): > assert isinstance(dn, DN) > if 'trust_show_type' in options: > - return make_trust_dn(self.env, options['trust_show_type'], dn) > + return make_trust_dn(self.env, options['trust_show_type'], DN(dn[0])) > > return dn > > @@ -1078,3 +1078,175 @@ class sidgen_was_run(Command): > return dict(result=True) > > api.register(sidgen_was_run) > + > +class subdomain(LDAPObject): > + """ > + Object representing a domain of the AD trust. > + """ > + trust_type_idx = {'2':u'ad'} > + object_name = _('trust domain') > + object_name_plural = _('trust domains') > + object_class = ['ipaNTTrustedDomain'] > + default_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', 'ipanttrustdirection', 'ipanttrustpartner'] > + search_display_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', ] > + > + label = _('Trusted domains') > + label_singular = _('Trusted domain') > + > + subdomain_args = ( > + Str('trust?', > + label=_('AD trust'), > + flags=('virtual_attribute',), > + ), > + Str('cn?', > + label=_('Domain name'), > + cli_name='domain', > + primary_key=True, > + flags=('req_update','req_create',), > + ), > + ) > + > + takes_params = ( > + Str('ipantflatname?', > + cli_name='flat_name', > + label=_('Domain NetBIOS name'), > + ), > + Str('ipanttrusteddomainsid?', > + cli_name='sid', > + label=_('Domain Security Identifier'), > + ), > + ) > + > + container_dn = api.env.container_trusts > + def get_dn(self, *keys, **kwargs): > + if len(keys) == 1: > + return self.api.Object.trust.get_dn(*keys, **kwargs) > + dn=make_trust_dn(self.env, getattr(kwargs, 'trust_type', u'ad'), DN(('cn', keys[1]), ('cn', keys[0]))) > + return dn > + > +api.register(subdomain) > + > +class trust_domain_find(LDAPSearch): > + __doc__ = _('Search subdomains of the trust') > + > + obj_name = 'subdomain' > + > + takes_args = subdomain.subdomain_args[0] > + takes_options = LDAPSearch.takes_options + (subdomain.subdomain_args[1],) > + def pre_callback(self, ldap, filters, attrs_list, base_dn, scope, *args, **options): > + assert isinstance(base_dn, DN) > + if not args[0]: > + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name is required to search subdomains')) > + > + base_dn = DN(self.api.Command.trust_show(args[0])['result']['dn']) > + return (filters, base_dn, ldap.SCOPE_SUBTREE) > +api.register(trust_domain_find) > + > +class trust_domain_mod(LDAPUpdate): > + __doc__ = _('Modify subdomain of the trust') > + > + obj_name = 'subdomain' > + > + takes_args = subdomain.subdomain_args > + takes_options = LDAPUpdate.takes_options + (_trust_type_option,) > + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): > + if len(keys) != 2: > + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name and subdomain name are required to modify the subdomain')) > + return dn > +api.register(trust_domain_mod) > + > +class trust_domain_create(LDAPCreate): > + __doc__ = _('Create subdomain of the trust') > + NO_CLI = True > + obj_name = 'subdomain' > + > + takes_args = subdomain.subdomain_args > + takes_options = LDAPCreate.takes_options + (_trust_type_option, > + Str('ipanttrustpartner?', > + label=_('Trusted domain partner'), > + ), > + ) > + > + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): > + if len(keys) != 2: > + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name and subdomain name are required to create the subdomain')) > + assert isinstance(dn, DN) > + if 'ipanttrustpartner' in options: > + entry_attrs['ipanttrustpartner'] = [options['ipanttrustpartner']] > + self.log.error('trust_domain_create(%s,%s), entry attrs %s' % (keys,options,entry_attrs)) > + return dn > +api.register(trust_domain_create) > + > +class trust_domain_del(LDAPDelete): > + __doc__ = _('Delete a subdomain of the trust.') > + > + obj_name = 'subdomain' > + msg_summary = _('Deleted subdomain "%(value)s"') > + > + takes_args = subdomain.subdomain_args > + def pre_callback(self, ldap, dn, *keys, **options): > + if len(keys) != 2: > + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name and subdomain name are required to delete the subdomain')) > + try: > + result = self.api.Command.trust_show(keys[0], raw=True) > + except errors.NotFound, e: > + self.obj.handle_not_found(*keys) > + options['trust_type'] = self.obj.trust_type_idx[result['result']['ipanttrusttype'][0]] > + return make_trust_dn(self.env, options['trust_type'], DN(('cn', keys[1]), ('cn', keys[0]))) > +api.register(trust_domain_del) > + > +class trust_domain_fetch(LDAPRetrieve): > + __doc__ = _('Refresh list of subdomains associated with the trust') > + obj_name = 'subdomain' > + > + takes_args = (subdomain.subdomain_args[0]) > + > + has_output = ( > + output.ListOfEntries('result'), > + output.summary > + ) > + def execute(self, *keys, **options): > + if not _bindings_installed: > + raise errors.NotFound( > + name=_('AD Trust setup'), > + reason=_( > + 'Cannot perform join operation without Samba 4 support ' > + 'installed. Make sure you have installed server-trust-ad ' > + 'sub-package of IPA' > + ) > + ) > + if len(keys) != 1: > + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name is required to search subdomains')) > + > + trust = self.api.Command.trust_show(keys[0], raw=True)['result'] > + > + trustinstance = ipaserver.dcerpc.TrustDomainJoins(self.api) > + if not trustinstance.configured: > + raise errors.NotFound( > + name=_('AD Trust setup'), > + reason=_( > + 'Cannot perform join operation without own domain ' > + 'configured. Make sure you have run ipa-adtrust-install ' > + 'on the IPA server first' > + ) > + ) > + domains = ipaserver.dcerpc.fetch_domains(self.api, trustinstance.local_flatname, trust['cn'][0]) > + result = dict(result=[]) > + if not domains: > + result['summary'] = unicode(_('No sudomains were detected during refresh')) > + return result > + > + for dom in domains: > + dom['trust_type'] = self.obj.trust_type_idx[trust['ipanttrusttype'][0]] > + try: > + res = self.api.Command.trust_domain_create(trust['cn'][0], **dom) > + result['result'].append(res['result']) > + except errors.DuplicateEntry: > + # Ignore updating duplicate entries > + pass > + if len(result['result']) > 0: > + result['summary'] = unicode(_('Subdomains successfully refreshed')) > + else: > + result['summary'] = unicode(_('No new subdomains were found')) > + return result > +api.register(trust_domain_fetch) > diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py > index 33e7e07..fcfedc4 100644 > --- a/ipaserver/dcerpc.py > +++ b/ipaserver/dcerpc.py > @@ -992,6 +992,60 @@ class TrustDomainInstance(object): > return True > return False > > +def fetch_domains(api, mydomain, trustdomain): > + trust_flags = dict( > + NETR_TRUST_FLAG_IN_FOREST = 0x00000001, > + NETR_TRUST_FLAG_OUTBOUND = 0x00000002, > + NETR_TRUST_FLAG_TREEROOT = 0x00000004, > + NETR_TRUST_FLAG_PRIMARY = 0x00000008, > + NETR_TRUST_FLAG_NATIVE = 0x00000010, > + NETR_TRUST_FLAG_INBOUND = 0x00000020, > + NETR_TRUST_FLAG_MIT_KRB5 = 0x00000080, > + NETR_TRUST_FLAG_AES = 0x00000100) > + > + trust_attributes = dict( > + NETR_TRUST_ATTRIBUTE_NON_TRANSITIVE = 0x00000001, > + NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x00000002, > + NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x00000004, > + NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x00000008, > + NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x00000010, > + NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x00000020, > + NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x00000040) > + > + domval = DomainValidator(api) > + (ccache_name, principal) = domval.kinit_as_http(trustdomain) > + if ccache_name: > + with installutils.private_ccache(path=ccache_name): > + td = TrustDomainInstance('') > + td.parm.set('workgroup', mydomain) > + td.creds = credentials.Credentials() > + td.creds.set_kerberos_state(credentials.MUST_USE_KERBEROS) > + td.creds.guess(td.parm) > + netrc = net.Net(creds=td.creds, lp=td.parm) > + try: > + result = netrc.finddc(domain=trustdomain, flags=nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_DS) > + except RuntimeError, e: > + raise assess_dcerpc_exception(message=str(e)) > + if not result: > + return None > + td.retrieve(unicode(result.pdc_dns_name)) > + > + netr_pipe = netlogon.netlogon(td.binding, td.parm, td.creds) > + domains = netr_pipe.netr_DsrEnumerateDomainTrusts(td.binding, 1) > + > + result = [] > + for t in domains.array: > + if ((t.trust_attributes & trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and > + (t.trust_flags & trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): > + res = dict() > + res['cn'] = unicode(t.dns_name) > + res['ipantflatname'] = unicode(t.netbios_name) > + res['ipanttrusteddomainsid'] = unicode(t.sid) > + res['ipanttrustpartner'] = res['cn'] > + result.append(res) > + return result > + > + > class TrustDomainJoins(object): > def __init__(self, api): > self.api = api > -- > 1.8.3.1 > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pvoborni at redhat.com Fri Sep 20 15:39:51 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 20 Sep 2013 17:39:51 +0200 Subject: [Freeipa-devel] [DOC] 0005 Updated chapter 4 - login into web UI In-Reply-To: <1379685975.2094.5.camel@unused-4-145.brq.redhat.com> References: <1379685975.2094.5.camel@unused-4-145.brq.redhat.com> Message-ID: <523C6C47.400@redhat.com> On 09/20/2013 04:06 PM, Martin Basti wrote: > Logging into web UI and configuring web browser sections were outdated > Thanks for the path. Here are my comments (some for existing issues): 1. There are whitespace warnings when applying this patch. 2. PDF output is bad. Images are too big - right half is not displayed. Several times there is image A with list item for image B below (image B is on the next page with list item for image C). I saw some 'missing image constraints warnings' during build - maybe that's the cause. 3. Section 4.3.5: Don't know why it's called 'Simple authentication'. Usually it's referred to as 'forms based authentication'. 3a. Following sentence is misleading: "the error first says to renew the Kerberos credentials or to configure the browser to support Kerberos authentication." IIRC the previous dialog had different wording. The new one gives user two options but it doesn't encourage user to 'renew Kerberos credentials'. Also, you have deleted the first instruction but left a second: "Then simply supply the UID and password for a configured FreeIPA user." without any context. IMO it should be reworded. 4. I think the entire section '4.3.6. Using the UI with Proxy Servers' is incorrect. Using Web UI with proxy is not an easy thing to do. 5. Old unused images should be deleted. 6. Section 4.4.1 (not sure if it's related to this patch) says: "randomly selects up to 20 entries" that's not true. There is no randomness. It selects: First record: ($PAGE_NUM * 20 +1), up to Last: (($PAGE_NUM + 1) *20). When first index is 1. 6a. LDAP search limit: the option name is --pkey-only not --pkey. -- Petr Vobornik From npmccallum at redhat.com Fri Sep 20 16:38:43 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 20 Sep 2013 12:38:43 -0400 Subject: [Freeipa-devel] [PATCH 0016] Add RADIUS proxy support to ipalib CLI In-Reply-To: <1379018880.2210.1.camel@localhost> References: <1378353973.19352.11.camel@localhost> <1379018880.2210.1.camel@localhost> Message-ID: <1379695123.1629.10.camel@localhost> On Thu, 2013-09-12 at 16:48 -0400, Nathaniel McCallum wrote: > On Thu, 2013-09-05 at 00:06 -0400, Nathaniel McCallum wrote: > > patch attached > > Update for ./makeapi attached. Version 3. This should fix all the current review issues, including the use of the referential integrity plugin. I had to make one schema change in order to make the referential integrity modification work. Note also that the command name prefix is changed from radius to radiusproxy. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0016-3-Add-RADIUS-proxy-support-to-ipalib-CLI.patch Type: text/x-patch Size: 31776 bytes Desc: not available URL: From simo at redhat.com Fri Sep 20 19:35:47 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 20 Sep 2013 15:35:47 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs Message-ID: <1379705747.30999.25.camel@willson.li.ssimo.org> This patch set is an initial implementation of ticket #3859 It seem to be working fine in my initial testing but I have not yet tested all cases. However I wonted to throw it on the list to get some initial feedback about the choices I made wrt access control and ipa-getkeytab flags and default behavior. In particular, the current patch set would require us to make host/service keytabs readable by the requesting party (whoever that is, admin or host itself) in order to allow it to get back the actual keytab. I am not sure this is ideal. Also write access to the keytab is still all is needed to allow someone to change it. Neither is ideal, but it was simpler as a first implementation. In particular I think we should allow either permission indipendently, and it should be something an admin can change. However I do not like allowing normal writes or reads to these attributes, mostly because w/o access to the master key nobody can really make sense of actually reading out the contents of KrbPrincipalKey or could write a blob that can be successfully decrypted. So I was wondering if we might want to prevent both reading and writing via LDAP (except via extended operations) and instead use another method to determine access patterns. As for ipa-getkeytab is everyone ok with tryin the new method first and always falling back to the old one (if a password has been provided) ? Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-keytabs-Modularize-setkeytab-operation.patch Type: text/x-patch Size: 16436 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-keytabs-Expose-and-modify-key-encoding-function.patch Type: text/x-patch Size: 5300 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-keytab-Add-new-extended-operation-to-get-a-keytab.patch Type: text/x-patch Size: 16191 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-ipa-getkeytab-Modularize-ldap_set_keytab-function.patch Type: text/x-patch Size: 11208 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-ipa-getkeytab-Add-support-for-get_keytab-extop.patch Type: text/x-patch Size: 15882 bytes Desc: not available URL: From pspacek at redhat.com Mon Sep 23 07:00:34 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 23 Sep 2013 09:00:34 +0200 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <1379705747.30999.25.camel@willson.li.ssimo.org> References: <1379705747.30999.25.camel@willson.li.ssimo.org> Message-ID: <523FE712.80108@redhat.com> On 20.9.2013 21:35, Simo Sorce wrote: > This patch set is an initial implementation of ticket #3859 > > It seem to be working fine in my initial testing but I have not yet > tested all cases. > > However I wonted to throw it on the list to get some initial feedback > about the choices I made wrt access control and ipa-getkeytab flags and > default behavior. > > In particular, the current patch set would require us to make > host/service keytabs readable by the requesting party (whoever that is, > admin or host itself) in order to allow it to get back the actual > keytab. I am not sure this is ideal. Also write access to the keytab is > still all is needed to allow someone to change it. > > Neither is ideal, but it was simpler as a first implementation. In > particular I think we should allow either permission indipendently, and > it should be something an admin can change. However I do not like > allowing normal writes or reads to these attributes, mostly because w/o > access to the master key nobody can really make sense of actually > reading out the contents of KrbPrincipalKey or could write a blob that > can be successfully decrypted. > > So I was wondering if we might want to prevent both reading and writing > via LDAP (except via extended operations) and instead use another method > to determine access patterns. > > As for ipa-getkeytab is everyone ok with tryin the new method first and > always falling back to the old one (if a password has been provided) ? > > Simo. I was always curious why we don't use normal kadmin protocol? :-) -- Petr^2 Spacek From jcholast at redhat.com Mon Sep 23 07:18:03 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Sep 2013 09:18:03 +0200 Subject: [Freeipa-devel] [PATCHES] 0177-0179 Add missing dict methods to CIDict In-Reply-To: <523995EB.9010706@redhat.com> References: <51113B3F.3070808@redhat.com> <51237565.1040404@redhat.com> <5124FBBB.6080801@redhat.com> <523871A7.9050506@redhat.com> <523995EB.9010706@redhat.com> Message-ID: <523FEB2B.3050507@redhat.com> On 18.9.2013 14:00, Petr Viktorin wrote: > On 09/17/2013 05:13 PM, Jan Cholasta wrote: >> On 20.2.2013 17:37, Petr Viktorin wrote: >>> On 02/19/2013 01:51 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 5.2.2013 18:02, Petr Viktorin wrote: >>>>> CIDict, our case-insensitive dictionary, inherits from dict but did >>>>> not >>>>> reimplement the full dict interface. Calling the missing methods >>>>> silently invoked case-sensitive behavior. Our code seems to avoid >>>>> that, >>>>> but it's a bit of a minefield for new development. >>>>> >>>>> Patch 119 adds the missing dict methods (except >>>>> view{items,keys,values}(), which now raise errors), and adds tests. >>>> >>>> Can you please also add the (obj, **kwargs) and (**kwargs) variants of >>>> __init__ and update? >>> >>> Added, thanks for the catch. >>> >>>> >>>>> >>>>> >>>>> Patches 117-118 modernize the testsuite a bit (these have been sitting >>>>> in my queue for a while, I think now is a good time to submit them): >>>>> The first one moves some old tests from the main code tree to tests/. >>>>> (The adtrust_install test wasn't run before, this move makes nose >>>>> notice >>>>> it). >>>>> The second converts CIDict's unittest-based suite to nose. >>>>> >>>> >>>> Honza >>>> >>> >>> >> >> Whoa, I totally forgot about these patches! >> >> Can you please rebase them? > > Sure! > >> One more comment: >> >> Document that CIDict.copy() returns a plain dict. >> >> Why does it return a plain dict? I think it should return a CIDict, >> otherwise it is not actually a copy, right? > > I wanted to keep the existing (intended) functionality. > But since we don't actually use CIDict.copy() anywhere any more, I've > made the change. Thanks. > > P.S. I recently came across a bug in python-ldap where something like > CIDict({'cn': ['name1', 'name2'], 'cN': ['name3']}) will throw away some > of the values. > This is expected at the CIDict level, but if you're working with dicts > of lists it's something to keep an eye out for. > This is a good point. IIRC when you use such a dict in python-ldap, it will fail with TYPE_OR_VALUE_EXISTS. I think we should raise an error in CIDict as well if such a dict is used in __init__() and update(), as this kind of error is very hard to track otherwise. Honza -- Jan Cholasta From mkosek at redhat.com Mon Sep 23 07:18:20 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Sep 2013 09:18:20 +0200 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <523AFF92.6070805@redhat.com> References: <523200E9.5010304@redhat.com> <523AFBA2.9070000@redhat.com> <523AFF92.6070805@redhat.com> Message-ID: <523FEB3C.2020408@redhat.com> On 09/19/2013 03:43 PM, Ana Krivokapic wrote: > On 09/19/2013 03:26 PM, Jan Cholasta wrote: >> Hi, >> >> On 12.9.2013 19:59, Ana Krivokapic wrote: >>> Hello, >>> >>> The design document for $SUBJECT can be found at: >>> http://www.freeipa.org/page/V3/Automember_rebuild_membership >>> >>> Related tickets: >>> https://fedorahosted.org/freeipa/ticket/3752 >>> https://fedorahosted.org/freeipa/ticket/3928 >>> >>> Thoughts, comments, questions welcome. >>> >> >> I don't think naming the commands user-automember-rebuild and >> host-automember-rebuild commands is correct. The names imply they are methods >> of user/host, but they don't directly do anything to user/host objects. I >> would prefer if they were kept in the automember namespace where they >> logically belong (automember-rebuild-user and automember-rebuild-host perhaps?) >> >> Honza >> > > That makes sense... I don't have a strong preference one way or other. So if > other agree with this suggestion, I will change it. I think Honza's comment makes sense. We can merge the functionality to automember-rebuild command: $ ipa automember-rebuild --type=group [ENTRY] $ ipa automember-rebuild --type=hostgroup [ENTRY] If no ENTRY is specified, it would run rebuild for all entries. If ENTRY is specified, it would use it as Primary Key the entry - user uid or group name. This way the API should be consistent with the rest of the automember plugin. Makes sense? Martin From jpazdziora at redhat.com Mon Sep 23 07:37:34 2013 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 23 Sep 2013 15:37:34 +0800 Subject: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments In-Reply-To: <1379077690.2804.1976.camel@willson.li.ssimo.org> References: <5232CC3E.1010401@redhat.com> <1379077690.2804.1976.camel@willson.li.ssimo.org> Message-ID: <20130923073734.GC2029@redhat.com> On Fri, Sep 13, 2013 at 09:08:10AM -0400, Simo Sorce wrote: > > > > The natural request is to add support for DNS views/split horizon DNS into > > FreeIPA, so different names and IP addresses can be served to clients inside > > and outside of the cloud. > > > > Is it enough? What else should we change to make FreeIPA reliable in clouds? > > I do not understand what's the use of views in this case. > > Views are used when you want to assign different IP addresses to the > same name depending on where the query comes from. Which can well be useful in cloud -- you might want to access the other machine of your setup using its internal IP address because it's cheaper than going through the external interface. > But here we have different names pointing to different addresses and the > machine actually know nothing about the external name/IP. Well, the fact that a name does or does not exist is also a use-case for views. There probably is little point presenting the internal names to the external world. > From the FreeIPA pov, if you use it for infrastructure you should just > care about internal names. Isn't it quite the oposite in cloud? The individual machines are disposable often and all that matters is that there is a machine which is able to provide a service, on some well-known stable public host name. Which physical VM serves that service can change rapidly. A one VM providing the service can change to five with some HA proxy in front of them. -- Jan Pazdziora | adelton at #ipa*, #brno Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Mon Sep 23 07:39:16 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Sep 2013 09:39:16 +0200 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <523C388E.2050008@redhat.com> References: <20130919190837.GC4216@redhat.com> <523BF6F5.1040803@redhat.com> <20130920073606.GF4216@redhat.com> <523C25ED.3010702@redhat.com> <20130920105516.GH4216@redhat.com> <523C388E.2050008@redhat.com> Message-ID: <523FF024.4010300@redhat.com> On 09/20/2013 01:59 PM, Jan Cholasta wrote: > On 20.9.2013 12:55, Alexander Bokovoy wrote: >>>>> 1) The object is named "subdomain", but the commands are named >>>>> "trust_domain_*". Please use the object name as the base for command >>>>> names. I would suggest renaming the object to "trustdomain", as the >>>>> framework does not allow underscores in object names, and "subdomain" >>>>> sounds a little bit too generic. >>>> subdomains as objects are not visible to users. Users cannot operate on >>>> subdomains themselves. I do not want to give you impression we are >>>> having separate trust and domains. Instead, we deal with trusts and >>>> subdomains are simply internal components of it. >>> >>> They are part of the API, whether they are visible to users or not, >>> and they should follow the same convention as the rest of the API. >>> >>> From the framework perspective, subdomains are child objects of >>> trusts, no different to how DNS records are child objects of DNS >>> zones, except they are internal and not visible to users. You even >>> implemented them this way in the patch, I just don't like how hackily >>> it is done. >> The difference is that with DNS records and zones you have explicit >> mapping -- record is under zone and zone is under dns container. The DN >> is explicitly defined by input under static DNS container DN. >> >> With trusts there are few possible containers and input does not define >> the DN fully. We have trust type which means whenever trust is created, >> type is either default or explicitly set, yet for any other operation on >> the trust its type is not specified and has to be looked up. >> >> With subdomains under trusts we get another level of indirection. Had >> subdomains and trusts be based on a static DN, it could have worked. >> However, we don't have trust type available so it needs to discovered >> every time. This doesn't play well with the framework, it is simply not >> expecting dynamic containers. > > This doesn't sound like a big obstacle to me. Right now the trust_type lookup > is done in trust_show.execute() for some reason, which is not the best place to > do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to > make parent_object work. Yup, get_dn() is the method where object DN lookup should be done. See for example host.py plugin get_dn method, we also do a dynamic lookup for correct host name. > >> >>>> The fact that you currently see these commands in 'ipa trust-*' family >>>> reflects the situation. -mod command is intended to be internal as well, >>>> it will not be visible in CLI in the end. The only command available to >>>> users will be 'ipa trust-domain-fetch'. >>> >>> All the more reason for following the usual convention. >> I don't follow you here. With a single visible command added to the >> trust family why it should be 'ipa trustdomain-fetch' instead of 'ipa >> trust-domain-fetch'? What is the reason for inconsistency. > > Sorry, I should have been more specific - trust-domain-fetch is OK and the rest > of the commands are not visible in the CLI, so naming them trustdomain-* will > not confuse anyone. +1 for being consistent with the rest of the system, even if the commands are internal (for now), we should keep the naming conventions that are present in the rest of the system. Since we are operating on trust domain objects, the API should be: trustdomain-add trustdomain-del trustdomain-find trustdomain-mod + the visible commands on Trust. I did not dig into code, but as Honza said, the best way to implement dynamic DN gathering is the get_dn() method. That way, it could be implemented in one place and all commands could take advantage of it instead of re-implementing it several times in pre_callback - this is just hackish. Alexander, can you please work with Honza in case the get_dn function does not work for you? He may prepare a patch for you if he has an idea how to do it better. > >> >> Current way framework lays down object-verb system is due to >> implementation convenience, not because this is a really required from >> CLI point of view. I believe I have reasonable arguments to not fall >> into trap of having multiple objects visible to CLI. CLI should be >> simple to use, it should not expose too much of internal complexity >> where not required. > > I agree with this. As I said above, I am not suggesting making the trust domain > objects visible to users. As above, even if the commands are internal, let's make them consistent with rest of the framework. It would be very hard to change API later if we for example find we want to expose the API. >>>>> 2) There is already support for objects inside objects in the >>>>> framework, there's no need to reinvent this. See the parent_object >>>>> attribute of LDAPObject and the dns plugin for practical example. >>>> It does not work in this case properly. Feel free to try to implement >>>> it, really. I have spent good deal of last two weeks trying all options >>>> possible. >>> >>> Why does it not work? The functionality of parent_object is pretty >>> straightforward, so I can't imagine what might go wrong. >> See above. It is not designed for the use case of dynamic container DNs >> which involves components not derived from the input. > > Honza I think it would have been very useful to have a design page before sending a patch. It is then easier to make design decisions without having to dig into the patch. Thank you, Martin From jcholast at redhat.com Mon Sep 23 07:57:21 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 23 Sep 2013 09:57:21 +0200 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <523FEB3C.2020408@redhat.com> References: <523200E9.5010304@redhat.com> <523AFBA2.9070000@redhat.com> <523AFF92.6070805@redhat.com> <523FEB3C.2020408@redhat.com> Message-ID: <523FF461.8010506@redhat.com> On 23.9.2013 09:18, Martin Kosek wrote: > On 09/19/2013 03:43 PM, Ana Krivokapic wrote: >> On 09/19/2013 03:26 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 12.9.2013 19:59, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> The design document for $SUBJECT can be found at: >>>> http://www.freeipa.org/page/V3/Automember_rebuild_membership >>>> >>>> Related tickets: >>>> https://fedorahosted.org/freeipa/ticket/3752 >>>> https://fedorahosted.org/freeipa/ticket/3928 >>>> >>>> Thoughts, comments, questions welcome. >>>> >>> >>> I don't think naming the commands user-automember-rebuild and >>> host-automember-rebuild commands is correct. The names imply they are methods >>> of user/host, but they don't directly do anything to user/host objects. I >>> would prefer if they were kept in the automember namespace where they >>> logically belong (automember-rebuild-user and automember-rebuild-host perhaps?) >>> >>> Honza >>> >> >> That makes sense... I don't have a strong preference one way or other. So if >> other agree with this suggestion, I will change it. > > I think Honza's comment makes sense. We can merge the functionality to > automember-rebuild command: > > $ ipa automember-rebuild --type=group [ENTRY] > $ ipa automember-rebuild --type=hostgroup [ENTRY] > > If no ENTRY is specified, it would run rebuild for all entries. If ENTRY is > specified, it would use it as Primary Key the entry - user uid or group name. > > This way the API should be consistent with the rest of the automember plugin. > > Makes sense? Yes, but I think the "--type=group " part might be confusing. What about: $ ipa automember-rebuild --type=group --users --users ... $ ipa automember-rebuild --type=hostgroup --hosts --hosts ... ? The --users and --hosts parameters are inspired by group-add-member and hostgroup-add-member. Also, the value of --type can be inferred, so it does not have to be explicitly specified: $ ipa automember-rebuild --users --users ... $ ipa automember-rebuild --hosts --hosts ... > > Martin > -- Jan Cholasta From abokovoy at redhat.com Mon Sep 23 08:15:09 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 23 Sep 2013 11:15:09 +0300 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <523FF024.4010300@redhat.com> References: <20130919190837.GC4216@redhat.com> <523BF6F5.1040803@redhat.com> <20130920073606.GF4216@redhat.com> <523C25ED.3010702@redhat.com> <20130920105516.GH4216@redhat.com> <523C388E.2050008@redhat.com> <523FF024.4010300@redhat.com> Message-ID: <20130923081509.GR4216@redhat.com> On Mon, 23 Sep 2013, Martin Kosek wrote: >>> However, we don't have trust type available so it needs to discovered >>> every time. This doesn't play well with the framework, it is simply not >>> expecting dynamic containers. >> >> This doesn't sound like a big obstacle to me. Right now the trust_type lookup >> is done in trust_show.execute() for some reason, which is not the best place to >> do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to >> make parent_object work. > >Yup, get_dn() is the method where object DN lookup should be done. See for >example host.py plugin get_dn method, we also do a dynamic lookup for correct >host name. I'll see if that would work. >the best way to implement dynamic DN gathering is the get_dn() method. That >way, it could be implemented in one place and all commands could take advantage >of it instead of re-implementing it several times in pre_callback - this is >just hackish. I'd suggest you look into the code. The commands use pre_callback for a different purpose than implementing dynamic DN gathering. >I think it would have been very useful to have a design page before sending a >patch. It is then easier to make design decisions without having to dig into >the patch. The design page is there for long time: http://www.freeipa.org/page/V3/Transitive_Trusts -- / Alexander Bokovoy From pviktori at redhat.com Mon Sep 23 10:08:58 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 23 Sep 2013 12:08:58 +0200 Subject: [Freeipa-devel] [PATCHES] 0177-0179 Add missing dict methods to CIDict In-Reply-To: <523FEB2B.3050507@redhat.com> References: <51113B3F.3070808@redhat.com> <51237565.1040404@redhat.com> <5124FBBB.6080801@redhat.com> <523871A7.9050506@redhat.com> <523995EB.9010706@redhat.com> <523FEB2B.3050507@redhat.com> Message-ID: <5240133A.3020105@redhat.com> On 09/23/2013 09:18 AM, Jan Cholasta wrote: > On 18.9.2013 14:00, Petr Viktorin wrote: >> On 09/17/2013 05:13 PM, Jan Cholasta wrote: >>> On 20.2.2013 17:37, Petr Viktorin wrote: >>>> On 02/19/2013 01:51 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 5.2.2013 18:02, Petr Viktorin wrote: >>>>>> CIDict, our case-insensitive dictionary, inherits from dict but did >>>>>> not >>>>>> reimplement the full dict interface. Calling the missing methods >>>>>> silently invoked case-sensitive behavior. Our code seems to avoid >>>>>> that, >>>>>> but it's a bit of a minefield for new development. >>>>>> >>>>>> Patch 119 adds the missing dict methods (except >>>>>> view{items,keys,values}(), which now raise errors), and adds tests. >>>>> >>>>> Can you please also add the (obj, **kwargs) and (**kwargs) variants of >>>>> __init__ and update? >>>> >>>> Added, thanks for the catch. >>>> >>>>> >>>>>> >>>>>> >>>>>> Patches 117-118 modernize the testsuite a bit (these have been >>>>>> sitting >>>>>> in my queue for a while, I think now is a good time to submit them): >>>>>> The first one moves some old tests from the main code tree to tests/. >>>>>> (The adtrust_install test wasn't run before, this move makes nose >>>>>> notice >>>>>> it). >>>>>> The second converts CIDict's unittest-based suite to nose. >>>>>> >>>>> >>>>> Honza >>>>> >>>> >>>> >>> >>> Whoa, I totally forgot about these patches! >>> >>> Can you please rebase them? >> >> Sure! >> >>> One more comment: >>> >>> Document that CIDict.copy() returns a plain dict. >>> >>> Why does it return a plain dict? I think it should return a CIDict, >>> otherwise it is not actually a copy, right? >> >> I wanted to keep the existing (intended) functionality. >> But since we don't actually use CIDict.copy() anywhere any more, I've >> made the change. > > Thanks. > >> >> P.S. I recently came across a bug in python-ldap where something like >> CIDict({'cn': ['name1', 'name2'], 'cN': ['name3']}) will throw away some >> of the values. >> This is expected at the CIDict level, but if you're working with dicts >> of lists it's something to keep an eye out for. >> > > This is a good point. IIRC when you use such a dict in python-ldap, it > will fail with TYPE_OR_VALUE_EXISTS. I think we should raise an error in > CIDict as well if such a dict is used in __init__() and update(), as > this kind of error is very hard to track otherwise. > > Honza > Right. Here's a patch that does that. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0280.3-Detect-updating-CIDict-with-duplicate-keys.patch Type: text/x-patch Size: 3917 bytes Desc: not available URL: From simo at redhat.com Mon Sep 23 12:12:29 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 23 Sep 2013 08:12:29 -0400 Subject: [Freeipa-devel] [PATCH] #3859: Better mechanism to retrieve keytabs In-Reply-To: <523FE712.80108@redhat.com> References: <1379705747.30999.25.camel@willson.li.ssimo.org> <523FE712.80108@redhat.com> Message-ID: <1379938349.17271.32.camel@willson.li.ssimo.org> On Mon, 2013-09-23 at 09:00 +0200, Petr Spacek wrote: > On 20.9.2013 21:35, Simo Sorce wrote: > > This patch set is an initial implementation of ticket #3859 > > > > It seem to be working fine in my initial testing but I have not yet > > tested all cases. > > > > However I wonted to throw it on the list to get some initial feedback > > about the choices I made wrt access control and ipa-getkeytab flags and > > default behavior. > > > > In particular, the current patch set would require us to make > > host/service keytabs readable by the requesting party (whoever that is, > > admin or host itself) in order to allow it to get back the actual > > keytab. I am not sure this is ideal. Also write access to the keytab is > > still all is needed to allow someone to change it. > > > > Neither is ideal, but it was simpler as a first implementation. In > > particular I think we should allow either permission indipendently, and > > it should be something an admin can change. However I do not like > > allowing normal writes or reads to these attributes, mostly because w/o > > access to the master key nobody can really make sense of actually > > reading out the contents of KrbPrincipalKey or could write a blob that > > can be successfully decrypted. > > > > So I was wondering if we might want to prevent both reading and writing > > via LDAP (except via extended operations) and instead use another method > > to determine access patterns. > > > > As for ipa-getkeytab is everyone ok with tryin the new method first and > > always falling back to the old one (if a password has been provided) ? > > > > Simo. > > I was always curious why we don't use normal kadmin protocol? :-) Kadmin won't respect LDAP based ACIs, it always operate as "root" against LDAP, and has it's own simple ACL file. We want to be able to easily manage and delegate access to keytab creation. We might try to change the kadmin code to impersonate the user but I think it would be invasive, I never seriously looked into it though. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Mon Sep 23 13:19:00 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 23 Sep 2013 15:19:00 +0200 Subject: [Freeipa-devel] [PATCH 0015] Add support for managing user auth types In-Reply-To: <1379533870.1629.5.camel@localhost> References: <1378353865.19352.9.camel@localhost> <522DCE8B.9040009@redhat.com> <1379533870.1629.5.camel@localhost> Message-ID: <52403FC4.6070807@redhat.com> On 09/18/2013 09:51 PM, Nathaniel McCallum wrote: > On Mon, 2013-09-09 at 15:35 +0200, Petr Viktorin wrote: >> On 09/05/2013 06:04 AM, Nathaniel McCallum wrote: >>> patch attached >> >> Thanks, some comments below. >> >> Git complains about trailing whitespace in the patch, please strip it. > > Fixed. > >>> freeipa-npmccallum-0015-Add-support-for-managing-user-auth-types.patch >>> >>> >>> >From 757436ccc431d26a3e62de830dad0b107a6c48ff Mon Sep 17 00:00:00 2001 >>> From: Nathaniel McCallum >>> Date: Wed, 4 Sep 2013 23:35:36 -0400 >>> Subject: [PATCH] Add support for managing user auth types >>> >>> https://fedorahosted.org/freeipa/ticket/3368 >>> --- >>> ipalib/plugins/config.py | 16 ++++++++++++++++ >>> ipalib/plugins/user.py | 32 ++++++++++++++++++++++---------- >>> 2 files changed, 38 insertions(+), 10 deletions(-) >>> >>> diff --git a/ipalib/plugins/config.py b/ipalib/plugins/config.py >>> index b9cf05016bf80cd48134cca5a50cdca7db423ca9..692ca22db70eb9a81a49eab6dc1e23284c8a9946 100644 >>> @@ -210,6 +218,14 @@ class config_mod(LDAPUpdate): >>> >>> def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): >>> assert isinstance(dn, DN) >>> + >>> + if 'ipauserauthtype' in entry_attrs: >>> + if 'objectclass' not in entry_attrs: >>> + (_dn, _entry_attrs) = ldap.get_entry(dn, ['objectclass']) >>> + entry_attrs['objectclass'] = _entry_attrs['objectclass'] >>> + if 'ipauserauthtypeclass' not in entry_attrs['objectclass']: >>> + entry_attrs['objectclass'].append('ipauserauthtypeclass') >> >> Shouldn't we rather add ipaUserAuthType to the ipaGuiConfig objectclass? > > No. The ipaUserAuthTypeClass is generic and will be used several places. > >> If not, we should still update ipaConfig on IPA update update rather >> than here; install/updates/50-ipaconfig.update would be a good place. > > Fixed. > >>> diff --git a/ipalib/plugins/user.py b/ipalib/plugins/user.py >>> index 471981f48204209753eda2fb994d4c653dca0fa2..02f62120d281a873dfd9c21e1b855b112cca05a4 100644 >> [...] >>> @@ -633,14 +640,19 @@ class user_mod(LDAPUpdate): >>> entry_attrs['userpassword'] = ipa_generate_password(user_pwdchars) >>> # save the password so it can be displayed in post_callback >>> setattr(context, 'randompassword', entry_attrs['userpassword']) >>> + >>> + if 'objectclass' not in entry_attrs: >>> + (_dn, _entry_attrs) = ldap.get_entry(dn, ['objectclass']) >>> + entry_attrs['objectclass'] = _entry_attrs['objectclass'] >> >> The framework is forcing some pretty ugly code here. >> I've filed https://fedorahosted.org/freeipa/ticket/3914 to simplify this >> in the future. >> >> >> Just a note, it's no longer necessary to use (_dn, _entry_attrs) here; >> ldap.get_entry() now returns a dict-like entry directly so you can use: >> >> _entry = ldap.get_entry(dn, ['objectclass']) >> entry_attrs['objectclass'] = _entry['objectclass'] >> >> In fact, unpacking the entry into a tuple returns the DN and the entry >> object itself. This: >> (dn, entry) = ldap.get_entry(...) >> is exactly equivalent to: >> entry = ldap.get_entry(...) >> dn = entry.dn >> but the former is deprecated. > > Fixed. Great, we're getting close! Please send patches in `git format-patch` style (they include commit info). Also, please bump the API revision in VERSION since API.txt was changed. When adding the objectclass in user, it is possible that the user doesn't exist. You should call handle_not_found in this case so the appropriate error message is generated. I ended up doing this for testing, squash in the patch if you want. There's another test failure when trying to rename a manager user. I didn't investigate in detail why that happens. I'm attaching the tests I used, do they look OK? -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0281-Add-tests-for-user-auth-type-management.patch Type: text/x-patch Size: 5027 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: squash-Add-support-for-managing-user-auth-types.patch Type: text/x-patch Size: 1090 bytes Desc: not available URL: From abokovoy at redhat.com Mon Sep 23 14:18:41 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 23 Sep 2013 17:18:41 +0300 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <20130923081509.GR4216@redhat.com> References: <20130919190837.GC4216@redhat.com> <523BF6F5.1040803@redhat.com> <20130920073606.GF4216@redhat.com> <523C25ED.3010702@redhat.com> <20130920105516.GH4216@redhat.com> <523C388E.2050008@redhat.com> <523FF024.4010300@redhat.com> <20130923081509.GR4216@redhat.com> Message-ID: <20130923141841.GS4216@redhat.com> On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >On Mon, 23 Sep 2013, Martin Kosek wrote: >>>>However, we don't have trust type available so it needs to discovered >>>>every time. This doesn't play well with the framework, it is simply not >>>>expecting dynamic containers. >>> >>>This doesn't sound like a big obstacle to me. Right now the trust_type lookup >>>is done in trust_show.execute() for some reason, which is not the best place to >>>do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to >>>make parent_object work. >> >>Yup, get_dn() is the method where object DN lookup should be done. See for >>example host.py plugin get_dn method, we also do a dynamic lookup for correct >>host name. >I'll see if that would work. > >>the best way to implement dynamic DN gathering is the get_dn() method. That >>way, it could be implemented in one place and all commands could take advantage >>of it instead of re-implementing it several times in pre_callback - this is >>just hackish. >I'd suggest you look into the code. The commands use pre_callback for a >different purpose than implementing dynamic DN gathering. > >>I think it would have been very useful to have a design page before sending a >>patch. It is then easier to make design decisions without having to dig into >>the patch. >The design page is there for long time: >http://www.freeipa.org/page/V3/Transitive_Trusts Ok, here is new version of the patch and updated version of my 0117 patch as Sumit noticed I've sent wrong version. -- / Alexander Bokovoy -------------- next part -------------- >From e2b43dae3b413fed303e7bde08e7868a9487ccbe Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 11 Sep 2013 21:34:55 +0300 Subject: [PATCH 1/2] ipaserver/dcerpc.py: populate forest trust information using realmdomains Use realmdomains information to prepopulate forest trust info. As result, all additional domains should now be enabled from the beginning, unless they really conflict with existing DNS domains on AD side. https://fedorahosted.org/freeipa/ticket/3919 --- ipaserver/dcerpc.py | 113 +++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 95 insertions(+), 18 deletions(-) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index bd8f5aa..c24230b 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -39,7 +39,7 @@ import uuid from samba import param from samba import credentials from samba.dcerpc import security, lsa, drsblobs, nbt, netlogon -from samba.ndr import ndr_pack +from samba.ndr import ndr_pack, ndr_print from samba import net import samba import random @@ -684,6 +684,12 @@ class DomainValidator(object): self._info[domain] = info return info +def string_to_array(what): + blob = [0] * len(what) + + for i in range(len(what)): + blob[i] = ord(what[i]) + return blob class TrustDomainInstance(object): @@ -698,6 +704,7 @@ class TrustDomainInstance(object): self._pipe = None self._policy_handle = None self.read_only = False + self.ftinfo_records = None def __gen_lsa_connection(self, binding): if self.creds is None: @@ -827,12 +834,6 @@ class TrustDomainInstance(object): def arcfour_encrypt(key, data): c = RC4.RC4(key) return c.update(data) - def string_to_array(what): - blob = [0] * len(what) - - for i in range(len(what)): - blob[i] = ord(what[i]) - return blob password_blob = string_to_array(trustdom_secret.encode('utf-16-le')) @@ -876,6 +877,53 @@ class TrustDomainInstance(object): self.auth_info = auth_info + def generate_ftinfo(self, another_domain): + """ + Generates TrustDomainInfoFullInfo2Internal structure + This structure allows to pass information about all domains associated + with the another domain's realm. + + Only top level name and top level name exclusions are handled here. + """ + if not another_domain.ftinfo_records: + return + + ftinfo_records = [] + info = lsa.ForestTrustInformation() + + for rec in another_domain.ftinfo_records: + record = lsa.ForestTrustRecord() + record.flags = 0 + record.time = rec['rec_time'] + record.type = rec['rec_type'] + record.forest_trust_data.string = rec['rec_name'] + ftinfo_records.append(record) + + info.count = len(ftinfo_records) + info.entries = ftinfo_records + return info + + def update_ftinfo(self, another_domain): + """ + Updates forest trust information in this forest corresponding + to the another domain's information. + """ + try: + if another_domain.ftinfo_records: + ftinfo = self.generate_ftinfo(another_domain) + # Set forest trust information -- we do it only against AD DC as + # smbd already has the information about itself + ldname = lsa.StringLarge() + ldname.string = another_domain.info['dns_domain'] + collision_info = self._pipe.lsaRSetForestTrustInformation(self._policy_handle, + ldname, + lsa.LSA_FOREST_TRUST_DOMAIN_INFO, + ftinfo, 0) + if collision_info: + root_logger.error("When setting forest trust information, got collision info back:\n%s" % (ndr_print(collision_info))) + except RuntimeError, e: + # We can ignore the error here -- setting up name suffix routes may fail + pass def establish_trust(self, another_domain, trustdom_secret): """ @@ -883,6 +931,12 @@ class TrustDomainInstance(object): Input: another_domain -- instance of TrustDomainInstance, initialized with #retrieve call trustdom_secret -- shared secred used for the trust """ + if self.info['name'] == another_domain.info['name']: + # Check that NetBIOS names do not clash + raise errors.ValidationError(name=u'AD Trust Setup', + error=_('the IPA server and the remote domain cannot share the same ' + 'NetBIOS name: %s') % self.info['name']) + self.generate_auth(trustdom_secret) info = lsa.TrustDomainInfoInfoEx() @@ -893,12 +947,6 @@ class TrustDomainInstance(object): info.trust_type = lsa.LSA_TRUST_TYPE_UPLEVEL info.trust_attributes = lsa.LSA_TRUST_ATTRIBUTE_FOREST_TRANSITIVE - if self.info['name'] == info.netbios_name.string: - # Check that NetBIOS names do not clash - raise errors.ValidationError(name=u'AD Trust Setup', - error=_('the IPA server and the remote domain cannot share the same ' - 'NetBIOS name: %s') % self.info['name']) - try: dname = lsa.String() dname.string = another_domain.info['dns_domain'] @@ -911,12 +959,14 @@ class TrustDomainInstance(object): except RuntimeError, (num, message): raise assess_dcerpc_exception(num=num, message=message) + self.update_ftinfo(another_domain) + + # We should use proper trustdom handle in order to modify the + # trust settings. Samba insists this has to be done with LSA + # OpenTrustedDomain* calls, it is not enough to have a handle + # returned by the CreateTrustedDomainEx2 call. + trustdom_handle = self._pipe.OpenTrustedDomainByName(self._policy_handle, dname, security.SEC_FLAG_MAXIMUM_ALLOWED) try: - # We should use proper trustdom handle in order to modify the - # trust settings. Samba insists this has to be done with LSA - # OpenTrustedDomain* calls, it is not enough to have a handle - # returned by the CreateTrustedDomainEx2 call. - trustdom_handle = self._pipe.OpenTrustedDomainByName(self._policy_handle, dname, security.SEC_FLAG_MAXIMUM_ALLOWED) infoclass = lsa.TrustDomainInfoSupportedEncTypes() infoclass.enc_types = security.KERB_ENCTYPE_RC4_HMAC_MD5 infoclass.enc_types |= security.KERB_ENCTYPE_AES128_CTS_HMAC_SHA1_96 @@ -1016,6 +1066,32 @@ class TrustDomainJoins(object): # Otherwise, use anonymously obtained data self.remote_domain = rd + def get_realmdomains(self): + """ + Generate list of records for forest trust information about + our realm domains. Note that the list generated currently + includes only top level domains, no exclusion domains, and no TDO objects + as we handle the latter in a separte way + """ + if self.local_domain.read_only: + return + + self.local_domain.ftinfo_records = [] + + realm_domains = self.api.Command.realmdomains_show()['result'] + trustconfig = self.api.Command.trustconfig_show()['result'] + # Use realmdomains' modification timestamp to judge records last update time + (dn, entry_attrs) = self.api.Backend.ldap2.get_entry(realm_domains['dn'], ['modifyTimestamp']) + # Convert the timestamp to Windows 64-bit timestamp format + trust_timestamp = long(time.mktime(time.strptime(entry_attrs['modifytimestamp'][0][:14], "%Y%m%d%H%M%S"))*1e7+116444736000000000) + + for dom in realm_domains['associateddomain']: + ftinfo = dict() + ftinfo['rec_name'] = dom + ftinfo['rec_time'] = trust_timestamp + ftinfo['rec_type'] = lsa.LSA_FOREST_TRUST_TOP_LEVEL_NAME + self.local_domain.ftinfo_records.append(ftinfo) + def join_ad_full_credentials(self, realm, realm_server, realm_admin, realm_passwd): if not self.configured: return None @@ -1030,6 +1106,7 @@ class TrustDomainJoins(object): if not self.remote_domain.read_only: trustdom_pass = samba.generate_random_password(128, 128) + self.get_realmdomains() self.remote_domain.establish_trust(self.local_domain, trustdom_pass) self.local_domain.establish_trust(self.remote_domain, trustdom_pass) result = self.remote_domain.verify_trust(self.local_domain) -- 1.8.3.1 -------------- next part -------------- >From 2bec4dd4709a31d6dfbfc76c5b747ad4a290d742 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 18 Sep 2013 17:04:19 +0200 Subject: [PATCH 2/2] trusts: support subdomains in a forest Add IPA CLI to manage trust domains. ipa trustdomain-fetch -- fetch list of subdomains from AD side and add new ones to IPA ipa trustdomain-find -- show all available domains ipa trustdomain-del -- remove domain from IPA view about IPA KDC needs also information for authentication paths to subdomains in case they are not hierarchical under AD forest trust root. This information is managed via capaths section in krb5.conf. SSSD should be able to generate it once ticket https://fedorahosted.org/sssd/ticket/2093 is resolved. part of https://fedorahosted.org/freeipa/ticket/3909 --- API.txt | 72 ++++++++++++++ ipalib/plugins/trust.py | 248 ++++++++++++++++++++++++++++++++++++++---------- ipaserver/dcerpc.py | 54 +++++++++++ 3 files changed, 323 insertions(+), 51 deletions(-) diff --git a/API.txt b/API.txt index 761d1d1..3239f53 100644 --- a/API.txt +++ b/API.txt @@ -3497,6 +3497,78 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: Output('value', , None) +command: trustdomain_create +args: 3,9,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('trust?') +arg: Str('cn?', cli_name='domain', primary_key=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('ipantflatname', attribute=True, cli_name='flat_name', multivalue=False, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, cli_name='sid', multivalue=False, required=False) +option: Str('ipanttrustpartner?') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', values=(u'ad',)) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trustdomain_del +args: 3,2,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('trust?') +arg: Str('cn?', cli_name='domain', primary_key=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trustdomain_fetch +args: 2,4,2 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('trust?') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +command: trustdomain_find +args: 3,8,4 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('criteria?', noextrawhitespace=False) +arg: Str('trust?') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn?', cli_name='domain', primary_key=True) +option: Str('ipantflatname', attribute=True, autofill=False, cli_name='flat_name', multivalue=False, query=True, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='sid', multivalue=False, query=True, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: trustdomain_mod +args: 3,10,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('trust?') +arg: Str('cn?', cli_name='domain', primary_key=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('ipantflatname', attribute=True, autofill=False, cli_name='flat_name', multivalue=False, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='sid', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', values=(u'ad',)) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('value', , None) command: user_add args: 1,35,3 arg: Str('uid', attribute=True, cli_name='login', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 3c117b4..ed50952 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -181,6 +181,13 @@ def trust_status_string(level): string = _trust_status_dict.get(level, _trust_type_dict_unknown) return unicode(string) +def make_trust_dn(env, trust_type, dn): + assert isinstance(dn, DN) + if trust_type: + container_dn = DN(('cn', trust_type), env.container_trusts, env.basedn) + return DN(dn, container_dn) + return dn + class trust(LDAPObject): """ Trust object. @@ -241,12 +248,24 @@ class trust(LDAPObject): raise errors.ValidationError(name=attr, error=_("invalid SID: %(value)s") % dict(value=value)) -def make_trust_dn(env, trust_type, dn): - assert isinstance(dn, DN) - if trust_type in trust.trust_types: - container_dn = DN(('cn', trust_type), env.container_trusts, env.basedn) - return DN(dn[0], container_dn) - return dn + def get_dn(self, *keys, **kwargs): + sdn = map(lambda x: ('cn', x), filter(lambda x: x, keys)) + sdn.reverse() + trust_type = kwargs.get('trust_type') + if not trust_type: + for ttype in self.trust_types: + dn=make_trust_dn(self.env, ttype, DN(*sdn)) + try: + object_exists = self.backend.get_entry(dn, ['']) + return object_exists.dn + except errors.NotFound: + pass + # if no trust object of any type exist, default to 'ad' + # this is required for *_add calls. + trust_type = u'ad' + + dn=make_trust_dn(self.env, trust_type, DN(*sdn)) + return dn class trust_add(LDAPCreate): __doc__ = _(''' @@ -576,10 +595,13 @@ sides. def execute_ad(self, full_join, *keys, **options): # Join domain using full credentials and with random trustdom # secret (will be generated by the join method) - try: - api.Command['trust_show'](keys[-1]) + + # First see if the trust is already in place + # Force retrieval of the trust object by not passing trust_type + dn = self.obj.get_dn(keys[-1], {}) + if dn: summary = _('Re-established trust to domain "%(value)s"') - except errors.NotFound: + else: summary = self.msg_summary # 1. Full access to the remote domain. Use admin credentials and @@ -652,14 +674,6 @@ class trust_del(LDAPDelete): msg_summary = _('Deleted trust "%(value)s"') - def pre_callback(self, ldap, dn, *keys, **options): - assert isinstance(dn, DN) - try: - result = self.api.Command.trust_show(keys[-1]) - except errors.NotFound, e: - self.obj.handle_not_found(*keys) - return result['result']['dn'] - class trust_mod(LDAPUpdate): __doc__ = _(""" Modify a trust (for future use). @@ -673,16 +687,10 @@ class trust_mod(LDAPUpdate): def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): assert isinstance(dn, DN) - result = None - try: - result = self.api.Command.trust_show(keys[-1]) - except errors.NotFound, e: - self.obj.handle_not_found(*keys) self.obj.validate_sid_blacklists(entry_attrs) - # TODO: we found the trust object, now modify it - return result['result']['dn'] + return dn class trust_find(LDAPSearch): __doc__ = _('Search for trusts.') @@ -696,8 +704,10 @@ class trust_find(LDAPSearch): # Since all trusts types are stored within separate containers under 'cn=trusts', # search needs to be done on a sub-tree scope def pre_callback(self, ldap, filters, attrs_list, base_dn, scope, *args, **options): - assert isinstance(base_dn, DN) - return (filters, base_dn, ldap.SCOPE_SUBTREE) + # list only trust, not trust domains + trust_filter = '(ipaNTSupportedEncryptionTypes=*)' + filter = ldap.combine_filters((filters, trust_filter), rules=ldap.MATCH_ALL) + return (filter, base_dn, ldap.SCOPE_SUBTREE) def post_callback(self, ldap, entries, truncated, *args, **options): if options.get('pkey_only', False): @@ -705,7 +715,7 @@ class trust_find(LDAPSearch): for entry in entries: (dn, attrs) = entry - + # Translate ipanttrusttype to trusttype if --raw not used if not options.get('raw', False): attrs['trusttype'] = trust_type_string(attrs['ipanttrusttype'][0]) @@ -718,30 +728,6 @@ class trust_show(LDAPRetrieve): has_output_params = LDAPRetrieve.has_output_params + trust_output_params +\ (Str('ipanttrusttype'), Str('ipanttrustdirection')) - def execute(self, *keys, **options): - error = None - result = None - for trust_type in trust.trust_types: - options['trust_show_type'] = trust_type - try: - result = super(trust_show, self).execute(*keys, **options) - except errors.NotFound, e: - result = None - error = e - if result: - break - if error or not result: - self.obj.handle_not_found(*keys) - - return result - - def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): - assert isinstance(dn, DN) - if 'trust_show_type' in options: - return make_trust_dn(self.env, options['trust_show_type'], dn) - - return dn - def post_callback(self, ldap, dn, entry_attrs, *keys, **options): # Translate ipanttrusttype to trusttype @@ -1078,3 +1064,163 @@ class sidgen_was_run(Command): return dict(result=True) api.register(sidgen_was_run) + +class trustdomain(LDAPObject): + """ + Object representing a domain of the AD trust. + """ + parent_object = 'trust' + trust_type_idx = {'2':u'ad'} + object_name = _('trust domain') + object_name_plural = _('trust domains') + object_class = ['ipaNTTrustedDomain'] + default_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', 'ipanttrustpartner'] + search_display_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', ] + + label = _('Trusted domains') + label_singular = _('Trusted domain') + + trustdomain_args = ( + Str('trust?', + label=_('AD trust'), + flags=('virtual_attribute',), + ), + Str('cn?', + label=_('Domain name'), + cli_name='domain', + primary_key=True, + flags=('req_update','req_create',), + ), + ) + + takes_params = ( + Str('ipantflatname?', + cli_name='flat_name', + label=_('Domain NetBIOS name'), + ), + Str('ipanttrusteddomainsid?', + cli_name='sid', + label=_('Domain Security Identifier'), + ), + ) +api.register(trustdomain) + +class trustdomain_find(LDAPSearch): + __doc__ = _('Search domains of the trust') + + takes_args = trustdomain.trustdomain_args[0] + takes_options = LDAPSearch.takes_options + (trustdomain.trustdomain_args[1],) + + def pre_callback(self, ldap, filters, attrs_list, base_dn, scope, *args, **options): + return (filters, base_dn, ldap.SCOPE_SUBTREE) +api.register(trustdomain_find) + +class trustdomain_mod(LDAPUpdate): + __doc__ = _('Modify trustdomain of the trust') + + NO_CLI = True + takes_args = trustdomain.trustdomain_args + takes_options = LDAPUpdate.takes_options + (_trust_type_option,) + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + args = filter(lambda x: x, keys) + if len(args) != 2: + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name and trust domain name are required to modify the trust domain')) + return dn +api.register(trustdomain_mod) + +class trustdomain_add(LDAPCreate): + __doc__ = _('Allow access from the trusted domain') + NO_CLI = True + + takes_args = trustdomain.trustdomain_args + takes_options = LDAPCreate.takes_options + (_trust_type_option, + Str('ipanttrustpartner?', + label=_('Trusted domain partner'), + ), + ) + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + args = filter(lambda x: x, keys) + if len(args) != 2: + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name and trust domain name are required to create the trust domain')) + if 'ipanttrustpartner' in options: + entry_attrs['ipanttrustpartner'] = [options['ipanttrustpartner']] + return dn +api.register(trustdomain_add) + +class trustdomain_del(LDAPDelete): + __doc__ = _('Remove infromation about the domain associated with the trust.') + + msg_summary = _('Removed information about the trusted domain "%(value)s"') + + takes_args = trustdomain.trustdomain_args + def pre_callback(self, ldap, dn, *keys, **options): + args = filter(lambda x: x, keys) + if len(args) != 2: + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name and trust domain name are required to delete the trust domain')) + return dn + + def execute(self, *keys, **options): + result = super(trustdomain_del, self).execute(*keys, **options) + result['value'] = keys[1] + return result + + +api.register(trustdomain_del) + +class trustdomain_fetch(LDAPRetrieve): + __doc__ = _('Refresh list of the domains associated with the trust') + + takes_args = (trustdomain.trustdomain_args[0]) + + has_output = ( + output.ListOfEntries('result'), + output.summary + ) + def execute(self, *keys, **options): + if not _bindings_installed: + raise errors.NotFound( + name=_('AD Trust setup'), + reason=_( + 'Cannot perform join operation without Samba 4 support ' + 'installed. Make sure you have installed server-trust-ad ' + 'sub-package of IPA' + ) + ) + if not keys[0]: + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name is required to fetch trust domains')) + + trust = self.api.Command.trust_show(keys[0], raw=True)['result'] + + trustinstance = ipaserver.dcerpc.TrustDomainJoins(self.api) + if not trustinstance.configured: + raise errors.NotFound( + name=_('AD Trust setup'), + reason=_( + 'Cannot perform join operation without own domain ' + 'configured. Make sure you have run ipa-adtrust-install ' + 'on the IPA server first' + ) + ) + domains = ipaserver.dcerpc.fetch_domains(self.api, trustinstance.local_flatname, trust['cn'][0]) + result = dict(result=[]) + if not domains: + result['summary'] = unicode(_('No trust domains were detected during refresh')) + return result + + for dom in domains: + dom['trust_type'] = self.obj.trust_type_idx[trust['ipanttrusttype'][0]] + try: + name = dom['cn'] + del dom['cn'] + res = self.api.Command.trustdomain_add(keys[0], name, **dom) + result['result'].append(res['result']) + except errors.DuplicateEntry: + # Ignore updating duplicate entries + pass + if len(result['result']) > 0: + result['summary'] = unicode(_('List of trust domains successfully refreshed')) + else: + result['summary'] = unicode(_('No new trust domains were found')) + return result +api.register(trustdomain_fetch) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index c24230b..af0e77e 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -1002,6 +1002,60 @@ class TrustDomainInstance(object): return True return False +def fetch_domains(api, mydomain, trustdomain): + trust_flags = dict( + NETR_TRUST_FLAG_IN_FOREST = 0x00000001, + NETR_TRUST_FLAG_OUTBOUND = 0x00000002, + NETR_TRUST_FLAG_TREEROOT = 0x00000004, + NETR_TRUST_FLAG_PRIMARY = 0x00000008, + NETR_TRUST_FLAG_NATIVE = 0x00000010, + NETR_TRUST_FLAG_INBOUND = 0x00000020, + NETR_TRUST_FLAG_MIT_KRB5 = 0x00000080, + NETR_TRUST_FLAG_AES = 0x00000100) + + trust_attributes = dict( + NETR_TRUST_ATTRIBUTE_NON_TRANSITIVE = 0x00000001, + NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x00000002, + NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x00000004, + NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x00000008, + NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x00000010, + NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x00000020, + NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x00000040) + + domval = DomainValidator(api) + (ccache_name, principal) = domval.kinit_as_http(trustdomain) + if ccache_name: + with installutils.private_ccache(path=ccache_name): + td = TrustDomainInstance('') + td.parm.set('workgroup', mydomain) + td.creds = credentials.Credentials() + td.creds.set_kerberos_state(credentials.MUST_USE_KERBEROS) + td.creds.guess(td.parm) + netrc = net.Net(creds=td.creds, lp=td.parm) + try: + result = netrc.finddc(domain=trustdomain, flags=nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_DS) + except RuntimeError, e: + raise assess_dcerpc_exception(message=str(e)) + if not result: + return None + td.retrieve(unicode(result.pdc_dns_name)) + + netr_pipe = netlogon.netlogon(td.binding, td.parm, td.creds) + domains = netr_pipe.netr_DsrEnumerateDomainTrusts(td.binding, 1) + + result = [] + for t in domains.array: + if ((t.trust_attributes & trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and + (t.trust_flags & trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): + res = dict() + res['cn'] = unicode(t.dns_name) + res['ipantflatname'] = unicode(t.netbios_name) + res['ipanttrusteddomainsid'] = unicode(t.sid) + res['ipanttrustpartner'] = res['cn'] + result.append(res) + return result + + class TrustDomainJoins(object): def __init__(self, api): self.api = api -- 1.8.3.1 From abokovoy at redhat.com Mon Sep 23 15:04:22 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 23 Sep 2013 18:04:22 +0300 Subject: [Freeipa-devel] [PATCH] 0118 add support for subdomains In-Reply-To: <20130923141841.GS4216@redhat.com> References: <20130919190837.GC4216@redhat.com> <523BF6F5.1040803@redhat.com> <20130920073606.GF4216@redhat.com> <523C25ED.3010702@redhat.com> <20130920105516.GH4216@redhat.com> <523C388E.2050008@redhat.com> <523FF024.4010300@redhat.com> <20130923081509.GR4216@redhat.com> <20130923141841.GS4216@redhat.com> Message-ID: <20130923150422.GT4216@redhat.com> On Mon, 23 Sep 2013, Alexander Bokovoy wrote: > On Mon, 23 Sep 2013, Alexander Bokovoy wrote: >> On Mon, 23 Sep 2013, Martin Kosek wrote: >>>>> However, we don't have trust type available so it needs to discovered >>>>> every time. This doesn't play well with the framework, it is simply not >>>>> expecting dynamic containers. >>>> >>>> This doesn't sound like a big obstacle to me. Right now the trust_type lookup >>>> is done in trust_show.execute() for some reason, which is not the best place to >>>> do it IMHO. Doing it in trust.get_dn() instead should simplify things enough to >>>> make parent_object work. >>> >>> Yup, get_dn() is the method where object DN lookup should be done. See for >>> example host.py plugin get_dn method, we also do a dynamic lookup for correct >>> host name. >> I'll see if that would work. >> >>> the best way to implement dynamic DN gathering is the get_dn() method. That >>> way, it could be implemented in one place and all commands could take advantage >>> of it instead of re-implementing it several times in pre_callback - this is >>> just hackish. >> I'd suggest you look into the code. The commands use pre_callback for a >> different purpose than implementing dynamic DN gathering. >> >>> I think it would have been very useful to have a design page before sending a >>> patch. It is then easier to make design decisions without having to dig into >>> the patch. >> The design page is there for long time: >> http://www.freeipa.org/page/V3/Transitive_Trusts > Ok, here is new version of the patch and updated version of my 0117 > patch as Sumit noticed I've sent wrong version. Ok, here is updated 0118 which fixes API.txt change for trustdomain_add -- I renamed trustdomain_create to trustdomain_add but forgot to rerun makeapi. -- / Alexander Bokovoy -------------- next part -------------- >From 2bec4dd4709a31d6dfbfc76c5b747ad4a290d742 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 18 Sep 2013 17:04:19 +0200 Subject: [PATCH 2/2] trusts: support subdomains in a forest Add IPA CLI to manage trust domains. ipa trustdomain-fetch -- fetch list of subdomains from AD side and add new ones to IPA ipa trustdomain-find -- show all available domains ipa trustdomain-del -- remove domain from IPA view about IPA KDC needs also information for authentication paths to subdomains in case they are not hierarchical under AD forest trust root. This information is managed via capaths section in krb5.conf. SSSD should be able to generate it once ticket https://fedorahosted.org/sssd/ticket/2093 is resolved. part of https://fedorahosted.org/freeipa/ticket/3909 --- API.txt | 72 ++++++++++++++ ipalib/plugins/trust.py | 248 ++++++++++++++++++++++++++++++++++++++---------- ipaserver/dcerpc.py | 54 +++++++++++ 3 files changed, 323 insertions(+), 51 deletions(-) diff --git a/API.txt b/API.txt index 761d1d1..3239f53 100644 --- a/API.txt +++ b/API.txt @@ -3497,6 +3497,78 @@ option: Str('version?', exclude='webui') output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) output: Output('summary', (, ), None) output: Output('value', , None) +command: trustdomain_add +args: 3,9,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('trust?') +arg: Str('cn?', cli_name='domain', primary_key=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('ipantflatname', attribute=True, cli_name='flat_name', multivalue=False, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, cli_name='sid', multivalue=False, required=False) +option: Str('ipanttrustpartner?') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', values=(u'ad',)) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trustdomain_del +args: 3,2,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('trust?') +arg: Str('cn?', cli_name='domain', primary_key=True) +option: Flag('continue', autofill=True, cli_name='continue', default=False) +option: Str('version?', exclude='webui') +output: Output('result', , None) +output: Output('summary', (, ), None) +output: Output('value', , None) +command: trustdomain_fetch +args: 2,4,2 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('trust?') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('version?', exclude='webui') +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +command: trustdomain_find +args: 3,8,4 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('criteria?', noextrawhitespace=False) +arg: Str('trust?') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('cn?', cli_name='domain', primary_key=True) +option: Str('ipantflatname', attribute=True, autofill=False, cli_name='flat_name', multivalue=False, query=True, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='sid', multivalue=False, query=True, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Int('sizelimit?', autofill=False, minvalue=0) +option: Int('timelimit?', autofill=False, minvalue=0) +option: Str('version?', exclude='webui') +output: Output('count', , None) +output: ListOfEntries('result', (, ), Gettext('A list of LDAP entries', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('truncated', , None) +command: trustdomain_mod +args: 3,10,3 +arg: Str('trustcn', cli_name='trust', query=True, required=True) +arg: Str('trust?') +arg: Str('cn?', cli_name='domain', primary_key=True) +option: Str('addattr*', cli_name='addattr', exclude='webui') +option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui') +option: Str('delattr*', cli_name='delattr', exclude='webui') +option: Str('ipantflatname', attribute=True, autofill=False, cli_name='flat_name', multivalue=False, required=False) +option: Str('ipanttrusteddomainsid', attribute=True, autofill=False, cli_name='sid', multivalue=False, required=False) +option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui') +option: Flag('rights', autofill=True, default=False) +option: Str('setattr*', cli_name='setattr', exclude='webui') +option: StrEnum('trust_type', autofill=True, cli_name='type', default=u'ad', values=(u'ad',)) +option: Str('version?', exclude='webui') +output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None)) +output: Output('summary', (, ), None) +output: Output('value', , None) command: user_add args: 1,35,3 arg: Str('uid', attribute=True, cli_name='login', maxlength=255, multivalue=False, pattern='^[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?$', primary_key=True, required=True) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 3c117b4..ed50952 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -181,6 +181,13 @@ def trust_status_string(level): string = _trust_status_dict.get(level, _trust_type_dict_unknown) return unicode(string) +def make_trust_dn(env, trust_type, dn): + assert isinstance(dn, DN) + if trust_type: + container_dn = DN(('cn', trust_type), env.container_trusts, env.basedn) + return DN(dn, container_dn) + return dn + class trust(LDAPObject): """ Trust object. @@ -241,12 +248,24 @@ class trust(LDAPObject): raise errors.ValidationError(name=attr, error=_("invalid SID: %(value)s") % dict(value=value)) -def make_trust_dn(env, trust_type, dn): - assert isinstance(dn, DN) - if trust_type in trust.trust_types: - container_dn = DN(('cn', trust_type), env.container_trusts, env.basedn) - return DN(dn[0], container_dn) - return dn + def get_dn(self, *keys, **kwargs): + sdn = map(lambda x: ('cn', x), filter(lambda x: x, keys)) + sdn.reverse() + trust_type = kwargs.get('trust_type') + if not trust_type: + for ttype in self.trust_types: + dn=make_trust_dn(self.env, ttype, DN(*sdn)) + try: + object_exists = self.backend.get_entry(dn, ['']) + return object_exists.dn + except errors.NotFound: + pass + # if no trust object of any type exist, default to 'ad' + # this is required for *_add calls. + trust_type = u'ad' + + dn=make_trust_dn(self.env, trust_type, DN(*sdn)) + return dn class trust_add(LDAPCreate): __doc__ = _(''' @@ -576,10 +595,13 @@ sides. def execute_ad(self, full_join, *keys, **options): # Join domain using full credentials and with random trustdom # secret (will be generated by the join method) - try: - api.Command['trust_show'](keys[-1]) + + # First see if the trust is already in place + # Force retrieval of the trust object by not passing trust_type + dn = self.obj.get_dn(keys[-1], {}) + if dn: summary = _('Re-established trust to domain "%(value)s"') - except errors.NotFound: + else: summary = self.msg_summary # 1. Full access to the remote domain. Use admin credentials and @@ -652,14 +674,6 @@ class trust_del(LDAPDelete): msg_summary = _('Deleted trust "%(value)s"') - def pre_callback(self, ldap, dn, *keys, **options): - assert isinstance(dn, DN) - try: - result = self.api.Command.trust_show(keys[-1]) - except errors.NotFound, e: - self.obj.handle_not_found(*keys) - return result['result']['dn'] - class trust_mod(LDAPUpdate): __doc__ = _(""" Modify a trust (for future use). @@ -673,16 +687,10 @@ class trust_mod(LDAPUpdate): def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): assert isinstance(dn, DN) - result = None - try: - result = self.api.Command.trust_show(keys[-1]) - except errors.NotFound, e: - self.obj.handle_not_found(*keys) self.obj.validate_sid_blacklists(entry_attrs) - # TODO: we found the trust object, now modify it - return result['result']['dn'] + return dn class trust_find(LDAPSearch): __doc__ = _('Search for trusts.') @@ -696,8 +704,10 @@ class trust_find(LDAPSearch): # Since all trusts types are stored within separate containers under 'cn=trusts', # search needs to be done on a sub-tree scope def pre_callback(self, ldap, filters, attrs_list, base_dn, scope, *args, **options): - assert isinstance(base_dn, DN) - return (filters, base_dn, ldap.SCOPE_SUBTREE) + # list only trust, not trust domains + trust_filter = '(ipaNTSupportedEncryptionTypes=*)' + filter = ldap.combine_filters((filters, trust_filter), rules=ldap.MATCH_ALL) + return (filter, base_dn, ldap.SCOPE_SUBTREE) def post_callback(self, ldap, entries, truncated, *args, **options): if options.get('pkey_only', False): @@ -705,7 +715,7 @@ class trust_find(LDAPSearch): for entry in entries: (dn, attrs) = entry - + # Translate ipanttrusttype to trusttype if --raw not used if not options.get('raw', False): attrs['trusttype'] = trust_type_string(attrs['ipanttrusttype'][0]) @@ -718,30 +728,6 @@ class trust_show(LDAPRetrieve): has_output_params = LDAPRetrieve.has_output_params + trust_output_params +\ (Str('ipanttrusttype'), Str('ipanttrustdirection')) - def execute(self, *keys, **options): - error = None - result = None - for trust_type in trust.trust_types: - options['trust_show_type'] = trust_type - try: - result = super(trust_show, self).execute(*keys, **options) - except errors.NotFound, e: - result = None - error = e - if result: - break - if error or not result: - self.obj.handle_not_found(*keys) - - return result - - def pre_callback(self, ldap, dn, entry_attrs, *keys, **options): - assert isinstance(dn, DN) - if 'trust_show_type' in options: - return make_trust_dn(self.env, options['trust_show_type'], dn) - - return dn - def post_callback(self, ldap, dn, entry_attrs, *keys, **options): # Translate ipanttrusttype to trusttype @@ -1078,3 +1064,163 @@ class sidgen_was_run(Command): return dict(result=True) api.register(sidgen_was_run) + +class trustdomain(LDAPObject): + """ + Object representing a domain of the AD trust. + """ + parent_object = 'trust' + trust_type_idx = {'2':u'ad'} + object_name = _('trust domain') + object_name_plural = _('trust domains') + object_class = ['ipaNTTrustedDomain'] + default_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', 'ipanttrustpartner'] + search_display_attributes = ['cn', 'ipantflatname', 'ipanttrusteddomainsid', ] + + label = _('Trusted domains') + label_singular = _('Trusted domain') + + trustdomain_args = ( + Str('trust?', + label=_('AD trust'), + flags=('virtual_attribute',), + ), + Str('cn?', + label=_('Domain name'), + cli_name='domain', + primary_key=True, + flags=('req_update','req_create',), + ), + ) + + takes_params = ( + Str('ipantflatname?', + cli_name='flat_name', + label=_('Domain NetBIOS name'), + ), + Str('ipanttrusteddomainsid?', + cli_name='sid', + label=_('Domain Security Identifier'), + ), + ) +api.register(trustdomain) + +class trustdomain_find(LDAPSearch): + __doc__ = _('Search domains of the trust') + + takes_args = trustdomain.trustdomain_args[0] + takes_options = LDAPSearch.takes_options + (trustdomain.trustdomain_args[1],) + + def pre_callback(self, ldap, filters, attrs_list, base_dn, scope, *args, **options): + return (filters, base_dn, ldap.SCOPE_SUBTREE) +api.register(trustdomain_find) + +class trustdomain_mod(LDAPUpdate): + __doc__ = _('Modify trustdomain of the trust') + + NO_CLI = True + takes_args = trustdomain.trustdomain_args + takes_options = LDAPUpdate.takes_options + (_trust_type_option,) + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + args = filter(lambda x: x, keys) + if len(args) != 2: + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name and trust domain name are required to modify the trust domain')) + return dn +api.register(trustdomain_mod) + +class trustdomain_add(LDAPCreate): + __doc__ = _('Allow access from the trusted domain') + NO_CLI = True + + takes_args = trustdomain.trustdomain_args + takes_options = LDAPCreate.takes_options + (_trust_type_option, + Str('ipanttrustpartner?', + label=_('Trusted domain partner'), + ), + ) + + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + args = filter(lambda x: x, keys) + if len(args) != 2: + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name and trust domain name are required to create the trust domain')) + if 'ipanttrustpartner' in options: + entry_attrs['ipanttrustpartner'] = [options['ipanttrustpartner']] + return dn +api.register(trustdomain_add) + +class trustdomain_del(LDAPDelete): + __doc__ = _('Remove infromation about the domain associated with the trust.') + + msg_summary = _('Removed information about the trusted domain "%(value)s"') + + takes_args = trustdomain.trustdomain_args + def pre_callback(self, ldap, dn, *keys, **options): + args = filter(lambda x: x, keys) + if len(args) != 2: + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name and trust domain name are required to delete the trust domain')) + return dn + + def execute(self, *keys, **options): + result = super(trustdomain_del, self).execute(*keys, **options) + result['value'] = keys[1] + return result + + +api.register(trustdomain_del) + +class trustdomain_fetch(LDAPRetrieve): + __doc__ = _('Refresh list of the domains associated with the trust') + + takes_args = (trustdomain.trustdomain_args[0]) + + has_output = ( + output.ListOfEntries('result'), + output.summary + ) + def execute(self, *keys, **options): + if not _bindings_installed: + raise errors.NotFound( + name=_('AD Trust setup'), + reason=_( + 'Cannot perform join operation without Samba 4 support ' + 'installed. Make sure you have installed server-trust-ad ' + 'sub-package of IPA' + ) + ) + if not keys[0]: + raise errors.ValidationError(name=_('AD trust'), error=_('Trust name is required to fetch trust domains')) + + trust = self.api.Command.trust_show(keys[0], raw=True)['result'] + + trustinstance = ipaserver.dcerpc.TrustDomainJoins(self.api) + if not trustinstance.configured: + raise errors.NotFound( + name=_('AD Trust setup'), + reason=_( + 'Cannot perform join operation without own domain ' + 'configured. Make sure you have run ipa-adtrust-install ' + 'on the IPA server first' + ) + ) + domains = ipaserver.dcerpc.fetch_domains(self.api, trustinstance.local_flatname, trust['cn'][0]) + result = dict(result=[]) + if not domains: + result['summary'] = unicode(_('No trust domains were detected during refresh')) + return result + + for dom in domains: + dom['trust_type'] = self.obj.trust_type_idx[trust['ipanttrusttype'][0]] + try: + name = dom['cn'] + del dom['cn'] + res = self.api.Command.trustdomain_add(keys[0], name, **dom) + result['result'].append(res['result']) + except errors.DuplicateEntry: + # Ignore updating duplicate entries + pass + if len(result['result']) > 0: + result['summary'] = unicode(_('List of trust domains successfully refreshed')) + else: + result['summary'] = unicode(_('No new trust domains were found')) + return result +api.register(trustdomain_fetch) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index c24230b..af0e77e 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -1002,6 +1002,60 @@ class TrustDomainInstance(object): return True return False +def fetch_domains(api, mydomain, trustdomain): + trust_flags = dict( + NETR_TRUST_FLAG_IN_FOREST = 0x00000001, + NETR_TRUST_FLAG_OUTBOUND = 0x00000002, + NETR_TRUST_FLAG_TREEROOT = 0x00000004, + NETR_TRUST_FLAG_PRIMARY = 0x00000008, + NETR_TRUST_FLAG_NATIVE = 0x00000010, + NETR_TRUST_FLAG_INBOUND = 0x00000020, + NETR_TRUST_FLAG_MIT_KRB5 = 0x00000080, + NETR_TRUST_FLAG_AES = 0x00000100) + + trust_attributes = dict( + NETR_TRUST_ATTRIBUTE_NON_TRANSITIVE = 0x00000001, + NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x00000002, + NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x00000004, + NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x00000008, + NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x00000010, + NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x00000020, + NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x00000040) + + domval = DomainValidator(api) + (ccache_name, principal) = domval.kinit_as_http(trustdomain) + if ccache_name: + with installutils.private_ccache(path=ccache_name): + td = TrustDomainInstance('') + td.parm.set('workgroup', mydomain) + td.creds = credentials.Credentials() + td.creds.set_kerberos_state(credentials.MUST_USE_KERBEROS) + td.creds.guess(td.parm) + netrc = net.Net(creds=td.creds, lp=td.parm) + try: + result = netrc.finddc(domain=trustdomain, flags=nbt.NBT_SERVER_LDAP | nbt.NBT_SERVER_DS) + except RuntimeError, e: + raise assess_dcerpc_exception(message=str(e)) + if not result: + return None + td.retrieve(unicode(result.pdc_dns_name)) + + netr_pipe = netlogon.netlogon(td.binding, td.parm, td.creds) + domains = netr_pipe.netr_DsrEnumerateDomainTrusts(td.binding, 1) + + result = [] + for t in domains.array: + if ((t.trust_attributes & trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and + (t.trust_flags & trust_flags['NETR_TRUST_FLAG_IN_FOREST'])): + res = dict() + res['cn'] = unicode(t.dns_name) + res['ipantflatname'] = unicode(t.netbios_name) + res['ipanttrusteddomainsid'] = unicode(t.sid) + res['ipanttrustpartner'] = res['cn'] + result.append(res) + return result + + class TrustDomainJoins(object): def __init__(self, api): self.api = api -- 1.8.3.1 From akrivoka at redhat.com Mon Sep 23 16:27:28 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 23 Sep 2013 18:27:28 +0200 Subject: [Freeipa-devel] [RFE] Support for automember rebuild membership In-Reply-To: <523FF461.8010506@redhat.com> References: <523200E9.5010304@redhat.com> <523AFBA2.9070000@redhat.com> <523AFF92.6070805@redhat.com> <523FEB3C.2020408@redhat.com> <523FF461.8010506@redhat.com> Message-ID: <52406BF0.8020506@redhat.com> On 09/23/2013 09:57 AM, Jan Cholasta wrote: > On 23.9.2013 09:18, Martin Kosek wrote: >> On 09/19/2013 03:43 PM, Ana Krivokapic wrote: >>> On 09/19/2013 03:26 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 12.9.2013 19:59, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> The design document for $SUBJECT can be found at: >>>>> http://www.freeipa.org/page/V3/Automember_rebuild_membership >>>>> >>>>> Related tickets: >>>>> https://fedorahosted.org/freeipa/ticket/3752 >>>>> https://fedorahosted.org/freeipa/ticket/3928 >>>>> >>>>> Thoughts, comments, questions welcome. >>>>> >>>> >>>> I don't think naming the commands user-automember-rebuild and >>>> host-automember-rebuild commands is correct. The names imply they are methods >>>> of user/host, but they don't directly do anything to user/host objects. I >>>> would prefer if they were kept in the automember namespace where they >>>> logically belong (automember-rebuild-user and automember-rebuild-host >>>> perhaps?) >>>> >>>> Honza >>>> >>> >>> That makes sense... I don't have a strong preference one way or other. So if >>> other agree with this suggestion, I will change it. >> >> I think Honza's comment makes sense. We can merge the functionality to >> automember-rebuild command: >> >> $ ipa automember-rebuild --type=group [ENTRY] >> $ ipa automember-rebuild --type=hostgroup [ENTRY] >> >> If no ENTRY is specified, it would run rebuild for all entries. If ENTRY is >> specified, it would use it as Primary Key the entry - user uid or group name. >> >> This way the API should be consistent with the rest of the automember plugin. >> >> Makes sense? > > Yes, but I think the "--type=group " part might be confusing. What > about: > > $ ipa automember-rebuild --type=group --users --users ... > $ ipa automember-rebuild --type=hostgroup --hosts --hosts ... > > ? > > The --users and --hosts parameters are inspired by group-add-member and > hostgroup-add-member. Also, the value of --type can be inferred, so it does > not have to be explicitly specified: > > $ ipa automember-rebuild --users --users ... > $ ipa automember-rebuild --hosts --hosts ... > >> >> Martin >> > > I like this suggestion, I updated the design page accordingly: http://www.freeipa.org/page/V3/Automember_rebuild_membership#CLI -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From akrivoka at redhat.com Mon Sep 23 17:41:07 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 23 Sep 2013 19:41:07 +0200 Subject: [Freeipa-devel] [PATCHES] 0068-0070 Automember rebuild membership In-Reply-To: <523AFC1E.4080005@redhat.com> References: <523AFC1E.4080005@redhat.com> Message-ID: <52407D33.6000009@redhat.com> On 09/19/2013 03:29 PM, Ana Krivokapic wrote: > Hello, > > This patch set adds automember rebuild membership functionality to IPA CLI. > > Design: http://www.freeipa.org/page/V3/Automember_rebuild_membership > Ticket: https://fedorahosted.org/freeipa/ticket/3752 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel This updated patch set introduces only one automember-rebuild command, instead of three. The changes are covered in the design document: http://www.freeipa.org/page/V3/Automember_rebuild_membership#CLI. Also, while working on these patches, I hit this bug again: https://fedorahosted.org/freeipa/ticket/2708. Since the fix is pretty straightforward, and the bug is related to automember feature, I included a fix for it in this patch set (patch 0071). -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0068-02-Add-automember-rebuild-command.patch Type: text/x-patch Size: 7710 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0071-Fix-error-message-when-adding-duplicate-automember-r.patch Type: text/x-patch Size: 3819 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0069-02-Add-permissions-for-automember-rebuild-command.patch Type: text/x-patch Size: 2389 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0070-02-Add-unit-tests-for-automember-rebuild-command.patch Type: text/x-patch Size: 24112 bytes Desc: not available URL: From simo at redhat.com Mon Sep 23 19:50:37 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 23 Sep 2013 15:50:37 -0400 Subject: [Freeipa-devel] [PATCH] follow up to #3859 Message-ID: <1379965837.17271.90.camel@willson.li.ssimo.org> Additional patch to add -r option to ipa-getkeytab man page. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-man-Add-r-option-to-ipa-getkeytab.1.patch Type: text/x-patch Size: 2015 bytes Desc: not available URL: From sbose at redhat.com Tue Sep 24 08:50:55 2013 From: sbose at redhat.com (Sumit Bose) Date: Tue, 24 Sep 2013 10:50:55 +0200 Subject: [Freeipa-devel] [PATCH] 120 CLDAP: do not read IPA domain from hostname Message-ID: <20130924085055.GU25628@localhost.localdomain> Hi, this patch fixes an issue in the CLDAP plugin if the IPA server comes from a different DNS domain than the IPA domain. Trac ticket is https://fedorahosted.org/freeipa/ticket/3941 . bye, Sumit -------------- next part -------------- From 16c2193e92aea40316c39a2598ea4ce28a796905 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Tue, 24 Sep 2013 10:09:26 +0200 Subject: [PATCH] CLDAP: do not read IPA domain from hostname Currently the CLDAP plugin determines the IPA domain name by reading the current host name and splitting of the domain part. But since an IPA server does not have to be in a DNS domain which has the same name as the IPA domain this may fail. The domain name was used to search the ipaNTDomainAttrs object, but since this object is unique in the tree it is sufficient to use the objectclass in the search filter. Now the IPA domain can be read from the ipaNTDomainAttrs object as well. Fixes https://fedorahosted.org/freeipa/ticket/3941 --- .../ipa-cldap/ipa_cldap_netlogon.c | 72 ++++++++-------------- 1 file changed, 25 insertions(+), 47 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c index dda933d6d4df4f95c9b70f1bd62c329c788c3a6f..7d29fe559be55607fcb6b83fa521372e5197b848 100644 --- a/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c +++ b/daemons/ipa-slapi-plugins/ipa-cldap/ipa_cldap_netlogon.c @@ -76,12 +76,12 @@ static int string_to_guid(char *str, struct GUID *guid) } static int ipa_cldap_get_domain_entry(struct ipa_cldap_ctx *ctx, - char *domain, + char **domain, char **guid, char **sid, char **name) { Slapi_PBlock *pb; Slapi_Entry **e = NULL; - char *filter; + const char *filter = "objectclass=ipaNTDomainAttrs"; int ret; pb = slapi_pblock_new(); @@ -89,12 +89,6 @@ static int ipa_cldap_get_domain_entry(struct ipa_cldap_ctx *ctx, return ENOMEM; } - ret = asprintf(&filter, "(&(cn=%s)(objectclass=ipaNTDomainAttrs))", domain); - if (ret == -1) { - ret = ENOMEM; - goto done; - } - slapi_search_internal_set_pb(pb, ctx->base_dn, LDAP_SCOPE_SUBTREE, filter, NULL, 0, NULL, NULL, ctx->plugin_id, 0); @@ -117,20 +111,20 @@ static int ipa_cldap_get_domain_entry(struct ipa_cldap_ctx *ctx, *guid = slapi_entry_attr_get_charptr(e[0], "ipaNTDomainGUID"); *sid = slapi_entry_attr_get_charptr(e[0], "ipaNTSecurityIdentifier"); *name = slapi_entry_attr_get_charptr(e[0], "ipaNTFlatName"); + *domain = slapi_entry_attr_get_charptr(e[0], "cn"); ret = 0; done: slapi_free_search_results_internal(pb); slapi_pblock_destroy(pb); - free(filter); return ret; } #define NETLOGON_SAM_LOGON_RESPONSE_EX_pusher \ (ndr_push_flags_fn_t)ndr_push_NETLOGON_SAM_LOGON_RESPONSE_EX -static int ipa_cldap_encode_netlogon(char *hostname, char *domain, +static int ipa_cldap_encode_netlogon(char *fq_hostname, char *domain, char *guid, char *sid, char *name, uint32_t ntver, struct berval *reply) { @@ -165,14 +159,14 @@ static int ipa_cldap_encode_netlogon(char *hostname, char *domain, string_to_guid(guid, &nlr->domain_uuid); nlr->forest = domain; nlr->dns_domain = domain; - nlr->pdc_dns_name = talloc_asprintf(nlr, "%s.%s", hostname, domain); - if (!nlr->pdc_dns_name) { - ret = ENOMEM; - goto done; - } + nlr->pdc_dns_name = fq_hostname; nlr->domain_name = name; - pdc_name = talloc_asprintf(nlr, "\\\\%s", hostname); + pdc_name = talloc_asprintf(nlr, "\\\\%s", fq_hostname); for (p = pdc_name; *p; p++) { + if (*p == '.') { + *p = '\0'; + break; + } *p = toupper(*p); } nlr->pdc_name = pdc_name; @@ -215,8 +209,8 @@ int ipa_cldap_netlogon(struct ipa_cldap_ctx *ctx, struct berval *reply) { char hostname[MAXHOSTNAMELEN + 1]; /* NOTE: lenght hardcoded in kernel */ - char *host = NULL; char *domain = NULL; + char *our_domain = NULL; char *guid = NULL; char *sid = NULL; char *name = NULL; @@ -295,8 +289,6 @@ int ipa_cldap_netlogon(struct ipa_cldap_ctx *ctx, goto done; } - /* TODO: get our own domain at plugin initialization, and avoid - * gethostname() */ ret = gethostname(hostname, MAXHOSTNAMELEN); if (ret == -1) { ret = errno; @@ -310,51 +302,37 @@ int ipa_cldap_netlogon(struct ipa_cldap_ctx *ctx, ret = EINVAL; goto done; } - *dot = '\0'; - /* this is the unqualified host name */ - host = strdup(hostname); - if (!host) { - ret = ENOMEM; + /* FIXME: we support only NETLOGON_NT_VERSION_5EX for now */ + if (!(ntver & NETLOGON_NT_VERSION_5EX)) { + ret = EINVAL; + goto done; + } + + ret = ipa_cldap_get_domain_entry(ctx, &our_domain, &guid, &sid, &name); + if (ret) { goto done; } /* If a domain is provided, check it is our own. * If no domain is provided the client is asking for our own domain. */ if (domain) { - ret = strcasecmp(domain, dot + 1); + ret = strcasecmp(domain, our_domain); if (ret != 0) { ret = EINVAL; goto done; } - } else { - domain = strdup(dot + 1); - if (!domain) { - ret = ENOMEM; - goto done; - } } - /* FIXME: we support only NETLOGON_NT_VERSION_5EX for now */ - if (!(ntver & NETLOGON_NT_VERSION_5EX)) { - ret = EINVAL; - goto done; - } - - ret = ipa_cldap_get_domain_entry(ctx, domain, &guid, &sid, &name); - if (ret) { - goto done; - } - - ret = ipa_cldap_encode_netlogon(host, domain, + ret = ipa_cldap_encode_netlogon(hostname, our_domain, guid, sid, name, ntver, reply); done: - free(host); free(domain); - free(guid); - free(sid); - free(name); + slapi_ch_free_string(&our_domain); + slapi_ch_free_string(&guid); + slapi_ch_free_string(&sid); + slapi_ch_free_string(&name); return ret; } -- 1.8.1.4 From jcholast at redhat.com Tue Sep 24 10:03:14 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Sep 2013 12:03:14 +0200 Subject: [Freeipa-devel] [PATCHES] 0177-0179 Add missing dict methods to CIDict In-Reply-To: <5240133A.3020105@redhat.com> References: <51113B3F.3070808@redhat.com> <51237565.1040404@redhat.com> <5124FBBB.6080801@redhat.com> <523871A7.9050506@redhat.com> <523995EB.9010706@redhat.com> <523FEB2B.3050507@redhat.com> <5240133A.3020105@redhat.com> Message-ID: <52416362.2090909@redhat.com> On 23.9.2013 12:08, Petr Viktorin wrote: > On 09/23/2013 09:18 AM, Jan Cholasta wrote: >> On 18.9.2013 14:00, Petr Viktorin wrote: >>> On 09/17/2013 05:13 PM, Jan Cholasta wrote: >>>> On 20.2.2013 17:37, Petr Viktorin wrote: >>>>> On 02/19/2013 01:51 PM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 5.2.2013 18:02, Petr Viktorin wrote: >>>>>>> CIDict, our case-insensitive dictionary, inherits from dict but did >>>>>>> not >>>>>>> reimplement the full dict interface. Calling the missing methods >>>>>>> silently invoked case-sensitive behavior. Our code seems to avoid >>>>>>> that, >>>>>>> but it's a bit of a minefield for new development. >>>>>>> >>>>>>> Patch 119 adds the missing dict methods (except >>>>>>> view{items,keys,values}(), which now raise errors), and adds tests. >>>>>> >>>>>> Can you please also add the (obj, **kwargs) and (**kwargs) >>>>>> variants of >>>>>> __init__ and update? >>>>> >>>>> Added, thanks for the catch. >>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Patches 117-118 modernize the testsuite a bit (these have been >>>>>>> sitting >>>>>>> in my queue for a while, I think now is a good time to submit them): >>>>>>> The first one moves some old tests from the main code tree to >>>>>>> tests/. >>>>>>> (The adtrust_install test wasn't run before, this move makes nose >>>>>>> notice >>>>>>> it). >>>>>>> The second converts CIDict's unittest-based suite to nose. >>>>>>> >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> >>>> >>>> Whoa, I totally forgot about these patches! >>>> >>>> Can you please rebase them? >>> >>> Sure! >>> >>>> One more comment: >>>> >>>> Document that CIDict.copy() returns a plain dict. >>>> >>>> Why does it return a plain dict? I think it should return a CIDict, >>>> otherwise it is not actually a copy, right? >>> >>> I wanted to keep the existing (intended) functionality. >>> But since we don't actually use CIDict.copy() anywhere any more, I've >>> made the change. >> >> Thanks. >> >>> >>> P.S. I recently came across a bug in python-ldap where something like >>> CIDict({'cn': ['name1', 'name2'], 'cN': ['name3']}) will throw away some >>> of the values. >>> This is expected at the CIDict level, but if you're working with dicts >>> of lists it's something to keep an eye out for. >>> >> >> This is a good point. IIRC when you use such a dict in python-ldap, it >> will fail with TYPE_OR_VALUE_EXISTS. I think we should raise an error in >> CIDict as well if such a dict is used in __init__() and update(), as >> this kind of error is very hard to track otherwise. >> >> Honza >> > > Right. Here's a patch that does that. > Thanks. ACK to all four patches. Honza -- Jan Cholasta From tbabej at redhat.com Tue Sep 24 10:03:15 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 24 Sep 2013 12:03:15 +0200 Subject: [Freeipa-devel] [PATCH 111] ipa-client-install: Publish CA certificate to systemwide store Message-ID: <52416363.8050800@redhat.com> Hi, During the installation, copy the CA certificate to the systemwide store (/etc/pki/ca-trust/source/anchors/ipa-ca.crt) and update the systemwide CA database. This allows browsers to access IPA WebUI without warning out of the box. https://fedorahosted.org/freeipa/ticket/3504 -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0111-ipa-client-install-Publish-CA-certificate-to-systemw.patch Type: text/x-patch Size: 4011 bytes Desc: not available URL: From jcholast at redhat.com Tue Sep 24 10:26:09 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Sep 2013 12:26:09 +0200 Subject: [Freeipa-devel] [PATCH 111] ipa-client-install: Publish CA certificate to systemwide store In-Reply-To: <52416363.8050800@redhat.com> References: <52416363.8050800@redhat.com> Message-ID: <524168C1.1050602@redhat.com> Hi, On 24.9.2013 12:03, Tomas Babej wrote: > Hi, > > During the installation, copy the CA certificate to the systemwide > store (/etc/pki/ca-trust/source/anchors/ipa-ca.crt) and update the > systemwide CA database. > > This allows browsers to access IPA WebUI without warning out of the > box. > > https://fedorahosted.org/freeipa/ticket/3504 > I think you should update /etc/pki/nssdb manually only if update-ca-cert fails. Honza -- Jan Cholasta From jcholast at redhat.com Tue Sep 24 11:30:10 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Sep 2013 13:30:10 +0200 Subject: [Freeipa-devel] [PATCH 111] ipa-client-install: Publish CA certificate to systemwide store In-Reply-To: <524168C1.1050602@redhat.com> References: <52416363.8050800@redhat.com> <524168C1.1050602@redhat.com> Message-ID: <524177C2.8030802@redhat.com> On 24.9.2013 12:26, Jan Cholasta wrote: > Hi, > > On 24.9.2013 12:03, Tomas Babej wrote: >> Hi, >> >> During the installation, copy the CA certificate to the systemwide >> store (/etc/pki/ca-trust/source/anchors/ipa-ca.crt) and update the >> systemwide CA database. >> >> This allows browsers to access IPA WebUI without warning out of the >> box. >> >> https://fedorahosted.org/freeipa/ticket/3504 >> > > I think you should update /etc/pki/nssdb manually only if update-ca-cert > fails. > > Honza > We discussed this with Tom?? off-line and it turns out that ipa-client-install fails if the CA cert is not added to /etc/pki/nssdb. However, according to p11-kit docs it should work: . I wonder what needs to be done to make it work in IPA... Honza -- Jan Cholasta From jcholast at redhat.com Tue Sep 24 13:35:35 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 24 Sep 2013 15:35:35 +0200 Subject: [Freeipa-devel] [PATCHES] 106-113 Access raw LDAP values directly from LDAPEntry In-Reply-To: <512E26E1.5010302@redhat.com> References: <512E26E1.5010302@redhat.com> Message-ID: <52419527.70200@redhat.com> On 27.2.2013 16:31, Jan Cholasta wrote: > Hi, > > these patches add the ability to access and manipulate raw attribute > values as they are returned from python-ldap to the LDAPEntry class. > This is useful for comparing entries, computing modlists for the modify > operation, deleting values that don't match the syntax of an attribute, > etc., because we don't need to care what syntax does a particular > attribute use, or what Python type is used for it in the framework (raw > values are always list of str). It should also make interaction with > non-389 DS LDAP servers easier in the framework. > > (It might be too late for this kind of changes to get into 3.2 now, I'm > posting these patches mainly so that you are aware that they exist.) > > Honza > This is now planned for 3.4: I fixed some issues in these patches and refined the API. Updated patches attached. Also added a patch to use raw values when adding new entries and a patch which refines LDAPEntry.single_value, so that it is consistent with the rest of the changes introduced in the patches. Patch 110 will probably be dropped in favor of Petr Viktorin's schema update patches, but I included it anyway. Incidentally, this also fixes and possibly also . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-106.2-Make-LDAPEntry-a-wrapper-around-dict-rather-than-a-d.patch Type: text/x-patch Size: 7272 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-107.2-Introduce-IPASimpleLDAPObject.decode-method-for-deco.patch Type: text/x-patch Size: 3308 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-108.2-Always-use-lists-for-values-in-LDAPEntry-internally.patch Type: text/x-patch Size: 4001 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-109.2-Decode-and-encode-attribute-values-in-LDAPEntry-on-d.patch Type: text/x-patch Size: 16350 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-110.2-Make-sure-attributeTypes-updates-are-done-before-obj.patch Type: text/x-patch Size: 1088 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-111.2-Remove-legacy-toDict-and-origDataDict-methods-of-LDA.patch Type: text/x-patch Size: 4878 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-112.2-Store-encoded-attribute-values-from-search-results-d.patch Type: text/x-patch Size: 886 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-113.2-Use-encoded-values-from-entry-objects-directly-when-.patch Type: text/x-patch Size: 3181 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-121.2-Use-encoded-values-from-entry-objects-directly-when-.patch Type: text/x-patch Size: 1478 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-169.2-Turn-LDAPEntry.single_value-into-a-dictionary-like-p.patch Type: text/x-patch Size: 49273 bytes Desc: not available URL: From pvoborni at redhat.com Tue Sep 24 14:03:36 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 24 Sep 2013 16:03:36 +0200 Subject: [Freeipa-devel] [DOC] Chapter 2 Installation In-Reply-To: <1377531272.2139.14.camel@unused-4-145.brq.redhat.com> References: <1377530209.2139.6.camel@unused-4-145.brq.redhat.com> <1377531272.2139.14.camel@unused-4-145.brq.redhat.com> Message-ID: <52419BB8.2010007@redhat.com> On 08/26/2013 05:34 PM, Martin Basti wrote: > It solves https://fedorahosted.org/freeipa/ticket/3763 too. > Sorry I forgot to add link to email before >> Hello, >> >> this patch fix some setup outputs and remove outdated section about >> updating freeIPA version 2 >> >> -- >> Martin Basti Thanks for the patch. 1. There is a commented-out note about installing replica of different version. I would keep it there and just replaced 'different' with 'older'. Also note that the 'newer' version exception is valid only when upgrading. There should not be two long-running ipa servers with different versions. 2. There are trailing white spaces. Questions: a) 2.1.5.1: Should we replace chkconfig and service command examples by systemctl? -- Petr Vobornik From pvoborni at redhat.com Tue Sep 24 14:31:21 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 24 Sep 2013 16:31:21 +0200 Subject: [Freeipa-devel] [PATCH] 459 Allow edit of ipakrbokasdelegate in Web UI when attrlevelrights are unknown Message-ID: <5241A239.2070104@redhat.com> Old host entries are missing object class with krbticketflags attribute. Therefore UI does not receive attrlevelrights for it. This OC is added when ipakrbokasdelegate(krbticketflags) is set. This patch adds the usual hack for such cases. https://fedorahosted.org/freeipa/ticket/3940 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0459-Allow-edit-of-ipakrbokasdelegate-in-Web-UI-when-attr.patch Type: text/x-patch Size: 1265 bytes Desc: not available URL: From pviktori at redhat.com Tue Sep 24 15:34:57 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 24 Sep 2013 17:34:57 +0200 Subject: [Freeipa-devel] [PATCH] 0235 tests: Use ipa-getkeytab from /usr/sbin instead of the in-tree one In-Reply-To: <1370360902.2744.40.camel@willson.li.ssimo.org> References: <51ADD407.6020100@redhat.com> <1370350403.2744.15.camel@willson.li.ssimo.org> <51AE06A5.4030301@redhat.com> <1370360902.2744.40.camel@willson.li.ssimo.org> Message-ID: <5241B121.6090203@redhat.com> On 06/04/2013 05:48 PM, Simo Sorce wrote: > On Tue, 2013-06-04 at 17:24 +0200, Petr Viktorin wrote: >> On 06/04/2013 02:53 PM, Simo Sorce wrote: >>> On Tue, 2013-06-04 at 13:48 +0200, Petr Viktorin wrote: >>>> Hardcoding the in-tree location for ipa-getkeytab makes testing outside >>>> the source tree impossible. This patch makes the tests use the installed >>>> location. >>>> >>>> In other places the test suite assumes IPA is installed system-wide, >>>> even if running from the source tree. >>>> I know I frequently forget to run `make` before testing, which makes the >>>> ipa-getkeytab tests fail. So this patch would work well for me (and >>>> probably other Python devs), but I guess others might be used to `make >>>> test` checking what `make` built. >>>> >>>> C developers, are you OK with e.g. adding `cp ipa-client/ipa-getkeytab >>>> /usr/sbin/ipa-getkeytab` to your testing workflow? >>> >>> Absolutely not. >>> >>>> Or should this be made configurable (or auto-detected)? >>> >>> You must not break a machine just to do make test. >>> >>> I often do make test, then make rpms and install rpms, I *never* >>> directly install on my development machine or VMs, I always go through >>> RPM in order to keep the system clean, and tests repeatable. >> >> I do the same except I never run make test on the development machine -- >> without IPA installed the tests don't work. >> >>> ipa-getkeytab specifically do not need root to be tested so I really do >>> not see that copying over a system path would ever be a good idea. >>> >>> Simo. >> >> >> With this version of the patch, the tests use ipa-getkeytab from $PATH, >> and the in-tree directory is added to PATH in make-test. Out-of-tree >> tests don't use make-test so they will use the system PATH. >> Is that OK? >> > > Sounds good to me. > > Simo. > Ping, could someone look at this patch? It should fix 7 of the 11 failures that happen when running the test suite out of tree. -- Petr? From pviktori at redhat.com Tue Sep 24 15:42:34 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 24 Sep 2013 17:42:34 +0200 Subject: [Freeipa-devel] [PATCHES] 0282-0286 Test improvements Message-ID: <5241B2EA.30907@redhat.com> Hello, These patches fix issues in the test suite, mainly those in BeakerLib integration. Patch 0282: When requested logs don't exist, tests shouldn't fail. The BeakerLib plugin was too strict here. Patch 0283: The Ordered plugin does not play well with generators: the generated tests are run, but they're not reported plugins' hooks (startTest etc.). I spent some time looking for ways to correct this, but was unsuccessful. The patch disables ordering for test generators (relative to the methods of a class -- the tests from one generator still run in the generated order). With this the BeakerLib plugin will report generated tests. Patch 0284: This adds arguments to "test names" that the BeakerLib plugin gives to generated tests. The patch only adds the names to the integration tests. As it becomes possible to run the rest of the suite out-of-tree, I can add them to the other test generators as well. Patch 0285: This just adds logging to Host.ldap_connect. Patch 0285: Correct the CLITestContext context manager used in help tests to re-raise unexpected exceptions. Except 0283/0284, these can be reviewed/applied individually. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0282-ipatests.beakerlib_plugin-Warn-instead-of-failing-wh.patch Type: text/x-patch Size: 1101 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0283-ipatests.order_plugin-Exclude-test-generators-from-t.patch Type: text/x-patch Size: 2107 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0284-ipatests.beakerlib_plugin-Add-argument-of-generated-.patch Type: text/x-patch Size: 2395 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0285-ipatests.test_integration.host-Add-logging-to-ldap_c.patch Type: text/x-patch Size: 1174 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0286-ipatests.test_cmdline.test_help-Re-raise-unexpected-.patch Type: text/x-patch Size: 1167 bytes Desc: not available URL: From nalin at redhat.com Tue Sep 24 16:14:43 2013 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 24 Sep 2013 12:14:43 -0400 Subject: [Freeipa-devel] [PATCH 111] ipa-client-install: Publish CA certificate to systemwide store In-Reply-To: <524177C2.8030802@redhat.com> References: <52416363.8050800@redhat.com> <524168C1.1050602@redhat.com> <524177C2.8030802@redhat.com> Message-ID: <20130924161443.GC23991@redhat.com> On Tue, Sep 24, 2013 at 01:30:10PM +0200, Jan Cholasta wrote: > We discussed this with Tom?? off-line and it turns out that > ipa-client-install fails if the CA cert is not added to > /etc/pki/nssdb. > > However, according to p11-kit docs it should work: > . I > wonder what needs to be done to make it work in IPA... On my system, there's no symlink to libnssckbi.so (or the right location in the link farm under /etc/alternatives) in /etc/pki/nssdb, so that database isn't going to automatically pull in the list of trusted CAs that p11-kit maintains. Whether the database under /etc/pki/nssdb should automatically include the usual set of trust anchors is probably a different conversation. HTH, Nalin From pvoborni at redhat.com Tue Sep 24 16:35:59 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 24 Sep 2013 18:35:59 +0200 Subject: [Freeipa-devel] [DOC] 0002 Chapter 3 Installing clients In-Reply-To: <1377530741.2139.11.camel@unused-4-145.brq.redhat.com> References: <1377530741.2139.11.camel@unused-4-145.brq.redhat.com> Message-ID: <5241BF6F.4070206@redhat.com> On 08/26/2013 05:25 PM, Martin Basti wrote: > Hello, > > this patch fix some setup outputs, add tips and order of command in > examples > > > -- > Martin Basti > Thanks for the patch. Issues: 1. trailing white space errors 2. Two hashes > @@ -436,7 +456,7 @@ RPCSVCGSSDARGS="-vvv" > > > Copy the keytab from the &IPA; server to the &IPA; client. For example: > -# scp /tmp/krb5.keytab root at client.example.com:/etc/krb5.keytab > +[root at server ~]## scp /tmp/krb5.keytab root at client.example.com:/etc/krb5.keytab --------------------------------------------------^^ > > > 3. > @@ -529,8 +549,16 @@ RPCSVCGSSDARGS="-vvv" > > Set the correct user permissions and, if necessary, SELinux contexts for the /etc/krb5.keytab file. > > -chown root:root 0600 > -system_u:object_r:krb5_keytab_t:s0 > + TIP > + > + To verify permissions with SELinux context use ls -Z /etc/krb5.keytab. > + > + > + Change permissions: > + [root at ipaclient ~]# chown root:root /etc/krb5.keytab > +[root at ipaclient ~]# chmod 0600 /etc/krb5.keytab > + Change SELinux context: Should be "Restore SELinux context:" > + [root at ipaclient ~]# chcon system_u:object_r:krb5_keytab_t:s0 /etc/krb5.keytab Should be "[root at ipaclient ~]# restorecon /etc/krb5.keytab" > > > Existing issues: a. NFS sections 3.4.8 and 3.5.14 seems to differ only in minor details. I think that one section should be deleted. Also it seems that section 3.4.8 is missing step 3.5.14c, otherwise 3.4.8f doesn't make much sense (first occurrence of nfs.example.com). -- Petr Vobornik From nkinder at redhat.com Tue Sep 24 18:40:38 2013 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 24 Sep 2013 11:40:38 -0700 Subject: [Freeipa-devel] [PATCH 0016] Add RADIUS proxy support to ipalib CLI In-Reply-To: <1379695123.1629.10.camel@localhost> References: <1378353973.19352.11.camel@localhost> <1379018880.2210.1.camel@localhost> <1379695123.1629.10.camel@localhost> Message-ID: <5241DCA6.1000600@redhat.com> On 09/20/2013 09:38 AM, Nathaniel McCallum wrote: > On Thu, 2013-09-12 at 16:48 -0400, Nathaniel McCallum wrote: >> On Thu, 2013-09-05 at 00:06 -0400, Nathaniel McCallum wrote: >>> patch attached >> Update for ./makeapi attached. > Version 3. This should fix all the current review issues, including the > use of the referential integrity plugin. I had to make one schema change > in order to make the referential integrity modification work. Note also > that the command name prefix is changed from radius to radiusproxy. The LDIF and update related changes look good to me. I'm not familiar with the ipalib code myself, so someone else should review that portion of your patch. Thanks, -NGK > > Nathaniel > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Wed Sep 25 08:15:03 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 25 Sep 2013 10:15:03 +0200 Subject: [Freeipa-devel] [PATCHES] 0177-0179 Add missing dict methods to CIDict In-Reply-To: <52416362.2090909@redhat.com> References: <51113B3F.3070808@redhat.com> <51237565.1040404@redhat.com> <5124FBBB.6080801@redhat.com> <523871A7.9050506@redhat.com> <523995EB.9010706@redhat.com> <523FEB2B.3050507@redhat.com> <5240133A.3020105@redhat.com> <52416362.2090909@redhat.com> Message-ID: <52429B87.1080404@redhat.com> On 09/24/2013 12:03 PM, Jan Cholasta wrote: > On 23.9.2013 12:08, Petr Viktorin wrote: >> On 09/23/2013 09:18 AM, Jan Cholasta wrote: >>> On 18.9.2013 14:00, Petr Viktorin wrote: >>>> On 09/17/2013 05:13 PM, Jan Cholasta wrote: >>>>> On 20.2.2013 17:37, Petr Viktorin wrote: >>>>>> On 02/19/2013 01:51 PM, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 5.2.2013 18:02, Petr Viktorin wrote: >>>>>>>> CIDict, our case-insensitive dictionary, inherits from dict but did >>>>>>>> not >>>>>>>> reimplement the full dict interface. Calling the missing methods >>>>>>>> silently invoked case-sensitive behavior. Our code seems to avoid >>>>>>>> that, >>>>>>>> but it's a bit of a minefield for new development. >>>>>>>> >>>>>>>> Patch 119 adds the missing dict methods (except >>>>>>>> view{items,keys,values}(), which now raise errors), and adds tests. >>>>>>> >>>>>>> Can you please also add the (obj, **kwargs) and (**kwargs) >>>>>>> variants of >>>>>>> __init__ and update? >>>>>> >>>>>> Added, thanks for the catch. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Patches 117-118 modernize the testsuite a bit (these have been >>>>>>>> sitting >>>>>>>> in my queue for a while, I think now is a good time to submit >>>>>>>> them): >>>>>>>> The first one moves some old tests from the main code tree to >>>>>>>> tests/. >>>>>>>> (The adtrust_install test wasn't run before, this move makes nose >>>>>>>> notice >>>>>>>> it). >>>>>>>> The second converts CIDict's unittest-based suite to nose. >>>>>>>> >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> >>>>> >>>>> Whoa, I totally forgot about these patches! >>>>> >>>>> Can you please rebase them? >>>> >>>> Sure! >>>> >>>>> One more comment: >>>>> >>>>> Document that CIDict.copy() returns a plain dict. >>>>> >>>>> Why does it return a plain dict? I think it should return a CIDict, >>>>> otherwise it is not actually a copy, right? >>>> >>>> I wanted to keep the existing (intended) functionality. >>>> But since we don't actually use CIDict.copy() anywhere any more, I've >>>> made the change. >>> >>> Thanks. >>> >>>> >>>> P.S. I recently came across a bug in python-ldap where something like >>>> CIDict({'cn': ['name1', 'name2'], 'cN': ['name3']}) will throw away >>>> some >>>> of the values. >>>> This is expected at the CIDict level, but if you're working with dicts >>>> of lists it's something to keep an eye out for. >>>> >>> >>> This is a good point. IIRC when you use such a dict in python-ldap, it >>> will fail with TYPE_OR_VALUE_EXISTS. I think we should raise an error in >>> CIDict as well if such a dict is used in __init__() and update(), as >>> this kind of error is very hard to track otherwise. >>> >>> Honza >>> >> >> Right. Here's a patch that does that. >> > > Thanks. > > ACK to all four patches. > Thanks, pushed to master: a93fc02af6eb50ecb0cfc69174c9f385d60bbbb3 -- Petr? From jcholast at redhat.com Wed Sep 25 08:46:17 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 25 Sep 2013 10:46:17 +0200 Subject: [Freeipa-devel] [PATCHES] 170-171 Allow PKCS#12 files with empty password in install tools Message-ID: <5242A2D9.10304@redhat.com> Hi, the attached patches fix . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-170-Read-passwords-from-stdin-when-importing-PKCS-12-fil.patch Type: text/x-patch Size: 8527 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-171-Allow-PKCS-12-files-with-empty-password-in-install-t.patch Type: text/x-patch Size: 4410 bytes Desc: not available URL: From akrivoka at redhat.com Wed Sep 25 09:51:49 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 25 Sep 2013 11:51:49 +0200 Subject: [Freeipa-devel] [PATCHES] 0072-0074 Add automember rebuild membership to the web UI Message-ID: <5242B235.6020608@redhat.com> Hello, This patch set addresses ticket https://fedorahosted.org/freeipa/ticket/3928. Patch 0072 hooks the new automember-rebuild command to the web UI (user and host pages). Patch 0073 adds some fixes to the web UI test driver, which are necessary for patch 0074. Patch 0074 adds web UI integration tests for the new feature. The patch set applies on top of my patches 0068-0071 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0074-Add-web-UI-integration-tests-for-automember-rebuild.patch Type: text/x-patch Size: 8214 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0073-Web-UI-integration-test-driver-enhancements.patch Type: text/x-patch Size: 3603 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0072-Add-automember-rebuild-command-to-the-web-UI.patch Type: text/x-patch Size: 9438 bytes Desc: not available URL: From pvoborni at redhat.com Wed Sep 25 11:06:50 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 25 Sep 2013 13:06:50 +0200 Subject: [Freeipa-devel] [DOC] Chapter 4 text In-Reply-To: <1379517057.9269.7.camel@unused-4-145.brq.redhat.com> References: <1379517057.9269.7.camel@unused-4-145.brq.redhat.com> Message-ID: <5242C3CA.4020203@redhat.com> On 09/18/2013 05:10 PM, Martin Basti wrote: > Patch fix examples in chapter 4, adds new examples, fix out of date > information. > > NOTE: Patch doesn't cover part 4.3 Logging with web UI > 1. Table 4.1. Configuration Areas Per Tab is missing Trusts in IPA tab. This menu item is visible only if ipa-adtrust-install was run. 2. 4.3.1. Supported Web Browsers doesn't match 2.1.3. Supported Web Browsers. IMO 4.3.1 is correct. Can be fixed in your patch 0001. 3. trailing white space errors I've noticed that some command examples starts with '$' or '#', others with '[user at ipaserver ~]$' or '[root at ipaserver ~]#'. IMO we should pick one sign ('$' or '#') and be consistent. Mixing short and long version in the same kind of examples should be also avoided (see 4.1.1.1.1. and 4.1.1.1.2.). -- Petr Vobornik From pvoborni at redhat.com Wed Sep 25 11:24:22 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 25 Sep 2013 13:24:22 +0200 Subject: [Freeipa-devel] [DOC] Chapter 4 screenshots In-Reply-To: <1379516848.9269.3.camel@unused-4-145.brq.redhat.com> References: <1379516848.9269.3.camel@unused-4-145.brq.redhat.com> Message-ID: <5242C7E6.1060907@redhat.com> On 09/18/2013 05:07 PM, Martin Basti wrote: > Patch adds new screen-shots for chapter 4 Basic Usage > > NOTE: Patch doesn't cover part 4.3 Logging with web UI > ACK, but I would wait for mbasti 0004 and 0005. -- Petr Vobornik From akrivoka at redhat.com Wed Sep 25 12:17:13 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 25 Sep 2013 14:17:13 +0200 Subject: [Freeipa-devel] [PATCH] 459 Allow edit of ipakrbokasdelegate in Web UI when attrlevelrights are unknown In-Reply-To: <5241A239.2070104@redhat.com> References: <5241A239.2070104@redhat.com> Message-ID: <5242D449.6000905@redhat.com> On 09/24/2013 04:31 PM, Petr Vobornik wrote: > Old host entries are missing object class with krbticketflags attribute. > Therefore UI does not receive attrlevelrights for it. This OC is added when > ipakrbokasdelegate(krbticketflags) is set. > > This patch adds the usual hack for such cases. > > https://fedorahosted.org/freeipa/ticket/3940 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel The patch works well. Could you please also add a regression test? -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Wed Sep 25 15:44:28 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 25 Sep 2013 17:44:28 +0200 Subject: [Freeipa-devel] [PATCH] 459 Allow edit of ipakrbokasdelegate in Web UI when attrlevelrights are unknown In-Reply-To: <5242D449.6000905@redhat.com> References: <5241A239.2070104@redhat.com> <5242D449.6000905@redhat.com> Message-ID: <524304DC.8010402@redhat.com> On 09/25/2013 02:17 PM, Ana Krivokapic wrote: > On 09/24/2013 04:31 PM, Petr Vobornik wrote: >> Old host entries are missing object class with krbticketflags attribute. >> Therefore UI does not receive attrlevelrights for it. This OC is added when >> ipakrbokasdelegate(krbticketflags) is set. >> >> This patch adds the usual hack for such cases. >> >> https://fedorahosted.org/freeipa/ticket/3940 > > The patch works well. Could you please also add a regression test? > Test modified. Sadly, the test doesn't cover old entries after server upgrade, which are the reason for the UI hack. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0459-1-Allow-edit-of-ipakrbokasdelegate-in-Web-UI-when-attr.patch Type: text/x-patch Size: 2238 bytes Desc: not available URL: From akrivoka at redhat.com Wed Sep 25 16:15:57 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 25 Sep 2013 18:15:57 +0200 Subject: [Freeipa-devel] [PATCH] 459 Allow edit of ipakrbokasdelegate in Web UI when attrlevelrights are unknown In-Reply-To: <524304DC.8010402@redhat.com> References: <5241A239.2070104@redhat.com> <5242D449.6000905@redhat.com> <524304DC.8010402@redhat.com> Message-ID: <52430C3D.4000406@redhat.com> On 09/25/2013 05:44 PM, Petr Vobornik wrote: > On 09/25/2013 02:17 PM, Ana Krivokapic wrote: >> On 09/24/2013 04:31 PM, Petr Vobornik wrote: >>> Old host entries are missing object class with krbticketflags attribute. >>> Therefore UI does not receive attrlevelrights for it. This OC is added when >>> ipakrbokasdelegate(krbticketflags) is set. >>> >>> This patch adds the usual hack for such cases. >>> >>> https://fedorahosted.org/freeipa/ticket/3940 >> >> The patch works well. Could you please also add a regression test? >> > > Test modified. Sadly, the test doesn't cover old entries after server upgrade, > which are the reason for the UI hack. ACK! (There's an unused variable (pkey) at the start of the test_kerberos_flags() method - you may just remove it before pushing.) -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From npmccallum at redhat.com Wed Sep 25 20:51:15 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 25 Sep 2013 16:51:15 -0400 Subject: [Freeipa-devel] [PATCH 0015] Add support for managing user auth types In-Reply-To: <52403FC4.6070807@redhat.com> References: <1378353865.19352.9.camel@localhost> <522DCE8B.9040009@redhat.com> <1379533870.1629.5.camel@localhost> <52403FC4.6070807@redhat.com> Message-ID: <1380142275.2046.2.camel@localhost> On Mon, 2013-09-23 at 15:19 +0200, Petr Viktorin wrote: > Great, we're getting close! > > Please send patches in `git format-patch` style (they include commit info). I usually do, I don't know what happened this last time. Sorry! :) > Also, please bump the API revision in VERSION since API.txt was changed. Fixed. > When adding the objectclass in user, it is possible that the user > doesn't exist. You should call handle_not_found in this case so the > appropriate error message is generated. > I ended up doing this for testing, squash in the patch if you want. Fixed. > There's another test failure when trying to rename a manager user. I > didn't investigate in detail why that happens. Does the failure happen without the patch? Is this just a standard make check? > I'm attaching the tests I used, do they look OK? Looks great! Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0015-4-Add-support-for-managing-user-auth-types.patch Type: text/x-patch Size: 11612 bytes Desc: not available URL: From npmccallum at redhat.com Wed Sep 25 20:56:03 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 25 Sep 2013 16:56:03 -0400 Subject: [Freeipa-devel] [PATCH 0016] Add RADIUS proxy support to ipalib CLI In-Reply-To: <1379695123.1629.10.camel@localhost> References: <1378353973.19352.11.camel@localhost> <1379018880.2210.1.camel@localhost> <1379695123.1629.10.camel@localhost> Message-ID: <1380142563.2046.3.camel@localhost> On Fri, 2013-09-20 at 12:38 -0400, Nathaniel McCallum wrote: > On Thu, 2013-09-12 at 16:48 -0400, Nathaniel McCallum wrote: > > On Thu, 2013-09-05 at 00:06 -0400, Nathaniel McCallum wrote: > > > patch attached > > > > Update for ./makeapi attached. > > Version 3. This should fix all the current review issues, including the > use of the referential integrity plugin. I had to make one schema change > in order to make the referential integrity modification work. Note also > that the command name prefix is changed from radius to radiusproxy. Version 4. This patch fixes my failure to increment the minor version number in the VERSION file. Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0016-4-Add-RADIUS-proxy-support-to-ipalib-CLI.patch Type: text/x-patch Size: 32219 bytes Desc: not available URL: From npmccallum at redhat.com Wed Sep 25 22:07:02 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 25 Sep 2013 18:07:02 -0400 Subject: [Freeipa-devel] [PATCH 0018] Ensure credentials structure is initialized Message-ID: <1380146822.2046.8.camel@localhost> Patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-npmccallum-0018-Ensure-credentials-structure-is-initialized.patch Type: text/x-patch Size: 1066 bytes Desc: not available URL: From tbabej at redhat.com Thu Sep 26 08:28:29 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 26 Sep 2013 10:28:29 +0200 Subject: [Freeipa-devel] [PATCH 0113] ipa-client: Set NIS domain name in the installer Message-ID: <5243F02D.9020005@redhat.com> Hi, Provides two new options for the ipa-client-install: --nisdomain: specifies the NIS domain name --no_nisdomain: flag to aviod setting the NIS domain name In case no --nisdomain is specified and --no_nisdomain flag was not set, the IPA domain is used. Manual pages updated. http://fedorahosted.org/freeipa/ticket/3202 Design page: http://www.freeipa.org/page/V3_Minor_Enhancements -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0113-ipa-client-Set-NIS-domain-name-in-the-installer.patch Type: text/x-patch Size: 3834 bytes Desc: not available URL: From pvoborni at redhat.com Thu Sep 26 08:28:48 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 26 Sep 2013 10:28:48 +0200 Subject: [Freeipa-devel] [PATCH] 459 Allow edit of ipakrbokasdelegate in Web UI when attrlevelrights are unknown In-Reply-To: <52430C3D.4000406@redhat.com> References: <5241A239.2070104@redhat.com> <5242D449.6000905@redhat.com> <524304DC.8010402@redhat.com> <52430C3D.4000406@redhat.com> Message-ID: <5243F040.3010909@redhat.com> On 09/25/2013 06:15 PM, Ana Krivokapic wrote: > On 09/25/2013 05:44 PM, Petr Vobornik wrote: >> On 09/25/2013 02:17 PM, Ana Krivokapic wrote: >>> On 09/24/2013 04:31 PM, Petr Vobornik wrote: >>>> Old host entries are missing object class with krbticketflags attribute. >>>> Therefore UI does not receive attrlevelrights for it. This OC is added when >>>> ipakrbokasdelegate(krbticketflags) is set. >>>> >>>> This patch adds the usual hack for such cases. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3940 >>> >>> The patch works well. Could you please also add a regression test? >>> >> >> Test modified. Sadly, the test doesn't cover old entries after server upgrade, >> which are the reason for the UI hack. > > ACK! > > (There's an unused variable (pkey) at the start of the test_kerberos_flags() > method - you may just remove it before pushing.) > Unused variable removed. Pushed to master, ipa-3-3. -- Petr Vobornik From pvoborni at redhat.com Thu Sep 26 09:12:19 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 26 Sep 2013 11:12:19 +0200 Subject: [Freeipa-devel] [PATCH 0018] Ensure credentials structure is initialized In-Reply-To: <1380146822.2046.8.camel@localhost> References: <1380146822.2046.8.camel@localhost> Message-ID: <5243FA73.2030904@redhat.com> On 09/26/2013 12:07 AM, Nathaniel McCallum wrote: > Patch attached. > Fixes the issue. ACK -- Petr Vobornik From jcholast at redhat.com Thu Sep 26 10:20:08 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Sep 2013 12:20:08 +0200 Subject: [Freeipa-devel] [PATCH 0113] ipa-client: Set NIS domain name in the installer In-Reply-To: <5243F02D.9020005@redhat.com> References: <5243F02D.9020005@redhat.com> Message-ID: <52440A58.6000506@redhat.com> On 26.9.2013 10:28, Tomas Babej wrote: > Hi, > > Provides two new options for the ipa-client-install: > --nisdomain: specifies the NIS domain name > --no_nisdomain: flag to aviod setting the NIS domain name > > In case no --nisdomain is specified and --no_nisdomain flag was > not set, the IPA domain is used. > > Manual pages updated. > > http://fedorahosted.org/freeipa/ticket/3202 > > Design page: > > http://www.freeipa.org/page/V3_Minor_Enhancements > Is the --no-nisdomain option necessary? IMO --nisdomain with empty value (i.e. "--nisdomain=" or "--nisdomain ''") should be sufficient for this. Honza -- Jan Cholasta From pviktori at redhat.com Thu Sep 26 10:36:15 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 26 Sep 2013 12:36:15 +0200 Subject: [Freeipa-devel] [PATCH 0018] Ensure credentials structure is initialized In-Reply-To: <1380146822.2046.8.camel@localhost> References: <1380146822.2046.8.camel@localhost> Message-ID: <52440E1F.6040805@redhat.com> On 09/26/2013 12:07 AM, Nathaniel McCallum wrote: > Patch attached. > There's a ticket to make FreeIPA build with stricter warnings: https://fedorahosted.org/freeipa/ticket/3896 AFAIU this will trip -Wmissing-field-initializers. -- Petr? From jcholast at redhat.com Thu Sep 26 10:40:58 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Sep 2013 12:40:58 +0200 Subject: [Freeipa-devel] Please use the new LDAPEntry API in new code Message-ID: <52440F3A.80707@redhat.com> Hi, I have seen in several recently submitted patches that some people still use the old LDAP API. It is deprecated and is going to be removed soon, so please don't use it anymore. Whenever you have an urge to do something like this: dn, entry_attrs = ldap.get_entry(...) ... ldap.update_entry(dn, entry_attrs) Do this instead: entry = ldap.get_entry(...) ... ldap.update_entry(entry) Thanks! Honza -- Jan Cholasta From jcholast at redhat.com Thu Sep 26 10:54:30 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Sep 2013 12:54:30 +0200 Subject: [Freeipa-devel] [PATCH 111] ipa-client-install: Publish CA certificate to systemwide store In-Reply-To: <20130924161443.GC23991@redhat.com> References: <52416363.8050800@redhat.com> <524168C1.1050602@redhat.com> <524177C2.8030802@redhat.com> <20130924161443.GC23991@redhat.com> Message-ID: <52441266.1020804@redhat.com> On 24.9.2013 18:14, Nalin Dahyabhai wrote: > On Tue, Sep 24, 2013 at 01:30:10PM +0200, Jan Cholasta wrote: >> We discussed this with Tom?? off-line and it turns out that >> ipa-client-install fails if the CA cert is not added to >> /etc/pki/nssdb. >> >> However, according to p11-kit docs it should work: >> . I >> wonder what needs to be done to make it work in IPA... > > On my system, there's no symlink to libnssckbi.so (or the right location > in the link farm under /etc/alternatives) in /etc/pki/nssdb, so that > database isn't going to automatically pull in the list of trusted CAs > that p11-kit maintains. > > Whether the database under /etc/pki/nssdb should automatically include > the usual set of trust anchors is probably a different conversation. Thanks for the info. Tom??, the patch is fine then. I have one more nitpick though: why did you change "the default NSS database" to "the NSS database"? The database in /etc/pki/nssdb *is* the default NSS database, so please change it back. Also I think "systemwide CA trust database" is better than "systemwide CA store". Honza -- Jan Cholasta From tbabej at redhat.com Thu Sep 26 10:59:46 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 26 Sep 2013 12:59:46 +0200 Subject: [Freeipa-devel] [PATCH 111] ipa-client-install: Publish CA certificate to systemwide store In-Reply-To: <52441266.1020804@redhat.com> References: <52416363.8050800@redhat.com> <524168C1.1050602@redhat.com> <524177C2.8030802@redhat.com> <20130924161443.GC23991@redhat.com> <52441266.1020804@redhat.com> Message-ID: <524413A2.2070601@redhat.com> On 09/26/2013 12:54 PM, Jan Cholasta wrote: > On 24.9.2013 18:14, Nalin Dahyabhai wrote: >> On Tue, Sep 24, 2013 at 01:30:10PM +0200, Jan Cholasta wrote: >>> We discussed this with Tom?? off-line and it turns out that >>> ipa-client-install fails if the CA cert is not added to >>> /etc/pki/nssdb. >>> >>> However, according to p11-kit docs it should work: >>> . I >>> wonder what needs to be done to make it work in IPA... >> >> On my system, there's no symlink to libnssckbi.so (or the right location >> in the link farm under /etc/alternatives) in /etc/pki/nssdb, so that >> database isn't going to automatically pull in the list of trusted CAs >> that p11-kit maintains. >> >> Whether the database under /etc/pki/nssdb should automatically include >> the usual set of trust anchors is probably a different conversation. > > Thanks for the info. > > Tom??, the patch is fine then. I have one more nitpick though: why did > you change "the default NSS database" to "the NSS database"? The > database in /etc/pki/nssdb *is* the default NSS database, so please > change it back. Also I think "systemwide CA trust database" is better > than "systemwide CA store". > > Honza > I fixed the descriptions. Updated patch attached. Tomas -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0111-2-ipa-client-install-Publish-CA-certificate-to-systemw.patch Type: text/x-patch Size: 4099 bytes Desc: not available URL: From pviktori at redhat.com Thu Sep 26 11:10:33 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 26 Sep 2013 13:10:33 +0200 Subject: [Freeipa-devel] [PATCH] [Fedora] Update translations from Transifex Message-ID: <52441629.5040402@redhat.com> Hello, There'll be a Fedora 20 L10n test on Thursday, and maintainers are asked to push packages with updated translations by Friday. We're planning another minor release after that deadline; in the mean time I will put this patch into Fedora 20 & Rawhide only. The patch goes on top of the ipa-3-3 branch. Welcome to new translators: Ubuntu's Adolfo Jayme Barrientos provided lots of new Spanish words, and Dralyab and G? Baylardfor helped to keep French up to date. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-Update-translations-from-Transifex.tar.xz Type: application/x-xz Size: 32380 bytes Desc: not available URL: From mkosek at redhat.com Thu Sep 26 12:02:31 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Sep 2013 14:02:31 +0200 Subject: [Freeipa-devel] [PATCH 0113] ipa-client: Set NIS domain name in the installer In-Reply-To: <5243F02D.9020005@redhat.com> References: <5243F02D.9020005@redhat.com> Message-ID: <52442257.80108@redhat.com> On 09/26/2013 10:28 AM, Tomas Babej wrote: > Hi, > > Provides two new options for the ipa-client-install: > --nisdomain: specifies the NIS domain name > --no_nisdomain: flag to aviod setting the NIS domain name > > In case no --nisdomain is specified and --no_nisdomain flag was > not set, the IPA domain is used. > > Manual pages updated. > > http://fedorahosted.org/freeipa/ticket/3202 > > Design page: > > http://www.freeipa.org/page/V3_Minor_Enhancements > Are you sure that authconfig is the right place to configure nisdomain? # authconfig --nisdomain example.com --update Stopping sssd: [ OK ] # service sssd status sssd is stopped # nisdomainname (none) We also need to verify that netgroups and SUDO support in SSSD will work with the new --nisdomain option. Martin From jcholast at redhat.com Thu Sep 26 12:22:13 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Sep 2013 14:22:13 +0200 Subject: [Freeipa-devel] [PATCHES] 106-113 Access raw LDAP values directly from LDAPEntry In-Reply-To: <52419527.70200@redhat.com> References: <512E26E1.5010302@redhat.com> <52419527.70200@redhat.com> Message-ID: <524426F5.6010006@redhat.com> On 24.9.2013 15:35, Jan Cholasta wrote: > On 27.2.2013 16:31, Jan Cholasta wrote: >> Hi, >> >> these patches add the ability to access and manipulate raw attribute >> values as they are returned from python-ldap to the LDAPEntry class. >> This is useful for comparing entries, computing modlists for the modify >> operation, deleting values that don't match the syntax of an attribute, >> etc., because we don't need to care what syntax does a particular >> attribute use, or what Python type is used for it in the framework (raw >> values are always list of str). It should also make interaction with >> non-389 DS LDAP servers easier in the framework. >> >> (It might be too late for this kind of changes to get into 3.2 now, I'm >> posting these patches mainly so that you are aware that they exist.) >> >> Honza >> > > This is now planned for 3.4: > > I fixed some issues in these patches and refined the API. Updated > patches attached. > > Also added a patch to use raw values when adding new entries and a patch > which refines LDAPEntry.single_value, so that it is consistent with the > rest of the changes introduced in the patches. > > Patch 110 will probably be dropped in favor of Petr Viktorin's schema > update patches, but I included it anyway. > > Incidentally, this also fixes > and possibly also > . > > Honza > Noticed a couple more issues and fixed them. Updated patches attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-106.3-Make-LDAPEntry-a-wrapper-around-dict-rather-than-a-d.patch Type: text/x-patch Size: 7272 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-107.3-Introduce-IPASimpleLDAPObject.decode-method-for-deco.patch Type: text/x-patch Size: 3308 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-108.3-Always-use-lists-for-values-in-LDAPEntry-internally.patch Type: text/x-patch Size: 4001 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-109.3-Decode-and-encode-attribute-values-in-LDAPEntry-on-d.patch Type: text/x-patch Size: 17310 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-110.3-Make-sure-attributeTypes-updates-are-done-before-obj.patch Type: text/x-patch Size: 1088 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-111.3-Remove-legacy-toDict-and-origDataDict-methods-of-LDA.patch Type: text/x-patch Size: 4878 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-112.3-Store-encoded-attribute-values-from-search-results-d.patch Type: text/x-patch Size: 886 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-113.3-Use-encoded-values-from-entry-objects-directly-when-.patch Type: text/x-patch Size: 3253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-121.3-Use-encoded-values-from-entry-objects-directly-when-.patch Type: text/x-patch Size: 1478 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-169.3-Turn-LDAPEntry.single_value-into-a-dictionary-like-p.patch Type: text/x-patch Size: 49542 bytes Desc: not available URL: From tbabej at redhat.com Thu Sep 26 12:24:57 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 26 Sep 2013 14:24:57 +0200 Subject: [Freeipa-devel] [PATCH 0113] ipa-client: Set NIS domain name in the installer In-Reply-To: <52442257.80108@redhat.com> References: <5243F02D.9020005@redhat.com> <52442257.80108@redhat.com> Message-ID: <52442799.5000406@redhat.com> On 09/26/2013 02:02 PM, Martin Kosek wrote: > On 09/26/2013 10:28 AM, Tomas Babej wrote: >> Hi, >> >> Provides two new options for the ipa-client-install: >> --nisdomain: specifies the NIS domain name >> --no_nisdomain: flag to aviod setting the NIS domain name >> >> In case no --nisdomain is specified and --no_nisdomain flag was >> not set, the IPA domain is used. >> >> Manual pages updated. >> >> http://fedorahosted.org/freeipa/ticket/3202 >> >> Design page: >> >> http://www.freeipa.org/page/V3_Minor_Enhancements >> > Are you sure that authconfig is the right place to configure nisdomain? > > > # authconfig --nisdomain example.com --update > Stopping sssd: [ OK ] > # service sssd status > sssd is stopped > # nisdomainname > (none) > > We also need to verify that netgroups and SUDO support in SSSD will work with > the new --nisdomain option. > > Martin We figured out with Martin that this is specific behaviour on the RHEL 6.4, on F19 I did not see sssd service being stopped. For nisdomainname command to read the configuration though, according to this Red Hat Access article you need to start ypbind service. https://access.redhat.com/site/articles/2278 This way I got it working on the F19. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbabej at redhat.com Thu Sep 26 12:28:40 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 26 Sep 2013 14:28:40 +0200 Subject: [Freeipa-devel] [PATCH 0113] ipa-client: Set NIS domain name in the installer In-Reply-To: <52440A58.6000506@redhat.com> References: <5243F02D.9020005@redhat.com> <52440A58.6000506@redhat.com> Message-ID: <52442878.9030702@redhat.com> On 09/26/2013 12:20 PM, Jan Cholasta wrote: > On 26.9.2013 10:28, Tomas Babej wrote: >> Hi, >> >> Provides two new options for the ipa-client-install: >> --nisdomain: specifies the NIS domain name >> --no_nisdomain: flag to aviod setting the NIS domain name >> >> In case no --nisdomain is specified and --no_nisdomain flag was >> not set, the IPA domain is used. >> >> Manual pages updated. >> >> http://fedorahosted.org/freeipa/ticket/3202 >> >> Design page: >> >> http://www.freeipa.org/page/V3_Minor_Enhancements >> > > Is the --no-nisdomain option necessary? IMO --nisdomain with empty > value (i.e. "--nisdomain=" or "--nisdomain ''") should be sufficient > for this. > > Honza > I just found --no-nisdomain more descriptive and explicit. If there is a consensus, I can remove it. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org From mkosek at redhat.com Thu Sep 26 12:32:12 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Sep 2013 14:32:12 +0200 Subject: [Freeipa-devel] [RFE] User Life-Cycle Management Message-ID: <5244294C.6000103@redhat.com> Hello developers! I prepared a first draft of User Life-Cycle Management feature, which should appear in later FreeIPA release. http://www.freeipa.org/page/V3/User_Life-Cycle_Management There are still open questions, the main one from my perspective is if the staged users should be stored in our main LDAP database/suffix or the alternate one. Both have pros and cons, I tried to list them in the design page. Keeping it in a separated suffix may allow less difficult maintenance of old and new FreeIPA servers as old FreeIPA servers and plugins (like ipa-kdb) will not see the staged users. But there are higher replication agreement and other costs connected with this approach. Comments, feedback is very welcome. Martin From mkosek at redhat.com Thu Sep 26 12:38:43 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Sep 2013 14:38:43 +0200 Subject: [Freeipa-devel] [PATCH 0113] ipa-client: Set NIS domain name in the installer In-Reply-To: <52442878.9030702@redhat.com> References: <5243F02D.9020005@redhat.com> <52440A58.6000506@redhat.com> <52442878.9030702@redhat.com> Message-ID: <52442AD3.8020408@redhat.com> On 09/26/2013 02:28 PM, Tomas Babej wrote: > On 09/26/2013 12:20 PM, Jan Cholasta wrote: >> On 26.9.2013 10:28, Tomas Babej wrote: >>> Hi, >>> >>> Provides two new options for the ipa-client-install: >>> --nisdomain: specifies the NIS domain name >>> --no_nisdomain: flag to aviod setting the NIS domain name >>> >>> In case no --nisdomain is specified and --no_nisdomain flag was >>> not set, the IPA domain is used. >>> >>> Manual pages updated. >>> >>> http://fedorahosted.org/freeipa/ticket/3202 >>> >>> Design page: >>> >>> http://www.freeipa.org/page/V3_Minor_Enhancements >>> >> >> Is the --no-nisdomain option necessary? IMO --nisdomain with empty value >> (i.e. "--nisdomain=" or "--nisdomain ''") should be sufficient for this. >> >> Honza >> > > I just found --no-nisdomain more descriptive and explicit. If there is a > consensus, I can remove it. > I am not aware of any precedent that would warrant --nisdomain="". IMO --no-nisdomain is more consistent with rest of the options. Martin From jcholast at redhat.com Thu Sep 26 12:45:03 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 26 Sep 2013 14:45:03 +0200 Subject: [Freeipa-devel] [PATCH 0113] ipa-client: Set NIS domain name in the installer In-Reply-To: <52442AD3.8020408@redhat.com> References: <5243F02D.9020005@redhat.com> <52440A58.6000506@redhat.com> <52442878.9030702@redhat.com> <52442AD3.8020408@redhat.com> Message-ID: <52442C4F.8060707@redhat.com> On 26.9.2013 14:38, Martin Kosek wrote: > On 09/26/2013 02:28 PM, Tomas Babej wrote: >> On 09/26/2013 12:20 PM, Jan Cholasta wrote: >>> On 26.9.2013 10:28, Tomas Babej wrote: >>>> Hi, >>>> >>>> Provides two new options for the ipa-client-install: >>>> --nisdomain: specifies the NIS domain name >>>> --no_nisdomain: flag to aviod setting the NIS domain name >>>> >>>> In case no --nisdomain is specified and --no_nisdomain flag was >>>> not set, the IPA domain is used. >>>> >>>> Manual pages updated. >>>> >>>> http://fedorahosted.org/freeipa/ticket/3202 >>>> >>>> Design page: >>>> >>>> http://www.freeipa.org/page/V3_Minor_Enhancements >>>> >>> >>> Is the --no-nisdomain option necessary? IMO --nisdomain with empty value >>> (i.e. "--nisdomain=" or "--nisdomain ''") should be sufficient for this. >>> >>> Honza >>> >> >> I just found --no-nisdomain more descriptive and explicit. If there is a >> consensus, I can remove it. >> > > I am not aware of any precedent that would warrant --nisdomain="". I have seen concerns about the number of ipa-client-install options in the past (not by me). > > IMO --no-nisdomain is more consistent with rest of the options. I don't see any other --