On 02/15/2013 02:23 PM, Orion Poplawski wrote:
On 02/15/2013 12:01 PM, Orion Poplawski wrote:
I've been trying to track down any bugs I may have filed without success, but
I'm pretty sure I tried at first adding a system user to LDAP groups and that
not working unless the system user was in LDAP. This may have been before I
started using SSSD on the servers so I'll need to retest this.
This still appears to be the case. As soon as I removed the system user from
our current ldap database, id now longer reported any other group memberships.
This is with the default using "memberUid" for group membership. With the
IPA schema of recording group membership with the full dn, it seems the user
would have to be in the database to have a dn.
Yes you're right, the user has to exist in LDAP in order to be a member
of a group managed in LDAP.
If your goal is not to have system users returned in a ldap search
you'll have to filter them (e.g. adding (uid >= 1024) to the search
filter because system users are usually less than some magic number, it
used to be 512, now it's 1024 I believe). Adding that (or some other
filter criteria) to every LDAP client in your enterprise is probably not
viable.
I don't think setting ACL's to prevent specific users from being
returned in searches is viable either because they need to visible
during the operations they're involved in.
The problem as I see it is that IPA by design stores users in a "flat"
namespace. That means you cannot partition users by putting them in
different LDAP containers (trees). During the design of IPA the issue of
whether we would use a flat namespace or permit different namespaces
(via LDAP containers, conventionally called organizational units, i.e.
OU's) came up. There was a sentiment that OU's had historically been
problematic, hence we have a flat namespace and partitioning would be
done via filtering. Thus only thing I can suggest at the moment is
filtering, perhaps others have a better idea.
Your other alternative is not put these system users in LDAP and instead
use local users & groups managed via some other mechanism (puppet?).
I'm not sure this issue has come up before, it does present some
interesting issues.
John
--
John Dennis <jden...@redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
