Compaq Advanced Server for OpenVMS
Server Administrator's Guide

Chapter 2
Managing Domains and Servers

This chapter describes the way Advanced Server participates in a domain and provides the concepts and procedures you use to manage servers and domains from Advanced Server.

Section 2.1, Managing a Domain, describes the way Advanced Server participates in domains and describes the procedures for administering domain operations from an Advanced Server.
Section 2.2, Managing Security Policies, describes how to manage the account policy and the audit policy.
Section 2.3, Managing a Server, describes the Advanced Server and how to administer server-specific operations.
Section 2.4,Advanced Server in OpenVMS Clusters, describes the way an OpenVMS Cluster acts as an Advanced Server.

2.1 Managing a Domain

A domain is a set of computers that share a common security accounts database (also referred to as the Security Account Manager (SAM) database) and security policy. The security accounts database contains security information such as user accounts and passwords, and groups, and the settings of the security policies. When you manage a domain and its services, you control its system entities and resources, and you can display information about its resources, such as its computers, connections, users and user sessions, shares, and services.

The Advanced Server may participate in any of the following three kinds of domains:

Windows NT domains, which consist of primary domain controllers (PDCs), backup domain controllers (BDCs), and member servers; Advanced Servers can participate in any of these three roles. A Windows NT domain must include at least one PDC. The PDC maintains the domain-wide security accounts database. Copies are kept on each BDC. Changes made to the PDC are replicated to the BDCs in the domain.
Windows 2000 mixed-mode domains, which include both Windows 2000 domain controllers and Windows NT or Compaq Advanced Server domain controllers; Advanced Servers can participate as BDCs and member servers. A Windows 2000 mixed-mode domain must include at least one Windows 2000 domain controller.
Windows 2000 native-mode domains (also referred to as a pure Windows 2000 domains), in which all domain controllers are Windows 2000 systems; Advanced Servers can participate as member servers only. A Windows 2000 native-mode domain must include at least one domain controller.
The domain controllers participate in a multi-master domain controller model, meaning that changes to the SAM database can be made on any domain controller. Any domain controller can be the replicator, sending copies of the updated SAM database to the other domain controllers.
This model contrasts to the PDC/BDC model used by Windows NT Servers and Advanced Server for OpenVMS servers configured as PDCs and BDCs. In the PDC/BDC model, changes to the SAM database are made on the PDC first, which then replicates the database changes to the BDCs.

Section 2.1.1, Server Roles in the Domain, describes the roles that the Advanced Server can take in a domain.

2.1.1 Server Roles in the Domain

The Advanced Server can have one of three roles in a domain:

Primary domain controller (PDC)
Each domain running logon validation must have one server that functions as the primary domain controller. This server has the domain's master copy of the security accounts database. The PDC can validate logon requests in the domain. You can change the security accounts database from any computer in the domain, and the change is made to the security accounts database on the PDC.
When you configure the server software into a new domain, the server establishes the domain's security accounts database (SAM database) and becomes the PDC. The default domain name is LANGROUP. You can specify a name that reflects your company or group.
Backup domain controller (BDC)
In addition to the primary domain controller, the domain can have backup domain controllers (BDCs). A BDC keeps a copy of the domain's master security accounts database. The copy of the security accounts database stored on BDCs is synchronized with the PDC's database, as explained in Section 2.1.2.1, Synchronizing SAM Databases on Domain Controllers. Like the PDC, a BDC can validate logon requests. This improves performance and reliability because the load of logon validation can be spread among several servers. Furthermore, logon validation in the domain can continue even if the PDC is unavailable. A BDC can be promoted to PDC.
When you configure the server software and specify an existing domain name, you can have the server join the existing domain as a BDC. The domain must include one active PDC. Note that as a BDC, the Advanced Server can participate in Windows 2000 mixed-mode domains. To participate in a native-mode Windows 2000 domain, the Advanced Server must be configured as a member server, as described below.
Member server
A member server is a server that is a member of a domain but does not store a copy of the domain's security accounts database and does not validate logon requests. Member servers rely on domain controllers to validate credentials of users requesting access to member server shares. Member servers maintain their own local security accounts database. For more information on managing a member server's local database, see Section 2.1.5, Member Servers and Domain Management.
Configuring the Advanced Server as a member server allows it to participate in a native-mode Windows 2000 domain without interruption to the Windows 2000 domain. A native-mode Windows 2000 domain must include at least one domain controller. Windows NT member servers can also participate along with Advanced Server member servers in native-mode Windows 2000 environments.

