Managing Domains

When you have established at least one domain, you can use the utilities provided in Windows NT Server Tools, Windows NT Administrative Tools, or Windows NT Server to perform the following domain management tasks:

Promote and demote domain controllers.
Synchronize backup domain controllers with the primary domain controller.
Add, remove, and rename domain computers.
Manage domain security, including account policy, audit policy, and trust relationships.

Promoting and Demoting Domain Controllers

In addition to the primary domain controller (PDC), you should have at least one backup domain controller (BDC) in every domain.

When a backup domain controller is promoted to primary domain controller, an up-to-date copy of the domain's directory database is replicated from the old PDC to the new one, and the old PDC is demoted to a BDC.

If a BDC is promoted to PDC while the existing PDC is unavailable (for example, while it is being repaired), and if the former PDC later returns to service, you must demote the former PDC to BDC. Until the former PDC is demoted to a BDC, it will not run the Net Logon service nor participate in authentication of user logons, and its icon in the Server Manager window will be dimmed.




	NOTE: Usually, when a BDC is promoted to a PDC, the system automatically demotes the former PDC to a BDC. However, if Server Manager cannot locate the PDC, the PDC is not demoted and the user receives a message indicating this condition. The user can choose to proceed without demoting the PDC or wait until the PDC can be demoted.

For information on how to promote and demote domain controllers, see "Promoting a Backup Domain Controller to Primary Domain Controller" and "Demoting a Primary Domain Controller to Backup Domain Controller" in Server Manager Help.

Directory Database Synchronization

The directory database is synchronized automatically by Advanced Server. Based on settings in the Advanced Server Registry, the PDC sends timed notices that signal the BDCs to request directory changes from the PDC. The notices are staggered so that all BDCs do not request changes at the same time. When the BDC requests changes, it informs the PDC of the last change it received. Thus the PDC always is aware of which BDC needs changes. If a BDC is up-to-date, then the BDC does not request changes.

For information about the Advanced Server Registry, see Advanced Server Administration.

Storage of Changes in the Change Log

Changes to the directory database consist of any new or changed passwords, new or changed user and group accounts, and any changes in their associated group memberships and user rights.

Changes to the directory database are recorded in the change log. The size of the change log determines how long changes can be held. The log holds a certain number of changes. As a new change is added, the oldest change is deleted. When a BDC requests changes, those changes which occurred since the last synchronization are copied to the BDC. The change log keeps only the most recent changes. If a BDC does not request changes in a timely manner, then the entire directory database must be copied to that BDC. For example, if a BDC is off-line for an extended period of time, the number of changes that can occur during that period may exceed the number that can be stored in the change log.

Partial and Full Synchronization

The automatic, timed replication to all domain BDCs of only those directory database changes that have occurred since the last synchronization is called partial synchronization. You can use Server Manager to force a partial synchronization of all BDCs in the domain. For example, if a new user is added to the domain and is in great need of certain resources, you can perform a partial synchronization to get the new user's account added to all BDCs as soon as possible.

If needed, you can use Server Manager to manually force a partial synchronization of a particular BDC with the PDC. For example, if access is denied because of a problem with the BDC computer account password (as evidenced by "access denied" messages in the event log), a partial synchronization of the BDC with the PDC fixes the password problem and reestablishes a secure channel.

Sending a copy of the entire directory database to a BDC is called full synchronization. Full synchronization is performed automatically when changes have been deleted from the change log before replication takes place and when a new BDC is added to a domain.

The default Net Logon service settings for the timing of updates (every five minutes) and the size of the change log (approximately 2000 changes) ensure that full synchronization will not be required under most operating conditions.

Synchronizing Domain Controllers

The Computer menu in Server Manager includes a command for synchronizing changes to the directory database. The command that is available depends on the type of computer that is selected, as follows:

