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 separately.

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 in
IPA, if possible. I imagine that sssd would be able to handle the case ok but
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 people 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, 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.

Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder Office                  FAX: 303-415-9702
3380 Mitchell Lane                       or...@nwra.com
Boulder, CO 80301                   http://www.nwra.com

Freeipa-users mailing list

Reply via email to