When you configure the Advanced Server for the first time, you select the role your server will perform in the domain. There may be times when you need to change the role of your server. The method you use to change the server depends on the current role of the server and the role you want to change it to. For more information on changing a server's role, see Section 2.1.1.1, Changing a Server's Role in a Domain.

In an OpenVMS Cluster, all nodes on the cluster running the Advanced Server must have the same role.

2.1.1.1 Changing a Server's Role in a Domain

The first server to be configured in a domain is always the primary domain controller (PDC). The PDC role is established during initial installation and configuration of the server. When you install a new server into an existing domain, you can configure it as a backup domain controller (BDC) or member server. You can change the role of the server from a BDC to a PDC, or vice versa, using the ADMINISTER SET COMPUTER/ROLE command. To change the role of a BDC to a member server, or vice versa, you must use PWRK$CONFIG. To change a PDC to a member server, you must first promote a BDC to a PDC in that domain. The original PDC is automatically demoted to a BDC, and then you can use PWRK$CONFIG to reconfigure it as a member server. Likewise, to change a member server to a PDC, you must first change the member server to a BDC (using PWRK$CONFIG), and then change the BDC to a PDC.

Table 2-1, Role Changes, lists possible role changes you can make and indicates the tools you can use to make the changes: PWRK$CONFIG and/or the ADMINISTER SET COMPUTER/ROLE command. Section 2.1.1.1.1, Changing the Role of a BDC to a PDC, or Vice Versa, explains in detail how to change the role of a BDC to a PCD, or vice versa. Section 2.1.1.1.2, Changing a BDC to a Member Server, or Vice Versa, explains how to change a BDC to a member server, or vice versa.

Table 2-1 Role Changes
To Change: Use: Notes:

BDC to PDC ADMINISTER Promoting the BDC automatically demotes the current PDC of the domain to a BDC.

BDC to Member PWRK$CONFIG

Member to PDC PWRK$CONFIG, then ADMINISTER First, use PWRK$CONFIG to change the member server to a BDC, and then use ADMINISTER to promote the BDC to a PDC.

Member to BDC PWRK$CONFIG

PDC to BDC ADMINISTER Use the ADMINISTER command to promote a BDC to PDC; this demotes the PDC to a BDC.

PDC to Member ADMINISTER, then PWRK$CONFIG First, use ADMINISTER to promote a BDC in the domain to a PDC. This demotes the original PDC to a BDC. Then, use PWRK$CONFIG to change the BDC to a member server.

**Table 2-1 Role Changes**
To Change:	Use:	Notes:
BDC to PDC	ADMINISTER	Promoting the BDC automatically demotes the current PDC of the domain to a BDC.
BDC to Member	PWRK$CONFIG
Member to PDC	PWRK$CONFIG, then ADMINISTER	First, use PWRK$CONFIG to change the member server to a BDC, and then use ADMINISTER to promote the BDC to a PDC.
Member to BDC	PWRK$CONFIG
PDC to BDC	ADMINISTER	Use the ADMINISTER command to promote a BDC to PDC; this demotes the PDC to a BDC.
PDC to Member	ADMINISTER, then PWRK$CONFIG	First, use ADMINISTER to promote a BDC in the domain to a PDC. This demotes the original PDC to a BDC. Then, use PWRK$CONFIG to change the BDC to a member server.

When you change the server role on one member of an OpenVMS Cluster, the role on all cluster members running the Advanced Server is also changed accordingly. For information about running the Advanced Server in a cluster environment, see Section 2.4,Advanced Server in OpenVMS Clusters.

2.1.1.1.1 Changing the Role of a BDC to a PDC, or Vice Versa

You change the role of the PDC by promoting a BDC. For example, if the PDC needs to be taken off line for maintenance, you can promote a BDC to be the PDC. When you promote a BDC, the role of the original PDC is automatically changed to BDC, at which point you can take it off line. In this case, when the original PDC comes back on line, it has the role of BDC. You can then promote it to PDC, if necessary.

If the PDC fails unexpectedly, the domain continues to provide logon validation as long as the NetLogon service is running on a BDC. However, to make changes to the security accounts database, a PDC is required. Therefore, if you think the PDC will be unavailable for more than a short time, you should promote a BDC. When the original PDC comes back on line after an unscheduled interruption, it continues to assume the role of PDC. If the PDC is restarted and you have promoted a BDC in its absence, the NetLogon service is not started on the server, and the following Alert message is generated and recorded in the system event log:

