The Advanced Server makes account management easy for administrators and network access easy for users, while ensuring network security. The Advanced Server provides user, built-in user, global, and local accounts so that you can provide appropriate network access for users.

This chapter describes the types of user accounts and how to provide users access to resources they need.

3.1 What is a User Account?

A user account contains information about the user, which includes the name, password, and restrictions on how the user can use the network. Every person who uses the network must have a user account on a domain in the network. A user needs only a single, centrally stored account. This account can provide the user with access to resources anywhere on the network.

Table 3-1 shows the attributes of a user account.

Table 3-1 User Account Attributes

Account Attribute	Comment
User name	The unique name that the user types when logging on. Often a combination of parts of the user's first and last names; for example, EGIBBONS for Evan Gibbons. The user name is unique within the domain.
Account security identifier (SID)	The unique number that identifies the account (hidden). A SID is generated automatically when an account is entered.
Account type	The account type is either global or local. Most accounts you create will be global accounts.
Description	A brief description of the user (optional).
Domain	Name of the domain where the user logs on.
Expiration date	A future date when the account automatically becomes disabled; it is useful for ensuring that accounts for temporary employees or students are not kept active unnecessarily (optional).
Full name	The user's full name, up to 48 characters (optional).
Group names	Names of local and global groups to which the user belongs.
Logon hours	The hours during which the user is allowed to log on. The default is all hours. This attribute determines when the user can log on to the network and access servers. Whether users are forced to log off when their logon hours expire is determined by a setting in the domain's security policy. For more information, see Section 3.2, Setting Password and Account Policies for the Domain, in this guide.
Logon workstations	The computer names of the workstations from which the user can log on to the domain. By default, the user can use any workstation, but you can restrict logon access to particular workstations (optional).
Password	The user's password. Generally not displayed as the user enters it. The Advanced Server and OpenVMS have independent user accounts databases, so OpenVMS users can have two passwords --- one for OpenVMS and one for Advanced Server. (Advanced Server passwords are case sensitive; OpenVMS passwords are not.) See Section 3.7, Password Synchronization, for more information on how to synchronize Advanced Server and OpenVMS account passwords.
User Profile	A file containing the user's home directory and logon script. The home directory is a directory on the server that is private to the user; the user controls access to this directory (optional). The logon script is a batch file or executable file that runs automatically when the user logs on (optional).

For each user account, several conditions are either true or false, as shown in Table 3-2.

Table 3-2 User Account Conditions

Account Condition	Default	Comments
Change Password at Next Logon?	Yes	If yes, users are forced to change the password the next time they log on. Then, after a user changes the password, this value is set to No.
User Cannot Change Password	No	If yes, users cannot change their own passwords. This is useful for shared accounts.
Password Never Expires	No	If yes, this user account ignores the password expiration policy set for the domain, and the password never expires. This is used for accounts that represent services, such as the Event Logger service. It is also useful for accounts for which you want the password never to change.
Account Disabled	No	If yes, this account is disabled and cannot be logged on to. It is not removed from the database, but no one can log on to the account until you again enable it. This is useful for "template accounts." See Section 3.3, Creating User Accounts, in this guide for more information.

3.2 Setting Password and Account Policies for the Domain

You also can specify whether users are forced to disconnect from the domain's servers when their logon hours expire. If users have not ended their connections by the time their logon hours expire, the servers they are connected to will end the connections. Users are not forced to log off their workstations.

For more information on how to set password and account policies, see your Server Administrator's Guide.

3.3 Creating User Accounts

Because user accounts contain so much information, it can be time consuming to add individual user accounts manually. To simplify the process, you can create and then disable template accounts that include all of the information needed for typical users. Disabled template accounts cannot be used for logging on, but you can copy the information in them to new user accounts and add individual account information such as user name and password. When you enable new accounts created with a template, all of the account information carries over to the new users with the exception of passwords and permissions.

For more information on copying existing accounts, see the COPY USER entry in the Compaq Advanced Server for OpenVMS Commands Reference Manual or the ADMINISTER commands online help.

