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?
rob
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
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
