Windows nt 4.0 trusts

For more information about how to back up, restore, and modify the registry, click the following article number to view the article in the Microsoft Knowledge Base: How to back up and restore the registry in Windows. Note Windows NT 4. Scenarios that are relevant to Windows NT 4.

The following information is informational only and is provided to facilitate an easier transition from Windows NT 4. The system cannot log you on now because the domain DomainName is not available. A domain controller for your domain could not be contacted. You have been logged on using cached account information.

Changes to your profile since you last logged on may not be available. Please ensure that you can contact the server that authenticated you. The following error occurred: Access is denied. The following error occurred: The system detected a possible attempt to compromise security. To repair a trust to a pre-Windows domain you must remove and re-add the trust on both sides. This problem occurs because of the default behavior of the Allow cryptography algorithms compatible with Windows NT 4.

This policy is configured to prevent Windows operating systems and third-party clients from using weak cryptography algorithms to establish NETLOGON security channels to Windows Server based domain controllers. Important Windows NT 4. If you make a large number of changes to the domain SAM, or make changes that must take effect immediately such as unlocking a user's account , you can perform a full or partial manual synchronization with Server Manager.

Server Manager's C omputer menu offers the following synchronization options:. As a rule, it's best to synchronize the entire domain from the PDC. Doing so ensures that all changes are pushed to the entire domain.

Only changes get pushed, not the entire SAM, so in most cases less than a changes , network traffic due to domain synchronization is insignificant. If you're concerned that a large number of SAM changes might affect network performance, you can change Registry values on each BDC to control the replication frequency and the percentage of system resources assigned to perform synchronization.

Even in a small, self-contained domain, you should have at least one BDC to accommodate user logons in the event of failure of the PDC. If you're building a large domain, you must determine the number of BDCs needed to accommodate all your users. Microsoft recommends a maximum of 2, users per BDC, but your network architecture is more likely to determine this number.

For instance, if you have a branch office that connects to the rest of your network with a slow link, it makes sense to place a BDC in the remote office for local authentication, as well as file and printer sharing. Fortunately, it's a relatively simple matter to add BDCs as required to handle the authentication load. Later in this chapter, the section "Deciding on the Right Design" provides recommendations for distributing BDCs within one or more domains.

When a Windows client is added to the domain, Windows NT Server creates a domain machine account for the client. The machine account is a unique SID assigned to the client name to identify the client to the PDC and BDC s so that users logging on to the client can access domain resources. Before a client running Windows NT Workstation 4. The Domain Administrators global group automatically is made a member of the client's Administrators local group so that Domain Administrator members have access to the client's resources.

When you log on to the client, the local SAM authenticates the logon name and password for access to the client's resources.

Next, the logon name and password is passed to the BDC or PDC for domain authentication and access to domain resources. This process, called workstation security , permits logging on to the client without the need to join the domain.

Windows NT Workstation is the only Microsoft client that uses the concept of machine accounts. Windows 3. When you want to authenticate to resources in a domain from these clients, you're simply using your domain user ID for authentication. The machine account provides an additional level of security for Windows NT Workstation. That is, a valid machine account enables an administrator to restrict access to domain resources based on a user authenticating from a specific domain workstation.

Also, workstations with machine accounts can be administered from Server Manager. From Server Manager, you can view a workstation's shares, files in use, or where to send alerts generated by that workstation. The unique SID of the machine account contributes to Windows NT security, but the SID creates problems when you want to move devices into and out of domains, or to rename a domain. The following sections describe the issues involved with reconfiguring clients and servers for use in different domains.

You may find a need to move a client from one domain to another. For example, a user in the Accounting domain may be relocating to the Sales domain. Moving a client to the new domain means changing that client's domain SID to match that of the new domain. When you move a client running Windows NT Workstation to a new domain, you connect to the new domain by changing the domain's name in the Identification page of Control Panel's Network property sheet. If you log on to the client as a member of the Domain Administrators group, you can change the domain to which the client is assigned and receive a new SID for its machine account when you connect it to the new domain.

To let users change domains on their own, a member of Domain Administrators must choose A dd Computer to Domain from Server Manager's C omputer menu to create a new account for the client in the other domain. If you have a Windows NT Workstation client in DomainA that you want to move temporarily to DomainB, you must re-create a machine account for that machine when reconnecting it to DomainA. Moving a domain controller from one domain to another isn't a step to be taken lightly. If you want to rename a domain, all domain controllers must be renamed.

You can change the domain name of a PDC or BDC to a new, unique domain name as described in the next section , but changing the domain name doesn't change the domain SID. After you reinstall Windows NT Server 4. Moving a plain server to a new domain follows the same process as moving a client running Windows NT Workstation 4. The plain server receives a new machine account SID, but the new SID is transparent to clients that access the server-based applications. When you move a Primary Domain Controller from one domain to another, all references to user and group accounts that existed in DomainA such as file and folder permissions for NTFS volumes are lost.

