Network planners face the challenge of designing a network that allows users and administrators to: access shared resources with a single log on and password, manage resources and accounts from a single location, and implement services that automatically update network account and security information.
Windows NT® Server Directory Services are the solution to these challenges. The Directory Services provide:
Before exploring Windows NT Server Directory Services further, it is necessary to introduce domains and trust relationships—the Windows NT Server features that work together to make directory services possible.
Windows NT Server directory services are based upon the configuration and use of Windows NT Server domains—logical groupings of users and computers for administrative purposes.
The group of computers that make up a domain can be organized in several ways depending on the structure of the company and the needs of the users. The design could be based on an administrative model, a geographic model or some other logical or common purpose. Experienced planners think of domains in terms of administrative units. In a large company, for example, each department could create its own domain. Thus, Human Resources and the Finance department could each have their own domains.
Trust relationships provide a secure communication channel between two domains. With a trust relationship, a domain will accept user accounts created in other domains as valid accounts and allow those accounts to access to local resources.
Note: Domains and trusts are explained in detail in Sections 2 and 3.
The Windows NT Server Directory Services make it possible for network planners, managers, and users to:
Looking at each of these components and features separately will provide a more detailed picture of the Windows NT Server Directory Services environment.
Windows NT Server Directory Services maintain the concept of "one user, one account." Because the Windows NT environment recognizes accounts outside of the domain in which they were created, users are able to cross trusts and access resources in any domain for which they have the appropriate permissions. This is true no matter where in the network the account is located. If the network operating system could not maintain the "one user, one account" concept, duplicate accounts could have conflicting permissions.
To illustrate the advantages of maintaining just one account for each user, suppose an employee from a large organization travels worldwide. The organization has multiple domains based on geographical locations. The employee can use a notebook computer to log on with only one account name no matter where the employee is located.
The scenario illustrated in the slide is a good example. A businesswoman whose home domain is in North America logs on while in Europe (1). In this case, the European domain controller will forward the logon request to the North American domain (2) for validation (3).
Once the user's home domain validates the account, the user can access resources anywhere on the network where he or she has the appropriate permissions.
Validating accounts across domains, a process called "pass-through authentication," makes "one user, one account" possible.
Trusts in Windows NT Server Directory Services make it possible for an administrator to grant access to shared resources regardless of their location. The ability to access resources anywhere on the network is called universal resource access, and it eliminates the need for multiple network accounts and passwords.
For example, when a user has an account on Domain A and attempts to access a resource in Domain B (1), one of the domain controllers in Domain B contacts a domain controller in Domain A to verify that the user has a valid network account (2). If the controller in Domain A validates the user, the server with the target resource verifies that the user from Domain A either has permissions to use the resource or is a member of a group that has permissions to use the resource (3).
Because trusts make the "one user, one account" concept possible, the user in the example above only needs to maintain a single account rather than multiple accounts.
Multiple accounts make it difficult to keep track of permissions. For example, when a user with one account in Domain A and another account in Domain B logs on in Domain B and attempts to access a resource in Domain B, one of the controllers in Domain B will validate the user. However, if permissions to the resource were only assigned to the account in Domain A, the user would not be allowed access to the resource because the user logged on as an account from Domain B, and permissions have not been granted to accounts from Domain B.
In a multiple account environment, users and administrators not only have to keep track of several accounts but multiple resource permissions and passwords as well.
With directory services, a single network administrator in one location can access any trusting domain in the network. Once in a domain, the administrator can use User Manager for Domains and Server Manager to manage:
Note: When a trust has been established, the administrator of the trusted domain can not administer a trusting domain until that administrator's account is made a member of the Administrators group in the trusting domain.
With the User Manager for Domains utility, an administrator can sit at any computer on the network that supports User Manager for Domains and manage any user account regardless of where the account is located.
The Windows NT Server's Server Manager is an application that uses directory services to support enterprise network operations including managing servers and computers.
To illustrate the role of directory services in remote domain management, suppose the administrator for the London domain of a large, multi-domain network is going on vacation. The backup administrator has the flu. To ensure smooth network operation in their absence, the London administrator can use User Manager for Domains to add the Paris domain administrator to the London Administrators group. This makes it possible for the Paris administrator to manage both the Paris and London domains.
Windows NT Server Directory Services provides synchronization and partitioning of the database to ensure smooth network operation automatically.
A domain administrator creates user accounts only once, on the Primary Domain Controller (PDC). The Account information is replicated (copied) automatically to the Backup Domain Controller(s) (BDC). When a user logs on, a domain controller (either the PDC or a BDC) validates the logon, checking its copy of the directory database for the correct user account, password, and any logon restrictions. Synchronizing the database eliminates any single point of failure for users logging on to the network.
In an enterprise network consisting of multiple domains, each domain will have a directory services database consisting of users, groups, and computer accounts within that domain. This capability allows the directory database to have multiple partitions within the entire network. Through multiple partitions of the database, the original large data base can be divided into smaller data bases which are easier to manage.
In a NetWare environment with multiple servers, users are required to remember:
To maintain user accounts and passwords in the Novell environment, the Supervisor must manage each server's bindery (the Novell account database) separately.
To simplify this, Directory Service Manager for NetWare (DSMN) provides a single network Logon for NetWare users by synchronizing accounts across all NetWare servers. Users need to remember only one account name and password for access to both Novell and Windows NT Server file, print, and application network resources.
DSMN allows administrators to copy NetWare user accounts to the Windows NT Server directory. This enables administrators to manage all network accounts from User Manager for Domains.
With DSMN, Administrators can:
The specified accounts are moved to the Windows NT Server domain and copied to the directory database. These accounts become Windows NT Server NetWare-compatible accounts and assume the account policy of the Windows NT Server domain.
If a user has accounts on two NetWare servers and these accounts have different user names, the administrator can merge the accounts' names when adding them to the domain. For example, DavidS and DavidSm could become DavidS, a single account.
Note: For more information about DSMN, refer to the Integrating Windows NT Server with NetWare Networks course.
The BackOffice applications were developed to take advantage of Windows NT Server Directory Services.
BackOffice single account management incorporates two separate services:
BackOffice applications in the Windows NT Server Directory Services environment offer several advantages including:
Because Windows NT Server Directory Services provides single-user access to network services and applications across the enterprise, BackOffice application developers can:
Because BackOffice applications have unique data access requirements, each BackOffice application:
For example, suppose the network administrator has created a group called SQLUsers, which contains all the users that need access to SQL Server. The SQL Server administrator uses the SQL Security Manager to grant the SQLUsers group access to SQL Server.
When a new employee starts work, and needs access to SQL Server, the network administrator will create a new account for the user and make him or her a member of the SQLUsers group. Nothing else needs to be done.
To implement directory services, a network designer will need to perform the following tasks:
As the slide indicates, the rest of the course provides the concepts, components, and hands-on experience to prepare network planners and administrators to use Windows NT Server Directory Services to meet these challenges.
At the end of this section, you will be able to:
In an environment where users and administrators are spread out across a network, resource sharing needs to be fast and simple, and network administration needs consolidation options. Toward this end, Windows NT Server Directory Services provide:
Trust relationships make this possible.
Trust relationships provide a secure communications channel between two domains. With a trust relationship, one domain accepts user accounts as valid accounts and allows access to local resources. This occurs even though the account does not exist in the local domain. For example, if a user has an account in Domain A, but needs to access a resource in Domain B where he doesn't have an account, a trust relationship can be established that allows resource sharing across domains. This happens through the user's single account in Domain A.
With trusts, the divisions between domains become invisible and allow administrators to see the network as one large organization rather than as a collection of LANs which must be managed separately. When trust relationships are properly established between domains, they allow a user to access the entire network through one user account.
Trust relationships move centralized administration to the enterprise level, rather than just the domain level. They simplify administration by essentially combining two domains into a single administrative unit. A user has to log on and provide a password only once to access any shared resources on the network for which the user account has been granted permissions.
Trust relationships can be set up as one or two-way relationships. In a one-way trust relationship, accounts in one domain can be given permission to access resources in another domain. One-way trust relationships are typically used in networks where user accounts must be centrally controlled in one domain, but resources require distributed control. For example, a company is migrating to Windows NT Server. They want centralized control over all the employee accounts, but want each department to control their own servers and workstations. To provide this, a corporate domain is created and all user accounts are placed in that domain. Each department then creates its own domain for their servers and workstations. By establishing a one-way trust relationship between the resource domains and the accounts domain, the users can be given permission to access resources in the departmental domains.
When the domains are joined by two one-way trusts, it is known as a two-way trust relationship. Accounts and resources are administered in each domain but can be given permission to access resources in the other domain. For example, the ABC company has two independent business units that want total control over their users, servers, and workstations. Each business unit can create its own domain with user accounts and resources. By establishing a two-way trust relationship between the domains, the two domains can have access to resources in the other domain.
When diagramming trusts and domains, trusts are always indicated with an arrow. In a one-way trust, the point or head of the arrow always points to the trusted domain, where the accounts reside, and away from the trusting domain, which usually contains shared resources.
In a two-way trust relationship, indicated by two arrows pointing in opposite directions, both domains contain user accounts that may access resources in the other domain.
In all trust relationships one domain is always the trusted domain while the other is the trusting domain.
The concepts of trusted versus trusting can be thought of in terms of users and resources. The domain with the resources is trusting users from a remote domain and will allow them to use the resources if the proper trust relationship has been established, and permissions are assigned.
If your neighbor wanted to use your VCR while you were on vacation, you would give your neighbor the key to your house, and your neighbor could enter your house and use your VCR while you were gone.
You have set up a one-way trust relationship with your neighbor where you trust your neighbor.
Your neighbor with the key (or user account database) represents the trusted domain. You represent the trusting domain with the VCR (resources). In a diagram of this arrangement, the arrow would point from you to your neighbor.
Setting up trusts properly requires knowledge and planning. Before setting up a trust relationship consider the following:
Using local and global groups across trusts is one way to make your network easier to administer and maintain. Keep in mind that your group strategy can be the same regardless of the domain model you implement.
When there are trust relationships between domains, global groups in a trusted domain can become members of a local group in a trusting domain. The trusting domain's local group can then be assigned permissions to resources, or administrative tasks, in the trusting domain.
The effect of this strategy is that the members of the global group from the trusted domain have the permissions that are granted to the local group in the trusting domain. The key is having global groups from a trusted domain join a local group in a trusting domain.
In an environment where multiple domains are connected by trust relationships, the primary group strategy is the same as that of a single domain: putting Users into Global Groups and Global Groups into Local Groups. However, across trust relationships, the global groups are defined in the trusted domain, and the local groups exist in all domains. The appropriate use of trust relationships, and global and local groups, can easily centralize administration in a multiple domain environment.
Using Windows NT Server Directory Services to manage large networks can be summed up in the following sentence: "Global accounts go into global groups, which go into local groups, which get permissions."
It explains how to implement a directory services structure which will manage any Windows NT network involving more than a single domain structure. It can be abbreviated with the letters A, G, L, and P.
The four letters stand for:
When an administrator coordinates the four components correctly, they make it possible to manage even the largest enterprise network from a single computer.
To clarify how this works, it is necessary to look at each component.
In Windows NT Server Directory Services, the network management process begins with global accounts. Global accounts can cross trusts, as opposed to local accounts which can function only in the domain in which they were created.
Because global accounts can cross trusts, they can move from domain to domain to access resources in any domain on the network.
Suppose, for example, a network consisted of two domains: Domain A and Domain B. The administrator should create accounts that can access resources in both domains, unless there is a compelling reason not to. Therefore, the administrator should create global accounts. Local accounts, on the other hand, would only be able to access resources in the domain in which they were created. A local account created in Domain B, for example, would only be able to access resources in Domain B. This local account would not be able to cross a trust to access resources in Domain A.
Using local accounts leads to a multiple-account environment and all the problems involved in having to keep track of multiple accounts, duplicate logons, separate permissions, and several passwords.
So, in a multi-domain environment, global accounts are essential to efficient account management. Yet, once global accounts have been created in one domain, the question remains, how do global accounts actually get across trusts form their home domain to a remote resource domain?
Global accounts can move from domain to domain on their own, but it is much more efficient to include them in groups which can also move from domain to domain. This is because groups are easier to manage than separate individuals.
If, for example, 35 users need to use a resource in a remote domain, it is far easier for the administrator to include them all in a global group and only have the one group to manage than it would be to manage 35 separate users all trying to use same resource.
Therefore, to get accounts from one domain to the next, the administrator creates global accounts and puts them in a global group. This way, accounts can go from one domain to the next in a neat, organized manner.
But one of the problems with global groups is that they cannot be granted permissions to use resources. Therefore, the question remains, once the members of a global group get to a remote domain, how can they get permissions to use resources in that remote domain?
Local groups can be granted permissions to use resources in the domain in which they were created. When a local group is assigned to use a resource, the permission to use that resource automatically extends to everyone in the local group.
For example, Office Support is a local group consisting of Margie Davis, Pete Thomas, Diane Lennon, and Ed Barret. Rather than give each of these accounts separate permissions to access information in a database, the administrator added them to the local group, Office Support, and gave Office Support access to the database. By giving the local group access to the database, the administrator automatically gave Margie Davis, Pete Thomas, Diane Lennon, and Ed Barret access to the database.
Not only can individual accounts be assigned to local groups, but global groups can also be assigned to local groups. This is the first half of the real key to managing large networks. The second half of the key involves permissions, and it will be described on the next page.
To answer the question from the previous page, then, the administrator would assign the global group to a local group which had access to the resource in the remote domain. Once the global group becomes a member of the local group, all the members of the global group automatically have access to the resource. This means that since all members of the local group have access to the resource, all members of the global group will automatically have access to the resource as well.
However, the question remains, what kind of access will members of the global group have in the resource, and how can that access be determined? If the resource is a database, for example, will they only be able to read the information or will they be able to change or even delete it?
Permissions can be assigned to local groups, and this will automatically include all members of the local group. Permissions can not, however, be granted to global groups. Therefore, to grant permissions to users in global groups, the global groups must be added to local groups.
Once global groups have been added to local groups, any permissions that the local group has will automatically be given to any global group assigned to it, and those permissions will extend to members of the global group.
If a global group were made a part of the local group that has access to a resource, all the members of the global group would automatically have the same access to the resource as the members of the local group. This is the second half of the key to managing large networks.
In a well-planned, efficient, enterprise network that uses the strategy of putting global groups into local groups and granting permissions to local groups, an administrator only has to grant permissions to one component, the local group. In this way, the administrator automatically grants those permissions to:
Considering the potential numbers of accounts in local and global groups, an administrator only has to grant permissions once, to a local group, in order to grant permissions to tens of thousands of users from every domain in the network.
Therefore, by combining four Windows NT components (global Accounts, Global groups, Local groups, Permissions—A,G,L,P), an administrator can simplify account and resource management in even the largest network.
In a multiple domain environment connected by trust relationships, use the following guidelines when implementing groups:
After you have a group strategy, you are ready to implement it.
In an enterprise network without directory services trusts, domains would exist as independent network entities unable to communicate easily with each other. Each domain would have to be managed separately. This affects not only network traffic and resource access, but the type of accounts the network can use as well.
An environment in which domains are unconnected by trusts would require separate network accounts for each domain. These accounts would be able to access resources only in their own domains. Such accounts, called local accounts, do exist in Windows NT Server.
However, in an environment where it is essential to share resources across domains, Windows NT provides another more versatile type of user account called a global account.
In the Windows NT Server environment, global accounts can cross trusts to access resources in different domains. Therefore, global accounts are essential to the concept of "one user, one account." Global accounts are the default account type when creating new users on a domain controller.
Local accounts are limited accounts that only have access to resources in the domain in which they were created. They enable users from an untrusted domain to access resources in the local account's domain. For example, a user in Domain A needs access to resources in Domain B and there is no trust relationship between the two domains. The Domain B administrator creates a new user, duplicating as much of the user's account information from Domain A as possible. The administrator then specifies that this new user's account is a local account type. This allows the user to access the resources in Domain B.
Local accounts are created the same way global (regular) accounts are. Local accounts, however, are not default accounts. As illustrated in the slide, the administrator must make a choice to designate an account as local.
Despite the restrictions, local accounts provide functions which can be valuable in the following situations:
While local accounts clearly have their place, they are not part of directory services. There are two primary reasons for this:
When a user changes the password in their home domain, the user will also have to change passwords in every domain where he or she has a local account. If users don't do this, they will be prompted for a password when they try to access a resource where they have a local account.
There are two keys to establishing one and two-way trust relationships:
Once trusts relationships have been established between domains, permissions can be granted across trusts.
Important: The trust relationship will not be complete until both domains have done their part to establish the trust relationship. The trust may be initiated from either domain.
To set up a one-way trust relationship, start User Manager for Domains, and then, from the Policies menu, choose Trust Relationships. There are two sections in the Trust Relationships dialog box:
The order in which trusts are established is not critical. However, it is better to establish the Permitted to Trust this Domain relationship first, and then establish the Trusted Domains relationship. This way, the new trust relationship takes effect immediately. If the Trusted Domains relationship is established before the Permitted to Trust this Domain relationship, it can take up to 15 minutes for the trust relationship to take effect.
Below is a recommended sequence that ensures that the administrator from the trusting domain receives a verification of a successfully established trust relationship:
Setting up a two-way trust relationships is very much like setting up one-way trust relationships.
When a two-way trust is established, the same domain name appears in both the Trusted Domains and the Permitted to Trust this Domain boxes.
The administrator in the trusted (account) domain may provide a password as part of implementing the trust. The administrator in the trusting (resource) domain must enter this password when it is time for the trusting domain to complete the trust. That is the only time the trusting domain administrator needs to enter the password.
This password is another form of security. The trusted domain administrator uses the password to control which domains will be allowed to participate in trust relationships.
Note: Turning a computer off will not affect trusts. As long as there is one domain controller running in the trusted domain the trust will remain in effect. If all domain controllers are off, starting one will reestablish the trust.
Once a trust has been established, an administrator can grant permissions across the trust. Permissions can be set at the time a user or a group is added to a domain, or permissions can be modified at a later time.
Permissions are added and modified through File Manager as described in previous Windows NT Server courses.
Pass-through authentication makes it possible for users to log on to computers or domains in which they have no account. With pass-through authentication, a user with an account on one domain can access the entire network—including all domains that trust the user's account domain. Once logged on, the user is known on the network as DomainName\Username, where dominate is the domain that contains the user's account and authenticates the logon request. For example, in a large network consisting of several domains tied together by trust relationships, a user can log on at a computer in Domain B and be verified by the user account database in Domain A.
Pass-through authentication can occur during either of the following instances:
The trusted domain logon process is done in the following sequence:
Two types of problems can interfere with trust functions in an enterprise system:
Windows NT trust relationships are non-transitive meaning permissions between two domains cannot be passed through to a third domain. For example, if the Research domain trusts the Production domain, and the Production domain trusts the Marketing domain, then the Research domain does not automatically trust the Marketing domain.
A user with an account in the Marketing domain who attempts to log on while physically located in the Research domain will not be authenticated because pass-through authentication will not occur between Research and Marketing. Marketing and Research have to set up their own trust relationship before pass-through authentication can occur between them.
A trust can be successfully implemented, function correctly for a period of time, and then fail or brake. A failed or broken trust is rare, but it could be caused by the following:
When creating, maintaining, and using trust relationships, there are a number of issues that can inhibit proper use of the trust. Following is a list of common trust relationship issues and possible resolutions:
Issue |
Possible resolution |
|
Cannot establish a trust relationship. |
Verify that the primary domain controllers in each domain are running. |
|
Cannot verify the trust relationship. |
The trusted domain must permit the trusting domain before the trusting domain can attempt to establish the trust relationship. Verify that no session exists with the primary domain controller. |
|
The trust relationship is broken. |
If a trust relationship is broken, trusted accounts will not be available for use anymore. Re-establish the trust relationship. |
|
Cannot re-establish a broken trust. |
Verify that the primary domain controllers in each domain are running. |
|
Cannot use trusted accounts. |
The trust relationship may have been established in the wrong direction. Break the existing relationship, and have the trusted domain permit the trusting domain, and the trusting domain to trust the trusted domain. |
|
Cannot administer another domain. |
Verify that the trusted domain's Domain Admins group is added to the local Administrators group. |
|
Access is denied when using trusted accounts. |
Check to see if the same account name exists in both domains. In a trust relationship, each account should only appear in one domain, the trusted domain or the local domain, but not both. |
|
Can access other domain resources when using a local account. |
Check if the same account name exists in both domains. In a trust relationship, each account should only appear in one domain, the trusted domain or the local domain, but not both. |
|