[Freeipa-users] Search Base issues

[Chris Whittle]

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 <rcritten at 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 <mkosek at redhat.com
> > <mailto:mkosek at 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
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140903/ec32f9fa/attachment.htm>