Thanks Martin, can you do SSSD on MAC's?
On Thu, Sep 4, 2014 at 4:45 AM, Martin Kosek <mko...@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 <cwhi...@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 <rcrit...@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 <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