The phrase “user account” refers to something which is often referred to simply as a “user”, but the longer phrase is meant to help distinguish a “user account” from the person, a.k.a. the “end user”, who is anticipated to be likely to use the user account. (Although those concepts are typically easy to keep separate in one's own mind, sometimes communication about an account may sound like a reference to the end user. Comments about “deleting the user” may be viewed as impersonal and unintentionally rude.)

[#usrbasop]: Basic Operations on User Accounts
[#useradd]: Adding a user account
[#userdel]: Removing a user account
[#userauth]: User authentication (Passwords, affecting whether enabled/disabled)
Authentication can be quite basic, or it can be a bit more complex. However, as each user needs a password, it is listed here in the basic operations sections.

One method of disabling a user's ability to log in is to change the credentials, such as the hash of whatever passphrase the user is using. The change can be systemic, such as prepending a sequence (such as a string consisting of a single character) which the end user won't possibly be able to enter, either due to being impossible to the hash algorithm or, a bit less secure but known to effectively work in some scenarios, simply being a string prepended to the password which the end user won't know (and won't likely crack). However, some environments have another setting/property for each user account that indicates whether it is disabled, and so knowing how to make sure the account is enabled can be important.

Simple logins: Username and basic passphrase
Key files
These are typically more secure than basic typed passphrases due to a substantially
One time passwords

A mixture of a neat/new technology (one time credentials) and an archaic technology that is best replaced (passwords).

Biometric reading technology
Some laptops have a fingerprint scanner.
Adjusting other user properties (e.g. home directory, etc.)
Home directory
Files, printers, etc.
Modifying a user's name, location, etc. Note that location and contact info may commonly be implemented in a way that allows such info to be commonly shared. Some properties, such as an end user's first name, might not be something that a typical end user has any way to change without going through an authorized staff member of the network administration. Others, such as a preferred E-Mail address or what shell is run with remote command lines, may be something more commonly allowing a user to edit.
Some of these settings may have defaults based on various factors such as: end user's typical physical location (such as which printers show up and which one is used by default), or other characteristics such as the person's position within an organization (such as setting the default printer for a graphics designer to a slower printer that prints with higher quality or more expensive paper, but having a financial user default to a printer that prints with lower quality but lower cost and higher speed.) Policies, including permissions, can certainly have an effect on what preferences make sense as defaults. Another example: Default outgoing E-Mail address.
Backing up/importing/exporting users
Policies (Enforcing policies)
User policies
ToS/EULA/etc. (Legal/documetnation/etc.)
Authentication Policies
e.g. password rotation (age, non-use of history), testing password strength
Other policies
File systems typically support permissions, which is a type of policy which is certainly important. Windows XP (and other systems) can force certain settings using a feature called "Local Policy". (Confirm: what operating systems have that? Win XP Home?) There is also “Group Policy”, which basically involves applying policies, similar to local policies, based on what group(s) an end user may be in.

Implementations of handling users: