Enabling/Disabling User Accounts


There may be multiple approaches to prevent a user from being logged in. It is important that anyone who might need to restore the account later knows (or can quickly find out) what method was used so that the change can be effectively reversed (without resorting to more extreme measures involving creating a new (replacement) account).

Disabling the account

One may be to disable the account, which means to change a setting that specifies whether the account is enabled. Different terminology may be used: for example, the setting might indicate whether the account is “active”.

This may be considered a more advanced technique: simple introductory guides will often choose to instead show people how to change passwords to disable an account. An advantage to that approach is that people following such a guide will also know how to change the password for a user, which may also be useful information. Also, different implementations of user accounts may vary more in the method of disabling accounts (when compared to how those implementations vary in other aspects). Also, software may need to have specific support for the concept of an account being disabled. This may require some additional work by software developers (although is less of an issue if the software developer is simply checking whether or not logins are possible).

(Most/all of the following details after this overview section will be about disabling an account.)

Modifying credentials

Another method may be to change the credentials that allow a user to log in. One big, huge, gigantic consideration to keep in mind when taking this approach is to make sure that the user does not have different credentials which would also work. For example, modern Unix systems may support people logging in by presenting a “key”, or by interacting with a traditional prompt that asks for a username and password. If a password is modified, the user may not be able to log in by using that method.

However, if a key was already set up, the user might still be able to log in by using the alternate method. So fully disabling an account will involve making sure that the user cannot log in using any authentication method that is already set up.

Also, make sure the user cannot set up any additional authentication methods, perhaps by writing a file to a directory that would let a network key start to be accepted.

Some password mechanisms may involve comparing a hash of the correct password to a hash of the submitted password that was typed in by somebody. This change can be systematic, such as prepending text that is not possible to be in a hash. In an environment which is not very secure, where passwords are directly visible, one method may be to add some text to the password. That should work, in theory, as long as the person whose account is disabled won't be able to figure out that that text is. That also may have the advantage of allowing the account to be easily restored to be using the same old password again.

The section on handling passwords for user accounts has details about this approach.

