2    Advanced Server Domains

Each ASU server must belong to a Windows domain and have a role in that domain. A Windows domain is a grouping of Advanced Servers that share a common directory database in which all domain security, user account, and group information is stored. An Advanced Server can be an ASU server, Windows NT server, or a Windows 2000 server. Other Advanced Server and Windows NT documents may refer to the directory database as the Security Accounts Manager (SAM) database.

This chapter describes:

See the ASU Installation and Administration Guide for information on installing the ASU software and configuring the ASU server in a domain.

2.1    Domain Roles

The domain role of an Advanced Server determines which one maintains the directory database and which ones receive a copy of the directory database. Each Advanced Server must have one of the following roles in the domain:

2.2    Common Domain Models

By planning and organizing domains, you can simplify network administration and ensure that users can connect to shares throughout the network. There are two types of domain models:

2.2.1    Trusted Domain Models

There are two types of trust relationships:

There are two common types of trusted domain models:

With each of these domain models, you create two types of domains:

You create a one-way trust from the resource domain to a master domain. Users log into a master domain and, because of the one-way trust, can access all of the disk and printers shares in the resource domains for which you have granted them access.

2.2.1.1    Single Master Domain Model

Figure 2-1 shows the single domain master model where all user accounts are created in a master domain called Personnel. All shares are created in the resource domains called Marketing, Sales, and Production.

Figure 2-1:  Single Domain Master Model

Because every domain user account exists in the master domain and because each resource domain trusts the master domain, every user account can use shares in any of the resource domains for which you have granted them access.

Features of the single master domain model include:

2.2.1.2    Multiple Master Domain Model

The multiple master domain model is similar to the single domain model in that you create domain user accounts in a master domain and shares in a resource domain; however, as the name implies, you create more than one master domain.

Figure 2-2 shows the multiple domain master model where all domain user accounts are created in two master domains called A_Personnel and B_Personnel. All shares are created in the resource domains South_Sales, South_Marketing, North_Sales, and North_Marketing.

Figure 2-2:  Multiple Domain Master Model

Because every domain user account exists in one of the master domains and because each resource domain trusts each master domain, every user account can use shares in any of the resource domains for which you have granted them access.

The multiple master domain model incorporates all of the features of a single master domain model and has the following additional features:

2.2.2    Single Domain Model

You can create a domain model in which domain user accounts and shares are created in the same domain. This means that you do not need to create any trust relationships because the domain user accounts and shares are in the same domain. If a domain user needs to access shares in other domains, you can create a domain user account with the same user name and password in those domains. 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 user account, Peter, with the same password. The Athens domain trusts the Berlin domain but no other trust relationships are established. The following table describes the access that Peter has while logged on to each domain:

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

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

2.3    Computer Accounts

A computer account is automatically created in the directory database for each BDC that joins a domain. Computer accounts are used to establish secure communications session.

A secure communications session is created when systems communicating in a connection are satisfied that the other system has identified itself correctly. Systems identify themselves by using their computer accounts. When a secure communications session is established, communications can begin between the systems.

Examples of secure communication sessions include the following:

2.4    Logging Into a Domain

To log into a domain, a user must have a domain user account either in the domain or in a trusted domain. An administrator creates a domain user account by assigning a user name and password to an account, specifying the user's identification data, and defining the user's rights in the domain. The Advanced Server then assigns a unique security identifier (SID) to the new account. See Chapter 3 for more information on creating domain user accounts.

Users can logon in to a domain in the following ways:

When a user of a Windows computer attempts to log into a domain, the NetLogon service on their computer attempts to locate and establish a secure communications channel with the NetLogon service on a domain controller that can authenticate the user. The NetLogon service automatically starts when the ASU server starts. These secure communications channels are used to exchange user identification data between computers' NetLogon services. The NetLogon service on PDCs and BDCs likewise attempts discovery with all trusted domains. After a domain controller is discovered that can authenticate the user, it is used for subsequent user account authentication.

2.4.1    Interactive Logon Authentication