File and folder permissions for the server in the new domain appear as Account Unknown. Renaming a domain requires you to change the domain names of all devices installed in the renamed domain. Changing the domain name of every device, including BDCs and clients, may be a huge task if you've installed Windows NT to many servers and clients across a dispersed network.

If DomainA participates in trust relationships with other domains, renaming the domain breaks the trust relationships, and you must re-create them. Windows NT trust relationships are the subject of the next section. The objective of Windows NT Server's domains and trusts is to provide users with a single logon to authenticate them to Windows NT Server resources, no matter where these resources are physically and logically located.

An understanding of the authentication process is necessary to take maximum advantage of Windows NT Server 4. Familiarity with the authentication process also is necessary to optimize the logical topology of your network to balance logon speed with the performance of applications running on your Windows NT 4. This book uses the term logon to include the authentication process. Technically, authentication precedes logon, because users can't log on to the network until they're authenticated.

Unless otherwise indicated in the text, logon includes both authentication and logon operations. Domain controllers verify that a particular user or machine running Windows NT has valid access to the domain. The NetLogon service provides a secure channel for messages associated with authentication and domain synchronization. A secure channel is a connection between the NetLogon services on two machines that's established and maintained internally by Windows NT's security subsystem, using its own set of user names and passwords.

Administrators have no access to this connection. When a client running Windows NT Workstation is powered up, the client goes through a series of steps to authenticate to the domain in which the client is installed. The authentication process depends, in part, on the network protocol in use. After the machine is authenticated to the domain by the fastest-responding domain controller, any user that logs on to that machine uses the responding domain controller's domain SAM database to verify his identity by means of a user name and password.

The process a client uses to choose an authentication domain controller is based on the fact that the controller responding most quickly to the request provides the authentication service to the client. There's no simple means to specify particular domain controllers to provide authentication to a set of workstations. If you have domain controllers across a slow link, there's an off chance that those domain controllers might respond first to client requests, and provide authentication services across that slow link.

This is an undesirable situation if the link is very slow. The goal is to prevent unwanted responses from remote domain controllers. You can restrict candidate domain controllers by creating a static mapping in WINS of a domain name type with a list of only those domain controllers that you want to respond for authentication services. In the case of a network that's broadcast-based, such as NetBEUI or NWLink, you can control where the broadcasts go by using bridge filters and limiting broadcast forwarding between network segments.

Any DCs that reside on the same physical network segment as a client, however, always receive the broadcast request for authentication. Deciding where to place your domain controllers depends on the network protocol you're using and the topology of your network.

A server farm consists of one or more network segments wherein all servers reside see fig. Each workstation segment has an equal opportunity to access both authentication and file and print services provided by the server farm. In a less-segmented flat , bridged, or broadcast-based environment such as that illustrated by figure In this configuration, the domain controllers and other servers can quickly service large numbers of workstations, regardless of the network protocol used.

If you're designing a domain to support remote offices that access your corporate network over slow links, such as ISDN or Switched lines, install a BDC in each remote office see fig. The BDC also provides file and printer sharing services for the remote office. The majority of traffic on Windows NT networks isn't authentication, domain synchronization, or name and browser requests, which occur relatively infrequently.

These two different trees have a separate namespace, but users can easily share and locate resources. The different domain trees in a forest act completely independently of each another. In order to create a forest, a root domain must exist. An existing domain tree cannot be joined to another tree without first destroying the tree and recreating it.

Forests cannot be further grouped. Active Directory Forests are commonly used for joining two separate companies into one Active Directory Environment whilst keeping separate identities. However as mentioned previously, two forests cannot be joined into a single forest without first destroying one of the forests and recreating it in the other.

There are workarounds for this such as cross-forest transitive trusts which you will read about later. Domain Controllers in a forest store information only for their own domains, but they share and replicate information such as trust, site and services information.

The Schema states the format of information stored in the Active Directory database. For example, the User object in Active Directory has several properties such as username, password, phone number, etc. The schema can be modified to include additional properties. For example, Exchange adds a mail property to the user account.

The Active Directory schema must be consistent for the entire Active Directory forest. Replication will not take place until the schema is consistent. E all domains have Exchange installed. A Windows Domain can contain more than one Domain Controller. All Domain Controllers in the domain will store the Active Directory database. Microsoft recommends that you always have more than one Domain Controller running a domain. Having additional Domain Controllers allows for fault-tolerance and load-balancing.

This domain has two controllers. Any changes made on either Domain Controller will be replicated to the other. There are no primary or secondary Domain Controllers as in NT 4. This is known as a multi-master arrangement.

In an Active Directory Forest or Tree, each domain controller stores a copy of its own domain. Although only Domain Controllers within a forest can replicate , Domains in different forests can share resources and authenticate users by using trusts. All Domains within an Active Directory forest trust each other by default, however trusts can be setup manually between Domains in different forests.