User accounts are divided into two types:

• Global accounts --- A normal user account in a user's home domain.
• Local accounts --- A user account restricted to the local domain.

Most of the user accounts that you create will be global user accounts. If there are multiple domains in the network, it is best if each user in the network has only one user account in only one domain, and each user's access to other domains is accomplished through the establishment of domain trust relationships.

3.5.2 How Local Accounts Work

If your network currently has servers other than the Advanced Server or Windows NT Server, such as a LAN Manager server, Novell NetWare, or IBM LAN server, you can use local user accounts (also called local accounts) to permit users of these systems to access network resources on Advanced Server systems.

A local account can be used only to access server resources over the network. It cannot be used to log on to a Windows NT Server or workstation computer from the console.

Local accounts can be placed in global and local groups; they can be assigned file permissions and rights. However, local accounts created in one domain cannot be used for resource access in domains that trust that domain; the use of each local account is limited to one domain.

You create and use local accounts in a domain as workarounds to existing restrictions:

• To allow users from LAN Manager servers in other domains to access Advanced Server resources
• To allow access to users whose home accounts are in untrusted domains, or domains not running the Advanced Server

By default, Advanced Server user accounts are mapped to OpenVMS accounts. If you use the Advanced Server ADMINISTER commands to create a new Advanced Server user account, you have the following options:

• You can map the new Advanced Server account to an existing OpenVMS account.
• Any Advanced Server account that you do not specifically map to an OpenVMS account maps to PWRK$DEFAULT.

The Advanced Server provides server configuration parameters that control user account mapping. You can set the parameters differently on different servers within a domain, depending on the OpenVMS security required on each server.

Host mapping is unique to each Advanced Server. It is not copied as part of user account database replication.

You can map multiple Advanced Server users to a single OpenVMS system user account. However, an Advanced Server user or group cannot map to more than one OpenVMS user account.

For more information on how to modify server configuration parameters, see your Server Administrator's Guide.

3.7 Password Synchronization

Advanced Server users may have two passwords: one for the Advanced Server account and another for the OpenVMS account. The passwords can be synchronized through the implementation of external authentication on the OpenVMS account.

For more information about Advanced Server passwords and OpenVMS passwords, refer to your Server Administrator's Guide.

3.8 Allowing Users of Other Domains to Access the Advanced Server

As you begin adding Advanced Servers to your network, you may have occasions when some user accounts are on Advanced Server domains and other user accounts are on domains of other servers, such as LAN Manager or IBM LAN servers.

If users with accounts on other systems need access to Advanced Server resources during a migration of your systems to the Advanced Server, you can create local accounts for those users in the domains that contain the resources they need to use. You can place the local accounts in local or global groups in the domain and assign necessary permissions to those groups. (Although you can give permissions directly to local accounts, this is not recommended. These permissions are difficult to maintain if you later upgrade the systems to the Advanced Server and no longer require the use of local accounts.)

If you replace other systems with the Advanced Server after having given users on those systems local accounts, you should delete the local accounts and assign appropriate permissions to the users' new Advanced Server accounts.

Local accounts are different from other user accounts in one important way --- a local account in one domain cannot be used in domains that trust that domain. Therefore, if you want to use local accounts to grant a user from another network operating system access to several Advanced Server domains, you must create a local account for the user on each of those domains.

3.9 Authenticating Logon Requests for Users

This section explains how the Advanced Server authenticates logon attempts from Windows NT Server and workstation computers; Windows, Windows 95, and Windows 98 workstations; and MS-DOS and OS/2 workstations.

3.9.1 Authenticating Requests from Windows NT Computers

When users log on at a Windows NT Server or Windows NT workstation computer, they provide a user name, domain or workstation name, and password. If a user's name and password match an account, the server notifies the workstation to approve the logon. Logon information such as the user's profile, home directory, and environment variables is then used to complete the logon process.

3.9.2 Authenticating Requests from Windows, Windows 95, Windows 98, MS-DOS, and OS/2 Computers

Unlike Windows NT computer users, Windows, Windows 95, Windows 98, MS-DOS, and OS/2 workstation users do not require validation when logging on to the network to gain access to their computers' resources.

This means that Windows, MS-DOS, OS/2, Windows 95, and Windows 98 computers are not secure --- there is no way to prevent an unauthorized user from sending network requests from one of these computers. However, you can prevent that user from accessing network resources by securing the resources themselves. This will prevent an unauthorized user's network requests from having any effect.

3.9.3 Authenticating Requests from LAN Manager Servers

The Advanced Server system of pass-through authentication depends on the principle that trust relationships allow servers in one domain to recognize user accounts from other domains. Even though LAN Manager servers can participate in Advanced Server domains and can recognize user accounts in their own domains, they will not be able to recognize user accounts from trusted domains; this is a limitation of LAN Manager servers.