On the user's local system, the Logon Information dialog box prompts the user for a user name, password, and domain or computer name.

The user enters their user name and password in the User name and Password fields. The user selects a domain or computer name from a Domain list. The content of the Domain list depends on whether or not the computer participates in a domain. If the computer is configured as follows:

To log on to the local computer, the user selects the local computer name. The computer checks its local directory database for the specified user name and password. If a match is found, the logon is approved. If a match is not found, the logon fails.

To log in to a domain, the user selects the domain name. The computer sends the domain name, user name, and password to a domain controller in the selected domain. The domain controller checks the domain name and then checks the user name and password against that domain's directory database and processes the request as follows:

2.4.2    Remote Logon Authentication

A remote logon occurs when a user is logged on to a computer or domain and then makes a network connection to another computer. The credentials used at interactive logon are used for the remote logon unless the user overrides those credentials by typing a different domain or computer name and user name in the Connect As box in the Map Network Drive dialog box.

If the user makes a network connection to a computer in a domain that contains their domain user account, the logon proceeds as if the user were connecting using an account on the remote computer. The remote computer authenticates the logon credentials against its directory database. If the account is not in the directory database but the Guest account is enabled with no password set, the user is logged on with Guest privileges. If the Guest account is not enabled, the logon fails. See Chapter 3 for information about the Guest account.

On some administrative screens such as User Manager for Domains, a user might need to precede their user name with the name of the domain where their domain user account was created to distinguish it from another user. For example, user JohnL from the Sales domain might appear as Sales\JohnL. This name would distinguish him from a different JohnL in another domain, such as Engineering\JohnL.

2.4.3    Cached Logon Information

The first time that a user logs on to a domain account from a given computer, a domain controller downloads validated logon information (from the directory database) to the computer. This downloaded information is cached on the computer. On subsequent logons, if a domain controller is not available, the user can log on to the domain account using the cached logon information.

Computers running Windows NT Server and Windows NT Workstation store the information used to authenticate the last several (the default is 10) users who logged on interactively. The credentials for users who log on to the local computer also are stored in that computer's local directory database.

2.5    Managing Domains

Managing domains includes the following:

2.5.1    Synchronizing the Directory Database

The PDC automatically sends timed notices that signal the BDCs to request directory database 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.

2.5.1.1    Directory Database Changes

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

Changes to the directory database are recorded in the change log. The log holds approximately 2000 changes. The size of the change log determines how long changes can be held. When the log is full and 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. 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.

2.5.1.2    Full and Partial Synchronization

Replicating the entire directory database to a BDC is called full synchronization. Full synchronization is performed automatically when a new BDC is added to a domain or when changes have been deleted from the change log before replication takes place. The NetLogon service default settings for the timing of updates (every five minutes) and the size of the change log ensure that full synchronization will not be required under most operating conditions.

Replicating only directory database changes that have occurred since the last synchronization to a BDC is called partial synchronization. You can force a partial synchronization to all BDCs or to a particular BDC. For example, if a new user is added to the domain or if a user's password changes, you can perform a partial synchronization to quickly replicate the new user's account or password change to the directory database on all BDCs.

You can use the Computer menu in Server Manager GUI to synchronize the directory database. The options that are available depend on the type of computer that is selected as follows:

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

2.5.2    Promoting and Demoting Controllers

There might be circumstances in which the PDC might become unavailable. For example, you might need to upgrade software or perform other maintenance operations.

If your domain consists of only a PDC and it becomes unavailable, users cannot log in. If your domain consists of a PDC and BDCs and the PDC becomes unavailable, users can log in to the domain; however, they cannot access shares that are on the PDC and you cannot create or modify user accounts because the master directory database is only on the PDC.

If the PDC becomes unavailable and you have a BDC in the domain, you can promote the BDC to be the PDC. When a BDC is promoted to PDC, 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 and the former PDC 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 NetLogon service nor participate in authentication of user logons, and its icon in the Server Manager window will be dimmed.

