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:
Primary domain controller (PDC). A PDC stores and maintains the directory database and authenticates domain user logon requests. A domain is created by configuring an Advanced Server as a PDC. There is only one PDC per domain.
You cannot configure the ASU server as a PDC in a Windows 2000 domain.
Backup domain controller (BDC). A BDC receives a copy of the directory database to authenticate domain user logon requests. This copy is synchronized periodically and automatically with the PDC. There can be many BDCs in a domain.
You can configure the ASU server as a BDC in a Windows 2000 Server domain only if the Windows 2000 Server is configured for mixed mode.
Member server. A member server maintains its own local user account database and does not receive a copy of the directory database, and therefore, does not process domain logon requests. A member server can participate in a domain to offer shared resources; however, a user must have a user account on the member server or in a domain in which the member server trusts. Trusts are described in Section 2.2. There can be many member servers in a domain.
You can configure the ASU server as a member server in a Windows 2000 Server domain if the Windows 2000 Server is configured for mixed or native mode.
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:
A trusted domain model in which Advanced Servers are configured in multiple domains and the domains establish a trust relationship. A trust relationship allows a trusting domain to trust that a trusted domain authenticated its users and, therefore, allows the users of the trusted domain to access to its shares.
A single domain model in which each Advanced Server is configured in one domain.
There are two types of trust relationships:
A one-way trust relationship is when one domain trusts another domain.
A two-way trust relationship is when two or more domains trust each other.
There are two common types of trusted domain models:
The single master domain model, which is best suited for environments with a small number of users.
The multiple master domain model, which is best suited for environments with a large number of users.
With each of these domain models, you create two types of domains:
A master domain in which you create domain user accounts.
Resource domains in which you create disk and printer shares.
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:
Centralized domain user account management. By creating all domain user accounts in a single domain and creating one-way-trust relationships between domains, you consolidate the administration of user accounts and avoid having to administer separate user account databases. As a result, users need only one domain user account to use shares in any of the domains.
Decentralized resource management or local system administration capability. Departmental domains can have their own administrators who manage the resources in the department.
Resources can be grouped logically, corresponding to local domains.
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:
Is scaleable to networks with any number of users.
Allows users to log on from anywhere in the network.
Provides centralized or decentralized administration.
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:
A BDC creates a secure communications session with the PDC to receive a copy of the master directory database and updates.
A PDC and BDCs in a trusting domain create a secure communications session with the PDC in trusted domains to pass user authentication information.
A Windows NT Workstation or Windows NT Server system running as a member server in a domain creates a secure communications session to a PDC or BDC in a domain to pass user authentication information.
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:
Interactive logon occurs when a user types information in the Logon Information dialog box displayed by the computer's operating system. In the Domain box, the user selects either the name of a domain or the name of the computer being used for logon, depending on where the user account is defined.
Remote logon occurs when a user already is logged in to a domain and makes a network connection to another computer. For example, the user connects to another computer using the Map Network Drive dialog box.
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:
As a member of a workgroup, the list contains the local computer name.
To participate in a domain, the list contains the computer name and every domain (including trusted domains) in which user account can be authenticated.
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:
If the domain name is correct and the user name and password match an entry in the directory database, the domain controller notifies the computer that the logon is approved.
If the domain name is recognized as a trusted domain, the domain controller passes the user name and password information to a trusted domain controller for authentication. If the trusted domain controller authenticates the account, the logon information is passed back to the initial domain controller and the user is logged on. If the account is not authenticated (that is, not defined in the trusted domain directory database), the logon fails.
If the domain controller does not recognize the domain name or if there is no entry in the directory database for the user, the logon fails.
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:
Synchronizing the directory database between the PDC and BDCs
Promoting and demoting controllers
Managing the domain account policy and audit policy
Managing trust relationships
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:
When the PDC is selected, the Synchronize Entire Domain option is available. 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 BDC is selected, the Synchronize With Primary Domain Controller option is available. This command copies the latest directory database changes to the selected BDC only.
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)
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:
The domain user account policy defines how passwords are used by domain user accounts.
The audit policy defines the types of events that are recorded in an event log.
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:
The
net account
command.
For more information
on the
net account
command, enter:
#
net help accounts /options
| more
The User Manager for Domains and selecting the Account option from the Policies menu.
See Managing the Account Policy in User Manager for Domains Help for more information.
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:
The
net auditing
command.
For more information
on the
net auditing
command, enter:
#
net help auditing /options
| more
The User Manager for Domains and selecting the Audit option from the Policies menu.
See Managing the Audit Policy in User Manager for Domains Help for more information.
You can view the logs by using:
The
elfread
command on the system on which
the ASU server is running.
See
elfread
(8)
The Event Viewer on a Windows system. See Chapter 6 for more information.
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:
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.
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:
The
net trust
command.
For more information
on the
net trust
command, enter the following command:
#
net help trust /options
| more
The User Manager for Domains and selecting the Trust Relationship option from the Policies menu.
See Trust Relationship Policy in User Manager for Domains Help for more information.
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:
The other domain already must trust your domain.
The domain user account that you are logged on to has the same name and password as a domain user account in the other domain.
The other domain has enabled its Guest account, and the domain user account that you are logged on to does not have the same name as any domain user 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.