For example, suppose that the Sales domain trusts the MIS domain. This allows you to assign permissions on the Advanced Server in Sales to users from MIS. However, you cannot assign permissions for resources on LAN Manager servers in Sales to users from MIS.

To solve this problem, you can create local user accounts in the domain containing the LAN Manager servers. You should create a local account for each user from a trusted domain who needs to access those servers. You create a local user account in the same way you create global user accounts except that as you create the user account, you designate it as a local account.

You then can place the local user account in global groups in your domain and assign those global groups the required permissions on LAN Manager servers. (You must use global groups because LAN Manager servers do not recognize local groups.)

Although you can give permissions directly to local user accounts, this is not recommended. They are difficult to maintain if you upgrade your LAN Manager servers to Advanced Servers and no longer require the use of local user accounts.

If you upgrade all of the servers in your domain to Advanced Servers, you can remove all local user accounts from the domain and create Advanced Server user accounts for those users when it is time to remove the local accounts.

3.10 Auditing User Actions

You can monitor the activities of users by auditing their actions and resources on your server. Auditing an action or resource causes an entry to be written to the security event log whenever that activity is performed or a resource is accessed. This helps to ensure that users are accountable for their actions.

Auditing in the Advanced Server is configured on the domain level. Every server in a domain is covered by the domain's audit policy.

You can specify that an audit entry is written to the security event log when certain actions are performed or files are accessed. An audit entry shows the action, the user, and the date and time of the action. Both successful and failed logon attempts can be audited. The audit trail shows who performed which actions on a network, and who tried to perform actions that are not permitted.

Table 3-3 lists the categories of events that you can choose to audit and which events are covered by each category. For each of the categories listed, you can choose whether to audit only successful actions in that category, failed attempts to perform actions in that category, both, or neither.

Table 3-3 Event Audit Categories

Category	Events
Logon and Logoff	Logon attempts, logoff attempts, and the creating and breaking of network connections to servers.
Object Access	Accesses of a directory or a file that is set for auditing in File Manager; uses of a printer managed by the computer.
Privilege Use	Successful uses of user or group rights, and failed attempts to use rights not assigned to users or groups.
Account Management	Creation, deletion, and modification of user and group accounts.
Security Policy Changes	Granting or revoking user rights to users and groups; changing the Audit policy; establishing and breaking trust relationships with other domains.
Restart 1, Shutdown 1, and System	Shutdowns and restarts of the computer, the filling up of the audit log, and the discarding of audit entries if the audit log is already full.
Process Tracking 1	Starts and stops of processes on the computer.

Using ADMINISTER commands, you specify which types of security events are audited; designate which files are audited and how; set the size of the event log files; and save or clear the event logs when they become full.

Table 3-4 shows the types of directory and file accesses you can audit.

Table 3-4 Auditing Directories and Files

Directory access	File access
Displaying names of files in the directory	Displaying the file's data
Displaying directory attributes	Displaying file attributes
Changing directory attributes	Displaying the file's owner and permissions
Creating subdirectories and files	Changing the file
Going to the directory's subdirectories	Changing file attributes
Displaying the directory's owner and permissions	Running the file
Deleting the directory	Deleting the file
Changing directory permissions	Changing the file's permissions
Changing directory ownership	Changing the file's ownership

For more information, see your Server Administrator's Guide.

By organizing users into domains and setting up trust relationships, you can manage and track the actions of users while allowing them access to the resources they need.

In addition, you can arrange users into groups. Using groups makes it easier and faster to grant multiple users access to resources. You perform only one task to grant rights or permissions to a group; those rights and permissions are then active for all current and future group members.

Another advantage to using groups is evident when a new user joins the network. For example, a new accountant is hired and a group called Accountants has permissions to all of the network resources needed by accountants. Adding the new user to the Accountants group gives the new accountant all of the permissions that are needed.

This chapter describes the types of groups and identifies some strategies you can use to make your network simpler to administer and easier to maintain.

4.1 What Is a Group?

A group is an account containing other accounts called members. The permissions granted to a group are also granted to its members. Groups are a convenient means of granting common access and user rights to collections of user accounts.

You can use the ADMINISTER commands to create and manage user and group accounts, to grant permissions for files and directories to users and groups, and to give users and groups access to printers.

On Advanced Servers, rights are granted and restricted on the domain level; if a group has a right within a domain, its members have the right on all servers in the domain (but not on Windows NT workstation computers participating in the domain).

4.2 Types of Groups

You can group users who have similar jobs or resource needs into the following types of groups:

• Global group --- A group that can be used in its own domain, on servers and workstations of the domain, and in trusting domains. In all of these instances, global groups can be granted rights and permissions and can become members of local groups. However, global groups can contain only user accounts from their own domains. A global group provides a way to create a set of users from inside the domain that can be used both in and out of the domain.
• Local group --- A group that can be granted permissions and rights only for the servers of its own domain. However, it can contain user accounts and global groups both from its own domain and from trusted domains. Local groups provide a way to create sets of users from both inside and outside the domain that can be used only on servers of the domain.

