[Freeipa-users] Search Base issues

Chris Whittle cwhittl at gmail.com
Sat Sep 6 14:08:34 UTC 2014


Thanks Martin, can you do SSSD on MAC's?


On Thu, Sep 4, 2014 at 4:45 AM, Martin Kosek <mkosek at redhat.com> wrote:

> 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
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140906/b2525ff3/attachment.htm>


More information about the Freeipa-users mailing list