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” might not be intended to insult anybody, but could be viewed as impersonal and rude.)
Groups might not be very directly implemented as properties of a user, and there may be groups other than just groups of user accounts (such as groups of computer accounts in AD).
For tasks involving both groups and users (such as adding a user to a group, but not the task of creating an empty group before any users are added to the group), the tasks may often be doable in one or both of two ways: Modifying a group to remove the user, or modifying a user so that the user's group memberships does not include the group. Functionally these tasks may be identical, but the point is that either approach may work, meaning that options may exist that involve using programs that are focused more on handling groups or by using programs that are focused more on handling settings related to users. Similarly, a graphical environment may have options available in a location by other options related to a group and may have options available in a location by other options related to user accounts.
- [#mkgroup]: Creating groups
- [#unxmkgrp]: Adding a group in Unix
There may be some specific commands for adding a group. Using such commands may help to make sure that the right files get modified. e.g. /etc/gshadow.
As an example, the following will add a group called “sshok” in OpenBSD:
Either follow a generic process for Unix, or perform the following specific steps.
First, verify that the group does not currently exist. Details on that may be found in the section about who is in a group.
Once it is confirmed that is the group does not exist, go ahead and make it. The following command should work in OpenBSD.
- [#whoingrp]: Seeing who is in a group/Listing what user accounts are in a group
Note: With at least some implementations, this information may also be checked on a per-user basis by checking user properties to review information about groups.
- Seeing who is in a group in Unix
This information presents details as found in OpenBSD. (Things (might?) be more complicated if other files, such as /etc/group (as an example), are used.)
The following example searches for a group named “gpname” at the beginning of a line in the relevant file:
to see who is in a group
If the group does not exist,
may simply show no output (including no error messages). If the group does exist, this should show the name of the group (at the start of the line), followed by some colon-separated values. After the third colon is a comma-separated list of users in the group. The comma-separated list may simply be empty.
This should show the group name, and people who are in the group because they are included in this file. There is one other reason why people may be in the group: if the group's GID matches the user account's GID. (“GID” stands for “group ID”, itself short for “group identifier”, and is a number.) In the output of the previous
command, the GID shows after the second colon.
As an example, if the GID to look for is zero, then run:
- Other methods
Different operating systems may have different commands. Commands might commonly start with the words “group”, “user”. e.g.: “
” or “
”. Perhaps running “
” (which could also be done by running “
”) may reveal some relevant commands.
For example, the following works in OpenBSD:
- [#grepmmbr]: Using
- Seeing who is in a group in Microsoft Windows
- Local group, from local machine
This may need further testing/documentation regarding what happens when trying these methods on a domain controller. e.g. Does localgroup work?
- Command line method
e.g.: if an existing local group
called “Administrators” is desired, use:
- Graphical Method
- The graphical method to use may vary based on the flavor of Windows. Versions designed for considered to be in the “Professional” or “Server” editions may have a “Local Groups and Users” (is that name right?) entry in a CompMgmt.msc. Other versions may not have a significant graphical interface for managing groups, although the control panel should have an icon that references “Users” or “User Accounts” and that area may be sufficient to determine if (and change whether) a user is part of the local Administrators group.
- Active Directory
The vendor behind the Microsoft Windows operating systems (Microsoft) also supports groups used by “Active Directory”. Support for Active Directory may vary based on what version of Microsoft Windows is being used. For instance, Microsoft Windows Server 2003 has better support than Microsoft Windows XP Professional while Microsoft Windows XP Home Edition may have minimal/insufficient support to work nearly as nicely with Active Directory resources. (This is intentional.)
This might involve using “
”? (... instead of “
(Further information on working with Active Directory groups is currently not available right here.)
- [#usrlsgrp]: Listing all the groups that have the user as a member. (Listing the groups a user is a member of.)
Here is a rather generic process that will work on many systems:
In that example command line, the intent was for the quotation marks to let the (
Bourne, or compatible) shell to not treat the characters with the quotation marks as special. (The quotation marks are not actually seen by
because the shell is treating them as a special character.) The term “
” refers to the account name of the user account. All that punctuation is literal.
That will list the groups that have the user added. This may not list the user's home group, which the user may also be a part of. To find the user's home group, review the /etc/passwd file for a line that starts with the username. On that line, check out the fourth field (so, the field after the third colon) to determine the GID (“group ID”), which is a number. Then view /etc/group for a line that has that same GID in the third field (which is after the second colon).
- Follow the generic process given for Unix platforms, or
For a user (e.g. “demoacct”, for the demonstration account used here as an example) who should be in the group, run the following:
The carrot represents a new line character. The output will likely list a group that is named after the username. For a superuser, the output will also likely contain the group called “wheel”. Some example output:
groups username wheel
Just ignore the first word “groups ”, and each of the remaining words is a group.
- [#ptusrngp]: Adding a user account to one or more groups
This might be able to be done in the process of Adding a user. Doing so may often be the fastest way to have the user be placed in a group. However, if the user was created without being put into a necessary group, an already-existing user can be added to a group.
Add to appropriate line in group file (or perhaps gshadow?).
In theory, this may be done by editing the /etc/group file. However, for the same sort of reasons why
are good ideas (to make sure that multiple administrators don't edit the same file at the same time and end up having whoever saves last wipe out any changes that were made since that administrator loaded the file), it is probably best to implement this change using a method other than just editing the file directly. Some software commands may perform the trick rather instantly.
For example, a following procedure may do the trick quite nicely:
- [#adtogpob]: Adding a user to a group when in OpenBSD
- Make sure the group exists. (To see whether it exists, see the section about listing members in a group.) (If the group does not exist, see the section about making a group.)
- Find out what groups the user is currently in. This is required, because this process doesn't add a group. This process entirely replaces the list of groups that the user is in. Therefore, to add a group, it is necessary to know what groups the user was in before any changes. Knowing that is required to create a list of all the groups that the user should be in after the change is made.
Add the desired group (e.g. “demogrp”) to the comma-separated list of groups that the user will be in. As an example, if the user “
demoacct” was in groups with the names of and “wheel” and “users” and “
demoacct” (since some operating systems may have group names that are named after each user), and if the goal was to join a group called ”
demogrp”, then the following would be an appropriate command:
The final word, after the space that follows the comma-separated list, is the impacted username. The reason that the username shows up earlier is a coincidence: the reason is because in this example, the user is in a group that happens to have the same name as the username. That may or may not be common practice (by default) for the operating system that is being used. (It is for OpenBSD.)
As a more realistic example, if a user named
boxrulerwas in a group called
boxrulerand a group called wheel, and it was desired to place this user into a group that had permissions to remote in using SSH, the following might be a command to use:
After this is done, check the list of groups again. (Meaning, once again, find out what groups the user is currently in. In multi-administrator environments, making this a commonly-applied practice may prevent problems from the fact that no lock file was used.)
- [#wnadtogp]: Adding users to groups Microsoft Windows
- [#wnlclgpa]: Adding one or more account(s) to the local groups in Microsoft Windows
- “Professional”-grade Operating Systems (Win2K+)
If the machine is going to be joining a domain, go ahead and join the domain. This will require rebooting the machine, and it is probably best to do this sooner rather than later so that the desired permissions scheme, which involves the domain, is used whenever any other files are being created.
Then find the local group called Administrators. One way to do this is to run Compmgmt.msc and find the local groups. That “Computer Management” program may be found from the Administrative Tools which is found in the Control Panel (which might be buried underneath the Settings menu on the Start Menu): the “Computer Management” program may also be accessed via MMC. confirm: Server Management may also work in Win Svr 2008. Various methods on running CompMgmt.msc should be added to the operating system documentation.
- If modifying who is an Administrator
If this machine is part of a domain, then chances are that the domain group called domain-based group named “Domain Admins” should be added to the computer's local group called “Administrators”. (This might already be done, but if it isn't, then that probably should be done.)
Then, there are different views about who else should be listed in the machine's local group called Administrators. In addition to the local user called Administrator and, if applicable, the domain group called “Domain Admins”, some people like to have “Domain Users” listed in the local machine's group. This allows end users to be able to install software, which may be desired in some circumstances (allowing end users to perform tasks without intervention by an organization's IT technical support staff which may be busy, otherwise unavailable (perhaps due to being remote), or have some sort of cost that is preferable to avoid when not completely necessary). Allowing end users to be able to install software without IT staff intervention may be undesirable in other circumstances (with organizations that want to control what end users can do, perhaps in the hopes of helping to limit malware getting installed onto the machine, and perhaps to limit how easily many openings there are to internal attacks).
It may be a good idea to have a local account which is an Administrator of that machine, so that the account can easily be used to join the domain in case the system ever stops being a part of the domain. (Details about adding a local account to the local Administrators group is in the section about “Home” versions of Microsoft Windows.) Unlike a network account which is shared by all machines on a network, this account ideally should have a different password than such an account on other machines, so that if one machine is compromised then the compromised credentials don't enable access to other machines. Also, updating such an account may be more difficult than a network-based account because doing so requires access to the machine being modified, and that may not be easily available for a machine which travels and is frequently not connected to an accessible network. It may be quite useless to have such an account if the account is expired, so be sure to change the password before it expires.
Finally, also see the other commentary about home versions of Microsoft Windows
- “Home” versions of Microsoft Windows
Presumably this is for Win2K+ and newer (not counting WinME). PresumablyThese instructions have not been tested. (The general process may work, but have been untested when the instructions were written.)
Additionally, it is a good idea to have a local account on the machine which is capable of being a local administrator, and documenting the credentials for that account.
One way to do this is to see the command line: Run the following command:
(To list the users of the group, just type the first three lines of that command. To specify a domain account, replace
MyDomainName\MyAcctName. Do not use the
/DOMAINswitch, because its actions are simply not needed in this case. What that switch does, is cause the domain controller to make modifications to the domain groups, even though the “
LOCALGROUP” sub-command was given to the
command. The affected group is a very different group than what is modified if adding a user to a local group. If trying to use a group name that has spaces, then surround the group name with quotation marks. The same might be needed for usernames with spaces. If an incorrect group was specified, see deleting a user from a local group.)
For most non-professional Microsoft Windows operating systems, there might not be a good way to do this in the graphical interface. There is in WinXP: The way I remember it... Boot to safe mode, and from safe mode run MMC, add the “Local Users and Groups” (or “Computer Managemenet”) snap-in, and connect to a remote system using the IPv4 address 127.0.0.1.
- Groups with Windows domains
- [#gkickout] Removing user(s) from a group
If the user is being removed from a group in order to remove superuser access, and if 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.
Perhaps try commands such as
. With OpenBSD,
ends up being similar to
- [#wnlclgpd]: How to remove a user from the local group called “Administrators” when in Windows
It is similar to
the steps of adding an
account to the local Administrators group.
If using the command line, use
- Windows: getting more info
The SID of a group can be seen. This also serves as a way to list all groups in the local machine's database.
This uses WMI.