[Freeipa-users] Search Base issues

[Martin Kosek]

Ok, thanks. Good to see it is working for you.

I see you actually do authorization decision based on Schema Compatibility
plugin :) Note that an alternate, preferred way of doing authorization in
FreeIPA though is HBAC where you would configure which group of users can login
to which machines.

But this is only being enforced when SSSD is on the client machine, so it may
not be working for all your machines.

Martin

On 09/03/2014 10:45 PM, Chris Whittle wrote:
> 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
>>>>
>>>>
>>>
>>>
>>
>