You cannot move a PDC to another domain until you promote a BDC. To move an ASU server to another domain, use the joindomain command. See joindomain(8) for more information.

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. You can choose to proceed without demoting the PDC or wait until the PDC can be demoted.

See Promoting a Backup Domain Controller to Primary Domain Controller and Demoting a Primary Domain Controller to Backup Domain Controller in Server Manager Help for more information.

2.5.3    Managing Domain Security Policies

ASU security policy settings can provide different levels of security for domain user actions on domain controllers, workstations, and member servers. You should establish a domain security policy as part of planning your domain.

When administering domains, security policy applies to the PDC and BDCs in the domain (they share the same security policy). When administering a computer running as a member server, security policy applies only to that computer.

You can define the following security policies:

2.5.3.1    Domain User Account Policy

The domain user account policy controls how domain user account passwords are used by all user accounts for a computer or domain and also determines the account lockout policy. Changes to account policy affect every domain user account on the computer or domain at the next logon. Table 2-1 describe the domain user account policy options that you can set.

Table 2-1:  Domain User Account Policy Options

Option Description

Maximum Password Age

The period of time that a password can be used before the system requires the user to change it.

Minimum Password Age

The period of time that a password must be used before the user is allowed to change it.

Minimum Password Length

The fewest characters that 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.

Lockout After

The number of incorrect logon attempts that will cause the account to be locked. The range is from 1 to 999.

A locked account remains locked until an administrator unlocks it or until the time specified by the Lockout Duration option passes.

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 the Lockout After option is set to 5, and the Reset Count After option is 30 minutes, then 5 bad logon attempts, each 29 minutes apart, would cause lockout.

Lockout Duration

Whether or not user accounts are locked until an administrator unlocks them (Forever) or for the specified number of minutes (Duration).

Forcibly Disconnect Remote Users From Server When Logon Hours Expire

Whether or not a user account that exceeds the time set by the Logon Hours option for that user is disconnected from all controllers in the domain. The user receives a warning message a few minutes prior to expiration of the logon hours.

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

See Section 3.1.1 for information on setting logon hours for a user.

Users Must Log On In Order To Change Password

Whether or not users can change their own passwords when they expire.

If you disable this option, users can change their own passwords when they expire without help from an administrator.

You can set domain user account policy options by using the following:

2.5.3.2    Audit Policy

Auditing allows you to record in an event log file selected activities of domain user accounts. In a domain, the audit policy applies to the PDC and all BDCs in the domain.

The ASU server can audit and record a range of events including system-wide events such as a user logging on and attempts by a particular user to read specific files. Both successful and unsuccessful attempts to perform an event can be audited and recorded. Table 2-2 describes the events that you can audit and record.

Table 2-2:  Audit Events

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 the File Manager, or a user sent a print job to a printer that is set for auditing in the 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 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.

Because an event 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 log. The maximum size of the log is defined in the Event Viewer.

You can set the audit policy by using the following:

You can view the logs by using:

2.5.4    Managing Trust Relationships

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 domain user accounts to be used in domains other than the domain in which these accounts are created. You need to create each domain user account only once and, through trust relationships, the account can be given access to any computer on your network, not just the computers in one domain.

2.5.4.1    Creating a Trust Relationship

Creating a trust relationship between two domains creates a computer account to be used by computers in the trusting domain to establish secure communications to the trusted domain.

Both the trusting and trusted domains must be configured to establish a trust relationship as follows:

  1. On the PDC in the trusted domain, add the name of the trusting domain to the list of domains that trusts it and assign a password for this relationship.

  2. On the PDC in the trusting domain, add the name of the domain to be trusted to its list of trusted domains. This requires the password from Step 1.

Note

A trust relationship will not work if the password assigned to a trust relationship changes on the trusted or trusting domain. If the password changes on the trusted or trusting domain, both sides of the trust relationship must be removed and recreated. When you recreate the trust relationship, you again must assign matching passwords for the trusting and trusted domains.

You can create and remove a trust relationship by using the following:

2.5.4.2    User Manager for Domains Limitations

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.

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

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.