Document revision date: 15 October 2001

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 (that is, 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. 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 04/09/01 07:44 AM. RUBYPALACE\\QUEEN>

  
  To administer LANDOFOZ again, log off the network by using the LOGOFF command. 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 04/09/01 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.

2.1.5 Member Servers and Domain Management

Using ADMINISTER commands on a member server (or directing them to a member server), you can manage the domainwide security accounts database as you would from any domain controller. Although a member server does not store or maintain the domainwide database, it still has access to the benefits of the centralized, domainwide database.

As with Windows NT, in some situations you might want to allow users to manage a server without giving them the ability to manage the entire domain. For this reason, the Advanced Server member server has a local security accounts database. This database initially has the users Administrator and Guest as local to the server.

Both the domain's Administrator and the local Administrator can manage the member server. Certain users can set the default to the member server's local database, as explained in Section 2.1.5.1, Administering the Member Server's Local Database. In any case, certain objects, such as global groups and trusts, are manageable only when logged into a domain controller's domain. Certain ADMINISTER commands will be restricted. Section 2.1.5.2, ADMINISTER Command Variances on Member Servers, lists the ADMINISTER commands that are not allowed or that provide restricted capabilities. The information in both of these sections applies to workstations as well as member servers.

2.1.5.1 Administering the Member Server's Local Database

Unless you have changed the default to the member server's local database, ADMINISTER commands normally operate domainwide --- that is, on the domain to which the member server belongs. For example, if you enter the ADMINISTER command on member server WIZARD in domain LANDOFOZ, the ADMINISTER prompt displays domain LANDOFOZ and server WIZARD:

$ ADMINISTER LANDOFOZ\\WIZARD>

To manage a member server's local database, you must either log on, or change the default domain to the local database. To change the default domain, specify for the domain name the member server's name preceded by two backslashes (\\). The following example shows how to use the SET ADMINISTRATION command to administer member server WIZARD's local domain database:

LANDOFOZ\\TINMAN> SET ADMINISTRATION/DOMAIN=\\WIZARD %PWRK-S-ADMSET, now administering domain "\\WIZARD", server "WIZARD" \\WIZARD\\WIZARD>

Note that when you administer the member server's local domain database, the ADMINISTER prompt displays the domain name preceded by two backslashes, and the domain name is the same as the name of the member server (in this case, \\WIZARD\\WIZARD).

In an OpenVMS Cluster in which the Advanced Servers are member servers, you can optionally specify for the domain name the Advanced Server cluster alias name preceded by two backslashes. When administering a clustered member server's local database, the ADMINISTER prompt displays the Advanced Server cluster alias as the domain (preceded by two backslashes). For the server name, unless you specified a server name, the prompt displays the name of the cluster member that responded first to the ADMINISTER interface.

2.1.5.2 ADMINISTER Command Variances on Member Servers

As mentioned previously, member servers do not maintain or manage the domainwide security accounts database and cannot manage or display certain objects, such as global groups, primary groups, and trusts. Table 2-2, Disallowed or Restricted Commands When Administering a Member Server's Local Database, lists the commands that are not allowed or that are restricted, when administering the member server's local domain and database. If you attempt to use these commands in such circumstances, the following error message will be displayed:

%PWRK-E-DCONLY, operation is only valid to a Domain Controller

The affected commands are categorized by each of the following management objects: COMPUTER, GROUP, TRUST, and USER.

Table 2-2 Disallowed or Restricted Commands When Administering a Member Server's Local Database

Object	Command	Restriction
COMPUTER	ADD	Not allowed.
	REMOVE	Not allowed.
	SET	Not allowed with the /ACCOUNT_SYNCHRONIZE or /ROLE= qualifiers.
	SHOW	When you do not specify a computer name with the command, it displays information about the member server only (the computer you are managing) rather than about all the computers in the domain. Note that the display symbol for a member server is [SV].
GROUP	ADD, COPY, MODIFY, REMOVE, SHOW	Do not use with global groups, and do not use the /GLOBAL or /PRIMARY_GROUP qualifier; GROUP commands manage local groups only.
TRUST	ADD, REMOVE, SHOW	Not allowed.
USER	ADD, COPY, MODIFY	Do not use with the /PRIMARY_GROUP qualifier; the ADD USER command adds the user to the Users local group; these commands manage memberships in local groups only.
	REMOVE, SHOW	These commands manage memberships in local groups only; the SHOW USERS command does not display the primary group or memberships in global groups.

2.1.6 Adding a Computer Account to a Domain

For an Advanced Server or a Windows NT computer to become a domain member, it must be added to the domain's security accounts database.

When a computer is configured to join an existing domain (for example, when you install a Windows NT Server or workstation, or when you run the PWRK$CONFIG.COM command procedure on an Advanced Server), the computer account can be added to the domain's security database automatically. This procedure requires that the user name and password of a user account with membership in the Administrators group be supplied.

Alternatively, use the ADD COMPUTER command to add the computer account to the domain's security database. After you add the computer account, the computer joins the domain automatically when it is started. No password is required when a computer joins the domain in this case.

The ADD COMPUTER command is useful only if you do not want to give out the user name and password of an Administrator account in your domain to the administrator of the computer that will join your domain. You can use the ADD COMPUTER command to add the computer account to your domain before the computer's administrator joins the domain. If you supply password information to the administrator of the other computer, the administrator can use the password when joining, and the computer account will be added to the domain automatically. Note that until the intended computer account actually joins the domain, a malicious user could give a different computer that computer name, and then have it join the domain using the computer account you have just created.

If the intended computer does not join the domain immediately, you can remove the computer account from the domain's security database by using the REMOVE COMPUTER command, as described in Section 2.1.7, Removing a Computer Account from a Domain's Security Database.

2.1.6.1 Procedure for Adding a Computer to a Domain

To add a computer to a domain, follow these steps:

1. Identify the name of the domain to which you will add the computer.
2. Obtain or establish the name of the computer you will add; be sure it is unique in the network and no more than 15 characters long.
3. Determine whether the computer you are adding is to be a workstation, server, or backup domain controller.
4. Use the ADD COMPUTER command. Optionally, include the /DESCRIPTION qualifier to provide a description of the computer. If you enter a description that contains nonalphanumeric characters, spaces, or lowercase letters, enclose the description string in quotation marks.

For example, the following command adds the computer GREENGIRL as a Windows NT workstation to the domain LANDOFOZ:

LANDOFOZ\\TINMAN> ADD COMPUTER GREENGIRL %PWRK-S-COMPADD, computer "GREENGIRL" added to domain "LANDOFOZ" LANDOFOZ\\TINMAN>

The computer is added to the domain's security database. The SHOW COMPUTERS command shows GREENGIRL as a Windows NT workstation. For example:

LANDOFOZ\\TINMAN> SHOW COMPUTERS Computers in domain "LANDOFOZ": Computer Type Description ----------- --------------------- -------------------------------- [PD] TINMAN OpenVMS (NT 3.51) Primary PATHWORKS V6.1 for OpenVMS (Advanced Server) [ws] GREENGIRL Windows NT Workstation

Note that when the computer type display symbol is in lowercase, such as [ws] in this example, it indicates that the computer is unavailable to the network. The computer might be unavailable because it has not yet been configured and started.

To determine whether a specific computer is available, use the SHOW COMPUTER command and specify the name of the computer.

2.1.7 Removing a Computer Account from a Domain's Security Database

When you remove a computer account from the domain's security database, the computer can no longer participate in domain security. It might be useful to remove a computer account from the domain's security database if the computer did not join the domain after its account was added to the domain's security database. You cannot remove a primary domain controller.

2.1.7.1 Procedure for Removing a Computer from a Domain

To remove a computer from a domain, follow these steps:

1. Identify the name of the computer you will remove.
2. Enter the REMOVE COMPUTER command. When you use this command, you receive a prompt to confirm the requested action.

For example, the following command removes the computer GREENGIRL from the domain LANDOFOZ:

LANDOFOZ\\TINMAN> REMOVE COMPUTER GREENGIRL Removing computer "GREENGIRL" from domain "LANDOFOZ" will render it incapable of authenticating domain logons until it is added to another domain. Do you want to continue with the removal [YES or NO] (YES) : YES %PWRK-S-COMPREM, computer "GREENGIRL" removed from domain "LANDOFOZ" LANDOFOZ\\TINMAN>

2.1.8 Managing Trust Relationships

A trust relationship is a link between two domains, in which one domain honors the users of another domain, trusting the other domain to authenticate the logons of its users. When trust relationships are properly established among domains and resource permissions are set properly, a user with an account in one domain is allowed to access resources on another domain. The domain that has the user accounts is the trusted domain; the domain with the required resources is the trusting domain.

The administrators of both domains must supply the same password when establishing the trust relationship. After the trust relationship is established, the password is changed periodically by the domain software.

2.1.8.1 Establishing Trust Relationships

Both domains participating in a trust relationship must take an action to establish the trust. First, the domain that will be trusted (that is, the domain in which the user accounts are defined) must indicate that it is willing to be trusted by permitting the other domain to trust it. Then the domain that will be trusting (that is, the domain in which the shared resources are defined) can indicate that it is willing to trust the other domain.

2.1.8.2 Setting Up a One-Way Trust Relationship

As an example, domain KANSAS has resources required by users who have user accounts in domain LANDOFOZ. You need to set up a trust relationship so that KANSAS trusts LANDOFOZ, as shown in Figure 2-1, One-Way Trust Relationship: KANSAS Domain Trusting LANDOFOZ Domain. This is called a one-way trust relationship.

Figure 2-1 One-Way Trust Relationship: KANSAS Domain Trusting LANDOFOZ Domain

To set up the one-way trust relationship between domains LANDOFOZ and KANSAS, use the following procedure:

1. When logged on in domain LANDOFOZ, enter the following command:

   LANDOFOZ\\TINMAN> ADD TRUST KANSAS/PERMITTED Password: Password verification: %PWRK-S-TRUSTADD, trust between domains "LANDOFOZ" and "KANSAS" added LANDOFOZ\\TINMAN>

   
   This adds domain KANSAS to the list of domains permitted to trust LANDOFOZ.

2. Log on to domain KANSAS, and enter the following command. Use the same password in this command that was used in the previous command.

   KANSAS\\TOPEKA> ADD TRUST LANDOFOZ/TRUSTED Password: Password verification: %PWRK-S-TRUSTADD, trust between domains "KANSAS" and "LANDOFOZ" added KANSAS\\TOPEKA>

   
   This command adds domain LANDOFOZ to the list of domains trusted by domain KANSAS.

If the steps to establishing a trust are done in the opposite order (that is, one domain trusts the other before the other has permitted the first domain to trust it), the trust will eventually work. However, this can take up to 15 minutes.

2.1.8.3 Setting Up a Two-Way Trust Relationship

When a two-way trust relationship has been established, each domain trusts the other, and users in both domains can access resources in the other domain, assuming resource permissions have been set up properly.

To set up a two-way trust relationship between domains LANDOFOZ and KANSAS, as shown in Figure 2-2, Two-Way Trust Relationship Between Domains KANSAS and LANDOFOZ, use the following procedure:

Figure 2-2 Two-Way Trust Relationship Between Domains KANSAS and LANDOFOZ

1. When logged on in domain LANDOFOZ, add the domain KANSAS to the list of domains permitted to trust LANDOFOZ, as follows:

   LANDOFOZ\\TINMAN> ADD TRUST KANSAS/PERMITTED

2. On domain KANSAS, add the domain LANDOFOZ to the list of domains trusted by KANSAS, as follows:

   KANSAS\\TOPEKA> ADD TRUST LANDOFOZ/TRUSTED

3. On domain KANSAS, add LANDOFOZ to the list of domains that are permitted to trust KANSAS, as follows:

   KANSAS\\TOPEKA> ADD TRUST LANDOFOZ/PERMITTED

4. On domain LANDOFOZ, add KANSAS to the list of domains that are trusted by LANDOFOZ, as follows:

   LANDOFOZ\\TINMAN> ADD TRUST KANSAS/TRUSTED

To display trust relationships, use the SHOW TRUSTS command. In the following example, a trust relationship has been established to enable domain KANSAS to trust domain LANDOFOZ. Use the SHOW TRUSTS command on domain LANDOFOZ to display its trust:

LANDOFOZ\\TINMAN> SHOW TRUSTS There are currently no domains trusted by domain LANDOFOZ Domains permitted to trust domain LANDOFOZ: KANSAS LANDOFOZ\\TINMAN>

Use the SHOW TRUSTS command on domain KANSAS to display its trust:

LANDOFOZ\\TINMAN> SHOW TRUSTS/DOMAIN=KANSAS Domains trusted by KANSAS: LANDOFOZ There are currently no domains permitted to trust domain KANSAS LANDOFOZ\\TINMAN>

2.1.8.5 Removing Trust Relationships

If you no longer want a trust relationship to be in effect, you must remove it. When you remove a trust, the trusting domain must cease to trust the trusted domain, and the trusted domain must cease to permit the trusting domain to trust it.

To remove a trust relationship, use the REMOVE TRUST/TRUSTED command and the REMOVE TRUST/PERMITTED command. For example:

LANDOFOZ\\TINMAN> REMOVE TRUST KANSAS/PERMITTED Removing domain "KANSAS" from the Permitted Domains List will prevent users in domain "LANDOFOZ" from accessing resources in domain "KANSAS". If you choose to continue, you must also administer domain "KANSAS" and remove "LANDOFOZ" from its list of Trusted Domains. Do you want to continue with the removal [YES or NO] (YES) : YES %PWRK-S-TRUSTREM, trust between domains "LANDOFOZ" and "KANSAS" removed LANDOFOZ\\TINMAN>

To reestablish the trust relationship, you again must supply matching passwords for the trusting and trusted domains. If only one side of the trust relationship is broken and reestablished, the trust will appear to work in some ways and fail in others. For example, you can grant resource access to a user from the trusted domain, but the user is not actually granted the indicated access. To eliminate such problems, remove the old trust relationships and establish new trust relationships.

2.2 Managing Security Policies

You can manage the following security policies:

• Account Policy --- controls how passwords and logon hours are managed for user accounts.
• Audit Policy --- defines which security events are logged by the server in a domain.

You manage the account policy for your domain using the SET ACCOUNT POLICY command. You can view the account policy with the SHOW ACCOUNT POLICY command. Changes to the account policy affect every user at the next logon.

The account policy characteristics that you can specify include:

• Whether a user connection is forcibly disconnected when the logon hours specified for that user account are exceeded --- specify the SET ACCOUNT POLICY/FORCE_DISCONNECT command. You specify logon hours for each user account with the ADD USER, COPY USER, or MODIFY USER command, using the /HOURS qualifier, as explained in Section 3.1.7, Specifying Logon Hours.
  If you specify /NOFORCE_DISCONNECT for the account policy, the user is not disconnected when the logon hours are exceeded, but the user cannot make a new connection until the times (days and hours) specified as the logon hours for the account.
• The policy for usage of passwords --- use the SET ACCOUNT POLICY/PASSWORD_POLICY=keyword command. You can specify the following keywords and values with the /PASSWORD_POLICY qualifier:
  • [NO]MINAGE=n --- the minimum number of days a user's password must be used before the user can change it.
  • [NO]MAXAGE=n --- the maximum number of days a user's password can be used before the server requires the user to change it.
  • MINLENGTH=n --- the minimum length of a password.
  • [NO]HISTORY=n --- the number of new passwords that must be used before an old password can be reused.
• Whether a user account is locked out after a specified number of failed attempts to logon --- use the SET ACCOUNT POLICY/LOCKOUT=keyword command. To enable account lockout, you must specify the following three keywords and their values with the /LOCKOUT qualifier:
  • ATTEMPTS=n, where n specifies the number of failed attempts to allow before locking the user account.
  • DURATION=n, where n specifies the number of minutes before a locked account is automatically unlocked. The value of this parameter must be greater than, or equal to, the value set for the WINDOW parameter.
  • WINDOW=n, where n specifies the number of minutes to wait after a user account has been locked out, before resetting the logon count.
  
  Specify these three parameters with the /LOCKOUT qualifier as shown in the example in Section 2.2.1.1, Example: Setting a User Account Policy.
  By default, user account lockout is disabled, meaning that the user accounts are never locked out, no matter how many failed logon attempts are made on a user account. The /NOLOCKOUT qualifier specifies that user accounts are never locked out.
  To unlock a user account that has been locked, use the MODIFY USER command with the /UNLOCK qualifier.

	privacy and legal statement
6556PRO_003.HTML