|Document revision date: 30 March 2001|
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.
|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.|
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.
|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
For each domain, you can specify every aspect of password policy:
minimum password length (default is 6), minimum and maximum password
age (defaults are 1 day and 90 days, respectively), and password
uniqueness, which prevents a user from changing his or her password to
a password that the user has used recently (the default is not to
enforce password uniqueness). The Advanced Server ADMINISTER commands
allow you to specify password and account policies.
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.
Every user account contains a unique identifier that is not copied to new accounts. This unique identifier is used for granting permissions to resources. If you delete a user account and then add it again, the new account will not have the same access permissions to resources as those granted to the original account.
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:
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.
You can rename the built-in Administrator account, but you cannot delete it. Also, you cannot remove it from the built-in Administrators and Domain Admins groups.
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.
184.108.40.206 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:
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.
You can rename the built-in Guest account, but you cannot delete it.
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.
If you set up your Advanced Server network so that all of the Advanced Server domains in which user accounts are defined are trusted by other domains, network guest logons will rarely occur at servers.
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:
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:
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:
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.
Advanced Server groups do not map in any way to OpenVMS system groups.
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
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.
|privacy and legal statement|