[#adkybrki]: An example of how this could be performed insufficiently

Here is a hyphothetical example of how changing credentials might not be done sufficiently. Let's say, for examle, IT staff simply changed the login password for a user in order to lock the user out. It was known that the user was quite computer saavy, and the new IT Administrative staff knew about the possibility of multiple accepted methods of authentication. The IT administrator found that the user did indeed have a key stored in ~/.ssh/ which would allow the user to log into an SSH server. At that point, the IT staff decided things were locked down sufficiently. However, the previous (fired) staff member was able to get access to a remote user's computer which was logged into a VPN. If the ~/.ssh/ directory is writable (and if the SSH server doesn't refuse a key due to writability) then the user may be able to re-instate the key. This became possible, despite two steps taken to lock out the user, because the user's account remained officially “enabled”.

So, rather than play hide and seek with multiple possible authentication methods, it may be simpler to just mark an account as disabled. Hopefully multiple authentication methods will then treat the account as disabled, and refuse to let it be used.

Deleting an account

Another method may be to delete the actual user account, and plan to later re-create a user account that will again have all (or most) of the same information. This method may have some drawbacks, such as also losing information about the user account. Customizations to the user account, such as information about the person (such as where the person lives) or security settings that affect how much access that person had to certain data, may be lost. If the age of an account is tracked (which might someday be used to, for example, reward long-term staff members), then that information could be lost.

Another drawback to this method may be that it could be very easy to tell the account management software to go ahead and delete files stored in a location that is related to that account. That might NOT be desirable: simply disabling an account may be easier than the amount of effort required to be careful enough to make sure these sort of files are not accidentally deleted.

Adjusting security groups
Another possible method, though this is probably not generally preferred, may be to just remove the user from certain groups. The biggest problem with this method of adjusting the groups that a user is in is likely the part of making absolutely certain that this approach will work flawlessly: It seems quite easy to overlook the detail of a potential possibility of certain access being granted when it's not desired.
Adjusting permissions

Another approach may be to just adjust specific permissions so that the user's available permissions do not provide the ability to perform administrator functions. In the case of how many popular operating systems implementation user accounts, this is probably even less practical than trying to remove access by adjusting security groups. Therefore, this is NOT a recommended approach in such cases. However, it is being mentioned for the sake of completeness, and because this is a practical approach in some cases involving simpler implementations of user accounts. For instance, a user account may be something built into a very specific piece of software, and in such cases Administrator access for an account might be granted solely based on whether a simple setting is set.

Getting back to user implementations of popular operating systems, the previous statement may be worth a bit further description to justify why this approach shouldn't be used. Actually, adjusting permissions on a part of the file system heirarchy, such as a single file, may be feasible. However, adjusting permissions related to roles, such as whether the person is allowed to adjust other user accounts or make changes to file system permissions, is probably going to be too granular to be a good implementation. In addition to possibly requiring more work up front, over time, the biggest threat is the possibility of changes made to how user accounts are implemented by the operating system. Such changes could be made if the operating system is upgraded to a major new version (perhaps years from now), or perhaps by something much smaller like an operating system update or the installation of some sort of software.

In many/most popular implementations of handling users, performing these actions may require some elevated privileges to accomplish the task (using any of the approaches mentioned above).

If the user being removed had superuser access, and the plan is to use a new account for ongoing superuser access, see a warning: why using a long-term account should be used to remove/disable superuser access from an older account.


As a standard practice, backup files before they are modified. This is especially worthwhile when the files to be changed are known ahead of time. See backing up the user database.

How to disable an account in Unix
Standard accounts used by the operating system

Before proceeding with any of these methods, consider if the method is lossy. If so, it may be better to skip the method in this section, and instead disable the user account by modifying login password/credential information. (However, if taking an approach other than disabling the user, be sure to thoroughly, sufficiently disable ALL methods of logging in.)

You may use one of the following approaches:

Using command line

Using a command line may require an implementation which may vary a bit more between Unix operating systems than the vipw method. An advantage, though, is that using such a method may be more scriptable. Also, if the syntax is memorized, making a change by calling the correct command line utility may be faster than loading a text editor in vipw and then making the changes (including saving the changes and exiting the text editor).

Disabling a user in OpenBSD

This is lossy: this is documented to change the password data to something impossible to enter, and to change the shell to nologin. The latter effect could be changed by using “usermod -s ksh username ” (or using chsh instead of usermod, and using the same command line parameters just shown). However, that won't necessarily set the shell to the same value as it was before (if there is any possibility that the user may have had a custom setting for what shell to use). The password is permanently lost when the account is disabled. When this was performed in a real case, the password (or perhaps its hash?) became set to thirteen asterisks (“*************”). The password may be set again by using usermod or chpass, either of which will use the EDITOR operating system environment variable, or if that variable is not set, will use vi.

userdel -vp true username

Customize the username in the above example.

The OpenBSD “manual page” for the userdel command notes that command may preserve some existing data, effectively disabling the account. (This is briefly referred to by OpenBSD FAQ 10: Users.) It seems likely that the “preserve” value defaults to what is in the /etc/usermgmt.conf file. Setting it to true as shown above will cause the home directory to not be deleted.

Some example output (including echoed input):

# userdel -vp true root
pwd_mkdb: warning, unknown root shell
pwd_mkdb: warning, unknown root shell
pwd_mkdb: warning, unknown root shell

(Does "root" shell refer to user? If so, CSS that to show it is customized? Why does this happen?)

[#dsusrlpw]: Disabling Unix system user accounts by modifying login password/credential information

In Unix, simple logins can generally be changed using a step that involves modifying a text file. Traditionally, Unix systems have used simple logins of usernames and passwords (or passphrases or passcodes). When dealing only with accounts that will only be using these sort of simple logins, a method that may work on more platforms is to use one of the methods involving a text editor. Be forewarned, though, that many newer systems may allow multiple methods of authentication. This approach may only address one single authentication method while other authentication methods remain enabled.

Using a text editor
[#whyvipw]: Using a safe text editor for this task
Using the vipw command

Despite the name, it is NOT necessary to use vi as the text editor when using the vipw command. The vipw command should be used if going the more manual route of editing a text file.

If the EDITOR environment variable if that is specified, vipw will try to use that. For details on interacting with environment variables such as the EDITOR environment variable, see Environmental variables (operating system, or command processor, variables).

Using vipw serves multiple purposes: one is that vipw provides some protection from having one administrator's changes be lost because another administrator is editing the same file. (The way this happens is this: One administrator reads the file to edit it. A second administrator reads the same file and makes changes and saves the changes. That Administrator may even check the end results of that person's actions, and successfully verify that the desired changes were saved. Then the first administrator saves the changes that were made to the earlier version of the file, overwriting the changes that were made by the second administrator. Whoever saves last gets to keep the changes that were intended. vipw works around this by using lock files so that administrators know that the file is being edited by another administrator.)

A second benefit to using vipw is that vipw may provide ease and speed to the process by running subsequent commands automatically. These subsequent commands may apply the changes to more than just the original text file that gets edited. For example, a database might be automatically modified after updating the text file. Simply using vipw could be fewer steps than a process of trying to do more things manually.

Another benefit to using vipw is the higher amount of portability of the process. As an example, with OpenBSD, not only does vipw end up editing the correct file, which would be /etc/master.passwd for that operating system, but vipw will also take care of subsequent changes that should be performed by running pwd_mkdb. Other operating systems may not use /etc/master.passwd nor pwd_mkdb. However, those other operating systems may use vipw to correctly modify whatever other files need to be modified.

Using chpass or chfn or chsh

These commands may be used to make changes. OpenBSD's manual page for chpass and chfn and chsh states, “chfn and chsh are synonyms for chpass.” (Presumably these commands might be different on some other operating systems.)

For the most part, these programs may be quite similar to using vipw including supporting the EDITOR variable. It also displays information more verbosely, which can be quite a bit nicer. The big potential downside is that it only operates on just one user at a time, which may be slower. However, if there is a desire to only work on just one user, then showing information for only the one user might even be more pleasant, and faster (as there isn't the need to hunt down a specific user).

Changes to make (using vipw)

To disable an account's system password, put a * before the password hash. (* is discussed in OpenBSD's man page about /etc/master.passwd, which says saying “there is nothing special about” that character compared to other characters that won't appear in a password hash. (Another example character is an exclamation point (“!”), which is also a character that generally/always won't appear in hashes using standard hashing schemes.)

Also, check the user's shell, which comes after the ninth colon (“:”). If the user's shell is not the system-wide default for active users, document its value so that it may be used again when restoring the account later (if that is a concern). Regardless of what the shell is, set it to the appropriate path for nologin (e.g. perhaps “/sbin/nologin”... there are probably plenty of other user accounts that have that login)

Note: If disabling the “root” account, a program like pwd_mkdb in OpenBSD (or other programs in some other operating systems) may make a warning, such as: “warning, unknown root shell”. That warning is referring to a situation that is actually just fine, if the situation is intended. The warning comes from the shell not being listed in the /etc/shells file. This may lead some to a temptation of just adding nologin's full path to the /etc/shells file. Do not do that. (ServerFault question about nologin in /etc/shells mentions that /etc/shells is meant to refer to “unrestricted” shells, so a user may perform standard operations like changing a shell, such as by using the chsh command.)

An alternative approach: grep

This may involve needing to use a text editor, which may or may not be a nice experience if the text editor is not easy to use (perhaps just because the text editor is unfamiliar). A different text editor may be specified by modifying the EDITOR value, but still the system may not have more preferred editors installed.

There is another approach, which lacks the benefit of a built-in solution for file locking. (On the plus side, it might be easier for automation/scripting.) A work-around might be available by somehow using grep -v, although one must make sure that the text being removed is not a substring that will affect any other user (which can be checked by not using -v).

Exact details on using this approach may vary a bit between operating systems, so exact steps are not being provided here. However, here are some things to keep in mind. Using this approach would require finding the file that does store the hash (e.g. /etc/master.passwd or (/etc/shadow ???) and then perhaps using pwd_mkdb (e.g. OpenBSD man page for pwd_mkdb). This method is not as good of a habit to get into because it doesn't provide protection from multiple simultaneous people editing the file (like vipw does protect from). So, a better approach may be to learn some basics of using vi, at least enough to be able to insert a character and save the file.

Other types of user accounts

For file sharing, the Samba software may have a local database: see filesystems: CIFS.

Enabling/disabling an account in Windows
Using the command line


net user username /active:no

(MS Q251394: How to Use the Net User Command documents this syntax, saying “The default is yes.”)

(Further research needed regarding domain accounts: perhaps /DOMAIN might be what works well. Run from any workstation or just DC?

Using a graphical interface

For systems using a home version of Microsoft Windows, domain accounts are generally not being used. (One reason for this is a lack of support of this type of version of Windows.) The best, and perhaps only decent, interface in these versions of Windows is the Control Panel applet for network-capable user accounts. This is typically called “Users”, or something similar, in the Control Panel, and may be started via the command line using “ control nusrmgr.cpl ”.

That approach may also work for Microsoft Windows Professional versions, as well as Microsoft Windows Server versions. However, these versions also offer some other options. Most notably, support for Active Directory accounts may mean that the best/proper interface to use for most actively-used accounts is to use “ADU&C”, a.k.a. “Active Directory Users & Computers”, which may be found on the domain controller in the “Administrative Tools” folder which is in the Control Panel and often also on the Start Menu.

Another option for Windows Professional versions, which may seem more straightforward than the Control Panel applet, is to use an MMC console. This may come with some versions of Windows, and may also be able to manage some remote versions of Windows. The easiest way to find this is typically using the Computer Management icon. Note that the MMC interface may not be as readily visible, and may not work (even if it is found as an MMC snap-in) on some versions of Windows.

Cisco IOS

Note: These steps are provided for people who already know the basics of interacting with a router. A technician who doesn't have that experience may wish to start with an introduction to using Cisco IOS. See: Cisco Introduction, Cisco Equipment, Cisco IOS basic usage guide.

No detailed information is here. Simply this reference where the topic is discussed further: disabling a user from the IOS local user database.