When the primary domain controller is selected, the Synchronize Entire Domain command is available on the Computer menu. This command copies the latest directory database changes from the PDC to all of the BDCs in the domain. Synchronize Entire Domain initiates synchronization of all BDCs without waiting for completion of any synchronization in progress.
When a backup domain controller is selected, the Synchronize With Primary Domain Controller command is available on the Computer menu. This command copies the latest directory database changes to the selected BDC only.

For information on how to synchronize domain controllers, see "Synchronizing a Backup Domain Controller with the Primary Domain Controller" and "Synchronizing All Servers of the Domain" in Server Manager Help.

Adding, Renaming, Moving, and Removing Domain Computers

A domain is created by installing Advanced Server and designating the computer as a primary domain controller. Other computers then can be added to the domain.

Before a computer running Advanced Server, Windows NT Server, or Windows NT Workstation can be a domain member and participate in domain security, it must be added to the domain. When a computer is added to a domain, Advanced Server creates a computer account for it. If the added computer is a backup domain controller, it requests a copy of the domain directory database.

Adding a Domain Workstation or Server Computer

To add a computer to a domain, you must be logged on to a user account that has the appropriate user rights.

With the appropriate rights, users can add workstations and servers to domains during or after installation.




	NOTE: A primary domain controller cannot be added to an existing domain.

There are four ways to add a computer to a domain:

A member of the Administrators or Account Operators group can use the Advanced Server joindomain command to reconfigure an Advanced Server computer to be a backup domain controller in an existing domain without reloading the server software. For this procedure to take effect, the primary domain controller must be running in the domain that is being joined. For more information, type man joindomain at the Advanced Server command prompt.
A Windows NT Workstation or Windows NT Server computer running as a member server can be added to a domain during installation of Windows NT and an Advanced Server or a Windows NT Server domain controller can be added to a domain during installation, but only if the installations are performed by a member of the Administrators or Account Operators group.
A member of the Administrators or Account Operators group, or a user who has the "Add workstation to domain" right, can add an existing Windows NT Workstation or Windows NT Server computer running as a member server to a domain using the Network option of that workstation's Control Panel. However, a Windows NT backup domain controller cannot be added to the domain in this way.
A member of the Administrators or Account Operators group can use Server Manager's Add To Domain command to add a computer account to the domain's security database. A Windows NT Workstation or a Windows NT Server running as a member server then can use the Network option of the computer's Control Panel to join the domain under that computer account.




	NOTE: Be sure to protect the security of an added computer name. Until the intended computer joins the domain, it is possible for a user to give a different computer that name and then have it join the domain using the computer account you have just created. If the added computer is a backup domain controller, when it joins it receives a copy of the domain's security database.

For more information about adding a computer to a domain, see "Adding a Computer to the Domain" in Server Manager Help.

Removing a Computer From a Domain

You can remove workstations, backup domain controllers, and member servers from a domain but you cannot remove the primary domain controller until you promote a backup domain controller.

When you remove a computer running Windows NT Workstation or Windows NT Server as a member server from an Advanced Server domain, use Server Manager to delete the computer's account from the directory database so that the computer cannot participate in domain security.

After a computer account has been removed from the domain, a user of the computer must move the computer to a new workgroup or domain using the Network option in Control Panel.




	WARNING! To remove a Windows NT backup domain controller from a domain, you must delete the computer account and reinstall Windows NT Server or Windows NT Workstation on that computer, indicating the new domain. Do not continue to use a backup domain controller that has been removed from a domain until you have reinstalled the operating system. An Advanced Server backup domain controller does not need to be reinstalled. It can be moved from one domain to another using the joindomain command.

For information about the joindomain command, type man joindomain at the Advanced Server command prompt.

For more information about removing a Windows NT computer from a domain, see "Removing a Computer from the Domain" in Server Manager Help.

Identifying Domains Internally

Administrators and users identify domains by domain names. Internally, however, Advanced Server identifies each domain by its security identifier (SID), a unique number assigned to the domain. This requires that administrators exercise a degree of caution when adding servers to a domain as illustrated in the following example.

