User and service accounts, and permissions

Why this matters

Physical security keeps people away from the hardware. Accounts and permissions decide what people, and programs, can do once they reach a server over the network. Most breaches do not break encryption or defeat a firewall. They use an account: a stolen password, an old account nobody disabled, or a service account with far more power than its job needs.

This lesson covers the principle that governs access, the kinds of accounts a server has, the special care service accounts need, how permissions combine to decide what someone can actually do, and the routine that removes access nobody should still have.

The lesson

Least privilege and role-based access

The principle of least privilege says every account should have exactly the access it needs to do its job, and no more. A help desk technician who resets passwords does not need to be a domain administrator. An application that reads one database does not need rights to every database on the server.

Least privilege limits damage. If an account is compromised, or its owner makes a mistake, the harm is limited to what that account could do. An attacker who steals an ordinary user's password gets an ordinary user's access; one who steals an administrator's gets everything.

Granting permissions to individuals one at a time does not scale, and it drifts. Role-based access control (RBAC) assigns permissions to roles, usually implemented as groups, and people receive access by being placed in the groups for their job. When someone joins the finance team, they are added to the finance group; when they move, they are removed from it and added to their new team's. Permissions are then reviewed by role rather than person by person.

A common Windows practice is to put users into groups by role, and give those groups permissions on resources, rather than granting permissions to individual users directly. It makes access easy to understand and easy to change.

Local accounts against directory accounts

A local account exists on one server only, stored in that server's own account database: the Security Accounts Manager (SAM) on Windows, or /etc/passwd and /etc/shadow on Linux. It can only be used to log on to that machine.

A directory account is stored centrally, typically in Active Directory on Windows networks or an LDAP directory, and can be used on any server that trusts the directory.

Directory accounts are preferred for almost everything, because they are managed in one place. A password change, a disabled account or a group membership change takes effect everywhere at once, and policies such as password rules apply consistently. Local accounts, by contrast, must be managed server by server, and are easily forgotten.

Local accounts still have roles. Every server has a built-in local administrator or root account, and some local access is needed for when the server cannot reach the directory. These accounts are powerful and often share the same password across many servers, so that one stolen password unlocks them all. Tools such as Microsoft's LAPS (Local Administrator Password Solution) give every server a unique, automatically rotated local administrator password, stored securely in the directory.

Service accounts and managed service accounts

A service account is an account used by an application or service rather than by a person: the identity a database engine, backup agent or web application runs as.

Service accounts are a common weakness:

• they are often given too much access, sometimes domain administrator rights, because it was the quickest way to make an installation work;
• their passwords are often set to never expire, and are rarely changed, because changing them means updating every service that uses them;
• their passwords end up written in scripts and documentation;
• nobody is sure what uses them, so nobody dares disable them.

Good practice is to give each service its own account, with only the permissions that service needs, denied the ability to log on interactively, and documented with its owner and purpose.

Windows offers a better answer in managed service accounts, and group managed service accounts (gMSAs) that work across several servers. Their passwords are long, random, and changed automatically by the domain, and no person ever needs to know them. On Linux, services commonly run as dedicated unprivileged system accounts with no login shell, so a compromised service cannot be used to log on.

Inheritance and effective permissions

Permissions on files and folders flow downwards. By default, a file or subfolder inherits the permissions of the folder it sits in, so setting permissions at the top of a share applies them to everything beneath. Inheritance can be disabled on a folder to give it different permissions, which is useful but creates exceptions that are easy to lose track of.

What a user can actually do, their effective permissions, is the result of combining everything that applies to them: permissions granted to their account and to every group they belong to, whether granted directly or inherited. Permissions from multiple groups add together, with one important exception: on Windows, an explicit deny normally overrides an allow.

Windows file shares add a second layer. A shared folder has share permissions, and the files within it have NTFS permissions. Someone connecting over the network gets the more restrictive of the two. A common approach is to keep share permissions broad and control access with NTFS permissions, so there is one place to look.

On Linux, standard permissions give read, write and execute to the file's owner, its group, and others, set with chmod and chown, and ACLs add finer control when needed.

When someone has more or less access than expected, Windows' Effective Access tab, in a folder's advanced security settings, calculates their actual permissions from all these sources.

Access reviews, and removing accounts nobody uses

Access accumulates. People change jobs and keep their old group memberships as well as gaining new ones; contractors finish and their accounts remain; test accounts are created and forgotten. Each unnecessary account or permission is an opportunity for an attacker, and old accounts are especially attractive, since nobody notices when they are used.

Access reviews, also called recertification, check access periodically. The owner of each system or data set, or each employee's manager, confirms that every account and permission is still needed, and anything that is not is removed. Privileged accounts should be reviewed more often than ordinary ones.

Alongside reviews:

• Disable accounts promptly when people leave, as part of the leaving process, not when someone happens to notice.
• Find inactive accounts, such as those with no logon for 90 days, using the directory's last-logon information, and disable them.
• Disable before deleting. A disabled account can be re-enabled if it turns out something depended on it; a deleted account cannot simply be restored, and on Windows, its security identifier is gone for good.