A primary domain controller is running in the domain

In this case, you must explicitly change the server's role to BDC using the SET COMPUTER/ROLE command. It may take a few minutes to complete a server role change in a domain.

While server roles are changing, you cannot make changes to the security accounts database; logon validation remains available during the role change if there is another BDC running the NetLogon service. See Section 2.3.4, Managing Services, for more information about the NetLogon service.

To change the server role in a domain from BDC to PDC, or vice versa, follow these steps:

Log on as the domain administrator.
Use the SHOW COMPUTERS command to check the server's current role.
Use the SET COMPUTER/ROLE command to change a server's role.
Use the SHOW COMPUTERS command to verify the new server role.

For example:

$ ADMINISTER LANDOFOZ\\TINMAN> LOGON ADMINISTRATOR Password: The server \\TINMAN successfully logged you on as Administrator. Your privilege level on domain LANDOFOZ is ADMIN. The last time you logged on was 8/11/00 2:57 PM. LANDOFOZ\\TINMAN> SHOW COMPUTERS Computers in domain "LANDOFOZ": Computer Type Description ------------ ------------------------ ---------------------------- [PD] TINMAN OpenVMS (NT 4.0) Primary Advanced Server V7.3 for OpenVMS [BD] WOODMAN OpenVMS (NT 3.51) Backup Advanced Server V7.2 for OpenVMS [SV] LIONHEART OpenVMS (NT 4.0) Server Advanced Server V7.3 for OpenVMS Total of 3 computers LANDOFOZ\\TINMAN> SET COMPUTER WOODMAN/ROLE=PRIMARY_DOMAIN_CONTROLLER Promoting "WOODMAN" to a Primary Domain Controller may take a few minutes. Do you want to continue with the promotion [YES or NO] (YES) : YES %PWRK-I-ROLESYNC, synchronizing "WOODMAN" with its primary %PWRK-I-ROLENLSTOP, stopping the Net Logon service on "WOODMAN" %PWRK-I-ROLENLSTOP, stopping the Net Logon service on "TINMAN" %PWRK-I-ROLECHANGE, changing "TINMAN"'s role to Backup Domain Controller %PWRK-I-ROLECHANGE, changing "WOODMAN"'s role to Primary Domain Controller %PWRK-I-ROLENLSTART, starting the Net Logon service on "WOODMAN" %PWRK-I-ROLENLSTART, starting the Net Logon service on "TINMAN" %PWRK-I-ROLECHANGED, the computers role was successfully changed LANDOFOZ\\TINMAN> SHOW COMPUTERS Computers in domain "LANDOFOZ": Computer Type Description ------------ ------------------------- ------------------------- [BD] TINMAN OpenVMS (NT 4.0) Backup Advanced Server V7.3 for OpenVMS [PD] WOODMAN OpenVMS (NT 3.51) Primary Advanced Server V7.2 for OpenVMS [SV] LIONHEART OpenVMS (NT 4.0) Server Advanced Server V7.3 for OpenVMS Total of 3 computers LANDOFOZ\\TINMAN>

Note that a member server (in this example, LIONHEART) is represented with the display symbol [SV], and the server type is Server.

2.1.1.1.2 Changing a BDC to a Member Server, or Vice Versa

To change the role of a BDC to a member server, you must use the PWRK$CONFIG procedure. You cannot use the SET COMPUTER/ROLE command. The same is true of changing the role of a member server to a BDC. These restrictions are similar (but less restrictive) to those of Windows NT, which requires the operating system software to be reinstalled to change a domain controller to a member server, or vice versa. For a list of advantages gained by configuring your server as a member server, and for details on configuring a server as a member server, refer to the Compaq Advanced Server for OpenVMS Server Installation and Configuration Guide.

Caution

If you reconfigure a backup domain controller as a member server, PWRK$CONFIG automatically removes the domain controller's domain user account database. If you reconfigure a member server to a BDC, PWRK$CONFIG automatically removes the member server's local user account database. The removed database is stored in the PWRK$LMDOMAINS: and PWRK$LMDATAFILES: directories in case you decide to restore them later. For more information, refer to the Compaq Advanced Server for OpenVMS Server Installation and Configuration Guide.

