On 02/15/2013 03:46 PM, Simo Sorce wrote:
> On Fri, 2013-02-15 at 12:01 -0700, Orion Poplawski wrote:
>> On 02/15/2013 11:49 AM, Rob Crittenden wrote:
>>>> Another example is a backup user account that backup software logs in as.
>>>> Also some accounts that own files and some services run as that are
>>>> needed on multiple machines. I suppose we could use puppet to manage
>>>> those, but ldap seems more convenient.
>>> In any case, it is probably reasonable to discuss these two cases
>>> As John said, for pure system daemons it is probably best to leave those as
>>> local accounts.
>>> For quasi local accounts like mock or backup accounts things get a little
>>> fuzzy. I think I would avoid storing the user in /etc/passwd and the group
>>> IPA, if possible. I imagine that sssd would be able to handle the case ok
>>> I don't know that this is something they actively test.
>>> Why do you want/need to distinguish them from "real" people?
>> What brought this up was the need to sync users from LDAP into another
>> authentication system, and for that system we only wanted "real" human
>> to be listed.
>> Also, we don't want these accounts listed in things like Thunderbird LDAP
>> address books (hence no "*person" attributes: mail cn givenName sn).
>> And just for doing periodic audits it would be helpful for distinguishing
>> between them.
>> I've been trying to track down any bugs I may have filed without success,
>> I'm pretty sure I tried at first adding a system user to LDAP groups and
>> 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 is an interesting use case, it would probably be appropriate to
> have a RFE filed to allow to create ipa users marked as 'non-person' so
> that they are not assigned the person objectclass.
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?
Freeipa-users mailing list