What is the difference between user and service account?

User accounts are used by real users, service accounts are used by system services such as web servers, mail transport agents, databases etc. By convention, and only by convention, service accounts have user IDs in the low range, e.g. < 1000 or so. Except for UID 0, service accounts don't have any special privileges. Service accounts may - and typically do - own specific resources, even device special files, but they don't have superuser-like privileges.

Service accounts can be created like ordinary user accounts (e.g. using useradd). However, service accounts are typically created and configured by the package manager upon installation of the service software. So, even as an administrator you should be rarely directly concerned with the creation of service accounts.

For good reason: In contrast to user accounts, service accounts often don't have a "proper" login shell, i.e. they have /usr/sbin/nologin as login shell (or, back in the old days, /bin/false). Moreover, service accounts are typically locked, i.e. it is not possible to login (for traditional /etc/passwd and /etc/shadow this can be achieved by setting the password hash to arbitrary values such as * or x). This is to harden the service accounts against abuse (defense in depth).

Having individual service accounts for each service serves two main purposes: It is a security measure to reduce the impact in case of an incident with one service (compartmentalization), and it simplifies administration as it becomes easier to track down what resources belong to which service. See this or this answers on related questions for more details.

Originally, users were intended to correspond to a human using the system, hence the name. Each process runs as a particular user, and each file is owned by a particular user. A special user, called root, is used for things that don't belong to any particular human user, i.e. the operating system itself. Since root corresponds to the operating system itself, it has all privileges.

Soon people found that it was convenient to create multiple system users, without extensive privileges. This allows isolating the various services that run on a machine, so that they don't tread on each others' toes. A service account (or “system account”, these two terms are synonyms) is one that corresponds to a service running on the system, rather than to someone using the system. You generally have a service account for each task running on the system that has its own set of privileges (e.g. its own files, its own network ports, etc.).

There is no formal definition of human vs system/service account. The kernel doesn't care (other than granting a lot of privileges to the user with UID 0). Most administration commands don't care either. Some typical differences are:

• A human user has a real name like “John Doe”, whereas a system user has a descriptive name like “Nasal daemon” or none at all.
• A human user has a real login shell (e.g. /bin/sh or /bin/bash or /bin/csh. Some system users have a shell (almost always /bin/sh), others don't, depending on how they are meant to be used (e.g. su foo requires foo to have a shell).
• A human user often has a password — but that's not always the case, for example a remote-only user might only have an SSH key. Note that on modern unices, the password is not in /etc/passwd but in some other file such as /etc/shadow.
• A human user's home directory is usually under /home (or some site-specific location), whereas a system user's home directory is usually not under /home and might not exist (but there are exceptions).
• Most sites designate a range of user IDs for system users and a disjoint range for human users. Reserving 100–65533 or 500–65533 or 1000–65533 is typical, and most distributions are set up to start allocating real user IDs from 500 or 1000.

On sites where accounts are shared across multiple machines, there is typically a central server that contains user lists, accessible via NIS or LDAP. The passwd entry in /etc/nsswitch.conf specifies where to find user information. It is common to have system users in the local /etc/passwd and real users from the network-wide database, but sometimes there are system users in the network-wide database (to enforce consistent UIDs, which facilitates server and data replication), and sometimes there are human users in the local file (to let them log in even when the network is hosed).

A human-accessible account disguised as a system user would typically not have a real name, but have a login shell, and either a password set or an SSH key, while having a user ID in the system range. In fact, it would be a better disguise to use an actual system account whose removal would cause some service to stop working. But you cannot have any hard-and-fast rules to detect potential attacks: by definition, attackers don't follow rules.

Service accounts and human accounts are managed by the same commands and recorded in the same files. Account creation commands may have options to set reasonable defaults for human vs service users, e.g. to pick a user ID in the proper range, and to prompt for a password for a human and disable password authentication for a service. For example, adduser vs adduser --system or useradd vs useradd -r on Linux.

• 1. a service account, a.k.a. technical account is an account that is designed to only be used by a service / application, not by a regular user.
• 2. Application and service developers want these accounts to restrict the associated processes rights and privileges instead of running their processes as root. Services as started by init, systemd or similar, which run as root, quickly downgrade to the service account to limit the risks. Depending on the OS used, the application accounts might be granted more privileges than regular accounts, e.g. the right to bind to a privileged TCP port, or on the opposite have their privileges reduced compared to a regular user, for example denying the service processes to call fork / exec. In such case, there is no need to have the services downgrading to the service account, they can be started with it.
• 3. You shouldn't need to but just create an account without a usable password and with a non working shell (e.g. /bin/false) and it won't be usable by a regular user, i.e. there will be no way to log in locally or remotely (e.g. thru ssh) using the account name. Like most limitations, using the root account or sudo allows to overcome it.