In either case, because of loss of local group information, access to some resources might be affected. If resource permissions have been set using local groups, those permissions will have to be reset. If resource permissions have been set using global groups or global user accounts, those permissions will remain in effect after the role change.

2.1.2 Domain Controllers and the SAM Database

The NetLogon service ensures that each BDC's copy of the domain-wide security accounts (SAM) database is identical to the master copy kept on the PDC. At regular intervals, any changes made to the master copy of the security accounts database on the PDC are replicated to all BDCs, as described in Section 2.1.2.1, Synchronizing SAM Databases on Domain Controllers. However, the Advanced Server does not replicate user files and directories.

If the PDC fails or is stopped, you cannot make changes that affect the domain's security accounts database, but logon validation continues as long as one or more BDCs are running the NetLogon service. Because PDCs and BDCs keep their own copies of the database, and because the PDC and all BDCs can validate logon requests, there is no single point of failure in the domain. However, if the PDC is unavailable for an extended period, you should promote a BDC to assume the PDC role, so that changes can be made to user accounts.

Each domain in a network is identified internally by a security identifier (SID), a unique number associated with the domain. When a PDC is installed and started, a unique SID is assigned. Therefore, if you have an existing domain, and you want to add a new server to the domain as the PDC, you must install the new server as a BDC first, then change the server's role. For information about changing the server's role, see Section 2.1.1.1, Changing a Server's Role in a Domain.

2.1.2.1 Synchronizing SAM Databases on Domain Controllers

Normally, the domain security databases are synchronized automatically at regular intervals: the primary domain controller (PDC) replicates its databases to the backup domain controllers (BDCs). In rare cases, you may need to synchronize them manually. For example, you may have just added some new users or groups and you want the BDCs to be able to validate the new user logons now, rather than after the next periodic synchronization. To do this, use the SET COMPUTER/ACCOUNT_SYNCHRONIZE command. You can synchronize all BDCs at once, or synchronize an individual BDC with the PDC.

2.1.2.1.1 How to Synchronize All Controllers in a Domain

To ensure that all BDCs are synchronized with the PDC, enter the SET COMPUTER /ACCOUNT_SYNCHRONIZE command, specifying the PDC.

For example, if the PDC is called TINMAN, the following command ensures that all BDCs in the domain are synchronized with TINMAN. This command results in each BDC receiving a synchronize status message from the PDC. The information in this message determines whether the BDC's databases are synchronized with the PDC's databases. If the status message indicates to a BDC that the PDC's databases contain changes that are not represented in the BDC's databases, the BDC will request a partial synchronization. The PDC sends the BDC only those database elements that were changed since the last time the BDC received a status message.

LANDOFOZ\\TINMAN> SET COMPUTER TINMAN/ACCOUNT_SYNCHRONIZE Resynchronizing "LANDOFOZ" domain may take a few minutes. Do you want to continue with the synchronization [YES or NO] (YES) : YES %PWRK-S-ACCSYNCHED, account synchronization was successfully initiated LANDOFOZ\\TINMAN>

Although the command has completed successfully, the synchronization process takes a few minutes to complete. You can monitor its progress by reviewing the System event log file using the SHOW EVENTS command. If the BDCs are already up-to-date, no event log message is recorded.

2.1.2.1.2 How to Synchronize a Specific Backup Domain Controller with the Primary Domain Controller

To synchronize a specific backup domain controller (BDC) with the primary domain controller (PDC), enter the SET COMPUTER/ACCOUNT_SYNCHRONIZE command, specifying the BDC name.

For example, if the BDC is called WOODMAN, the following command synchronizes only the server WOODMAN with the domain's primary domain controller, TINMAN. The BDC requests a full synchronization, meaning that the entire databases are replicated to the BDC.

LANDOFOZ\\TINMAN> SET COMPUTER WOODMAN/ACCOUNT_SYNCHRONIZE Resynchronizing "WOODMAN" with its Primary Domain Controller "TINMAN" may take a few minutes. After the synchronization has completed, you should check the Event Logs on "WOODMAN" and "TINMAN" to determine whether synchronization was successful. Do you want to continue with the synchronization [YES or NO] (YES) : YES %PWRK-S-ACCSYNCHED, account synchronization was successful LANDOFOZ\\TINMAN>