Table 4-1 shows the contents of both local and global groups.

Table 4-1 Contents of Local and Global Groups

A global group contains . . .	A local group contains . . .
Name (up to 20 characters)	Name (up to 20 characters)
Description	Description
Members' user names	Members' user names or global group names; names of users and global groups from trusted domains

4.3 Global Groups

Figure 4-1 shows the global group Accounting, which can contain only users from the Finance domain, but which can appear in permissions lists in any domain that trusts Finance. In this example, the Accounting group can be granted permissions in the Sales domain. Likewise, the global group Planners can contain users only from the Sales domain, but the Planners group can appear in permissions lists in the Production domain.

Figure 4-1 Understanding Global Groups

4.4 Local Groups

Local groups also can be used to classify users and give them predefined sets of rights and permissions. For example, to make an account for a print operator in a domain, you would add the account to the Print Operators local group in the domain. The account then would have all the rights and abilities required for a print operator. The use of that group is local to the servers in that domain. A local group can contain users and global groups, but it cannot contain any other local groups.

In Figure 4-2, a local group, Accounting, has been added to the Sales domain. Although Accounting can contain users and global groups from Finance (and any other domains that Sales trusts), Accounting can be assigned permissions and rights only in Sales.

Local groups also exist on Windows NT workstation computers. A local group on a workstation can contain user accounts from the workstation itself, and users and global groups from the workstation's domain and domains trusted by the workstation's domain.

Figure 4-2 Understanding Local Groups

The terms global group and local group indicate the scope of a group, not the contents of the group; they refer to the rights and permissions that a group can be granted. Local groups can contain global groups, but global groups cannot contain either local groups or other global groups. Although global and local groups serve similar functions, different rules apply to their creation and use.

As shown in Figure 4-2, a global group, Accounting, created in the Finance domain can:

• Contain users from the Finance domain
• Be used in any domain that trusts the Finance domain

A local group created in the Sales domain can:

• Contain users and global groups from the Sales domain and any domain that the Sales domain trusts
• Be used on servers in the Sales domain only

This section discusses strategies for using global and local groups that can make your network easier to administer and maintain.

If you organize your domains so that each represents a division or department of your company, you can think of a global group as being a group of users from the same department. This group of users can be assigned permissions and rights in other domains. In this way, the global group becomes a means of exporting a group of users as a single unit to other domains in the company.

When administering an Advanced Server, you may see that a global group name is preceded by the domain name in which the global group is located. You see both the types of users that the group represents (by the group name) and the origin or location of that group (by the domain name). For example, when you view file permissions on a server in the Sales domain, if the Accounting global group in the Finance domain has permissions, they are shown as Finance\Accounting. In this way, you can positively identify a global group when it is referred to in a domain other than its own. (A global group viewed in its own domain has no domain name prefix. For example, when you view file permissions on a server in the Sales domain, global groups located in the Sales domain, such as Planners in Figure 4-2, are shown by their group names only.)

A local group can include users and global groups from other trusted domains. Therefore, it is a way to import users and global groups from other domains into a single unit for use in the local domain.

For example, suppose that a domain called Engineering has a server with a shared directory containing documents that explain the new technologies that the company is investigating. If managers in other departments (domains) are interested in seeing these documents, network administrators can provide this ability by performing the following procedure:

1. Create global groups in the other domains (such as Marketing\Managers and Sales\Managers).
2. In the Engineering domain, create a local group called All Managers.
3. Put the Marketing\Managers and Sales\Managers global groups in the All Managers local group.
4. Grant All Managers permission to read the files in the directory.

In this example, you could give permission to read the files to all the Managers global groups from the other domains and thus bypass the step of creating the local group. However, in many cases, creating the local group saves time later. For example, imagine that later on you add two new directories containing files of interest to managers. If you have not created the All Managers local group, you need to grant access for the new directories separately to all the Managers global groups, instead of to the single local group. If the All Managers local group contains many global groups rather than just the two in this example, creating it could represent a significant savings of effort.

As this example illustrates, a local group is a way of assembling global groups and assigning them permissions in one step. If another global group needs the same permissions as an existing global group, you can add the new global group to the appropriate local group to give it all the permissions it needs.

Table 4-2 summarizes the uses of global and local groups.

Table 4-2 Purposes of Global and Local Groups

Purpose	Use	Comments
Group users of a domain into a single unit for use in other domains	Global group	The global group can be put into local groups, or given permissions and rights directly, in other domains.
Need permissions and rights only in one domain	Local group	The local group can contain users and global groups from other domains.
Need permissions to access resources on Windows NT workstation computers	Global group	A domain's global groups can be given permissions on Windows NT workstation computers, but a domain's local groups cannot.
Contain other groups	Local group	The local group can contain global groups and individual users; no group of any type can contain other local groups.
Include users from multiple domains	Local group	The local group can contain users and global groups. The local group can be used only in the domain in which it is created.