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

Reply via email to