Although the command has completed successfully, the synchronization process takes a few minutes to complete, and longer if the database contains thousands of accounts. You can monitor its progress by reviewing the System event log of the primary domain controller, using the command SHOW EVENTS/SERVER=pdc_name (where pdc_name is the name of the primary domain controller). (Note that the primary domain controller periodically posts an update to its System event log during a full synchronization; the backup domain controllers post a single update when the synchronization has completed.)

2.1.3 Displaying the Current Domain

When you use the ADMINISTER command-line interface, the command prompt provides the name of your domain, along with the name of the server. By default, you are set up to administer the local server and the domain to which it belongs. The default domain remains in effect for the duration of the current OpenVMS login session, or until you log off the domain or change the default domain. (You can change the default server, too.)

To display the current domain and server, execute the ADMINISTER command. For example:

$ ADMINISTER LANDOFOZ\\TINMAN>

The domain name and server name are in the command prompt. In this example, the domain name is LANDOFOZ and the server name is TINMAN.

Any domain name prefixed by the double backslashes indicates a member server (or workstation) local security accounts database will be the target of ADMINISTER commands. For more information on managing member servers, see Section 2.1.5, Member Servers and Domain Management.

Use the SHOW ADMINISTRATION command to display information about the current domain and your logged-on user account. For example:

LANDOFOZ\\TINMAN> SHOW ADMINISTRATION Administration information: The domain being administered is: LANDOFOZ The domain controller for the domain is: TINMAN The domain controller type is: Advanced Server for OpenVMS The server being administered is TINMAN The server type is: Advanced Server for OpenVMS The user name is: ADMINISTRATOR The user is logged on to domain LANDOFOZ and has been authenticated. The user's privilege level on this domain is: ADMIN The user's workstation is TINMAN and is in domain LANDOFOZ. LANDOFOZ\\TINMAN>

2.1.4 Administering Another Domain

You can administer another domain in either of the following ways:

Use the SET ADMINISTRATION /DOMAIN command. You can perform only administrative functions that do not require you to be logged on to the domain you are administering, such as the SHOW TRUSTS command. For example:

LANDOFOZ\\TINMAN> SET ADMINISTRATION/DOMAIN=RUBYPALACE %PWRK-S-ADMSET, now administering domain "RUBYPALACE", server "QUEEN" RUBYPALACE\\QUEEN> SHOW TRUSTS There are currently no domains trusted by domain RUBYPALACE. Domains permitted to trust domain RUBYPALACE: LANDOFOZ

In this example, because a server was not specified with the SET ADMINISTRATION command (using the /SERVER qualifier), and the local server (TINMAN) is not a member of the specified domain (RUBYPLACE), the default server is the primary domain controller of the specified domain. The primary domain controller in domain RUBYPLACE is QUEEN.

Use the LOGON command to log on to the domain. You must log on to the domain to perform some administrative functions, such as the ADD TRUST command. If you do not supply the password on the LOGON command line, you will be prompted for it, if necessary. For example:

$ ADMINISTER LANDOFOZ\\TINMAN> LOGON ADMINISTRATOR/DOMAIN=RUBYPALACE Password: The server \\QUEEN successfully logged you on as Administrator. Your privilege level on domain RUBYPALACE is ADMIN. The last time you logged on was 08/09/00 07:44 AM. RUBYPALACE\\QUEEN>

To administer LANDOFOZ again, log off. The LOGOFF command logs you off the network. After you log off the server QUEEN, you must log on to the server TINMAN to administer domain LANDOFOZ. For example:

RUBYPALACE\\QUEEN>LOGOFF ADMINISTRATOR was logged off successfully. LANDOFOZ\\TINMAN>LOGON ADMINISTRATOR Password: The server \\TINMAN successfully logged you on as Administrator. Your privilege level on domain LANDOFOZ is ADMIN. The last time you logged on was 08/09/00 07:16 AM.

For information about the requirements for administrative functions, refer to the Compaq Advanced Server for OpenVMS Commands Reference Manual.

Section 2.1.5, Member Servers and Domain Management, explains how to administer a member server's local database.

Contents

Index

Compaq Advanced Server for OpenVMSServer Administrator's Guide

Chapter 2Managing Domains and Servers

2.1 Managing a Domain

2.1.2 Domain Controllers and the SAM Database

Compaq Advanced Server for OpenVMS
Server Administrator's Guide

Chapter 2
Managing Domains and Servers