[Freeipa-users] Search Base issues
Chris Whittle
cwhittl at gmail.com
Wed Sep 3 20:45:29 UTC 2014
Success here is my LDIF if anyone needs to do this with a MAC
> dn: cn=Mac Users, cn=Schema Compatibility, cn=plugins, cn=config
>
> objectClass: top
>
> objectClass: extensibleObject
>
> cn: Mac Users
>
> schema-compat-search-base: cn=users,cn=accounts,dc=DOMAIN,dc=com
>
> schema-compat-search-filter:
> (&(objectClass=posixaccount)(memberOf=cn=canlogin,cn=groups,cn=accounts,dc
> DOMAIN,dc=com))
>
> schema-compat-container-group: cn=compat,dc=DOMAIN,dc=com
>
> schema-compat-container-rdn: cn=canlogin
>
> schema-compat-entry-rdn: cn=%{cn}
>
> schema-compat-entry-attribute: objectclass=inetOrgPerson
>
> schema-compat-entry-attribute: objectclass=posixAccount
>
> schema-compat-entry-attribute: gecos=%{cn}
>
> schema-compat-entry-attribute: cn=%{cn}
>
> schema-compat-entry-attribute: uid=%{uid}
>
> schema-compat-entry-attribute: uidNumber=%{uidNumber}
>
> schema-compat-entry-attribute: gidNumber=%{gidNumber}
>
> schema-compat-entry-attribute: loginShell=%{loginShell}
>
> schema-compat-entry-attribute: homeDirectory=%{homeDirectory}
>
On Wed, Sep 3, 2014 at 1:04 PM, Chris Whittle <cwhittl at gmail.com> wrote:
> 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/c5ad7b70/attachment.htm>
More information about the Freeipa-users
mailing list