A domain named Sales.dom has a primary domain controller named SALES1, and no other Advanced Server computers. The SALES1 server becomes inactive and you install the Advanced Server on another computer, SALES2, and configure it to be the primary domain controller for Sales.dom.

The effect of this operation is to create a new domain named Sales.dom that is entirely separate from the original Sales.dom — a new SID will have been generated for Sales.dom on the SALES2 server that will not match the SID for Sales.dom on the SALES1 server. This means that any Windows NT Workstation computers that had been members of Sales.dom while SALES1 was the primary domain controller will not be able to support user logons to the domain Sales.dom when SALES2 is the primary domain controller. Furthermore, if the SALES1 server is restarted when the SALES2 server is active, the Net Logon service will not start on the SALES1 server because Advanced Server software will detect two different domain SIDs with the same domain name.

To configure both servers to work properly in the original Sales.dom, you need to run the joindomain command on the SALES2 server while the SALES1 server is running. The joindomain command obtains the SID for Sales.dom from the SALES1 server and uses it to configure the SALES2 server as a backup domain con troller in the original Sales.dom domain.

This same procedure should be used to move an Advanced Server computer from one domain to another. The joindomain command would be executed on the computer that is changing its domain. When it is executed, the primary domain controller must be running in the domain that is to be joined so that joindomain can obtain the SID of that domain.

Changing the Computer Name of a Server or Workstation

To change the name of an Advanced Server computer, use the Advanced Server setservername command.

For information about the setservername command, type man setservername at the Advanced Server command prompt.

To change the name of a Windows NT computer, first use Server Manager to create a computer account for the computer under its new name. Then, change the computer name at the server or workstation using the Network option in Control Panel. After the computer name has been changed, use Server Manager to remove the old computer account from the domain.

If you are changing the name of a backup domain controller, make sure the new computer account has been added to the directory database before deleting the old computer account from the directory database. Use Server Manager to synchronize the directory database.

For more information, see "Adding a Computer to the Domain" and "Changing a Computer Name" in Server Manager Help.

For information about how to synchronize domain controllers, see "Synchronizing a Backup Domain Controller with the Primary Domain Controller" in Server Manager Help.

Changing the Name of a Domain

To change the name of an Advanced Server domain, use the setdomainname command on every Advanced Server computer in the domain. Use the Network option in the Control Panel to change the domain name on every Windows NT Workstation and Windows NT Server computer in the domain. Then, reestablish existing trust relationships. The domain security identifier (SID) does not change.

You can use this procedure to change the domain name of every computer in a domain. You cannot use it to move a domain controller from one domain to another. Also, you cannot use this procedure to split a domain into two separate domains or to join two separate domains into a single domain.

For information about the setdomainname command, type man setdomainname at the Advanced Server command prompt.

Moving a Computer to a Different Domain

To change the domain to which an Advanced Server computer belongs, use the joindomain command.

For information about the joindomain command, type man joindomain at the Advanced Server command prompt.

A Windows NT backup domain controller cannot change domains unless Windows NT Server is reinstalled. Member servers and computers running Windows NT Workstation can change domains without requiring Windows NT to be reinstalled.

To move a workstation or member server from one Advanced Server domain to another, remove the computer from the old domain and add it to the new one.

For information about on to move a Windows NT computer from one domain to another, see "Removing a Computer from the Domain" and "Adding a Computer to the Domain" in Server Manager Help.

Managing Domain Security Policies

Advanced Server, Windows NT Server, and Windows NT Workstation security policy settings can provide different levels of security for user actions on domain controllers and on workstations and member servers. Domain security policy should be established as part of planning your domain.

When administering domains, security policy applies to the primary and backup domain controllers in the domain (they share the same security policy). When administering a computer running Windows NT Workstation or a computer running Windows NT Server as a member server, security policy applies only to that computer.

