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
