There are lots of use cases where it makes sense to have a share 'application' 

-agentless monitoring
-penetration testing
-code deployment

The system user is not always the user an application is running as.  Sometimes 
it is just a user that is used to gain access to a remote system.  


Brian Cook
Solutions Architect, Red Hat, Inc.

On Feb 15, 2013, at 9:52 AM, John Dennis <> wrote:

> On 02/15/2013 12:32 PM, Orion Poplawski wrote:
>> On 02/15/2013 09:45 AM, Petr Viktorin wrote:
>>> On 02/15/2013 05:36 PM, Orion Poplawski wrote:
>>>> Is there a recommended way to distinguish between "real" human user
>>>> accounts in IPA and non-human "system" accounts in IPA?
>>> What kind of system accounts do you have in IPA? Consider not storing them 
>>> in
>>> IPA at all.
>> Yeah, that seems like the better idea, but:
>> I think the main issue we've run into is needing the apache user to be a
>> member of groups in ldap, and that not working unless the apache user was in
>> ldap as well.
>> 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.
> Generally system users do not need accounts. Most daemons define a system 
> user only for the purposes of having a uid they can drop privileges to after 
> starting as root. These users typically do not have shells (technically their 
> shell is /sbin/nologin) nor home directories. Also these system accounts 
> typically have fixed well known uid's. Also these system users are 
> automatically created when you install the package. Thus there is little 
> point in trying to manage them. If you find yourself with a need to manage 
> them step back and ask yourself why.
> -- 
> John Dennis <>
> Looking to carve out IT costs?
> _______________________________________________
> Freeipa-users mailing list

Freeipa-users mailing list

Reply via email to