You can define three security policies:

Account policy controls how passwords are used by user accounts.
Audit policy controls the types of events that are recorded in the security log (which you can view in Event Viewer if you are logged on as a member of the Administrators group).
Trust Relationships policy controls which domains are trusted and which domains are trusting domains. This policy is not used in the single domain model and is not available when administering a computer running Windows NT Workstation or a computer running Windows NT Server as a member server.

A fourth security policy, the User Rights policy, is applied to groups or users and affects the activities allowed on either an individual workstation or member server, or on all domain controllers in a domain.

For information about the User Rights security policy, see Chapter 3, "Working With User and Group Accounts."

For information about trust relationships, see "Administering Trust Relationships" later in this chapter.

Setting User Password (Account) Policy

The Account policy controls how passwords must be used by all user accounts for a computer or domain and also determines the account lockout policy.

Password restrictions include password expiration limits, whether a password can be changed and when a change is required, whether each new password must be different from former passwords, and how long a password can be.

The account lockout feature enables you to make Advanced Server more secure from intruders who try to log on by guessing the passwords of existing user accounts. When account lockout is enabled, a user account becomes locked if a number of incorrect logon attempts occur within a specified amount of time. Locked accounts cannot log on. A locked account remains locked until an administrator unlocks it or until a specified amount of time passes. By default, account lockout is disabled.




	NOTE: The account lockout feature is not available in earlier versions of Advanced Server or LAN Manager, Version 2.2.

There are four password parameters that you can define in the Account Policy dialog box.

Parameter	Description
Maximum Password Age	The period of time a password can be used before the system requires the user to change it.
Minimum Password Age	The period of time a password must be used before the user is allowed to change it. If you select the Allow Changes Immediately option, then under Password Uniqueness you should select the Do Not Keep Password History option.
Minimum Password Length	The fewest characters a password can contain.
Password Uniqueness	The number of new passwords that must be used by a user account before an old password can be reused. If you enter a uniqueness value here (for example, Remember 4 Passwords), then under Minimum Password Age you should specify an age value (for example, Allow Changes In 7 Days).

If you select Account Lockout, you also should set the following parameters.

Parameter	Meaning
Lockout After	The number of incorrect logon attempts that will cause the account to be locked. The range is from 1 to 999.
Reset Count After	The maximum number of minutes that can occur between any two bad logon attempts. The range is from 1 to 99999. For example, if Lockout After is 5 bad logon attempts, and Reset Count After is 30 minutes, then 5 bad logon attempts, each 29 minutes apart, would cause lockout.
Lockout Duration	Select Forever to cause locked accounts to remain locked until an administrator unlocks them. Select Duration and type a number to cause accounts to remain locked for the specified number of minutes.

The Forcibly Disconnect Remote Users From Server When Logon Hours Expire option interacts with the logon hours defined for a user account. If the option is selected, a user account that exceeds the time set in the Logon Hours dialog box is disconnected from all connections to any server in the domain. The user receives a warning message a few minutes prior to expiration of the logon hours.

If this option is cleared, the user will not be disconnected when Logon Hours has been reached, but no new connections are allowed and a warning message is sent every five minutes.

When Users Must Log On In Order To Change Password is selected, users can not change their own passwords when they expire; they must get help from an administrator. When this option is cleared, users can change their own passwords when they expire without help from an administrator.

Changes to account policy affect every user on the computer or domain at the next logon.

For information on how to set account policy, see "Managing the Account Policy" in User Manager for Domains Help.

For information about setting logon hours, see Chapter 3, "Working With User and Group Accounts."

Setting the Audit Policy

Auditing allows you to track selected activities of users. On a domain controller, the Audit policy determines the amount and type of security logging Advanced Server performs on all of the domain controllers in the domain. On workstations or member servers, the Audit policy determines the amount and type of security logging performed on the individual computer.

