By default, a user must be authenticated by Windows NT and Tru64 UNIX security policies when they request access to shares. Therefore, users who access shares must have the following:
A domain user account that you create. The ASU server uses this account to authenticate the user to enforce the Windows NT security policy set for the share.
A Tru64 UNIX user account that is automatically created when you create the domain user account. The Tru64 UNIX operating system software uses this account to authenticate the user to enforce the Tru64 UNIX security policy set for the file system or printer that is associated with a share.
A domain user account and Tru64 UNIX user account contain information about the user, including name, password, and other information that a security system uses to authenticate a user.
This chapter describes:
See the ASU
Installation and Administration Guide
for information on creating domain
user accounts and groups.
3.1 Domain User Accounts
A domain user account contains information that defines a user in an Advanced Server domain.
Table 3-1
describes the elements of a domain
user account.
Table 3-1: Domain User Account Elements
Account Element | Description |
User name |
The unique name that the user types when logging on. |
Full name |
The user's full name. |
Description |
Text describing the user or user account. |
Password |
The user's password. See Table 3-2 for setting password options. |
Logon hours |
The hours during which the user can log in to the domain. See Section 3.1.1 for more information about setting Logon Hours. Whether or not users are forced to log off when their logon hours expire is defined by the Forcibly Disconnect Remote Users From Server When Logon Hours Expire option in the domain's account security policy. See Section 2.5.3.1 for more information about setting domain account security policy. |
Logon workstations |
The computer names of workstations from which a user can log in to the domain. By default, the user can log in from any workstation. |
Expiration date |
A future date when the account automatically becomes disabled; it is useful to ensure that accounts for temporary employees or students are not kept active unnecessarily. |
Logon script |
A batch file or executable file that runs automatically when the user logs on. See Section 3.1.2 for more information. |
Home directory |
A directory that is private to the user. See Section 3.1.3 for more information. |
Profile |
The path to a folder containing information that is retained to create the user's desktop environment, such as program groups, network connections, and screen colors. See Section 3.1.4 for more information. |
Account type |
Account type is either global or local. Most accounts you create will be global accounts. |
Table 3-2
describes the options that
you can use to control a user's password.
Table 3-2: Domain User Account Password Options
Option | Description |
User Must Change Password at Next Logon |
Whether or not the user will be forced to change their password the next time they log in to the domain. This option is defined by the Maximum Password Age option in the domain's account security policy. See Section 2.5.3.1 for more information about setting domain account security policy. |
User Cannot Change Password |
Whether or not the user can change their password. This restriction is useful for shared accounts. It does not apply to administrators. |
Password Never Expires |
Whether or not the user's passwords expires.
This is used for accounts that represent services such as the
|
Account Disabled |
Whether or not the account is disabled and cannot be used to log on. Although the account is not removed from the directory database, the user cannot log in to the domain until the account is enabled. |
A domain user account includes a security identifier (SID), a unique
number that identifies the account.
Every account on your network is issued
a unique SID when the account is created.
Internal processes refer to an
account's SID rather than the account's user name.
If you create an account,
delete it, and then create an account with the same name, the new account
will not have the rights or permissions that previously were granted to the
old account because the accounts have different SID numbers.
Renaming a user
account retains the SID.
3.1.1 Specifying Logon Hours
By default, users can connect to the ASU server 24 hours a day, seven days a week; however, you can restrict access.
When a user is connected to a controller and the logon hours are exceeded, the user either will be disconnected from all server connections or will be allowed to remain connected but denied any new connections, depending on if you enabled the Forcibly Disconnect Remote Users From Server When Logon Hours Expire option. See Section 2.5.3.1 for more information on setting this option.
You specify the logon hours for a user by using the following:
The
net user /TIMES:{times | ALL}
command.
For more information on the
net user
command, enter the
following command:
#
net help user /options
| more
The User Manager for Domains and viewing properties for a selected user, then selecting Hours in the User Properties dialog box.
A Logon Hours dialog box is displayed. The Logon Hours dialog box displays a one-week calendar, with logon hours displayed in one-hour increments across seven days. A box represents each hour. For example, the first box in each row represents the hour from midnight through 12:59 A.M., and the last box in each row represents the hour from 11:00 P.M. through 11:59 P.M. The filled boxes indicate when the user is allowed to connect to controllers; the empty boxes indicate when a user is prohibited from connecting.
Note
The logon hours are in the time zone of the PDC, not in the time zone of the workstation or server to which the user is logging on or connecting.
A logon script is an executable or batch file that contains commands that automatically run when a user logs on to a system on which the ASU server is running. Logon scripts are used to automatically configure users' working environments, such as making network connections and starting applications.
The best way to ensure that logon scripts always are available is to
use the
Replicator
service.
The
Replicator
service maintains identical copies of a directory tree on multiple controllers.
When you make a change to a file in the master copy of the tree (located
on the export server), the
Replicator
service automatically
copies the change to the import controllers.
3.1.2.1 Creating a Logon Script
You create logon scripts by using a text editor, then using the
Replicator
service to distribute the logon scripts to domain controllers.
When using the
Replicator
service, the ASU server
searches for logon scripts in the
/usr/net/servers/lanman/shares/asu/repl/import/scripts
directory on import servers and in the
/usr/net/servers/lanman/shares/asu/repl/export/scripts
directory on export servers.
If you do not use the
Replicator
service, you must make sure that the logon scripts are in the same
directory on each controller because any controller can validate the logon
request, then execute the logon script.
See
Section 4.2
for more information on directory replication.
Table 3-3
describes special parameters
that you can use when creating logon scripts.
Table 3-3: Logon Script Parameters
Parameter | Description |
%HOMEDRIVE% | The user's local workstation drive letter connected to the user's home directory |
%HOMEPATH% | The full path of the user's home directory |
%HOMESHARE% | The name of the share containing the user's home directory |
%OS% | The operating system of the user's workstation |
%PROCESSOR_ARCHITECTURE% | The processor type of the user's workstation |
%PROCESSOR_LEVEL% | The processor level of the user's workstation |
%USERDOMAIN% | The domain containing the user's account |
%USERNAME% | The domain user name |
3.1.2.2 Assigning a Logon Script
You assign a logon script to a domain user account by using the following:
The
net user
username
/scriptpath:[pathname]
command.
For more
information on the
net user
command, enter the following
command:
#
net help user /options
| more
The User Manager for Domains and selecting the properties for a user, clicking on the Profile button, and entering the path of the logon script in the Logon Script Name box.
A user's home directory is a directory that is accessible to the user
and contains files and programs for that user.
When a user logs on at a workstation,
a connection is made automatically to that user's home directory; this becomes
that user's default directory for the File Open and Save As dialog boxes,
for the command prompt, and for all applications that do not have a working
directory defined.
By default, when you create a domain user account, the
ASU server creates a home directory for the user in the
/usr/users
directory using the user's Tru64 UNIX account name.
If you do not specify a home directory, the default home directory is
the
\USERS\DEFAULT
directory on the user's local drive.
Because home directories collect user files in one location, they make
it easy for an administrator to back up user files and delete user accounts.
3.1.3.1 Assigning Home Directories
You assign a home directory to a user account by using the following:
The
net user
username
/homedir:pathname
command.
For more
information on the
net user
command, enter the following
command:
#
net help user /options
| more
The User Manager for Domains and selecting the properties for a user, clicking on the Profile button, and entering the path of the home directory in the Home Directory box.
If you specify a home directory on a controller and it does not exist, it is created. If you specify a directory on the user's local system and it does not exist, it is not created.
In the Home Directory box,
%USERNAME%
can be substituted
for the last entry in the path.
The system later substitutes the user name
of the domain user account.
This substitution is useful when multiple domain
user accounts are selected.
For example, you have selected eight domain user
accounts.
In the Home Directory box, you might select Connect, specify a
drive letter of K, select the To box, and type
\\SALES\home\%username%
.
When you choose OK to save the User Environment Profile, the
actual user name will be substituted for each
%USERNAME%
entry.
When a domain user account is copied, the home directory is copied in one of the following two ways:
If the last subdirectory of the home directory path of the user account being copied is the user's name, the new account substitutes the new user's name in the home directory path. For example, if the original domain user account has a user name of PETER and a home directory of \\SETTER\USERS\PETER, a copied (new) domain user account with the user name of EVAN would have a home directory of \\SETTER\USERS\EVAN.
If the last subdirectory of the home directory path of the user account being copied is not the user's name, then the home directory path is copied exactly. For example, if the original domain user account has the user name of PETER and a home directory of \\HOUND\USERS\HOME, then a copied (new) domain user account with the user name of EVAN would have the same home directory of \\HOUND\USERS\HOME.
A user profile defines the work environment settings that are set when a user logs into a domain. These settings include all the user-specific settings of a user's Windows environment, such as which options in Control Panel they can use, screen colors, share connections, mouse settings, shortcuts, window size, and position.
Types of user profiles include the following:
Local user profiles that are created automatically on the computer the first time a user logs on to a computer running the Windows operating system software. Each user's individual user profile is available to that user on successive logons at that computer.
Roaming user profiles that are available on computers running the ASU server and on computers running the Windows operating system software. To enable roaming user profiles, an administrator enters a user profile path into the user account. The first time the user logs off, the local user profile is copied to that location. Thereafter, the copy of the user profile is downloaded each time the user logs on (if it is more current than the local copy). Both the local and server copies are updated each time the user logs off.
Mandatory user profiles that are roaming profiles that are created for the user and cannot be changed by the user. When the user logs off, the local user profile is not saved and a copy of the local user profile is not copied to the server.
User profiles are available on computers running Windows 95; however,
a user profile created on Windows 95 is not available to the user on a computer
running the ASU server or Windows NT, even if the user profile is stored on
these systems.
3.1.4.1 Creating a User Profile
You use the System Policy Editor to create a user profile. The System Policy Editor is a Windows based interface that you can use to view and manage policies that define the environment for specific Windows computers, users, or groups when logged in to a domain.
Using the System Policy Editor you can set the following:
A user-specific policy that applies to each domain user account or group. Most policies are user-specific.
A machine-specific policy that applies to all users on a Windows system and does not change according to user since it does not follow users as they move between different systems.
The System Policy Editor saves settings in a policy (.POL
) file.
When a user logs in, a program called the policy downloader
starts.
The policy downloader is installed on every Windows client.
The policy
downloader looks on the network for the policy file, opens the policy file,
looks for an entry using the local computer name or user name, and merges
the administrator's registry settings as defined in the policy file into the
local registry.
If the downloader does not find an entry with the local computer
name or user name in the policy file, then it looks for the DEFAULT USER or
DEFAULT COMPUTER entry and uses those registry settings for the merge.
If
there are no entries for a specific user or computer and default entries do
not exist, then no merge takes place.
See the ASU
Installation and Administration Guide
for more information about the System
Policy Editor.
3.1.4.2 Assigning Profiles
You assign a profile to a domain user account by using the following:
The
net user
username
/profilepath:[pathname]
command.
For
more information on the
net user
command, enter the following
command:
#
net help user /options
| more
The User Manager for Domains and selecting the properties for a user, clicking on the Profile button, and entering the path of the profile in the User Profile Path box.
3.1.5 Managing the User Rights Policy
A right authorizes a user to perform certain actions on a computer system, such as backing up files and directories, logging on to a computer interactively, or shutting down a system. Rights exist as capabilities for using either domain controllers at the domain level or workstations or member servers at the local level. Rights can be granted to domain user accounts or groups.
A user who logs on to a domain user account or belongs to a group to which the appropriate rights have been granted to perform actions can carry out the actions. When a user does not have appropriate rights to perform an action, an attempt to carry out that action is blocked by the ASU server.
Rights apply to the system as a whole and are different from permissions, which apply to specific objects. A permission is a rule associated with an object (usually a directory, file, or printer), and it regulates which users can have access to the object and in what manner. Most often the creator or owner of the object sets the permissions for the object. However, because all rights are not associated with a specific object and are applied at the domain (domain controllers) or local (workstation or member server) level, they sometimes can override permissions set on an object. For example, a user logged on to a domain account that is a member of the Backup Operators group has the right to perform backup tasks for all servers of the domain. Doing so requires the ability to read all files on those servers, even files on which their owners have set permissions that explicitly deny access to all users, including members of the Backup Operators group. A right, in this case, the right to perform a backup, takes precedence over all file and directory permissions.
Table 3-4
describes user rights.
See
Section 4.1
for more information about permissions.
Table 3-4: User Rights
User Right | Allows |
Access this computer from network | Connecting over the network to a controller. This right cannot be revoked from the Administrator's local group. |
Add workstations to domain | Adding a workstation to the domain, allowing the workstation to recognize the domain's user accounts and global groups and those of trusted domains. |
Back up files and directories | Backing up files and directories and reading of all files. This right supersedes file and directory permissions, and also applies to the Registry. |
Change the system time | Setting the time for the internal clock of a controller. |
Force shutdown from a remote system | This right is not currently implemented. It is reserved for future use. |
Load and unload device drivers | Installing and removing device drivers. |
Log on locally | Logging on locally at the controller. |
Manage auditing and security log | Specifying what types of share access (such as file access) are to be audited. Viewing and clearing the security log. This right does not allow a user to set system auditing. This ability is held only by the Administrators group. |
Restore files and directories | Restoring (writing) files and directories. This right supersedes file and directory permissions, and also applies to the Registry. |
Shut down the system | Shutting down the controller. |
Take ownership of files or other objects | Taking ownership of files, directories, and other objects on a controller. |
You assign rights to a domain user account by using the User Manager for Domains and selecting Policies, then User Rights.
When you assign user rights for a domain, the rights apply to all the
controllers.
When you administer user rights on a workstation or member server,
the rights apply only to the workstation or member server.
3.1.6 Built-in Domain User Accounts
Two built-in user accounts are created automatically when you install the ASU software:
The Administrator account
The Guest account
3.1.6.1 Built-in Administrator User Account
The built-in Administrator account is allowed to perform domain management tasks on a controller, workstation, or member server that belongs to that domain.
When you install the ASU software you are prompted for a password to the built-in Administrator account. This password should be guarded carefully because if the password is forgotten or the person who knows the password becomes unavailable, the built-in Administrator account is unusable. The password can be changed and it does not expire.
The built-in Administrator account can never be deleted or disabled. This feature distinguishes the Administrator account from other members of the Administrators local group.
Following installation of the ASU software, you should create additional administrative accounts with administrative-level capabilities, while reserving the built-in Administrator account for emergency purposes. When administrative users have separate accounts, their actions can be audited on an individual user account basis rather than trying to audit the built-in Administrator account.
See the ASU
Installation and Administration Guide
for information about installing the
ASU software.
See
Chapter 6
for information about auditing.
3.1.6.2 Built-in Guest User Account
The built-in Guest account can be used by a user who needs to log in to the domain, but does not have a domain user account in the domain or in a trusted domain. A user whose account is disabled (but not deleted) also can use the Guest account.
The Guest account is disabled by default, does not require a password, and has no predefined rights or permissions in the domain however, you can set a password and rights and permissions for the Guest account like any other domain user account.
There are two types of guest logons as follows:
A local guest logon. A local guest logon occurs when a user logs on interactively at a computer running Windows software and specifies Guest as the user name in the Logon Information dialog box. Because the Guest account on these computers (but not on domain controllers) has the built-in right to log on locally, the guest user can then work at that computer (subject to the rights and permissions you have granted the Guest account) and use it to access the network.
A network guest logon. A network guest logon occurs when a user makes a network connection to a controller and that controller does not recognize the user's user name, domain name, and password. A network guest logon is approved only if the Guest account of the destination controller is enabled and has no password set. The guest user then has all rights, permissions, and group memberships on the controller that are granted to the Guest account, even though the user did not specify Guest as their user name.
3.1.6.2.1 Enabling the Guest Account
You enable the Guest account on each controller by using the following:
The
net user Guest /active:yes
command.
For more information on the
net user
command, enter the
following command:
#
net help user /options
| more
The User Manager for Domains and selecting the Guest user, then clicking in the box next to Account Disabled to remove the check mark.
By default, the Tru64 UNIX operating system software authenticates a user before they can access a file system or printer that is assocated with a share.
By default, when you create a domain user account, a Tru64 UNIX
user account is automatically created in the local
/etc/passwd
file if an account with the same name does not exist.
The Tru64 UNIX
operating system software uses this account to authenticate the user.
However,
you can configure the Tru64 UNIX operating system software to send authentication
requests to a network information service (NIS), a Windows 2000 Server, or
to a Windows NT Server Version 4.0.
The NIS, Windows 2000 Server, or Windows
NT Server Version 4.0 uses the information in its user account database to
authenticate users on behalf of the Tru64 UNIX operating system software
and sends the results back.
This is useful if you have a user account database
on a NIS, Windows 2000 Server, or on a Windows NT Server Version 4.0 and you
do not want to create a user account database on the Tru64 UNIX system.
See the ASU
Installation and Administration Guide
for more information on configuring
user account authentication.
3.2.1 Associating Domain User Accounts to Tru64 UNIX User Accounts
By default, a domain user account is associated with a Tru64 UNIX
user account.
This association allows your Tru64 UNIX files to be owned
by your Tru64 UNIX system user account and to be accessed by the domain
user account.
Domain user accounts that are not mapped to a specific Tru64 UNIX
user account are mapped by default to the
lmworld
Tru64 UNIX
user account.
The Tru64 UNIX user account name that is assigned to the domain user account will be the same as or similar to the domain user account name. Differences can arise in cases of long, duplicate, or special character user account names. If a domain user account user is associated to a non-existent Tru64 UNIX user account, or if the Tru64 UNIX user account for the user is deleted, the user will not have access to any shares.
You use the
mapuname
command to control the association
of domain user accounts to Tru64 UNIX user accounts.
The default relationship
between domain user accounts and Tru64 UNIX user accounts is controlled
by values assigned to user-related registry value entries in the ASU registry.
See the ASU
Installation and Administration Guide
for more information about the ASU
registry.
3.3 Grouping Domain User Accounts
To ease administration, you can group domain user accounts and administer the group as one unit. Domain user accounts added to a group become members of the group and immediately acquire the rights and permissions granted to the group. Changes made to the group affect each member. Group membership provides an easy way to grant common capabilities to sets of users.
There are the following three types of groups:
Local groups
Global groups
Special groups
A local group contains domain user accounts and global groups from the
local domain and from domains that it trusts.
A local group cannot contain
other local groups.
Table 3-5
describes the built-in
local groups.
Table 3-5: Local Groups
Group | Description |
Administrators |
Members are automatically granted every built-in right and ability to manage the domain and controllers. By default, the Domain Admins global group is a member of the Administrators local group. |
Users |
Members have normal user access to and capabilities for the domain. By default, the Domain Users global group is a member of the Users local group. |
Guests |
Members have no rights on controllers. However, they do have certain rights at their individual workstations. By default, the Domain Guests global group is a member of the Guests local group. |
Account Operators |
Members can create, modify, and delete most domain user accounts and groups, log on to and shut down domain controllers, and add controllers or member servers to a domain. Members cannot administer security policies, modify or delete the Domain Admins global group, the Administrators, Account Operators, Backup Operators, Print Operators, or Server Operators local groups, any global groups belonging to these local groups, or accounts of members of any of these groups. |
Backup Operators |
Members can back up and restore files on a PDC and BDCs. |
Print Operators |
Members can create, delete, and manage printer shares on the domain's controllers and can shut down these controllers. |
Server Operators |
Members can create, delete, and manage shares and change the system time. |
Replicator |
Members can mange the
|
Not all built-in local groups exist on ASU servers, Windows NT servers,
Windows NT workstations, and member servers.
Table 3-6
identifies which built-in local groups exist on ASU servers, Windows NT servers,
Windows NT workstations, and member servers.
Table 3-6: Built-in Local Groups
ASU Servers and Windows NT Servers | Windows NT Workstations and Member Servers |
Administrators | Administrators |
Users | Users |
Guests | Guests |
Account Operators | Backup Operators |
Backup Operators | Replicator |
Print Operators | Power Users |
Server Operators | |
Replicator |
A global group contains domain user accounts from the domain in which it is created. A global group cannot contain local groups, other global groups, or domain user accounts from other domains. You can add a global group to local groups in the same domain, to domains that trust that domain, or to member servers or computers running Windows NT Workstation in the same or a trusting domain. You can grant a global group permissions and rights in its own domain, on workstations or member servers, or in trusting domains. You cannot create a global group on a computer running Windows NT Workstation or on computers running as a member server.
Table 3-7
describes the built-in global groups.
These groups cannot be deleted.
Table 3-7: Global Groups
Group | Description |
Domain Admins |
Members can administer the domain, the controllers and workstations of the domain, and a trusting domain that has added the Domain Admins global group from this domain to the Administrators local group in the trusting domain. Only Administrators can modify the Domain Admins global group. The built-in Administrator user account is a member of the Domain Admins global group. The Domain Admins global group is a member of the Administrators local group. To provide a domain user account with administrative-level capabilities, add the account to the Domain Admins global group. |
Domain Users |
Members have normal user access to and capabilities for the domain and the computers in the domain running Windows NT Workstation and Windows NT Server as a member server. Only Administrators and Account Operators can modify the Domain Users global group. The built-in Administrator user account is a member of the Domain Users global group. By default, all new domain user accounts created in the domain are added to the Domain Users group, unless you specifically remove them. The Domain Users global group is a member of the Users local group for the domain and of the Users local group for every computer in the domain running Windows NT Workstation or member servers running Windows NT Server. |
Domain Guests |
Members have no rights on controllers. The built-in Guest user account is a member of the Domain Guests global group. The Domain Guests global group is a member of the Guests local group. Add user accounts that are intended to have more limited rights and permissions than typical domain user accounts to the Domain Guests group and remove them from the Domain Users group. Only Administrators and Account Operators can modify the Domain Guests global group. |
Table 3-8 describes the other groups that used for special purposes. Because the memberships of these groups cannot be altered, the groups are not listed in User Manager for Domains.
When you administer the ASU server, these special groups sometimes appear
in the list.
For example, they can appear when assigning permissions to shares
and files.
Table 3-8: Special Groups
Group | Description |
Everyone |
Members include all local and remote users (that is, the Interactive and Network groups combined). In a domain, members can access the network and connect to disk and printer shares. |
Interactive |
Members include anyone using the computer locally. |
Network |
Members include users connected over the network to the computer. |
System |
Members include the operating system. |
Creator Owner |
Members include users who create a subdirectory, file, or print job. For a directory, if permissions are granted to the Creator Owner group, the creator of a subdirectory or file will be granted those permissions for that subdirectory or file. For a printer, if permissions are granted to the Creator Owner group, the creator of a print job will be granted those permissions for that print job. |
3.3.4 Strategies for Using Groups
Some rights are only provided to users who are members of a specific group. For example, the only way to allow a person to create domain user accounts is to add that person's domain user account to either the Administrators or Account Operators local group on the domain.
You can add a user to more than one built-in group. For example, a user in both the Print Operators and Backup Operators groups has all the rights granted to Print Operators and all the rights granted to Backup Operators.
In a domain, rights are granted and restricted on the domain level; if a group has a right in a domain, its members have that right on all the controllers in the domain. On member servers, rights granted apply only to that computer.
In a multiple-domain setting, you can think of global groups as a means of adding users to the local groups of trusting domains. To extend users' rights and permissions to resources on other domains, add their accounts to a global group in your domain and then add the global group to a local group in a trusting domain.
Even if you maintain a single domain, keep in mind that additional domains may be added in the future. You can use global groups added to local groups for granting all rights and permissions. Later, if another domain is created, the rights and permissions assigned to your local groups can be extended to a new domain's users by creating a trust relationship and adding global groups from the new domain to your local groups. Likewise, if the new domain trusts your domain, your global groups can be added to the new domain local groups.
Domain global groups also can be used for administrative purpose on computers running Windows NT Workstation or on member servers running Windows NT Server. For example, the Domain Admins global group is added by default to the Administrators built-in local group on each workstation or member server that joins the existing domain. Membership in the workstation or member server local Administrators group enables the network administrator to manage the computer remotely by creating program groups, installing software, and troubleshooting computer problems.
Most network administrators have dual roles. They are both administrators and users of the network. A network is more secure if an administrator uses two domain user accounts. One of these accounts should be in the Domain Admins global group and should be used to perform network management tasks and the other account should be in the Domain Users global group and should be used at all other times. While logged on as a regular user, an administrator cannot inadvertently change aspects of the network that only administrators can change. And, if an administrator were to accidentally introduce a virus, the program would not have the rights of an administrator and would not modify the operating system.
Table 3-9
provides some guidelines for using
global and local groups:
Table 3-9: Group Guidelines
Purpose of Group | Use | Comments |
To group users of a domain into a single unit for use in other domains or user workstations | Global | The global group can be put into local groups or given permissions and rights directly in other domains. |
To group users who need permissions and rights only in one domain | Local | The local group can contain users and global groups from this and other domains. |
To group users who need permissions on computers running Windows NT Workstation or on member servers | Global | A domain's global groups can be given permissions on these computers, but a domain's local groups cannot. |
To contain other groups | Local | The local group can contain global groups and users; however, no group can contain other local groups. |
To group users from multiple domains | Local | The local group can be used in only the domain in which it is created. If you need to be able to grant this local group permissions in multiple domains, you must create the local group in every domain in which you need it. |
A group name must be unique to the domain or to the computer being administered. A global group name can contain up to 20 characters. A local group name can contain up to 256 characters. A group name can contain any uppercase or lowercase alphanumeric characters.
When a group name is displayed and when the distinction is necessary, the ASU server identifies the domain or workstation the group is from by displaying the group name in the form DOMAINNAME\groupname or COMPUTERNAME\groupname. For example, a group named Managers from a domain named Engineering would be displayed as ENGINEERING\Managers.
You can copy a group or create one. By copying, you ensure that the new group has the same members as the original group. However, the permissions and rights of the original group are not copied to the new group.
A group includes a security identifier (SID), a unique number that identifies the group. Every group on your network is issued a unique SID when the account is first created. Internal processes refer to a group SID rather than the group name. If you create a group, delete it, then create a group with the same name, the new group will not have the rights or permissions that previously were granted to the old group because the new group will have a different SID. Renaming a group retains the SID. Groups that you create can be deleted, but the built-in groups cannot. Deleting a group removes only that group; it does not delete the domain user accounts or global groups that are members of the deleted group.