<div dir="ltr">Thanks Martin, can you do SSSD on MAC's? </div><div class="gmail_extra"> <div class="gmail_quote">On Thu, Sep 4, 2014 at 4:45 AM, Martin Kosek <<a href="mailto:mkosek@redhat.com" target="_blank">mkosek@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <div class="HOEnZb"><div class="h5"> 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 <<a href="mailto:cwhittl@gmail.com">cwhittl@gmail.com</a>> 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 <<a href="mailto:rcritten@redhat.com">rcritten@redhat.com</a>> >> 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 <<a href="mailto:mkosek@redhat.com">mkosek@redhat.com</a> >>>> <mailto:<a href="mailto:mkosek@redhat.com">mkosek@redhat.com</a>>> 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 <a href="https://fedorahosted.org/freeipa/ticket/4522" target="_blank">https://fedorahosted.org/freeipa/ticket/4522</a>) 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 >>>> >>>> >>> >>> >> > </div></div></blockquote></div> </div>