Advanced Server can record a range of event types — from system-wide events such as a user logging on, to attempts by a particular user to read specific files. Both successful and unsuccessful attempts to perform an action can be recorded.

Use the Audit policy to select the types of security events that will be audited. When an audited event occurs, an entry is added to the computer's security log. Use Event Viewer to view the security log.

Setting up auditing on files, directories, and printers is a two-part process. After you enable auditing for the domain and select the events to audit, you then can apply audit security to specific files, directories, and printers using the Security tab on the respective object's property sheet.

For information about using auditing as a resource security measure, see Chapter 5 "Managing Shared Resources and Resource Security."

When administering domains, the Audit policy applies to the security log of the primary and backup domain controllers in the domain because they share the same Audit policy.

When administering a computer running Windows NT Workstation or a computer running Windows NT Server as a member server, the Audit policy applies only to the security log of that computer.

The following table describes the types of events that can be audited.

Type of event	Description
Logon and Logoff	A user logged on or off or made a network connection.
File and Object Access	A user opened a directory or a file that is set for auditing in File Manager, or a user sent a print job to a printer that is set for auditing in Print Manager.
Use of User Rights	A user used a user right (except those rights related to logon and logoff).
User and Group Management	A user or group account was created, changed, or deleted. A user account was renamed, disabled, or enabled; or a password was set or changed.
Security Policy Changes	A change was made to the User Rights, Audit, or Trust Relationships policies.
Restart, Shutdown, and System	A user restarted or shut down the computer, or an event has occurred that affects system security or the security log.
Process Tracking*	These events provided detailed tracking information for things like program activation, some forms of handle duplication, indirect object accesses, and process exit.

* Applies only to Windows NT.

Because the security log size is limited, select the events to be audited carefully and consider the amount of disk space you are willing to devote to the security log. The maximum size of the security log is defined in Event Viewer.

For more information, see "Managing the Audit Policy" in User Manager for Domains Help; "Viewing Event Logs," "Searching for Events," and "Viewing Event Details" in Event Viewer Help; and "To add a user or group to a permissions list" and "To add a user or group to an auditing list" in Windows NT Help.

For information about the security log and using Event Viewer, see Chapter 7, "Monitoring Events."

Administering Trust Relationships

By grouping computers into domains, network administrators and users benefit in the following ways:

Servers in a domain form a single administrative unit, sharing security and user account information, thereby saving administrators and users time and effort.
Users browsing the network for available resources see the network grouped into domains rather than as individual servers and printers on the whole network. (This benefit is identical to the Windows for Workgroups and Windows 95 concept of a workgroup.)

Trust relationships move the convenience of centralized administration from the domain level to the network level. By establishing trust relationships between the domains on your network, you enable user accounts and global groups to be used in domains other than the domain in which these accounts are located. You need to create each user account only once and the account can be given access to any computer on your network — not just the computers in one domain.

Trust relationships are created only between Advanced Server or Windows NT Server domains. When administering member servers, computers running Windows NT Workstation, or a LAN Manager 2.2 domain, the Trust Relationships command is unavailable.

The following diagram illustrates a trust relationship between two domains that contain both resources and accounts.

One-way trust relationship

In the preceding diagram, user accounts from the Sales domain can use resources in the Production domain. The effect of this trust is that users from Sales can log on to their domain and receive access to servers in the Production domain, and they can do so from any workstation in either domain. Users from Sales can be added to local groups in the Production domain. Users in Production, however, cannot belong to local groups in the Sales domain, log on to the Production domain from Sales workstations, nor connect to servers in the Sales domain.

One common scenario for a one-way trust is for a domain containing only accounts to be trusted by one or more resource domains. That trust configuration results in all accounts being trusted to use all resources.

Creating a Trust Relationship Between Two Domains

Trust relationships between domains also can be established by using the net trust command. For more information, type net help trust at the Advanced Server command prompt.

