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

As with Windows NT, there may be situtations where you would like to allow people 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 account 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 domain-wide --- 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, as shown:

$ ADMINISTER LANDOFOZ\\WIZARD>

To manage a member server's local database, you must log in, or change the default domain to the local database. To do so, specify for the domain name the member server's name preceded by two backslashes (\\). The following example shows how to specify 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>

As shown, 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 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 name as the domain (preceded by two backslashes). For the server name, unless you specified a specific 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 domain-wide 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 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 qualifiers; 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 wish 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. If you do not wish to supply this information, 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 it when joining and the computer account will be added to the domain automatically. Note that until the intended computer account actually joins the domain, it is possible for a malicious user to 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 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 4.0) Primary Advanced Server V7.3 for OpenVMS [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 been configured and started yet.

To determine whether a specific computer is available, use the SHOW COMPUTER command, specifying 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 execute 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, where 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 where 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 where the shared resources are defined) can indicate that it is willing to trust the other domain.

For example, assume there are two domains: LANDOFOZ and KANSAS. 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. This is called a one-way trust relationship.

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

To set up the trust relationship, use the following procedure:

1. When logged in on 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.2 Displaying the Trust Relationships

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. Execute 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>

Execute 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.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, follow the steps given below.

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

1. When logged in on 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

If you no longer want a trust relationship to be in effect, you must remove it. When you remove a trust, both sides of the trust relationship must be dissolved. 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.

The following example shows how to set the account policy for the domain so that users are disconnected when they exceed their logon hours (/FORCE_DISCONNECT), and they are locked out after three failed logon attemps. The failed logon count resets 20 minutes after the last failed login attempt, and locked-out accounts are unlocked after 25 minutes.

LANDOFOZ\\TINMAN> SET ACCOUNT POLICY/FORCE_DISCONNECT- _LANDOFOZ\\TINMAN> /LOCKOUT=(ATTEMPTS=3,WINDOW=20,DURATION=25) %PWRK-S-ACCPOLSET, account policy set for domain "LANDOFOZ"

2.2.1.2 Example: Displaying the Account Policy for a Domain

The following example shows how to use the SHOW ACCOUNT POLICY command to display the account policy for a domain:

LANDOFOZ\\TINMAN> SHOW ACCOUNT POLICY Account Policy for domain "LANDOFOZ": Minimum password age (days) : 1 Maximum password age (days) : 42 Minimum password length : 0 Length of password history maintained : None Force user logoff after logon hours expire: YES Lock out account after how many bad password attempts : 3 Number of minutes account remains locked : 20 Number of minutes to wait before resetting lockout count : 25 Role of server TINMAN : Primary Domain Controller