Re: [Freeipa-users] Search Base issues
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
Re: [Freeipa-users] Search Base issues
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
Re: [Freeipa-users] Search Base issues
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 HTH, Martin Martin On 09/02/2014 11:09 PM, Rob Crittenden wrote: Chris Whittle wrote: If I do this ldapsearch -LLL -H ldaps://DOMAIN:636 -x -D uid=mac_slave,cn=users,cn=accounts,dc=domain,dc=com -w 'nachopassword' -b uid=awesomeuser,cn=users,cn=accounts,dc=domain,dc=com It works fine AFAICT there currently isn't a permission for the compat tree. The admin user can do it via 'Admin can manage any entry and of course DM can do it because it can do anything. A temporary workaround would be to add an aci manually: dn: dc=example,dc=com changetype: modify add: aci aci: (targetattr = *)(target = ldap:///uid=*,cn=canlogin,cn=compat,dc=example,dc=com;)(version 3.0;acl Read canlogin compat tree;allow (compare,read,search) userdn = ldap:///all;;) This won't show up as a permission and will grant all authenticated users read access to the canlogin compat tree. I'm assuming here this contains entries keyed on uid. rob -- 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
Re: [Freeipa-users] Search Base issues
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
Re: [Freeipa-users] Search Base issues
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) On Wed, Sep 3, 2014 at 9:10 AM, Martin Kosek 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
Re: [Freeipa-users] Search Base issues
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
Re: [Freeipa-users] Search Base issues
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
Re: [Freeipa-users] Search Base issues
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
Re: [Freeipa-users] Search Base issues
Ok Dmitri, I got it added using what you sent and the following links https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt and https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html I think i'm 90% there with the caveat that I can't seem to see what permissions I need to give a user to view my NIS view. Right now Directory Manager can see it but that is it. Any ideas? On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle cwhi...@gmail.com wrote: Thanks Dimitri, before I get too far this rabbit hole (cause it looks a little scary) let me make sure I get it. So using Slap-NIS I should be able to create a view into FreeIPA that would show only a subset of user based on something like a group or an attribute? Then using the built in MAC Directory Utility (or any LDAP client) I should be able to use that Slap-NIS view as a searchbase and it would return just people I wanted. This could be used keep anyone outside that view from logging in? I'm sorry for the noob questions but there isn't a lot of good documentation on SlapNIS from first glance and I don't want to spend 2 days figuring it out if it's not going to work. As always extremely appreciated! Whitt On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal d...@redhat.com wrote: On 09/02/2014 03:04 AM, Chris Whittle wrote: I am trying to limit who can login to my macs and I'm having to stick to what OSX will let me do. Currently I can only limit users using the searchbase and right now it's cn=users,cn=accounts,dc=DOMAIN,dc=com This works fine unless I wanted to create a user that I wanted in LDAP for other purposes but not to login. So my questions are, A)Can we create different OUs in FreeIPA like most LDAP servers? You can use slapi-nis to create an alternative view of the tree or trees and point your special client to that tree. There you might be able to expose a small subset of users that match your special criteria. The slapi-nis and compat docs are in the doc folder in the corresponding git repo. IPA uses compat tree for its own purposes but you can tweak it if you need or create a different view. HTH B)If not anyone have any idea on how I could do this with OSX's directory Utility? Thanks! -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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
Re: [Freeipa-users] Search Base issues
On 09/02/2014 09:34 PM, Chris Whittle wrote: Ok Dmitri, I got it added using what you sent and the following links https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt and https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html I think i'm 90% there with the caveat that I can't seem to see what permissions I need to give a user to view my NIS view. Right now Directory Manager can see it but that is it. Any ideas? You got me :-) I would defer to specialist in this area to solve this problem. On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle cwhi...@gmail.com mailto:cwhi...@gmail.com wrote: Thanks Dimitri, before I get too far this rabbit hole (cause it looks a little scary) let me make sure I get it. So using Slap-NIS I should be able to create a view into FreeIPA that would show only a subset of user based on something like a group or an attribute? Then using the built in MAC Directory Utility (or any LDAP client) I should be able to use that Slap-NIS view as a searchbase and it would return just people I wanted. This could be used keep anyone outside that view from logging in? I'm sorry for the noob questions but there isn't a lot of good documentation on SlapNIS from first glance and I don't want to spend 2 days figuring it out if it's not going to work. As always extremely appreciated! Whitt On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 09/02/2014 03:04 AM, Chris Whittle wrote: I am trying to limit who can login to my macs and I'm having to stick to what OSX will let me do. Currently I can only limit users using the searchbase and right now it's cn=users,cn=accounts,dc=DOMAIN,dc=com This works fine unless I wanted to create a user that I wanted in LDAP for other purposes but not to login. So my questions are, A)Can we create different OUs in FreeIPA like most LDAP servers? You can use slapi-nis to create an alternative view of the tree or trees and point your special client to that tree. There you might be able to expose a small subset of users that match your special criteria. The slapi-nis and compat docs are in the doc folder in the corresponding git repo. IPA uses compat tree for its own purposes but you can tweak it if you need or create a different view. HTH B)If not anyone have any idea on how I could do this with OSX's directory Utility? Thanks! -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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
Re: [Freeipa-users] Search Base issues
hmmm... Is there not a permission or role in freeIPA that I could give a group or role just to see everything in my CN cn=canlogin,cn=compat,dc=DOMAIN,dc=com On Tue, Sep 2, 2014 at 3:06 PM, Dmitri Pal d...@redhat.com wrote: On 09/02/2014 09:34 PM, Chris Whittle wrote: Ok Dmitri, I got it added using what you sent and the following links https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt and https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html I think i'm 90% there with the caveat that I can't seem to see what permissions I need to give a user to view my NIS view. Right now Directory Manager can see it but that is it. Any ideas? You got me :-) I would defer to specialist in this area to solve this problem. On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle cwhi...@gmail.com wrote: Thanks Dimitri, before I get too far this rabbit hole (cause it looks a little scary) let me make sure I get it. So using Slap-NIS I should be able to create a view into FreeIPA that would show only a subset of user based on something like a group or an attribute? Then using the built in MAC Directory Utility (or any LDAP client) I should be able to use that Slap-NIS view as a searchbase and it would return just people I wanted. This could be used keep anyone outside that view from logging in? I'm sorry for the noob questions but there isn't a lot of good documentation on SlapNIS from first glance and I don't want to spend 2 days figuring it out if it's not going to work. As always extremely appreciated! Whitt On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal d...@redhat.com wrote: On 09/02/2014 03:04 AM, Chris Whittle wrote: I am trying to limit who can login to my macs and I'm having to stick to what OSX will let me do. Currently I can only limit users using the searchbase and right now it's cn=users,cn=accounts,dc=DOMAIN,dc=com This works fine unless I wanted to create a user that I wanted in LDAP for other purposes but not to login. So my questions are, A)Can we create different OUs in FreeIPA like most LDAP servers? You can use slapi-nis to create an alternative view of the tree or trees and point your special client to that tree. There you might be able to expose a small subset of users that match your special criteria. The slapi-nis and compat docs are in the doc folder in the corresponding git repo. IPA uses compat tree for its own purposes but you can tweak it if you need or create a different view. HTH B)If not anyone have any idea on how I could do this with OSX's directory Utility? Thanks! -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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
Re: [Freeipa-users] Search Base issues
On 09/02/2014 10:08 PM, Chris Whittle wrote: hmmm... Is there not a permission or role in freeIPA that I could give a group or role just to see everything in my CN cn=canlogin,cn=compat,dc=DOMAIN,dc=com I thint it might be related to the new permission system that was released in 4.0. Stay tuned, the chivalry is on the way... On Tue, Sep 2, 2014 at 3:06 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 09/02/2014 09:34 PM, Chris Whittle wrote: Ok Dmitri, I got it added using what you sent and the following links https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt and https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html I think i'm 90% there with the caveat that I can't seem to see what permissions I need to give a user to view my NIS view. Right now Directory Manager can see it but that is it. Any ideas? You got me :-) I would defer to specialist in this area to solve this problem. On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle cwhi...@gmail.com mailto:cwhi...@gmail.com wrote: Thanks Dimitri, before I get too far this rabbit hole (cause it looks a little scary) let me make sure I get it. So using Slap-NIS I should be able to create a view into FreeIPA that would show only a subset of user based on something like a group or an attribute? Then using the built in MAC Directory Utility (or any LDAP client) I should be able to use that Slap-NIS view as a searchbase and it would return just people I wanted. This could be used keep anyone outside that view from logging in? I'm sorry for the noob questions but there isn't a lot of good documentation on SlapNIS from first glance and I don't want to spend 2 days figuring it out if it's not going to work. As always extremely appreciated! Whitt On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 09/02/2014 03:04 AM, Chris Whittle wrote: I am trying to limit who can login to my macs and I'm having to stick to what OSX will let me do. Currently I can only limit users using the searchbase and right now it's cn=users,cn=accounts,dc=DOMAIN,dc=com This works fine unless I wanted to create a user that I wanted in LDAP for other purposes but not to login. So my questions are, A)Can we create different OUs in FreeIPA like most LDAP servers? You can use slapi-nis to create an alternative view of the tree or trees and point your special client to that tree. There you might be able to expose a small subset of users that match your special criteria. The slapi-nis and compat docs are in the doc folder in the corresponding git repo. IPA uses compat tree for its own purposes but you can tweak it if you need or create a different view. HTH B)If not anyone have any idea on how I could do this with OSX's directory Utility? Thanks! -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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
Re: [Freeipa-users] Search Base issues
Thanks Dmitri, I'm so close I can almost see the end! On Tue, Sep 2, 2014 at 3:24 PM, Dmitri Pal d...@redhat.com wrote: On 09/02/2014 10:08 PM, Chris Whittle wrote: hmmm... Is there not a permission or role in freeIPA that I could give a group or role just to see everything in my CN cn=canlogin,cn=compat,dc=DOMAIN,dc=com I thint it might be related to the new permission system that was released in 4.0. Stay tuned, the chivalry is on the way... On Tue, Sep 2, 2014 at 3:06 PM, Dmitri Pal d...@redhat.com wrote: On 09/02/2014 09:34 PM, Chris Whittle wrote: Ok Dmitri, I got it added using what you sent and the following links https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt and https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html I think i'm 90% there with the caveat that I can't seem to see what permissions I need to give a user to view my NIS view. Right now Directory Manager can see it but that is it. Any ideas? You got me :-) I would defer to specialist in this area to solve this problem. On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle cwhi...@gmail.com wrote: Thanks Dimitri, before I get too far this rabbit hole (cause it looks a little scary) let me make sure I get it. So using Slap-NIS I should be able to create a view into FreeIPA that would show only a subset of user based on something like a group or an attribute? Then using the built in MAC Directory Utility (or any LDAP client) I should be able to use that Slap-NIS view as a searchbase and it would return just people I wanted. This could be used keep anyone outside that view from logging in? I'm sorry for the noob questions but there isn't a lot of good documentation on SlapNIS from first glance and I don't want to spend 2 days figuring it out if it's not going to work. As always extremely appreciated! Whitt On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal d...@redhat.com wrote: On 09/02/2014 03:04 AM, Chris Whittle wrote: I am trying to limit who can login to my macs and I'm having to stick to what OSX will let me do. Currently I can only limit users using the searchbase and right now it's cn=users,cn=accounts,dc=DOMAIN,dc=com This works fine unless I wanted to create a user that I wanted in LDAP for other purposes but not to login. So my questions are, A)Can we create different OUs in FreeIPA like most LDAP servers? You can use slapi-nis to create an alternative view of the tree or trees and point your special client to that tree. There you might be able to expose a small subset of users that match your special criteria. The slapi-nis and compat docs are in the doc folder in the corresponding git repo. IPA uses compat tree for its own purposes but you can tweak it if you need or create a different view. HTH B)If not anyone have any idea on how I could do this with OSX's directory Utility? Thanks! -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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
Re: [Freeipa-users] Search Base issues
Chris Whittle wrote: hmmm... Is there not a permission or role in freeIPA that I could give a group or role just to see everything in my CN cn=canlogin,cn=compat,dc=DOMAIN,dc=com Can you provide more details on what you're doing, and how you are binding? Can you search the cn=users,cn=compat,dc=DOMAIN,dc=com tree? AFAICT you should be able to read cn=compat as long as you bind as a user. rob On Tue, Sep 2, 2014 at 3:06 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 09/02/2014 09:34 PM, Chris Whittle wrote: Ok Dmitri, I got it added using what you sent and the following links https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt and https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html I think i'm 90% there with the caveat that I can't seem to see what permissions I need to give a user to view my NIS view. Right now Directory Manager can see it but that is it. Any ideas? You got me :-) I would defer to specialist in this area to solve this problem. On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle cwhi...@gmail.com mailto:cwhi...@gmail.com wrote: Thanks Dimitri, before I get too far this rabbit hole (cause it looks a little scary) let me make sure I get it. So using Slap-NIS I should be able to create a view into FreeIPA that would show only a subset of user based on something like a group or an attribute? Then using the built in MAC Directory Utility (or any LDAP client) I should be able to use that Slap-NIS view as a searchbase and it would return just people I wanted. This could be used keep anyone outside that view from logging in? I'm sorry for the noob questions but there isn't a lot of good documentation on SlapNIS from first glance and I don't want to spend 2 days figuring it out if it's not going to work. As always extremely appreciated! Whitt On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 09/02/2014 03:04 AM, Chris Whittle wrote: I am trying to limit who can login to my macs and I'm having to stick to what OSX will let me do. Currently I can only limit users using the searchbase and right now it's cn=users,cn=accounts,dc=DOMAIN,dc=com This works fine unless I wanted to create a user that I wanted in LDAP for other purposes but not to login. So my questions are, A)Can we create different OUs in FreeIPA like most LDAP servers? You can use slapi-nis to create an alternative view of the tree or trees and point your special client to that tree. There you might be able to expose a small subset of users that match your special criteria. The slapi-nis and compat docs are in the doc folder in the corresponding git repo. IPA uses compat tree for its own purposes but you can tweak it if you need or create a different view. HTH B)If not anyone have any idea on how I could do this with OSX's directory Utility? Thanks! -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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
Re: [Freeipa-users] Search Base issues
For testing I'm using ldapsearch -LLL -H ldaps://DOMAIN636 -x -D cn=directory manager -w 'nachopassword' -b cn=canlogin,cn=compat,dc=domain,dc=com If I do it with directory manager it works fine, if I use my automation user (just a generic user with no extra permissions) it returns nothing, no error, just empty space if I add -v (verbose) i get ldap_initialize( ldaps://domain.com:636/??base ) filter: (objectclass=*) requesting: All userApplication attributes Thanks everyone! On Tue, Sep 2, 2014 at 3:31 PM, Rob Crittenden rcrit...@redhat.com wrote: Chris Whittle wrote: hmmm... Is there not a permission or role in freeIPA that I could give a group or role just to see everything in my CN cn=canlogin,cn=compat,dc=DOMAIN,dc=com Can you provide more details on what you're doing, and how you are binding? Can you search the cn=users,cn=compat,dc=DOMAIN,dc=com tree? AFAICT you should be able to read cn=compat as long as you bind as a user. rob On Tue, Sep 2, 2014 at 3:06 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 09/02/2014 09:34 PM, Chris Whittle wrote: Ok Dmitri, I got it added using what you sent and the following links https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt and https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html I think i'm 90% there with the caveat that I can't seem to see what permissions I need to give a user to view my NIS view. Right now Directory Manager can see it but that is it. Any ideas? You got me :-) I would defer to specialist in this area to solve this problem. On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle cwhi...@gmail.com mailto:cwhi...@gmail.com wrote: Thanks Dimitri, before I get too far this rabbit hole (cause it looks a little scary) let me make sure I get it. So using Slap-NIS I should be able to create a view into FreeIPA that would show only a subset of user based on something like a group or an attribute? Then using the built in MAC Directory Utility (or any LDAP client) I should be able to use that Slap-NIS view as a searchbase and it would return just people I wanted. This could be used keep anyone outside that view from logging in? I'm sorry for the noob questions but there isn't a lot of good documentation on SlapNIS from first glance and I don't want to spend 2 days figuring it out if it's not going to work. As always extremely appreciated! Whitt On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 09/02/2014 03:04 AM, Chris Whittle wrote: I am trying to limit who can login to my macs and I'm having to stick to what OSX will let me do. Currently I can only limit users using the searchbase and right now it's cn=users,cn=accounts,dc=DOMAIN,dc=com This works fine unless I wanted to create a user that I wanted in LDAP for other purposes but not to login. So my questions are, A)Can we create different OUs in FreeIPA like most LDAP servers? You can use slapi-nis to create an alternative view of the tree or trees and point your special client to that tree. There you might be able to expose a small subset of users that match your special criteria. The slapi-nis and compat docs are in the doc folder in the corresponding git repo. IPA uses compat tree for its own purposes but you can tweak it if you need or create a different view. HTH B)If not anyone have any idea on how I could do this with OSX's directory Utility? Thanks! -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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
Re: [Freeipa-users] Search Base issues
If I do this ldapsearch -LLL -H ldaps://DOMAIN:636 -x -D uid=mac_slave,cn=users,cn=accounts,dc=domain,dc=com -w 'nachopassword' -b uid=awesomeuser,cn=users,cn=accounts,dc=domain,dc=com It works fine **Mac_Slave is my automation user. On Tue, Sep 2, 2014 at 3:40 PM, Chris Whittle cwhi...@gmail.com wrote: For testing I'm using ldapsearch -LLL -H ldaps://DOMAIN636 -x -D cn=directory manager -w 'nachopassword' -b cn=canlogin,cn=compat,dc=domain,dc=com If I do it with directory manager it works fine, if I use my automation user (just a generic user with no extra permissions) it returns nothing, no error, just empty space if I add -v (verbose) i get ldap_initialize( ldaps://domain.com:636/??base ) filter: (objectclass=*) requesting: All userApplication attributes Thanks everyone! On Tue, Sep 2, 2014 at 3:31 PM, Rob Crittenden rcrit...@redhat.com wrote: Chris Whittle wrote: hmmm... Is there not a permission or role in freeIPA that I could give a group or role just to see everything in my CN cn=canlogin,cn=compat,dc=DOMAIN,dc=com Can you provide more details on what you're doing, and how you are binding? Can you search the cn=users,cn=compat,dc=DOMAIN,dc=com tree? AFAICT you should be able to read cn=compat as long as you bind as a user. rob On Tue, Sep 2, 2014 at 3:06 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 09/02/2014 09:34 PM, Chris Whittle wrote: Ok Dmitri, I got it added using what you sent and the following links https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt and https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html I think i'm 90% there with the caveat that I can't seem to see what permissions I need to give a user to view my NIS view. Right now Directory Manager can see it but that is it. Any ideas? You got me :-) I would defer to specialist in this area to solve this problem. On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle cwhi...@gmail.com mailto:cwhi...@gmail.com wrote: Thanks Dimitri, before I get too far this rabbit hole (cause it looks a little scary) let me make sure I get it. So using Slap-NIS I should be able to create a view into FreeIPA that would show only a subset of user based on something like a group or an attribute? Then using the built in MAC Directory Utility (or any LDAP client) I should be able to use that Slap-NIS view as a searchbase and it would return just people I wanted. This could be used keep anyone outside that view from logging in? I'm sorry for the noob questions but there isn't a lot of good documentation on SlapNIS from first glance and I don't want to spend 2 days figuring it out if it's not going to work. As always extremely appreciated! Whitt On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 09/02/2014 03:04 AM, Chris Whittle wrote: I am trying to limit who can login to my macs and I'm having to stick to what OSX will let me do. Currently I can only limit users using the searchbase and right now it's cn=users,cn=accounts,dc=DOMAIN,dc=com This works fine unless I wanted to create a user that I wanted in LDAP for other purposes but not to login. So my questions are, A)Can we create different OUs in FreeIPA like most LDAP servers? You can use slapi-nis to create an alternative view of the tree or trees and point your special client to that tree. There you might be able to expose a small subset of users that match your special criteria. The slapi-nis and compat docs are in the doc folder in the corresponding git repo. IPA uses compat tree for its own purposes but you can tweak it if you need or create a different view. HTH B)If not anyone have any idea on how I could do this with OSX's directory Utility? Thanks! -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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
Re: [Freeipa-users] Search Base issues
Chris Whittle wrote: If I do this ldapsearch -LLL -H ldaps://DOMAIN:636 -x -D uid=mac_slave,cn=users,cn=accounts,dc=domain,dc=com -w 'nachopassword' -b uid=awesomeuser,cn=users,cn=accounts,dc=domain,dc=com It works fine AFAICT there currently isn't a permission for the compat tree. The admin user can do it via 'Admin can manage any entry and of course DM can do it because it can do anything. A temporary workaround would be to add an aci manually: dn: dc=example,dc=com changetype: modify add: aci aci: (targetattr = *)(target = ldap:///uid=*,cn=canlogin,cn=compat,dc=example,dc=com;)(version 3.0;acl Read canlogin compat tree;allow (compare,read,search) userdn = ldap:///all;;) This won't show up as a permission and will grant all authenticated users read access to the canlogin compat tree. I'm assuming here this contains entries keyed on uid. rob **Mac_Slave is my automation user. On Tue, Sep 2, 2014 at 3:40 PM, Chris Whittle cwhi...@gmail.com mailto:cwhi...@gmail.com wrote: For testing I'm using ldapsearch -LLL -H ldaps://DOMAIN636 -x -D cn=directory manager -w 'nachopassword' -b cn=canlogin,cn=compat,dc=domain,dc=com If I do it with directory manager it works fine, if I use my automation user (just a generic user with no extra permissions) it returns nothing, no error, just empty space if I add -v (verbose) i get ldap_initialize( ldaps://domain.com:636/??base http://domain.com:636/??base ) filter: (objectclass=*) requesting: All userApplication attributes Thanks everyone! On Tue, Sep 2, 2014 at 3:31 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Chris Whittle wrote: hmmm... Is there not a permission or role in freeIPA that I could give a group or role just to see everything in my CN cn=canlogin,cn=compat,dc=DOMAIN,dc=com Can you provide more details on what you're doing, and how you are binding? Can you search the cn=users,cn=compat,dc=DOMAIN,dc=com tree? AFAICT you should be able to read cn=compat as long as you bind as a user. rob On Tue, Sep 2, 2014 at 3:06 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com mailto:d...@redhat.com mailto:d...@redhat.com wrote: On 09/02/2014 09:34 PM, Chris Whittle wrote: Ok Dmitri, I got it added using what you sent and the following links https://git.fedorahosted.org/cgit/slapi-nis.git/tree/doc/sch-getting-started.txt and https://www.redhat.com/archives/freeipa-users/2009-August/msg00013.html I think i'm 90% there with the caveat that I can't seem to see what permissions I need to give a user to view my NIS view. Right now Directory Manager can see it but that is it. Any ideas? You got me :-) I would defer to specialist in this area to solve this problem. On Tue, Sep 2, 2014 at 9:00 AM, Chris Whittle cwhi...@gmail.com mailto:cwhi...@gmail.com mailto:cwhi...@gmail.com mailto:cwhi...@gmail.com wrote: Thanks Dimitri, before I get too far this rabbit hole (cause it looks a little scary) let me make sure I get it. So using Slap-NIS I should be able to create a view into FreeIPA that would show only a subset of user based on something like a group or an attribute? Then using the built in MAC Directory Utility (or any LDAP client) I should be able to use that Slap-NIS view as a searchbase and it would return just people I wanted. This could be used keep anyone outside that view from logging in? I'm sorry for the noob questions but there isn't a lot of good documentation on SlapNIS from first glance and I don't want to spend 2 days figuring it out if it's not going to work. As always extremely appreciated! Whitt On Tue, Sep 2, 2014 at 3:54 AM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com mailto:d...@redhat.com mailto:d...@redhat.com wrote: On 09/02/2014 03:04 AM, Chris Whittle wrote: I am trying to limit who can login to my macs and I'm having to stick to what OSX will let me do.
