Thanks Rob for the explanation! I think I have it working, I just have to test a machine and verify.
On Wed, Sep 3, 2014 at 12:47 PM, Rob Crittenden <rcrit...@redhat.com> wrote: > Chris Whittle wrote: > > That worked, but having issues get it to work with the OSX Directory > > Utility. > > I'm wondering if it's because when you go against the OU normally it's > > returning more info about the user versus what's being returned from the > > compat "view" I'm going to experiment with the attributes it's returning > > and see if that's it. > > > > I'm also wondering why FreeIPA doesn't support multiple OU's natively, > > this would be so much easier with multiple OUs (one for my non-users and > > one for my users) > > Because they are so very often used really, really poorly, resulting in > having to move entries around a lot with no real technical reason behind > it. Think about the number of times an IT department gets renamed, oops, > today they are called Global Support Services, oh no, didn't you hear, > now they are ... Each one requiring an entire subtree move. Where the > users exist in LDAP does not generally need to reflect the > organizational structure. > > Your case is a bit different from most, where you want to host two > completely separate kinds of users. > > rob > > > > > > > On Wed, Sep 3, 2014 at 9:10 AM, Martin Kosek <mko...@redhat.com > > <mailto:mko...@redhat.com>> wrote: > > > > On 09/03/2014 03:08 PM, Rob Crittenden wrote: > > > Martin Kosek wrote: > > >> On 09/03/2014 09:02 AM, Martin Kosek wrote: > > >>> In the meantime, you can use the workaround that Rob sent, you > > would just need > > >>> to delete it again when the fix is in, so that the permissions > > do not step on > > >>> each other. > > >> > > >> Actually, wait a minute. I think Rob's ACI example may be too > > wide, it may > > >> expose any attribute in the compat tree, including a potential > > userPassword. > > > > > > The ACI was on his custom cn=canlogin subtree, not all of > cn=compat. > > > > > >> As I see, it seems that slapi-nis plugin do not fortunately > > expose that, but it > > >> is safer to just list the attributes that one wants to display > > (this is also > > >> what we did in FreeIPA 4.0, no global wildcard allowing ACIs any > > more). > > >> > > >> I added a respective permission via Web UI (one part of it cannot > > be added via > > >> CLI, see https://fedorahosted.org/freeipa/ticket/4522) and compat > > tree now > > >> works for me. See attached example. > > >> > > >> Resulting permission shown in CLI: > > >> > > >> # ipa permission-show "TEMPORARY - Read compat tree" > > >> Permission name: TEMPORARY - Read compat tree > > >> Granted rights: read, search, compare > > >> Effective attributes: cn, description, gecos, gidnumber, > > homedirectory, > > >> loginshell, memberuid, > > >> objectclass, uid, uidnumber > > >> Bind rule type: all > > >> Subtree: dc=mkosek-fedora20,dc=test > > >> ACI target DN: cn=compat,dc=mkosek-fedora20,dc=test > > >> > > >> It is much easier to manipulate than ACI added via ldapmodify. > > > > > > I see you filed a bug on the missing CLI option. That's why I did > the > > > ACI, because I couldn't demonstrate how to add this ACI on the > CLI. I > > > hadn't gotten around to doing that last night. > > > > > > rob > > > > Right. Surprisingly, the option was available in Web UI, thus the > Web UI > > screenshot I attached to the thread :) But we have the CLI option > fixed > > already, will be part of FreeIPA 4.0.2 which will be released very > soon. > > > > Martin > > > > > >
-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project