HP OpenVMS Systems
HP Advanced Server for OpenVMS
In addition to one primary domain controller and one or more backup domain controllers, the domain can contain one or more member servers. Advanced Server, Windows NT Server, and LAN Manager V2.x servers can function as member servers. (Support of member server functionality begins with V7.3 of the Advanced Server for OpenVMS.)
A domain can have several member servers, or none. A member server differs from a domain controller in the following ways:
Member servers rely on domain controllers to validate credentials of users requesting access to member server shares. When a domain user attempts to access data on a member server's shares, the user's workstation sends user name and password information to the member server. The member server then relays this information to a domain controller to authenticate the user. The domain controller can authenticate domain user requests to member server resources.
PATHWORKS for OpenVMS (LAN Manager) and LAN Manager V2.x servers can coexist in a domain with the Advanced Server. A LAN Manager server cannot be the primary domain controller in such a domain, however, because LAN Manager V2.x does not support all the types of information contained in Advanced Server accounts.
Under some circumstances, you may need to maintain LAN Manager servers. For example, you may need to have a PATHWORKS V5 for OpenVMS server to provide Remote Boot Services, which are not supported by Advanced Server. You can incorporate LAN Manager servers into your network as backup domain controllers, member servers, or standalone servers in an Advanced Server domain.
If it is a backup domain controller or member server, a LAN Manager server stores a copy of the domain's security database. A LAN Manager server running as a backup domain controller can validate logon attempts from computers running Windows for Workgroups or LAN Manager software. A LAN Manager standalone server does not receive a copy of the domain accounts database, and neither standalone nor member servers can validate client domain logon requests.
Do not rely solely on LAN Manager servers as your backup domain controllers in an Advanced Server domain. LAN Manager servers cannot authenticate logon requests from Windows NT workstation computers, and they cannot be promoted to primary domain controller in an Advanced Server domain.
For more information about the differences between Windows NT Server
and the Advanced Server, see Appendix A, Differences Between Advanced Server and Windows NT Server, in this guide.
2.5.6 Advanced Server for UNIX (Tru64 UNIX) Servers
An Advanced Server for UNIX (Tru64 UNIX) server can be part of the same domain as an Advanced Server for OpenVMS server and can be designated as the primary domain controller. For Advanced Server for UNIX (Tru64 UNIX) servers, you have the following options:
For more information about the Advanced Server for UNIX (Tru64 UNIX) product, see the
Advanced Server for UNIX (Tru64 UNIX) documentation set.
2.6 Workstation Environments
On an Advanced Server network, you can use user profiles to define and enhance workstation environments. A user profile contains the per-user settings of the Windows NT environment, including the following:
You manage user environments by editing the user profile. However, user
profiles are applicable only at Windows NT workstation computers and
have no effect on other types of client workstations.
2.6.1 Tips for Using Logon Scripts
A logon script is an executable or batch file composed of Advanced Server and operating system commands that runs automatically when a user logs on to the network. Logon scripts are used to configure users' work environments, make network connections, and start applications. They also can be used to run programs that scan for computer viruses on local workstations.
Advantages to using logon scripts include:
To assign a user a logon script, specify the path name of the logon script file in the user's account profile. Then, when the user logs on, the logon script downloads and runs. You can assign a different logon script to each user or create logon scripts for use by multiple users. For more information on user profiles, see Chapter 3, User Accounts.
The path name that you specify in the user's account profile is relative to the logon script path of the computer on which the script is stored. For example, if PWRK$LMROOT:[LANMAN.REPL.IMPORT.SCRIPTS] is the computer logon script path and PWRK$LMROOT:[LANMAN.REPL.IMPORT.SCRIPTS]cristalw.bat is the script for CristalW, then you need to specify only cristalw.bat as the logon script path name in CristalW's account profile.
To create a logon script, simply create an MS-DOS batch file. Table 2-1 describes several special parameters that you can use when creating logon scripts. Although a logon script works from any client, these parameters apply only when the user logs on from a Windows NT client.
|%HOMEDRIVE%||The letter for the local workstation drive connected to the user's home directory.|
|%HOMEPATH%||The full path name of the user's home directory. This parameter applies only when the home directory is a local directory (absolute path) on the workstation.|
|%HOMESHARE%||The share name containing the user's home directory. This parameter applies only when the home directory is a shared network directory (UNC path).|
|%OS%||The operating system of the user's workstation.|
|%PROCESSOR_ARCHITECTURE%||The processor type (such as 80386) of the user's workstation.|
|%PROCESSOR_IDENTIFIER%||The processor model (such as Model 3, Intel) of the user's workstation.|
|%PROCESSOR_LEVEL%||The processor level (such as 6) of the user's workstation.|
|%PROCESSOR_REVISION%||The processor revision (such as 0304) of the user's workstation.|
|%USERDOMAIN%||The name of the domain containing the user's account.|
|%USERNAME%||The user's user name.|
A logon script always downloads from the server that validates the
user's logon request. To ensure that logon scripts always work, be sure
that logon scripts for all user accounts in a domain exist on every
server in the domain that validates logon requests.
2.6.2 Tips for Using Home Directories
The home directory can be a local path on the server or a remote path located on another server on the network. If users have home directories on computers other than their own workstations, connections are made automatically to their home directories at every logon from a Windows NT workstation computer.
Whenever a user starts from the command prompt on a Windows NT workstation computer, the user's home directory is set as the default directory. The user's home directory also is set as the working directory for all applications that the user starts, except when those applications have a program item that specifies a different working directory. Note that the home directory takes effect only for users starting from a Windows NT workstation. When a user logs on from a non-Windows NT client, the usual default directory takes effect.
For information on file and directory permissions, see Chapter 6, Managing Network Shares,
in this guide.
2.6.3 Windows NT, Windows 2000 and Windows XP Workstation Computers
A Windows NT, Windows 2000, and Windows XP workstation computer participating in a workgroup has its own database of users, processes logon requests by itself, uses only its own users and groups, and is separate from all domains. Computers in a workgroup do not share account information. On this type of workstation, only the user accounts that were created at the workstation can be logged on to or given rights and permissions at the workstation.
Users can log on to an Advanced Server domain from a Windows NT, Windows 2000 or Windows XP workstation only if that workstation is part of the domain or of a trusted domain. A Windows NT, Windows 2000 or Windows XP workstation computer that participates in a domain does not get a copy of the domain's user database, but it does receive the benefits of the domain's user and group database. It can use user accounts and global groups from that domain, and the domains it trusts, to provide access to resources on the workstation.
At a Windows NT, Windows 2000 or Windows XP workstation computer participating in a domain, users can log on to user accounts located in the workstation domain (or in any domain the workstation domain trusts). For example, suppose a workstation is participating in the Sales domain, and Sales trusts the MIS domain. At the workstation, a user can log on to an account located in either the Sales domain or the MIS domain. You can place users and global groups from the domain (and domains trusted by the workstation domain) in local groups on the workstation, and you can assign permissions and rights on the workstation to users and global groups from the domain (and domains trusted by the workstation domain).
Even though a workstation participating in a domain can use accounts located in that domain, user accounts still can be created at the workstation itself. These accounts are local to that workstation and cannot be used on any other computer.
You should not create a local workstation account for a user who has a domain account. Instead, a user with a domain account always should log on to that account.
Even if a Windows NT, Windows 2000 or Windows XP workstation computer participates in a domain, it cannot use local groups defined in the domain; however, it can use users and global groups defined in the domain. See Chapter 4, Groups, in this guide for more information about using groups.
Windows for Workgroups computers generally are organized into workgroups. Workgroups are similar to domains in network browsing: When a user uses File Manager to browse the network, the user sees the network divided into domains and workgroups. If the user selects a domain or workgroup, then the user can browse the contents of that domain or workgroup.
Every Windows for Workgroups computer on your network can participate in a domain or in a workgroup. In most cases, you will want Windows for Workgroups computers to participate in a domain so that they can be integrated into the Advanced Server administrative models.
Windows for Workgroups computers can participate in workgroups containing Windows NT workstations. Similarly, on a Windows for Workgroups computer, you can specify the name of an Advanced Server domain as the computer's workgroup and the Windows for Workgroups computer can then function as a computer contained in the domain.
If a Windows for Workgroups user must access a resource in a domain that has no Windows for Workgroups computers, the user must know the name of the computer on which the resource is located. Whenever a Windows for Workgroups computer starts, the user can log on to the network using a user name and password previously specified at the computer. Alternatively, the user can wait to log on to the network until making an initial network access attempt.
If a Windows for Workgroups user has an account in an Advanced Server
domain, you can specify the user name and password of that account to
Windows for Workgroups and set the workgroup name on the computer to be
the name of the domain. Then, users can log on to their domain accounts
automatically when they log on to the network.
2.6.5 Windows 95 and Windows 98 Computers
You can choose whether you want the Windows 95 and Windows 98 computers on your network to participate in a workgroup or in a domain. In most cases, you will want them to participate in a domain, because a user with an account on an Advanced Server domain can log on to that account from a Windows 95 or Windows 98 computer only if that computer is part of the domain.
Windows 95 and Windows 98 computers that participate in a domain do not get a copy of the domain's user database, but they do receive the benefits of the domain's user and group databases.
You can configure a Windows 95 or Windows 98 computer to prevent users from logging on to the local workstation after an unsuccessful attempt to log on to the domain. This prevents users from gaining access to resources local to the Windows 95 or Windows 98 workstation if, for example, their domain user accounts have expired or have been disabled.
A Windows 95 or Windows 98 computer that participates in a workgroup has its own database of users and can process logon requests. However, computers in a workgroup do not share account information. This means that you can assign rights and enable users to log on only to accounts that are created on the Windows 95 or Windows 98 computer.
Windows 95 and Windows 98 computers that participate in a workgroup can
control access to resources by running share-level security. Under
share-level security, each shared resource on a local workstation is
protected by a unique password. Users from remote computers can access
the resource only if they enter the correct password.
2.6.6 Windows, MS-DOS, and OS/2 Computers
Windows V3.x, MS-DOS, and OS/2 computers cannot store user accounts. This makes them unable to participate in domains in the same way as Windows NT, Windows 95, Windows 98, Windows 2000, or Windows for Workgroups computers. However, with valid network logon, they can access resources on servers.
Windows, MS-DOS, and OS/2 computers usually have a default domain set for network viewing. If a user has a domain account, the domain into which the user logs on is always viewed. You can add other domains to the viewing list.