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
> > 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.
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.
Simo Sorce * Red Hat, Inc * New York
Freeipa-users mailing list