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 Dennis <jden...@redhat.com>

Looking to carve out IT costs?

Freeipa-users mailing list

Reply via email to