A built-in user account is a user account automatically provided when an Advanced Server domain is created. When an Advanced Server is installed as a primary domain controller, you have two built-in user accounts:

• Administrator --- The account used by the person who manages the overall configuration of the domain.
• Guest --- An account provided so that the occasional or one-time user can log on to the system and be granted limited capabilities. By default, this account is disabled.

You can create additional user accounts for other users who log on, and you can modify existing accounts.

The remainder of this section further explains the Administrator and Guest built-in user accounts.

3.4.1 Administrator Account

The built-in Administrator account is a member of the Administrators, Domain Admins, and Domain Users built-in groups, and is granted the rights and permissions of those groups.

The Administrator account is the account used by the person who manages the overall configuration of the domain: the network administrator. The network administrator has more control over the domain and its workstations than does any other user. The network administrator can manage security policy, establish trust relationships, create, modify, or delete user accounts and groups, create and connect to shared directories (including administrative shares), share printers, take ownership of files and other objects, and shut down servers.

The Administrator account is a member of the Domain Admins global group, and the Domain Admins global group is by default a member of the Administrators local group of the domain. Therefore, a user logged on to the Administrator account is able to administer both the local domain and the Windows NT workstation computers in the local domain.

During the configuration of the primary domain controller of a new domain, the person doing the configuration is prompted to enter a password for the built-in Administrator account. This password should be guarded not only for security reasons, but also because if the password is forgotten or the person who knows the password is unavailable, the built-in Administrator account becomes unusable.

Following installation, it is strongly recommended that you create an additional administrative account for every person who needs administrative-level abilities and to reserve the built-in Administrator account for emergency purposes. When all administrative users have separate accounts, their actions can be audited.

3.4.1.1 Logging On as System Administrator

Most of the system administrators on your network have dual roles: they are both administrators and users. Although they perform network administration tasks, they also perform tasks as network users.

For this reason, every system administrator should maintain the following two accounts:

• An account in the Administrators group used to perform network tasks
• An account in the Users group used when not performing network management tasks

Your network will be more secure if your system administrator uses these two accounts. While a system administrator is logged on as a regular user, he or she will be unable to change aspects of the network that only system administrators can change. However, using this method will result in some inconvenience for system administrators, because they will have to log off and then log on again before they can administer the network. For more information on these two groups, see Section 4.7.1, Built-In Local Groups.

3.4.2 Guest Account

The built-in Guest account is a member of the Domain Guests built-in group and receives the rights and permissions granted to that group. The Guest account allows the occasional or one-time user to log on to the system with limited capabilities. When a user without an account on a domain attempts to use server resources, access is granted to the user based on the guest access permissions.

When you initially install the Advanced Server, the Guest account is disabled by default. You must explicitly enable the Guest account if you want to provide access to domain resources for users who do not have accounts on the domain.

The Guest account is installed with a blank password. If the password is left blank, users from untrusted domains (without accounts in this domain) can connect to this domain remotely using the Guest account.

The Guest account does not have a password and can be used to support network guest logons.

A network guest logon occurs when a user tries to access a computer over the network but does not have an account in the computer's domain or in a domain that the computer trusts. Because the account does not exist in the computer's domain, or in any domain that it trusts, the computer does not recognize the user who is trying to access it. In this case, the computer approves the access as a guest logon, as long as the Guest account of the target computer is enabled and has no password.

The guest user then has all of the rights, permissions, and group memberships on the computer that are granted to the Guest account, even though the guest user did not specify Guest as his or her user name.

A network guest logon can occur only when a user with no account on the domain or on a trusted domain tries to access the computer, and the guest account is enabled. By default, the guest account is disabled. To enable the guest account, the administrator must modify the guest disuser flag, using the MODIFY USER command. See the Compaq Advanced Server for OpenVMS Commands Reference Manual for information on how to enable the guest account.

3.5 Types of User Accounts

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, allowing Advanced Server resources to be accessed by:

• Users from LAN Manager servers in other domains
• 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, and which does not already have a matching 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 2000 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 and Windows 2000 Computers

When users log on at a Windows NT Server or workstation computer, or at a Windows 2000 Server or 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 and Windows 2000 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.