[Freeipa-users] Non-human users

[John Dennis]

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 <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/