To create trust relationships, use the Trust Relationships command on the Policies menu in User Manager for Domains. Creating a one-way trust relationship requires two steps: first one domain (the domain that is to be the trusted domain) must add a second domain (the domain that is to be the trusting domain) to the list of domains that trust it. Then the trusting domain must add the trusted domain to the list of domains that it trusts. Because the trust relationship is not yet established, these two steps may need to be performed by separate administrators.

It is best to establish the Trusting Domain relationship first, followed by the Trusted Domain relationship. This order allows the password used for setting up the relationship to be verified immediately when the relationship is first used.

For information on how to create a trust relationship, see "Adding a Trusting Domain" and "Adding a Trusted Domain" in User Manager for Domains Help.

Removing a Trust Relationship Between Two Domains

To remove a trust relationship, you must remove both halves of the trust. From the trusting domain, remove the trusted domain. From the trusted domain, remove the trusting domain.




	NOTE: When an administrator establishes a trust relationship between two domains, a computer account is created to be used by computers in the trusting domain to establish secure communications to the trusted domain. The password for this account is given at the time that the trust relationship is established. This password is changed periodically by the trusting domain server software. If a trust relationship is broken, 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. When you reestablish the trust relationship, you again must store matching passwords for the trusting and trusted domains. If only one side of the trust relationship is broken and reestablished, trust will appear to work in some ways and fail in others. For example, it will be possible to grant resource access to a user from the trusted domain, but the user will not actually be granted the indicated access.

Limitations in Server Tools' User Manager for Domains

The User Manager for Domains that is included in the Windows NT Server Tools program group for Windows 95 computers has limitations that affect the administration of trusted domains. You should consider them when planning your network. (Note that these limitations do not affect the Windows NT Administrative Tools program group which is installed on Windows NT Workstation computers.)

In order to use the Trust Relationships dialog box to trust another domain, and the Add Users and Groups dialog box to grant privileges and group memberships to users in a trusted domain, at least one of the following conditions must exist:

The other domain already must trust your domain.
The domain account that you are logged on to has the same name and password as an account in the other domain.
The other domain has enabled its Guest account, and the domain account that you are logged on to does not have the same name as any account in the other domain.

Additionally, the User Manager for Domains that is included in the Windows NT Server Tools program group cannot verify trust relationships between domains. Be sure to enter correct passwords for the trust relationship. If you are performing this procedure from Windows NT Server Tools, you will receive a message indicating the trust relationship could not be verified.

Duplicate User Accounts in Different Domains

In an Advanced Server environment, access for a single user across multiple domains generally can be arranged by adding an account with the same user name and password to each domain. If a user matches the user name and password, access is given regardless of which domain the user is logged on to.

The exception to this rule is when trust relationships are in operation. If a trust relationship is established between two domains, then the trusting domain is able to distinguish users in the trusted domain from users in the local domain — even if they have the same name and password.

Consider three domains: Athens, Berlin, and Cairo. Each domain has a global user account, MasterAdmin. MasterAdmin has the same password and is a member of the global group Domain Admins in each domain. The Athens domain trusts the Berlin domain but no other trust relationships are established.

The following table describes the access that MasterAdmin has while logged on to each domain:

Logged On	Can Administer	Cannot Administer
Athens	Athens, Berlin, Cairo
Berlin	Berlin, Cairo	Athens
Cairo	Athens, Berlin, Cairo

It would appear that the trust relationship between Athens and Berlin has restricted the access of the MasterAdmin user across the domains. In fact, the trust relationship has made access more controllable. The Athens domain now can distinguish the user Athens\MasterAdmin from the user Berlin\MasterAdmin and grant access accordingly.

In order for MasterAdmin to administer the Athens domain from Berlin, the user Berlin\MasterAdmin should be added to the Domain Admins global group in the Athens domain. If the password for the Berlin\MasterAdmin account changes, it could be used to administer Athens but not Cairo.